ProjectOmega — Director & R&D Lead on an AI-Built UE 5.8 Co-op Multiplayer Game

Role: Director & R&D Lead · AI-First Experiment · Duration: Aug 2026 – present ·Team: Solo + AI agents · Engine: UE5 ·Platforms: Windows · In Development
UE5 C++ GAS StateTree Push Model Voxel Systems Automation Testing

The Question

Anyone can demo an AI writing code. The question I wanted answered is harder: can an AI pipeline build and maintain a genuinely complicated system over months, without a human writing any of the code?

ProjectOmega is a game I had wanted to make for years: a server-authoritative co-op action game whose scope was always too big for one programmer. That made it the right candidate for the experiment. Built in pure UE 5.8 C++ with no Blueprints, its design calls for the things that usually break AI-written code:

  • In the design

    Gameplay Ability System

    GAS is demanding even for experienced engineers. Its prediction, replication and activation rules punish a confident guess.

  • In the design

    Custom movement, off the navmesh

    Unreal's navigation assumes enemies walk on floors. This one crawls walls and ceilings, which means a bespoke navigation and movement system rather than engine defaults.

  • In the design

    Voxel systems

    Runtime-generated, destructible geometry that has to stay consistent between a host and a joined client.

  • In the design

    Server authority throughout

    Multiplayer state is where AI-written code quietly fails: it compiles, passes a smoke test, and disagrees between machines under load.

Results So Far

  • Four gameplay slices signed off in under a month: input and combat authority, the reward and run-outcome path, enemy navigation, and the first weapon.
  • Every slice accepted in a packaged host + client run. The bar is two machines agreeing on the game state.
  • A wall-and-ceiling-crawling enemy on a purpose-built navigation module, from first spike to sign-off in four days.
  • Tests written before the code on every slice, and run on a real map before any packaged build.

My Role

I wrote the game design documentation and none of the code. The design canon is mine: the game design document, system designs, player-role fantasies and technical contracts, over 200,000 words that every spec is grounded in. Per slice I set the scope, the architecture constraints it has to respect, and what done means. Then I verify the result and either sign it off or send it back, and I play every slice myself before accepting it.

That division is the experiment. If I patch the output by hand, the result stops answering the question.

How a Slice Gets Built

01 Choose I pick the next slice to build.

AI agents do the work, reviewed by models from other vendors

02 Spec A short spec of what the slice must do, drawn from my design docs and reviewed until the models agree.
03 Plan An implementation plan, reviewed the same way.
04 Build Tests first, then the code, then a code review.
05 Verify Package it and run it with a host and a joined client.
06 Sign off I play the packaged build. If it holds up, the slice is done.
One feature slice, start to finish. The agents do the middle; I own both ends.

The decisions at either end are mine, and so is the design documentation every spec is drawn from. Everything between them is the pipeline, driven from Codex: GameCodeGolem so the agents check Unreal’s actual behaviour instead of recalling it, and VibeSlice for the workflow and cross-model review.

  1. Aug 22 Process dry run ~4.5 hours

    Ran the whole sign-off path before any gameplay code existed, including killing a session mid-slice and resuming it from saved state. Accepted as operations only, with no gameplay shipped.

  2. Aug 26 Input & combat authority 3 days

    Two players move, look, jump, and sprint with stamina. Jump and Sprint are server-activated GAS abilities, on Push Model replication.

  3. Sep 2 Rewards & run outcomes 6 days

    A full co-op run: grab the pickup, go down at 0 HP with a 30 s bleed-out, get revived with a 3 s channel, then wipe or reach the exit.

  4. Sep 7 Wall-crawling enemy 4 days

    A defender crawls over a wall and across the ceiling to cut players off, telegraphs every attack, and returns to its post.

  5. Sep 15 First weapon 8 days

    A server-checked hitscan weapon with state on the PlayerState. Diagnosing blocked shots found muzzle parallax overriding the camera hit target. Balance values remain provisional.

  6. Now Voxel publication seam 4 weeks and counting

    Selected on 15 September as a scope test: one slice whose spec and plan are each larger than the four above combined. Twelve days to freeze the spec and plan. The build got most of the way through its plan, then stalled in verification, where it has been for two weeks.

