The entity component model is all the rave for the last decade. But if you look at the design it opens more issues than it solves.
Broadly speaking the entity component model can be summarized as the following: An entity is composed of components who each serve a unique purpose. The entity does not contain any logic of its own but is empowered by said components.
But what does the entity component model try to solve?
Each and every illustration of the entity component model starts with a classic object oriented conundrum: a deep inheritance hierarchy with orthogonal proposes. For example you have a
Goblin class. You form two specialisations of the
Goblin class, the
FylingGoblin who can fly and the
MagicGoblin who uses magic spells. The problem is that it is hard to create the
FylingMagicGoblin.
Even with C++ and its multiple inheritance, you are not in the clear as you still have the
dreaded diamond and virtual inheritance to solve. But most languages simply do not support a concise way to implement it.
When solving the issue with components, the components
GroundMovement,
FlyingMovment,
MeleeAttack and
MagicAttack are created and the different types of goblins are composed from these.
Good job, now we went from one anti-pattern (deep inheritance hierarchy) to a different anti-pattern (wide inheritance hierarchy). The central issue is that the inheritance hierarchy tries to incorporate orthogonal concepts and that is never a good idea. Why not have two object hierarchies, one for attack modes and one for movement modes?
As you can see from an object oriented standpoint the entity component model fares quite poorly. But that is not the only problem the entity component model tries to solve.
In many cases you see the concept of a data driven engine. The idea is that you can cut down on development time by moving the object composition out of the code and into some form of data. This allows game designers to "build" new objects by writing some XML or using a
fancy editor. Although the underlying motivation is valid, it does not need to use an entity component model, as a few
counter examples show quite well.
Putting the structural criticism aside, a naive implementation of the entity component model can in no way be efficient. In most cases the components are not such high concepts as moving or attacking, they are more along the lines of rendering and collision detection. But unless you have additional management structures, you need to look at each and every entity and check if it has components that are relevant for the rendering process.
The simplest way to resolve the issue, without altering the design too radically, is the introduction of systems. In this case the actual implementation is within the systems and the components are just indicating the desired behaviour. The result is that a system has all the relevant data in a very concise and compact format and as a result can operate quite efficiently.
But if you look closely you can see that we have all these useless components. What if you removed the components and just used properties on the components and the systems just look for appropriately named properties? Now you have duck typing.
Duck typing is a concept that is used a lot in weakly typed languages, like for example JavaScript or Python. The main idea here is that the actual type is irrelevant, but specific properties and function are expected on a given object within a specific context. For example it is irrelevant if it is a file stream, a memory stream or a network socket - if it has the
write function it can be used to serialize objects to.
The problem with duck typing is that is does not lend itself easily to native languages. You can cook up some solution using some varying type but in no way is this an elegant solution.
Chances are you already have a scripting system, in this case the solution is quite straight forward, you implement the core game logic in scripts and underlying systems look at this definition and implement any heavy lifting in native code. The idea of
alternating hard and soft layers is
nothing new and should be considered where flexibility and performance is needed.
You may think that implementing the game logic in scripts is an inefficient way to do it. In cases where you are building a simulation-oriented game this may be quite true. In these cases is makes sense to extract your logic and reduce it to its core concepts, a simulaiton if you will. Then implement the presentation layer and control layers externally directly against the simulation layer.
The nice thing about this design is that you can split the presentation layer and simulation so far that you can put one of them on one computer and the other on a different one.
Wait, did you just describe MVC? Um... No... Stop changing the subject.
When looking into scalability you get interesting requirements.
One very clever implementation of the entity component system was make it scale in an MMO setting. The idea here is that entities and components do not exist in code, but are entries in a database. The systems are distributed over multiple computers and each work at their own pace and read and write to the dabase as required.
This design addresses the need of a distributed system and reminds me of the
High Level Architecture][10] used by NASA and NATO to hook up multiple real-time simulations together. Yes this design approach even has its own standard, the IEEE 1516.
Ok, oh wise one, what should we do?
If you read about these issues you are either building a game engine or a game. Each and every game has different requirements and game engines try to satisfy a subset of these different requirements. Remember what you are developing and the scope of your requirements. If your current design sucks, you do not need to go overboard with your design, because chances are you aren't gonna need it. Try to make the smallest step that will solve the problem you are facing. It pays out to be creative and look at what others have done.
).
Interesting article. I am working with entity component model lately and so far I am more satisfied with it than with OO. It needs a lot of mental adjustments to understand how to design the game differently.
Anyway, I want to point out one thing. When you remove components from the flow and store all data in the entities, you are losing some important features - shared and/or reusable data.
Components as the smallest data unit can be easily shared among other entities. That means you save some memory and also some processing time, because changing component in one entity makes that change applied to all other entities that contain this component. That can be very useful in some scenarios.
For example you want your weapons to have all the same base stats. You can create one component with that and assign the reference to all weapons created. Later you may decide that all these weapons need little tweak on one stat, so you just change it in that one component and it's all good. If you need one weapon to be special and stand out, you give it just its own component with own stats.
Other feature I have mentioned is reusable data. This can be handy for example for positioning. Instead of having like 10 components with the same X,Y,Z just because there is more items on that very spot, you can simply share one component among them. Other use is for pooling where entity gets removed, but some frequently used components can be stored in stack and reused for new entity. Garbage collector will be more happy this way, less mess to clean up and smaller overhead in creating those objects all over again.