-
Notifications
You must be signed in to change notification settings - Fork 0
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.
- Player UI
- Popup Menus
- Obstacles
- Boss Enemies
- Progress Tracker
- Checkpoint Design and Functionality
- Score System
- Lives System
- Game Background
- Multiple game-level
- Visual Improvements
- Tutorial Level
- Character Design and Animations
- Character Damage Animations
- Player Animation Functionalities
- Player and Serpent Portal Transition
- Pop-up Menus
- Obstacles
- Lives & Score User Testing
- Buffs & Debuffs
- Buffs & Debuffs redesign
- Obstacle Animation
- Background Design
- Level 2 Background Appearance
- Enemy Monster User Testing
- Level 1 Floor Terrain Testing
- Introduction Screens User Testing
- Character Movement Interviews & User Testing
- Sound user testing
- Level 2 Obstacles and enemy
- Story, Loading, Level 4 and Win Condition Sound Design User Testing
- Giant Bug and Purple Squid animation user testing
- General Gameplay and Tutorial Level User Testing
- Level 4 Terrain User Testing
- Game Outro User Testing