Making a generic MovableGameEntity Class for my 2D game?

Question

Hello, I have come to a point in my 2D game ( I'm writing the whole engine myself for learning purposes ), where I need to create some kind of class that Inherits from my GameEntity class that will contain Entities that actually move somehow in my game.

For example, that class ( MovableGameEntity ) could contain an enemy, so it would have to be initialized with the Sprite Sheet movement frames for that particular enemy, and somehow the atributes for that enemy, like "Energy", "Speed" , "Strength" , "Defense"..etc . But that class could also be the one that contains some kind of animated projectile thrown by some enemy or my main character, or a big falling rock, etc.

I'm trying to figure out if this approach is fine, and if it is, try to make it pretty generic, maybe "data driven", but wanted some insight or advice in how to do so. I don't want to end up with "Enemy1 class" "Enemy 2 Class" ... "Enemy N class" , etc etc.

So any kind of advice or experience if someone already did something similar, is pretty welcome.

Answer 1

So it sounds like you want to have a single GameEntity class that can represent many different Entities -- bullets, enemies, etc.

But, wisely, you don't want to end up with EnemyGameEntity and BulletGameEntity, because as it turns out that's hard to work with.

I've used the Strategy Pattern here in the past.

In other words, rather than using inheritance, I would probably make a single GameEntity class that holds a reference to an IEntityStrategy (or IEntityType, or whatever you want to call it). The GameEntity then passes most of its method calls off to the private EntityStrategy object (which encapsulates the unique behavior of a given Entity), and you get very dynamic behavior.

So for instance, let's say it's time for the GameEntity to move. You call GameEntity.move, and then the move method calls .move on its internal IEntityStrategy. In this way, a single GameEntity class can handle all your actors, and while an enemy might always move directly towards the hero, a bullet will always continue on a direct path -- the EntityStrategy controls that.

You might also end up creating a Factory class to configure your GameEntities.

In an RPG, maybe you wwould end up making calls like this:

ThisEntity = EntityFactory.Generate(EntityTypes.Orc, 5)

Where 5 is, for instance, the creature's level. The factory could level the Orc up, generate a name for him using the orc naming scheme, and do whatever else you want. Using our example above, it could configure the orc to use the movement scheme of Movement.AggressiveAttacker, and so on.

You mentioned being data driven. The EntityFactory could tie into a database to configure the Entities, or an xml file, etc.

Answer 2

You are right to want to avoid having a specific class for each enemy.

To design the class, you have to ask yourself what information you need to know about a particular enemy. But ask it from a programmatic standpoint.

For example, what information does the graphics engine for you game need? Thoughts off the top of my head: location, movement state (for sprite sheet), type of enemy (again for sprite sheet), more?

What information does the physics engine need? location, speed, direction of movement (note, the physics engine might be very simple ala nethack)

What information does the combat system need: stats, weapons (inventory?), skills

What information does the AI need: attack/defend/run away

Build the class based on the different pieces of your program that will be interacting with it, and what they need to know.