Games Designer
Thief VR:
Legacy of Shadow
Prototyping & Mechanics
Initially, I was responsible the rapid prototyping out of many of the player mechanics, using in house tools and writing custom C# scripts to quickly prove out concepts for the team to play.
In this section I will go into detail about my design process developing the game's lockpicking mechanic:
I began by rapidly making several mockups for the team to play, to narrow down the sort of feeling that we might want. I was particularly keen to make use of the 3D nature of VR controllers, in order to create a minigame that felt fresh in comparison to flatscreen mechanics controlled with a console controller/ keyboard & mouse.
You can watch the video I recorded of my very first prototypes below (... apologies, I was in the midst of a nasty cold at the time...)
After initial feedback I continued to develop the version seen above at 2:40.
Given that the player will actually be interacting with a virtual lock with their physical hands, I thought it would be interesting to base the mechanic more on the real life movements of picking an actual lock, than the complete abstractions often found in flatscreen games.
In real life, the unlocking is done with the one dominant hand - moving the pick into/out of the lock, and lifting it to push pins up/down - and the offhand is used only to apply torque to the lock. Therefore, in order to better suit a game I made the following adjustments:
-
rather than have the right hand do everything, I split the in/out movement of selecting a pin onto the left hand, keeping the right hand only for lifting a pin into the right position.
-
since VR controllers are ill-suited to precise movements, the players needs to make proportionally larger arm movements to move their tools / pick the lock's pins.
-
adding a "gamified" fail-state to picking a pin, whereby raising the right hand too high beyond the golden zone, would not only reset the current pin, but all previously successfully picked pins as well, requiring the player to start over. Doing so encourages the player to make slow, careful movements in line with the fantasy of an artful thief, as well as adding tension to the act - a player is torn between wanting to go fast in order not to get caught by any guards who may soon stumble upon you, but not so fast that they fail and have to take even longer redoing previous pins.
To really lean in to the immersive strengths of VR, it was also important to me that, once learned, the mechanic should be playable without any UI of any kind. Players wanting the true thief experience could pick locks using only visual, audio and haptic feedback cues, just like a real thief.
​
In this way, having both a UI and a non-UI version, our mechanic would have a low skill floor but high skill ceiling; we could satisfy both players looking for an intriguing and immersive experience, who really wanted to experience the feeling a thievery as an art, whilst also remaining accessible to more casual players.
​
Below you can see a more polished version of the mechanic, along suggested tutorialisation. Players are introduced to the mechanic and then encouraged to try it again without the aid of UI, after which they choose to continue in either mode (which can be changed at any time from the pause settings menu).
Since such a mechanic obviously relies on locks varying in layout pattern and difficulty throughout the game, I developed editor tooling to make help Level Design create new locks in just a few clicks:
-
Randomisation: After choosing whether the lock consists of 3, 4 or 5 pins (red box), a level designer can set left & hand right hand values (how far forward one needs to push your left hand forward to select a specific pin & how high one has to raise one's right hand to pick it) with the click of a button.
-
In order to ensure an enjoyable experience, especially in immersive mode, left-hand pins will always be spaced far enough apart that their haptic feedback won't blend into eachother, and right-hand height values will be over a minimum height and not too close to that of their neighbours
-
Left & Right hand randomises separated for ease of use, should the designer be happy with the configuration of one but wish to re-randomise the other.
-
​
-
Finetuning & Validation: Level designer's may finetune positions manually themselves with the sliders should they wish & then press a button to check that all positions are valid, without the need to play it in headset themselves to check
​
-
Example comparison: the final button will snap all values to a default configuration hand-placed by me according to whether it is a 3, 4 or 5 pin lock, for designers to get a visual sense of what feels nice for each difficulty.
However towards the end of the project, after a change in the project's leadership, it was decided that none of the players abilities should be complex enough as to require a multi-stage tutorial. We pivoted to simplify the mechanic into its final release version seen below
Enemy NPCs
I was responsible for delivering an engaging and immersive stealth experience by designing enemies with believable, dynamic behaviour and clear, consistent and reactions to player actions.
I collaborated closely with all departments - working with Code, Art, Animation for smoothing flowing animation states, and liaising with Narrative & Audio to plan out all necessary barks ready for recording, localisation and implementation, across a range of character archetypes.
​​
Initially, I was tasked with building AI behaviours in a visual behavioural tree asset (seen below), so that I could follow, debug and edit guard behaviour at runtime, largely independent of the Code team. However, due to performance issues with the tool under the technical constraints of VR, this proved unsustainable, and I collaborated closely with a coder to write guard behaviours directly in C#.​
Due to the time and resource constraints of the project, rather than developing a complex managerial system to control all the guards, each enemy NPC is an autonomous entity, independent of one another, making decisions based on external stimuli that it perceives from the player or other guards.
​
Here you can see their overarching behavioural states below:
In order to create a believable and engaging dynamic stealth sandbox I developed the following core behaviours for the guards:
. The default behaviour of enemy guards. I worked in close collaboration with Level Design, to create a simple system of nodes, allowing them to quickly and easily lay out routes through the levels, with fine control over the timing, positioning and direction of the guards along its points. Guards returning to this state, after having been fully alerted to the presence of the player, will keep their weapon drawn.
-
Patrolling
. A system for Level Design & Animation to populate the levels with to bring a sense of life to the environment, such as a stopping to warm his hands on a fire, leaning over a balcony or sleeping. Each instance is able to be fully controlled by Level Design to last a set, randomised or infinite time until interrupted by player action.
-
Environmental Animations
. By far the most complicated overarching behaviour consisting of interconnected sub-behaviours: chasing, melee combat, out-of-reach combat and searching for the player - once they have lost sight of them, or if they were fully aggroed by something else having never spotted the player themselves. This is the highest priority behaviour, and while in this state certain stimuli, that would usually cause a guard to enter a specific behaviour, will instead be ignored or activate internal custom logic. Alerthunting guards will yell at nearby NPCs to join them in the hunt, but to prevent a player from being overwhelmed by rushing through a level aggroing all of its enemies at once, most of the key sub-behaviours such as chasing are limited to 4 individuals. Any 5th guard attempting to chase will have to periodically evaluate whether he is closer than one of the 4 guards already chasing, and either be prevented from doing so or replace one of the chasers.
-
Alert Hunting (See graphs below)
. A suspicious guard whose red detection metre fills over halfway will abandon their current position to investigate the player's current position.
-
Investigate Player Sighting
. An unaware guard will become suspicious and investigate the position of the sound. Upon arrival NPCs will play a search animation, long enough for a player to either slip past or engage in pickpocketing. Suspicious guards hearing further sounds can be rerouted or more likely aggroed up into Alert Hunting.
-
Investigate Audio Distraction
. A suspicious guard whose red detection metre fills over halfway will abandon their current position to investigate the player's current position.
-
Investigate Player Sighting
. Guards will notice when the player uses water arrows to extinguish braziers, wall torches and fireplaces. Unaware guards that come across one will investigate and relight them before returning to patrol. Guards within the light sources sphere of light when it is extinguished will become suspicious and draw their weapon before relighting it, while guards that see the water arrow - are close by and directly looking at the light source - will aggro into AlertHunting and immediately start searching for the culprit.
-
Investigate Lighting Change
. A non hunting guard that notices an unconscious friend will become suspicious draw their weapon and move to help wake them up. Once resuscitated, both guards will enter AlertHunting and standing searching for the player. However, if the helping guard has recently deaggroed from AlertHunting himself, then both guards will instead simply return to Alerted Patrol to prevent the player having to wait for successive cycles of searching guards to calm down.
-
Investigate Unconscious Body
. A non hunting guard will run up to a dead body, play a short animation and then aggro himself and any surrounding guards into AlertHunting.
-
Investigate Dead Body
. Non hunting guards that are touched - for example in a bungled attempt to pickpocket them - will become suspicious, draw their weapon and turn in the direction they were touched
-
Investigate Touch
. Most anomaly investigation behaviours are performed only by a sole primary responder. Other guards who perceive an anomaly that is flagged as already being investigated will instead stop their patrol, draw their weapon and look towards the point of interest for a time before deescalating and resuming their patrol.
-
Suspicious Look At
A more detailed overview of AlertHunting can be seen in the graphs below:
Overview of a guard's AlertHunting behaviour when detection metre has fully filled
Overview of a hunting guard's searching behaviour once they have lost sight of the player
Overview of a guard's AlertHunting behaviour when detection metre has fully filled
​SEARCHING SYSTEM
​​
Given the guards' autonomous nature, we needed to develop a system to grant the illusion of co-ordinated searching, no matter which part of the level hunting guards lose sight of you.
​​
We overlaid the maps' navmeshes with a series of search points (illustrated by a yellow sphere gizmo), which individual guards will be able to reserve and release:
-
Guards will attempt to find an available search spot within a max distance of the Last Known Player Position (hereafter referred to as LKPP), that they can run to within a max pathable distance.
-
When one is found they will reserve it (turning it red), and also put any nearby search spots on cooldown (turning them blue).
-
Spots that are found within range of the LKPP but are not an acceptable pathing distance, such as a point on the floor above inside a building, will also be put on cooldown to prevent other guards from wasting calculations.
-
-
When a guard has reached their reserved spot they will perform a series of directional search animations or turns, before searching for a new spot to run to.
-
When reaching a new location (or after turning) they perform a few directional raycasts checks for environmental geometry, to calculate which search animations are acceptable. In this way, for example, you won't have a guard standing to the right of a wall, spending several seconds gazing to his left straight at a wall, rather than to the empty space to his left.
-
-
When they have found a new spot, they will put their current spot onto cooldown, reserve the new one and repeat the cycle until the Lost Sight of Player timer runs out, and they give up the search.
-
The range at which the guards will attempt to find their new search spot, after finishing with their current one, will increase, causing guards to gradually spread out from the LKPP if the level layout permits.
-
Players can redirect/prolong the search by distracting the guards, for example by throwing a glass bottle away from their position. In such cases, the guards will rush over to the new location and, if they do not find the player there, they will treat this new location as the LKPP from which to base their continuing search around.​
​For the most believable results of where guards should run to, manual placement of search locations throughout the environment was desired, so a tool was created for Level Design to add/remove search spots to the guards' navmesh with a click of the mouse.
​
However, to ensure environments could be playtested with guards to a reasonable degree during blockout stages without unnecessary delay, we also added an option to generate spots across the entire level automatically in a grid like fashion.
​Below you can see an example of the system in action, after three guards begun searching for the player after spotting a dead body:
Choosing New Search Point Logic
​
-
nearest yellow in range that was not last spot
-
nearest blue in range that was not last spot
-
the yellow that was last spot
-
the blue that was
last spot​
STEALTH TAKEDOWNS​
The player is equipped with a blackjack to perform stealth takedowns on enemies, by striking them on the head.
Since the player is likely to be crouched when approaching guards to keep them from being alerted to the sound of their footsteps, we also give players the option to strike guards in the back of the legs to bring them down onto their knees.
In this way, a player is not required to stretch or stand up to incapacitate a guard in order to reach their head, at the cost of having to strike twice - and therefore making an extra noise that could potentially further alert nearby guards.
​
MELEE COMBAT
The fantasy we wish the player to experience is that of a thief, not a warrior or assassin, and so we wanted to discourage players from attempting to fight enemies with their blackjack except as a method of last resort.
​​
As we cannot control a players movements in VR, I landed on a parrying system:
Guards engaged in combat are invulnerable to blackjack strikes from the player, but the player can use their blackjack to deflect incoming attacks and avoid damage. After a number of successful parries an enemy will be briefly stunned, allowing the player to knock them out with the blackjack as usual.
​
To parry a strike, a player must swing their own blackjack into the oncoming sword at the correct timing and angle.
​
In this way we achieve a balance between intuitiveness and difficulty; fighting off one guard at a time should be manageable, whereas fighting multiple guards at once would feel extremely difficult.
​
You can watch the youtuber "A Wolf in VR" playing through the combat tutorial in the opening mission below, to get a sense of the mechanic:​
ENEMY VARIETY
​
I was also responsible for creating and balancing the different enemy types across the game, to ensure that Level Design could create varied stealth scenarios of increasing challenge throughout the game.
​
​
​
​
​
​
​
​
​
​
-
Guards come in helmeted & non-helmeted varieties
-
guards without a helmet will be KOed instantly when struck on the head with the player's blackjack, whereas helmeted guards will only be knocked down onto their knees, requiring a further (audible!) stroke to the head to fully incapacitate them.
-
Unhelmeted guards will die instantly from an arrow shot to the head, whereas players will have to carefully aim for the face of a helmeted guard for a one-shot-kill, as hitting the helmet will only damage the guard's health akin to a body shot.
-
-
Captains, more elite versions of the standard guard
-
while behaviourally the same as a standard guard, they are faster in combat and do more damage, but will have pickpocket-able loot of higher value
-
-
Crossbowmen
-
these guards will attempt to engage the player at range, and only chase the player in order to keep their firing lines clear, reloading after every shot
-
-
Heavies, designed to force the player to stealth around them
-
these guards are slow to catch up but can kill with a single hit, and their strikes cannot be parried, only avoided!
-
they cannot be knocked out from stealth, and have an extremely large health pool, requiring more arrows to down than an un-upgraded player initially starts a level with, unless they manage to shoot their face through their extremely narrow eye slot.
-
Enemy Perception
Each cone is also further subdivided in sections, so that detection speed can be precisely controlled and modified, the further you are from the guard. Changing the detection time proportionally between the set values of the zones allows us to avoid sudden jumps in detection speed when crossing between sections, as all changes will be smooth.
For example, in the image below a guard would detect a player anywhere in the yellow zone in 1 second, whereas a player standing exactly in the middle of the turquoise zone would be detected in 6.5 seconds.
When a player intersects with any of a guards vision cone, they will fire off raycasts towards specified points on the player rig, to calculate if they have enough of an unobstructed view of the player, and if so begin to detect the player (in this way the player is still able to peek round corners to a small extent before being detected).
Players can frequently be in more than one cone at a time, and so will be detected with the values of the highest priority cone (eg. if a lit player is overlapping both the Direct LOS cone and the Peripheral cone, he will be detected with LOS values)
​​
As a guard detects a player they first fill their suspicion metre, a value between 0 -> 1, signified in the video below by a yellow bar filling. Once this number becomes 1 a guard becomes suspicious, stops patrolling and draws their weapon. Further detection of the player will cause their detection metre to fill from 0 -> 1, signified in the video below by a red bar filling. When this number reaches 1, the guard has fully detected the player and will attempt to hunt them down and kill them.
The rate at which the detection metre fills in each section of a cone is based on:
In this screenshot, you can see the detection values of both sections of the Close purple cone (the first chunk from 0m - 3.75m, and the second 3.75m - 6m), for players that are DARK.
In this screenshot, you can see the detection values of both sections of the Close purple cone (the first chunk from 0m - 3.75m, and the second 3.75m - 6m), for players that are DARK.
-
​​Light status of player
- Each section has a faster base fill rate for a lit player, or a slower fill rate for a dark player (or a rate of 0 if the player cannot be detected in the dark)
-
Status of the NPC (unaware vs suspicious)
-
One base rate for unaware guards to fill their (yellow) suspicion metre, and another faster rate to fill their (red) alert metre
-
-
Extra modifiers
-
The base rate is then multiplied by various factors to either speed up or slow down the rate of detection including:
-
is the player stationary?
-
(if not) is the player moving? If so are moving even faster than a specified speed?
-
is the player crouched?
-
-
​​
To the left you can see the detection values for the Close vision cone for unlit players - numbers are the time it takes for the guard's metre to fully fill, from 0 to 1, in seconds.
In the example video below you see me walking around slowly, unlit, right at the limit of a guard's dark vision (6m cone). The guard starts to detect me slowly until I crouch and hold still, then begins detecting me again once I continue moving, fully filling his suspicion metre (yellow) and then detection metre (red).
HEARING
​
As well as vision, guards also have to respond to sounds of different types - player footsteps (walking vs running vs landing), distractions (thrown bottle smashes, arrows hitting walls/floors etc.), shouts of their fellow guards - and differing volumes.
​
For simplicity’s sake, and to aid balancing multiple objects types across the game, we set all possible noises to a discrete distance range - silent, quiet, medium, loud or very loud - but noises of the same volume range can still increase a guard's suspicion/detection metre by different amounts based on context.
For example, in order not to feel punishingly unfair footsteps had to be calibrated such that when a guard hears your first footstep (provided you are not running), you have a chance to back off without your second footstep further alerting the guard too much.
Likewise, many of the players interactions with enemies - knocking out a NPC with one hit vs knocking a character to their knees vs killing a guard with an arrow headshot - had to be tuned in order to give the stealth sandbox a satisfying degree of challenge without feeling overly unforgiving.​​​​​​
My initial proposal for the range footstep noise can travel over the various floor types
After playtesting feedback we reduced the range of walking on quiet floors and crouch-walking over loud floors.
My initial proposal for the range footstep noise can travel over the various floor types
As with the original games, the surface of the floor the players walks on, as well as the speed at which they move, will affect the range at which enemies can hear you, allowing Level Design to create distinct infiltration pathways through their environment.​​​​​​​
When a sound occurs, the sound manager will first check for all guards within range with a simple distance check, then use the level's audio navmesh to evaluate potential pathable routes to acceptable NPCs (up to the length of the sound's range + an extra 25%), in order to account for level geometry such as walls, ceilings and large obstacles.
In the event that more than one guard is made suspicious by hearing the same sound, one guard will be designated as the primary responder and sent to investigate, while the others will merely pause after drawing their weapons and look in its direction for a short period of time before resuming their previous behaviours (provided the player is not caught, of course). In this way the player will not be continuously overwhelmed from different directions after making mistake, and can also use distractions, such as throwing items or shooting arrows, to lure guards away from their current position, and sneak by unnoticed.
​
Repeated sounds will further raise a guard's detection metre. If it fills completely, the guard will become fully alert and begin hunting the player - using the same searching behaviour as if he had previously been chasing the player and had lost sight of them.