To understand this post, it may be necessary to read about the differences between stacked and flat software hierarchies. Yes, its a long piece of required reading, but its worth it. I’ll wait for you here.
Still here? In this post, I am not going to talk about what stacked or flat hierarchies are. I’m not going to talk about their advantages or disadvantages. Instead, I will talk about a little software architecture I learned about from the game development community known as Entity Systems. I will also show a simple sample implementation of such an entity system – a flat hierarchy. My implementation will be crude and simple and not really a good representative of flat hierarchies, component systems or entity systems, but I’m hoping that it will be enough to give you a practical taster of how one can make use of these concepts. My hope is that others will expand on these ideas to build some useful software tools for the programmer community to make use of. So, put simply, please don’t complain that this implementation is inefficient and useless, instead use the concepts to build an efficient and useful variant. In a future post, I may develop such a system, but for now, a simple proof-of-concept implementation is more suitable, as it allows us to talk and reason about the concepts. Anyway, here goes…
My definitions and terminology may be slightly different from those used in the game development communities and if anyone spots such discrepancies, please point them out so that I can fix it. The concepts are simple enough – instead of of having our software composed as objects in the object oriented manner, we have entities. This is more than just a simple name change, however, as an Entity is really just a name or a tag. It does not contain data, it does not contain actions. Its just a named placeholder so that our system knows that it exists and can find it. An entity may be tagged with zero or more traits. A trait provides two things to an entity: a system and a state. The system is a function of code which continuously processes all entities with its particular trait. For example, a Renderable trait may exist, which tells the software that an entity can be rendered on the screen, that traits system will continuosly process all Renderable entities and render them to the screen. By tagging an entity as Renderable, it instantly becomes seen and processed by the system and if the tag is removed, it will no longer be processed by that system. A trait will also give an entity a state, which is the collection of all data required for that traits system to process it. In the case of a Renderable trait, the state could contain important data such as the representation (image data, polygons, etc) and position on screen.
Time for a quick recap. Our entity based software will consist of the following components:
- Entity – an identifier which may have zero or more traits attached to it.
- Trait – a behaviour or characteristic applied to an entity.
- System – a processing system which updates or otherwise processes the states for a given trait.
- State – the data asscociated with a trait.
In the next post (or perhaps I’ll edit this one instead), I’ll introduce a simple prototype implementation of these ideas, so that people can play around with it and see what they can do. This should help spark new ideas. Hopefully in the future, I will then implement a proper and efficient version which can be used to build real softweare, though for now a prototype should be good enough.
