The Entity Model Of Game Design

The entity model of game design is so ubiquitous, that you have probably never heard of it mainly due to it being the model used by everyone.

I have a hankering to write a proper lengthy article on it, but I’ll start with a little blog post first. Simple put the entity model proposes that virtually all games and there designs can be modelled by ‘entities’ and the interactions between them.

So what is an Entity?

Simply put an entity is a thing that exists in the game world (most implementation give them spatial data but this isn’t required), that can send and receive messages from other entites and other game systems.

Bit of a cop out of a definition really… and thats largely due to it being a ‘catch all’ model. And if you think its sounds a lot like object-oriented programming, you’d be right. The both came from attempts to simulate the real world.

Virtually everything is an entity… the players avatar, the enemies, AI path-nodes, the ground you stand on etc. Each one has a set of properties and rules that define how it relates to other entities.


An entity communicates to another entity via messages. These are very game specific but things like “Hit a Wall” to “Do random damage to your left arm” ensure that rules of the game are carried out.

Generally many of the messages will be hard coded into the game and most entity level editors won’t let you manipulate them but from a game theoretic point of view, they are still message sends and receives and most rules will be how an entity responds to them.

Making Entities

The base game engine will encode some primitive level of functionality on an entity. For example the player entity probably has collision data that means it stands on other entities. The entities that you can stand on will be defined as having to property of “being the ground”. Because of this, entity tend to be grouped into similar functionality.

All the entities that have physics might be one group, but obviously things like AI Path-nodes wouldn’t be a member of that group. How this grouping is done, usually comes down to one of two models, a purely hierarchical model or a component model.

Hierarchical Model: Ground is a Static Collidable Object is a Physics Object is an Renderable Entity

Component Model: Ground has a Static Collidable Component and a Renderable Entity Component

The component model while more flexible is more complex. You can quickly end up with components that aren’t really re-usable groupings and are really just a part of the specialised entity definition. The hierarchical model suffers from the opposite, if you want Wet Ground you have to derive off Ground and so would Deformable Ground, so how do you get Wet Deformable Ground?

Another major source of gnashing of teeth (and differences between games) is how the rules that make up the entity are defined. The old school method is that they a defined purely in the base language that everything is programmed in (C/C++ for most games or C# for XNA), a more common approach now is partly base language plus a scripting language (Lua or some custom language are common). Another approach is to define only the engine being written in the base language and all entity rules defined in the script language.

Script languages are (in theory) easier to work with by less skilled programmers (say designers with a more artistic background) and are more domain specific so even skilled programmers can achieve more game features in less time (trading execution speed for development time). Both are true… and also lies.

Many script environments are badly thought out (if its not domain specific enough, you probably should have used the base language) and often lack basic programmer assists (debuggers, type safety, decent IDEs).

I’m a firm believer in the hybrid approach… Try and enable both base language and script and then choose the most appropriate as seen fit. Of course that requires a certain level of ‘programming’ skill in itself but then I’m in the school of thought that programming and game design are similar skills (can break problems in to chunks, think through the corner cases, visualise complex things in your head) so that’s fine by me (and while it doesn’t mean all designers or programmers are good at the other job, it does mean there is a subset who are… but thats another blog post to discuss).

And then finally you need some way of putting entities down and changing properties and connecting the messages, generally some kind of level editor.

Hmmm enough for now… Its a huge topic (possibly a books worth…) but one I rarely see discussed and give it how the entire game hangs together, thats slightly odd. I’ll be back for some more soon…