Sign in to follow this  

"Refactoring Game Entities With Components" -- Thoughts on this technique?

This topic is 4292 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

In the latest GameDeveloper Mag (March 2006), there was an article by Mick West titled "Evolve Your Hierarchy: Refactoring Game Entities With Components" (sorry, I couldn't find an online link). I was wondering what your thoughts/experiences were with the technique outlined. I am becoming increasingly unsatisfied and even disgusted with the typical object hierarchy especially given the codebase we are stuck with using that is a perfect example for many of the problems with typical OOP. I have been pondering off and on about how a component type system might fare and this article fueled my fire to further investigate it. I decided that I will implement it in a small scale for a game system I have just begun working on because it will fit perfectly with how I designed it. As an added bonus, it would be a good way to evaluate if components are worth doing on a large scale (a game-wide replacement of our currently horrible game object hierarchy). Unfortunately, the article was very light on any technical details so any "gotchas" or suggestions on the best direction to proceed would be great.

Share this post


Link to post
Share on other sites
Can you give some examples of what the article means by "components"? Is it talking about preferring object composition over inheritance?

-Alex

Share this post


Link to post
Share on other sites
I haven't seen the article yet, but if the general suggestion is prefer composition for game object behavior over inheritance, I can certainly concur. In fact, I've been trying to push this technique inside one of our techs for a long time... it wasn't until a game team actually started hammering on the tech alongside the dev engineers did it actually get done (several years later).

It's definitely the way to go. If you're looking for some other food on the subject, I'd suggest checking out Scott Bilas' presentations from GDC (Google should find it) regarding Dungeon Siege, as well as the discussions of Halo's framework (also GDC, I believe, but maybe Emerging Tech).

Share this post


Link to post
Share on other sites
Yeah, one of the resources sited for the article was Scot Bilas' GDC 2002 presentation -- "A Data-Driven Game Object System". http://www.drizzle.com/~scottb/gdc/game-objects.htm

Also, "Component Based Object Management" by Bjarne Rene in Game Programming Gems 5 and "Game Object Structure: Inheritance vs. Aggregation" (2002) by Kyle Wilson: http://www.gamearchitect.net/Articles/GameObjects1.html

I have to be honest, I haven't looked at these references yet but I will. And yes, the article is exactly talking about object composition using components instead of a game entity hierarchy.

The author also said that there was much resistance to moving over to components until he had a working system the other programmers could see and use then they bought into (some quicker than others ;) ). I know there are several programmers here who are already onboard without even talking to them but I know there are definately others who will resist mightily. :D

I didn't realize that Scott Bilas' talk was regarding Dungeon Siege. I was already discussing that with one of our programmers and how he liked that method.

So did you find it to be a large painful job switching over to components from your hierarchy?

Share this post


Link to post
Share on other sites
After spending two months formulating nodes for my own scene graph I have finally realized that you cannot automate the creation of nodes in an object oriented manner. There is a time when OO fails you and this is one of them.

Data is the key to creating complex scenes, not a super sweet neat hierarchy with lots of inheritence and other goodies, when it comes down to it, you just gotta have some cold hard data when creating complex scenes, especially if your goal is speed.

Share this post


Link to post
Share on other sites
Quote:
Original post by Shamino
After spending two months formulating nodes for my own scene graph I have finally realized that you cannot automate the creation of nodes in an object oriented manner. There is a time when OO fails you and this is one of them.

Data is the key to creating complex scenes, not a super sweet neat hierarchy with lots of inheritence and other goodies, when it comes down to it, you just gotta have some cold hard data when creating complex scenes, especially if your goal is speed.

I am curious as to how OO failed you here? OO in no way requires you to use inheritance for everything. A great deal of what OO advocates is the use of composition. That is: building new components through the combination of existing modules. That doesn't mean you need a large inheritance heirarchy (in fact this is discouraged quite deeply and whomever tought you that OO meant that should be shot).

Share this post


