Refactoring Game Entities with Components
Up until fairly recent years, game programmers have consistently used a deep class hierarchy to represent game entities. The tide is beginning to shift from this use of deep hierarchies to a variety of methods that compose a game entity object as an aggregation of components. This article explains what this means, and explores some of the benefits and practical considerations of such an approach. I will describe my personal experience in implementing this system on a large code base, including how to sell the idea to other programmers and management.
GAME ENTITIES
Different games have different requirements as to what is needed in a game entity, but in most games the concept of a game entity is quite similar. A game entity is some object that exists in the game world, usually the object is visible to the player, and usually it can move around.
Some example entities:
- Missile
- Car
- Tank
- Grenade
- Gun
- Hero
- Pedestrian
- Alien
- Jetpack
- Med-kit
- Rock
Entities can usually do various things. Here are some of the things you might want the entities to do
- Run a script
- Move
- React as a rigid body
- Emit Particles
- Play located audio
- Be packed up by the player
- Be worn by the player
- Explode
- React to magnets
- Be targeted by the player
- Follow a path
- Animate
TRADITIONAL DEEP HIERARCHIES
The traditional way of representing a set of game entities like this is to perform an object-oriented decomposition of the set of entities we want to represent. This usually starts out with good intentions, but is frequently modified as the game development progresses – particularly if a game engine is re-used for a different game. We usually end up with something like figure 1, but with a far greater number of nodes in the class hierarchy.
As development progresses, we usually need to add various points of functionality to the entities. The objects must either encapsulate the functionality themselves, or be derived from an object that includes that functionality. Often, the functionality is added to the class hierarchy at some level near the root, such as the CEntity class. This has the benefit of the functionality being available to all derived classes, but has the downside of the associated overhead also being carried by those classes.
Even fairly simple objects such as rocks or grenades can end up with a large amount of additional functionality (and associated member variables, and possibly unnecessary execution of member functions). Often, the traditional game object hierarchy ends up creating the type of object known as “the blob” . The blob is a classic “anti-pattern” which manifests as a huge single class (or a specific branch of a class hierarchy) with a large amount of complex interwoven functionality.
While the blob anti-pattern often shows up near the root of the object hierarchy, it will also show up in leaf nodes. The most likely candidate for this is the class representing the player character. Since the game is usually programmed around a single character, then the object representing that character often has a very large amount of functionality. Frequently this is implemented as a large number of member functions in a class such as CPlayer.
The result of implementing functionality near the root of the hierarchy is an overburdening of the leaf objects with unneeded functionality. However, the opposite method of implementing the functionality in the leaf nodes can also have unfortunate consequence. Functionality now becomes compartmentalized, so that only the objects specifically programmed for that particular functionality can use it. Programmers often duplicate code to mirror functionality already implemented in a different object. Eventually messy re-factoring is required by re-structuring the class hierarchy to move and combine functionality.
Take for example the functionality of having an object react under physics as a rigid body. Not every object needs to be able to do this. As you can see in figure 1, we just have the CRock and the CGrenade classes derived from CRigid. What happens when we want to apply this functionality to the vehicles? You have to move the CRigid class further up the hierarchy, making it more and more like the root-heavy blob pattern we saw before, with all the functionality bunched in a narrow chain of classes from which most other entity classes are derived.
AN AGGREGATION OF COMPONENTS
The component approach, which is gaining more acceptance in current game development, is one of separating the functionality into individual components that are mostly independent of one another. The traditional object hierarchy is dispensed with, and an object is now created as an aggregation (a collection) of independent components.
Each object now only has the functionality that it needs. Any distinct new functionality is implemented by adding a component.
A system of forming an object from aggregating components can be implemented in one of three ways, which may be viewed as separate stages in moving from a blob object hierarchy to a composite object.
OBJECT AS ORGANIZED BLOB
A common way of re-factoring a blob object is to break out the functionality of that object into sub-objects, which are then referenced by the first object. Eventually the parent blob object can mostly be replaced by a series of pointers to other objects, and the blob object’s member functions become interface functions for the functions of those sub-objects.
This may actually be a reasonable solution if the amount of functionality in your game objects is reasonably small, or if time is limited. You can implement arbitrary object aggregation simply by allowing some of the sub-objects to be absent (by having a NULL pointer to them). Assuming there are not too many sub-objects, then this still allows you the advantage of having lightweight pseudo-composite objects without having to implement a framework for managing the components of that object.
The downside is that this is still essentially a blob. All the functionality is still encapsulated within one large object. It is unlikely you will fully factor the blob into purely sub-objects, so you will still be left with some significant overhead, which will weight down your lightweight objects. You still have the overhead of constantly checking all the NULL pointers to see if they need updating.
OBJECT AS COMPONENT CONTAINER
The next stage is to factor out each of the components (the “sub-objects” in the previous example) into objects that share a common base class, so we can store a list of components inside of an object.
This is an intermediate solution, as we still have the root “object” that represents the game entity. However, it may be a reasonable solution, or indeed the only practical solution, if a large part of the code base requires this notion of a game object as a concrete object.
Your game object then becomes an interface object that acts as a bridge between the legacy code in your game, and the new system of composite objects. As time permits, you will eventually remove the notion of game entity as being a monolithic object, and instead address the object more and more directly via its components. Eventually you may be able to transition to a pure aggregation.
OBJECT AS A PURE AGGREGATION
In this final arrangement, an object is simply the sum of its parts. Figure 2 shows a scheme where each game entity is comprised of a collection of components. There is no “game entity object” as such. Each column in the diagram represents a list of identical components, each row can be though of as representing an objects. The components themselves can be treated as being independent of the objects they make up.
PRACTICAL EXPERIENCE
I first implemented a system of object composition from components when working at Neversoft, on the Tony Hawk series of games. Our game object system had developed over the course of three successive games until we had a game object hierarchy that resembled the blob anti-pattern I described earlier. It suffered from all the same problems: the objects tended to be heavyweight. Objects had unnecessary data and functionality. Sometimes the unnecessary functionality slowed down the game. Functionality was sometimes duplicated in different branches of the tree.
I had heard about this new-fangled “component based objects” system on the sweng-gamedev mailing list, and decided it sounded like a very good idea. I set to re-organizing the code-base and two years later, it was done.
Why so long? Well, firstly we were churning out Tony Hawk games at the rate of one per year, so there was little time between games to devote to re-factoring. Secondly, I miscalculated the scale of the problem. A three-year old code-base contains a lot of code. A lot of that code became somewhat inflexible over the years. Since the code relied on the game objects being game objects, and very particular game objects at that, it proved to be a lot of work to make everything work as components.
EXPECT RESISTANCE
The first problem I encountered was in trying to explain the system to other programmers. If you are not particularly familiar with the idea of object composition and aggregation, then it can strike you as pointless, needlessly complex, and unnecessary extra work. Programmers who have worked with the traditional system of object hierarchies for many years become very used to working that way. They even become very good at working that way, and manage to work around the problems as they arise.
Selling the idea to management is also a difficult. You need to be able to explain in plain words exactly how this is going to help get the game done faster. Something along the lines of:
“Whenever we add new stuff to the game now, it takes a long time to do, and there are lots of bugs. If we do this new component object thing, it will let us add new stuff a lot quicker, and have fewer bugs.”
My approach was to introduce it in a stealth manner. I first discussed the idea with a couple of programmers individually, and eventually convinced them it was a good idea. I then implemented the basic framework for generic components, and implemented one small aspect of game object functionality as a component.
I then presented this to the rest of the programmers. There was some confusion and resistance, but since it was implemented and working there was not much argument.
SLOW PROGRESS
Once the framework was established, the conversion from static hierarchy to object composition happened slowly. It is thankless work, since you spend hours and days re-factoring code into something that seems functionally no different to the code it replaces. In addition, we were doing this while still implementing new features for the next iteration of the game.
At an early point, we hit the problem of re-factoring our largest class, the skater class. Since it contained a vast amount of functionality, it was almost impossible to re-factor a piece at a time. In addition, it could not really be re-factored until the other object systems in the game conformed to the component way of doing things. These in turn could not be cleanly refactored as components unless the skater was also a component.
The solution here was to create a “blob component.” This was a single huge component, which encapsulated much of the functionality of the skater class. A few other blob components were required in other places, and we eventually shoehorned the entire object system into a collection of components. Once this was in place, the blob components could gradually be refactored into more atomic components.
RESULTS
The first results of this re-factoring were barely tangible. But over time the code became cleaner and easier to maintain as functionality was encapsulated in discreet components. Programmers began to create new types of object in less time simply by combining a few components and adding a new one.
We created a system of data-driven object creation, so that entirely new types of object could be created by the designers. This proved invaluable in the speedy creation and configuration of new types of objects.
Eventually the programmers came (at different rates) to embrace the component system, and became very adept at adding new functionality via components. The common interface and the strict encapsulation led to a reduction in bugs, and code that that was easier to read, maintain and re-use.
IMPLEMENTATION DETAILS
Giving each component a common interface means deriving from a base class with virtual functions. This introduces some additional overhead. Do not let this turn you against the idea, as the additional overhead is small, compared to the savings due to simplification of objects.
Since each component has a common interface, it is very easy to add additional debug member functions to each component. That made it a relatively simple matter to add an object inspector that could dump the contents of the components of a composite object in a human readable manner. Later this would evolve into a sophisticated remote debugging tool that was always up to date with all possible types of game object. This is something that would have been very tiresome to implement and maintain with the traditional hierarchy.
Ideally, components should not know about each other. However, in a practical world, there are always going to be dependencies between specific components. Performance issues also dictate that components should be able to quickly access other components. Initially we had all component references going through the component manager, however when this started using up over 5% of our CPU time, we allowed the components to store pointers to one another, and call member functions in other components directly.
The order of composition of the components in an object can be important. In our initial system, we stored the components as a list inside a container object. Each component had an update function, which was called as we iterated over the list of components for each object.
Since the object creation was data driven, it could create problems if the list of components is in an unexpected order. If one object updates physics before animation, and the other updates animation before physics, then they might get out of sync with each other. Dependencies such as this need to be identified, and then enforced in code.
CONCLUSIONS
Moving from blob style object hierarchies to composite objects made from a collection of components was one of the best decisions I made. The initial results were disappointing as it took a long time to re-factor existing code. However, the end results were well worth it, with lightweight, flexible, robust and re-usable code.
Resources
Scott Bilas: GDC 2002 Presentation: A Data-Driven Game Object System
http://scottbilas.com/files/2002/gdc_san_jose/game_objects_slides.pdf
Bjarne Rene: Component Based Object Management. Game Programming Gems 5, 2005, page 25.
Kyle Wilson: Game Object Structure: Inheritence vs Aggregation, 2002, http://gamearchitect.net/Articles/GameObjects1.html
[…] Evolve Your Hierarchy : Refactoring Game Entities With Components 2. Game Programming Gems 6 , Section 4.6 : Game Object Component System 3. A Data-Driven Game […]
Pingback by Component Based Entity System Design Part 1 | Purple Pwny Games — April 24, 2009 @ 7:10 pm
[…] 1. https://cowboyprogramming.com/2007/01/05/evolve-your-heirachy/ […]
Pingback by Entity Systems « chrislunsford.com — June 7, 2009 @ 10:48 am
I’m trying to understand the semantics behind the different components. Say that you had implemented a new extendable entity system, the most beutiful you could imagine.
1. How would you have divided the responsibilities between the different components?
2. What guidelines/rules would you instruct to new programmers so that the system could be kept as clean as possible when it’s added with many new components?
Thanks
Comment by Bjrn — June 20, 2009 @ 9:19 am
Beware of striving for beauty over pragmatism.
Your questions are a little broad, and really the only answer I can give us “it depends”. What is your actual goal here? Where are you now, and where are you going?
Comment by Mick West — June 20, 2009 @ 10:03 am
My goal is a simple 2d prototype (platforms, player, some enemies, some gui), an environment to learn thinking about entities as components.
But what is a component, really? (i.e. “separtion of concerns”)
Is is a pure data structure without functions, which is operated on by subsystems, or is the componentes themself the subsystems.
I do realize that there is multiple ways to approach the problem, my objective is finding the right metaphor to work under so it is consistent.
… I’m looking for a definition, which explains the perspective/angle/paradigm/mindset/mental model in how to think about the components, the rules of conduct and semantics in naming them.
Comment by Bjrn — June 20, 2009 @ 10:53 am
A component is still just an object containing data, with methods that act on that data. It’s just more atomic, and the components are used in aggregate to create entities (which would normally be complex objects)
I’d recommend you look at done of the implementations discussed in the comments.
Comment by Mick West — June 20, 2009 @ 12:54 pm
Hi Mick,
I’d be interested to hear what you think of Adam Martin’s (incomplete!) series of articles which describes a different kind of entity system. http://t-machine.org/index.php/2007/09/03/entity-systems-are-the-future-of-mmog-development-part-1/
This concept does not consider an entity or a component to be an instance of a class but, rather, pure data similar to a database table. It also relies heavily on a FlyWeight implementation (at least, that’s what I think).
I’ve used your concept of component systems (OOP components) in several projects, but Adam’s way of looking at it has really intrigued me. It would be great to hear your thoughts on analysis and comparison of the two, etc.
Comment by jason — July 25, 2009 @ 1:25 pm
My article is a fairly simple description, and leaves open a lot of the implementation issues.
You can abstract things a lot, but there can be performance issues. What Adam seems to be describing is the “Object as Pure Aggregation” method, which is shown in the the diagram above. The method of aggregating (saying which components belong to which entities – or more abstractly how entity-like output arises from discreet components) is an implementation issue. Adam suggests using a Database – but I’m not sure if he’s actually done this.
Comment by Mick West — July 25, 2009 @ 1:59 pm
Great write-up, super useful for communicating similar ideas to other people on the team. Thanks!
errata: “This may actually be a reasonably solution” -> “This may actually be a reasonable solution”
Comment by andrei pokrovsky — September 10, 2009 @ 1:22 pm
Thanks Andrei, I fixed the typo.
Comment by Mick West — September 10, 2009 @ 1:36 pm
Great article Mick.
While reading your article though, a question kept popping up in my head which I don’t seem to be able to shake off.
Take a light or a camera for instance. Beyond the very essence of their nature, i.e. as objects that illuminate or capture the scene, either of them may have or have not a Position, Render, Physics or Script component and so on, so they clearly must have their place in such a system, either as entities or as components, so my question is how do you go about incorporating these objects into such a system? Are lights and cameras components too? So a scriptable camera consists of two components, the CameraComponent and the ScriptComponent? What about a particle emitter? Or a physical joint?
Generally speaking, what’s the rule of thumb for recognizing components?
Thanks in advance.
Comment by Ash — September 28, 2009 @ 4:15 pm
Ash, that sounds about right. A fairly simple thing such as a camera could be a single component, but would likely be at least a CameraComponent that specifies the view vector and FOV, and some ScriptComponent or AttachComponent that governs how it moves.
When creating components, or functionality for an existing component, consider if it can be split into sub components that might be useful in another composite object. All the things you mention could be components.
Comment by Mick West — September 28, 2009 @ 4:25 pm
I’m a fan of this appraoch. I despise it when I look at someone elses code and I have to work my way up six or seven inheirtance levels just to find the meat and potatoes of some procedure. There’s nothing more confusing about joining a project than learning what class in the heirarchy does exactly what, especially when they’re horribly mislabelled classes which are doing things the name suggests they shouldn’t be doing and no one’s bothered to update it.
I’ve tried my hand at this design before and the real difficulty I’ve always run into is enforcing a particular order that components should be in the container class. The method I’ve employed before is to have each component maintain it’s own list of dependencies which are checked when the component is added to an object or component collection. The problem inherent with this is that it’s very easy to create cyclic dependencies, especially later on in the project when you have potentially thousands of components.
There’s no easy solution, but the traditional approach simply doesn’t cut the mustard these days in my opinion, and something new like the composite design is definitely an improvement.
Comment by Marc — October 5, 2009 @ 11:09 am
Truly fascinating!!!
Comment by Zach — November 12, 2009 @ 8:04 pm
[…] more capable of handling new things. For instance, enemies are now based on components as per an article on Cowboy Programming, making it super easy to create new enemy behaviors (and combinations of existing behaviors). It […]
Pingback by Drilian’s House of Game Development » Blog Archive » Update For The Past N Months — January 5, 2010 @ 8:15 pm
Incredible! Do you have an example running? because i have several problems trying it.
thanks
jhon
Comment by John Jones — January 16, 2010 @ 5:24 am
[…] https://cowboyprogramming.com/2007/01/05/evolve-your-heirachy/ […]
Pingback by Un Nouveau Moteur | Kromatyk — January 16, 2010 @ 12:01 pm
[…] Engine: Case Study: The Age Of Mythology Doug Church – Object Systems Mick West – Refactoring Game Entities with Components Kyle Wilson has a blog with a bunch of strong posts about engine design. Be sure to check out the […]
Pingback by Game Engine Design / iPhone Game Engine Resources | Kleinsch — January 18, 2010 @ 5:55 pm
[…] the ground will have a render part and a physics part. My system is similar to the one mentioned in this article. Components should be highly reusable. For example, I might write an AI part, let’s say for […]
Pingback by Nightshade Engine — May 11, 2010 @ 7:49 am
[…] would have pretty much all part types except AI. My system is similar to the one mentioned in this article. Components should be highly reusable. For example, I might write an AI part, let’s say for […]
Pingback by Nightshade Engine — June 19, 2010 @ 8:44 am
[…] Evolve Your Hierarchy ( 2007 ) By Mick West https://cowboyprogramming.com/2007/01/05/evolve-your-heirachy/ […]
Pingback by [ç¿»è¯] Evolve Your Hierarchy « Black Straits Historical — August 31, 2010 @ 7:10 am
[…] on structuring your game code. The first was the Guerilla Guide to Game Code, and the second was Evolve Your Hierarchy, by Mick […]
Pingback by Zerg: my new game architecture-entity-system-thingy « My .plan — September 11, 2010 @ 1:06 pm
[…] Evolve Your Hierarchy, one of the classic texts on the subject by Mick West […]
Pingback by State of the Art Game Objects | GBGames - Thoughts on Indie Game Development — November 11, 2010 @ 4:53 pm
[…] Inspired by this article, I got thinking about the overall effectiveness of my programming methods. […]
Pingback by component-vs-hierarchical-modeling | Code, Hacks and Other Nerdy Things — December 29, 2010 @ 1:02 am
[…] on January 10, 2011 by Rohin Knight I recently learnt about component based game engines at https://cowboyprogramming.com/2007/01/05/evolve-your-heirachy/. But I was unsure how I should implement […]
Pingback by Component Based game development | Rohin's Development Blog — January 9, 2011 @ 11:14 pm
[…] architecture, and get a very flexible code. To learn more about this model, I invite you to read Evolve Your Hierarchy by Mick […]
Pingback by Creating An Eternal Animation With Crafty.js | Programmateur — January 10, 2011 @ 5:03 pm
[…] many have proposed a component based system. Before continuing, I recommend reading Evolve Your Hierarchy, a good introduction to the […]
Pingback by Complex Functionality Using Component Systems « GameDevSoc — January 20, 2011 @ 8:34 am
You mention using a factory method to create entities. I’ve gotten used to inheritance and I like each entity having it’s own class. However, I want to switch to components.
Should I use a single factory class with different methods for each entity, or should I use separate classes for each entity, and use the class constructor to create the entity?
Comment by Trent Sterling — February 18, 2011 @ 5:23 am
A factory will encapsulate better, avoiding duplication.
Comment by Mick — February 18, 2011 @ 8:24 am
[…] Evolve Your Hierarchy […]
Pingback by Refactoring Fun « Hydroxic-Acid — February 27, 2011 @ 7:56 pm
[…] many have proposed a component based system. Before continuing, I recommend reading Evolve Your Hierarchy, a good introduction to the […]
Pingback by Complex Functionality Using Component Systems — March 10, 2011 @ 9:43 am
[…] This link gives a great introduction to an entity component system. […]
Pingback by Clojure Entity Component System | resatori — March 16, 2011 @ 9:40 am
[…] got an article from a friend that will help with solidifying my engine architecture.  I have a programming […]
Pingback by The best laid plans… | SLEEPY-GENIUS: tHE gAME dESIGN mUSINGS oF mARCUS mONTGOMERY — March 18, 2011 @ 1:27 am
[…] https://cowboyprogramming.com/2007/01/05/evolve-your-heirachy/ […]
Pingback by Entity frameworks | Gray Lantern — April 1, 2011 @ 8:17 pm
[…] Share this on:Facebook Twitter Delicious Digg Google Reddit Stumbleupon Email ← Indexes.js – When you need to find certain […]
Pingback by Component-based game design | Javascript Team — June 5, 2011 @ 7:02 am
[…] Mick West’s blog post on the component system at Neversoft in the Tony Hawks games is an excellent introduction to entities and components. It’s where I first found out about components. […]
Pingback by Game Objects and Entities » John Payne's Code Blog — June 17, 2011 @ 8:37 am
[…] Note: If you don’t have at least a vague concept of component-entity design, read this article first. […]
Pingback by As promised: Component Binding BEHIND THE SCENES « et1337 makes games — June 27, 2011 @ 5:16 pm
[…] Cowboy Programming discusses these benefits in illustrated detail while Lambdor discusses some problems he found. […]
Pingback by Component system | BoxHacker — July 1, 2011 @ 6:04 pm
[…] I used as reference: https://cowboyprogramming.com/2007/01/05/evolve-your-heirachy/ http://gameprogrammingpatterns.com/component.html […]
Pingback by » Onedayitwillmake — July 5, 2011 @ 7:23 pm
[…] Evolve Your Hierarchy (Cowboy Programming) – A detailed review of components vs OO hierarchies. […]
Pingback by Entity/Component Game Design: A Primer — July 10, 2011 @ 11:44 am
[…] mess. I fell into the classic deep hierarchy problem and, after some research, I began working on a component-based entity system. In the near future I will be posting a series of coding posts about the […]
Pingback by Introducing ‘Xanor’ (WIP) - pekalicious — July 17, 2011 @ 2:18 pm
[…] hierarchical classes with inheritance. Â It has been used for some years in the game industry (Here one of the most cited article on the subject on CowboyProgramming blog) , but it has recently become a big trend over amateur/indie game development. Even so, it”™s hard […]
Pingback by Component-based architecture « Burger Engine Blog — July 18, 2011 @ 2:02 pm
[…] Evolve Your Hierarchy (Cowboy Programming) ”“ A detailed review of components vs OO hierarchies. […]
Pingback by Developers Diary – Developing Methodology | Ploobs — August 11, 2011 @ 5:58 am
[…] Dokuro2 is a game engine that I am writing in SFML to allow me to create games in it more easily. It is has a component based entity design, which I think has many advantages over the usual inheritance based entity design. I read this article and it converted me https://cowboyprogramming.com/2007/01/05/evolve-your-heirachy/ =) […]
Pingback by 2D Game Engine – Dokuro2 « Bombpersons's Blog — September 23, 2011 @ 8:53 am
[…] for avoidÂing using deep inherÂitÂance hierÂachÂies when clasÂsiÂfyÂing game objects123, and IÂ won”™t reitÂerÂate that arguÂment here. SufÂfice it to say, using only […]
Pingback by Component-Based? Entity-Component? Confused? Part 1 | chris mann — September 28, 2011 @ 6:49 am
[…] a great differentiator from other engines. Instead of long chains of inheritance it's built on a "Entity Component System" where sprites (called Entities) are manipulated by adding reusable Components to […]
Pingback by Engines — October 15, 2011 @ 1:44 pm
[…] min) Read up on component based (as opposed to hierarchy based) engine design (1, 2, 3, […]
Pingback by Daily Update #2 | Game Development Blog — November 2, 2011 @ 8:23 pm
[…] Evolve your hierarchy – Cowboy Programming – https://cowboyprogramming.com/2007/01/05/evolve-your-heirachy/ […]
Pingback by Scripting with Artemis Entity System Framework « Gemserk — November 13, 2011 @ 7:11 am
[…] leer más sobre este sistema en la siguiente página: Refactoring Game Entities with Components. Donde se explica más en detalle como funciona este sistema. También en la siguiente […]
Pingback by Crafty, Game engine para el desarrollo de videojuegos para navegador - Chalchicha.es — November 16, 2011 @ 2:42 am
[…] Components for game entities […]
Pingback by Amit’s Game Programming Information[ref] « Morgen Free's Blog — December 12, 2011 @ 12:49 am