Changing game object type: reinstantiating the object, or switching an object state

Question

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.

Answer 1

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.

Answer 2

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.

Answer 3

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.