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

  1. 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.
  2. 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

  1. Data – Components
  2. 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:
 

12 Responses to Entity Systems

  1. Don Pipo says:

    Very interesting. I tried exactly the same in the last days and came up with a solution which was a mix between “Common” and “True”. But I stumbled over a lot of problems, especially with communication between components/systems.

    I like your idea how you handle entities (like you explained in the comments here: http://www.tomseysdavies.com/2011/02/03/getting-started-with-ember/). But I never used dependency junction or something like SwiftSuspenders.
    Nevertheless your framework seems to be much more advanced than my solution. I would really like to see a more complex demo for Ember.

    I will follow this blog :)

  2. admin says:

    Its through my own attempts and a lot of reading that I ended up here. I’m slowly working on a simple 2d engine if anyone else wants to get involved.

  3. Ben Garney says:

    Actually, you’ll find that PBE follows the second layout, not the first. Propagating updates down through the entity layer is prone to problems both in performance and function.

  4. admin says:

    These examples are deliberately simplified to keep this post to reasonable length. PBE is rather more complicated than any of these systems and has concepts such as properties which kind of blur the lines. The key thing I focus on is the separation of data and logic and while this is probably possible in PBE, in the examples I have seen this isn’t the case e.g here

  5. Troy Gilbert says:

    Your quote about games being real-time databases with pretty front-ends struck a chord — as in, I remembered reading it before (and taking it to heart!). I did a bit of Googling and finally found it: Game Architecture and Design, an excellent book which I read years ago. Thanks for reminding me of it, and thanks for this article!

  6. admin says:

    Ah that’s where I got it from! Struck a cord with me though at the time I had no idea how to implement it.

  7. Eric Smith says:

    I took an entity-component approach on the first version of my engine, but ended up with a much simpler approach the second time. I just thought I’d share my views on what I learned:

    One of the problems with entity/component is that it tends to mask the functionality of the entity in another layer, making some code seem “magical”, and making debugging more difficult. Since components are meant to be re-used, the developer tends to attempt to use them, but spends just as much time trying to learn the component as they would have if they made the logic themselves. But even then, they don’t understand what they did quite as well.

    Another problem is the component developer’s desire to create a “re-usable” component often gets in the way of what could have been a very simple game object. Game objects often have very specialized functionality, and since Flash is a very simple language, it’s often just as easy to code out the specifically-needed logic for each entity, even if it means a bit of redundant code. After all, this is ActionScript, not a complex and dangerous language like C++. Since ActionScript is still very “scripty”, I’ve found components to be more confusing than just building the game object in plain, simple script. It reduces the layers between the logic and the developer, making the dev feel like they understand what’s happening, and thus empowering them.

  8. admin says:

    I deliberately use the term “entity systems” to differentiate the approach I advocate from your standard “entity-component “ approach. This is because using the ½ way route brings with it lots of issues and my guess is this is the route you took?
    Game objects often share a lot of common functionality coding each one by hand means lots of duplicate code which makes bug fixing difficult. In simple games (most flash games are) especially in a limited field platform/physics games for example then hard coding game objects will work but it is fundamentally inflexible and doesn’t scale. Id look to games like Battlefield 3 and ask why they use the entity systems approach as remember they also have access to scripting languages (and use them). In fact Unity is a great example of how we should be making games in flash.

    Here is a list of things a few things that an entity system can make much easier for you

    A generic save (one bit of code for all your games)
    In game editors (pause edit and save you levels, create and modify entities as you play)
    Client server architecture (Multi-player games)
    Database driven games (Massively multi-player games)

  9. [...] : Gamasutra the Entity Component Model, Entity Systems are the future of MMOG development, Entity Systems. This links are very interesting, but there isn’t any implementation. You can find [...]

  10. [...] : Gamasutra the Entity Component Model, Entity Systems are the future of MMOG development, Entity Systems. Then Richard Lord has made a very good blog post with code example using his own framework : Ash. [...]

  11. [...] more about it in an upcoming post sometime later. If you are curious, read more here: T=Machine and Tom Davies. These two posts are the main reason why I started building my own entity system in [...]

  12. marco says:

    “Slow(er) looking up the entities we need for each system every frame is going to effect performance.”

    This isn’t intrinsically true. A system can store references to all relevant components. It doesn’t need to know the entity ID at all since components are independently functional objects. An entity-ID getter within a component superclass also doesn’t violate the ES paradigm if you really need it.

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>