Wanderer: TFoF

Wanderer: The Fragments of Fate is a VR action-adventure title in which players travel in time to solve puzzles and resolve the mistakes that led to current state of the world. It’s an ambitious multiplatform game made by a relatively small team of developers, and over the two years that I worked there as an engineer I found myself wearing a lot of hats.

Interactive Items

Much of what I worked on when I started at Mighty Eyes were items that the player could pick up and manipulate. Some of my first tasks were to set up hand poses for grabbing simple, static mesh objects like bottles and ammo containers. Before long I was reviewing and creating my own items that had more complex functionality.

The party popper was one of the first items I created from scratch. At its core, it’s essentially two static meshes (the tube, and the tab) connected via a physics constraint that is visually represented by a cable component. When the player pulls on the tab with enough force, multiple changes occur to sell the effect of the popper being triggered: the constraint loosens and increases in length, the tube mesh is replaced for one that is now opened, a sound and confetti VFX are played, a force is applied to objects in front of the popper, and any small fires are also extinguished. Beyond an item’s base functionality, all items need to support being restored to any possible state via save/load operations, being placed in the inventory, and must account for many other system considerations. This attention to interactive detail is especially important in VR where interactive fidelity is so much of what sells the experience. Essentially all of the items I worked on demanded similar degrees of attention.

The cake featured at the start of the game is another object I wholly put together. Despite looking quite simple, it actually involves many of the systems developed for the game. For one, the cake can be eaten by being brought close to the player’s face causing it’s meshes to swap out for ones that is progressively more eaten. The candle is a separate item actor that uses our component-based socketing system to attach to the cake piece. The sockets have tag identifiers that ensure only permitted objects can attach together while still allowing any candle to be removed from and placed back into any cake piece interchangeably. Finally, the candles each have a child fire actor that can be ignited or extinguished when overlapped by other fire actors.

In retrospect, I have likely reviewed or made edits to just about every item in the game in the time that I’ve been at the studio.

Fixed Interactives

In addition to the objects that the player can pick up I also set up interactions and gameplay logic for actors that are fixed in place. One thing that you’ll notice with many of these objects is the necessity of using physics for interactions that would otherwise be handled by an interact prompt in most flatscreen games. Here I set up the back of the car to open by physically pressing into a button that opens the trunk. This unlocks the physics constraint holding the trunk down, and if the player wishes to close it they’re able to physically push it back into place until it locks again.

Oftentimes these objects serve as puzzles that the player must physically interact with to solve. In the case of the puzzle below, the door that is pulled open by the player must first by unlocked using a key that is physically inserted and turned inside the door’s lock. Behind the door are series of four rotating dials and a lever that can be grabbed and moved, but is physically blocked by a barrier until the combination is solved. To really nail down the feel of the dials, I created a child class of Unreal’s physics constraint component with the additional functionality of snapping to an arbitrary number of points by updating the constraint’s angular driver. Various exposed variables allowed for fine tuning this effect such as the influence of dead zones. Similar to the items, fixed interactables such as this also need to account for save and load operations.

Some objects like the dart shooters don’t require direct player interaction and can be triggered from via a GAS event from something like a trigger volume or the pressure plate actors I initially made for the shooters, but have since been used pretty ubiquitously for testing rooms and other game scenarios. I set these plates up to be able to be selectively triggered by players, NPCs, and items with the option of having a weight requirement to trigger.

Hints

After working extensively on interactives my work shifted to auditing and extending the game’s hints system. These hints use the player’s current narrative progress to determine which hint would be the most appropriate to aid the palyer with a puzzle, or help them reach the next part of the narrative. Working on the hints introduced me to Articy which was the external tool that we used to manage the state and flow of progression in the game’s narrative. Since much of the game had changed since the hints were initially set up, I found that I had to make significant changes to the hints in most levels. Sometimes this meant adding a case that was not accounted for, other times it required completely rewriting the existing logical flow, or adding a whole new block of hints for previously non-existent levels which was the case with the secret downstairs lab.

Narrative

Working on the hints required me to familiarize myself with the game’s story logic since they needed to match the narrative state perfectly. As a consequence of this I found myself not only working on the hints but actively debugging and updating the game’s narrative logic as well. This often led me to find and fix bugs that prevented characters from speaking, caused the game’s narrative to become soft-locked and even parts of the narrative that weren’t even being triggered by the game. In one particular case I realized that it was possible for a player to progress through the third Mayan level without having any idea of why they were there. In order to fix this, I pitched an idea for a narrative appropriate puzzle that could be used to force players to speak to an exposition character that they might have missed. The designers were happy enough with the idea that the core concept was implemented into the game as I had suggested. In addition to updating narrative logic, I also wrote a number of dialogue lines lines that are spoken by the watch character in order to fill some gaps in the narrative and hints system. Some of these were edited before being recorded but much of what I’ve written is currently in the game just as I wrote it which his pretty neat.

Objectives

