Design Pattern: Creatures, races and professions

I'm starting to try and conceive the CUnit hierarchy for a single-player game that will mix the Rogue and MUD game styles.

A CUnit is any passible game object (i.e. can be the target of an AI system). As such, a CUnit can be anything from the player character, to a wardog, a dragon, an hostile/friendly NPC...

(I am currently not thinking on having sentient objects. So my CItem hierarchy is out of the equation).

CUnits will be characterized by their race and their role (profession). The Player and NPCs will have both, monsters will only have a race (possibly also a role... some generic monster profession).

CRace examples: Human, Elf, Dwarf, Dragon, Kobold, wardog, ...
CRole examples: Fighter, Mage, Rogue, Paladin,... Monster.

I'm having trouble devising the design pattern for this structure.

As I see it, I will have 3 hierarchies. Their bases will be CRole (profession, or class for the AD&Ders out there), CRace and CUnit.

Of them, CUnit will multi-inherit from CRole and CRace. CUnit will then be the base for the 3 types of possible units: PC, NPC, Monster. So, a short synopsis would be...

Code:

---

class CRole {}
class CRace {}
class CUnit: public CRole, public CProfession {}

class CPC: public CUnit {}
class CNPC: public CUnit {}
class CMonster: public CUnit {}

---

However, I'm feeling this isn't a good model. More, it's too rigid. Everytime I want a new role or profession I will have to create a new class. Soon, if imagination allows me, I'll have tens of classes spreading out just to support this model.

I need a better design pattern. Can you help me?

I'm not sure I'd want to make CUnit ANY possible game unit, but it is your choice.
A better OOP design is probably to make these "character" classes a tree:

Code:

---

      CUnit
        /  \
      PC  Beast
        |
      NPC

---

Race is a property of a character I would think, it would be better if it stayed that way: you could make the user choose from an enum when he constructs the object.
As for jobs, I'm really torn about that. Depending on your needs it could be a class on it's own, but I think it's just another property. Your game engine could examine the character and decide what he/she can do.

Something to think about.

I don't know why you would have NPC derive from PC. I'd imagine Playable Characters would have all the functions of NPCs and then some, not the other way around. I personally don't get the CUnit, either. Personally, I don't see a thing Creatures would have that NPCs don't and a thing NPCs have that PCs don't, so I really just see:

Code:

---

Creep
  |
 NPC
  | 
  PC

---

I'd say to Mario, though, I think for your hierarchy, you should be thinking "has a" not "is a". In reality, a CUnit "has a" race and a role, not "is a" race and a role. In that sense, it's easier when implementing your CUnits to distinguish racial traits and skills from professional traits and skills, and using some polymorphism, your CUnits can easily change professions without changing their full type.

Everything "alive" in-game is a Being. Certain Beings are non-sentient Creatures (AI Beasts, as you put it), some Beings are sentient Characters. All beings are composed of Arms, Legs, Heads, and other body parts, which each can hold certain types and numbers of Items--Weapons, Shields, Armor, Books, Jewelry, etc.

This might help you

Quote:

---

Originally Posted by Aran

Everything "alive" in-game is a Being. Certain Beings are non-sentient Creatures (AI Beasts, as you put it), some Beings are sentient Characters. All beings are composed of Arms, Legs, Heads, and other body parts, which each can hold certain types and numbers of Items--Weapons, Shields, Armor, Books, Jewelry, etc.

---

The arm objects should contain a hand object which of course contains a vector of finger objects all of which contain nail objects which naturally inherit from bone objects. All of this obviously contains billions of cell objects which all contain organelle objects which in turn contain atom objects with quark objects inside of them and... *booooooom*

No, I see what you mean about the limbs, which have their use in armor and such, of course this really doesn't need to be done as limbs, simply as armor slots. Chest armor, greaves, gauntlets, helmet, boots, etc... Whether they have two arms or eight, gauntlets should be gauntlets.

I already have the inventory system in place. It will be a data member of a creature. CInventory is a class that derives from CItem in fact. So that an inventory becomes an abstract notion of a container attached to any creature. This is useful to me because in the game system I'm developing, once a creature dies it becomes a container (the corpse "holds" the creature items). The corpse can be picked, put inside another container (provided is big enough), and will have a lifespan, after which it will rot away.

Anyways... I can see you guys points. I was perhaps complicating the model. Race and Profession should definitely be seen as properties of CUnit (considering changing the name to CCreature)

You better have some distinguishing feature between a dead NPC and a container like a chest. Otherwise, any chance of a proper resurrection spell will be moot.

Will have to think of it. Didn't remember about resurrection....

Of the top of my head... maybe a weak_ptr that is 0 if it is a normal container, or the address of it's owner, if it is a corpse. It is feasible to think that the creature is not deallocated before its corpse rots.