Jackdaw and the entity-component system

13 views
Skip to first unread message

Sam Foster

unread,
Feb 17, 2012, 9:02:46 AM2/17/12
to leedsjs
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

Sam Foster

unread,
Feb 17, 2012, 9:36:46 AM2/17/12
to leedsjs
Actually, there's a couple of other important components we need if
we're following conventional game architecture: a renderer, and a
camera.
The renderer is what turns the entities' state into the visual
representation - i.e. it manages the canvas and draws everything
visible to it on each tick. We could have other renderers - I like the
idea of an ascii art renderer, a webgl/three.js renderer etc.
The camera translates game coordinates into viewport coordinates and
does any scaling and skewing etc. necessary. That lets us keep
knowledge of whether we are top-down, side-on, 3d/first-person or
whatever out of the entity and game logic and data. Again, it should
in theory be trivial to change the camera to get pan-ing, side vs. top-
down, or whatever.

There are plenty of pseudo-code and referenceable implementations of
both of these things out there if someone wants to take them on.

On Feb 17, 2:02 pm, Sam Foster <potatosculp...@gmail.com> wrote:
> 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....

Abe

unread,
Feb 19, 2012, 9:20:30 AM2/19/12
to lee...@googlegroups.com
Thanks Sam,

Those are some interesting articles.

The entity component system looks like it could provide some exciting benefits.

I agree that the github issues system could help us avoid stepping on toes.

Perhaps we should get into a habit of assigning ourselves to issues
before starting work so that others don't do the same task/ bug.

I added a couple of labels (task and bug) that we can use to help
filter and understand the issues.

I have created an issue for adding the movable component to the player
on level_002, labelled it a task and assigned myself to to it.

Cheers,
Abe

Reply all
Reply to author
Forward
0 new messages