Game Development Stack Exchange is a question and answer site for professional and independent game developers. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I work on a strategy game, where the player occasionally has to transform ordinary citizens into the so called "leaders". Leaders are temporary units, which the player can control directly, in order to interact with the other citizens. After some time, the leader gets transformed back to a normal citizen.

My question is if I should stick to the classical OOP approach of keeping citizens and leaders in two separate classes, whereas the leader class extends the citizen class, and every time when I need a leader, I simply re-instantiate the current citizen instance.

I personally dislike this approach, however. I already have a state machine implemented, and am more likely to keep only the citizen class (or rather, human class). Rather, I'd like to keep the citizen/leader separation into two different states. When I need one or the other type, I simply switch the current state.

share|improve this question
up vote 5 down vote accepted

Most games don't have different classes for different entity types, because it's not very flexible. Your example is a classic case of why this is so! Classical OO with one-class-per-noun is great for toy problems but not so good in the real world.

I'd suggest using the Strategy pattern, and swapping out a behaviour object that encapsulates the key differences between the two types of character, leaving the rest of the entity unchanged.

share|improve this answer

With a components-based entity system, you can simply do

if (citizen.leaderComponent)
    leaderComponent.update() //...or ".processLeaderDirectives()", or whatever.

Obviously this leaderComponent has references to whatever it modifies, such as group state/motivation tables or whatever. So it is a data member of every Entity, but is only non-null if the citizen is a leader (i.e. you've assigned a leaderComponent to this Entity). Think of it like a leader hat. Anybody can wear one, but only the bigshots wear the stovepipes.

share|improve this answer

You can add a flag for the citizen to know if it's leader or not.

And you can separate the Logic/IA and made Behaviours, this way units can behave in different ways easily.

There is technique called Behaviour Trees, but maybe it will be enough for you encapsulating the state machines.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.