-
Notifications
You must be signed in to change notification settings - Fork 1
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!
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);
}
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.
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.
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.
- For collision avoidance and other steering behaviours: http://www.red3d.com/cwr/steer/
- For pathfinding, look into algorithms for generating a navigation mesh or navigation grid.
- The entire Programming Game AI By Example book is recommended if you're interested in game AI.
Testing Plans
Team 1
Team 2
Team 3
Team 4
Team 5
Team 1
Team 2
Team 3
Team 4
Team 5
User Testing
Sprint 1 - Game Audio
Sprint 1 - Character Design
Sprint 1 - Menu Assets
Sprint 1 - Map Design
Sprint 1 - Void
Sprint 2 - Game Audio
Sprint 2 - Character Design
Sprint 2 - Menu Assets
Sprint 2 - Interactable Design Animation
Sprint 2 - Levels 1 & 4, and Level Editor
Sprint 2 - Proposed Level 2 & 3 Designs
Sprint 2 - Current Game State
Sprint 3 - Menu Assets
Sprint 3 - Map Design
Sprint 3 - Score Display
Sprint 3 - Player Death and Spawn Animations
Sprint 3 - Pick Ups and Pause Screen
Sprint 4 - Gameplay
Sprint 4 - Game UI and Animation
Sprint 4 - Level Background and Music
Sprint 4 - Game User Testing
Sprint 4 - Final Game State Testing
Entities and Components
Status Components
Event System
Player Animations Implementation
Development Resources
Entities and Components
Level Editor (Saving and Loading
Multiple Levels)