• 04/02/13 07:37 PM

    Understanding Component-Entity-Systems

    General and Gameplay Programming

    Klutzershy
    The traditional way to implement game entities was to use object-oriented programming. Each entity was an object, which intuitively allowed for an instantiation system based on classes and enabled entities to extend others through polymorphism. This led to large, rigid class hierarchies. As the number of entities grew, it became increasingly difficult to place a new entity in the hierarchy, especially if the entity needed a lot of different types of functionality. Here, you can see a simple class hierarchy. A static enemy does not fit well into the tree. [attachment=14579:classdiagram.png] To solve this, game programmers started to build entities through composition instead of inheritance. An entity is simply an aggregation (technically a composition) of components. This has some major benefits over the object-oriented architecture described above:
    1. It's easy to add new, complex entities
    2. It's easy to define new entities in data
    3. It's more efficient
    Here's how a few of the entities above would be implemented. Notice that the components are all pure data - no methods. This will be explained in detail below. [attachment=14581:compositiondiagram.png]

    The Component

    A component can be likened to a C struct. It has no methods and is only capable of storing data, not acting upon it. In a typical implementation, each different component type will derive from an abstract [tt]Component[/tt] class, which provides facilities for getting a component's type and containing entity at runtime. Each component describes a certain aspect of an entity and its parameters. By themselves, components are practically meaningless, but when used in conjunction with entities and systems, they become extremely powerful. Empty components are useful for tagging entities.

    Examples

    • Position (x, y)
    • Velocity (x, y)
    • Physics (body)
    • Sprite (images, animations)
    • Health (value)
    • Character (name, level)
    • Player (empty)

    The Entity

    An entity is something that exists in your game world. Again, an entity is little more than a list of components. Because they are so simple, most implementations won't define an entity as a concrete piece of data. Instead, an entity is a unique ID, and all components that make up an entity will be tagged with that ID. The entity is an implicit aggregation of the components tagged with its ID. If you want, you can allow components to be dynamically added to and removed from entities. This allows you to "mutate" entities on the fly. For example, you could have a spell that makes its target freeze. To do this, you could simply remove the [tt]Velocity[/tt] component.

    Examples

    • Rock (Position, Sprite)
    • Crate (Position, Sprite, Health)
    • Sign (Position, Sprite, Text)
    • Ball (Position, Velocity, Physics, Sprite)
    • Enemy (Position, Velocity, Sprite, Character, Input, AI)
    • Player (Position, Velocity, Sprite, Character, Input, Player)

    The System

    Notice that I've neglected to mention any form of game logic. This is the job of the systems. A system operates on related groups of components, i.e. components that belong to the same entity. For example, the character movement system might operate on a [tt]Position[/tt], a [tt]Velocity[/tt], a [tt]Collider[/tt], and an [tt]Input[/tt]. Each system will be updated once per frame in a logical order. To make a character jump, first the [tt]keyJump[/tt] field of the Input data is checked. If it is true, the system will look through the contacts contained in the [tt]Collider[/tt] data and check if there is one with the ground. If so, it will set the [tt]Velocity[/tt]'s [tt]y[/tt] field to make the character jump. Because a system only operates on components if the whole group is present, components implicitly define the behaviour an entity will have. For example, an entity with a [tt]Position[/tt] component but not a [tt]Velocity[/tt] component will be static. Since the [tt]Movement[/tt] system uses a [tt]Position[/tt] and a [tt]Velocity[/tt], it won't operate on the [tt]Position[/tt] contained within that entity. Adding a [tt]Velocity[/tt] component will make the [tt]Movement[/tt] system work on that entity, thus making the entity dynamic and affected by gravity. This behaviour can be exploited with "tag components" (explained above) to reuse components in different contexts. For example, the [tt]Input[/tt] component defines generic flags for jumping, moving, and shooting. Adding an empty [tt]Player[/tt] component will tag the entity for the [tt]PlayerControl[/tt] system so that the [tt]Input[/tt] data will be populated based on controller inputs.

    Examples

    • Movement (Position, Velocity) - Adds velocity to position
    • Gravity (Velocity) - Accelerates velocity due to gravity
    • Render (Position, Sprite) - Draws sprites
    • PlayerControl (Input, Player) - Sets the player-controlled entity's input according to a controller
    • BotControl (Input, AI) - Sets a bot-controlled entity's input according to an AI agent

    Conclusion

    To wrap up, OOP-based entity hierarchies need to be left behind in favour of Component-Entity-Systems. Entities are your game objects, which are implicitly defined by a collection of components. These components are pure data and are operated on in functional groups by the systems. I hope I've managed to help you to understand how Component-Entity-Systems work, and to convince you that they are better than traditional OOP. If you have any questions about the article, I'd appreciate a comment or message. A follow-up article has been posted, which provides a sample C implementation and solves some design problems. Implementing Component-Entity-Systems

    [i]Article Update Log[/i]

    [b]1 April 2013 - Initial submission[/b] [b]2 April 2013 - Initial publication; cleaned up formatting[/b] [b]29 September 2013 - Added notice of follow-up article; changed some formatting[/b])


      Report Article


    User Feedback




    Oh, I love the diagrams, it is even clearer and faster to understand that the introduction written by Richard Lord (Ash Framework). Good job yay !

    Share this comment


    Link to comment
    Share on other sites

    I agree, this is a nice intro. Are you planning to follow this up with an article on systems and design challenges? This could easily be made into a small series, especially with how often the topic comes up. (Well, maybe not often relative to "Which language?")

    Share this comment


    Link to comment
    Share on other sites

    Great article. What did you use to create the diagrams?

     

    I used PlantUML, a text-based UML graphing tool.

     

     

    I agree, this is a nice intro. Are you planning to follow this up with an article on systems and design challenges? This could easily be made into a small series, especially with how often the topic comes up. (Well, maybe not often relative to "Which language?")

     

    I think so, yes.  There's a lot more to CES than just the theory.

    Share this comment


    Link to comment
    Share on other sites

    I like how you presented this thing. Many forum posts I've read on component system tend to be extremely elaborated and fail to point out what really counts. It appears to me you have been very good at condensing the core notions.

     

    Not related to your article but to Component Systems in general, how would you deal with gameplay specific behaviours?

     

    Here's an example for the purpose of discussion. 

    • A simulated entity A={collision brush, mass, graphical model, movement} hits an object 'B'. In this case there's "typical" response, we have no problem.
    • Same as before but A has now got a power-up which allows it to ignore collisions with objects of type B. Or perhaps even worse, the specific object B.

    I'm currently using overriden functions for that, it feels a bit too inheritance-based but I don't see how to improve that. I was thinking about some "filter" components but the concept seems to be quite vague. What do you think? Does it even qualifies for being called component-based?

    Share this comment


    Link to comment
    Share on other sites

    Not related to your article but to Component Systems in general, how would you deal with gameplay specific behaviours?

     

    In at least your specific case, I would maybe have a filter component.  Your physics system (or possibly a separate system) can be in charge of registering these "collision groups" with your physics engine.

     

    Lots of gameplay features can be implemented with dynamic components.

    Share this comment


    Link to comment
    Share on other sites

    I do like this article, but I think it's worth pointing out that not every component-based system has to treat components as structs of data with no behaviour, moving all the behaviour into systems. Some component-based systems will encapsulate the behaviour into the component, such as with Unity's system for example. The benefit of this is that it's easier to mix and match components as they are usually self-contained. The downside is that when components do rely on each other, these dependencies are not always obvious.

    Share this comment


    Link to comment
    Share on other sites

    I do like this article, but I think it's worth pointing out that not every component-based system has to treat components as structs of data with no behaviour, moving all the behaviour into systems. Some component-based systems will encapsulate the behaviour into the component, such as with Unity's system for example. The benefit of this is that it's easier to mix and match components as they are usually self-contained. The downside is that when components do rely on each other, these dependencies are not always obvious.

    I've found, after many years of working with such a component system, that very few components tend to be entirely self-contained. It's very difficult to orthogonalize a lot of behavior in such a way that it can operate in isolation from other behavior, however the goal of a component system is to compartmentalize as much as possible. As a result, the more you try to split apart components the more they need to communicate to function, and the more you merge them together the less they are truly individual "components", rather than globs of somewhat-related data and functionality. I suppose you could say that separating the data and the behavior eases this pressure a bit, and makes it easier to split apart the data while also establishing clear dependencies between it and the behavior.

    Share this comment


    Link to comment
    Share on other sites

    This article is pretty good at clearly explaining many things. If I have game Entities derive from an interface as they have in common a group of Components and a Name ID, should I also derive my Systems from a common interface?

    Share this comment


    Link to comment
    Share on other sites

    This article is pretty good at clearly explaining many things. If I have game Entities derive from an interface as they have in common a group of Components and a Name ID, should I also derive my Systems from a common interface?

     

    First of all, game entities shouldn't be deriving from an interface.  Specialization is done through adding components.  Systems should be derived from an interface to handle automatic component registering.

    Share this comment


    Link to comment
    Share on other sites

    How would systems operate on a collection of components? And what would be a good way to store components? As I undersand from the article components derive from an interface and are stored under entities. This leads to me something like :

     

     

     

    class IComponent{};
    
    class Position : public IComponent
    {
    public:
    float x,y;
    };
    
    class Velocity: public IComponent
    {
    public:
    float x,y;
    };
    
    class Entity
    {
    public:
    std::vector<IComponent*> components;
    };
     

     

     

    Afterwards a Physics system operates on the components of entities to add velocity to the position of these entities but how does that system work and decide if a component is a specific type(dynamic casts?virtual functions in the IComponent?). Would it be better to store components like so :

     

     

     

    class Entity
    {
    public:
    std::map<std::string,IComponent*> components;
    };
     

    So you can give names to components and access them with those names.

     

    I think it could be nice to have a pt2 which goes a bit into implementation details.

    Share this comment


    Link to comment
    Share on other sites

    I think it could be nice to have a pt2 which goes a bit into implementation details.

     

    I'm currently working on my own implementation myself.  When I figure out the best way to do it, I'll follow up with an article on that.

    Share this comment


    Link to comment
    Share on other sites

    I guess your implementation collides a bit with the one I followed in this article, which is why I gave Entities a common interface. But I see your point in why you may not do that, because then it leads back into an inheritance pattern of making all sorts of Entity classes.

     

    Then if you want to really know that a given Entity could be a Monster, other than peeking inside its components, is to give it a generic name as a string. Maybe that's the job of an entity management system, it would see what components are stored in it and then determine, "this is a Monster". And similarly, if any components are replaced/removed, the system would check again.

    Share this comment


    Link to comment
    Share on other sites

    The key thing to understand is that there is no notion of a "Monster".  An entity can behave like a Monster if it has the correct components, but beyond loading in the data and spawning the entity the systems don't care.

    Share this comment


    Link to comment
    Share on other sites

    I guess your implementation collides a bit with the one I followed in this article, which is why I gave Entities a common interface. But I see your point in why you may not do that, because then it leads back into an inheritance pattern of making all sorts of Entity classes.

     

    Then if you want to really know that a given Entity could be a Monster, other than peeking inside its components, is to give it a generic name as a string. Maybe that's the job of an entity management system, it would see what components are stored in it and then determine, "this is a Monster". And similarly, if any components are replaced/removed, the system would check again.

     

    If I understand correctly, if you wanted the entity to be a "Monster", then you'd give that Entity a "Monster" component. That way, the Entity is only defined by the components given. If the last boss is a zombie pirate with hovers. The Entity (I think) would look like: Entity (boss, zombie, pirate, hover). 

     

    Anyone, please feel free to correct any of my misunderstandings.

    Share this comment


    Link to comment
    Share on other sites

    very helpful article , the usage of diagrams make it sample to understand (I found english not easy to understand and words relatide to game developpment make it harder ) If you can make other articles with diagrams for level conception I will be very grateful,
     

    Share this comment


    Link to comment
    Share on other sites

    Very helpful article for someone relatively new to this stuff, like me. I've been trying to do an implementation of this in C++, and while I can understand the concept I've been having a fair bit of trouble. One thing that's really been bugging me keeping track of an entity's components. How would you recommend storing an entity's components, and then how would you suggest accessing them from a system?

    Share this comment


    Link to comment
    Share on other sites

    Then if you want to really know that a given Entity could be a Monster, other than peeking inside its components, is to give it a generic name as a string. Maybe that's the job of an entity management system, it would see what components are stored in it and then determine, "this is a Monster". And similarly, if any components are replaced/removed, the system would check again.

     

    There shouldn't ever be any reason to know whether an entity is a monster. If you have code that does "if this is a monster, then....", that means you're doing it wrong.

     

    Of course, for debugging purposes it can be useful to identify the object somehow. The code that created the entity and its components can tag it with some string identifier in that case (or if you're using some sort of prefab system, then the name of the prefab).

    Share this comment


    Link to comment
    Share on other sites

    How would you go about implementing a "kill all monsters" type of spell? Would you tag the entity with a monster component? Or, what is the right (/better) way to do such a thing in a component based approach?

     

    <snip>

     

    There shouldn't ever be any reason to know whether an entity is a monster. If you have code that does "if this is a monster, then....", that means you're doing it wrong.

    Share this comment


    Link to comment
    Share on other sites



    Create an account or sign in to comment

    You need to be a member in order to leave a comment

    Create an account

    Sign up for a new account in our community. It's easy!

    Register a new account

    Sign in

    Already have an account? Sign in here.

    Sign In Now