6 Agents Team Up to Make a Game

AI Game Development Is Beginning to Add the “Playtesting” Step

Recently, a Vibe Gaming workflow in which six Agents collaborate to develop a game has attracted attention. Unlike the common “generate a mini-game from a single sentence” approach, this workflow does not stop at producing code. Instead, different Agents handle tasks such as requirements decomposition, implementation, execution, playtesting, issue analysis, and bug fixing, creating an automated closed loop from generation to validation.

What is truly noteworthy here is not the number “six,” nor is it that AI has once again created a mini-game.

The key point is this: Agents are beginning to tackle one of the hardest questions to automate in game development—The code runs, but is the game actually fun?

Over the past year, Vibe Coding has already demonstrated that large models are highly capable of rapidly assembling games such as Snake, platformers, tower defense games, and top-down shooters. Prototypes built with HTML, JavaScript, Godot, or Unity—even those with assets and sound effects—can be generated within a few rounds of prompting.

But developers quickly encounter the same wall:

• The character can move, but there is noticeable input latency;
• Collision detection produces no errors, but the hitboxes are infuriating;
• Enemies spawn, but their spawn points may immediately trap the player;
• The scoring system works correctly, but the difficulty curve has no rhythm;
• The game does not crash, but after ten seconds of play, no one wants to open it again.

These issues are usually not caught by unit tests. From a software engineering perspective, the program is “correct”; from a game design perspective, it has already failed.

Six Agents Do Not Simply Mean Writing Code in Parallel

Public information emphasizes a team of six collaborating Agents. Their specific names are not important. Based on their actual responsibilities, the system can be understood as consisting of six types of roles:

1. Goals and Gameplay Agent: Turns a vague request into a core loop, control scheme, win and loss conditions, and constraints.
2. Task Planning Agent: Breaks development down into tasks such as scenes, character controls, enemy logic, UI, and sound effects, then determines the execution order.
3. Implementation Agent: Modifies project files and generates scripts, level configurations, and asset-loading logic.
4. Execution and Observation Agent: Launches the game and collects visuals, logs, input responses, and runtime state.
5. Playtesting Agent: Simulates player actions and attempts to win, lose, restart, and explore edge-case behaviors.
6. Debugging Agent: Identifies causes based on playtest records, proposes patches, and sends tasks back through the implementation and validation stages.

These six roles do not necessarily correspond to six entirely different models, nor do they require six independent processes. From an engineering perspective, they are more likely to consist of different system prompts, tool permissions, contexts, and acceptance criteria.

In other words, the value of a multi-Agent system does not come from “six models making noise together.” It comes from creating conflicts between responsibilities: the Agent writing the code tends to declare the task complete, while the Playtesting Agent’s job is to prove that it is not.

This closely resembles a real game development team. A programmer says the feature has been implemented, and QA responds with a recording showing that if the player presses jump twice in a corner, they can clip out of the map.

How the Workflow Moves from “Generated” to “Playable”

The core of this Vibe Gaming workflow can be summarized as a loop:

Define goals → Generate or modify → Launch and run → Automated playtesting → Record anomalies → Diagnose and fix → Playtest again.

It looks similar to the traditional code Agent workflow of “write code—run tests—fix tests,” but games introduce two additional challenges: inputs are continuous, and quality standards are heavily experience-driven.

Step One: Turn Natural Language into Testable Acceptance Criteria

If the user simply says, “Make a fun space-dodging game,” the Agent can easily generate a Demo that appears complete but cannot actually be evaluated.

A more effective requirement should specify at least:

• How the player controls the game;
• What the core activity of each session is;
• Under what conditions the player wins or loses;
• Whether difficulty changes over time;
• Whether the player can restart quickly after losing;
• Which values may be adjusted after playtesting.

For example, “The player moves a spaceship left and right to avoid blocks falling from the top; a collision ends the game; survival time determines the score; pressing the spacebar restarts immediately” is much more suitable for an Agent to execute than “Make a space game.”

It is important not to lock down every value from the beginning. Movement speed, enemy density, acceleration, and hit feedback are precisely the kinds of things that should be adjusted through playtesting. Requirements need to define the rules clearly while leaving room for experience optimization.

Step Two: Generate a Minimum Playable Version Instead of Adding Every System at Once

Even multiple Agents cannot compensate for poor task decomposition.

