top of page
Writer's pictureHolly Boyle

Enemy Design & AI

One of the larger aspects of the project I was tasked with designing and implementing was the enemy AI.


I started with setting up a base enemy actor, one that could follow a basic patrol routine and receive damage. For all of the AI in the game, I made use of Unreal's behaviour trees to control their, well, behaviour.


I tried to be conscious of how any level designers on the team might want or need the enemies to behave before player interaction, so I tried to give a variety of options for enemy patrols. They could remain stationary, randomly explore a given radius, or follow a set path.



For the three main types of enemies we would end up designing for the game, we made use of a set of character asset packs from the Unreal Marketplace: Enemy Goblin, Enemy Orc, and Golem.


We made the decision to use these since we only had one dedicated asset developer on the team, and it would be far too much work for them to model, rig and animate the different models.

The character assets we did use had the advantage of being compatible with Unreal's default humanoid skeleton, which meant we could easily retarget other animations to them.

 

Goblins



The first proper enemy to be implemented into the game was the Goblins. As a team we had discussions to try and decide on what the desired behaviour for the goblins would be. We all agreed that they should have relatively low HP, but as a result usually would be found in groups throughout each level. Individually they would be just a nuisance, but with multiple they would pose more of a threat.


In terms of their attacks, I felt it should be kept simple, seeing as they are meant to be the most basic type of enemy. They would have a quick up-close melee attack, and a mid-ranged spit-ball attack at distances.



For the melee attack's hitboxes, I attached a small capsule collider to both arms in the actor, and disabled collision on them. Then using animation notify states, the colliders are re-enabled at the appropriate timings on each attack animation.


The spit-ball attack was done with a similar animation notify, which spawns the projectile slightly in front of the Goblin's mouth. The projectile itself was created by modifying a water particle-effect from the same asset pack we used for our magic effects.



With the attacks working individually, I quickly put together a behaviour tree to see how the Goblins would work in-game:



As you can see in the video, I added some floating damage numbers for when the player attacks any enemies. The aim of this was to provide more feedback to the player on how much damage they are dealing.


From testing this prototype version of the goblins, we found that groups of them using their ranged attack all at once would probably be a bit overwhelming for the player. While their melee attacks can be interrupted by hitting them, at a distance it isn't possible to interrupt their spit-ball attacks.


To remedy this I started experimenting with the idea of dynamically assigning melee or ranged attack roles within groups of enemies like this. This way we could limit the number of ranged attackers to a specified ratio, like 1 ranged per 3 melee enemies.


I set up the goblin's blueprints so that they would determine their role upon first detecting and chasing the player.


Improving Hit Reaction / Feedback

A common piece of feedback we received from our playtests was that there wasn't enough weight or response to the player's attacks when hitting enemies. While I had tried to partially improve this with the floating damage text mentioned previously, I had a few more ideas to help with it.


The first was adding a proper

I went into the Goblins' material code and added a new colour multiplier controlled by a new parameter. By making a dynamic material instance in the Goblin's own blueprint, I could use this parameter with a timeline to create a quick red flash effect upon taking damage. I think this makes it extremely clear to the player when they have damaged a particular enemy, and since our game is going for a very stylized art direction, I think it fits well visually.


As a result though, I did end up going back to adjust the floating damage text's visuals, adding an outline to the font since they would otherwise blend in with the red flash.


 

Orcs


In contrast to the Goblins, we knew we wanted a tougher, larger enemy that would usually be fought individually. Apart from this general idea though, we hadn't really settled on how we wanted the Orcs to act in game for a large part of development. For a while, I had just set up their animation blueprint and behaviour tree similar to the Goblins, and had them use a basic melee attack when close to the player.


The main feedback we received based on our presentations then was predictably that there wasn't enough to differentiate the Orcs and Goblins in combat. If anything, Goblins were the more interesting enemy, since they could alternate between melee and ranged attacks.


When it came to acting on this feedback, I was also looking for ways to make the combat of the game more interesting in general. The optimal strategy in most encounters was usually to just repeatedly hit enemies, which would become quite dull after some time. I wanted the player to have to think more about movement, and potentially make use of other options for attacking rather than just using their sword or magic.


With the only relevant stat to combat being 'Health', there wasn't much room to incentivise other strategies. The idea I had then was to create a second stat for larger enemies like the Orcs, in the form of a 'Stagger' meter.


The Stagger meter starts empty, and builds up with every hit the player lands on the enemy.

When it's completely filled, the enemy enters a staggered state, where they remain stunned for a short period of time and take additional damage.


With this mechanic added to the game, I could have the Orc's regular attacks be uninterruptable, forcing the player to move about and dodge their swings, putting more thought into when to get close and attack. However, eventually the player can still build up enough stagger to create a window to focus entirely on their own attacks.


As you might also have seen in the video, alongside the stagger mechanic I added a throwable glass bottle for the player to use against enemies. The idea is that, while it does very little damage, it builds up a significant amount of stagger, providing another option for the player to make use of in combat. I had originally planned to add a larger variety of items like this, but due to the time constraints we were under for the project I didn't have the time.


Adjustments

As part of making the Orc's attacks uninterruptable, I put a lot of effort into making sure they felt well-telegraphed and fair for the player. The base animations that I was using were too fast to properly react to, so I spent some time adjusting them in new Animation Montages.



I also had to spend some time in the Orc animation blueprint, trying to figure out a way to blend in their hit reaction animation without interrupting their current attack animations.



I ended up making the blend weight value into a variable, as from testing I noticed that in some cases, the hit reaction animation blending with attack animations could cause the attack's hitboxes to move significantly off-course, often missing the player entirely when they would otherwise have been hit. By making the value a variable, I could use animation notifies during important parts of each attack animation to disable blending the hit reaction entirely.


Magic Interaction

Since a large part of the game's core was its magic system, I wanted the enemies to have more interesting and strategic interactions with different types of magic. One example of this that was actually implemented was using the heavy ice attack to freeze enemies:



Unfortunately, since the heavy attacks for magic ended up not making it into the final version of the game, this mechanic didn't make it in either. I had other ideas for magic interactions, such as a heavy fire attack that did damage over time, but in the end other features took precedent as we came towards the end of development.


Looking back, I do regret to being able to spend more time on working the magic into the combat a bit more.



6 views0 comments

Recent Posts

See All

Kommentare


bottom of page