VibeGame: Prompt-to-Game Development with AI-Native Engine and Self-Evolving Adversarial Agent Team

VibeGame. Prompt-to-Game Development with AI-Native Engine and Self-Evolving Adversarial Agent Team. By Wenbo Hu and fifteen others, from Nanjing University, S-Lab at Nanyang Technological University, and one other institution. Published on the twenty-second of October.

Large language model agents can now develop software through natural-language interaction, but stretching that to end-to-end game development is still hard. A playable game means coordinating code, scenes, assets, animations, physics and configuration all at once. And developers need to validate how those pieces behave together, which takes interactive testing, not just reading the code.

VibeGame is a framework for building complete 2D game projects from natural-language prompts, with reference images as an optional extra. It rests on two pieces: a game engine designed to be native to AI agents, and a team of agents set against each other so that building and reviewing are done by different hands.

The engine represents a project's state as structured text validated against a schema, and it offers frame-synchronous runtime control. That lets agents inspect game states, execute actions and verify behaviour at their own pace. On top of that interface sits the Adversarial Agent Team, eight specialized agents that separate implementation from review, so problems are found and fixed over repeated rounds.

The point of the split is that whoever builds a piece is not the one who signs it off. Review finds a problem, implementation fixes it, and the loop runs again until the work holds up.

There is also a self-evolution mechanism, and it needs no training. Each project that is carried out and accepted gets distilled into three kinds of reusable material: skeletons, modules, and collaboration contracts. Those are kept for future development, so a later project can start from what an earlier one already worked out rather than from nothing.

Evaluation covers two settings. In prompt-assets-to-game, or PA2G, agents receive an asset library. In prompt-to-game, or P2G, agents generate their own art. On a GameCraft-Bench subset, VibeGame in P2G consistently beats a range of agent harnesses running either P2G or PA2G with the same underlying model, among them GPT-6.1-Sol. VibeGame, making its own art, outperforms harnesses that were handed assets.

The framework's bet is on structure around the model rather than the model itself: an engine that agents can test against, a team that checks its own work, and a library of past projects that grows with every accepted game.

VibeGame. Prompt-to-Game Development with AI-Native Engine and Self-Evolving Adversarial Agent Team. By Wenbo Hu and fifteen others, from Nanjing University, S-Lab at Nanyang Technological University, and one other institution. Published on the twenty-second of October. This is the long version: the whole paper rather than the abstract.

A playable game has to hold code, scenes, assets, animations, physics and configuration together, and many of its problems only show up while someone is playing it. Games resist coding agents from two sides. Commercial engines such as Unity and Unreal Engine scatter project state across graphical editors and binary files that an agent cannot reliably inspect or edit. World models such as Genie generate something interactive, but no source code anyone can revise. The game-building agents that do exist, the authors note, mostly save runtime checks for final evaluation, or only confirm that the game builds and runs. A game can build perfectly and still be unplayable.

The task they set is called prompt to game: from a text description and optional reference images, produce a complete, playable project, finding and fixing its problems along the way.

Two settings run through the evaluation. In prompt-assets-to-game, the agent is handed a library of ready-made art. In prompt to game, it must generate its own. That sounds like a visual advantage, but with the weaker model tested, the paper finds image generation brings none. Every VibeGame result is in the setting where it makes its own art, while the baselines run in both.

The second thing to hold is that a game executes faster than an agent can reason about it. Verification needs execution that can be paused, advanced, and examined.

There are three parts. The first is the AI-native engine, built on Phaser, a web framework that expresses projects entirely in text. Phaser imposes little structure, so the authors add some. Each game is a set of scenes stored in type-checked JSON files. Each scene is a hierarchy of nodes, and each node declares its appearance, collision geometry, behaviour scripts and configuration explicitly. Because dependencies are explicit, schema validation catches a missing asset before the game ever runs. A frame-synchronous interface lets agents pause, advance a set number of frames, read or change positions and velocities, inject semantic actions such as press jump, and capture screenshots. And the engine's uncompiled source is copied into every project, so an agent can read what the engine actually does instead of trusting documentation.

The second part is the Adversarial Agent Team: eight roles, namely orchestrator, designer, artist, architect, programmer, auditor, player and reviewer. The designer expands the request into a game design document, the artist produces concept art, and once the user confirms both, they become the ground truth. The architect plans, the programmer implements, the auditor checks the result statically against the design, and the player runs the game under frame control, using a vision model to judge whether it looks as intended. A sub-task is done only when it passes both checks. Finally an independent reviewer judges functionality, visual quality and playability, and every rejection becomes a new repair task. The point is separation: the role that builds is never the role that approves.

The third part is training-free self-evolution. An accepted project is distilled into skeletons, which are runnable templates for a game type carrying error notes and art recipes; modules, which are reusable behaviour scripts, some turning past runtime failures into static checks; and contracts, which spell out how each role handles a recurring feature, such as a map.

The test set is thirty tasks from GameCraft-Bench, two from each of fifteen game types, ported to Phaser, with a twenty-four hour budget per task. With the weaker model, GPT five point six Luna, VibeGame leads the strongest baseline by eleven point seven points overall, and leads in all four rubric categories. The frontier model, GPT six point one Sol, gives the more informative picture. There VibeGame trails Codex by less than a point on core mechanics and on functional visuals, and wins on content depth and on art and presentation, for a lead of four point one nine overall. Frontier models, the paper reads this, already build mechanics on their own, and fall short on depth and polish.

The ablation tests which part carries the weight. On a ten-task subset, removing the engine costs ten point three three points, while removing the auditor, player and reviewer costs four point six three. An appendix isolates the engine further: given to plain Codex with the same asset library, it lifts Codex from sixty-four point four four to sixty-seven point one three. A blind user study, in which people played pairs of anonymised games, broadly agrees with the model judge, with an average human win rate for VibeGame of seventy-two point seven percent.

The paper has a short limitations section. It covers only two-dimensional games, has not been tested in complex three-dimensional scenes or on commercial games that sustain long-term play, and its design is implemented on a web engine rather than established ones such as Godot.

A separate appendix is more candid. When VibeGame develops games of different types one after another, the accumulated experience can lower performance. That is why the main experiments run without any accumulated experience. In the ablation, experience evolved by the stronger model on five other tasks raised the weaker model's overall score by two point nine two points, but its content depth and functional visuals both dipped slightly.

The judge is another caveat. The authors replaced the benchmark's judge, GPT five point five, after finding clear errors, and switching judges changed both absolute scores and rankings. VibeGame comes first under both, but under the original judge its lead with the weaker model shrinks to about two and a half points. Scores average three judge passes, but no spread across repeated runs is reported.

The idea to carry away is that, for game-building agents, the environment matters as much as the agent. Make the whole project legible as validated text, make time stop when the agent needs to look, and keep the builder separate from the judge. The largest gains land exactly where frontier models still fall short: depth of content and polish of presentation.