From 2022-2024 I worked on DeathSprint 66.
I was on this project from early prototyping all the way until release and post-launch.
In my role I took on Gameplay and UI code.
Primarily I was responsible for implementing the in-game HUD.
Some of my other responsibilites included:
Here’s a closer look at some of the features mentioned above.
I created various widgets for the HUD, using various techniques to achieve some cool effects. The entire HUD was completely event-driven except for where it made sense otherwise (race timer, for example).
On the image above you can see the following elements I created:
Below I’ll explain a little more about some of the more complicated
DeathSprint 66 is canonically a game show, and to sell that effect we wanted to have emojis that burst from the bottom of the screen that respond to your characters in-game actions, to mimick viewers watching at home.
Originally, we had a small number of emoji widgets that’d burst onto the screen, which was slow and costly. Using a widget pool didn’t help too much either, since the bulk of the cost was the overhead of the widgets themselves, so in the end I decided to use an SMeshWidget.
This essentially allowed me to instance widgets and draw all emojis in a single drawcall, meaning instead of a handfull of slow emojis on screen, we could have had thousands, and they were lightning quick too!
The ability container was really fun to implement, it’s a 3d coin-flip animation that travels up the screen, fading away to reveal the ability you have randomly received!
The surge bar is all material based, I worked on it together with a really talented Tech Artist, it consists of three separate bars that fill up, and turn a different colour upon filling up, all on a radial meter.
I was also one of a few programmers who worked on cosmetics implementation, mainly responsible for reading the data given to us from backend. The indexes for skins, emoji packs, and banners would be sent from the server and I created the system that read that data and displayed the correct cosmetic.
We faced a problem with our racing game in that the characters all ran at the same speed, meaning you could only overtake someone if they messed up and died. To remedy this, I came up with a system where doing well at the game (chaining up wallruns, ziplines, drifting, etc.) would allow you to build ‘momentum’.
Your momentum score was then used to increase your maximum speed, allowing you to travel faster. This ended up working really well as it created a sense of ‘flow-state’ to the player.
One thing I’m really proud of is the way I set this system up.
It allowed designers to:
They could do all of this without any code support.
The system itself managed your momentum modifiers, calculated your momentum score, and then calcualted your new max speed based on a Momentum -> Max Speed curve, injecting the new max speed into the movement code.
Towards the beginning of production I also helped in setting up and learning about the Gameplay Ability System which was new to us at the time. Using it, I implemented a few character abilities, some of which are still in the game (although they were built upon by another programmer after me!)
Whilst on ziplines and grindrails the character can lean to either side to dodge traps.
I worked together with Animation to achieve this effect using blend-spaces.
The character can be hit with other players’ abilities, one ability causes the player to grab their head with both hands. Obviously, while the player is ziplining or wallrunning, one of their hands is preoccupied, so I looked into Skeletal Animation Masking. This allowed us to mask off part of the animation if the hands were pre-occupied, meaning their hand on the wall or zipline would stay there, and only the other hand would play the animation.
I added ImGui into our custom version of Unreal Engine, and used it to make some nice debug tools for DeathSprint, including a graph which showed speed over time and momentum over time.
Part of implementing the UI was making sure the UI was performant. I used an array of techniques to diagnose and optimize the HUD, such as:
Through this I managed to get the entire HUD under 1ms/tick, even under worst-case scenario.
For around 2 years, I have been working on Enginefall.
I have taken on a number of roles, such as Gameplay Programmer, UI Programmer, and Strike Team Lead.
Here are some of my responsibilities:
I got to work on lots of really cool stuff on Enginefall, here’s a more in-depth look at some of the highlights.
The recoil system was set up to be physically realistic (as reasonably possible), the chief inspiration for the system was Counter-Strike 2.
The recoil system involved a few moving parts:
These elements together created a system where a designer could assign per-bullet forces on the weapon, allowing them to create spray patterns. Then when a player fires, the recoil is simulated accurately, and once they stop firing the character recovers from the recoil. The player themselves could also try to offset the recovery and become more accurate.
The recoil system was set up to be very flexible, but as a result of this flexibility, it now took quite a long time to create and tweak patterns.
Every time a designer wants to change a spray pattern, they’d have to open the weapon, go to the bullets, change the forces, load the game up, get a weapon, and finally fire it against a wall. Each iteration could take several minutes, which is obviously too slow.
To remedy this I created the Recoil Visualization Tool.
This tool did a few things:
It did all of this in Editor time, meaning you didn’t even have to launch the game to iterate on spray patterns!
This was mostly animation work, helping to set up the animations so the sections run in the correct order, loop appropriately, and then transition out of it smoothly afterwards. The system also needed to support animation cancelling, which was allowing the player to shoot before the gun was fully reloaded.
The animation work I did here was also used on other weapon reloads to allow anim cancelling, and for looping animations for consumable items.
Implementing the Riot Shield involved allowing items to use their parent’s Ability System Component for Combat logic, but use their own attributes for tracking health. This work also involved setting up Gameplay Cues for audio.
This is a system I owned, designed, and implemented, that aimed to solve “toxic PvP”. The idea is that the more you kill people, the more difficult the game becomes. We did this by giving each player a trace score. When a threshold was passed, the game would introduce a challenge, such as revealing your location briefly when you kill someone. At extreme levels, the TRACE System would send NPC Guards to hunt you down (though I did not implement the bots).
The thresholds for TRACE were fully customisable and very flexible, they could be changed per-carriage, per-train, or for the whole game. This also came with some UI work, audio work, and some tech art implementation for player outlines. I also created a range of cheats and debug information for this system, allowing QA to test very easily.
I was responsible for implementing ladders, and spent a while iterating and making them feel smooth. They needed to support the player moving up and down, restrict lateral movement somewhat to prevent falling off, traverse facing the ladder or facing away.
They needed to dismount and mount smoothly, catch the player at the top, but don’t catch the player too well otherwise they’d get sucked in accidentally.
They also needed to support curved and kinked ladders.
And finally, they needed to have a satisfying jump-off and re-attach, to allow jumping between ladders.
All of this was difficult to do, but the end product felt amazing (or at least I thought so, others probably thought “they’re just ladders, what’s the big deal?”)
Enginefall had lots of clothing items, and Art asked for a system that allowed for interactions between these clothing items.
I created a system that detected when clothes were covering each other and then would allow artists to select from some default behaviour, or create custom behaviour per-item.
For common operations, I implemented a solution where we could create generic blueprints to apply operations to clothing items, the system allowed multiple effects to be chained up. This meant the system was very flexible, allowing us to create effects like hiding items, swapping out meshes, applying VFX, and more!
The filtered slots system allowed us to enforce item-types per slot. We wanted a clothing column and a utility column, but both had to point to the same inventory component, so as not to create extra work for the coverage system detailed above. In the end this was a pretty simple change, but I was happy with it nonetheless.
The objective of this task was simple, convert world object locations into screen space, add a waypoint above them, and clamp them to the screen in an oval shape.
The task involved doing some pretty funky maths to manipulate world objects into screen space, since the default ProjectWorldLocationToWidgetPosition can fail, if the object is directly behind the player. After getting it in screen space, it was as simple as clamping to various shapes to prevent it going off the screen, or beyond the radius we set.
This was just a condensed list of all the awesome stuff I got to do on Enginefall, but hopefully it provided some insight into my role in bringing this title to life.