https://cowboyprogramming.com/2007/01/05/evolve-your-heirachy/ Cowboy Programming Game Development and General Hacking by the Old West * [ ] [Search] * Recent Posts + 1995 Programming on the Sega Saturn + Customizing Home Page Bookmarks on iPhone and iPad + AURemoteIOServer Error getting default device UID: '!obj' + iPhone OpenAL Linking Problem + Some Uses of SQL Databases in Game Development + Custom responsiveness measuring device + My coding practices in 1991 + Debugging Memory Corruption in Game Development + CPanel Hotlink Protection Breaks WP Permalinks + The CheckWord Pricing Experiment + CheckWord Reviews + CheckWord - My iPhone Scrabble word checker app + CheckWord + Perforce SSH from Windows and Mac to Linux + Measuring Responsiveness in Video Games + Programming Responsiveness + Running in Circles + Practical Fluid Mechanics + Debugging Heisenbugs + Exponential Optimizing, or not. + Managed Code in Games + Blogroll and Categories not working in WordPress 2.3.2 + Visualizing and Diagrams + What is ntkmlpa.exe? + Hotfixing Vista + MySQL Server Install Problems with Vista + Optional code in WordPress header + Reddit-proofing WordPress + Get and Build Ruby 1.9 for Windows + Compiling Ruby as a Visual Studio Solution + Why won't it build? + Speeding up slow Vista + Why is Vista Slow? + Optimized Asset Processing + Falling Sand Game from the '80s + What is invalid parameter noinfo and how do I get rid of it? + Comments vs. Self Documenting Code + Stylus Control + The Seven Stages of the Programmer + Programming Bio + Cowboy Scrabble Programming + Delving into Cowboy Programming + Visualizing Floats + Trends in Game Programming + Shattering Reality + Blob Physics + Parallax Mapped Bullet Holes + Multithreading Particle Sytems + Evolve Your Hierarchy + Multi-core Processors + Mature Optimization + Practical Hash IDs + Programming Poker AI + Debug and Release + What is Cowboy Programming? + Pushing Buttons + Some Trees I Made + About + Teleological vs. Ontogenetic + Blob Correction + Notes on "Mature Optimization" * * * Recent Comments + Quora on Evolve Your Hierarchy + Require.js and Inheritance aEURC/ Tal Woolf | Interactive Developer on Evolve Your Hierarchy + Game Models aEUR" A Different Approach (Part 2) | npruehs on Evolve Your Hierarchy + Game Models - A Different Approach I | npruehs on Evolve Your Hierarchy + Passez A l' Entity System ! Partie 1 on Evolve Your Hierarchy + Artemis: the Greek goddess of software architecture | star-fu.tv on Evolve Your Hierarchy + Game Objects << DTO Software on Evolve Your Hierarchy + DevBlog: C+ << 7c0h on Evolve Your Hierarchy + The Core Concept << The Infestation Cometh on Evolve Your Hierarchy + Game components infrastructure for XNA. | Box Hacker on Evolve Your Hierarchy + PadrAues no desenvolvimento de games | USPGameDev on Evolve Your Hierarchy + Developer Diary: Jetpack game HTML5 - Day 1 - Michiel De Mey's Blog - Michiel De Mey's Blog - Programmer, designer and flash juggler on Evolve Your Hierarchy + Implementing Object Composition | Q&A System on Evolve Your Hierarchy + Developer Diary: Jetpack game HTML5 - Day 1 - Michiel De Mey's Blog - Programmer, designer and flash juggler on Evolve Your Hierarchy + aeoe%0e--oeRe-Factorycs,,comment << NDark MSN Live Space on Evolve Your Hierarchy + C++ Metadata aEUR" Part II, Inheritance, Dynamic Casting, and Allocation | Game Development Student Journal on Evolve Your Hierarchy + Day 8: Add game entities to our iPhone game on Evolve Your Hierarchy + design patterns - MVC-like compartmentalization in games? - Game Development - Stack Exchange | TechRetriever on Evolve Your Hierarchy + Functional Reactive Programming kick-starter guide << Web life between Python and lambda calculus on Evolve Your Hierarchy + Complex Functionality Using Component Systems | GameDevSoc on Evolve Your Hierarchy + AmitaEUR(tm)s Game Programming Information[ref] << Morgen Free's Blog on Evolve Your Hierarchy + Crafty, Game engine para el desarrollo de videojuegos para navegador - Chalchicha.es on Evolve Your Hierarchy + Scripting with Artemis Entity System Framework << Gemserk on Evolve Your Hierarchy + Daily Update #2 | Game Development Blog on Evolve Your Hierarchy + Engines on Evolve Your Hierarchy + Component-Based? Entity-Component? Confused? Part 1 | chris mann on Evolve Your Hierarchy + 2D Game Engine - Dokuro2 << Bombpersons's Blog on Evolve Your Hierarchy + Lag: The Bane Of Touch Screens | Games from Within on Measuring Responsiveness in Video Games + Developers Diary - Developing Methodology | Ploobs on Evolve Your Hierarchy + Learn how to play a guitar today. Lots of video tutorials and guides on Measuring Responsiveness in Video Games + Fun With Springs... | FML on Blob Physics + Component-based architecture << Burger Engine Blog on Evolve Your Hierarchy + Introducing 'Xanor' (WIP) - pekalicious on Evolve Your Hierarchy + Entity/Component Game Design: A Primer on Evolve Your Hierarchy + Cowboy coding | Jesus Was Rasta on Delving into Cowboy Programming + >> Onedayitwillmake on Evolve Your Hierarchy + Component system | BoxHacker on Evolve Your Hierarchy + As promised: Component Binding BEHIND THE SCENES << et1337 makes games on Evolve Your Hierarchy + Game Objects and Entities >> John Payne's Code Blog on Evolve Your Hierarchy + Component-based game design | Javascript Team on Evolve Your Hierarchy + Mark J. Derulo on Programming Responsiveness + Christian Smith on Blogroll and Categories not working in WordPress 2.3.2 + Entity frameworks | Gray Lantern on Evolve Your Hierarchy + Fyodor on Visualizing Floats + The best laid plans... | SLEEPY-GENIUS: tHE gAME dESIGN mUSINGS oF mARCUS mONTGOMERY on Evolve Your Hierarchy + Clojure Entity Component System | resatori on Evolve Your Hierarchy + Complex Functionality Using Component Systems on Evolve Your Hierarchy + Refactoring Fun << Hydroxic-Acid on Evolve Your Hierarchy + Mick on Evolve Your Hierarchy + Trent Sterling on Evolve Your Hierarchy + Lancechop on CheckWord + Shaikh Zafar on iPhone OpenAL Linking Problem + lost files recovery on Reddit-proofing WordPress + Aaron Schmidt on CheckWord - My iPhone Scrabble word checker app + SEO Content Writing Service on Reddit-proofing WordPress + Tweets that mention Cowboy Programming A>> Delving into Cowboy Programming -- Topsy.com on Delving into Cowboy Programming + Complex Functionality Using Component Systems << GameDevSoc on Evolve Your Hierarchy + Creating An Eternal Animation With Crafty.js | Programmateur on Evolve Your Hierarchy + Component Based game development | Rohin's Development Blog on Evolve Your Hierarchy + component-vs-hierarchical-modeling | Code, Hacks and Other Nerdy Things on Evolve Your Hierarchy + Modelli di Intelligenza nel Poker - Indie Vault on Programming Poker AI + State of the Art Game Objects | GBGames - Thoughts on Indie Game Development on Evolve Your Hierarchy + Cowboy Programming >> Falling Sand Game from the '80s | After Today News on Falling Sand Game from the '80s + Games from Within | Lag: The Bane Of Touch Screens on Programming Responsiveness + Zerg: my new game architecture-entity-system-thingy << My .plan on Evolve Your Hierarchy + [c?>>e-] Evolve Your Hierarchy << Black Straits Historical on Evolve Your Hierarchy + 10 a,--a,+-a, a,(c)a,dega,--a,ua1^ Developer a,,,a,SSa,PSa,PSa,1a1%0 | CodePonPon.com on Delving into Cowboy Programming + EastZoneSoupCube - links for 2010-07-20 on Programming Poker AI + Nightshade Engine on Evolve Your Hierarchy + Nightshade Engine on Evolve Your Hierarchy + Gotta strike while the iron is hot - A night at TSC (2010.03.24) << Scrabble Adventures on CheckWord - My iPhone Scrabble word checker app + Mick West on Delving into Cowboy Programming + Kevin C on Delving into Cowboy Programming + Peter Moss on Some Trees I Made + vitrier on AURemoteIOServer Error getting default device UID: '!obj' + Rein on Some Uses of SQL Databases in Game Development + Boynton Beach on AURemoteIOServer Error getting default device UID: '!obj' + Poker Bill on Programming Poker AI + Free iPad on Custom responsiveness measuring device + Eastern Europe on Custom responsiveness measuring device + Compressibility of Water << Greg Arakelian on Practical Fluid Mechanics + personalized playing cards on Programming Poker AI + jonathan on AURemoteIOServer Error getting default device UID: '!obj' + Game Engine Design / iPhone Game Engine Resources | Kleinsch on Evolve Your Hierarchy + Facebook Applications on iPhone OpenAL Linking Problem + Matt Kukowski on Comments vs. Self Documenting Code + Un Nouveau Moteur | Kromatyk on Evolve Your Hierarchy + John Jones on Evolve Your Hierarchy + van lines movers on AURemoteIOServer Error getting default device UID: '!obj' + Adam on Reddit-proofing WordPress + Interesting Reading... - The Blogs at HowStuffWorks on Programming Responsiveness + iPhone Games Review on iPhone OpenAL Linking Problem + Linkmoko on My coding practices in 1991 + To assert or not to assert | .mischief.mayhem.soap. on Some Uses of SQL Databases in Game Development + burning calories on Visualizing Floats + Drilian's House of Game Development >> Blog Archive >> Update For The Past N Months on Evolve Your Hierarchy + Matt C. on Why is Vista Slow? + Bill on CPanel Hotlink Protection Breaks WP Permalinks + gebA$?udeenergieberater on iPhone OpenAL Linking Problem + Programming Tools on My coding practices in 1991 + Erik on Delving into Cowboy Programming + computer education on Programming Bio + waldkraiburg on Pushing Buttons + Mick West on CheckWord Reviews + Stan R. on CheckWord Reviews + baju korea on Debugging Memory Corruption in Game Development + Alexander Churanov on Debugging Memory Corruption in Game Development + pyrlanta on Some Uses of SQL Databases in Game Development + Angelreisen on Pushing Buttons + Erick on Programming Poker AI + Glass Queens on iPhone OpenAL Linking Problem + dog health information on Visualizing Floats + muscle supplements on Programming Bio + ASSelik kapA+- on Compiling Ruby as a Visual Studio Solution + Facebook Applications on iPhone OpenAL Linking Problem + jonathon @ be a video game tester on Custom responsiveness measuring device + clabbers on CheckWord + Second Chance Checking on iPhone OpenAL Linking Problem + Zach on Evolve Your Hierarchy + Seiska on Cowboy Scrabble Programming + lehti on Debugging Heisenbugs + Tilaa on iPhone OpenAL Linking Problem + train horn on Custom responsiveness measuring device + Ian on My coding practices in 1991 + Payday Loans IL on My coding practices in 1991 + Phil Ivey on Programming Poker AI + spyder paintball guns on Custom responsiveness measuring device + pitching machines on Custom responsiveness measuring device + adult site reviews on My coding practices in 1991 + Catherine Ellis on Hotfixing Vista + software gestionale on Shattering Reality + ajay powell on iPhone OpenAL Linking Problem + estetik on Falling Sand Game from the '80s + Poker guy on Programming Poker AI + Catherine Ellis on Visualizing Floats + simon on AURemoteIOServer Error getting default device UID: '!obj' + Checking Account on iPhone OpenAL Linking Problem + Facebook Application Developers on CheckWord - My iPhone Scrabble word checker app + Patil S K on MySQL Server Install Problems with Vista + WSOP on Programming Poker AI + iphone application developers on Debugging Memory Corruption in Game Development + Baju Muslim on Debugging Memory Corruption in Game Development + Justin on MySQL Server Install Problems with Vista + Omar on Blob Physics + danny on iPhone OpenAL Linking Problem + Marc on Evolve Your Hierarchy + postgresql fanboy on Some Uses of SQL Databases in Game Development + Mick West on Evolve Your Hierarchy + Ash on Evolve Your Hierarchy + thuiswerk on CPanel Hotlink Protection Breaks WP Permalinks + EvaUnit02 on Programming Responsiveness + Shakor on Delving into Cowboy Programming + Cindy on MySQL Server Install Problems with Vista + nielsbot on CheckWord - My iPhone Scrabble word checker app + Miles3298 on Why is Vista Slow? + Brad on AURemoteIOServer Error getting default device UID: '! obj' + Smartie77 on Speeding up slow Vista + Smartie77 on Why is Vista Slow? + bholly on AURemoteIOServer Error getting default device UID: '!obj' + james @ train horns for sale on Reddit-proofing WordPress + Mick West on Evolve Your Hierarchy + andrei pokrovsky on Evolve Your Hierarchy + fx trading on AURemoteIOServer Error getting default device UID: '!obj' + Mick West on MySQL Server Install Problems with Vista + Phillip on MySQL Server Install Problems with Vista + bowling news on iPhone OpenAL Linking Problem + corporate video on AURemoteIOServer Error getting default device UID: '!obj' + Mobile Application Development on iPhone OpenAL Linking Problem + Mobile Application Development on CheckWord - My iPhone Scrabble word checker app + DoNEURDuDdegN,D,D2D1/2DdegN NEURDuDoD>>DdegD1/4Ddeg on AURemoteIOServer Error getting default device UID: '!obj' + Problems with Wordpress categories gone | Mosabuam - Manfred Moser, Werner Moser and gang on Blogroll and Categories not working in WordPress 2.3.2 + gAPtten sikis on Reddit-proofing WordPress + kelowna on Custom responsiveness measuring device + Generic on Custom responsiveness measuring device + Kirk on Custom responsiveness measuring device + Kirk on Some Uses of SQL Databases in Game Development + Kirk on AURemoteIOServer Error getting default device UID: '! obj' + Steven on Programming Poker AI + Steven on Programming Bio + xt Commerce Templates on Pushing Buttons + EIleen @ Philippines Outsourcing on Some Trees I Made + nintendo r4ds on AURemoteIOServer Error getting default device UID: '!obj' + J Surrey on AURemoteIOServer Error getting default device UID: '!obj' + xt Commerce Templates on CPanel Hotlink Protection Breaks WP Permalinks + Mick West on CPanel Hotlink Protection Breaks WP Permalinks + motorsport on CPanel Hotlink Protection Breaks WP Permalinks + Mick West on CheckWord - My iPhone Scrabble word checker app + Lee Rimar on CheckWord - My iPhone Scrabble word checker app + RobertMfromLI on Blogroll and Categories not working in WordPress 2.3.2 + ZigBee on AURemoteIOServer Error getting default device UID: '!obj' + Raymund @ Pinoy Social Network on Some Uses of SQL Databases in Game Development + Krishna on MySQL Server Install Problems with Vista + Yuly Navas on AURemoteIOServer Error getting default device UID: '!obj' + Tim Claason on Delving into Cowboy Programming + iphone on iPhone OpenAL Linking Problem + busana muslim on Debugging Memory Corruption in Game Development + coding on My coding practices in 1991 + Pimp My Nintendo on Measuring Responsiveness in Video Games + Handmade jewellery on iPhone OpenAL Linking Problem + songs on Blogroll and Categories not working in WordPress 2.3.2 + Music Videos on AURemoteIOServer Error getting default device UID: '!obj' + vippipaikat on Custom responsiveness measuring device + Mick West on Evolve Your Hierarchy + jason on Evolve Your Hierarchy + Brian on The Seven Stages of the Programmer + Brian on The Seven Stages of the Programmer + F on Delving into Cowboy Programming + tony g poker coupon code on CheckWord - My iPhone Scrabble word checker app + New cars on AURemoteIOServer Error getting default device UID: '!obj' + Understanding Lag << c# to javascript, actionscript on Programming Responsiveness + Zed Shaw on The Seven Stages of the Programmer + Andy on The Seven Stages of the Programmer + Andy on The Seven Stages of the Programmer + Dominique Rabeuf on The Seven Stages of the Programmer + Niner on The Seven Stages of the Programmer + Doug on The Seven Stages of the Programmer + Hugh on MySQL Server Install Problems with Vista + ggn on My coding practices in 1991 + ggn on My coding practices in 1991 + Spanish Fork Mechanic on CPanel Hotlink Protection Breaks WP Permalinks + fast property sale on Custom responsiveness measuring device + Bill on MySQL Server Install Problems with Vista + The extreme IT personalities and how to lead around them. << The World of an IT Leader on Delving into Cowboy Programming + Mick West on Programming Poker AI + 3m0k1D on Programming Poker AI + mike on Custom responsiveness measuring device + Pmaz on Programming Poker AI + Mick West on Evolve Your Hierarchy + Bjrn on Evolve Your Hierarchy + Mick West on Evolve Your Hierarchy + Bjrn on Evolve Your Hierarchy + perfect on Reddit-proofing WordPress + James on Measuring Responsiveness in Video Games + Andy Berdan on AURemoteIOServer Error getting default device UID: '!obj' + Ali on Falling Sand Game from the '80s + tony on Falling Sand Game from the '80s + Entity Systems << chrislunsford.com on Evolve Your Hierarchy + Gareth Lees on Some Uses of SQL Databases in Game Development + inkjetcanvas on Custom responsiveness measuring device + Manu on MySQL Server Install Problems with Vista + Arul Inthirarajah on CheckWord + Mike on Practical Fluid Mechanics + Mike on Programming Bio + cooking games on Falling Sand Game from the '80s + Free Games Download on Falling Sand Game from the '80s + Mick West on Some Trees I Made + Domain Reviews on CPanel Hotlink Protection Breaks WP Permalinks + Joe on Some Trees I Made + Mick West on Mature Optimization + Malcolm on Mature Optimization * Wordpress + Log in + Entries feed + Comments feed + WordPress.org * Search [ ] [Search] * Recent Posts + 1995 Programming on the Sega Saturn + Customizing Home Page Bookmarks on iPhone and iPad + AURemoteIOServer Error getting default device UID: '!obj' + iPhone OpenAL Linking Problem + Some Uses of SQL Databases in Game Development + Custom responsiveness measuring device + My coding practices in 1991 + Debugging Memory Corruption in Game Development + CPanel Hotlink Protection Breaks WP Permalinks + The CheckWord Pricing Experiment + CheckWord Reviews + CheckWord - My iPhone Scrabble word checker app + CheckWord + Perforce SSH from Windows and Mac to Linux + Measuring Responsiveness in Video Games + Programming Responsiveness + Running in Circles + Practical Fluid Mechanics + Debugging Heisenbugs + Exponential Optimizing, or not. + Managed Code in Games + Blogroll and Categories not working in WordPress 2.3.2 + Visualizing and Diagrams + What is ntkmlpa.exe? + Hotfixing Vista + MySQL Server Install Problems with Vista + Optional code in WordPress header + Reddit-proofing WordPress + Get and Build Ruby 1.9 for Windows + Compiling Ruby as a Visual Studio Solution + Why won't it build? + Speeding up slow Vista + Why is Vista Slow? + Optimized Asset Processing + Falling Sand Game from the '80s + What is invalid parameter noinfo and how do I get rid of it? + Comments vs. Self Documenting Code + Stylus Control + The Seven Stages of the Programmer + Programming Bio + Cowboy Scrabble Programming + Delving into Cowboy Programming + Visualizing Floats + Trends in Game Programming + Shattering Reality + Blob Physics + Parallax Mapped Bullet Holes + Multithreading Particle Sytems + Evolve Your Hierarchy + Multi-core Processors + Mature Optimization + Practical Hash IDs + Programming Poker AI + Debug and Release + What is Cowboy Programming? + Pushing Buttons + Some Trees I Made + About + Teleological vs. Ontogenetic + Blob Correction + Notes on "Mature Optimization" * Meta + Log in + Valid XHTML + XFN + WordPress Prev/Next Posts << Multi-core Processors | Home | Multithreading Particle Sytems >> Friday, January 5th, 2007 at 11:35 am Evolve Your Hierarchy By Mick West 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 [Fig-1] 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 aEUR" 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 aEURoethe blobaEUR . The blob is a classic aEURoeanti-patternaEUR 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 objectaEUR(tm)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 aEURoesub-objectsaEUR 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 aEURoeobjectaEUR 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 aEURoegame entity objectaEUR 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. [Fig-2] 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 aEURoecomponent based objectsaEUR 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: aEURoeWhenever 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.aEUR 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 aEURoeblob component.aEUR 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 This entry is filed under Game Development, Inner Product. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site. 120 Responses to "Evolve Your Hierarchy" 1 Complex Functionality Using Component Systems | GameDevSoc says: December 13th, 2011 at 7:47 am [...] many have proposed a component based system. Before continuing, I recommend reading Evolve Your Hierarchy, a good introduction to the [...] 2 Functional Reactive Programming kick-starter guide << Web life between Python and lambda calculus says: December 24th, 2011 at 6:19 am [...] System, a sort of Architectural Pattern to develop game logic (read an excellent introduction here.) Nevertheless, before even starting to think how to apply it in a functional context, I've [...] 3 design patterns - MVC-like compartmentalization in games? - Game Development - Stack Exchange | TechRetriever says: December 30th, 2011 at 5:06 am [...] https://cowboyprogramming.com/2007/01/05/evolve-your-heirachy/ http://gameprogrammingpatterns.com/component.html [...] 4 Day 8: Add game entities to our iPhone game says: January 4th, 2012 at 3:34 am [...] recently came across an article, which simply explains what we might want some of our game entities to do, these are summarized [...] 5 C++ Metadata aEUR" Part II, Inheritance, Dynamic Casting, and Allocation | Game Development Student Journal says: January 21st, 2012 at 3:03 am [...] of supporting multiple-inheritance with dynamic type casting in an engine that makes heavy use of component-based design are relatively [...] 6 aeoe%0e--oeRe-Factorycs,,comment << NDark MSN Live Space says: January 26th, 2012 at 10:20 pm [...] https://cowboyprogramming.com/2007/01/05/evolve-your-heirachy/ [...] 7 Developer Diary: Jetpack game HTML5 - Day 1 - Michiel De Mey's Blog - Programmer, designer and flash juggler says: January 31st, 2012 at 9:00 am [...] It's really easy to use, though it might be confusing at first because it's a modular game engine that uses entities and components. I suggest you read this article if you don't have any experience with it: https://cowboyprogramming.com/2007/01/05/evolve-your-heirachy/ [...] 8 Implementing Object Composition | Q&A System says: February 7th, 2012 at 3:00 pm [...] attempting to framework my fixture item courses comparable to how it is finished in this article. just one method to carry out this tactic is discussed in this StackOverflow [...] 9 Developer Diary: Jetpack game HTML5 - Day 1 - Michiel De Mey's Blog - Michiel De Mey's Blog - Programmer, designer and flash juggler says: February 8th, 2012 at 1:53 pm [...] It's really easy to use, though it might be confusing at first because it's a modular game engine that uses entities and components. I suggest you read this article if you don't have any experience with it: https://cowboyprogramming.com/2007/01/05/evolve-your-heirachy/ [...] 10 PadrAues no desenvolvimento de games | USPGameDev says: February 18th, 2012 at 6:21 pm [...] Um artigo que tenta mostrar as vantagens de usar agregaASSAPSo ao invA(c)s de heranASSa: (link) [...] 11 Game components infrastructure for XNA. | Box Hacker says: February 21st, 2012 at 9:06 pm [...] mentioned in an article by Cowboy Programming here it has marginal gains early into a project but reaps high development gains later [...] 12 The Core Concept << The Infestation Cometh says: February 29th, 2012 at 4:09 pm [...] C++ version. I'll go into more specifics on it later, but for further reading on the concept try here, or even search for "Component Based Architecture". Share this:TwitterFacebookLike [...] 13 DevBlog: C+ << 7c0h says: March 2nd, 2012 at 5:49 pm [...] bug, repetir" cuando se trata de programas inAotiles como el mAo. Tomemos como ejemplo el modelo de programaciA3n de Entidades y Componentes. El artAculo que enlazo (nota: si estA!n en esto del desarrollo de juegos deberAan darle una [...] 14 Game Objects << DTO Software says: March 22nd, 2012 at 12:35 pm [...] https://cowboyprogramming.com/2007/01/05/evolve-your-heirachy/ [...] 15 Artemis: the Greek goddess of software architecture | star-fu.tv says: April 12th, 2012 at 12:39 am [...] Evolve Your Hierarchy [...] 16 Passez A l' Entity System ! Partie 1 says: April 30th, 2012 at 12:32 pm [...] Cow boy programming : Evolve your hierarchy Si vous avez aimA(c), partagez ! [...] 17 Game Models - A Different Approach I | npruehs says: May 24th, 2012 at 1:24 pm [...] West. Evolve Your Hierarchy. https://cowboyprogramming.com/2007/ 01/05/evolve-your-heirachy/, January [...] 18 Game Models aEUR" A Different Approach (Part 2) | npruehs says: May 27th, 2012 at 11:18 am [...] West. Evolve Your Hierarchy. https://cowboyprogramming.com/2007/ 01/05/evolve-your-heirachy/, January [...] 19 Require.js and Inheritance aEURC/ Tal Woolf | Interactive Developer says: June 27th, 2012 at 6:43 am [...] If you are thinking of taking a more modular approach,A Mike West discusses this in his postA aEURoeEvolve Your HierarchyaEUR . Or alternatively if you are planning on making a larger application and need more structure and [...] 20 Quora says: September 4th, 2012 at 5:57 pm Have you used or considered Component / Entity System frameworks to build games? Interested in your feedback and experience.... Yes, I have built a system from scratch in Java, and now use it every day as a built-in feature of Unity. Their embrace of this philosophy has radically simplified development for me. Mick West (co-founder of Neversoft) got me started on the journey wi... Leave a Reply You must be logged in to post a comment. Cowboy Programming is powered by WordPress | Using Tiga theme with a bit of Ozh + WP 2.2 / 2.3 Tiga Upgrade