Re: pyglet audiogame examples
Everything that's actually worth using does the WXPython main loop. It's called the event loop, and you'll probably end up just duplicating it yourself. Twisted, Pyglet, lots of stuff. The fact that Pygame doesn't has always baffled me as getting that right is actually not as simple as it looks. You can get a basic one working, but you can't get it doing all the power saving stuff and with precise timing and all that like they do so easily. WX doesn't have a choice though. Their main loop is so complicated (and has to be) that you'd never really be able to duplicate it.
As for cross-platform accessibility, you can't. It can't be done. This has to be done on a per-platform basis. There is no choice. I wouldn't hold your breath on Kivy, and Kivy is, as you said, decidedly not simple. I'm going to probably have to go over there now.
As for Libaudioverse?&
nbsp; Well, yeah, I do want to make money. But I still maintain: Pygame for sound, something else for, well, everything else. Or just use the avbin hack.
Do note: you can almost certainly get the Pyglet and WX event loops going in the same app. I'm about to try this; it doesn't look overly hard. The Pyglet guide tells you how to make your own Pyglet event loop function, and the WX event loop does have support to call stuff every so often. This lets you have the game-oriented Pyglet event handling for game stuff and the WX widget-oriented event handling for the WX stuff.
Don't use decorators. Make people subclass your screens. This is simple, programming language agnostic, and pretty standard. Also, yes, you do want to break it into functions. Your idea of actions as things that happen every tick is kind of off: a key may be pressed at any time, for example. Whether the engine makes it part of the ti
ck is beside the point; it shouldn't be conceptually exposed that way. Make a base class, give it empty event handlers: on_key_down, on_key_up, on_mouse_move, on_tick. Those should be sufficient and should take different arguments depending on what they're for. The action fo jumping should happen through setting the is_jumping flag or the jump_next_tick flag, not through having tick read controls directly. The latter does not allow for control remapping or platform-neutral anything, really.
You probably won't win me to your engine, but you probably aren't expecting to. My personal effort is already at the point where I'm putting in generic object editors which allow one to, well, edit objects. It's decidedly not basic, but it's looking like it's going to end up being more powerful than I expected going in, which is actually really nice if true. I suppose that part of this is that I don't care
so much about making it super friendly to new programmers, I care about making it powerful enough you could write online games and Shades of Doom clones with it pretty easily. This does mean adding complexity at the beginning; there's no really good trade-off here, and I'm far enough along that it's not worth cutting out complexity if that means cutting out capabilities or making the code ultimately harder to deal with for gains at the beginning.
_______________________________________________ Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
