Enemy class hierarchy

Game Play & Game Design
#1

Hi! I’m creating a game where I’m planning on having multiple types of enemies.
Lets say I’ll have giants, dwarfs, humans (both melee and ranged), basic flying type enemies aswell. Thier AI will be controlled with FSM.
What’s a good way to design the class structure of the enemies. I’m a bit lost here.

I don’t know if it’s good or not but what I have right now looks s’thing like this:

  • Abstract enemy core class wich contains all general variables needed for the enemies (HP, stats, etc…)
  • Abstract ground type class extending the enemy core. This contains abstract methods and variables regarding movement
  • Dwarf class extending ground type. This is the actual class of an enemy containing all methods needed like render(), update(), etc…
#2

Probably not that.

Just one class for enemies. Then control different aspects of behaviour with plugins. In Revenge of the Titans, we’ve got just one “gidrah” class, and it’s controlled by a “brain” (which chooses its objectives), a “movement” which controls its navigation and movement, and optionally a “weapon” it uses.

Nav and movement are controlled again by separate plugins for different sorts of movement - we’ve got two basic sorts in RotT - “ground” movement with A* pathfinding, and “flying” movement which ignores terrain.

and so on.

General takeaway: composition using interfaces rather than deep class hierarchies.

Cas :slight_smile:

#3

Composition is key whether you do it explicitly (traditional OOP / what Cas is doing) or implicitly (component architecture). The latter has also been called the Entity System Architecture or Entity Component Architecture when used in a game context for entity systems.

Creating an entity system via inheritance (traditional OOP) which is the direction you have originally taken is a nightmare eventually unless your game is simple and well defined. Big problems occur when you want to copy or have the same behavior shared between unit types that don’t directly descend from the same parent. The nasty hack / anti-pattern that then rears it’s head is the god object as one pushes up to the base entity class more and more functionality that is potentially shared between various branches of unit types.