Recently,Martin Devans made a post about Entity Systems. While his post is succinct and descriptive about the various advantages and disadvantages of Component Based Entity Systems, I feel that he portrayed entity system's as an inviolate, "standardized" layout. I'm here today to present an alternative component based system.

In Martin's system, Entities act as containers for components, components represent data, and controllers represent behavior. In my system, things are structured slightly differently. Entities act as a container for 3 types of things: They can have 1 ore more Components, 1 or more Properties, and one or more Events.

Components encapsulate behaviors or "attributes" (I use the term lightly, because attributes has a connotation of data.) of an entity. Including a specific component with an entity changes the way it's treated by the rest of the game. A "CursorComponent" makes the entity follow the cursor around. A "Selectable" component causes the game engine to start looking at that entity when it does selection box queries. Any data they use which might be shared (position, rotation, etc) across multiple components, is stored in properties.

Properties are a type safe container for data. Entity.AddProperty("Position", Vector2.Zero); either adds a vector2 property to the entity named position, or, if the position property already exists, it returns the preexisting one. Thus, If multiple components "Add" a position property, they'll all be looking at the same thing. A change in one will result in everyone else seeing a different value as well.

Events are exactly what they sound like: They allow components, either of that entity or another entity, to register and listen for specific occurences. Most components listen to the "Die" event, removing themselves when the entity dies. The "RenderableComponent", however, listens to the "Die" event and displays a death animation first, and THEN removes itself.

Now, some components implement isolated behaviors. A "Physics" component will update position based on velocity, and velocity based on acceleration. However, some components need broad, all encompassing calculations. Collision detection, for example, needs information about all components at once. This is where "Broadphases" come in. The game implements certain broadphases, which listen for newly created components of certain types. Each of these then gets CPU time, which can perform calculations and updates taking into account all the data at once.

The system provides for extremely flexible, fluid, and responsive entity systems. If anyone wants examples of how a game object would be created (what components it would have, how they would behave, etc) I'll write up some pseudo-code for you. If you need clarifications, feel free to ask as well, either in comments or in email. (Or most likely you'll be Martin, since noone reads this blog yet. =P)