Link to post
Share on other sites
Another technique that is starting to be used more these days is mix-in inheritance. The idea is that you create several base classes which provide specific functionality. Game objects then inherit from the classes they need. It steps away from the traditional game object heirarchy where you put common functionality in the top of the tree and all objects are stuck with it whether they need it or not.

As an example, imagine that you have a Bullet object. In most game object heirarchies the Bullet class would like have a method called render() or some such as part of a Renderable interface further up in the heirarchy. But in reality, the Bullet may not even need to be rendered. Using mix-in inheritance, you would have a Renderable class that can be inherited from as needed, or in the case of the Bullet not inherited from at all.

This is an easy system to implement in a language like C++, which supports multiple inheritance. And as long as you limit the base classes to specific functionality, you avoid problems like diamond heirarchies. Such a system can also be implemented in Java, but it isn't straightforward and is more effort than it's worth, IMO.

Julian Gold talks about this (and other, rather nonstandard techniques) in his book Object-oriented Game Development. He talks a bit about different object heirarchies (collapsed - no inheritance (think C structs), shallow - the most common, and vertical) and why they are flawed. He then explains how he things mix-ins solve the problems. He also talks about how composition can solve those problems, and why it's an inferior to the mix-in solution.

I've never applied mix-in inheritance myself and probably never will (I tend to use Java and C, where it just doesn't apply). But it's something to look into for those who are wanting something different. I also recommend Gold's book for such people. He really is quite cynical about some of the thins people commonly accept as 'good OO'.

Share this post


Link to post
Share on other sites
Quote:
Original post by Aldacron
Another technique that is starting to be used more these days is mix-in inheritance. The idea is that you create several base classes which provide specific functionality. Game objects then inherit from the classes they need. It steps away from the traditional game object heirarchy where you put common functionality in the top of the tree and all objects are stuck with it whether they need it or not.


This sounds like policy-based design. Is that what you meant?

Share this post


Link to post
Share on other sites
Quote:
Original post by skanatic
Quote:
Original post by Aldacron
Another technique that is starting to be used more these days is mix-in inheritance. The idea is that you create several base classes which provide specific functionality. Game objects then inherit from the classes they need. It steps away from the traditional game object heirarchy where you put common functionality in the top of the tree and all objects are stuck with it whether they need it or not.


This sounds like policy-based design. Is that what you meant?


Mixins

Share this post


Link to post
Share on other sites
Quote:
This sounds like policy-based design. Is that what you meant?


mixins (wikipedia.org)
mixins (c2.com)

It may be worth mentioning for those reading along the decorator pattern which also allows you attach additional responsibilities without subclassing. snk_kid has a great post right here on gamedev that details use of the decorator (and composite) pattern to add behaviour though composition when creating scene graphs.

[Edited by - srh on March 2, 2006 8:43:06 AM]

Share this post


Link to post
Share on other sites
I use a combination of mixins and composition in Ancient Galaxy, but over time, the composition method is winning out, for sure.

