Design
I decide the architecture.
GPU abstraction boundaries, immutable render packets, owner-authoritative netcode - design calls, not generated ones.
How I work / 4 agent-directed projects
How the
work happens.
I architect, evaluate, and review. Agent harnesses do most of the typing, and projects built that way are labelled below.
Verification
Nothing merges on vibes.
1,271 tests, a guard that fails the build on abstraction leaks, architecture checks every push.
Throughput
Weeks of work, done in days.
Several models running in parallel through omp and Claude Code, split so they do not collide.
Evaluation
I learn it before I add it.
New Vulkan extensions and NAT traversal - studied properly, then mostly left out. The connect ladder earned its place.
Tools for teammates
I build what they asked for.
Every in-house tool starts with the programmers and QA who will live in it. I write up what they need, then document the result so it is usable without me.
Release pressure
I take the tickets nobody else can finish.
Near submission I work directly with producers and clear the TRC tickets at risk of missing the date, including other seniors' queues when they are away. I was doing that before I had the title.
Selected work / 4 case studies
Selected
projects.
4 projects with more detail on my role, the technical problems, and the result.
/01
AetherCore
An editor-first Vulkan game engine for 2D and 3D games, with a GPU-driven renderer, hot-reloadable C# gameplay, owner-authoritative multiplayer with full NAT traversal, and an end-to-end asset and publishing pipeline.
Role I own the architecture and direct the work. The engine started as hand-written C++ and Vulkan, and as it grew I moved to directing it through multi-agent harnesses - I set the design, the boundaries, and the acceptance criteria, then review, verify, and land the result.
- Eight projects live in the repository - playable games, a physics sandbox, and a networked multiplayer test bed - so every subsystem is exercised by something being built with it.
- Projects move from imported assets and authored scenes to hot-reloaded gameplay, networked sessions, and packaged standalone builds without leaving the engine workflow.
Case study
AetherCore
An editor-first Vulkan game engine for 2D and 3D games, with a GPU-driven renderer, hot-reloadable C# gameplay, owner-authoritative multiplayer with full NAT traversal, and an end-to-end asset and publishing pipeline.
Role
I own the architecture and direct the work. The engine started as hand-written C++ and Vulkan, and as it grew I moved to directing it through multi-agent harnesses - I set the design, the boundaries, and the acceptance criteria, then review, verify, and land the result.
Problem
I wanted the renderer, authoring tools, scripting layer, networking, and shipping workflow to evolve as one usable engine - not become another technically interesting renderer demo that never supported making a game.
Outcome
- Eight projects live in the repository - playable games, a physics sandbox, and a networked multiplayer test bed - so every subsystem is exercised by something being built with it.
- Projects move from imported assets and authored scenes to hot-reloaded gameplay, networked sessions, and packaged standalone builds without leaving the engine workflow.
- Tagging a release publishes a self-contained editor that someone can install and build games with, without a compiler, the Vulkan SDK, or the source repository.
- The Launcher and Editor can be driven and inspected programmatically for reproducible scene authoring, screenshots, diagnostics, and end-to-end validation.
How it was built
AetherCore began as hand-written C++ and Vulkan. As the surface area grew I moved to directing it through agent harnesses (omp, Claude Code) and several models working in parallel, which is how an engine this size stays tractable for one person - subsystems that would have taken weeks land in days. I am the architect and the reviewer rather than the person typing every line: I decide the design and the constraints, the agents implement against them, and nothing merges until it passes the test suite, the GPU abstraction guard, and my own review. The 1,271 tests and the architecture checks in CI exist because that workflow needs a hard verification floor.
Approach
- Kept engine-facing GPU abstractions separate from the Vulkan backend and moved frame data through immutable render packets rather than reading the ECS from the render thread.
- Made reflection a single source of truth for editable component fields across the inspector, scene serializer, script bindings, and editor-control surface.
- Built the editor, standalone Launcher, managed gameplay SDK, diagnostics, and asset pipeline around the same project model so iteration and shipping use the same foundations.
- Designed the netcode so the owner of an entity simulates it - no round trip on your own input and no correction - and made connectivity degrade through a cheapest-first ladder so a game gets LAN play, NAT traversal, and relay fallback without a player ever forwarding a port.
- Treated the engine's own games as the acceptance test, building each subsystem against a project that needed it rather than against a demo scene.
- Engine
- AetherCore
- Graphics API
- Vulkan
Capabilities
- Render graph with bindless descriptors, buffer device address, and GPU-driven draw culling
- Tiled lighting with cascaded and local shadows, contact shadows, GTAO, and screen-space reflections
- Post-processing stack covering volumetric fog, bloom, depth of field, histogram auto-exposure, and a tonemapper with eight selectable operators
- Owner-authoritative multiplayer over ENet - network identity components, session state, and host-to-client and multicast RPCs callable from script
- Cheapest-first connect ladder of LAN broadcast, UPnP/NAT-PMP/PCP port mapping, STUN hole punching, rendezvous signalling, and opt-in TURN relay, with no port forwarding at any rung
- Editor-first 2D and 3D workflow with a standalone project Launcher, dockable viewport and inspectors, and linked prefab instances
- Authoring tools including sprite slicing, animation timelines, chunked tilemaps, a command-based undo system, and autosave with crash recovery
- Hot-reloadable .NET 10 C# gameplay SDK with collectible load contexts, inspector-exposed script fields, F5 rebuild, and one-click Visual Studio debugging
- Managed EditorGui immediate-mode API for writing editor tooling in C#
- Jolt 3D physics and Box2D 2D physics with ragdolls, character controllers, script-driven weld and rope constraints, and colliders generated from sprites and tilemaps
- Retained UI system with per-element custom shaders, inline rich-text effect spans, GPU curve text rendering, text editing, scrolling, and gamepad navigation
- Asset pipeline with glTF ingestion, freshness-checked project-wide baking, texture transcoding, material presets, zstd-compressed engine and project PAKs, and a virtual file system
- Diagnostics with Tracy CPU and GPU instrumentation, a frame timeline panel, tagged allocation tracking over mimalloc with a compile-time tracking ceiling, render-pass timings, and resource inspection
- Built-in MCP server so a coding agent can drive a live editor - managing panels, querying the render graph, capturing screenshots, and entering play mode
Engineering signals
- The public repository carries 1,271 automated test cases across 152 suites covering rendering, physics, scripting, assets, networking, and memory - countable directly from the checked-out source
- CI runs static architecture checks and a Windows build-and-unit pass on every push; editor and runtime GPU smokes run locally as a pre-merge gauntlet
- An automated GPU abstraction guard fails the build when engine code reaches past the abstraction into the Vulkan backend
- The public repository measures roughly 164,000 lines of C++ across 685 files by a direct line count of the source, plus a 13,000-line C# gameplay SDK
- Immutable render-frame extraction keeps the render thread independent from mutable ECS state
- Per-tag allocation counters with a compile-time tracking ceiling, so memory attribution costs nothing in retail builds
- Separate development, ship, and retail build policies keep diagnostics available without leaking them into release builds
- Windows and Linux build presets, with tagged releases producing a self-contained installer that needs no compiler or Vulkan SDK
Select an image to enlarge
Internal tools / production systems
/02
Big Ant In-House Tools Suite
Internal tooling and automation suite spanning memory diagnostics, crash reporting, CI/developer workflow scripts, and distributed QA orchestration for large-scale automated game validation.
Role Designed and implemented multiple production tools used by programmers and QA, including memory analysis workflows, crash triage pipelines, script ecosystem migration, and distributed automated crash testing. Each one started with the people who would use it - I sat down with them, wrote up what they actually needed, and documented the finished tool so it did not depend on me.
- Reduced the time required to identify recurring crashes and high-impact memory waste.
- Enabled unattended testing across multiple game instances with callstacks and logs delivered directly to the team.
Case study
Big Ant In-House Tools Suite
Internal tooling and automation suite spanning memory diagnostics, crash reporting, CI/developer workflow scripts, and distributed QA orchestration for large-scale automated game validation.
Role
Designed and implemented multiple production tools used by programmers and QA, including memory analysis workflows, crash triage pipelines, script ecosystem migration, and distributed automated crash testing. Each one started with the people who would use it - I sat down with them, wrote up what they actually needed, and documented the finished tool so it did not depend on me.
Problem
Memory investigation, crash triage, release checks, and multi-machine QA all depended on repetitive manual work that made failures slower to reproduce and harder to group.
Outcome
- Reduced the time required to identify recurring crashes and high-impact memory waste.
- Enabled unattended testing across multiple game instances with callstacks and logs delivered directly to the team.
- Consolidated fragile automation into a more maintainable CSX toolchain used across production workflows.
- Tools that teammates adopted and ran themselves, documented well enough that my involvement was not a dependency.
Approach
- Built focused tools around the existing studio workflow instead of asking programmers and QA to adopt an entirely separate platform.
- Converted raw memory and crash data into grouped, searchable evidence that could be acted on without manually inspecting every dump or machine.
- Used Discord and websockets as a lightweight control and reporting surface for distributed automated game validation.
- Worked directly with the programmers and QA who would use each tool, writing up their requirements first so the tool solved the real problem rather than the one I assumed.
- Wrote and maintained usage documentation for every tool so teammates could get a good result without asking me how it works.
- Engine
- Proprietary Studio Engine
Capabilities
- Internal memory-analysis tool for CSV-driven leak and waste analysis
- Internal crash-capture pipeline with WER-based dump/log capture and crash grouping
- CSX migration of internal automation scripts from Python
- Discord-managed distributed QA orchestrator using websockets for multi-instance crash detection
/03
Cricket 26
A multi-platform cricket game released on PC, PlayStation, and Xbox.
Role I fully implemented the title's client-side WebSocket stack, including cross-platform TLS handshake support, and took that networking work through TRC certification for release, alongside building in-house tooling.
- The websocket client and its TLS handshake paths shipped in the released game on PC, PlayStation, and Xbox.
- The title passed platform certification with the networking stack in place.
Case study
Cricket 26
NetworkingProfessional2025
A multi-platform cricket game released on PC, PlayStation, and Xbox.
Role
I fully implemented the title's client-side WebSocket stack, including cross-platform TLS handshake support, and took that networking work through TRC certification for release, alongside building in-house tooling.
Problem
The title needed a production-ready websocket client with secure TLS behaviour that remained consistent across every supported platform and its different networking constraints.
Outcome
- The websocket client and its TLS handshake paths shipped in the released game on PC, PlayStation, and Xbox.
- The title passed platform certification with the networking stack in place.
- The team kept in-house tooling improvements around the release workflow.
Approach
- Implemented the client-side websocket stack and platform-specific TLS handshake path inside the studio engine.
- Worked alongside certification and release requirements so the networking implementation was validated under the same constraints as the shipped game.
- Continued improving in-house tooling around the release workflow rather than treating networking as an isolated feature.
- Engine
- Proprietary Studio Engine
Capabilities
- Cricket franchise systems support
- Multi-platform release workflow
- Client-side WebSocket implementation
- Cross-platform TLS handshake implementation
Select an image to enlarge
/04
TIEBREAK
A multi-platform licensed tennis game with career modes, online play, and a large UI surface built across two interface systems.
Role Owned most of the UI implementation, built complete game modes, and helped bridge the in-house widget system and NoesisGUI.
- Delivered the UI and complete game modes for the initial release and later platform work.
- Kept the existing UI working while the project moved to NoesisGUI.
Case study
TIEBREAK
A multi-platform licensed tennis game with career modes, online play, and a large UI surface built across two interface systems.
Role
Owned most of the UI implementation, built complete game modes, and helped bridge the in-house widget system and NoesisGUI.
Problem
TIEBREAK still depended on the studio's legacy widget framework while other programmers were moving to NoesisGUI, leaving a large amount of UI and entire game modes to be delivered under severe schedule pressure.
Outcome
- Delivered the UI and complete game modes for the initial release and later platform work.
- Kept the existing UI working while the project moved to NoesisGUI.
- Became the main programmer responsible for the legacy widget system.
Approach
- Reverse-engineered the useful behaviours provided by NoesisGUI and reproduced them within the existing in-house widget system.
- Took practical ownership of the legacy UI stack so the rest of the team could move to newer projects without blocking TIEBREAK.
- Coordinated directly with server developers and implemented complete game-mode flows rather than stopping at individual screens.
- Engine
- Proprietary Studio Engine
Capabilities
- Real-time gameplay systems
- Input and responsiveness tuning
- Performance optimisation
- Platform release support and adaptation
- Production QA and optimisation for expansion content
Select an image to enlarge
Work archive / 29 entries
All
projects.
Professional work, personal engines, experiments, and smaller tools.
/01
Crash Twinsanity Improved
A fix-and-polish mod for the PAL release of Crash Twinsanity on PS2 that patches the disc image directly, restoring cut content and improving load times and output.
Direct ISO patching that rebuilds a modded disc image without touching the original · Restored cutscene skipping with an on-screen prompt in five languages · 25-50% faster level loads depending on CDVD configuration
Case study
Crash Twinsanity Improved
A fix-and-polish mod for the PAL release of Crash Twinsanity on PS2 that patches the disc image directly, restoring cut content and improving load times and output.
Role
Solo project, directed rather than hand-written. I chose what to fix, worked out what the patches had to do to the PAL executable, and verified every change in the emulator; the patcher and wiki were largely agent-built to that spec.
Problem
The retail PAL release disabled the cutscene-skip feature before shipping, loads levels slowly, and outputs 480i, and none of these could be fixed from emulator settings alone.
Outcome
- A documented, reproducible mod with a published wiki covering what changed and why, requiring no copyrighted game files in the repository.
How it was built
This one was agent-directed from the start. I drove the reverse-engineering - deciding which cut features were worth restoring, reading the PAL executable's behaviour, and testing each patch in PCSX2 - and used agents to write the Python patcher, the build tooling, and the wiki against that spec. The verification is the part I own: every change here was confirmed running on a patched disc image.
Approach
- Patched the game executable and files inside the ISO directly, restoring sixteen cutscene skips and fixing behaviour such as invincibility masks and crate shadows.
- Wrapped the patches in a Python build script so anyone with their own PAL disc image can produce a patched copy, plus a PCSX2 widescreen and HD texture setup.
- Engine
- None
Capabilities
- Direct ISO patching that rebuilds a modded disc image without touching the original
- Restored cutscene skipping with an on-screen prompt in five languages
- 25-50% faster level loads depending on CDVD configuration
- 480p/60Hz output with frame timing matched to the new mode
- A Python build script and PCSX2 configuration presets
Select an image to enlarge
/02
This Portfolio
The site you are reading - a static Astro build with a filterable project archive, a tabbed case-study overlay, and a CV generated from the same content collection.
Single static page built from a typed Astro content collection of every project · Filterable archive with search, domain and year facets, URL-synced state, and lazy paging · Tabbed case-study overlay with focus trapping, keyboard tab navigation, and image zoom
Case study
This Portfolio
The site you are reading - a static Astro build with a filterable project archive, a tabbed case-study overlay, and a CV generated from the same content collection.
Role
I set the direction, the information architecture, and the editorial standard, and I review every change. The implementation is agent-directed, which is also why this entry exists - it would be strange to label the other projects and quietly leave this one out.
Problem
A portfolio is the one artifact a hiring manager actually reads, and mine had drifted - a stale job title, projects described in dense, unreadable blocks, and claims with no evidence behind them.
Outcome
- Every project now declares how it was built, which is the point of the exercise.
- The CV, the share image, and the shipped-title counts are all derived from the content collection, so they cannot drift from the projects they describe.
How it was built
This site is itself agent-directed work, and disclosing that is the whole reason the label exists. I set the direction, judge the writing, and reject what does not hold up - including the parts of an automated audit that turned out to be wrong. The agent does the implementation and the verification runs: headless browser checks for layout and accessibility, a real build before anything lands. If you want to see how I direct this kind of work rather than read about it, the commit history is public.
Approach
- Ran a parallel read-only audit across positioning, copy, credibility, information architecture, accessibility, and the content model, then verified every finding at the cited line before acting on it.
- Moved editorial rules into the schema - explicit domains, real metrics only, and an authorship field - so a future entry cannot quietly break them.
- Engine
- Astro
Capabilities
- Single static page built from a typed Astro content collection of every project
- Filterable archive with search, domain and year facets, URL-synced state, and lazy paging
- Tabbed case-study overlay with focus trapping, keyboard tab navigation, and image zoom
- One-page CV rendered to PDF from the same sourced content rather than maintained separately
- Authorship metadata on every project so agent-directed work is labelled in the UI
Select an image to enlarge
/03
AetherCore
An editor-first Vulkan game engine for 2D and 3D games, with a GPU-driven renderer, hot-reloadable C# gameplay, owner-authoritative multiplayer with full NAT traversal, and an end-to-end asset and publishing pipeline.
Render graph with bindless descriptors, buffer device address, and GPU-driven draw culling · Tiled lighting with cascaded and local shadows, contact shadows, GTAO, and screen-space reflections · Post-processing stack covering volumetric fog, bloom, depth of field, histogram auto-exposure, and a tonemapper with eight selectable operators
Case study
AetherCore
An editor-first Vulkan game engine for 2D and 3D games, with a GPU-driven renderer, hot-reloadable C# gameplay, owner-authoritative multiplayer with full NAT traversal, and an end-to-end asset and publishing pipeline.
Role
I own the architecture and direct the work. The engine started as hand-written C++ and Vulkan, and as it grew I moved to directing it through multi-agent harnesses - I set the design, the boundaries, and the acceptance criteria, then review, verify, and land the result.
Problem
I wanted the renderer, authoring tools, scripting layer, networking, and shipping workflow to evolve as one usable engine - not become another technically interesting renderer demo that never supported making a game.
Outcome
- Eight projects live in the repository - playable games, a physics sandbox, and a networked multiplayer test bed - so every subsystem is exercised by something being built with it.
- Projects move from imported assets and authored scenes to hot-reloaded gameplay, networked sessions, and packaged standalone builds without leaving the engine workflow.
- Tagging a release publishes a self-contained editor that someone can install and build games with, without a compiler, the Vulkan SDK, or the source repository.
- The Launcher and Editor can be driven and inspected programmatically for reproducible scene authoring, screenshots, diagnostics, and end-to-end validation.
How it was built
AetherCore began as hand-written C++ and Vulkan. As the surface area grew I moved to directing it through agent harnesses (omp, Claude Code) and several models working in parallel, which is how an engine this size stays tractable for one person - subsystems that would have taken weeks land in days. I am the architect and the reviewer rather than the person typing every line: I decide the design and the constraints, the agents implement against them, and nothing merges until it passes the test suite, the GPU abstraction guard, and my own review. The 1,271 tests and the architecture checks in CI exist because that workflow needs a hard verification floor.
Approach
- Kept engine-facing GPU abstractions separate from the Vulkan backend and moved frame data through immutable render packets rather than reading the ECS from the render thread.
- Made reflection a single source of truth for editable component fields across the inspector, scene serializer, script bindings, and editor-control surface.
- Built the editor, standalone Launcher, managed gameplay SDK, diagnostics, and asset pipeline around the same project model so iteration and shipping use the same foundations.
- Designed the netcode so the owner of an entity simulates it - no round trip on your own input and no correction - and made connectivity degrade through a cheapest-first ladder so a game gets LAN play, NAT traversal, and relay fallback without a player ever forwarding a port.
- Treated the engine's own games as the acceptance test, building each subsystem against a project that needed it rather than against a demo scene.
- Engine
- AetherCore
- Graphics API
- Vulkan
Capabilities
- Render graph with bindless descriptors, buffer device address, and GPU-driven draw culling
- Tiled lighting with cascaded and local shadows, contact shadows, GTAO, and screen-space reflections
- Post-processing stack covering volumetric fog, bloom, depth of field, histogram auto-exposure, and a tonemapper with eight selectable operators
- Owner-authoritative multiplayer over ENet - network identity components, session state, and host-to-client and multicast RPCs callable from script
- Cheapest-first connect ladder of LAN broadcast, UPnP/NAT-PMP/PCP port mapping, STUN hole punching, rendezvous signalling, and opt-in TURN relay, with no port forwarding at any rung
- Editor-first 2D and 3D workflow with a standalone project Launcher, dockable viewport and inspectors, and linked prefab instances
- Authoring tools including sprite slicing, animation timelines, chunked tilemaps, a command-based undo system, and autosave with crash recovery
- Hot-reloadable .NET 10 C# gameplay SDK with collectible load contexts, inspector-exposed script fields, F5 rebuild, and one-click Visual Studio debugging
- Managed EditorGui immediate-mode API for writing editor tooling in C#
- Jolt 3D physics and Box2D 2D physics with ragdolls, character controllers, script-driven weld and rope constraints, and colliders generated from sprites and tilemaps
- Retained UI system with per-element custom shaders, inline rich-text effect spans, GPU curve text rendering, text editing, scrolling, and gamepad navigation
- Asset pipeline with glTF ingestion, freshness-checked project-wide baking, texture transcoding, material presets, zstd-compressed engine and project PAKs, and a virtual file system
- Diagnostics with Tracy CPU and GPU instrumentation, a frame timeline panel, tagged allocation tracking over mimalloc with a compile-time tracking ceiling, render-pass timings, and resource inspection
- Built-in MCP server so a coding agent can drive a live editor - managing panels, querying the render graph, capturing screenshots, and entering play mode
Engineering signals
- The public repository carries 1,271 automated test cases across 152 suites covering rendering, physics, scripting, assets, networking, and memory - countable directly from the checked-out source
- CI runs static architecture checks and a Windows build-and-unit pass on every push; editor and runtime GPU smokes run locally as a pre-merge gauntlet
- An automated GPU abstraction guard fails the build when engine code reaches past the abstraction into the Vulkan backend
- The public repository measures roughly 164,000 lines of C++ across 685 files by a direct line count of the source, plus a 13,000-line C# gameplay SDK
- Immutable render-frame extraction keeps the render thread independent from mutable ECS state
- Per-tag allocation counters with a compile-time tracking ceiling, so memory attribution costs nothing in retail builds
- Separate development, ship, and retail build policies keep diagnostics available without leaking them into release builds
- Windows and Linux build presets, with tagged releases producing a self-contained installer that needs no compiler or Vulkan SDK
Select an image to enlarge
/04
RS3 Grand Exchange Analyzer
A Rust desktop application that scores RuneScape 3 Grand Exchange market history to surface profitable item flips, backed by a Python data collection pipeline and SQLite.
Multi-factor flip scoring across ROI, volume, profit, volatility, and data reliability · Automatic filtering of unrealistic flips by volume, ROI, and price sanity bounds · Item tiering from Diamond to Crash based on profitability
Case study
RS3 Grand Exchange Analyzer
A Rust desktop application that scores RuneScape 3 Grand Exchange market history to surface profitable item flips, backed by a Python data collection pipeline and SQLite.
Role
Solo project. I designed the scoring model and the data pipeline and wrote the first version by hand, then moved the build to agent-directed development while keeping the design decisions and the review my own.
Problem
Flipping in the Grand Exchange means guessing which of thousands of items have enough liquidity and spread to be worth trading, from raw price history that gives no guidance.
Outcome
- A working end-to-end pipeline from API collection through to a ranked, filterable list of flips.
How it was built
I wrote the first version by hand and then shifted to directing agents through a harness once the shape of the scoring model was settled. The judgement calls that make it work - which factors to weight, how to log-scale volume, where to cut vendor trash out of the results - are mine; a lot of the implementation and the Rust UI plumbing was agent-written to my spec and reviewed by me.
Approach
- Scored each item with weighted factors, including a logarithmic volume score and a spread penalty, and filtered out data anomalies such as sub-100gp vendor trash.
- Shipped a Rust desktop UI with a Grand Exchange-inspired theme, backed by a Python pipeline that collects and compresses daily market history into SQLite.
- Engine
- None
Capabilities
- Multi-factor flip scoring across ROI, volume, profit, volatility, and data reliability
- Automatic filtering of unrealistic flips by volume, ROI, and price sanity bounds
- Item tiering from Diamond to Crash based on profitability
- Persistent favourites and customisable budget, ROI, and profit filters
- Python collector backfilling market history into SQLite from the Weirdgloop API
/05
Big Ant In-House Tools Suite
Internal tooling and automation suite spanning memory diagnostics, crash reporting, CI/developer workflow scripts, and distributed QA orchestration for large-scale automated game validation.
Internal memory-analysis tool for CSV-driven leak and waste analysis · Internal crash-capture pipeline with WER-based dump/log capture and crash grouping · CSX migration of internal automation scripts from Python
Case study
Big Ant In-House Tools Suite
Internal tooling and automation suite spanning memory diagnostics, crash reporting, CI/developer workflow scripts, and distributed QA orchestration for large-scale automated game validation.
Role
Designed and implemented multiple production tools used by programmers and QA, including memory analysis workflows, crash triage pipelines, script ecosystem migration, and distributed automated crash testing. Each one started with the people who would use it - I sat down with them, wrote up what they actually needed, and documented the finished tool so it did not depend on me.
Problem
Memory investigation, crash triage, release checks, and multi-machine QA all depended on repetitive manual work that made failures slower to reproduce and harder to group.
Outcome
- Reduced the time required to identify recurring crashes and high-impact memory waste.
- Enabled unattended testing across multiple game instances with callstacks and logs delivered directly to the team.
- Consolidated fragile automation into a more maintainable CSX toolchain used across production workflows.
- Tools that teammates adopted and ran themselves, documented well enough that my involvement was not a dependency.
Approach
- Built focused tools around the existing studio workflow instead of asking programmers and QA to adopt an entirely separate platform.
- Converted raw memory and crash data into grouped, searchable evidence that could be acted on without manually inspecting every dump or machine.
- Used Discord and websockets as a lightweight control and reporting surface for distributed automated game validation.
- Worked directly with the programmers and QA who would use each tool, writing up their requirements first so the tool solved the real problem rather than the one I assumed.
- Wrote and maintained usage documentation for every tool so teammates could get a good result without asking me how it works.
- Engine
- Proprietary Studio Engine
Capabilities
- Internal memory-analysis tool for CSV-driven leak and waste analysis
- Internal crash-capture pipeline with WER-based dump/log capture and crash grouping
- CSX migration of internal automation scripts from Python
- Discord-managed distributed QA orchestrator using websockets for multi-instance crash detection
/06
Cricket 26
A multi-platform cricket game released on PC, PlayStation, and Xbox.
Cricket franchise systems support · Multi-platform release workflow · Client-side WebSocket implementation
Case study
Cricket 26
NetworkingProfessional2025
A multi-platform cricket game released on PC, PlayStation, and Xbox.
Role
I fully implemented the title's client-side WebSocket stack, including cross-platform TLS handshake support, and took that networking work through TRC certification for release, alongside building in-house tooling.
Problem
The title needed a production-ready websocket client with secure TLS behaviour that remained consistent across every supported platform and its different networking constraints.
Outcome
- The websocket client and its TLS handshake paths shipped in the released game on PC, PlayStation, and Xbox.
- The title passed platform certification with the networking stack in place.
- The team kept in-house tooling improvements around the release workflow.
Approach
- Implemented the client-side websocket stack and platform-specific TLS handshake path inside the studio engine.
- Worked alongside certification and release requirements so the networking implementation was validated under the same constraints as the shipped game.
- Continued improving in-house tooling around the release workflow rather than treating networking as an isolated feature.
- Engine
- Proprietary Studio Engine
Capabilities
- Cricket franchise systems support
- Multi-platform release workflow
- Client-side WebSocket implementation
- Cross-platform TLS handshake implementation
Select an image to enlarge
/07
Rugby League 26
A rugby league title where I contributed cross-title code integration, in-house tooling support, client-server integration, and certification work across the project lifecycle.
Sports simulation systems · Cross-platform feature delivery · Production gameplay tuning
Case study
Rugby League 26
NetworkingProfessional2025
A rugby league title where I contributed cross-title code integration, in-house tooling support, client-server integration, and certification work across the project lifecycle.
Role
I handled cross-title code integration, supported the team's in-house tooling, worked on client-server integration, and carried TRC certification work across the project lifecycle.
- Engine
- Proprietary Studio Engine
Capabilities
- Sports simulation systems
- Cross-platform feature delivery
- Production gameplay tuning
- Ongoing franchise support
Select an image to enlarge
/08
Fly
Modern audio player with real-time visualisation, spatial audio control, and advanced audio processing using OpenAL-Soft and ImGui.
Multi-format audio support (MP3, WAV, FLAC) · Real-time FFT-based visualisation · Spatial 3D audio positioning
Case study
Fly
Modern audio player with real-time visualisation, spatial audio control, and advanced audio processing using OpenAL-Soft and ImGui.
Role
C++ audio systems developer.
- Engine
- Native C++ WinApp
Capabilities
- Multi-format audio support (MP3, WAV, FLAC)
- Real-time FFT-based visualisation
- Spatial 3D audio positioning
- Advanced audio effects (Bass, Treble, Pitch, Normalization)
- Playlist management
- Presets (Chipmunk mode, Slowed mode)
Select an image to enlarge
/09
Odyssean-Engine
A modular 2D/3D game engine framework with OpenGL and Vulkan backends and physically based rendering - the predecessor step in my engine lineage that led to AetherCore, where I first learned cross-API renderer architecture and modular subsystem integration.
OpenGL and Vulkan backends · Physically Based Rendering (PBR) · Modular system integration
Case study
Odyssean-Engine
A modular 2D/3D game engine framework with OpenGL and Vulkan backends and physically based rendering - the predecessor step in my engine lineage that led to AetherCore, where I first learned cross-API renderer architecture and modular subsystem integration.
Role
Engine systems and rendering architecture.
- Engine
- Odyssean Engine
- Graphics API
- OpenGL
Capabilities
- OpenGL and Vulkan backends
- Physically Based Rendering (PBR)
- Modular system integration
- 2D and 3D runtime support
Select an image to enlarge
/10
AFL 26
A multi-platform AFL title where I brought the game's gameplay systems up to date with newer studio titles, integrated PlayFab, and fixed server-side issues during production.
Ongoing sports franchise support · Multi-platform release delivery · Gameplay and systems iteration
Case study
AFL 26
NetworkingProfessional2025
A multi-platform AFL title where I brought the game's gameplay systems up to date with newer studio titles, integrated PlayFab, and fixed server-side issues during production.
Role
I ported and merged gameplay systems from newer studio titles into the AFL codebase, integrated PlayFab online services, and tracked down and fixed server-side bugs introduced by the merge process.
Problem
The AFL codebase had fallen behind newer titles in the studio and needed its gameplay systems brought up to date, with working online services, in time for release.
Approach
- Pulled updated gameplay systems from newer studio projects and merged them into the AFL codebase.
- Integrated PlayFab to provide the title's online services.
- Tracked down and fixed server-side bugs introduced through the merge process.
- Engine
- Proprietary Studio Engine
Capabilities
- Ongoing sports franchise support
- Multi-platform release delivery
- Gameplay and systems iteration
- Production bug fixing and polish
Select an image to enlarge
/11
EnetPlayGround
Networking sandbox where I worked through ENet, reliable UDP communication, and client-server architecture patterns - the groundwork that later fed AetherCore's netcode.
Concurrent multi-client connection management on a threaded server · Reliable packet delivery implementation · Broadcast messaging infrastructure
Case study
EnetPlayGround
Networking sandbox where I worked through ENet, reliable UDP communication, and client-server architecture patterns - the groundwork that later fed AetherCore's netcode.
Role
Networking systems programmer.
- Engine
- C++ Networking Framework
Capabilities
- Concurrent multi-client connection management on a threaded server
- Reliable packet delivery implementation
- Broadcast messaging infrastructure
- Reconnection handling and client state synchronization
- MySQL database integration
- Plugin architecture support
- Position visualisation
- Comprehensive logging system
Select an image to enlarge
/12
RenderAlchemy
OpenGL-powered colour grading laboratory experimenting with HDR rendering, CLUT workflows, and post-processing effects.
Real-time 3D rendering with customisable camera · Advanced colour grading using 1D and 3D CLUTs · HDR rendering with multiple tone mapping operators
Case study
RenderAlchemy
OpenGL-powered colour grading laboratory experimenting with HDR rendering, CLUT workflows, and post-processing effects.
Role
Graphics programmer and tooling designer.
- Engine
- Custom OpenGL
- Graphics API
- OpenGL
Capabilities
- Real-time 3D rendering with customisable camera
- Advanced colour grading using 1D and 3D CLUTs
- HDR rendering with multiple tone mapping operators
- Split-screen comparison for before/after views
- Dear ImGui-powered UI
Select an image to enlarge
/13
CSX-Forms
A C# scripting library that turns plain CSX scripts into styled WinForms applications with DPI scaling, dark mode, and rounded corners.
WindowManager class for building forms from CSX scripts with a single · Automatic DPI scaling based on system settings · Dark mode detection and theming that follows the Windows theme
Case study
CSX-Forms
A C# scripting library that turns plain CSX scripts into styled WinForms applications with DPI scaling, dark mode, and rounded corners.
Role
Solo developer.
Problem
C# scripting with dotnet-script is convenient for utilities, but CSX files have no easy way to get a presentable windowed UI without dragging in a full project.
Outcome
- Windowed C# scripting utilities that match the Windows theme without any project scaffolding.
Approach
- Packaged WinForms setup, theming, and keyboard shortcut handling into a loadable Window.csx so a script stays a script.
- Engine
- None
Capabilities
- WindowManager class for building forms from CSX scripts with a single
- Automatic DPI scaling based on system settings
- Dark mode detection and theming that follows the Windows theme
- Rounded corners on Windows 10 and above
- Worked examples in the repository's examples directory
/14
Rugby 25
A multi-platform rugby title where I brought an ageing codebase up to date with newer studio systems, handled client-to-server integration, and cleared the title through platform certification.
Sports gameplay systems · Platform release support · Iterative production polish
Case study
Rugby 25
NetworkingProfessional2025
A multi-platform rugby title where I brought an ageing codebase up to date with newer studio systems, handled client-to-server integration, and cleared the title through platform certification.
Role
I merged systems from multiple newer titles into the older Rugby codebase, patched the resulting conflicts and regressions, handled client-to-server integration, and put in the TRC certification work needed to get this legacy codebase through platform submissions.
- Engine
- Proprietary Studio Engine
Capabilities
- Sports gameplay systems
- Platform release support
- Iterative production polish
- Team-based feature integration
Select an image to enlarge
/15
CppOdyssey
A Jekyll-based documentation website covering C++ development - from project setup and fundamentals through to advanced topics like building Vulkan game engines.
C++ project setup guides · Step-by-step Vulkan tutorials · Code examples with commentary
Case study
CppOdyssey
A Jekyll-based documentation website covering C++ development - from project setup and fundamentals through to advanced topics like building Vulkan game engines.
Role
Technical writer and systems educator.
- Engine
- Jekyll + GitHub Pages
Capabilities
- C++ project setup guides
- Step-by-step Vulkan tutorials
- Code examples with commentary
- Hosted on GitHub Pages with just-the-docs theme
Select an image to enlarge
/16
Tycoon
Co-developed Lua/Love2D game project exploring what it is like to build a full game entirely in Lua, with Declan owning major AI agent systems while I handled gameplay systems, tools, integration, and art.
Full game loop and state machine built in Lua · Multi-region progression systems with upgrade and resource mechanics · Clicker/tycoon gameplay with active and passive income flow
Case study
Tycoon
Co-developed Lua/Love2D game project exploring what it is like to build a full game entirely in Lua, with Declan owning major AI agent systems while I handled gameplay systems, tools, integration, and art.
Role
Co-developer with Declan. Declan led AI agent development and behaviour systems; I led gameplay systems, tools, integration, and art.
- Engine
- LÖVE (Love2D)
Capabilities
- Full game loop and state machine built in Lua
- Multi-region progression systems with upgrade and resource mechanics
- Clicker/tycoon gameplay with active and passive income flow
- Skill tree, save/load persistence, and menu/settings flows
- Steam integration for achievements, stats, invites, and rich presence
- AI agent behaviour systems developed by Declan
Select an image to enlarge
/17
TIEBREAK
A multi-platform licensed tennis game with career modes, online play, and a large UI surface built across two interface systems.
Real-time gameplay systems · Input and responsiveness tuning · Performance optimisation
Case study
TIEBREAK
A multi-platform licensed tennis game with career modes, online play, and a large UI surface built across two interface systems.
Role
Owned most of the UI implementation, built complete game modes, and helped bridge the in-house widget system and NoesisGUI.
Problem
TIEBREAK still depended on the studio's legacy widget framework while other programmers were moving to NoesisGUI, leaving a large amount of UI and entire game modes to be delivered under severe schedule pressure.
Outcome
- Delivered the UI and complete game modes for the initial release and later platform work.
- Kept the existing UI working while the project moved to NoesisGUI.
- Became the main programmer responsible for the legacy widget system.
Approach
- Reverse-engineered the useful behaviours provided by NoesisGUI and reproduced them within the existing in-house widget system.
- Took practical ownership of the legacy UI stack so the rest of the team could move to newer projects without blocking TIEBREAK.
- Coordinated directly with server developers and implemented complete game-mode flows rather than stopping at individual screens.
- Engine
- Proprietary Studio Engine
Capabilities
- Real-time gameplay systems
- Input and responsiveness tuning
- Performance optimisation
- Platform release support and adaptation
- Production QA and optimisation for expansion content
Select an image to enlarge
/18
SlimeProject
A Vulkan-based game engine (SlimeOdyssey) paired with a 2D platformer game - built to explore modern Vulkan 1.3 features, ECS architecture, and PBR rendering across Windows, Linux, and macOS.
Vulkan 1.3 renderer with vk-bootstrap and VulkanMemoryAllocator · Entity Component System (ECS) architecture · Physically Based Rendering (PBR)
Case study
SlimeProject
A Vulkan-based game engine (SlimeOdyssey) paired with a 2D platformer game - built to explore modern Vulkan 1.3 features, ECS architecture, and PBR rendering across Windows, Linux, and macOS.
Role
Engine and gameplay programmer, co-developed with Connor Young.
- Engine
- SlimeOdyssey (custom)
- Graphics API
- Vulkan
Capabilities
- Vulkan 1.3 renderer with vk-bootstrap and VulkanMemoryAllocator
- Entity Component System (ECS) architecture
- Physically Based Rendering (PBR)
- Cross-platform support (Windows, Linux, macOS)
- ImGui integration for in-engine debugging
- SPIRV-Cross shader reflection
- 2D platformer game with moving platforms and power-ups
- Automated multi-platform CI build pipeline
Select an image to enlarge
/19
DreadedEscape
An unfinished weekend prototype where two friends and I got co-op multiplayer, Steamworks sessions, and a playable map running in Unreal Engine 5.
Co-op multiplayer sessions in Unreal Engine 5 · Steamworks session and menu flow · House map and terrain built for puzzle traversal
Case study
DreadedEscape
An unfinished weekend prototype where two friends and I got co-op multiplayer, Steamworks sessions, and a playable map running in Unreal Engine 5.
Role
One of three people on a weekend project. I set up the UE5 project and Git LFS pipeline, wired the main menus and Steamworks session flow, stood up the multiplayer layer, and built the house map and terrain. Declan Rogers designed the game and contributed map and programming work; Connor Young maintained the build automation.
Problem
I wanted hands-on time with Unreal Engine 5's multiplayer and Steamworks session stack rather than reading about it, so we gave ourselves a weekend and a co-op horror premise to force the work.
Outcome
- Got co-op sessions, menus, and a traversable map working, which is where the project stopped - it was never finished and is not a shipped game.
- Came away with practical experience of UE5's replication and Steamworks session model, which is the reason it is listed here.
Approach
- Bootstrapped the UE5 project, Git LFS asset handling, and a CI build workflow so three people could work on one codebase immediately.
- Built the session and menu flow on Steamworks, then the map the puzzles were meant to live in.
- Engine
- Unreal Engine 5
Capabilities
- Co-op multiplayer sessions in Unreal Engine 5
- Steamworks session and menu flow
- House map and terrain built for puzzle traversal
- Git LFS and GitHub Actions build pipeline for a three-person team
/20
Cricket 24
A multi-platform cricket title where I built UI screens, fixed state-flow issues, integrated PlayFab and PlayGo, and worked on TRC certification.
Gameplay systems · Content and rules integration · Performance-minded feature work
Case study
Cricket 24
A multi-platform cricket title where I built UI screens, fixed state-flow issues, integrated PlayFab and PlayGo, and worked on TRC certification.
Role
I built a large number of UI screens, resolved state-flow issues, and implemented PlayFab and PlayGo online features, then carried the TRC certification work needed for the title to pass platform submissions.
- Engine
- Proprietary Studio Engine
Capabilities
- Gameplay systems
- Content and rules integration
- Performance-minded feature work
- Production tooling collaboration
Select an image to enlarge
/21
AFL 23
A licensed AFL game where I took ownership of the in-house UI backend, built frontend screens, and contributed to the Academy player creation system.
Game feature implementation · Bug fixing and polish · Cross-team integration
Case study
AFL 23
A licensed AFL game where I took ownership of the in-house UI backend, built frontend screens, and contributed to the Academy player creation system.
Role
Implemented and maintained the UI backend powering every screen in the game, built numerous frontend screens, and contributed to the Academy player creation system.
- Engine
- Proprietary Studio Engine
Capabilities
- Game feature implementation
- Bug fixing and polish
- Cross-team integration
- Performance-conscious delivery
Select an image to enlarge
/22
Cvar Testing
C++ sandbox project for prototyping a runtime command console that can execute custom commands in a live application without relying on a GUI.
Runtime command console integrated directly into the application loop · CVar-style command registration and parsing pipeline · Custom commands for driving behaviour and triggering code paths at runtime
Case study
Cvar Testing
C++ sandbox project for prototyping a runtime command console that can execute custom commands in a live application without relying on a GUI.
Role
Solo engine tools programmer.
- Engine
- Custom C++ Application
Capabilities
- Runtime command console integrated directly into the application loop
- CVar-style command registration and parsing pipeline
- Custom commands for driving behaviour and triggering code paths at runtime
- Lightweight workflow for debugging and iteration without building UI panels
Select an image to enlarge
/23
Early Work (2019-2022)
The learning projects that preceded my engine and graphics work, built alongside an Advanced Diploma of Professional Game Development at AIE Melbourne, plus a lot of self-taught C++ and Unity work in my own time.
Shop Game (2019) - text-based console market simulator with dynamic item pricing, my first exercise in classes, structs, and reusable C++ · Simon (2019) - memory game built on an update/draw loop with class-driven state flow and a custom DynamicArray template · SlimeCube (2022) - OpenGL viewer that loaded complex meshes and simulated PBR materials, with ImGui controls and CMake cross-platform builds
Case study
Early Work (2019-2022)
GameplayHobby2022
The learning projects that preceded my engine and graphics work, built alongside an Advanced Diploma of Professional Game Development at AIE Melbourne, plus a lot of self-taught C++ and Unity work in my own time.
- Engine
- Unity, AIE Bootstrap, console C++, WinForms (.NET), and OpenGL
Capabilities
- Shop Game (2019) - text-based console market simulator with dynamic item pricing, my first exercise in classes, structs, and reusable C++
- Simon (2019) - memory game built on an update/draw loop with class-driven state flow and a custom DynamicArray template
- SlimeCube (2022) - OpenGL viewer that loaded complex meshes and simulated PBR materials, with ImGui controls and CMake cross-platform builds
- Unity and C# projects (2019-2020) - a resource-management game, a roguelike, a hex-grid strategy prototype, a VR shooter, and cross-platform and UI test beds
/24
Cricket 22
My first shipped professional title, a AAA cricket game where I fixed bugs across the game during its production cycle.
Sports gameplay systems · Broad platform support · Production QA and optimisation
Case study
Cricket 22
GameplayProfessional2022
My first shipped professional title, a AAA cricket game where I fixed bugs across the game during its production cycle.
Role
I implemented bug fixes across the game during its production, working within a broad multi-platform AAA sports title as my first professional credit.
- Engine
- Proprietary Studio Engine
Capabilities
- Sports gameplay systems
- Broad platform support
- Production QA and optimisation
- Franchise feature continuation
Select an image to enlarge
/25
Frozen Depths
Technical research project exploring procedural terrain and mesh generation with the Marching Cubes algorithm.
Marching Cubes mesh extraction · Procedural terrain generation · Real-time mesh updates
Case study
Frozen Depths
Technical research project exploring procedural terrain and mesh generation with the Marching Cubes algorithm.
Role
Graphics and systems programmer focused on procedural generation.
- Engine
- Unity
Capabilities
- Marching Cubes mesh extraction
- Procedural terrain generation
- Real-time mesh updates
- Simulation-driven world shaping
Select an image to enlarge
/26
2D Unnamed Game
Experimental OpenGL 2D game framework focused on physics, sprite rendering, text rendering, and texture atlasing.
2D physics and collision systems · Sprite and text rendering pipeline · Texture atlas workflow
Case study
2D Unnamed Game
Experimental OpenGL 2D game framework focused on physics, sprite rendering, text rendering, and texture atlasing.
Role
Solo developer building gameplay and rendering systems.
- Engine
- Custom 2D Engine
- Graphics API
- OpenGL
Capabilities
- 2D physics and collision systems
- Sprite and text rendering pipeline
- Texture atlas workflow
- Input and gameplay loop prototyping
Select an image to enlarge
/27
PBR Renderer
OpenGL renderer implementing a physically based rendering pipeline with multi-texture material support.
Physically based rendering · Multi-texture material system · Real-time lighting
Case study
PBR Renderer
GraphicsOpenGLHobby2021
OpenGL renderer implementing a physically based rendering pipeline with multi-texture material support.
Role
Solo graphics programmer.
- Engine
- Custom Renderer
- Graphics API
- OpenGL
Capabilities
- Physically based rendering
- Multi-texture material system
- Real-time lighting
- Model rendering pipeline
Engineering signals
- Supports up to six textures per model
Select an image to enlarge
/28
Fluid & Noise Simulations
Two C++ cellular automata experiments - a 2D liquid physics simulator and a noise-driven procedural world generator.
2D liquid physics via cellular automata · Procedural world generation with noise · Real-time simulation stepping
Case study
Fluid & Noise Simulations
Two C++ cellular automata experiments - a 2D liquid physics simulator and a noise-driven procedural world generator.
Role
Simulation and procedural systems programmer.
- Engine
- C++ Simulation
- Graphics API
- OpenGL
Capabilities
- 2D liquid physics via cellular automata
- Procedural world generation with noise
- Real-time simulation stepping
- Cellular automata rule systems
Select an image to enlarge
/29
PixelEdit
WinForms image editor project built to learn how desktop applications are structured, while exploring core algorithms needed for practical editing tools.
Bresenham-style line rasterization for drawing tools · Queue-based flood fill implementation for bucket behaviour
Case study
PixelEdit
WinForms image editor project built to learn how desktop applications are structured, while exploring core algorithms needed for practical editing tools.
Role
Solo programmer.
- Engine
- Windows Forms (.NET Framework)
Capabilities
- Bresenham-style line rasterization for drawing tools
- Queue-based flood fill implementation for bucket behaviour
Select an image to enlarge
No projects match the current filter set.