Evolve your hierarchy | Hacker News Reader

Evolve your hierarchy

cowboyprogramming.com

25 pointswallflower10 comments

This is posted in 2007 but it is still useful, at least a possible solution.

As of right now, I am still doing game entities like he is describing except it is divided up into three parts which are events, models, and controllers. It was largely the result of having the needs to easily doing unit test without doing extremely complicated of a setup and as well making it far easier to maintain my code.

This setup migrates the game codebase from total disaster to something that is much cleaner. Now that this article has come into views, I fear that the codebase I have will slip back into oblivion as models, their corresponding rendering code, and the controllers gathers into blobs.

Having been through this sort of headache a couple of times, I'm convinced that the coupling of functionality must be as loose as possible. It sounds like OP's solution follows that approach, although he's a bit thin on specifics. Another useful concept in this context that is usually unknown (and often partially reinvented) by C++ programmers is protoypal inheritance. C++ makes this anything but simple, and you essentially have to reinvent your object system. It can be done, but it's not pleasant. I'll need to try these things in more expressive languages sometime.

Wow, cool. I was wondering when these would show up here on HN. For a more thorough treatment, you may want to read this series of posts by Adam Martin :

http://t-machine.org/index.php/2007/09/03/entity-systems-are...

Thanks, I felt it relevant in light of the interest in Flixel. The other classic article of the pair I submitted:

The Gorilla Guide to Game Coding

http://www.gamasutra.com/features/20050414/rouwe_01.shtml

The problem he's attacking is very real, especially in game development - your objects don't obey a tree hierarchy, and diamond multiple inheritance is definitely not the answer either. I'm not 100% sure I understand how he's implemented this, however. I'd be useful to see some more specific examples than the extremely abstract high-level diagram.

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.

This bit sounds familiar...

Seems like the Go language's implementation of Interfaces would be very useful here!

I've not looked into Go yet (I go on holiday and Google release a new language while I'm a away, hmph!) but if it's anything like Objective-C's 'protocols', it could work. You'd need to capture any messages and forward them to the appropriate component using some fast dispatching mechanism (hash table, I guess).

This can also help performance -- you get much better cache coherency by putting the components in arrays (an array of bounding boxes, an array of geometry...), and then you can do all sorts of cool data transformation tricks on these arrays (build a tree across it, or a sorted list of pointers, convert to a different coordinate space...) without all the OO overhead (which you still get when you need/want it...) But underneath all that, you still have a tightly packed array of data.

This sounds like a way to essentially accomplish multiple inheritance without having to deal with the problems caused by actually using multiple inheritance. Mixins (in languages that have them) would seem to do much the same thing as well.

Seems like a really good idea in this context; I will definitely keep this in mind whenever I'm faced with a huge, hairy, blobby object hierarchy.

This brings back terrible, terrible memories of MFC. I remember opening up my Visual C++ packaging to find a gigantic poster, several feet wide, showing the entire MFC class hierarchy. And the text wasn't even very big.

CObject anyone?

Reply on news.ycombinator.com