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

Can you give some examples of what the article means by "components"? Is it talking about preferring object composition over inheritance?

-Alex

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).

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?

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.

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).

Well then, if the method I suggested (data usage) is object oriented, then kudos to me :D.

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'.

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?

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

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]

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.

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???

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

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?

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).

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?

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. ;)

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.

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"