My main mixins are Obj ( the main game object class, containing an id, a string name for the object, and the object's type ), and Persistent ( saving & loading of member data ).

Most items in my game are Entities, like the player, enemies, interactive objects, while some are derived from Particle::Cluster, like smoke, debris, bullets, etc.

All things derived from Obj have a map of facets ( like properties ), which store a string name, and a union of int, string, matrix, etc. as the payload.

These facets are used for setting up the object upon level build, as well as runtime information about the object's state. The facets are automatically saved & loaded as part of the Obj mixin, so when you need a new data member for an object, you can add it ( even at runtime ), and it will be saved & loaded with the object instance. This is way better than adding a data member, which requries touching header files that cause rebuilds, breaking saved games and/or levels, and manually initializing, saving and loading it.

We have made a GUI-oriented facet editor available in game and in the editor to uniformly allow adding, deleting and editing of facets. This also simplified the editor quite a bit, because more and more of the important per-entity info is in the facets, rather than in the data members, which require a custom gui to update.


Share this post


Link to post
Share on other sites
From you main Object class, do you then use inheritence to further define geometric objects (like nodes for a scene graph), and things like that? Lifetime of particles, etc etc etc???

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Quote:
Original post by Shamino
After spending two months formulating nodes for my own scene graph I have finally realized that you cannot automate the creation of nodes in an object oriented manner.


Really? What I think you meant to say is:

Quote:

...I have finally realized that I cannot automate the creation...


What you're talking about is serialization of objects. This is a well defined problem that's been solved a million times by others.

Share this post


Link to post
Share on other sites
Quote:
Original post by helix
In the latest GameDeveloper Mag (March 2006), there was an article by Mick West titled "Evolve Your Hierarchy: Refactoring Game Entities With Components" (sorry, I couldn't find an online link). I was wondering what your thoughts/experiences were with the technique outlined.

I am becoming increasingly unsatisfied and even disgusted with the typical object hierarchy especially given the codebase we are stuck with using that is a perfect example for many of the problems with typical OOP. I have been pondering off and on about how a component type system might fare and this article fueled my fire to further investigate it. I decided that I will implement it in a small scale for a game system I have just begun working on because it will fit perfectly with how I designed it. As an added bonus, it would be a good way to evaluate if components are worth doing on a large scale (a game-wide replacement of our currently horrible game object hierarchy). Unfortunately, the article was very light on any technical details so any "gotchas" or suggestions on the best direction to proceed would be great.


We are using a component based technique on our rpg in progress Mistlands since we started coding on it in (we did not know the name then so we use the name propertys). The main reason was that it would be cool to try something like it :). I'll read the articles and see if i have any comments to give that could help. You can always download the mistlands snapshot and have a look if you wish, source code is included :). Also some documentation on our forum about it.

http://zeropointgameplay.com/snapshot

http://zeropointgameplay.com/forum/viewforum.php?f=18

Share this post


Link to post
Share on other sites
Quote:
Original post by Anonymous Poster
Quote:
Original post by Shamino
After spending two months formulating nodes for my own scene graph I have finally realized that you cannot automate the creation of nodes in an object oriented manner.


Really? What I think you meant to say is:

Quote:

...I have finally realized that I cannot automate the creation...


What you're talking about is serialization of objects. This is a well defined problem that's been solved a million times by others.


Perhaps :D, but isn't that kinda like the same thing as using components (data types) to create scenes?

Share this post


Link to post
Share on other sites
I've recently stumbled across the Composition Design article (not sure which one) and I'm now amazed at how many people do not realize the difference between the "is-a" and "has-a" relationships when using inheritance in their projects. Since polymorphism has a "is-a" pattern to follow, sometimes programmers deviate from it and ocasionally use the "has-a" instead. At the moment, the optimum solution for overly complex projects is a collaboration of the Composite and Inheritance designs, simply because you can use advantages of both (Polymorphism/Virtual functions in Inheritance and COM-similar patterns with Composite).

Share this post


Link to post
Share on other sites
I have only just started formal software engineering in uni, but I've been coding for a great while longer. So I don't know all the technical terms, but I think I use mixins. I define by attributes/properties. Like (preface G for these) GTangible (gives it a position, rotation, dimension), GRenderable (gives it required members and methods), GAnimated (etc...)

Does anyone have a nice fancy word for this?

Share this post


Link to post
Share on other sites
I've used mixins (I didn't realize it had a name!) in the past with great success. It was on smaller scale projects so I'm not sure if it would still be as feasible on a major project like I'm working on now. However, that is unfortunately not an option with our codebase because the hierarchy and all the classes are defined in script (AAAAARGH!!!!!) which does not allow for multiple inheritance. Don't ask me whose bright idea that was but it sucks! Interestingly enough, there is actually a component system in place but it is not used in the manner described in the article but rather for data storage for the most part.

I will have a look at those patterns posted -- they sound interesting. And I might sift through the code posted above as well. ;)