If the first iteration is required to include a story, inventory, combat, skill tree, bosses, save system, leaderboards, and multiplayer, the Agents will likely deliver a collection of loosely connected modules. Each feature may exist independently, but the combined result will be impossible to validate.

A more reliable approach is to first complete the minimum core loop:

• The player can enter the game;
• The player can control the character;
• There is a clear objective;
• There is a success or failure state;
• The game can be restarted.

Only after this loop is playable should attacks, items, levels, and visual feedback be added one by one. For an Agent, adding one system at a time is not conservative—it reduces the problem search space.

Step Three: The Playtesting Agent Must Actually Control the Game

This is the most critical step in the entire workflow.

The Playtesting Agent cannot merely read the source code or inspect startup logs. It needs to send keyboard, mouse, or controller inputs to the runtime environment just as a player would, then observe the visuals and state changes after each action.

For web games, this can be accomplished through browser automation. In engines such as Unity and Godot, it requires editor interfaces, runtime debugging channels, or tool protocols such as MCP. Ideally, the Agent should have access to four types of information simultaneously:

• Visual information: Screenshots, recordings, or continuous frames;
• Runtime logs: Exception stacks, warnings, and asset-loading errors;
• Structured state: Player coordinates, health, speed, current level, and collision objects;
• Action traces: Which input was made, when it was made, how long it lasted, and what result it produced.

With screenshots alone, the Agent can easily make incorrect guesses. With logs alone, it cannot see experiential issues. Only by combining visual information with structured state does it have a chance to determine whether a character failed to move because the input was not registered, the speed was zero, the animation did not play, or the camera failed to follow.

Step Four: Separate Bugs from Game-Feel Defects

Game testing cannot focus solely on crashes.

The Playtesting Agent must distinguish between at least three types of issues:

The first type is functional bugs. Examples include broken collision detection, characters passing through walls, unclickable buttons, or the inability to restart after losing. These issues usually have clear expected outcomes and are well suited to automated fixes.

The second type is state and rule errors. For example, an enemy has been eliminated but the counter does not update; the player can still move after health reaches zero; or the level completion condition can never be triggered. These errors require correlating what appears on screen with the internal state.

The third type is experience issues. Examples include movement feeling too floaty, enemies being too slow, a lack of hit feedback, excessively long waits at the start, or sudden difficulty spikes. These issues may not violate the requirements, but they directly determine whether the game is worth continuing to play.

The third type is the hardest. An Agent can measure the latency between input and movement, and it can calculate the player’s average survival time, but whether the game “feels good” is still not a deterministic function.

A more practical approach is to translate subjective experience into observable metrics:

• How many milliseconds pass between pressing a direction key and the start of movement;
• How long it takes the character to accelerate from rest to maximum speed;
• How the enemy spawn rate changes during the first 30 seconds;
• Whether the player receives clear visual feedback before dying;
• How many actions are required to restart after a session ends;
• Whether the automated player encounters unavoidable deaths or permanent softlocks.

These metrics cannot replace a designer, but they can filter out a large number of prototypes that are “obviously not fun.”

What Multi-Agent Systems Really Provide Is an Accountable Iteration Chain

The most common problem with single-Agent development is that all context becomes mixed together.

The same Agent is responsible for understanding the requirements, writing the code, and evaluating its own work. If the first implementation chooses the wrong architecture, every subsequent fix tends to preserve the original answer rather than challenge the faulty assumption. The model can easily fall into a self-consistent state: the code produces no errors, so the feature must be complete.

Multi-Agent systems reduce this bias by separating contexts. The Playtesting Agent does not need to protect the code author’s ego. It only needs to report:

• At which step progress became impossible;
• What input triggered the problem;
• Whether the problem can be reproduced consistently;
• Whether the fix introduced a regression.

The Debugging Agent can then translate “the game is not fun” into specific changes, such as increasing fall speed, shortening attack wind-up, making the hit-flash effect more visible, or adjusting the collision box. The result is then handed back to the Playtesting Agent for verification.

If the requirements, patches, action traces, and validation results from every iteration are recorded, the process itself becomes a project asset. Developers can see not only the final code, but also trace why a particular parameter was changed.

This is where Vibe Gaming begins to look more like engineering than wish-making compared with early Vibe Coding.

But Automated Playtesting Is Still Far from Real Game QA

This workflow is useful, but it should not be marketed as proof that “AI can now make games independently.” At present, there are at least four unavoidable limitations.

1. Agents May Learn to Pass, Rather Than Learn to Play