Due to my work on the hints and narrative, I gradually became the go-to dev for any narrative related questions on the team. At a certain point the designers decided that we need an objectives system for players that would compliments the existing hints. I was tasked with designing a system that could easily integrate with our existing Articy-based narrative. The requirements were that the player would have one objective that conveyed the overall goal within a particular time period, and another that was more granular and described the task at hand. My solution for the first was to have variable that could store the current state and description of the overall goal. The state was useful since it simplified localization for many of the redundant states like ‘Unknown Objective’. Updates to unique states were then just set as a part of narrative progression. For the more granular objectives I was able to piggyback off the existing hints logic by inserting code to update the text of the current objective adjacent to the most closely appropriate hint. As was the case with the watch lines I added, I wrote many of the objectives, some of which were edited and some that made it into the final game untouched.

Tutorials

I worked on many of the tutorials that the player sees involving combat in addition to some that were added later during development. Much like other gameplay code, I set these up using a combination of gameplay events that responded to GAS events, and changes in actor tags, narrative and other game states.

Characters

Prior to launch I was left in charge of some of the systems previously managed by senior devs on the team. Wanderer’s custom metahumans and and any systems relevant to them were included in this. Much of what I what I worked on involved fixing existing issues and extending the features of our characters’ navigation, AI and pooling to name a few. One of the more ambitious additions I worked on was the partial simulation of character skeletons while they animated. Unreal’s physics control component is the tool of choice for this kind of feature, but it took a lot of troubleshooting to get it to function as intended with our custom characters. I did manage to get it to work, but due to the game’s imminent release its integration had to be postponed to a later patch to allow for proper testing and optimization. It’s inclusion would yield a huge boost in character fidelity that regular animations have a difficult time matching, even when using blend spaces.

Combat

In response to community feedback regarding the game’s combat, I was tasked with improving the game’s combat around the time of Wanderer’s launch. This touched many aspects of the game, but broadly my contributions here were in the form of modifying and extending things like our characters’ state trees and perception, updating weapon functionality, and exposing data to make it easier for designers to tweak and iterate on the feel of those systems.

Combat: AI

Some of the AI change I made were to make the AI seem more responsive to the player’s actions, oftentimes in cases where they would previously just break. One example of this was to handle cases in which melee enemies couldn’t reach the player due to being on different navigation mesh islands. My solution to this was to have them taunt the player, a functionality I also repurposed for groups of enemies to give enemies that didn’t have permission to attack a more engaged presence. This was then extended to account for whether the player is holding any kind of ranged weapon, in which case they immediately try to find cover using the existing AI logic. Returning to reachable terrain restores their aggressive state. I also made changes to the conditions under which ranged enemies could enter and exist designated cover points to prevent them from doing odd actions like ping-ponging between cover points.

Combat: Melee

Some of the more general changes I made to melee combat were to add velocity based damage, and filtering for valid hits using controller velocity to prevent players from connecting hits that feel unnatural. Similar to this was the addition of a minimum velocity for killing blows. NPCs also receive a location based impulse on death that is affected by the hitting force. I also made some changes to parrying enemy attacks such as adding knockback for the player and a chance to be disarmed by strong attacks.

Although there was an existing system for sharp weapons that could penetrate characters, subsequent changes to characters had created a situation when stabbing live enemies. It would often launch the player due to the kinematic NPC animation applying an effectively infinite force to the player still holding the weapon. I was able to resolve this by making the physics constraints that governed the effect more relaxed while the enemy was alive. For performance reasons, our characters immediately swap to a more optimized dead duplicate version immediately after being killed. Due to this now being able to occur while the player is actively stabbing an enemy I also needed to update this system to support being able to postpone the switch.

Combat: Ranged

I made many changes to how the ranged weapons in our game worked to give us more options for balancing and to improve their overall feel. The first step of this was moving as many of the parameters used to define each weapon to common data table since these were previously spread out among many different blueprints and gameplay effect definitions. Additional features that I added post launch were damage falloff curves and dynamic bullet spread for automatic weapons, among others.

One tiny feature I prototyped but regrettably never made into the game was a way for players to pull out grenade pins with their teeth. This was done through existing systems by making the pin an edible item much like the cake featured earlier on the page.

Tools

During my time on the project I made and updated a number of developer tools. Many of these took the form of editor utility widgets that we used to automate setting data, or to query objects in a level for potential errors. For instance, I updated a utility to keep track of a history of gameplay events that had fired on a selected actor and made a utility that could query all level sequences in a map for potential errors.

I also wrote a number of commands to help with debugging such as functions that toggled specific types of character perception, and one that killed specified character types. We also had developer options that allowed us to dynamically inject components to specified types of actors on begin play. I made some components that operated this way to show debug information for things like NPC awareness, current statetree state, and displaying damage values.

My time at Mighty Eyes was one that improved my ability to rapidly adapt and also repeatedly put me in situations where I had to assume greater and greater responsibility. Despite the pressure, I’m grateful for the experience as it has led to me becoming a much more capable developer.