An AI game playtest bot prototype should run one tiny room over and over before you build the next one. Give the bot simple goals, log every death, stuck state, repeated safe route, and ignored mechanic, then fix the room that already exists.
The most useful tester for an AI-made game is not a clever player. It is a stubborn one. It jumps too early, holds right too long, attacks from the same bad distance, refuses to use the new button, and keeps choosing the safest path even when that path is dull.
That is exactly why you want it. A human playtester tries to understand your intention. A bot repeats the room until your intention falls apart.
This workflow is for AI-assisted 2D prototypes where the first question is not "is the game finished?" but "can the loop survive repeated abuse?" Chatforce is included because its AI game studio workflow is useful for getting a browser-playable loop quickly. Unity documents ML-Agents for training and evaluating agents in game environments, and Unity Test Framework for Edit Mode and Play Mode tests. Godot documents runtime debugging tools, including visible collision, paths, and navigation.
Chatforce
A prompt-to-game and multi-agent game studio for creating a browser-playable first version fast. It fits the first stage here: make the room playable, share it, and learn which loop is worth testing harder.
Unity ML-Agents
A Unity package and toolkit for turning Unity scenes into learning environments where agents observe, act, and receive rewards. It is the serious option when you want trained behavior instead of a simple scripted runner.
Unity Test Framework
Unity's testing package for Edit Mode and Play Mode tests. It is better for repeatable assertions than for taste, but that is exactly the point when checking state, input, and fail conditions.
Godot
An open-source engine with runtime debug views for collisions, paths, navigation, and remote scene inspection. It is useful when you want to see why the bot got stuck instead of only reading a log.
The Bot Should Be Boring
Do not start by asking for an agent that "plays well." That sounds better than it is. A good player skips half the bugs because skill covers them. A boring bot finds the edge cases you were going to miss.
I would rather have four dumb bots than one smart one: a runner that holds right, a jumper that hits jump at fixed intervals, a fighter that attacks whenever an enemy is nearby, and a coward that backs away from danger. None of these are human. Together they tell you whether the room can explain itself under pressure.
If the bot keeps winning with the most boring route, the problem is not the bot. The room taught it to be boring.
The right-holder
This bot holds the main movement direction and only jumps when blocked. It finds pits, bad checkpoint placement, one-way softlocks, and rooms that can be cleared without thinking.
If this bot reaches the goal often, your level may be a hallway with decoration.
The panic jumper
This bot jumps on a rhythm, too early and too late. It exposes ceiling snags, missed coyote time, unfair spike spacing, and ledges that only work for the designer.
If every miss looks random, your platforming language is not readable yet.
The button masher
This bot attacks or interacts whenever a target is close. It reveals animation locks, cooldown lies, enemy stun bugs, and prompts that appear too late.
If mashing beats careful timing, the combat rule is probably too flat.
The coward
This bot keeps distance from hazards and enemies. It finds safe corners, kiting loops, dead zones, and rewards that do not pull the player back into risk.
If the safest route is also the fastest route, your risk design is upside down.
Start With A One-Room Contract
A playtest bot needs a contract, not a personality essay. Give it a start point, a goal, a maximum run time, a small input set, and a list of states to report. Keep the room tiny. One platform gap, one enemy, one pickup, one door, one reset.
In Chatforce, I would use it for the first playable pass: "Make a 2D browser platformer with one room, one coin, one enemy, one hazard, one exit, and a debug overlay that records deaths, stuck time, jump misses, enemy hits, and route trails." A public game like Cursor Keepy-Uppies shows the practical value of a shareable browser build: the test subject is a link, not a project setup ritual.
After that, move deeper only if the room deserves it. Unity ML-Agents makes sense when you want an agent to learn from observations and rewards inside a Unity scene. Unity Test Framework makes sense when you need repeatable Play Mode assertions, such as "the player never stays immobile for five seconds while alive" or "the exit cannot be reached without touching the key." Godot is good when you want to watch the debug truth directly: collision shapes, visible paths, navigation, and runtime state.
What The Bot Should Log
| Signal | What it catches | First fix to try |
|---|---|---|
| Stuck time | The player is alive but cannot progress, move, or reset cleanly | Add a reset, widen the gap, move the obstacle, or fix collision |
| Repeated route | The bot takes the same low-risk path every run | Move reward, add timing pressure, or make the shortcut cost something |
| Ignored mechanic | The bot clears the room without using the mechanic you built | Require the mechanic once in a safe setup before using it under pressure |
| Death cluster | Many deaths happen at the same tile, enemy, or transition | Check telegraphing, hitboxes, camera framing, and checkpoint distance |
| Input dead zone | Inputs are accepted but do not change state when the player expects them to | Test buffer windows, cooldown feedback, and animation locks |
Do Not Reward Completion Only
If the bot only gets a reward for reaching the end, it will teach you one thing: whether reaching the end is possible. That is too thin. You need smaller signals.
Reward touching the new mechanic. Penalize standing still. Track time spent in safe corners. Count how often the bot sees a pickup and ignores it. Count how often it attacks into empty space. The goal is not to train a champion. The goal is to turn invisible boredom into visible numbers and route trails.
- Keep the prototype to one room with one goal, one enemy, one pickup, one hazard, and one reset.
- Create at least four simple bot behaviors: right-holder, panic jumper, button masher, and coward.
- Log stuck time, repeated routes, ignored mechanics, death clusters, and dead inputs.
- Draw route trails during testing so you can see where the bot keeps going.
- Set a maximum run time so softlocks become visible failures.
- Save the last few seconds of inputs before each death or reset.
- Fix the room before adding more rooms.
Use Chatforce
You need a playable 2D loop from text and want to test whether the idea deserves deeper QA.
Fast first playable builds, browser links, prompt-to-game iteration, early route checksUse Unity ML-Agents
You are already in Unity and want agents that learn from observations, actions, and rewards.
Reward experiments, trained agents, simulation-heavy testingUse Unity Test Framework
You need repeatable Play Mode checks for state, fail conditions, and regressions.
Assertions, CI-friendly checks, input and state validationUse Godot
You want to watch collision, paths, navigation, and runtime state while the test runs.
Debug visibility, small 2D prototypes, hand-tuned game feelRun the boring bot before you add content. If it gets stuck, loops safely, ignores the new mechanic, or wins without making a choice, your next prompt should fix the room, not expand the game.
FAQ
What should an AI game playtest bot prototype test first?
Start with stuck states, repeated safe routes, ignored mechanics, death clusters, and dead inputs in one small room. Those failures tell you more than a full level pass.
Should I use a trained AI agent or a scripted bot?
Use scripted bots first. They are easier to understand and faster to debug. Move to trained agents when you already know which behavior you want to explore.
Where does Chatforce fit in automated playtesting?
Use Chatforce to get the browser-playable first loop quickly. Then use engine tools such as Unity ML-Agents, Unity Test Framework, or Godot debugging when the prototype needs deeper repeatable tests.