Share this post


Link to post
Share on other sites
inheritance & sub-type relations in a typical statically typed languages are well static and fixed at compile-time that is why traditional hierarchies are rigid, tightly coupled, and brittle because those who are not in the know focus way to much on the "is-a" relationships with out considering if that relationship really makes common sense and the consequences of making such decisions. And no mixins don't exactly solve the problem completely since again in typical statically typed languages it's static and the relationship is fixed at compile-time.

It's been known for a long time that what you may believe to be a generalization (sub-type/class) relationship should really be some kind of association relationship, composition/aggregation (i don't mean the composite design pattern though highly related) are specific kinds of association relationships they are preferred, they should be thought as the default. The reason why they are preferred is:


  1. There much more likely to represent the system/abstraction correctly than generalization relationships.

  2. They can represent dynamic relationships much more easily than generalization relationships in a statically typed language. There not bounded by the compile-time barrier, you can do more things change guts/skin of objects at runtime etc, etc.



Around 1994 Gang-of-Four (GOF) released a aload of OO design patterns most of them using associative relationships, i suggest you read the book.

Lastly generalization & association relationships (aswell as any other kind of relationships) go hand in hand not in total isolation on there own.

Share this post


Link to post
Share on other sites
Great to see this kind of discussion finally happening. I'm noob on this board but have been in the software business for 20+ years. OO took too long to catch on in the real world. We started with structured programming in the 80s until C/C++ took hold in the 90s but top-down was still being taught in the schools. We talked about parallel arch in the 90s before multicores became a pipe dream and finally reality last year. Adopting OOD and OOP principals is the key to going to parallel arch and multicore. Component basing should improve the organization of objects forcing tighter rules and looser object coupling. Too often as some of you have said, getting Is-a'ed out forces programming to tightly couple class building to rigid forms and robs attention from techniques such as mix-ins and more generic classing. Patterns have evolved to address a path to object hormony resolving most of the issues of dealing with what-is and what-has and how implementation should play in. Looking at the facets example, you can see that collections play more of a role than inheritance.Beeing able to assemble a collection of objects that work in unison is the key to succesfull object interaction. Like a shop full of tools, a bandsaw is not the only tool as inheritance is not the only method of class construction. Inheritance, Is-a and Has-a is important to maintaining object purity. If you later find a Is-a/Has-a violation then refactoring a well developed set of objects should not be difficult. Refactoring from procedural to OO is the nightmare :eek:. Take the bullet example: The bullet is not velocity but has velocity once fired until is encounters flesh, wall or ground then it "is" shrapnel. (Ok that ended in a morph). Being able to provide the physics without a tight couple is-s relation is the key since this object can do many things and morph into a differnt object in the end and be used again. CBullet is fired from a gun, has velocity for 2 seconds and strikes a brick in a wall. It shrooms into the brick, breaks in two and half falls to the ground. Bird sees the fellen shrapnel and takes it way. A once pure class has been striped back to abstract, reformed as two objects and now has pieces of CBrick attached. Also CBird has a piece of the action now also.
I can see a lot of use for components in the future of development since we already use them with current 3rd party products. I currently use components to seperate the object collections(world and stuff) from physics and rendering. Using Visitor and Adaptor patterns I have enough flexibility to allow using these same engines elsewhere. This thread hits on the next step of my componentizing effort. I have started collections of objects that I intend to integrate into the main mesh of the world and define these components by their physical makeup. Take the woodcutters shed used in a lot of games. If it gets trashed it becomes scenic material and you can't reuse it. If the shed were a composite made of other objects, boards then you could reuses parts. Say the shed is razed and the enemy is killed. Provided they did not torch it the boards should be still there. A couple of surfs could take theboards back to the stockpile and reused. This does require more work and billboarding this in LOD gets difficult but it's possible. "Long live OO"

Share this post


Link to post
Share on other sites
Quote:
Original post by AlabamaCajun
OO took too long to catch on in the real world.


