What would be a good way to code up a character class?

Right now I have this:

Entity
Character Extends Entity
Dwarf, Elf and Human all Extend Entity.

This works pretty well.  But each race can have skills (some different)
Each race can also have different classes and different classes can have different skills.

Right now I have Classes and Skills as their own classes/objects and add them to race.
Inside Character I have an "array" of skills and classes.  It's kind of muddled though because classes can add skills.

Is there a better way to design this?

A small example:


Dwarf has Defend skills.
Elf has no skills.

Fighter has Attack and Defend skill.
Mage has no skill.


A dwarf fighter would have Attack and 2+Defend.
Mage Elf would have none
Fighter Elf would have Attack and Defend.

Right now all this info is spread all over the place.


I can't extend the Classes ontop of Race cause each race could be any class.

Yeah, I typically will only use subclasses for the more abstract type of object: Entity, DrawnEntity, FriendlyEntity, MonsterEntity, etc. Stuff like that. Then you use data members to decide any specific functionality that is different across each.

Instead of making a different class for every single skill, you'd probably be better off just making most of them individual data members of CombatEntity or something - defend, attack, etc. sound pretty general. The sorts of things you would use subclasses for would be very specific functionality that needs its own way of executing.

One thing to consider is that you get all sorts of gameplay variety for free if you do what Orangy is describing. If the player/allies and monsters are the same class, that means that you can very easily implement a "capture" or "charm" approach. i.e. you can add any monster or player, anytime, anywhere, to your party. If you end up with an insane class hierarchy, this is not at all easy.

Usually I make everything the same class, except I give them all an integer that determines their allegiance. Then it's very simple to say if (myAlliegiance != theirAllegiance) {startBattle()} or something similar. That way you also get different factions of enemies fighting each other for free and a whole lot of fun in between. Make your system work for you!

In general, the only time I make a subclass is when I want to limit functionality for the sake of speed/memory or sanity. For example, I usually keep a BackgroundEntity separate from a CombatEntity, because it really doesn't need the insane number of stats related to combat that a player and monsters need. It also doesn't need to move, have velocity, etc. That saves me from worrying if a wall is going to start moving around for some reason, as well as adding in a lot of if (canFight) {doSomething} if (canMove) {doSomething}.

The difference between a dwarf and an elf is completely cosmetic. There is no functionality whatsoever to limit between them except for how they're drawn and perhaps some minor behavioral or stat differences. Therefore, definitely don't make them different classes!

I spent 8 hours re-writing this last night.

Right now I have:

Entity
Character extends
Player extends Character

Character is just a monster or whatever, player adds player specific functions.
In Character I have a hashmap of "attribute name" and int.  This stores basic things like health, xp, level, stength, etc. 
Basically anything that can be an int.  Works well.

Skill, Feat and Spells, etc are all objects.

Each character has a RaceID and an Array of Classes (I'm going to call them Casts to avoid confusion).

When a character is created with a certain RaceID, it'll look up all it's feats, skills, etc from a static final hashmap (but this could be stored in DB, XML, etc backend); it'll find it's info and add it.  Same when cast is added. it'll look up all it's info in the hashmap table and add it based on cast id.


This seems to work well.  The only problem is the info for Race, Cast, etc are stored in this huge ulgy static hashmap.  It works nice, but doesn't feel right.  Even if I stored it in a DB, xml or cvs, etc - I'd still have to load all this data into some type of structure I could easily access.  It doesn't really and everything uses the same info... so a static final hashmap is the way to store this info?  Seems a bit awkward.


One cool thing that I got working is that I can attach a method or jpython script to a feat/skills by a String.  So I have feat "Knockdown" that has a string called "RuleSetObject.knockdown(self,other)".  When player uses that feat it looks up that method by string name and executes it.  I'll have to see how fast jpython is, but with this; it'll be super easy to quickly add new functionality.  Also give modders a lot of flexibility since none of the actions are hardcoded, but will be stored in db, xml, etc.