chrislunsford.com

I can’t remember what first got me interested in entity systems.  I do know that I was immediately intrigued; entity systems seemed like a new, intuitive way of developing code for games.  And i’m a sucker for paradigm shifts; it doesn’t matter what the old paradigm was…a new one always seems better to me.  However, my enthusiasm over entity systems was curbed by the lack of information (particularly concerning implementation) available online.  There are a few articles and forum threads that discuss the topic.  Any inquiry into entity systems for game development seems to ultimately lead back to them.  I will continue this trend by linking to them here.  For background, read (and re-read, and re-read…) these articles:

1. http://cowboyprogramming.com/2007/01/05/evolve-your-heirachy/

2. http://www.gamearchitect.net/Articles/GameObjects1.html

3. http://www.drizzle.com/~scottb/gdc/game-objects.htm (Scott Bilas has a lot of good info for this sort of development: http://www.drizzle.com/~scottb/ )

4. http://t-machine.org/index.php/2007/09/03/entity-systems-are-the-future-of-mmog-development-part-1/ (4-part series on MMO game development with entity systems)

5. http://www.gamedev.net/community/forums/topic.asp?topic_id=463508

After reading through these pages (multiple times over the period of a few months), I think that I started to grasp the concept.  Part of the difficulty is the fact that I’m not experienced with C/C++, which is where most code for game development lives (and therefore, all examples of entity system implementations, as well).  I’m mostly a web developer; and although I do speak some OO, I had a hard time understanding a lot of the back-and-forth on the subject.   And most of this back-and-forth related to the method of implementing entity systems.  There seems to be some disagreement about the proper approach.  And although I cannot say authoritatively that one way is better than another, I do believe that many of the implementations are missing the point.

To summarize my understanding of an entity system:

1. An entity is an identifier used to associate components of a single game object.

2. A component is a grouping of data that all relate to a specific facet of a particular game object (position, combat, etc.)

For both of these pieces, there are no functions and no classes…it’s all data.  This data resides in some data structure: a hash map, an array, a relational database…whatever.  Since I come from a web development background, I quickly latched onto the idea of using a relational database.

At this point, I pause to make a few notes.  First, so far, none of the information I’ve presented is my own.  I’m merely summing up what I’ve found in the linked articles, especially Adam’s series of posts at t-machine.org.  The rest of the article follows logically from what’s already out there, but I don’t believe that it’s been spelled out anywhere, yet, so I’ll call it my own.  Second, the reason that there is so much discussion about the implementation is that a well-formed entity system may very well not be capable of supporting a large mmo-type game.   There are multiple reasons, many of them outlined in the articles above.  So, what I describe here is my understanding of a ‘proper’ entity system.  Whether or not this implementation is the proper one for a production environment is yet to be known (by me, at least).  The real optimum likely lies somewhere between pure inheritance and pure aggregation…but we should at least be fair to pure aggregation (or, at least, my version of pure aggregation) and describe it accurately.

Back to relational databases.  With this method, I think the implementation becomes readily apparent:  an entity is a primary key, and a component is a row in a table.  The entity serves no purpose other than to uniquely identify a set of data.  And a component is just one instance of some pre-determined schema.  The real magic happens elsewhere, in the sub-systems.

A sub-system, then, is a group of functions responsible for one aspect of a game engine.  Every tick, the sub-system is tapped by the game loop; wakes up and updates all components under its control and goes back to sleep.  For example, there is likely to be a position sub-system…responsible for player location and movement.  When PositionSubSystem.Update() is called, the position system fetches all rows in the `Position` table, iterates through them and applies the velocity in each row to the position in each row.  The positions are now updated and sent to the proper clients to be drawn.  The position sub-system goes back to sleep, only to wake up and do the same thing next tick.  With this method, the sub-system doesn’t need to keep lists of registered components, it simply operates on all instances of the component.  If an object does not have a position to be updated, then it won’t have the Position component, and there won’t be any data for it in the `Position` table.  This example may not be perfect, because there are lots of game objects that do have a position but will never move, like a tree, for instance.  No problem, really; two quick solutions come to mind (other than the obviously simple…just apply a zero velocity every tick and they won’t move).  The first is to design components (and, as a result, the database schema) so that position and velocity are independent components. So instead of just `Position` we have `Movable` too.  The second solution is to use a simple where clause in the original query to only return objects with non-zero velocities…saving us some processing time looping through rows of trees for no reason.

The first alternative above opens up the need to mix components to perform game operations.  Even if we didn’t do it with position, it would be necessary for just about everything else.  Combat relies upon position. Combat even relies upon combat; you must have the information for both the attacker and the defender.  These situations are solved by using primary and foreign keys to link data together.  So when the Attack subsystem wakes up and pulls the rows for every entity currently attacking, the query will return the attack table joined with the position table.  The attacker will have a key designating who the defender is, allowing for the system to pull the relevant information from the database to carry out the battle.  At least…I think that should work.  Determining whether or not it’s fast enough, robust enough, or flexible enough will require writing some code and testing it.