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...
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.Code:class CRole {} class CRace {} class CUnit: public CRole, public CProfession {} class CPC: public CUnit {} class CNPC: public CUnit {} class CMonster: public CUnit {}
I need a better design pattern. Can you help me?