Have an agent test a feature
The agent-driven playtest, with its device profiles.
“It works” is not proof. An agent can actually launch your game, play a scenario, read the server and client consoles, take screenshots, stop the test, and deliver a verdict. This is the difference between an agent that says it fixed a bug and an agent that shows it.
How a playtest works
Section titled “How a playtest works”Before you start
Section titled “Before you start”- Roblox Studio open on your project’s place, with the plugin attached. See Connect VibeStarter to Roblox Studio.
- An agent launched on the project. See Launch and drive your agents.
- Some patience: during the test, the place is held by that agent. The others wait their turn.
Ask for a playtest
Section titled “Ask for a playtest”There is no button: you ask for it in French, in the agent’s pane. Requests like these (written in French) trigger a real test:
- “Launch the game and check that the chest opens when I press E in front of it.”
- “Test that buying the Game Pass really doubles the coins, and show me the console.”
- “Walk a player to the dungeon door and tell me whether they get there.”
- “Measure the FPS when the zombies appear.”
- Write your request, saying what must be true at the end. “Check that” makes a better test than “see whether it works.”
- The agent takes the place, launches the game, and plays the scenario. The Studio status badge changes to “Studio busy” followed by its name.
- It reads the server console and the client console, takes the screenshots it needs, and then stops the test.
- It gives you its verdict in its pane, with what it actually observed.
The three verdicts
Section titled “The three verdicts”| Verdict | What it means |
|---|---|
| PASS | The expected behavior was observed during a real launch of the game. |
| FAIL | The expected behavior did not happen, and the agent describes what happened instead. |
| INCONCLUSIVE | The test could not conclude: the scenario did not run to the end, or a check could not be made. It is neither a success nor a failure. |
What a scenario can contain
Section titled “What a scenario can contain”A scenario has from one to thirty-two steps. Each step is one of these types:
- a player input: keys, clicks, mouse movements, typed text;
- Luau code run in the place;
- a check: what must be true at that moment of the test;
- a wait: let the game run for a few seconds;
- a screenshot of the render;
- a character move to a point, with pathfinding;
- a build or layout check;
- a performance measurement over a short period.
Two settings are added to the scenario:
- the number of players, from one to eight, to test what only happens with several players;
- the device profile, replayable on one to three profiles, to check that it also works on a phone screen.
Replay a scenario
Section titled “Replay a scenario”A scenario is saved in your project’s .vibestarter/tests/ folder, under the name the
agent gives it. It can be replayed as is later, by you or by another agent: “replay the
chest test” is enough.
This is what makes the playtest useful over time: after a change to your game, you run the existing tests instead of checking everything by hand.
The other checks your agents can do
Section titled “The other checks your agents can do”The playtest answers “does it work?” Other checks answer questions that a screenshot does not show:
| What you ask | What the agent checks |
|---|---|
| “Check my map” | Parts that are neither anchored nor welded, models without a main anchor point, objects floating or sinking into the ground, overlapping faces |
| “Check this asset” | Real dimensions, anchor point, upright pose, offset, unanchored parts |
| “Check this rigged model” | Unreachable limbs, limbs anchored by mistake, badly placed joints, parts pulled by two motors |
| “Check my interface” | Elements off screen, cut off at the edge, zero size, text overflowing, overlapping elements |
| “Measure the performance” | Average, median, worst frame, and memory over a short period |
Limits
Section titled “Limits”- One test at a time per experience. Two worlds of the same game cannot be played together: Roblox Studio ejects the first one. Two different experiences, however, can be tested at the same time.
- No screenshots during a multiplayer test. For a visual check, you need a single-player test.
- A reduced Studio window can pause its rendering, which prevents the capture. The tool tells you about it instead of returning an empty image.
- The test runs in Roblox Studio, not on your live game. It does not join any public server and does not read any player data.
- The place is held during the test. The Stop · place name badge, in the header of the pane of the agent that is testing, stops the test and gives you back control.
Frequently asked questions
Section titled “Frequently asked questions”“How do I make sure it really works?” Ask for a playtest with a sentence that says what must be true at the end, then read the verdict. A PASS has been observed; a claim in the agent’s text has not.
“The agent says it’s fixed, but it isn’t.” Ask it to prove it with a playtest. If it returns INCONCLUSIVE, the scenario did not run to the end: say which step is missing.
“Why are my other agents blocked during a test?” Only one agent drives a place at a time. The others keep going on whatever does not require Studio. See Making your quota last.
“Can I test on mobile?” Yes, with the scenario’s device profiles: the agent replays the same test on another profile.