• 15
• 15
• 11
• 9
• 10

# Best way to implement character classes

This topic is 3989 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

Hi there, i was wondering if i could pick someones brain with some actual experience with creating character classes for a strategy game. Ive been working on a 2d strategy game that involves having multiple players, each with a dynamic number of "characters" on a battlefield. I was wondering if anyone could critique my approach with this.... Basically i wrote a generic character class that will serve as the blueprint for every character, the problem though is that it seems to fragment or "sphagettify" the code when it comes to adding the character to a players inventory, like when initializing the stats for the character, settings its sprite and so forth. Would it be easier to create a static class for each type of character? (meaning instead of Ccharacter you have Cknight, Cmage, Csoldier, etc)

##### Share on other sites
Why not use Ccharacter as the base class for Cknight, Cmage, etc.

##### Share on other sites
and get rid of that silly C prefix. Csoldier is a lot less readable than Soldier.

##### Share on other sites
Quote:
 Original post by RDragon1and get rid of that silly C prefix. Csoldier is a lot less readable than Soldier.

You really should try to be helpful with your replies. If somebody likes prefixing their class names with 'C' then who are you to say they shouldn't?

@jsloan:
My two most common approaches are what GamerYZ said (use Ccharacter as a base class and then derive your different class types from that) and to use a type specifier, but that requires scripting. If you're using some form of scripting I can explain more, otherwise it'd just be confusing lol.

##### Share on other sites
Quote:
 Why not use Ccharacter as the base class for Cknight, Cmage, etc.

It's worth noting that commercial RPGs pretty much never do this. It introduces too much code into what should be data-driven. It's also an overuse of inheritance. (Consider how you would handle also supporting race.) Instead, it's much more common to have a member variable of type CClass, with different objects of CClass representing different character classes.

##### Share on other sites
Thanks everyone for your replies, i do appreciate it!

Quote:
 Original post by SneftelIt's worth noting that commercial RPGs pretty much never do this. It introduces too much code into what should be data-driven. It's also an overuse of inheritance. (Consider how you would handle also supporting race.) Instead, it's much more common to have a member variable of type CClass, with different objects of CClass representing different character classes.

I find this comment very insightful and could you possibly elaborate on this a bit more, or provide an example?

##### Share on other sites
Quote:
Original post by Programmer16
Quote:
 Original post by RDragon1and get rid of that silly C prefix. Csoldier is a lot less readable than Soldier.

You really should try to be helpful with your replies. If somebody likes prefixing their class names with 'C' then who are you to say they shouldn't?

Someone who would be more helpful if they didn't have to spend more time and effort ignoring useless prefixing.

And I agree with Sneftel. Placing information in the typename itself (where you usually can't access it) is bad mojo.

##### Share on other sites
Jsloan,

Figure out what you are trying to do first. Why is the functionality grouped? What do they share and what is not shared?

I would consider using a component system over a hierarchy for characters. Some things of your characters may only differ by a few stats and some might behave differently. If the difference is only stats or visuals, you can load these from data (make an xml or txt file for each character). If they are going to behave differently you'll need to read in that data and then do some kind of processing in code. For example, the mage can use magic bolts but the solders only has melee. Then you can read in and create and then add different types of functionality to different characters. For example the mage file would have a magic attribute. When using inheritance for characters you end up with things that don't always make sense or you limit yourself. For example a troll that does magic and melee, is he a mage or a soldier? You could use multiple inheritance to solve it but you might end up with a web of dependencies. With components you can add a melee component and a magic component. What constitutes as a component and what is a variation is up to you. For example a long sword and a short sword might both be melee components with a different range value.

##### Share on other sites
The basic idea is to prefer composition to inheritance. Let's see how it might look.

class Race{public:    vector<SpecialPower> const& getSpecialPowers() const;};class CharacterClass{public:    boolean isMagicUser() const;};class Character{public:    void SetRace(Race race);    void SetCharacterClass(CharacterClass characterClass);    boolean isMagicUser() const { return characterClass.isMagicUser(); }private:    Race race;    CharacterClass characterClass;};...{    Race elfRace = resourceLoader.LoadRaceFile("elf.rce");    CharacetClass mageClass = resourceLoader.LoadCharacterClassFile("mage.cls");    Character bob;    bob.setRace(elfRace);    bob.setClass(mageClass);}

Get the idea? Race-specific stuff is delegated to the race member. Class-specific stuff is delegated to the characterClass member.