VibeGame: An Open-Source Eight-Agent Team That Builds 2D Games From a Prompt

VibeGame, a new paper and open-source repository, builds complete playable 2D web games from a text prompt by giving a team of eight AI agents an engine they can read and control frame by frame. The code is on GitHub under the Apache-2.0 license, it runs on Claude Code or Codex, and the authors report it beats other agent harnesses on a game-creation benchmark. Those benchmark numbers are the authors' own and we have not reproduced them, so read them as claims to check.

This post explains the design, what the authors claim, how to try it, and the risks of running a multi-agent tool that skips permission prompts.

TL;DR

What VibeGame does

The paper's abstract describes the problem plainly: language-model agents can already write software from natural-language instructions, but "end-to-end game development remains challenging" because a playable game needs code, scenes, assets, animations, physics and configuration to work together, and a developer has to test the integrated behavior by playing it.

VibeGame attacks that in two parts, per the arXiv abstract:

1. An AI-native game engine. The engine "represents project state as schema-validated structured text and provides frame-synchronous runtime control." In practice that means an agent can read the state of the game as text, send actions, advance a frame and check what happened, at its own pace, instead of watching a video or guessing from code.
2. An Adversarial Agent Team of eight specialized agents. The design separates implementation from review "so that problems are found and fixed through multi-round loops." According to the authors' Hugging Face post, the team designs the game, creates its own art and animations, writes the code, then plays and reviews the result until it passes.

A third piece is a training-free "self-evolution" mechanism: for each accepted project, the system distills what worked into reusable skeletons, modules and collaboration contracts for future games. No model weights change; the learning is stored as reusable project material.

Two evaluation settings

The paper evaluates two modes. In prompt-assets-to-game (PA2G), agents are given an asset library to build from. In prompt-to-game (P2G), agents generate their own art. The abstract says that on a GameCraft-Bench subset, VibeGame in P2G, the harder setting, "consistently outperforms a range of agent harnesses in either P2G or PA2G with the same underlying model, including GPT-6.1-Sol."

The authors' Hugging Face post gives the headline margins: on 30 GameCraft-Bench tasks, VibeGame beats the strongest baseline harness by 11.70 points with GPT-5.6-Luna and by 4.19 points with GPT-6.1-Sol. Two things are worth noticing.

• The gap narrows with the stronger model. A harness helps more when the base model is weaker. That is typical, and it suggests the framework's value is organizing the work, not unlocking new capability.
• The scale of "points" is not explained in what we read. We did not find the scoring definition in the abstract or the post, so we cannot say how large 11.70 points is. Check the technical report before quoting it.

What is in the repository

The GitHub repository describes VibeGame as an "open-source self-evolving multi-agent framework with an AI-Native game engine that turns your natural language into a fully playable 2D web game and edit it any way you want, built on Claude Code & Codex." The README lists demos such as a civilization prototype, a Hollow Knight-style boss slice, an arcade fighter, a dungeon roguelike, a Fruit Ninja clone and an AI werewolf party game. These are the authors' showcase projects; we did not play them.

It also ships a web dashboard with four tabs: Chat (talk to the agents), Assets (preview animations and sprite bounds), Objects (configure character animations and properties) and Play (try the game). That matters because pure prompt-to-game output is rarely final. The dashboard is how a human edits what the agents made.

The roadmap in the README lists open-sourcing the Phaser-based implementation, adding Godot and Unity support, and expanding from 2D to 3D. Phaser is the web game framework under the 2D engine. The README's roadmap items were unchecked in the version we read, so treat Godot, Unity and 3D as plans.

How to try it

The README's requirements are Python 3.12 or newer, uv, tmux, and at least one agent CLI, Claude Code or Codex. Node.js and npm are not required for the standard setup. The quick start is short:

git clone https://github.com/tettethu/VibeGame
cd VibeGame
./setup.sh

mkdir my-game && cd my-game
vibegame init
vibegame start

Inside an agent session, the README suggests the standard build workflow with a goal, for example /vibegame-build Build a compact roguelike dungeon with one boss encounter. You can run or close the game with vibegame run --port auto and vibegame close, and continue an existing project with vibegame start --project ./my-game "Continue polishing the boss fight".

Two setup notes from the README matter:

• Claude Code users: VibeGame launches agents with claude --dangerously-skip-permissions. If you have never used that flag, run it once in a terminal and accept the prompt, because the first-run consent screen cannot be completed inside VibeGame's managed session.
• Codex users: after setup.sh, run vibegame setup codex-hooks, open Codex, enter /hooks and trust the added hooks. Until both steps are done, Codex agents run but never register with the dashboard.

Why an engine agents can read matters

Most coding-agent failures on games come from the same place: the agent writes code it cannot verify. A game is a moving, stateful program whose correctness shows up only in play. Giving the agent text-form state and frame-by-frame control turns "does it feel right" into a checkable loop: advance five frames, read the position of the player, confirm the jump arc.

This connects to a wider idea we have covered in loop engineering for coding agents: reliability comes from the loop around the model, with checks it can run, not from a bigger prompt. VibeGame applies that to games, and the adversarial split between builder and reviewer mirrors the review-agent patterns in a team's Claude Code code-review process.

The reusable "skeletons, modules and collaboration contracts" are conceptually close to the packaged instructions described in our guide to agent skills: knowledge captured once and reused across projects.

How it compares with other game-making agents

Game generation with agents is crowded. Our coverage includes a Claude Code game-studio template with 49 agents and 74 skills and Simon Willison's vibe-coded real-time strategy game. The difference is where the structure lives.

The Hugging Face paper page also lists related work from the past weeks, such as CEGame-Bench, GameASG-Bench and SWE-Game, which shows this is an active research area with several competing harnesses and benchmarks. A result on one benchmark does not carry to the others.

Limits and open questions

• Self-reported results. The gains are from the authors, on a subset of 30 tasks, against baselines they chose and ran. Independent replication is the missing piece.
• 2D only. Complex 3D games are on the roadmap, not in the release.
• Quality is not measured by points alone. A game that passes review can still be dull. The dashboard exists because humans still tune feel, balance and art.
• Cost is not stated in what we read. Eight agents in multi-round loops will use many tokens. Neither the abstract nor the README gives a per-game cost, so budget a test project before you commit.
• Art generation and rights. In P2G mode the agents generate their own art. Check the license and provenance of generated assets before you ship a game commercially.
• Maturity. The repository showed 24 commits and about 297 stars. That is early; expect rough edges.

Safety: the permission flag

The README is open about its biggest operational risk: agents are launched with --dangerously-skip-permissions, so they can read, write and run commands without asking. For a tool whose agents write and execute code, that is a real exposure. Run VibeGame in a disposable VM or container, keep SSH keys, cloud credentials and personal files out of reach, and review what the dashboard shows. If you want a policy layer that stops agents before dangerous actions, the explainx.ai team builds AgentBeam for that purpose.

Should you try it?

If you build games or study agent harnesses, yes, in a sandbox. The most interesting idea is not the eight agents but the engine contract: a game state that is text, schema-validated and steppable by frame. That makes agent verification concrete, and you can borrow it for other interactive software. If you only want a game for fun, expect to spend time in the dashboard editing what the agents produce.

Related reading

• Loop engineering for coding agents with Claude Code
• What are agent skills? A complete guide
• Claude Code Game Studios: 49 agents and 74 skills
• Battle Drones: a vibe-coded RTS built with Claude Code
• A team's Claude Code code-review process

Repository details, star counts and benchmark claims are as of October 31, 2026.