I've been pretty curious about this. I'm working on a game and want to have a class system that is set up similarly to Team Fortress 2's.
My main question here is how could a system like this be done? Is there a main 'Player' class, and then the classes inherits that class? Sort of like class Scout : public Player? Or are there enums used to accomplish this?
It's literally just regular object oriented programming.
When you have the chance, download the Source Engine, or go take a look at the Source Engine on the GitHub.
They provided classes based on Half life, and Half Life 2. It is the wrong game, but the same engine and programming style is used for TF2.
And no. Player would not be derived from Scout as scout is controlled BY the player. Scout would be derived from Player, which Player would be derived from a base GameObject.
The reason being that Player has data that is shared by all TF2 classes.
But each TF2 class has data that's different from one another.
There's also no reason that inheritance would have to be used here... you could use composition where Player has a Class.
e.g.
struct Class
{
float runSpeed;
float maxHealth;
vector<Weapon*> allowedWeapons;
};
Class g_scout = { 200, 100, {shotgun, bat} };
struct Player
{
Class* m_Class;
float health;
};
There's also no reason that inheritance would have to be used here... you could use composition
In fact, using inheritance here will very quickly result in problems. Consider how many different things may control a given character in your local game:
If we make Scout, Heavy, etc all inherit from the Player class, then what do we do for the RemotePlayer and AIPlayer classes?
When you have the chance, download the Source Engine, or go take a look at the Source Engine on the GitHub.
That is the answer. And to make it easier, here is the link for Steam, and here is the link for GitHub. The Source 2013 Multiplayer stuff includes Team Fortress 2. They provide source and tools, all that is left is the work.
For some reason, that step ("Work") seems to be the one most people have an aversion to.
Actual player classes needn't be an actual class in the codebase. There is nothing preventing them from just asigning one specific model with a few specific set of weapons, and switch those based on what the user selects in some UI widget.
Hell, making a Scout class seems to me like heavy handed hardcoding of how the weapons/models/abilities should be distributed. You don't want that, you don't need that, and doing it in a generic way will make your life easier when modifying classes, adding, removing or merging classes, etc.
