If you're watching the jackdaw repo on github, you'll have seen some
commits go in recently. I've put in the start of an "entity component"
system. This is a pattern widely used in the game industry which
avoids deep class heirarchies, lends itself well to data-backed
objects (think describing a level and all it contains with a JSON
file).
Here's a couple articles on entity-component that I found
enlightening:
*
http://www.gamasutra.com/blogs/MeganFox/20101208/6590/Game_Engines_101_The_EntityComponent_Model.php
*
http://cowboyprogramming.com/2007/01/05/evolve-your-heirachy/
*
http://scottbilas.com/files/2002/gdc_san_jose/game_objects_slides.pdf
There's lots to do.
* Currently, although there's a test/demo of the sprite component, its
only used in the 'example' level. It could be adopted in the level_002
and level_003 levels to turn our square player character into a moving
8bit stylee dude.
* I have the entity's render method doing all the sprite ->
canvas.drawImage stuff. Probably that should be refactored to a method
on the sprite component?
* The key, walls and door in the levels should all be entities
* The keyboard controls are now implemented as a component; we could
use an on-screen "game-pad" control too for mobile/touch devices
* collision needs to raise an event and be handled smartly so for some
types if means the collider bounces back, for others (like the key and
door) something else happens.
Apart from that and other stuff that will be apparent if you look at
the code, we're at a point now where we can use some more graphics and
maybe sound. And, if we want to do levels using three.js or box2d or
whatever, there's some work there to untangle the level from the game
logic so the game really just keeps track for truly global/game-scoped
stuff (the levels, maybe player score/lives), and the level is
everything else.
If you do take something on, please just drop a note here or create an
issue in github so we don't have people stepping on each others toes.
thanks,
/Sam