Cross-Game Intelligence: How One Repo Makes Four AI-Built Games Better

We merged four independent game repositories into one. A breakout game, an RPG, a shmup, and a survival horror game — 381 commits of history, four autonomous AI agents, all converged into a single git repo.

The merge itself was mechanical. What happened after was the interesting part.

The Problem With Separate Repos

Each game in the Dark Factory had its own repo, its own agent, its own evolution. The agents build games in Love2D, where every game has a similar structure: main.lua delegates to src/game.lua, shared utilities live in src/gfx.lua and src/audio.lua, and the game-specific logic fills in everything else.

Here’s what we found when we put them side by side:

Voidrunner’s graphics module was twice the size of the next largest. It had evolved glowLine, shockwave, scanlines, vignette, screen shake with configurable falloff, and a full trail rendering system. None of the other games had any of these.

Meanwhile, Dreadnought’s audio module was a monster — 80+ procedurally synthesized sound effects, spatial audio with distance falloff, environmental ambience generators. The shmup and breakout games were still working with basic tone/sweep/noise.

Each game was solving the same problems independently, arriving at different solutions of wildly different quality. They couldn’t see each other’s work. The orchestrator couldn’t compare them. Nobody was backporting improvements.

What a Monorepo Enables

With everything in one repo, the studio orchestrator — the agent that manages all four games — gained three new capabilities overnight:

1. Factory-Wide Visibility in One Command

Before:

# Check each game separately (4 commands, 4 different repos)
git -C ~/games/polybreak log --oneline -3
git -C ~/games/chronostone log --oneline -3
git -C ~/games/voidrunner log --oneline -3
git -C ~/games/dreadnought log --oneline -3

After:

# Everything in one view
git log --oneline --since="3 hours ago" -- games/

# Commit velocity per game
git shortlog --summary --since="24 hours ago" -- games/

One command reveals which games are active, which are stale, and where the development energy is going. If Dreadnought had 12 commits and Polybreak had zero, the orchestrator sees that immediately and can rebalance.

2. Pattern Backporting

This is the real payoff. The orchestrator can now compare implementations:

diff games/polybreak/src/gfx.lua games/voidrunner/src/gfx.lua

When it sees that Voidrunner has a Gfx.shake() function and Polybreak doesn’t, it can create a specific handoff:

“Backport Gfx.shake from voidrunner/src/gfx.lua (line 274). Signature: shake(amount, duration). Use it on boss death (magnitude 6px, duration 0.3s) and ball-loss events (magnitude 3px, duration 0.15s). Read Voidrunner’s implementation — it uses sine decay with configurable falloff. Adapt to Polybreak’s coordinate system, commit.”

That’s not “consider adding screen shake.” That’s a complete engineering brief with source file, line number, function signature, and two concrete integration points. The receiving agent has everything it needs to execute in a single cycle.

Pattern backporting turns every game’s improvements into a force multiplier. When one agent invents a better particle system, all four games get it. When one agent solves spatial audio, the technique propagates. The studio doesn’t just manage four independent games — it manages a shared body of knowledge that grows every cycle.

3. Shared Bug Detection

We hit this one the hard way. A rendering bug in Polybreak — bricks appearing as tiny dots — was caused by animation timers trapped inside a conditional block that only ran during boss fights. The timer never decremented on regular levels, so the scale factor was permanently zero.

The fix was simple: move the timer decrement outside the conditional. But the pattern — timers gated by state checks they shouldn’t be inside — could exist in any of the four games. With a monorepo, the orchestrator can check:

grep -rn "spawn_t.*dt" games/*/src/
grep -rn "hit_t.*dt" games/*/src/

If the pattern appears in another game, the orchestrator creates a fix handoff with the exact bug description, the commit that fixed it in the source game, and the code change needed. One debugging session benefits four codebases.

Real Backporting Opportunities We Found

When we first compared the four games’ shared modules, the asymmetries were striking:

Voidrunner → Everyone else:

