# Making specific Enemy Classes

So I was just looking through an old game I had made for android, and was second guessing how I was sub-classing enemy for each particular enemy in my game. My enemy class had all kinds of properties, like sprite speed size and different bools that related to the state of the enemy...etc. But then for each enemy in the game I created a sub-class from enemy, and all I did was set all those properties to a specific value. Something like this:

public class Ninja extends Enemy
{
public Ninja(Vector2 pos)
{
super(pos);
this.speed = 10;
this.sprite = Content.Ninja;
this.size = spriteSize.Medium;
this.hitPoints = 200;
//..etc
}
}


That was basically the whole class. Looking back it seems like a waste of making a class at all, it left me with nothing else to change about that enemy, but just a convenient way to declare them. Is this common practice? I suppose it is nice to have all these stats grouped into 1 place, but it seems like a small amount of information to have for a whole class, maybe I'm just over-thinking this. Does anyone else ever do similar things in their games? Maybe it would be better to just make a static method somewhere that generates a Enemy with these stats called like CreateNinja, and save myself the clutter of having a whole class for it. What do you guys think?

• You want to be more worried about how early design decisions will affect your ability to create new enemy types and customize them later, and not so much about how it seems like a lot of overhead right now. – Patrick Hughes Nov 15 '13 at 3:44
• This is pretty common. Instead of writing it as a class, write it as data (eg. text file) and viola, you have a "data driven" architecture. – ashes999 Nov 15 '13 at 4:27
• The data-driven approach is much better, unless there's a compelling reason that a new enemy type needs to be a different class, just have an Enemy class. Assign parameters such as sprite and name to that class. That way you can configure all your enemies in a config file and you don't have to rebuild your whole project because you tweaked an enemy's parameters or added a new enemy. – Foo Barrigno Nov 15 '13 at 12:08

Generally, you extend a class so you can override its methods. Suppose Enemy has a goToPoint method that moves the object in a straight line at a constant speed. You want a Ninja to disappear from its current position and reappear at the appropriate point. In this case you want to override this method, and creating a Ninja class that extends Enemy makes sense.