This page highlights my time at Huey Games, a small porting and co-devlopment games studio, where I worked as a programmer on a variety of exciting projects. During my time at the studio, I contributed to several game titles and development tools across multiple platforms. Below, you'll find an overview of some of the games and projects I was involved in, showcasing the skills I developed and the experience I gained working with the fantastic team there.
I led the optimisation for the Nintendo Switch, as well as working on other porting tasks, as part of the porting team on Cuisineer, transforming the original PC version into a stable and performant console experience. This involved extensive use of tools like Unity’s Profiler, the NVIDIA' low level graphics debugger, and the Nintendo CPU profiler to identify and address performance bottlenecks.
To get the game running smoothly, we reduced texture sizes, simplified models and materials, and reworked systems like the minimap and particle effects for efficiency. I also optimised gameplay code—improving AI distance checks, switching from sphere casts to raycasts, and streamlining the pathfinding system. In addition to optimisation, we handled many typical porting tasks, including input setup, UI adjustments, saving/loading changes, and localisation.
I also developed custom optimisation tools that were later integrated into Huey’s internal porting framework, HueyCore, helping streamline future projects across the studio.
While working on the porting team for PlateUp!, our primary focus was on adapting the game's netcode to use Photon Realtime to support online multiplayer across consoles. This involved integrating with the game's custom Entity Component System and ensuring full compliance with each platform’s online service requirements, including moderation of user-generated content such as restaurant names. We also implemented compressed save systems to meet strict save file size limitations on consoles.
Alongside the networking work, we also handled many of the core porting tasks required for multi-platform support—configuring controller input, adapting the UI for console layouts, managing localisation, and ensuring save/load systems functioned correctly on each platform. Finally we adjusted resolution and frame rate settings to deliver a consistent, playable experience on all target hardware.
During my time at Huey Games, I contributed significantly to HueyCore, the studio's internal porting framework designed to streamline and automate as much of the multi-platform development process as possible. HueyCore consists of a wide array of systems, overrides, and tools built to simplify platform-specific requirements across consoles. It has been actively developed over several years, with contributions from many programmers—my own work focused on both core systems and major tooling enhancements.
One of my key responsibilities involved working on native save systems, particularly for the Xbox platform. This required deep integration with HueyCore's override architecture, where I carefully reviewed and updated override classes to ensure full coverage of all methods and properties from the base implementations. This was essential for maintaining consistent save/load functionality across console SDKs.
My two major contributions to HueyCore were the runtime optimisation tools and the developer menu. The runtime tools were initially created during the optimisation phase of Cuisineer, and later integrated into HueyCore for broader use.
These tools included:
- Component Toggler – Allowed selective disabling of component types such as Rigidbody, Collider, Particle System, Mesh Renderer (skinned and static), Sprite Renderer, UI Canvas, Light, and Audio Source.
- Camera Tool – Provided live control over camera settings like field of view, post-processing, anti-aliasing, depth textures, clipping planes, and camera rendering status.
- Render Pipeline Tool – Exposed quality settings specific to the active render pipeline (Built-in, URP, HDRP), including shadow quality, render scale, upscaling, HDR, batching, and more.
- General Quality Settings Tool – Enabled changes to cross-pipeline settings such as VSync, target frame rate, texture quality, LOD bias, skin weights, and real-time reflections.
- Time Tool – Allowed adjustments to fixed timestep, max timestep, and maximum particle timestep.
- Proximity Tool – Logged all overlapping colliders to help identify performance-heavy areas.
- Mesh Info Tool – Reported on high-poly meshes exceeding a set triangle count to highlight optimisation opportunities.
The second major contribution was the Dev Menu, a runtime debug interface inspired by the PS3’s XMB menu. Designed as an all-in-one developer tool, it provided access to a range of runtime functions including: unlocking or removing achievements/trophies, triggering PlayStation activities, managing build connections, toggling DLC content, and launching runtime optimisation tools. While the menu system wasn’t fully completed before I left the company, it laid a strong foundation for future development and internal debugging workflows.
My work on HueyCore helped improve both the speed and quality of Huey’s porting process, and several of the tools I built became key components used across multiple projects.
Wreckout was the first project I worked on at Huey Games—a sole, sink-or-swim task that gave me full ownership and responsibility over a highly technical challenge. Initially, my role involved converting the game’s existing netcode from Photon Realtime to Photon Fusion, which went smoothly and allowed us to take advantage of improved client-host networking and performance.
Partway through development, after discussions with the team at Photon, the decision was made to migrate the project to Photon Quantum—a deterministic, rollback-based multiplayer engine built for competitive precision and full-state synchronization. This required a complete rewrite of the game’s codebase to fit Quantum’s deterministic Entity Component System architecture. All floating-point operations had to be converted to fixed-point math, and performance-critical logic relied on unsafe code and pointers to access simulation frame data for deterministic reads.
Most Unity MonoBehaviour components and GameObject-based structures were replaced with Quantum’s own ECS-style domain-specific language (.qtn), using structs instead of classes. Physics colliders and rigidbodies were swapped for Quantum’s deterministic equivalents, including entity and static colliders. Prefabs became Quantum entity prototypes, and scriptable objects and physics materials were rebuilt using Quantum’s custom configuration systems. Large portions of the level data—including maps and gameplay parameters—had to be baked into deterministic formats using Quantum’s tooling and configuration files.
This process gave me deep experience in deterministic game development, fixed-point systems, and the unique requirements of rollback networking. Working with Quantum also meant embracing a completely new development paradigm—more akin to low-level simulation engine development than traditional Unity workflows. Despite the steep learning curve, it was a highly rewarding challenge that significantly strengthened my skills in networking, systems architecture, and ECS-based game design.