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.

I am trying to write a platform shooter in C++ with a really good class structure for robustness. The game itself is secondary; it is the learning process of writing it that is primary.

I am implementing an inheritance tree for all of the objects in my game, but I find myself unsure on some decisions.

One specific issue that it bugging me is this:

I have an Actor that is simply defined as anything in the game world. Under Actor is Character. Both of these classes are abstract.

Under Character is the Philosopher, who is the main character that the user commands. Also under Character is NPC, which uses an AI module with stock routines for friendly, enemy and (maybe) neutral alignments.

So under NPC I want to have three subclasses: FriendlyNPC, EnemyNPC and NeutralNPC. These classes are not abstract, and will often be subclassed in order to make different types of NPC's, like Engineer, Scientist and the most evil Programmer.

Still, if I want to implement a generic NPC named Kevin, it would nice to be able to put him in without making a new class for him. I could just instantiate a FriendlyNPC and pass some values for the AI machine and for the dialogue; that would be ideal.

But what if Kevin is the one benevolent Programmer in the whole world? Now we must make a class for him (but what should it be called?). Now we have a character that should inherit from Programmer (as Kevin has all the same abilities but just uses the friendly AI functions) but also should inherit from FriendlyNPC.

Programmer and FriendlyNPC branched away from each other on the inheritance tree, so inheriting from both of them would have conflicts, because some of the same functions have been implemented in different ways on the two of them.

1) Is there a better way to order these classes to avoid these conflicts? Having three subclasses; Friendly, Enemy and Neutral; from each type of NPC; Engineer, Scientist, and Programmer; would amount to a huge number of classes.

I would share specific implementation details, but I am writing the game slowly, piece by piece, and so I haven't implemented past Character yet.

2) Is there a place where I can learn these programming paradigms? I am already trying to take advantage of some good design patterns, like MVC architecture and Mediator objects. The whole point of this project is to write something in good style.

It is difficult to tell what should become a subclass and what should become a state (i.e. Friendly boolean v. Friendly class). Having many states slows down code with if statements and makes classes long and unwieldy. On the other hand, having a class for everything isn't practical. 3) Are there good rules of thumb or resources to learn more about this?

4) Finally, where does templating come in to this? How should I coordinate templates into my class structure? I have never actually taken advantage of templating honestly, but I hear that it increases modularity, which means good code.

share|improve this question
    
You don't need a full blown CBES, you can start smaller by choosing proper abstractions, still being able to compose your objects at runtime. The NPC-variations sound like they can be basically 1 general NPC class, they just have different "AI-Brains". So build some different AI-Brain-classes: FriendlyBrain, EnemyBrain, NeutralBrain all derived from BrainBase, put that BrainBase member into the NPC class and assign it at runtime to fit your needs. –  Maik Semder Dec 16 '12 at 21:26

2 Answers 2

up vote 8 down vote accepted

Refer to the popular software engineering principle, "Prefer composition over inheritance". Class proliferation concerns are the central reason behind the Component-Based Entity Systems (CBEs) so often mentioned on this site, which is a gamedev-specific embodiment of the aforementioned principle.

The essence of the matter is that inheritance hierarchies are compile-time-composable ONLY, whereas composition hierarchies (objects consisting of other objects and primitives) are runtime-composable. Immutable vs. mutable. Your choice.

See Mick West's introduction to CBES. Also see answers like this one (ahem), by searching this site for "composition inheritance".

share|improve this answer
    
Great answer! I had no idea this even existed, or that deep inheritance structures were not a de-facto standard. (If I had known I would've found the answer through the gamedev question you linked to) –  Eric Thoma Dec 16 '12 at 7:12

Regarding question two:

http://www.oodesign.com/

Look for:

  • Singleton
  • Visitor
  • Observer
  • Command
  • Proxy
share|improve this answer
    
That is a very helpful site. Thanks! –  Eric Thoma Dec 16 '12 at 7:10

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.