I really don't recommend doing this. There's no reason you can't modify
CSDKPlayer to do what you want it to do. Also the whole point of subclassing
is so that you can make the subclass have different behavior, or perhaps
multiple subclasses with different behaviors. However, the aforementioned
factory problems are a good example of how it would be hard to do that kind
of thing. Even if you want different types of players with different
behaviors, it's not really worth it to go through all that work. Even for
TF2, where all of the player classes behave very differently, they all exist
in a single CTF2Player class. The code looks something like this:
int CTF2Player::GetPlayerSpeed()
{
switch(GetClass())
{
case CLASS_SCOUT:
return 300;
case CLASS_PYRO:
return 250;
// ...etc
}
}
Compared to 9 different subclasses and 9 different GetPlayerSpeed functions,
I'd much prefer the code above.
Do you have any compelling reason for making a subclass? Because otherwise
it's probably not worth it.
--
Jorge "Vino" Rodriguez
_______________________________________________
To unsubscribe, edit your list preferences, or view the list archives, please
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders
