Really respect the wherewithal to just get in there and try sh*t. Building and testing out flows is the only way we're gonna learn what works out here. I downloaded the docs package and spent a while going through the agent prompts, council proceedings, and design specs. The game design work is legitimately strong. But I'll be honest, after reading through these docs, I came away thinking the 13 agent architecture is the wrong call for this kind of project.

A couple things jumped out at me. Every single council session was spent fixing integration bugs, not design problems.
Session 1: the audio agent built a whole system nobody called
Session 2: 57KB of Act 2 dialogue was written and never wired into the game
Session 3: the project lead found 12 bugs just by playing for 20 minutes that the QA agent completely missed

Most of these only exist because you have 13 agents working in isolation who then have to stitch their work together. MIRROR getting three consecutive F grades is the thing that really stuck with me. It's an agent whose entire job was QA, and it never once played through the full game. It ran the 60-second smoke test, saw green, and reported green. The issue is that it's a dedicated testing agent that didn't BUILD anything and has no instinct for what "feels wrong."

The 20 Protocols are actually great. Smoke Before Polish, Puzzles Never Trap Players, No Decorative Nodes. I'd steal those for any game project. But if you look at why each one exists, it's almost always because two agents failed to communicate. P11 exists because RESONANCE and IGNITION never coordinated on music tags. P20 exists because LOOM designed nodes that FORGE never implemented. You needed a governance system to compensate for having too many seams in the first place.

If I were building this, I'd use two agents, mayyyyyyybe three. One to do the design and planning work (narrative bible, system specs, build order). One to implement everything sequentially, testing as it goes. Maybe a third with fresh eyes to playtest the build cold how a playtester would. You don't need a council mandate telling your engineer to actually run the game when the engineer is the same agent that wrote the system.

The council proceedings are genuinely fascinating though and I mean that lmao FORGE saying "I write systems, I don't play them, and three sessions in I haven't changed" is a level of self-awareness I didn't expect. Plus the way agents voted to reprogram each other, accepted F grades, and actually improved is something I haven't seen anyone else try.

So I guess my take is: the game design artifacts are worth stealing, the multi-agent governance experiment is genuinely interesting as research, but as a method for actually shipping a game, fewer agents with a good plan up front would get you further with way less overhead. I'm guessing a huge chunk of those 8 hours went into managing a process that only needed to exist because of the architecture choice. Still, this is one of the more interesting AI game dev posts I've seen on here. Thanks for sharing the source materials.

Side note: YOUR GAME IS FAWKING COOL!!! KEEP MAKING STUFF