Technical Breakdown: The Oculus
- Jun 10
- 4 min read
As part of my tech design class, I was tasked with creating a new world obstacle that was designed by a fellow designer, Kimball Brooksby. I was given a design document for this obstacle, it was my task to implement it in Unreal using Blueprints.
Overview
Design doc exerpt:
“The Oculus is a static hazard with a shifting field of danger. It stands watch over its immediate surroundings, passing its gaze about as it waits for the player or their murder to appear. When they do, it locks onto them, following them for a brief duration before firing out a laser that reduces the target to flitting cinders.”
Components
I began constructing the actor by setting up the components it would need. For the visual assets, I used Fab assets I already had in the project:
I used a spring arm with a hitbox attached, so that the hitbox would be able to compress if it hits a wall. Additionally I included a rotating movement component, which allowed me to have the object constantly turn without being performance intensive.
Scripting its Behavior
To implement the Oculus’s behavior, I categorized its behavior into 3 distinct stages:
Searching: The stage where The Oculus would passively rotate and sweep throughout the level.
Arming: The stage where The Oculus would lock onto the player before it attacks.
Attacking: The stage where The Oculus is dealing damage to the player.
Each stage was split into the blueprint graph. I made sure to color code each stage for readability.
Searching
The Oculus would enter its searching behavior by resetting its eye rotation and activating its rotating movement component. This would cause it to spin around at a set speed. It would also cancel several timers used for other states.
While searching, an overlap event on The Oculus’s sight hitbox would be active. It would listen for an overlap with the player. When the player overlaps with the hitbox, it would start a linetrace for the player. The point of the linetrace is to account for cases where the player is behind cover.
If the linetrace is unsuccessful, The Oculus would continue on its path.
If the linetrace is successful, The Oculus would enter its “Arming” mode.
The linetrace would end if The Oculus is still in searching mode and the player exits overlap with the sight hitbox. The linetrace was implemented to have a more precise way to see if the oculus “see’s” the player, without constantly having to perform a linetrace.
Arming
When entering the Arming state, the oculus would deactivate its rotating component and start constantly looking at the player. This was achieved by a looping timer event, where the eye’s world rotation is set using a Find Look at Rotation. A second timer would then be set for the transition into the attacking stage.
Attacking
When entering the Attacking state, the Oculus would set a looping timer event to apply damage. This event refers to a boolean set by the raytrace to ensure the eye can “see” the player. If it can, it will deal damage.
Secondly, the Attacking state starts a separate timer to check if the eye should revert to its “Searching” behavior. This timer is refreshed in the line trace event if the linetrace meets the player. If not, the timer would eventually expire on its own and allow the Oculus to return to the Searching stage.
{GIF}
Line Trace
Both the attacking and searching stages use a line trace from the eye to the player, so the linetrace event was broken into a separate section and would change its behavior based on the state the oculus was in.
Construction Script
The Oculus takes advantage of the construction script to expose several variables that would be useful to level designers. These variables were also requested in the design document:
Sweep Radius - The radius in meters out from the base of the Oculus that its sight will center on.
Sweep Duration - How long in seconds it takes for the Oculus to complete one full sweep.
Sight Radius - The distance in meters from the center of the Oculus’ sight that it will see the player.
Arming Time - How long in seconds it takes from seeing the player
To calculate the sweep duration, I had to alter the rotation rate of the Rotating Movement component. I had to unpack the Rotating Movement component, and I noticed that a rotation rate of 360 would result in a full rotation in 1 second. I used this fact to determine that dividing 360 by the desired number of seconds would give me the correct rotation rate.
Determining the sight radius was simple: it simply alters the radius of the sphere hitbox as well as the visual effects.
The Sweep Radius was more complex. The design doc requested this value in meters from the base of The Oculus. However, this value needed to ultimately affect the rotation of the eye. My solution was to add a scene component, the “EyeLookAtPoint” and alter its relative location. I then changed the eye’s rotation to reflect the translation of the point.
A massive challenge was creating a visual indicator for the range of the eye’s sweep. I considered using a debug circle, but these would disappear and ultimately not be useful for level designers. I determined the best solution would be to create a new component: a spline path, that would only be useful in the editor.
I created a new function to create this spline. The function would set 4 spline points in each direction from the base, using the sweep radius variable. I then set the spline tangent of each point to make it a perfect circle.
Full Behavior Blueprint:
Comments