Why use an entity system framework for game development?

Following my previous post on entity systems for game development I received a number of good questions from developers. I answered many of them in the comments on that post, but one question stands out. It’s all very well explaining what an entity system framework is, and even building one, but why would you want to use one? In particular, why use the later component/system architecture I described and that I implement in Ash rather than the earlier object-oriented entity architecture as used, for example, in PushButton Engine.

So, in this post I will look more at what the final architecture is, what it gives us that other architectures don’t, and why I personally prefer this architecture.

The core of the architecture

First, it’s worth noting that the core of this architecture is the components and the systems. Components are value-objects that contain the state of the game, and systems are the logic that operates on that state, changing it as the game progresses. The other elements of the architecture are purely incidental, designed to make life easier.

The entity object is present to collect related components together. The relation between components is encapsulated by the concept of an entity and that is vital to the architecture, but it isn’t necessary to use an explicit Entity object for this. There are some frameworks that simply use an id to represent the entity, adding the entity id to every component to indicate which entity it belongs to. In this scenario there is no requirement for an entity object at all and entity based operations are performed through an entity manager, using the id to indicate which entity they are operating on.

As a concept, the entity is vital to the architecture. But as a code construct it is entirely optional. I include it because, when using an object-oriented language, the entity object makes life easier. In particular, it enables us to create the methods that operate on the entity as methods of an entity object and to track and manage the entity through this object, removing the need to track ids throughout the code.

While the concept of an entity is vital to the architecture, the concept of node objects is entirely incidental. The nodes are used as the objects in the collections of components supplied to the systems. We could instead provide each system with a collection of the relevant entities and let the systems pull the components they want to operate on out of the entities, using the get() method of the entity.

In Ash, the nodes serve two purposes. First they enable us to use a more efficient data structure in which the node objects that the systems receive are nodes in a linked list. This improves the execution speed of the framework.

Second, using the node objects enables us to apply strong, static typing throughout our code. The method to fetch a component from an entity necessarily returns an untyped object, which must then be cast to the correct component type for use in the game code. The properties on the node are already statically typed to the components’ data types, so no casting is necessary.

So, fundamentally, the entity architecture is about components and systems.

This is not object-oriented programming

We can build our entity architecture using an object-oriented language but, on a fundamental level, this is not object-oriented programming. The architecture is not about objects, it’s about data (components) and sub-routines that operate on that data (systems).

For many object-oriented programmers this is the hardest part of working with an entity system framework. Our tendency is to fall back to what we know and as an object-oriented programmer using an object-oriented language that means encapsulating data and operations together into objects. If you do this with a framework like Ash you will fail.

Data-Oriented Programming

Games tend to be about lots of fast changing state, with players, non-player characters, game objects like bullets and lasers, bats and balls, tables and chairs, and levels, scores, lives and more all having state that might include position, rotation, speed, acceleration, weight, colour, intention, goals, desires, friendships, enemies and more.

The state of the game can be encapsulated in this large mass of constantly changing data, and on a technical level the game is entirely about what this data is and how this data changes.

In a game a single little piece of this data may have many operations acting on it. Take, for example, a player character that has a position property that represents the character’s position in the game world. This single piece of data may be used by

  • The render system, to draw the player in the world.
  • The camera system, to position the camera relative to the player.
  • The AI systems of all non-player characters, to decide how they should react to the player.
  • The input system, which alters the player’s position based on user input.
  • The physics system, which alters the player’s position based on the physics of the game world.
  • The collision system, which tests whether the player is colliding with other objects and resolves those collisions.

and probably many more systems besides. If we try to build our game using objects that encapsulate data with the operations that act on that data, then we will build dependencies between all these different systems as they all want to be encapsulated with the player’s position data. This can’t be done unless we code the game as one single, massive class, so inevitably we break some parts of the game into separate systems and provide data to those systems – the physics system, the graphics system – while including other elements of the game logic within the entity objects themselves.

An entity architecture based on components and systems takes the idea of discrete systems to its logical conclusion. All operations are programmed as independent systems, and all game state is stored separately in a set of data components, which are provided to the systems according to their need.

The systems are decoupled form each other. Each system knows only about itself and the data it operates on. It knows and cares nothing at all about the other systems and how they may have affected by or used the data before or after this system gets to work with it.

Also, by embracing the system as the core logic of the architecture, we are encouraged to make many smaller and simpler systems rather than a few large complex ones, which again leads to simpler code and looser coupling.

This decoupling makes building your game much easier. It is why I enjoy working with this form of entity system so much, and why I built Ash.

Storing the game state

Another benefit of the component/system architecture is apparent when you want to save and restore the game state. Because the game state is contained entirely in the components, and because these are simple value objects, saving the game state is a relatively simple matter of serialising out the components, and restoring the game state involves just deserialising the data back in again.

In most cases, serialising a value-object is straightforward, and one could simply json-encode each component, with additional data to indicate its entity owner (an id) and its component type (a string), to save the game state.

