AI - UQdeco2800/2022-studio-3 GitHub Wiki

Some in-built support for writing game AIs is given in the engine. The AITaskComponent (code) can be given a list of priority tasks. Every frame, it calculates the priority of each task, and runs the highest priority one. A task should be able to be started and stopped at any time, and can succeed, fail, or run forever. The power of this task-based system is that a task can be made up of smaller sub-tasks.

For example, the ghost enemy AI has the following tasks:

WanderTask with constant priority 1.
ChaseTask with a low priority if the player is not visible, but a high priority if the player is visible.

This allows the ghost to chase the player only while they are in line of sight. The wander task is made up of two smaller tasks:

MoveTask to move to a random location.
WaitTask to wait for a bit before moving again.

Note that these tasks do not need priorities, since they are run repeatedly in a sequence inside the wander task. MoveTask is also used inside of ChaseTask to let the ghost move towards the player. By splitting the AI's actions into smaller tasks, we can reuse the same code in multiple places!

Usage

Using the AI task component is as simple as attaching it to an entity and giving it the priority tasks you want it to run. It will always run the highest priority one available. For example:

public Entity createEnemy() {
  AITaskComponent aiComponent = new AITaskComponent()
    .addTask(new WanderTask())
    .addTask(new ChaseTask(player));
  
  return new Entity()
    .addComponent(aiComponent);
}

Pathfinding and Movement

The provided AI code is deliberately basic in terms of movement. Enemies run straight towards the player, ignoring obstacles in their way. If your game requires more complicated movement, refer to the relevant parts of Further Reading. Implementing a full pathfinding algorithm like A* is a challenging undertaking since the game uses physics and is not grid-based.

Behind the Scenes

Why not just use a Finite State Machine (FSM)?

FSMs can be great for modelling basic game AI, and are a common application of the state pattern in game development. Depending on how complex your AI becomes, you can quickly reach the limits of what FSMs can do. Key limitations here are:

States are very highly coupled to each other since each state contains exit logic to other states. This makes it very hard to reuse parts of the AI across different entities.
It's difficult to nest states without creating multiple FSMs inside each other. This also makes it difficult to break one state down into multiple smaller states, reducing reusability.

What about behaviour trees?

Behaviour trees are a very powerful and commonly used system for programming game AI. Feel free to implement these in your game if desired, but they have been left out of the base implementation due to their complexity.