Summary
A sci-fi action horror campaign, released on Meta Quest in October 2025 by Patient 8 Games and patched through sixteen releases. Large by standalone VR standards: 119 scenes across 17 connected areas, fifteen enemy types, and a branching save system with a New Game Plus mode. Four years in development.
I was lead developer and principal programmer. For long stretches of production I was the only programmer on the project, and roughly 78 per cent of the codebase is mine: 622 scripts and about 78,000 lines across 26 distinct systems.
The problem
Standalone VR is the hardest target in consumer games. The headset is a mobile chip strapped to someone’s face, it has to hold frame rate or people feel physically unwell, and it has a fraction of the memory a PC game assumes. Almost every technical decision on this project was downstream of that.
The game also had to be big. A short, contained VR experience can sidestep most of these problems. A seventeen-area facility with a branching save system cannot.
What I built
Everything except art, writing, audio and boss AI. Concretely: the save and serialisation system, level streaming and the addressable content architecture, the entire weapon framework, VR player movement and interaction, animation programming, the enemy AI foundation and squad coordination, all progression and unlock systems, the in-game tools and puzzles, and about six thousand lines of custom editor tooling built to solve problems this production kept hitting.
Four pieces are worth pulling out.
Failure that is survivable. In a long single-player game, a corrupted save is a player losing twenty hours. So the save system validates and repairs rather than trusting: damaged or out-of-date files are recovered where possible, and the player is told honestly where they are not, instead of the game crashing on load or quietly wiping a run. The save contract is version-tolerant by design, so shipping a patch does not invalidate saves written by the previous build.
The hardest part was restoring weapons. Because guns in this game are physical objects you handle – magazines you push in, chambers that hold individual shells, break actions you swing open – restoring a save means re-spawning the weapon and then driving its physical state back to what it was, waiting on the VR physics to settle before each step. It is a lot of machinery to make loading a game look like nothing happened.
Streaming a large world onto a mobile headset. 119 scenes loaded as addressable references, with content split into 37 area-scoped bundles so memory stays bounded to the part of the facility the player is in. Transitions fade the world out, stream the next area behind a progress bar, wait for the graphics to be genuinely ready rather than merely loaded, and hand control back. Getting the readiness gate right is the difference between a clean transition and a lurch.
Holding frame rate structurally, not cosmetically. Shaders are compiled and warmed before the player sees anything, so no effect stutters the first time it appears. Enemies switch themselves off at distance, coordinated centrally on a slow tick rather than each agent thinking every frame. Doors act as occlusion boundaries so the headset never renders rooms it cannot see. Render settings are tuned separately for Quest 2 and Quest 3 rather than shipping one lowest-common-denominator compromise, and the game issues sustained-performance hints and reacts to thermal notifications at runtime.
Accessibility that shipped. A complete left-handed play mode – every weapon, tool, holster and grab point mirrored, switchable from a setting rather than a separate build – plus colour-blind filters, seated and standing modes, snap and smooth turning, teleport and stick locomotion, subtitle controls, and automatic height recalibration when the play space drifts. Most VR titles skip left-handed support because it touches nearly every interactive object in the game. This one has it.
Technical detail
For the engineer reading this rather than the producer.
The project is Unity 2022.3 LTS on URP, targeting Android ARM64 for Quest and Windows standalone, with separate renderer assets per device tier and around forty per-area post-process profiles.
The VR layer extends a commercial interaction framework rather than replacing it,
and in several places corrects it – the teleporter, for instance, maintains its
own overlap sets to synthesise trigger exit events the framework drops when you
teleport out of a volume. Procedural arms run a FABRIK solver with an explicit
elbow-constraint plane and target smoothing on reacquisition. Enemy locomotion
synchronises navigation agent velocity against animator parameters through
OnAnimatorMove so nothing skates.
AI is a shared behaviour base under fifteen archetypes driving 25 behaviour trees, with a central coordinator handling awareness, sound propagation and distance-disable on a configurable tick. Cover positions are claimed through a static registry with distance-keyed reservation and explicit release, so enemies do not contend for the same doorway.
The save layer gathers and re-applies state across roughly fifteen subsystem managers through a version-tolerant binary contract, with a pure static validate-and-repair pass that raises a corruption event to the UI rather than throwing, and a migration path for pre-versioning saves.
The editor tooling exists because a 37-group addressables architecture is fragile: bundles break, assets silently duplicate across groups, and references go missing after merges. Backup, validation and restore of the whole addressables configuration turns a build-breaking accident into a five-minute fix.
Credit where it is due
Nine people committed code to this project. The audio integration, the boss AI, the graphics settings layer, two render features, the shader prewarm system and the largest of the content-repair tools were written by other members of the team, and all of the art, animation content and writing was theirs. The environment art, creature models and motion library are licensed asset packs. The VR interaction framework underneath my player systems is a commercial product, authored by someone who also contributed to the project directly.