The easiest thing for an automated player to optimize is objective completion. If the win condition contains an exploit, it may repeatedly use that exploit to clear the game rather than experience it as intended.

This is common in both reinforcement learning and automated testing: the system achieves the metric while undermining the experience. Developers therefore need to define both permitted and prohibited behaviors. When necessary, they must also introduce Playtesting Agents with different styles, such as aggressive players, cautious players, button-mashers, and edge-case testers.

2. Visual Assessment Still Produces False Positives

Particles, animations, camera shake, and occlusion in continuous visuals make judgment more difficult for multimodal models. An Agent may mistake an intended animation for a frozen character, or miss a clipping issue that appears for only a single frame.

Providing structured state interfaces for key objects remains more reliable than asking the model to rely solely on visuals.

3. Fixing One Bug May Create Another

To fix clipping through a corner, an Agent may simply enlarge the collider, only to make it impossible for the character to pass through narrow doors. To make enemies more threatening, it may increase their speed and ruin the beginner level.

For this reason, every modification must be followed not only by retesting the current issue, but also by running a fixed set of regression scenarios. Automated fixes without regression testing merely create new uncertainty at high speed.

4. Playability Does Not Equal Aesthetic Quality

Pacing, narrative, visual style, sound design, and emotional arcs cannot easily be derived from the absence of bugs. AI can add screen shake, particles, and sound effects, but that does not mean it understands why a particular moment needs silence or restraint.

Games are ultimately experience products. Automated playtesting can eliminate many low-level issues that keep a game below a passing grade, but moving from a 60 to a 90 still requires human judgment.

The Most Practical Value for Developers: Shorter Validation Cycles

We are more inclined to view six-Agent Vibe Gaming as a prototype validation and automated regression system, rather than an “AI studio” capable of completely replacing a game development team.

It is best suited to three types of scenarios:

• Independent development and Game Jams: Rapidly validate core mechanics and reduce the time spent on launching, packaging, and repetitive playtesting;
• Batch level testing: Automatically check for unwinnable levels, spawn deaths, or permanent softlocks;
• Continuous integration regression testing: Automatically launch the game after every commit, replay fixed action sequences, and compare the results.

For large commercial projects, it is more likely to serve as an auxiliary tool for QA and technical design in the near term. Letting Agents run a thousand sets of inputs overnight and collect recordings of anomalies is reasonable; letting them determine combat pacing and the final art direction remains highly risky.

There is also a cost issue that cannot be ignored. Multi-Agent loops repeatedly read the project, capture screenshots, invoke tools, and generate patches. Token usage, inference time, and runtime resource consumption can all grow rapidly. Without clear exit conditions, six roles can easily become trapped in an endless “fix—regress—fix again” cycle.

At minimum, a production deployment should therefore define:

• The maximum number of repair iterations for each issue;
• The files and code areas that may be modified;
• The regression scenarios that must pass before an automatic commit;
• Human approval checkpoints for high-risk operations;
• Logging, recording, and version rollback mechanisms for failures.

From Vibe Coding to Vibe Gaming, the Standard Has Finally Changed

The excitement of early Vibe Coding came from generation speed: one sentence, a few minutes, and a Demo that could be opened.

The new standard revealed by Vibe Gaming is more demanding: AI cannot merely write the code. It must also enter the runtime environment, receive feedback, acknowledge failure, and complete the fix.

The gap between “the code runs” and “the game is playable” is not filled by more code, but by an entire system of observation, testing, and iteration. The significance of the six Agents lies in their attempt to break down a process that once depended heavily on human experience into steps that machines can execute and verify.

Our assessment is that this is not yet the moment when AI can independently produce mature games, but it is already a major step beyond merely generating Snake. A truly valuable Agent is not one that writes all the code correctly on the first attempt, but one that, after discovering it was wrong, knows where to look, what to change, and how to prove that the problem has actually been resolved.

What applies to game development applies equally to other forms of software.

References

This article analyzes automated playtesting and game engine toolchains based on recent public reporting and the following engineering project materials.

• Microsoft Playwright: A browser automation framework that can be used to simulate input, capture screenshots and recordings, and collect runtime state from web games.
• Unity MCP: An open-source project that connects AI Agents to the Unity Editor, offering insight into how Agents can operate scenes, scripts, and runtime environments.
• Model Context Protocol Specification: The MCP protocol specification, useful for understanding how Agents connect to editors, file systems, and external tools in a standardized manner.