OO is not only one to take time to catch on from academia to industry actually it probably isn't as bad as some other paradigms that have alot of potential.

Quote:
Original post by AlabamaCajun
We started with structured programming in the 80s until C/C++ took hold in the 90s but top-down was still being taught in the schools.


Maybe in industry but not necessarily in academia and what you may or may not have been taught depends on which university you went to.

Quote:
Original post by AlabamaCajun
We talked about parallel arch in the 90s before multicores became a pipe dream and finally reality last year. Adopting OOD and OOP principals is the key to going to parallel arch and multicore.


No, not necessarily, infact without being very, very careful and using lots of architectural/design patterns imperative OO languages can make large-scale massively concurrent/parallel applications a major nightmare and quite infeasible. The main reason why is it encourages too much explicit shared mutable state and constructs that do not foster implicit parallelism. Actually the future is more likely in hybrid functional languages (and no it's not procedural) because it's been known for a long time in academia that purely functional languages have a high level of implicit parallelism to be taken advantage of and has constructs that help in writing massively concurrent/parallel applications and make writing them more feasible without the need to do extra careful/cautious coding all the time.

So you know that i'm not talking rubbish i suggest investigating ""The Next Mainstream Programming Languages: A Game Developer's Perspective".

Just as with OO, this is going to take time to catch on actually it is taking along time to catch on in the industry.

Quote:
Original post by AlabamaCajun
"Long live OO"


OO has it's place but it's not a panacea and not more suited to every problem domain in existence than other paradigms.

Share this post


Link to post
Share on other sites
[Quote] by snk_kid] ~ Actually the future is more likely in hybrid functional languages ~
Point well taken on the matter of going foward with programming techology. I think we tend to attempt to solve problems with time tested principles and forget that newer methodologies could better solve the problem. As for acedemia when I colleged in the early 80s RPG and Cobol were the staples in business principles. One procedural and the other event driven. Mentors kept us from using gotos and enforced structured programming. I do agree that the hybid languages will better serve as RAD tools, I have strong beliefs that OO will handle parallel just as easy. It's all in how the model is developed. Attempting to reach equlibrium with core usage will be the challange. We already use objects to run the shader(s) and the principal proves itself. I do realize that shaders are nothing more than Functors which are objects that are defined by their properties and a single method. OO is not just a class but a discipline of logical thinking and realworld modeling.

Share this post


Link to post
Share on other sites
Quote:
Original post by AlabamaCajun
I think we tend to attempt to solve problems with time tested principles and forget that newer methodologies could better solve the problem.


Right it's easy to get carried away by the hype and become a little ignorant without realizing it, i think just about everyone is a crime of it from time to time.

Whats funny is that the functional paradigm isn't new, it's older than both structured and OO paradigms and OOP was probably being done in one of the daddy functional languages i.e lisp before anyone knew what OOP was or made it an explicit paradigm/practice.

Share this post


Link to post
Share on other sites
Quote:
Original post by snk_kid
Right it's easy to get carried away by the hype and become a little ignorant without realizing it, i think just about everyone is a crime of it from time to time.

Whats funny is that the functional paradigm isn't new, it's older than both structured and OO paradigms and OOP was probably being done in one of the daddy functional languages i.e lisp before anyone knew what OOP was or made it an explicit paradigm/practice.


Absolutly right :thup: (thumps up). I can definitelty rememeber working in assembler with a intel 8085 processor and Z80 Disk controller where both needed to run parallel. OSs not do this although it's more of task switching act than a single programme!

Interesting thought pops into mind: With micro controllers a sort of component functionality is being implimented. Each controller is programmed as a Functor and has a specialized purpose with any number of sensors and/or output responsed. It's also a study on neural netting where the conrollers are both parallel and interconnected. This enforces strict class obedience since one controller can't get to the other controllers privates:blush:

Share this post


Link to post
Share on other sites

This topic is 4292 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this