Sinister Soups Serving Musings On Game Development and Play


Objects, Components, and Entities, Oh My!

A new post at last, and it’s that rarest of rare beasts, a programming post!

I’ve been reading and thinking about game system architecture lately. What I mean, specifically, is how objects and actors that take part in a game are represented in code, and what the relationships (in code) between them are like.

The traditional approach follows the Object Oriented programming model of a class hierarchy, where everything is represented by an object containing both data and functions, so that an Orc has both a Size value and an EatPeasant() function bundled up inside it. Furthermore, rather than writing each object from scratch, inheritance is used so that a tree of objects emerges, where specific actors like Orcs inherit much of their data and functionality from object higher up in the tree.

For example, an Orc may inherit its Size from a Monster class, as well as Position, which Monster in turn inherits from MovableObject, which inherits it from GameObject.

This is the naïve OOP approach to managing the actors in a game, and it is almost certainly the wrong approach, at least for a game of any appreciable size or complexity. Don’t get me wrong, it’s an intuitive way to set things up, especially for programmers with experience in other fields, and it can work very well for a small game where the hierarchy can be kept under control and doesn’t grow to massive, unmanageable proportions.

But there are better ways to do things, ways that are much cleaner once you have hundreds of different types of objects in your game, ways that are ultimately just as intuitive once you get used to them.

This is what I’ve been reading about, and pondering, in recent days: component-based architectures and entity systems for representing and managing the actors in your game. While I explain the concepts involved below, if you're really interested in the subject I recommend Mick West's article on the subject, which is very well written and goes into considerable detail.

At its most basic, a component-based architecture eschews a complex object hierarchy in favor of every actor in the game being a collection of components that define what that actor is, and what that actor does. Each actor then, apart from perhaps having some extremely common data such as an identifier, holds a list of components like PhysicsComponent, InputControllable, IsMonster, or whatever else is necessary to define all the operations that the actor can undergo.

These components then hold the relevant data and functions that define the actor, while centralized game systems either iterate over the actors, or even hold their own references to the individual actors’ components, and are able to do whatever updating or rendering the component requires every frame.

The benefits to this kind of setup are many. For one thing, instead of having perhaps hundreds of separate inherited objects, each necessitating its own class with all the upkeep that this entails, actors are simply the sum of their components, and any time a new component is written by a programmer, it can not only very easily be used to create new actors, but can also be trivially added to actors that already exist, giving them new functionality.

This means that with the proper tools, designers can easily redefine behavior on any actor simply by changing what components make up that actor, or tweaking the data that component manages; the only limitation is what components are available. Writing an individual component is also simpler and easier to test than modifying a fully realized, complex, working object that is being passed around throughout the game.

As an example, our Orc from before would be defined by the components that give it a size, and that allow it to eat peasants. If we then decide that Orcs should fly, we can give it a flying component, one which we might already be using for birds, or that we can subsequently use for whatever other actors we think should fly.

It also becomes trivially easy to make other Orc-like monsters, by simply swapping out a couple of components, or simply initializing the new monsters components with different data. For instance, a Goblin monster may be functionally identical to the Orc, but its SpriteComponent loads Goblin.jpg instead of Orc.jpg.

A component system within the confines of an object-oriented language like C++ or C# is all well and good, but what I found particularly interesting while reading on this subject was a method used by Adam Martin, to do away with the pesky and ill-fitting OOP paradigm entirely while designing this sort of component-based architecture.

Essentially, Adam proposes that the actors in a game (which he call entities, a common term that I have not used up until now specifically because he calls his method an Entity System) and their components should be approached using a database model.

Instead of even having an actor class which holds a list of component objects, he advocates divorcing the data and functionality of entities entirely from the traditional OOP model. An entity then becomes nothing more than a unique identifier, a number or a string, and components become packets of data needed by that entity.

Separate systems operate on the data in a component, for instance, a PhysicsSystem might take the data in a PhysicsComponent and use it modify the data in the entity’s PositionComponent, but components themselves merely hold data, not functionality.

The cool thing about this, though it took me a while to make sense of it, is that instead of passing around complex class-based objects in your code, you can simply hold onto an ID for the entity you want, and then essentially perform database-style queries to obtain any data you currently need from the components bound to that ID.

Not only do you get all the benefits of the popular and powerful component architecture, but you also keep your data separate from functionality which comes with a number of benefits; for example, it allows you to perform parallel operations easily on different entities (which are just sets of data) without breaking anything.

I feel like my thoughts about this database-like view of a component system are not yet fully formed, but I definitely feel like there is a powerful elegance to doing things this way. I will need to let the thoughts simmer some more before I have more to say about it, I think.

I recommend checking out Adam’s series of articles on the subject, linked above. It really is quite eye-opening.

Comments (1) Trackbacks (0)
  1. Go digging around in the raw files for dwarf fortress. It seems like more of an entity system is at use there, with each actor type (dwarf, elf, human, magmaman, whatever) having an entry. They then have several flags which dictate common traits. It might be interesting to learn a thing or two from the setup.

    Individual dwarfs at the same time have a name (their identifier), and their own traits which are randomly selected from a set of traits available to their entity, but not necessarily common to all dwarfs. So, you never end up with a dwarf who can fly, but you do end up with a dwarf that likes cows for their haunting moos and hates his neighbor Urist McJackass because he keeps a pet rat.

    The real fun comes from giving the user a way to leverage this system to their advantage, or even actively manipulate it. Again to the dwarf fortress example, you can draft dwarfs into the military who have the appropriate traits (toughness, lack of empathy, strength) to create a military juggernaut that clears the fortress of all threats swiftly. At the same time, it is just as much fun to give the clumsy dwarf with poor eyesight and spatial sense an adamantine battle axe and have him spar with all the dwarfs you deem “unfit” for your fortress. As an added bonus, it gives your surgeons something to do!

Leave a comment

You must be logged in to post a comment.

No trackbacks yet.