ProjectOmega — Director & R&D Lead on an AI-Built UE 5.8 Co-op Multiplayer Game
- ▸ A game I had wanted to make for years, with a scope too big for one programmer, became the experiment: can my AI systems build and maintain a genuinely complicated multiplayer game? GAS, custom movement, voxel systems, server authority, pure C++.
- ▸ Four server-authoritative slices signed off in under a month, each accepted only after a hands-off packaged run with a host and a joined client. I wrote none of the code.
- ▸ I wrote the game design documentation the agents build from, and I direct and verify: scope, architecture constraints, acceptance criteria, sign-off, and playtesting every slice myself.
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
AI agents do the work, reviewed by models from other vendors
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
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.
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:
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.
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