Take the 2-minute tour ×
Game Development Stack Exchange is a question and answer site for professional and independent game developers. It's 100% free, no registration required.

The question is pretty self explaining: doesn't multiple inheritance solve all the problems that entity systems also solve?

I just remembered a term called "multiple inheritance", and that seems to solve a lot of bloating problems that classical inheritance imposed.

share|improve this question
1  
Multiple inheritance is similar to entity systems, but it's not the same. For example, multiple inheritance entities cannot have components added and removed at run-time. Not all languages support multiple inheritance either. You could also consider composition to be in the same category vs entity/components. –  Byte56 Jul 26 '12 at 18:17
2  
If your classes are already so neat that you can seamlessly inherit them together in any way you like, they might as well be components already. Components also allow composition/aggregation at runtime –  melak47 Jul 26 '12 at 18:19
    
Well, its more complex and less error prone, so why prefer it? –  API-Beast Jul 26 '12 at 22:43
2  
MI doesn't really address "bloat" issues either, as inheriting an excess of interface from a parent class or classes is more a symptom of poorly using an inheritance mechanism rather than of single versus multiple inheritance. The same "bloat" can be achieved in a composition-oriented approach to a problem, as well. –  Josh Petrie Jul 27 '12 at 1:16
    
@MrBeast do you mean more complex/more error prone, less complex/error prone, or "why not prefer it?" –  David Lively Aug 17 '12 at 23:04
add comment

2 Answers 2

up vote 9 down vote accepted

No, multiple inheritance does not solve all the same problems that entity systems do: entity systems and multiple inheritance are two very different things. You can build an entity system with or without multiple inheritance and similarly you can utilize multiple inheritance without building an entity system.

Traditionally, component-focused entity systems are developed because of a desire to move away from heavy inheritance in any form, aiming instead for composition. There is sufficient literature and discussion elsewhere on this adage, for example on programmers SE or SO itself, and it the larger question of why to prefer composition is sort of off-topic for game development. In short, however, it's an approach that tends to lend itself to improved mutability and maintainability.

share|improve this answer
add comment

Josh's answer is awesome, but I'd like to add:

One of the coolest features of Entity/Component is the data-driven way in which every "thing" in your game is created and managed. From what I've seen, once you have a nice library of component types and systems created, you can build just about anything with minimal code modifications. (Note: minimal != 0)

By defining your game in terms of behavior, and giving yourself the ability to modify those behaviors on the fly - at runtime, during initialization by loading them from a script or database, etc. - you open up an entire world of new possibilities. Want to see why your shadows don't land where you'd expect? Add a camera/POV component to your light.

Entity/component lets you build anything you want, as long as you've created the blocks.

Also, multiple inheritance causes the same problem as single inheritance. When you add an attribute or behavior in the hierarchy, it propagates. As long as you're making deep hierarchies, you'll run into situations where you're carrying unnecessary weight, duplicating code, or resolving conflicts. Most of that can be avoided when you imagine your game as data.

I've just started playing with this in the past few weeks, but I'm impressed at how simple things have become. It's not a silver bullet - I've run across a few cases where attaching a lambda to a component was the cleanest and most expedient way to solve a problem - but it's a pretty great pattern, if you can call it that.

On a slightly related note: one of the big, boring maintenance generators in data-centric applications (websites, etc.) is mapping hierarchical objects into relational databases. We've got lots of nifty solutions around, but they're ultimately all hacks designed to flatten hierarchies. Instead of building your model so that it serves the purpose of the application, you wind up compromising between an effective hierarchy and a logical relational representation. I've been toying with the idea of rebuilding a pretty large hierarchy in one of my apps as an entity/component system - ditch the hierarchy and make the database the Gold Standard for the rest of the implementation - and it's promising.

When you integrate capabilities like dynamic code generation/code caching that can address performance issues, you wind up with a fast, flexible, logical architecture that might just realize the reusable code goal of OOP in a much, much better way.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.