“Favour composition over inheritance”
If you haven’t already read my previous post on the problems of traditional game architecture and why entity systems are needed. I’m going to cover the basics of an entity system before we look at 3 different implantations and the pro’s and con’s of each.
What is an entity?
An entity (sometimes called game object) represents something in the game. For every tree,tank or ninja we have an entity. An entity is container to which we can add components (behaviours) that define what it is. e.g In this rather conceptual example a Ninja gets a Renderer, Physics, Health and Stealth components which together make up a Ninja.
This is the basics of all Entity systems one of key feature is the ability to create entities and change there components at run time. So a Ninja could become a Tank! (that’s the hard sell done).
Spotter guide.
There are 3 main ways to implement an entity system I have seen and I’m going to quickly out line them all and take a critical look at the pro’s and con’s. I’m going to call them common, almost and true (yes I’m bias but I think they are appropriate names)
“Common”
Most common implantation you are going to come across. Its based on the strategy pattern and its the simplest to understand. The first time I built a entity system this is what I did. There are good example out there in flash like PushButton Engine.
How it works
All components have a common interface normal with a function update(). Calling update() on entity causes update() to be called on all its components. Components then update there data for example a render component may copy its graphics to a view port.
Pros
Simple and fast. Better than inheritance.
Cons
Scalability and flexibility (how easy it is to make changes). To explain the issue lets take an example. We have an entity with both renderer and physics components. Both need to know about the location of the entity in the world. So we have two options
- push the data up into the entity its self. In complex games this can result inmore and more specialised data gets pushed up into the entity creating a god object.
- Allow components to access other components data. When one component depends on the data in another component we get a dependency. Component A can’t function unless component B exists. As a game grows so does the complexity of the dependencies.
There are work arounds to this issue for example automatically creating component B when A is added but then we need to give it the correct data. We start to lose the ability to mix and match components on the fly that makes an entity system so powerful. Entity to entity communication for example in collision detection is also difficult.
“Almost”
This was suggest to me by a friend I’m including it here as its hard to criticise and has a lot of positives points.
How it works
This gets the big leap correct it separates the data from the logic. In the common implementation both data and logic are combined in a component here they separated into
- Data – Components
- Logic – Systems(behaviours)
This is counter intuitive and contrary to what’s drilled into you about OOP. However it solves lots of issues.
A renderer system could require a spacial component (position in the world .etc) and a graphics component where as a physics system may require just the spacial component. Think of the components as the model and systems as the controller in MVC terms. Systems normally implement a common interface with a update() function
Pros
More scalable the systems have no dependencies on one another and can share data. Fast.
Cons
Systems are still dependent on an entity having specific components. This can be worked around to an extent by implementing it so that when we and a system to an entity any missing components are created automatically. This however means that we have to add a system before we can start setting the components data as they may not exist before that point. The main issue with this system come with entity to entity communication for example in collision detection. A collision system attached to an entity needs to check its self against all the others entities with collision systems this can be done with events but it also can be a lot simpler as we will see next.
“True”
“A game is just a real time database with a graphical front end”
- Dave Roderick
This is a blanket statment but its fundamentally true and this architecture is the closest fit to this statement I have found.
How it works
Again we separate out the logic and the data. However rather than adding systems to the individual entities we add the systems to the game its self. The systems can the do a real time look up and requests all entities that have the required components for processing. For instance a rendering system will ask every frame for all entities that have Spacial and Graphical components it will then run though the list drawing each one.
Pros
Scalable and easy to make change due to low dependences. Truly data driven. Simple. Collisions etc. are much easier to manage.
Cons
Slow(er) looking up the entities we need for each system every frame is going to effect performance. Counter-intuitive and requires you to rethink your approach to programming.
Conclusion
All these systems are better that a traditional inheritance hierarchy. I chose the “true” system for my frame work Ember as I think its pros out way its cons when it comes to the real issues of game development. It can also be implemented so that performance issues can become negligible. you can read how to get started using Ember here.
If you want to read more on entity systems its covered in some depth here by t-machine blogs.
Also check out Richard Lords post with a practical example here
http://www.richardlord.net/blog/what-is-an-entity-framework
Tagged with: architecture • components • entities • flash • game