Back to the Entity Model of Game Design (first post here), this time lets take a simple game we all know and love and try and identify at some crude high level some entities and how they can be modelled.

LEGAL DISCLAIMER : I’m using Ms Pac-men as an example, but in no way implies I have any rights to use it etc. Namco are the owners etc. Just using it as its a reference point for the discussion…

Ms Pac-men – We all know and love it, and its running on my 360 in the background as I type this (I also worked on an update of Ms Pac-man once). Its simple enough that we can think about it in a entity centric model without getting bogged down with a complex game design (its worth noting, that it was probably never modelled like this, it pre dates it by decades and its really overkill for a game like this).

Ms Pac-man has a number of elements that are easy to identity. I’m not going to define all the rules here, just an example of a few tiny bits of the entity model.

• Ms Pac-man : Player controlled
• Blinky : Red Ghost
• Pinky : Pink Ghost
• Inky : Blue Ghost
• Sue : Orange Ghost
• Pills : Ms-Pac-man eats them
• Power-Pills : Allow Ms Pac-man to eat Blinky, Pink, Inky or Sue
• Cherry : A fruit bonus that Ms Pac-man eats
• Strawberry : A fruit bonus that Ms Pac-man eats
• More fruit : A fruit bonus that Ms Pac-man eats (there are about half a dozen so i won’t list them)
• Walls : Nothing can go thro
• Hud : Keeps Score and Life count

For brevity I’ve not listed all the fruit or the cut scene characters.

Now it would be possible to create the game with just this. Each unique thing is an entity and you then proceed to describe each rule and how they relate to each with no sharing, but this is just silly. The concept of Ghosts and Fruit clearly share a great deal of commonality.

So it makes sense to introduce this to our model. Keeping things simple we define at this stage an idea of Entity Type.

Entity Type – Entity are concrete instances with unique parameters (and possibly rules) of an entity type. Most implementation details are defined at the Entity Type level allowing sharing of rules and message handling.

So lets define a few Entity Types

• Player – Is user controlled avatar
• Ghost - AI controlled creature
• Edible - Player consumes edible things

Now take some of our Entities from before and distribute them

• Player – Ms Pac-man
• Ghost – Blinky, Pinky, Inky, Sue
• Edible – Pills, Power-Pill, Cherry, Strawberry, More Fruit

Better… because we can now writes rules for how the Player interacts with Ghosts but still not good enough. We would like to group all the fruit together so a Entity Type that derives off another would be good addition, but a more thorny issue is the one of edible ghosts… When you eat a Power-Pill ghosts become edible for a short time (at least on most levels), how does this fit in?

There are two possibilities; one using the component model is that Edible is a component and can be changed at real time. The other using the hierarchy model is that Edible has a state (CanBeEaten) that is set when something is actually edible. I’ll come back to state (its a big topic that we will need to explore when we write rules but for now i want to keep focusing on entities them self).

Both method fundamentally work the same way (somewhere something stores whether something is currently edible or not) but the component model is more intuitive here.

Inky is a Ghost is an Edible is how we would write the hierarchical relationship, but for a lot of the game it isn’t actually edible? This seems to break our intuitive definition of “is a“. The hierarchy model implies a strong relationship that isn’t true here.

The component model has a relationship seems a better fit, especially if you can change components based on the current game state. Inky is a Ghost has an Edible Component isn’t very good English but still scans better than is a when the relation is actually is not. (some of you may be already thinking what we want is is sometimes… for another time )

However the relationship Inky is a Ghost seems a better fit than Inky has a Ghost.

And you’ve guessed it, it demonstrates that a hybrid component and hierarchical model probably works best for even the simplest games. And using this form of simple word association makes deciding whether something makes sense as a component or a hierarchy fairly easy.

If we to allow an Entity Type to have Entity Components itself which are the inherited by the actual Entities this would simplify things even more.

So lets use this information to define our Entities and Entity Types and Entity Component.

Entity Components

• Edible - Player consumable things

Entity Types

• Player – Is user controlled avatar
• Ghost has a Edible Component - AI controlled creature
• Fruit has a Edible Component – A bonus score item

Entities

• Ms Pac-man is a Player
• Blinky is a Ghost
• Pinky is a Ghost
• Inky is a Ghost
• Sue is a Ghost
• Pills has an Edible Component
• Power-Pills has an Edible Component
• Cherry is a Fruit
• Strawberry is a Fruit
• More fruit is a Fruit

Now clearly this is far from being finished and its defiantly not the only (or even best) model you could use but already we started to break down the game into more manageable chunks. We can now define rules that work on Fruit and only have (for example) the graphics and bonus score changed per entity. Adding a new type of fruit would also be easy. We can define how Power-Pills affect the Player and Ghosts without having to code it for each of Blinky, Inky, Pinky and Sue separately.

What we don’t have is any way of defining how things change over time (State) or how the rules and message will actually work. There also a big gaping hole where walls and Hud should be (Intentionally left for the moment). More to come another day…

Hope thats given some thoughts… I’m well aware that a blog mind dump probably isn’t the best medium for this kind of article. I’ll probably go back over at some point and tidy up into proper article pages but something is better than nothing Feel free to ask question or tear it to pieces

Tuesday, March 27th, 2007 @ 11:35 pm Computer Games, Development
RSS 2.0 Trackback