Player classes like Support,Heavy and Medic

How should these be handled?
Should there be a subclass that extends Player or should Player hold an object that says which class it is.

Player {

private SubClass class = new Heavy();
void render() {
renderImg(class.getSprite().getImage(),some coords);
renderImg(class.getWeapon().getImage(),some coords);
}
}

I’m looking for a neat solution in the longrun.

Extending is the way to go, no checks to write like, if class == heavy deal X damage, if class == medic deal X damage…

Whether or not to use polymorphism via a static class hierarchy depends on:

  • how “static” your character types are, i.e. how frequently do you need to introduce new character types?
  • how much the character types have in common in behaviour and properties
  • whether you want to add new character types without rebuilding your application
  • whether you want to configure the properties and behaviour of your character types without rebuilding your application

And that all totally depends on the kind of game you are making. Polymorphism via subclassing generally is useful for decoupling the client of a type from the different subclasses/incarnations of a type, so that once a new subclass/incarnation is added, the client hopefully does not have to be modified.

However, static polymorphism says nothing about the consistency in behaviour of each subclass.
This is what the “Liskov Substitution Principle” is all about: Even if you had used subclassing it can well be that the client only depending on the superclass/interface still needs to know the specific subclasses because one or more subclasses do not adhere to the behavioural contract defined in the superclass/interface.
This is when one uses “x instanceof Y” checks in client code.

A very common example of that is with the common misconception that a square “is a” rectangle by modeling that via subclassing. Or by assuming that a circle “is an” ellipsis by modeling that using subclassing.

So, before modeling your character types using subclassing, try to first define the behavioural interface of a “Player.” What can he do (i.e. what behaviour does it exhibit as methods?) and do all possible subclasses adhere to that contract?

I’m making an online top down shooter.
Basicly I want it to have classes like Battlefield or TF2 have.
The player holds this data(excluding like sprites and collisionbox which then should be placed in the subclass(eg. Heavy):
-Team(enum, used in Room classes)
-Room
-Position(inherited from Entity)
-Connection(KryoNet)

I also have an Object map stored in Player where I store some variables. I did this because I did not want half my player class full with setters and getters. The map uses a PropertyKey enum as key.

setProperty(PropertyKey.COMBAT_LEVEL, 1);
		setProperty(PropertyKey.HEALTH, 100);
		setProperty(PropertyKey.SPEED, 2);
		setProperty(PropertyKey.AMMO, 50);
		setProperty(PropertyKey.ROTATION, 0);
		setProperty(PropertyKey.IS_CHATTING, false);
		setProperty(PropertyKey.IS_LOCAL, local);
		setProperty(PropertyKey.IS_MOVING, false);
		setProperty(PropertyKey.IS_PLAYING, false);