Decoupling AI from game logic

Question

Imagine a game with different types of characters or "actors" which can perform actions like walking and shooting. They are implemented using the state pattern to reduce the amount of coupling: each actor has a current state which can be one of the different possible state objects like DefaultState, ReloadingState or StunnedState which determine what happens when its methods like Reload(), Shoot() or Walk(direction) are called. Every frame the current state object updates the actor and returns the next state.

This works great for the player who doesn't need to know anything about the internals. However, an AI controller needs to know its character's current state to make intelligent decisions. For example, in the DefaultState the AI character would walk towards the nearest enemy while in StunnedState it would flee. It seems like every state should have its own AI routine, but how should this be implemented while trying to keep this logic separate from the actor class? The AI could query the actor for its current state and decide its actions based on that, but that would result in a bloated and messy if-else block. The State class shouldn't know anything about the AI so it cannot be in charge of changing the AI's state either. How can I implement an AI which chooses different actions based on the actor's current state while maintaining loose coupling?

Answer 1

A design pattern I've enjoyed using has two types of things: task management and task execution. Task management asks the question "What should I be doing right now?" And task execution asks, "How do I complete the current task?"

Task Managers

The job of the task manager is to constantly look at the AI's internal state (read-only) to determine whether new tasks should be assigned. Tasks have priorities, and are placed on a Priority Queue when assigned. Tasks are also unique, so that an agent can't be assigned exactly the same task twice.

For instance, the Task Manager could constantly be checking to see if the agent has sensed any new enemies that must be attacked. If enemies are sensed, it adds high-priority DestroyThreat tasks to the task queue.

When the agent is done with the current task, it pops another one off the task queue. Task managers can also pre-empt the current task by putting it back on the queue if an extremely high priority task overrides the current task.

Task Executors

Your agent will have several actions which are merely functions, bits of behavior tree, or states in a state machine. Every action can either fail, or succeed. These are implemented inside the AI agent itself. They should be atomic (like "play animation" or "attack entity").

The task executor will simply tell the AI agent what actions to take given a current task. It does not need to directly know about the agent's state, but only the return values of the actions the agent takes. The executor can either fail the task, or succeed, based on whether the current action fails or succeeds. If the task fails, it is either put back on the task queue or is destroyed, depending on the desired behavior.

Answer 2

Depending on the language you're using use a virtual function, a function pointer, or a delegate for your actor's "do something" function (some engines call it Process() or Update() )

in C++

class BaseAI {
protected:
  //...
  virtual void ProcessFrame() = 0;
public:
  static void ProcessAIs(); // this call the ProcessFrame of all existing BaseAIs

  //...
};


class Monster : public BaseAI
{
protected:
  void ProcessFrame() {
    // do monster stuff
  }

  //...
};

class BigBoss : public BaseAI
{
protected:
  void ProcessFrame() {
    // do big boss stuff
  }

  //...
};

That's what function pointers / virtuals / delegates are for.

Answer 3

create corresponding states for the AI. for example:

AIDefaultState, AIReloadingState , AIStunnedState 

you can inherit from the normal states if seemed logically correct in your situation