Each of the four signed-off slices was accepted in a packaged build with a host and a joined client.

What Came Out

The wall-crawling enemy is the clearest test of the premise. Unreal’s navmesh wouldn’t carry it, so the pipeline produced a surface graph spanning floors, walls and ceilings, with the enemy’s “up” rotating as it moves between them. Behaviour runs server-only and replicates with smoothing.

Packaged build, first-person view: an orange enemy block clings to a vertical wall, its AGGRO label rotated with it. A debug readout in the corner shows the host player's health at 40.
Packaged build: the defender clinging to a wall mid-intercept. The host's health readout drops as its attacks land.
Three packaged-build frames side by side: the enemy block in red labelled AGGRO, the same block in yellow labelled WIND-UP, and a downed player marker next to it labelled DOWNED.
Pursuit, a telegraphed wind-up, and five hits later, a downed player.

Tests are written before the code, and the rules are tested on their exact edges. That is the sort of thing an unsupervised agent skips and a reviewed one doesn’t:

OmegaEnemyTest.cpp Pipeline output — boundaries tested on both sides
TestFalse(TEXT("just outside the attack boundary"),
	Defender->BeginWindUpForTest(EOmegaEnemyWindUpOrigin::Pursue, 0.0));
// … target moved to the exact boundary
TestTrue(TEXT("inclusive boundary begins WindUp"),
	Defender->BeginWindUpForTest(EOmegaEnemyWindUpOrigin::Pursue, 0.0));
TestFalse(TEXT("callback before the deadline deals zero damage"), /* … */);
TestTrue(TEXT("callback at the exact deadline commits damage"), /* … */);

Multiplayer state got the most scrutiny. The slice covering downs, revives and rewards went back twice before I accepted it, with a clean package and a full rerun of every scenario each time. Clients resend requests the server has already handled, so the reward path treats a repeat as a transaction it has already seen: acknowledged again, never granted twice.

Two packaged game windows side by side. On the host (left) and the joined client (right), player 1 is shown as downed, with matching debug readouts of health, state, and bleed-out timer.
Packaged two-player run: the host and the joined client agree that player 1 is downed.

What the Experiment Has Shown

  • It holds at this scale

    Four slices in under a month, no hand-written code

    Each reviewed across several models and proven in a packaged two-player build. The pipeline has kept that pace and that standard for the whole run so far.

  • It needs a hard bar

    Review alone is not enough

    Reviewers argue confidently about code none of them has run. A misspelled console command survived three rounds and was only caught when it executed, and one build silently used the wrong map.

  • It needs grounding

    Checked against engine source

    A challenged call chain was verified in UE 5.8 source rather than taken on faith, which surfaced a default replication rate that would have made one test unable to fail.

  • Scope test

    One slice bigger than the four before it combined

    The voxel slice is a deliberate trial of whether the pipeline can deliver a feature of that size in one pass instead of in chunks. Its spec and plan each outweigh the four signed-off slices put together. Four weeks in, the spec took twelve days to freeze against two to five before, and the build got most of the way through its plan before stalling in verification for the last two weeks. So far the answer favours chunks.

Tools & Tech

Unreal Engine 5.8, C++, Gameplay Ability System, StateTree, Push Model replication, voxel systems, Unreal Automation Testing, Unreal Editor MCP, Codex CLI, Git. Built by agents on Codex working through GameCodeGolem, run and reviewed through VibeSlice.

Curious what a directed AI pipeline can actually ship?

Tell me what you're building and what you need. I typically respond within 24–48 hours.

Start a Conversation