Re: pyglet audiogame examples
yes. Though I have never heard them called widget trees. If you are thinking WX event handling, that's similar but not the same. In audiogame_engine, the topmost screen always gets the event first; if it doesn't handle it or wants to pass it through, the next screen down gets it and etc. until one of them stops it, or there are none left.
In most frameworks for this kind of thing, you only get a stack. A screen or the equivalent will do whatever it needs to to get the world ready for the next one, say stopping all sounds, and then push it on top. When the new one is done, it pops itself back off and has either modified the world or called a function somewhere to indicate your choice. Or whatever, really.
if you need to pop multiple screens off, that needs to be coded in the screens themselves. I.e. if escape is supposed to get rid of all the menus, then each menu needs to detect the closure of whatever submenu scr
eens it has open in that manner somehow. It is probably easier to make a generic menu/submenu screen that you populate with stuff, say menu items and callbacks for if they're selected. I'm not sure if you're saying that audiogame_engine doesn't let you pop multiple screens at once and you want to or something completely different.
Pyglet does basically this, but better. in Pyglet, you don't have to inherit from a magical base class that magically does stuff and you can define new events, say incoming network message. The Pyglet programming guide does a pretty good job explaining the how, but the why is basically not there.
What you end up with is something that's a little more complicated individually, in that you have to type some boilerplate framework code around it. But it's better than the one taken together: you won't have 20 if statements that do different things depending on some sort of state var
iable and a function that goes on for a very long time dealing with it.
As for when you really, really need it though?
Items that add one-off keystrokes. Just push some event handlers that intercept keystrokes that item is interested in. A flute, for example. That you play with the number keys. There are other ways of doing this, but the general system here is sufficient to do it.
Modaless menus and dialogs. A modal dialog is something like a pause screen or inventory screen in an offline, single-player game: while you are in it, nothing else happens. A modaless menu, supposing that I am spelling that term right, is the opposite. So, say, a spellcasting menu that doesn't stop gameplay and takes over a couple keys somewhere. Or a combat system like Final Fantasy XII where you select all your attacks and stuff but can walk around the whole time. Or basically every menu ever in an online game.
You can do gam
es without it. It's just something you're eventually going to end up using. Other types of apps like WX use it; it's pretty common to have a setup like this. The point is mostly separating logic for reasoning purposes.
_______________________________________________ Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
