Hello Sanctuary seekers,

Today I'd like to talk about AI.
I'm going to run through, at quite a high level some of the AI implementation, specifically the zombie enemy type currently in the game and their idle wander loop but this generally gives an insight into how AI currently works in After Sanctuary.

If left alone, the zombies just idle and wander within a range.
This post pertains to the zombies found in interior scenes (more in another devlog) and only covers this idle wander loop.

Zombie do idle, zombie do wander. Repeat.

Lets get started.

All AI types currently use a finite state machine (FSM) to power them.

I call it a controller because a state machine isn't enough for what I'm trying to achieve.
All AI need to keep some information regardless of the state they are currently in, such as the last time a player was seen in order to make a decision on what to do next.
The state machine (controller) I'm currently implementing does just that and allows for more realistic decision making because it provides context.

It's not just a dedicated FSM which could be a good thing or a bad thing depending on you're own perspective and programming practises.

I'll leave that there...

The AI have states such as idle, random wander, chase, search, attack, die etc..

Not all AI types have these states. Some do, some don't.

Some AI types have different states.
All states are reusable across different AI types if needed.

I'll cover the idle/wander loop for the zombie AI today at it's most basic level.

There's more going on here than I'm going to cover in this devlog.

All AI have sensors attached to them so they can get a representation of the environment and what that contains.

The zombie AI have a visual sensor so they can find the player and a hearing sensor so they can hear noises such as footsteps, doors opening, gunfire etc.
Each sound that is emitted by the player or other things in the environment has a range, sound type (weapon, generic, UI etc), is it in 3d or 2d spatial space, are the AI privy to this sound and should they react to this? (for example, UI sounds, never). Footsteps yes, if they are in range to hear them, amongst other options.
It's very robust and when I read back through the code it's my favourite thing in the world

All AI have the above but the Zombie AI should not be too clever.

Lets see some code!!

Firstly, We define a BaseState class which all AI states can inherit from.
This lets us create all of our states based on this class and whatever we pass the state into will be agnostic to the type of state and everything else that has to follow (AI type etc).
It's almost a blueprint for the most basic boilerplate code rather than a contract each AI type has to adhere to.
It's designed to be consistent but not each state will need all of it.

All methods need to have an implementation so they aren't absent when called by the controller but they can perform no operation and it's all fine.

Loading...

The only parts that *should* require further explanation are LogicUpdate() and PhysXUpdate().

These are fired from the controllers Update() and LateUpdate() methods respectively to give more control within the state itself over timing.

Maths in logic, physics in PhysX...

We have all the methods we currently need and a constructor at the top where we can pass in our controller.
Different AI types have a different controller, all inherited from the baseController class.

Loading...

Not every controller will need to try to find a random place in the level but hey, We're talking about idle/wander loop here so it's fine for this example... possibly

Lets take a look at the idle state, step by step at its most basic level.

Firstly, we declare some variables and a constructor.
most are self explanatory.

The constructor allows us to pass in our controller so the state can access it and any public variables and methods it contains.

When we enter the state, set a random idle time between the idleTimeMin and IdleTimeMax variables.

We also tell the controllers AgentMover to stop moving because we're idle...

The Agent mover(controller.mover) handles navigation from one place to another, movement speed, and animations so we don't have to worry about it in a state.

We can give the agent mover a speed if we like but in this case the mover knows we are not going to move so it handles it rather gracefully and sets it to zero all on its own when we call controller.mover.Stop().

The LogicUpdate() runs every frame and is called from the controllers Update() method.
In here, we increment the timer variable by the amount of time that has elapsed between the current frame and the previous frame.
If we go past our timeToIdleFor, we ask the controller to change to the wander state, as is our want after the zombie AI has idled for an appropriate amount of time.

The controller calls Exit() on this state and starts the new wander state.
The Exit() state exists to clean up before we transition.
It will be called on the controllers current state to provide a means of cleaning up each time we transition to a new state but on this occasion it's empty and contains a //noop (No Operation) comment and as such is not worth showing.

The wander state:

We set up variables for a min and max wander distance and also how many times we should retry if our A* system is failing to find us a path.

When we enter the wander state, we set the controller speed, subscribe to an event provided by the AgentMover class so we can take action when we reach our destination and ask for a path.
If we get a valid path we move to it.
If we don't we try again.

Once we reach the end of the path, the AgentMover fires the OnArrived event and we ask the controller to change the state back to the idle state, thus completing our loop.

This is very basic and doesn't include sensor code, the way a player is seen or a noise is heard or anything else that completes the AI, more about that in future posts.

Until next time,

Stay safe.