Allegro.cc - Online Community

Allegro.cc Forums » Game Design & Concepts » Component-driven design

This thread is locked; no one can reply to it. rss feed Print
 1   2 
Component-driven design
Indeterminatus
Member #737
November 2000
avatar

I read about this in one of the Game Programming Gems books, but I don't know which one from the top of my head (although I want to say the fifth volume).

_______________________________
Indeterminatus. [Atomic Butcher]
si tacuisses, philosophus mansisses

CGamesPlay
Member #2,559
July 2002
avatar

Now that we have established (I hope) that there is nothing that can be accomplished with MI but cannot be accomplished with Component-driven design (CDD) and vice versa, what are the relative benefits of using one system over the other, in concrete terms? Specifically, since there are no technical advantages when compared solely based on capacity, the advantages of one system over another are organization and ease of modification.

So, help me compare the two designs.

  • MI keeps things in a structured heirarchy. CDD offers a soup of components with no intrinsic structure.

  • CDD allows one to quickly change behaviors by assigning additional components to individual entities or to specialized templates. MI requires one create a specialized class to add additional behavior.

  • CDD features components that can be reused. MI generally requires code duplication[1].

Can anyone add to this list?

References

  1. MI allows this, but having multiple inheritance past the first level of ancestry creates complex inheritance patterns and is generally frowned upon. Example: creating a 'Boss AI' base class and inheriting that amongst several unrelated classes creates a complicated inheritance scheme.

--
Tomasu: Every time you read this: hugging!

Ryan Patterson - <http://cgamesplay.com/>

Steve++
Member #1,816
January 2002

axilmar said:

That's my opinion as well. Renaming something and then marketing it as new is silly.

This isn't just about composition. It's about providing a component framework that happens to use composition.

CDD allows one to quickly change behaviors by assigning additional components to individual entities or to specialized templates. MI requires one create a specialized class to add additional behavior.

Not just "quickly", but also at runtime. That's one of the big differences.

Inheritance is nice to have in the toolkit and I'm sure that even among CDD components there would be a lot of inheritance happening, especially among components that implement the same interfaces. One of the biggest benefits of CDD is that it favours service driven architecture over multiple inheritance spaghetti. I personally favour loosely coupled code.

axilmar
Member #1,204
April 2001

Steve++ said:

This isn't just about composition. It's about providing a component framework that happens to use composition.

I am ok with the framework, but I am not ok with presenting composition as something new.

Quote:

I personally favour loosely coupled code.

I do as well.

Here is something useful to read regarding multiple inheritance:

C++ FQA Lite: Inheritance -- multiple and virtual inheritance

Tobias Dammers
Member #2,604
August 2002
avatar

Personally, I avoid all occurrences of MI that do not follow the "one normal base class plus an arbitrary number of interfaces" pattern. In other words, when a class inherits from multiple base classes, then all but one must be interfaces (that is, they contain nothing but pure virtual methods).
A nice problem to illustrate the strengths and weaknesses of both methods: The classic species hierarchy. Let's consider a Dog and an Emu.

A Dog IS A Mammal.
A Dog IS A LandAnimal.

An Emu IS A Bird.
An Emu IS A LandAnimal.

A Mammal IS AN Animal.
A Bird IS AN Animal.
A LandAnimal IS AN Animal.

This doesn't work, obviously, because Dog tries to inherit from two classes that share a common base class.
Using composition, the 'Animal' class's members would be distributed over two components (say, AnimalClass, from which Mammal and Bird derive; and AnimalHabitat, from which LandAnimal, SeaAnimal, etc. derive), both of which with their own independent inheritance tree; class Animal would consist of nothing but instances of the two components.
Using multiple inheritance, Mammal and Bird would still derive from Animal, but LandAnimal would not. They could, however, both implement IAnimal.

---
Me make music: Triofobie
---
"We need Tobias and his awesome trombone, too." - Johan Halmén

 1   2 


Go to: