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).
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.
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.
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.
High level overview of Ash
Ash is divided into four main aspects:
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.
Ash Game has an update function that will update all of your systems in priority order
in a time dependent fashion.
If you are using the Flash Event Manager to update your game, such as using an ENTER_FRAME event
you could run…
…but this if you use time dependency’s in your game, if you are not accounting for elapsed time
just pass in 1.
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!
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:
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!
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…
- 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.
- 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
- Keep systems as small and concise as you can, forget about performance implications and focus on making your game work!
- 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.
- 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.
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.
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