Adam Martin wrote about comparing components in an entity system framework to data in a relational database (there’s lots of interesting entity related stuff on Adam’s blog), and emphasising that conversion between a relational database for long-term storage and components for game play doesn’t require any object/relational mapping, because components are simple copies of the relational database’s data structure rather than complex objects.

This leads further to the conclusion that a component/system architecture is ideal for an MMO game, since state will be stored in a relational database on the game servers, and much of the processing of that state will occur on the servers, where using a set of discrete, independent systems to process the data as the game unfolds is an excellent fit to both the data storage requirements of the state and the parallelism available on the servers.

Concurrency

Indeed, a component/system architecture is well suited to applying concurrency to a game. In most games, some of the systems are entirely independent of each other, including being independent of the order in which they are applied. This makes it easy to run these systems in parallel.

Further, most systems consist of a loop in which all nodes are processed sequentially. In many cases, the loop can be parallelised since the nodes can be updated independently of each other.

This gives us two places in the code where concurrency can be applied without altering the core logic of the game, which is inside the loop in the systems, or the core state of the game, which is in the components.

This makes adding concurrency to the game relatively simple.

We don’t need object-orientation

Finally, because the component/system architecture is not object-oriented, it lends itself to other programming languages that implement different programming paradigms like functional programming and procedural programming. While I created Ash as an Actionscript framework, this architecture would be well suited to Javascript for client side development or any of the many functional languages used for highly concurrent server side development.

Update: In-game editors

Tom Davies has pointed out that a very valuable benefit to him is how easy it is to create an in-game level editor when developing with an entity system framework like Ember or Ash. You can see his example here.

I agree with Tom, this is a very useful benefit of these frameworks. The complete separation of the game state and the game logic in an entity system framework makes it easy to create an editor that lets you alter the state (configuration, level design, AI, etc.) while playing the game. Add to this the easier saving and loading of state and you have a framework that is very well suited to in-game editing.

60 thoughts on “Why use an entity system framework for game development?

  1. @jeremy

    nodes : NodeList is a list of node objects. Each node contains a reference to an entity and a static typed reference to the components of that entity that are required by the node. This helps with performance since components can be accessed directly from the node rather than being accessed as dynamic objects via the entity.

    Further, the nodelist only contains nodes for those entities that have all the components required by the node class.

  2. @Eugene

    After a year with it, I would use this architecture for all my games. It probably sounds too good to be true, but I really don’t have any problems with it (at least, none that I remember right now).

  3. @Richard It’s awesome. I’m now going to create js game based on entity system. And planning to use port to js ash.js.

    So i have one more question: How did you usually implement AI for game? Which more suitable for Ash?

  4. Hello Richard. Thank you for those wonderful articles. I had found about entity framework just yesterday as I am trying to develop small game which should be rather scalable and modular. Ash seems like really brilliant solution for that.

    After reading this article I have a question. Is there some general solution for data conflicts ? Like when two or more systems are trying to modify same data property ?

    For example Input system changes position based on input from player. Collision system decided player cannot go there and wants to revert that position. Than Physics system kicks in and does something else with player position.

    I can imagine that Input system could just trigger event which Collision system handles and alters position accordingly, but what about Physics system ? Would that be reacting on same event or simply wait for event from Collision system ? Finally there is Rendering system which should render only final state. It would make ugly glitches if Rendering would work with position that is not fully updated just yet.

    I am very far from skilled game developer, so there are probably hundreds solution for such situation, but I am more interested in some general idea about handling conflicts between systems.

    Thanks for a reply and have a nice day !

  5. Hi Daniel

    If you’re using a physics system, then you won’t want to change the position based on the input, you’ll want to change the velocity and then let the physics system move the object based on that velocity, which solves the problem you mention.

    I’ve never actually had a conflict like the one you describe, so I can’t comment on how I would solve them. I suspect they may result from errors in the underlying model of the game.

  6. Hello Richard, in your architecture, a component is assigned to an entity but can we have a component shared between many entities ?

    Like a HealthComponent which is shared between Enemy1 and Enemy2 entities because Enemy1 and Enemy2 are parts of a big enemy and shares their healths.

    Do you think that the concept of sharing component between entities is correct or it adds too much complexity in the entity system ?

    And if we want to use Box2D with entity system, by example if we want to manage joints, a joint is a link between two bodies, there are many sorts of joints and a body can be attached by multiple joints, how achieve this in entity system ?

    It’s a question that I asked in gamedev stackexchange website but no answer : http://gamedev.stackexchange.com/questions/58210/box2d-joints-in-entity-components-system

    Thank you

  7. Hi Johnmph

    I see no problem with sharing a component between two entities, in fact I do that in some of my games. It’s a very efficient way to share state between two entities.

    As for the Box2d question, I don’t know enough about Box2d or your specific scenario to offer a solution, sorry.

  8. Thank you very much, I have a last question :

    In fact, the solution I found for Box2D implies to have a component which have a reference to an another entity which contains some component.

    But the problem is : What happens if the entity referenced (or its component) is removed ?

    I can add code to keep coherency but is it correct or having these links between component are a result of a bad component conception ?

    Thank you

  9. Pingback: Parsec Patrol Diaries: Entity Component Systems – blog.lmorchard.com

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>