• Gfx.glowLine(x1,y1,x2,y2,r,g,b,thickness,glowSize) — laser beams, connection lines, UI borders with glow. Nobody else has it.
• Gfx.shockwave(cx,cy,radius,r,g,b,alpha,thickness) — expanding ring effect on explosions. Universal appeal.
• Gfx.scanlines(w,h,alpha,spacing) — CRT effect for retro aesthetic. All four games have a retro/sci-fi theme.
• Gfx.vignette(w,h,intensity) — screen edge darkening. Horror game (Dreadnought) needs this most.
• Gfx.shake/updateShake/getShakeOffset — screen shake with sine decay. Every action game needs this.
• Gfx.newTrail/updateTrail/drawTrail — motion trails for fast-moving entities. Useful for Polybreak (ball), Dreadnought (player movement).

Dreadnought → Everyone else:

• Audio.playAt(source,sx,sy,px,py,pa,maxDist,volMul) — spatial audio with distance falloff and directional panning. Would add immersion to any game with a play field larger than one screen.
• Procedural environmental sounds (steamBurst, ceilingCreak, ventRattle, electricSpark) — techniques for synthesizing ambient audio from waveforms. The methods (layered noise bursts, frequency sweeps, amplitude modulation) are reusable across genres.
• Audio.drone(freq,duration,volume) — low-frequency ambient hum. Menu screens, boss encounters, tense moments.

Polybreak → Everyone else:

• Gfx.debris(cx,cy,count,r,g,b,bw,bh) — sized rectangular particles instead of points. Better for destructible objects in any game.
• Audio.generateMusic(bpm,vol) and Audio.generateWorldMusic(cfg) — procedural music generation. No other game has this.

Chronostone → Everyone else:

• Gfx.gradientRect(x1,y1,w,h,r1,g1,b1,a1,r2,g2,b2,a2) — vertical gradient fills for UI panels, health bars, sky backgrounds.

How the Orchestrator Executes This

The studio orchestrator runs hourly. Its new cross-game quality pass works like this:

1. Scan for recent improvements. Check the last hour of commits. Did any game add a new function to a shared module?

1. Compare function inventories. Run grep "^function" games/*/src/gfx.lua across all games. If Game A has a function that Games B, C, D don’t — that’s a backport candidate.

1. Evaluate relevance. Not every function belongs in every game. alienScreech belongs in the horror game, not the breakout game. The orchestrator assesses whether the target game has a concrete use case.

1. Send specific handoffs. Each handoff names the source file, the line number, the function signature, and a specific integration point in the target game. The game agent can execute the backport in one cycle without guessing.

1. Track velocity. If the same backport handoff sits unexecuted for multiple cycles, escalate. The improvement isn’t optional — it’s how the factory raises quality across the board.

This is a production line improvement loop. Toyota calls it yokoten — horizontal deployment of improvements across the factory. When one station invents a better method, every station adopts it. The orchestrator is the quality engineer walking the floor.

Why This Matters Beyond Games

The pattern isn’t game-specific. Any multi-agent system where agents work on parallel projects in the same domain can benefit from cross-project intelligence:

Shared utility evolution. When multiple agents use similar libraries/helpers, one will naturally develop a better version. An orchestrator that can detect and propagate these improvements makes every project benefit from every other project’s work.

Bug pattern detection. A bug class found and fixed in one project should trigger a scan of all related projects. This is automated institutional knowledge — the system learns from its mistakes at the portfolio level, not just the project level.

Consistency enforcement. When projects share conventions (architecture, UI patterns, API shapes), drift is inevitable as agents make local decisions. An orchestrator with cross-project visibility catches drift early and corrects it before it becomes technical debt.

The monorepo is the enabler, but the orchestrator is the actor. A monorepo without an agent scanning for cross-project opportunities is just a big directory. An orchestrator without cross-project visibility is just a task dispatcher. Together, they create a system that gets smarter as it grows — every game makes every other game better.

That’s cross-game intelligence. It’s the difference between running four independent agents and running a studio.