AI movement and spell progression

Like I said at the end of my last blog post, I decided to attempt to mix two sprints into one and have twice as many objectives but double the timeline to complete them so I can add variety to my work. Doing this I found my motivation had slightly improved as I would get invested in the start of developing a feature but I was splitting my focus I felt development may have been affected. However, I feel like I had a similar amount of success in developing these features. As I feel like I may have lost some motivation towards the end of this sprint I will probably go back to the week-long sprints as I felt like this suited me better so I can keep working away at this project.

One of the features I worked on in this sprint was the AI’s movement, I wanted

to have an enemy that would have simple behaviour as this is supposed to be a demo of the spells/abilities I am creating and the AI is meant to be used to demonstrate this. However, I did want to play around a little bit with how they work.

I wanted there to be two types of enemy AI so they can emulate an encampment of soldiers that the player will come across when exploring the environment. To keep this simple I wanted to have one AI that would patrol a route and one that would stay in place to emulate either a soldier taking a rest or being stationed somewhere. I did this by having a boolean that would tell the AI controller whether they would be moving or not. I set out the patrol route by creating an actor that would signal to the AI when they are overlapping them to tell it to start moving to the next actor in an array I set up.

When they see the player they will spring into action. I wanted to have a system that wouldn’t overload the player so I followed something I saw in a GDC talk about the combat in Doom (Find a link) that talked about basing what enemies would close in on the player on how the fight scenes are set out in martial arts films be having at most two combatants close in. This would make it so the player has to worry about two enemies at once, maybe three if I have time to add ranged enemies. Setting this up in the AI’s behaviour tree I wanted to use the EQS system to create points around the player that the AI will move to. The AI will move to the closest point to them but not if that point is already taken by another enemy. I actually created two of these circles of points, one being in range to attack the player (only two enemies will go to these points) and another further out to make it seem like the player is taking on a larger group when they only have to focus on two enemies. This would play into the power fantasy I wanted to create with the player.

Screenshot the points that the EQS system creates around the player. With the green spheres being more valuable and red being the least. The AI will move to the highest value point they can.

To finish the AI I want to fix a problem I’ve seen they will switch to patrolling/being stationary again as soon as they lose sight of the player. I want to add a cooldown to the boolean that is based on so they wouldn’t turn away instantly, plus I want to have the point the AI moves to around the player to update as the player moves so they will stay around the player. I also need to add a stun function to the AI so the player can stun an enemy to control the combat more. The last thing for the AI I would add is to find an asset pack online and assign meshes/animation to the AI for polish, to make the final piece more presentable.

This week I decided to expand on the spells I created last sprint by adding in some visual progression based on the attribute that’ll be assigned to the spells. I want to have a system similar to D&D and Elden Ring where the character attribute scores affect how much damage they do with certain weapons, I wanted to have a similar system but with the spells, they can use but I also aimed to have spells the player can unlock once an attribute reaches a certain level. I set up the change in the particle effects from the spells based on the attribute value the player has. I used the Niagara System and the variables you can set the values of size and spawn rate to be set on spawn when the player uses the spells. This would increase the size and amount of particles spawned. I wanted to have this progression so the player will feel like the spells do more damage based on the visuals and encourage the player to invest in the attribute.

I also added some functionality to these spells so they can deal damage. I wanted to little bonuses to how much damage the player does with their spells based on milestones of getting the attribute to a certain again to encourage the player to invest in upgrading the attribute which I need to add a system of upgrading spells/attributes with some kind of points. I needed to demonstrate that the player was dealing damage so I added a simple health bar that is displayed above the enemy, the way I set it up how it’s displayed is be drawing the widget on the screen so I should limit the visibility of this to how close the enemy is and if the enemy is on screen so it does look like a rock that between the player and the enemy has its own health bar.

Lastly, I made changes to how the lock-on system works. Previously, the player could change who they are locked onto by pressing the same button they used to activate the system. This would probably result in the trying to get out of combat to just lock onto another enemy unless they get through the entire list of enemies. This list would be set up by what enemies have entered a radius around the player but it would be in the order they entered this range and the player would lock onto the first enemy in this list, which obviously I needed to change as it could confuse the player.

To change who they are locked onto I made it so the player would only need to move the camera left, for targeting the next enemy who is counterclockwise and right clockwise. Functionally this is done with an arrow component that will rotate with this input and when it

reaches a 10 degrees difference in rotation it will activate the switch, and switch to the

enemy that is at the closest angle. It would then reset the rotation of the arrow component. If there is no other enemy it would just reset the arrow component.

Since the player would cycle through the enemies that have entered the range the player can lock onto the enemies in the order they entered that range it would start by locking onto the first enemy that entered that range (unless they have left this range). This obviously could cause issues with the player as they could be looking at one enemy to turn and face one directly behind them. Using the same function as switching the lock, once the player activates it they will lock onto the enemy that is closest to the direction they were looking at. These changes would make it easier for the player to choose who they lock in.