Jump to content
  • Advertisement
Sign in to follow this  
helix

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

This topic is 4602 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
Advertisement
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
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!