How should I handle animation state systems in derived classes?

Question

I'm trying to get some kind of state system for my game objects.

I have a base Actor class that is derived by classes like Policeman, Informant or Brawler. Each of those classes describes different functionality, but I want as much of the functionality to be shared.

On of those is animation system. Each class has their own states (for example Policeman has Walking, Shouting and Shooting, while Informant has Idle and Whispering).

What is the best way of handling such states? Do I have the Actor class have something like

enum ActorState 
{
state1,
state2,
state3,
...
}

And just map each behaviour of appropriate actor (Policeman, Informant, etc) to ActorState, so that the rendering system of ActorState can take over?

Or maybe is there some better solution that people use.

Game is 2D, sprite based, and I'm using Unity3D system, with Actor being a component to GameObjects.

Answer 1

I have a base Actor class that is derived by classes...

This design goes completely against Unity's design, unfortunately. If you try to use a large class hierarchy within Unity's system, things are going to be very difficult. Unity chooses to use composition over inheritance, or has-a over is-a.

To build unique objects in Unity, you should prefer to compose components, rather than inherit functionality. This makes functionalities reusable, independent and focused. Look at what you have in your monolithic classes and see how they might be split up. For example an actor may be broken up into these components:

-Move( could be an interface to a *movable*, meaning any type of movement can be "plugged" in. )
-Health( keeps a health count. )
-Respawn( may respawn after health reaches zero. )
-DamageOnCollision( may damage enemies or players etc on collision )
-WeaponUser( may provide functionality for using certain weapons in some ways. )

Seeing this, you can compose different game objects. I apologise if you are already doing this, your post just made it seem as if you're not.

Now, there is a huge problem with this. The things I listed above describe only one state. We don't want each component to check what state the object is in because then it ties that component( which is meant to be independent ) to a particular game object and destroys it's portability between objects. So, how do we communicate state changes?

What I've done in a project I've been working on is create a state machine component. This component simply holds a dictionary of states with the key being the state name. What does a state hold? A state holds a list of all components that will be active while that state is active. So, when we transition from one state to another:

-Disable all components that are in the old state but NOT in the new state.
-Enable all components that are in the new state but NOT in the old state.

For this to work each component must strictly follow these rules:

-OnDisable must do any clean up to make sure it no longer has any effect on outside objects.
-If a component is disabled, it should have NO effect whatsoever.

Using these rules, a component can be enabled and disabled on state transitions and work correctly. A serialized list or dictionary can allow you to drag and drop each component into a state to allow this control from the editor.