This week we want a playable prototype level to present to the panel.

To do this we must complete the following:

  • Polished combat mechanics
    • Attack
    • Block
    • Dodge
  • Boss AI
    • Basic AI development
    • Following player character
    • Jumping at player character when in range
  • Damage calculation, collision
  • Level zones, functional Hell-evator (teleportation upon collision with a ‘door’)
  • Boss battle mechanics
  • HUD
  • Text interaction, basic conversation

Initially I will be responsible for the Boss AI and I will pick up more responsibility as I complete more tasks.

The Boss

The Boss is a huge, Frankenstein frog in a circular classroom environment.

toad01(Lexi Townsend, 2017)

He will be programmed to chase the player character around the stage and jump on them when in range.

Our producer told us that the lumbering sort of feel we were aiming for in the boss fight is inspired by King Bob-omb in Super Mario 64.


I spent some time considering how the movement should be constructed and I looked at footage of King Bob-omb’s battle for ideas on how to breakdown and program the movement incrementally.

Option 1)

To produce the incremental movement King Bob-omb appears to have and to simulate a frog-like ‘hopping’ effect, I first considered coding ‘steps’ of movement.

If Boss is NOT in range of player:
 – Allow each ‘step’ to be a movement towards the player character at a given velocity (where each step is as long as its timer allows it to be)

If Boss IS in range of player:
 – ‘Jump’ towards player character (target landing to be on player character’s last known location before movement was triggered)
 – Assign ‘jumping’ animation

Option 2)

I realised that the first option was very inefficient, repeating the first ‘step’ movement over and over. This same ‘hopping’ effect could be achieved by an animation.

When I observed King Bob-omb closer I realised his movement appeared ‘stuttering’ because his steps were so small compared to his overall size. His stride length was around the same size as Mario’s, but his huge body made this movement seem like a shuffle.

With this in mind, I devised a second, more efficient, strategy.

If Boss cannot see player:
 -Turn until player is within Boss’ range of vision

If Boss is NOT in range of player:
 – Let either step size be small or time taken per step be long
 – Assign a ‘hopping’ animation (frog equivalent of stock walking animation)

If Boss IS in range of player:
 – ‘Jump’ towards player character (target landing to be on player character’s last known location before movement was triggered)
 – Potentially create a shadow where the Boss aims to land
 – Let timer be relatively long to allow player to escape from under the Boss


AI following Player Character (3 hours)

Initially, I wanted to code this behaviour to a simple sphere in order to showcase just the boss mechanics. However with further research I realised I required a pawn with an event graph to map these behaviours to. Following a tutorial online, I duplicated a player character pawn and began repurposing it as an AI.

I began by deleting the pre-existing nodes and key mapping, and also deleted the camera actor and ‘FollowCamera’ in Viewport.


Once a ‘pawn sensing’ component is added, the green lines represent the AI’s peripheral field of vision (this value can be changed to create a more realistic cone-like shape).


The next section implements some basic functionality on Blueprint for the AI.

“Upon sensing -> (the player character) -> move AI towards the target actor (let the target actor be the player character)”

To create the PawnSensing ‘OnSeePawn’ node, it is imperative that the PawnSensing component is selected in the components list before searching for the node on the blueprint.

pawnsensing node.PNG

Now the AI will proceed to chase the player character as soon as the pc crosses into its field of vision.

A problem I encountered while playtesting is that because field of vision is a cone shape, it is very easy to pass in and immediately out of the AI’s field of vision when standing very close.

  • I halved the AI character movement speed from 600 to 300. This helped immensely with the problem I was having with running in and immediately back out of the AI’s field of vision.
  • I expanded the AI’s sight radius, as I found when playtesting I could run outside of the AI’s sight radius too easily (separately to its cone of peripheral vision).

TIP: To create an area for the AI to move in, select Volumes > NavMeshBounds.

Searching for the Player Character  (1 hour)

Whenever the AI ‘lost sight of’ the player character, it froze in place. To combat this, I made the AI rotate on the spot to ‘search’ for the player character to re-trigger ‘pawnsensing’ and continue following it.


  • In testing, I found that the AI ‘snapped’ its orientation to face the player character. I fixed this by using RINTERP.

Smooth Rotation (2 hours)

Initially, upon rotation the AI snapped to the target orientation. I decided to search further for how to produce a smoother rotation.

  • AI Pawn and under Components > CharacterMovement > Enable “Orient Rotation to Movement”
  • Under Defaults > Pawn > Disable “Use Controller Rotation Yaw”

RINTERP then allows for smooth rotation between two orientations.

smooth rotation.PNG

Calculating Distance Between AI and Player (3 hours)

I return a Boolean value based on a comparison between the AI (self) actor and the Player Character locations.


Jumping upon Distance Trigger (2 hours)

  • If distance is smaller than (desired distance) > trigger jump


  • After testing, I changed the ‘Air Control’ in AI character movement to 0 to stop the AI moving or rotating in the air towards the player character.
  • After testing, I added a delay on a ‘can jump’ state so that the AI does not continuously jump while in range of the player character
  • If there is no force, the AI will jump on the spot. In the future this will need to be changed for the AI to jump ONTO the player’s last known location.

AI ATTACK (3 hours)

At timed intervals, the AI boss will abruptly give up chasing the player character, return to the centre of the map and spin around in a circle at increments of degrees, firing a projectile at each turn. It will then resume chasing the player.

Returning the AI to the centre of the map on a timer was not too difficult. I created a Boolean ‘Time to Attack?’ – if found to be true On Tick, a the AI is directed to move to a given location (centre of map).

set on play


To create the rotating attack upon successful relocation, I spent a long time trying to create loops but found that Unreal does not support loops that use delay functionality. In the end, I created a ‘pivot’ function to a number of degrees and repeatedly called this function in the EventGraph.



Implementation: (calling function with delays)


After the attack is completed, the custom event “Attack Off” is called to reset ‘Time to Attack?’ to false, allowing the AI to continue chasing the player until such a time that ‘Time to Attack?’ is set back to true.

set attack

(i) https://www.youtube.com/watch?v=3GV6-4uhkYc


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s