The Blog

Using an entity component system in AS3
August 29th, 2012Game DevelopmentJames 2 Comments

An ECS is a process if creating your game objects by aggregating different parts into
a unified whole. The parts are given to an entity so that systems can process them
to do something meaningful or cool (like spawn a bucket of skulls).

A player entity?

The end result is that your game objects (entities) are just a data structure that can
store many parts (components).

To make the parts work you create systems that can process an entities components
so they can do stuff.

Entity Location State Health Speed
Player x x x x
Bullet x x

The entity component system I am referring too is based on the Relational Model (think SQL databases) so entity is a row where each column is a component.

The systems that process components in an entity need nodes (primary keys) from the relational
table so they can process sets of components without needing to understand who has them.

Node/Key Location State Health Speed
Mover x x
HealthDegrade x
StateMachine x

This means that the systems, components and entities are all decoupled from each other,
which is normally a hard thing to pull of in the standard inheritance style development.

An entity system will select all of components in an entity  that are apart of its key, if it cannot
get a result then the entity does not belong to the system and will not be processed.

For a look of what components you might want to use have a walk over to Michael’s
post about common components here.

When should you use one?

There are mixes opinions about when such a system should be used however
from my personal experience I would recommend it if any of the following two
scenarios apply to you:

  • Your game will have a large scope, to me that is anything that will take more than 5
    weeks to develop
  • Your game is reasonably large and you need to rapidly develop your game using
    some evolutionary process such as agile. Requirements are likely to change.

For a small game like Snake, Pacman or even Asteroids it could be a little over kill
as an entity component system takes longer to get the ball rolling due to setting up
the initial components/systems.

On a fresh game project I tend to spend a fair deal of time working on common/general
components and systems before reaching the juicy stuff. A small game will be easier and quicker
to just roll out a standard game-object class with some inheritance. (Ironically using an inheritance based
methodology will be quicker to set up but far longer to change/remove/add later on in your development).

I guess from the above rant it would be fair to say that use an entity component system if you want to develop your game faster long term.

What is Ash?

Ash Entity Framework is a very nice and well though of ECS for AS3!

Its creator Richard lord has written a series of articles about them which I highly recommend,
it also talks about some theory.

  1. Hello Ash
  2. What is an Entity Component System?
  3. Why use an Entity component System?

High level overview of Ash

Ash is divided into four main aspects:

Diagram

Game

Ash uses its Game object to add/remove/update entities and systems so that
its processing is automatically handled without us needing to write our own
code for it.

It could be seen as the heart of the system and in practice I spend far less time adding entities
and systems compared to writing actual game components and systems.

Possible gotcha

Ash Game has an update function that will update all of your systems in priority order
in a time dependent fashion.

_ash.update(elapsedTimeSeconds);

If you are using the Flash Event Manager to update your game, such as using an ENTER_FRAME event
you could run…

_ash.update(currentFrame/framesPerSecond);

…but this if you use time dependency’s in your game, if you are not accounting for elapsed time
just pass in  1.

Entity

Your entities can have components added at any point in time, when a component is added your systems may be informed from the Ash Game that the entity has become apart of the system.

This means that by adding/removing components an entity can change behaviour at run time very easily!

If your entity has a UserInput component that a UserInputSystem will process to update player movement, you could remove it when a cut-scene starts to prevent the player from receiving input…
…when the cut-scene has finished you can then add the UserInput component and he will work again!

When your entity has components added just add it to the game and the rest is done for you!

Nodes

To keep systems and entities decoupled AND to improve performance your systems are given
a node, containing only the components needed for that system to work.

When an entity is added/removed or an entities component is added/removed ash game will update the node list for the systems to process automatically.

Here is an example:

MovementNode:
Location
Speed

Your movement system can now process the MovementNode:

node.Location.x += node.Speed.X * time;


Without ever needing to understand which entities have it.

I am not the biggest fan of creating a class which basically just have public fields however
for this system it is perfectly acceptable, also nodes can be used in multiple systems…

A cool part to using nodes is that Ash connects them into a super fast linked list so when
a system updates them it will have the minimal overhead!

Systems

An entity system can work with lists of nodes and process them in any way you want!

Ash has a bunch of different systems you could use and here are the two I commonly use…

  1. System – The most basic bare bones you can get, create a node list when overriding the addToGame function. I tend to use this when a system works with more than one node type.
  2. ListIteratingSystem – If the systems just loops over a single node type then I use this as
    already set up for such a scenario.

Ash tips and tricks

  1. Keep systems as small and concise as you can, forget about performance implications and focus on making your game work!
  2. Use “Marker” components when you need to differentiate between one entity and another which have the same component types. A marker class is just an empty class, such as “Player” or “Enemy”. I do not like this approach but sometimes you have no choice, most of the time you can find a solution without a marker. Check out Shaun Smith’s post for more information on marker components here.
    Another solution is to work with multiple Ash Games and register different systems, yet it is still a hack around.
  3. Hook onto the Ash Game’s updateComplete event if you want to remove a system or entity, I found it makes life easier and less complicated.

IMPORTANT TIP
Decide early on how to manage events in your systems, using events between components can cause
headaches as it messes up the flow between systems. It would be better to push events to a list
and let the system process them in turn compared to responding immediately but there is a memory cost.

Conclusion

As can be downloaded here

Entity component systems can make your games easier to develop but they can take
a little time to get used to. Do not rush into a project until you have played about with
at least a space invaders clone or risk failing hard!

When you grasp how it all fits into place developing games feel more natural, give ash a try!

Thanks for reading :)

2 comments on “Using an entity component system in AS3

  1. FirsoffMaxim on said:

    HI, thanx for the article.
    Initially difficult to lay the mosaic between: Nodes, Systems, Components.
    Do you have an own example of Ash?

Leave a Reply

Your email address will not be published. Required fields are marked *

*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>