Unreal Engine


Six weeks


Solo Project

In this project the objective was to explore third person navigation- and combat mechanics that are both interesting and flexible whilst having a focus on a fast and fluid style of action. The intended outcome of the mechanics are smooth transitions between movement states and responsive controls. I aimed to achieve fluid character mechanics which transitions easily between a combative- and a non-combative state. The character will use aim while moving, so accuracy and precision are equally important as the fast-paced movement. The process of achieving this began with the research on how the character movement controls the cameras rotation and vice versa.


UE4 World Coordinate System 

  • - Forward direction (Roll): X-axis
  • - Right direction (Pitch): Y-axis
  • - Up direction (Yaw): Z-axis



Current setting: the controller rotates the camera but not the character (on idle, y axis, and backward movement). I want the character to turn and face the direction of travel indifferent of which way the camera is facing. To accompany this logic, the controller rotation is disabled and instead the character controls the rotation of the camera. To make smooth rotation transitions, the implementation of leaning depended on the characters rate of rotation and acceleration by controller input on the Y-axis.


Pawn control rotation: the character controls the rotation of the camera when disabled. The component will revert to using the stored Relative Rotation of the component. This component itself does not rotate, but instead maintains its relative rotation to its

parent as normal and just reposition and rotates its children as desired by the inherited rotation.


Orient rotation to movement: the character will turn to face the direction of travel. No matter which way the camera is facing, your character will always face the direction in which it is moving.

Controller desired rotation: the character will orient the direction of the controller rotation. In most games, this is visually represented by the direction of the camera so the character’s back is always to the camera and it rotates to match when the camera is swung. You can decouple your camera from the following control rotation so a more accurate description is that the character will face whichever direction the controller input is pointing.


The core functionality is located in the character blueprint and these values are used to control the animations. The character blueprint performs updates on values (i.e the controller input and variables such as speed and yaw direction) which are called and set in the animation blueprint event graph. This blueprint perform updates to the values which are used in the anim graph to drive the state machines, blendspaces and anim offsets. The anim graph is used to evaluate the final pose for the skeletal mesh. To achieve smooth transitions between the movement states, different caches are saved,

combined and blended per bone.



The launch mechanics are created by creating an anim montage from an animation which are then combined with the state machine using saved caches and blended per bone in the anim graph. This is used to combine lower, and upper body animations and can be called indifferent of the current movement state.


Pictured are the state machine which controls the jumping mechanics. This state machine primarily checks the values of the movement speed, is in-air (jumping) and the time remaining ratio of the animation for its transitions.


Pictured are the state machine which controls the movement mechanics. This state machine primarily checks the values of the movement speed and direction, and which foot is forward when coming to a stop. The latter condition is checked by using anim notifies inside the animations. The anim notifies are called in the anim graph and are set by a boolean value.


Pictured is an animation with notifies which facilitate setting up events to occur at specific points during an animation sequence. These notifies are added to determine when footsteps occur to change animation state and to add a camera shake effect.Short description of the work if you like.


Pictured is an example of how the notifies are called inside the anim graph and used for a precise animation execution in the launch mechanics.


To emphasise the agile properties of the player character, I designed the artificial intelligence (AI) with opposing characteristics. I made them much larger and their movement significantly slower. I used the same animation blueprint and skeleton as the player character and modified the animation rate combined with the movement speed to facilitate their different character mechanics


I have previously created AI using only blueprints, so for this project I wanted focus on creating them using Behavior Trees. The basic logic is that the AI controller speaks to behavior tree and the behavior tree speaks to its blackboard. While the behavior tree asset is used to execute branches containing logic, to determine which branches should be executed, the behavior tree relies on another asset called a blackboard which serves as the brain for a behavior tree. The blackboard contains several user defined keys that holds information used by the behavior tree to make decisions. For example, you could have a boolean key called Can See Player which the behavior tree can reference to see if the value has changed. If the value is true, it could be execute a branch that causes the NPC to chase the player. If it false, it could execute a different branch where the NPC moves around randomly.



- Selector (executes children from left to right. If one succeeds it will not execute other nodes)

- Sequence (executes nodes from left to right regardless of success or not)

- Simple Parallel (while doing A, do B as well)

Add any of the following functions to composites for modifying behavior:

Behavior Tree Tasks

A task is an action you want the AI to perform, such as move to a location or rotate to face something.

Behavior Tree Decorators

Decorators (also known as conditionals) attach to nodes inside the behavior tree and can be used to make a decision whether a branch (or a single node) should be executed.

Behavior Tree Services

Services attach to composite nodes and will execute at their defined frequency as long as their branch is being executed. These are often used to make checks and to update the blackboard and take the place of traditional parallel nodes in other behavior tree systems.

Pictured are the behavior tree created for the NPC. The logic goes from the NPC using a set patrol path whilst the boolean value of Can See Player is not set/false. Once that value changes to is set/true, the NPC will start moving towards the character and attack within a set radius.


The first prototype consisted of having the pawn control the camera rotation in the combative mode and combine this logic by implementing a strafe and a turn-in-place mechanic to support this functionality. Once implemented and tested, I found that the controls combined with the limitation of movement speed did not support fluid movement mechanics. I found that the strafing mechanics was both unaesthetic at a higher movement speed and did not support the fast paced movement. It did provided me the idea on further explore movement on the Y-axis whilst having the rotation orient to the movement. The strafing mechanics would be suitable if the combat system would include a lock-on targeting and slower paced combat. In the the second prototype, the movement is decided on mouse axis angles instead of input. The pawn controls the camera rotation once movement input is recognised. The focus is on fast movement (run and sprint) and while the camera rotates with the character, the possibility of a 360 rotation at a certain speed rotation on the x-axis.

The exploration phase is important to find inspiration and to discover which mechanics that will work in the game. The objective was to find the main mechanic and to create movement in support of that. While prototyping I found that the combination of the camera angles, effects/feedback and function is what makes good character mechanics (function + feedback= good movement).

The greatest value of this project would come from the process itself; by prototyping and exploring mechanics. I began by exploring the player character movement since this would be the deciding factor and lathe groundwork on how to proceed with the

non-player-characters (NPC) movement. Their movement should work in accord to achieve the intended outcome.