

Evolve your hierarchy - wallflower
http://cowboyprogramming.com/2007/01/05/evolve-your-heirachy/

======
kiba
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.

~~~
pmjordan
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.

------
cellis
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...](http://t-machine.org/index.php/2007/09/03/entity-systems-are-the-
future-of-mmog-development-part-1/)

~~~
wallflower
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>

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

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

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

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

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

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

