Opioid2D Status Update
I've been quiet for a few days, so here's a brief feature checklist on how Opioid2D is coming together.
- Rendering engine: 100% done.
- Scene engine: 85% done. Still missing state transitions and a couple of callbacks, but otherwise all the important functionality from pygext has been translated.
- Sprite engine: 90% done. Nothing fancy here, so it has been straightforward to re-implement. Added very basic physics on top of the pygext API (velocity, acceleration, friction).
- Action system: 60% done. The base classes need some more tuning, and then I'll get to work on implementing all the different actions from pygext.
- Event handling: 90% done. Needs support for multiple states.
- Keyboard handling: 95% done. Needs testing and might require some small tweaks.
- Mouse handling: 10% done. Barely started with this, but should be a quick job.
- Collision detection: Not started yet, but I'm going to start implementing this tonight. The plan is to start with simple radius-based collision detection (as in pygext) and then expand it to (convex-) polygonal collision nodes and add optional multi-sampling for fast moving entities.
- Particle engine: Not started yet, but should be very straightforward to translate from pygext's implementation.
- Large sprite support: Not started yet. Sprites are currently constrained to a maximum size of 512x512 by the rendering engine.
- Camera system and scrolling: Not started yet.
- GUI framework: Not started yet.
posted by shang at 12:01
4 Comments:
this looks nice! a couple comments:
- why not have nestable Scenes, instead of multiple states within a scene and all those methods for the different states needing to be inside the same class? it seems a state is almost the same as a Scene anyway, and might want to create its own entities, which makes it exactly like a Scene.
- it might be nice for entities to have named action layers/channels to help manage multiple action chains executing in parallel, without keeping references to all the actions around.
The difference between a scene and a state is that a Scene "owns" the layers and sprites, so when the engine changes to a new Scene, all current sprites are cleared away.
The main use-case for states is when you want to temporarily override one or two event handlers in the current scene, while retaining the layers and sprites intact. Having fully featured nested scenes for this purpose seems like overkill. :)
Being able to refer to action chains by name is a very good idea. I'll be sure to include that.
I can totally see the usefulness of states for things that don't have a lot of sprites associated with them, and like you said to override a few event handlers. I guess I was thinking of a lot of possible situations with the main game scene, which will probably be the most complex scene already.
There are often a lot of different overlays that happen over a game screen, for example an options window with a bunch of sprites for it, buttons, checkboxes, sliders etc, with the main game screen still visible in the background. Then if you press the "Quit" button you might even get a popup over that, that if you press "No" on that popup it will go away and you'll be back in the Options state, then pressing "Back to game" gets rid of the Options window. Plus they're modal so they need to override ALL the event handlers. Also you might have level intro/outro popups, or some kind of RPG-style inventory/store overlay or some other in-game stat-adjusting overlay on top of the game screen, which might have non-trivial functionality associated with it.
Now we have a ton of extra stuff in the Game scene class, which will already probably be pretty full of other stuff. Granted most of these extra things are pretty simple, but if they all have to be handled inside one scene it adds up, so I'd want to split many of them out into other classes.
Then I'd end up with a bunch of extra state callbacks in the main game scene class that just delegate to instances of other classes, which handle events and create/destroy a bunch of sprites just like a scene does. At that point it just seems easier to make them regular scenes that are drawn on top of their parents, and get rid of all those extra callbacks.
This kind of thing would admittedly make director a little more complicated, but I don't think the scene class would have to even know about it. Also I think it could be done without breaking any current functionality. If I get a chance in the next couple of weeks I might try hacking something like this into pygext and send you a patch to try to convince you.
Ah, thanks for the longer explanation. I can understand what you are after much more clearly now.
Yes, that sort of thing would be useful, and not that hard to implement even. If you want to discuss this in more detail, please email me at shang@iki.fi. It'll be more convenient than commenting here. :)
Post a Comment
<< Home