4 Hugues Ross - Blog: Capstone Update 14: The blog post where I actually discuss monster AI
Hugues Ross


Capstone Update 14: The blog post where I actually discuss monster AI

This past week, our team took The Last Light to an expo in Montreal. By all accounts, it went well, but the work leading up to it was intense. I'll probably be taking things a bit easy, given that I spent 17+ hours working on the project last week.

One of the big things that I worked on last week was the monster AI. We now have a rough sketch of the AI implemented, and in the first level. I'm going to go through a quick rundown of the behaviors here, and what I plan to add in the future.

The Monster is based on a basic finite state machine, currently containing 4 states:


 This is the default state for the monster. Currently, it chooses a random location within a small radius that isn't illuminated and that it can see, then goes there and repeats. This was implemented before I received the full designer spec for the monster, so it differs somewhat from their design for the moment.

Their system has the monster moving randomly between predetermined points, with a bias towards the player's position. This is partially implemented, but the waypoint EQS generator is still WIP.


Previously, the player would die if they stayed in the darkness too long. Now, we have a more concrete and visible threat in the monster. When the player strays into the darkness without a light, the monster is alerted and enters a seeking state.

In this state, the monster finds a direct path to the player and chases them. If the player is caught, they begin to rapidly lose health, shown by a post-processing effect. Their health will regenerate after a few seconds of safety, however.

Currently, this is a pretty dumb state. Because the monster uses UE4's default pathfinding, it finds the most direct route. However, this route usually passing through includes light, which harms it. I haven't decided how to handle this yet, but I'm considering both navigation modifiers and custom navigation. Only time will tell.


 When the monster is lit and begins to take damage, it retreats. This is done using a simple pair of EQS tests on top of the same generator used for wandering. The tests A. ensure that the monster won't be moving into light and B. Heavily favor locations that are more distant from the player. The result is a behavior that feels 'right' when the player shines a light on the monster.


The monster takes damage from light, so if it spends too much time lit up it will enter a dead state. Once 'dead', it disappears for a few seconds, before reforming and continuing with what it was doing.

One major thing that needs to be done still is making it move in this state. It seems counter-intuitive, but by making it move as if it were fleeing, I can ensure that the monster won't reform directly on the player or inside a light.

My Goals

I've explained all the monster work that remains, but I also have some other goals for this coming week, mostly focused on graphical improvements.

First off, I need to improve the damage effect. Right now, it's not quite "in your face" enough, which probably makes it difficult for new players to realize that they're dying. Some additional blur, contrast, and color tweaks should hopefully make the player more aware of what's happening.

After that, I need to work some more on the interaction shader. Currently, it works well, but the designers have requested more control over it, such as color and width options. I'd like to get that done soon so that they have more time to play with it.

I don't expect to solve the pathfinding issue just yet, but we'll see.

No comments: