Ready at Dawn

Though my time at Ready at Dawn was short (studio was shut down just 6 months after I joined), there was still a lot of opportunity to push their projects forward. The majority of my work focused on interfacing with artists to develop tools and workflows for the studio's first project in UE5.

Of most interest was a port of Unreal's Pivot Painter tool from 3DS Max to Maya. Pivot Painter is a tool for effeciently modeling and rendering complex motion on static meshes (for wind animation on foliage, for example). This was my first exposure to writing Maya plugins. It also involved writing a fairly complex material that deformed static meshes based on wind generated from gameplay events.

The Art of Flight

The Art of Flight is a dreamy shmup built by myself and friend Collin Eye with our proprietary Etcetera engine. Typically our work is split between him on design/gameplay programming and me for engine/tech work. For this game I completely rewrote our renderer to support variable backends (in this case D3D12 and Vulkan), implemented a Steamdeck port, developed a new build system for our engine (including automatic build uploads to Steam), and wrote a number of offline tools for pregenerating the "watercolor" backgrounds..

The Art of Flight is projected to ship in Q1 of 2025.

MTG Arena

In early 2021 I started work on the MTG Arena Rules Engine team. We're responsible for implementing large sets of new card designs for major releases roughly every two months. To facilitate this we use a natural language processing system to parse card text and automatically generate runtime code.

Luckily, Magic card rule text has a fairly strict grammar we call "Magickese" so the problem is tractable. We've implemented a set of NLTK syntax productions that produce parse trees with embedded semantics for each card ability. These parse trees are then transformed into CLIPS rule definitions with a custom Python compiler. Then at runtime a CLIPS interpreter/C++ harness executes a combination of hand-written rules and rules generated by the compiler.

Most card work involves extending the Python compiler to support new ability text but often need to modify other parts of the pipeline. The Rules team also handles localization, coordination with the Duel Scene (match UI) team, and providing feedback on early card designs to ensure they work well in a digital context.

Resident Evil 4 (VR)

Resident Evil 4 is a VR remake of one of the most beloved titles in the franchise. I started working on the game with Armature Studio in late 2019. The port involved a heavily modified version of the original game code wrapped in Unreal 4 for rendering and VR support.

My major contribution to the game was implementing a VR-capable UI library that was used extensively in the inventory/map/merchant screen/menus. The main advantage of the custom UI library is native support for multiple pointing devices. UE4 has a builtin UI system but it was designed with only a single mouse in mind, which poses some problems for a VR game. The library I built had support for many UI primitives including buttons, sliders, and scrollable regions.

One of the coolest parts of the original game was the inventory system. The player needed to manage all of their items in a size limited briefcase by translating and rotating them to cram everything in. This screen needed to be rebuilt entirely to work in a VR context and I handled the programmatic heavy lifting to get it done. The implementation involved the VR UI library mentioned above, UE4 Blueprints, and a bunch of wrapper code to tie UE4 and the original inventory management system together.

In the original version all of the inventory items are locked to a grid. The VR version allows you to pick up and rotate items to get a good look at them. Mapping an arbitrarily oriented object back into the coordinate space of the briefcase proved to be quite a challenge. The inventory also supports combining/attaching items, equipping weapons, and deleting items. (Note: the image below depicts the original game, not the VR remake.)

I also worked on similar overhauls to the Map and Files screens and developed a data-driven system for populating in-game menus.

Sports Scramble

Sports Scramble is a whimsical sports game that was a launch title for the Oculus Quest. This was my first project at Armature.

By the time I arrived there were only 5 months left on the project and most of the core gameplay challenges had been solved. There was quite a bit of physics fudging to allow for arbitrarily sized play-spaces and for synchronizing ball positions over a network. However, multiplayer only supported direct invitations to people in your Oculus Friends list.

My first major task was to implement a more robust system for joining multiplayer games, either through direct invites with friends or with randoms in a matchmaking queue. Originally players would abruptly teleport to the game once they connected but that was undesirable for many reasons. After connecting, two players would need to hang around in a lobby in order to select game options, and then smoothly transition to the gameplay level. This involved a complete overhaul of the game connection process and the way in which the levels were loaded.

The Oculus Quest had few other multiplayer games at launch, and as such we ran headfirst into a very hairy problem with the OS. At any time the player can back out of a game and into the OS menu. In order to maintain framerate while the menu is open, the main thread of the active game is suspended. Unreal handles all network data on the main thread, which means that suspending during a multiplayer game can result in dropping (so-called) "reliable" Remote Procedure Calls. A single dropped RPC in our game can have catastrophic effects and result in soft locks, so must be avoided at all costs.

In order to actually solve this problem, we needed a way to determine whether the remote player ever opened the OS menu during a multiplayer game, and immediately stop the game and reset to the last known stable state. The solution I devised turned out to be rather elegant: each player keeps track of an integer "generation", and the last known "generation" of the remote player. Each player periodicly sends both values over the network to the other player. If at any point the local player suspends the game or the remote player's generation is greater than the local generation, the game pauses and the local generation increments. Once the generations converge to the same value on both ends the game is reset and play resumes.

I also worked on a variety of other networking problems on Sports Scramble. This was the first multiplayer game the studio had made in Unreal, so there were some inevitable problems towards the end of the project. In many cases game state replicated incorrectly and soft locks were possible within some of the multiplayer menus. The asynchronous nature of a multiplayer game led to countless bugs that were nearly impossible to track down and replicate. The experience I had with From Other Suns was invaluable and crucial for launching Sports Scramble on time.

Fail Factory (Quest port)

After Sports Scramble wrapped, there was a bit of a lull in work while the next project ramped up. During that time I was tasked with (almost) single-handedly porting Armature's previous VR game, Fail Factory, to the Oculus Quest.

Fail Factory originally shipped on the Oculus Go, which had severe limitations. The headset itself was less powerful, there was only one controller, and both the headset and controller only had 3 DOF movement (rotation only, no positional tracking). The solutions required to work around these constraints were incompatible with the higher fidelity tracking of the Quest, so much of the core gameplay needed to be reimplemented.

For one, the player now had two controllers in their hands at all times. We decided to allow the player to switch hands by simply pressing a button on their off-hand at any time. This lead to many subtle bugs caused by assuming there would only ever be a single hand. For example, UI buttons would become stuck in a highlighted state if you swap hands while hovering over one. There were also more serious gameplay bugs in the same vein.

Another challenge was that the original version of Fail Factory was released with Unreal Engine 4.18 but shipping on the Oculus Quest required an upgrade to Unreal 4.23. The Go version made some simplifications to the 4.18 rendering pipeline to hit target performance. In the following versions of Unreal many changes were made to this pipeline, which broke our customizations. In order to maintain the same look these custom changes had to be forward-ported to Unreal 4.23, which required a significant deep dive into Unreal rendering internals.

There's always a lot that goes into any port project, and Fail Factory was no different. Including the above, I modified the achievement system to work with the new Oculus API, polished up the block-grabbing feel, and fixed bugs both old and new. Since launch it has been bundled with Sports Scramble for numerous promotional events and has helped drive sales of both titles.

From Other Suns

From Other Suns is a VR FTL-em-up, made with Unreal 4 at Gunfire Games. I joined Gunfire in the last year of the project, and worked on FoS until ship.

The most prominent feature I worked on was the player's inventory system. Players use the inventory by picking up weapons/items from the world and dropping them into a virtual bucket accessed from the other hand. While seemingly simple, FoS is a networked game so ensuring the state of the world/inventories was synchronized across all clients was a challenge. Due to the implementation of weapons and other items in FoS, it made sense to build most of the inventory interface with Blueprints.

Interstellar travel is at the core of FoS, and because the game is procedurally generated the universe needs to be different every time. I developed a method that computes star locations by maximally filling a volume with blue noise. The method was easily tunable and allowed us to change the density of stars and the volume of the universe. We tried a couple of universe shapes and interfaces for visualizing and interacting with the "Star Chart", including a large pannable stellarium, before we settled on a simple extruded capsule.

I also worked on weapon/item popups and ammo readouts, frequent networking/replication bugs, a bunch of support/bug fixes for the intro tutorial, a slew of savestate deserialization issues, and many smaller game feel features related to picking up, dropping, and interacting with objects in VR. All of the programmers on the team were generalists and we each had to have extensive knowledge of the entire codebase to diagnosis and fix issues with interconnected systems.