How to let coding agents playtest the games they build

A coding agent such as Claude Code or Codex can only playtest a game if it has a way to run the game, send it inputs and read back what happened. Six open-source tools, all MIT-licensed and all posted to GitHub between October 21 and 28, 2026, each provide part of that loop for a different engine or setup. This guide covers what each one does and a setup that works with any of them.

Why agents need to see their own game

An agent can write game code quickly, but it can't see the screen or press keys. Ludra's README says that with a normal engine the agent is "coding blind": it has no way to notice a character dropping through the level until someone plays it. Compiling and unit tests catch some errors, but the unity-playtest README argues that the bugs that slip past them tend to involve scenes, timing, physics and networking.

The fix is the same across the tools below: give the agent a way to run the game (often headless, meaning without a visible window), drive it with scripted input, and get back text, numbers or screenshots it can check against what you asked for.

The tools

Ludra

Ludra, by ersingvn, is a game engine designed to be used by an agent rather than through an editor. According to its README, a game is a set of plain JSON files, and when ludra check finds a problem it reports the exact field and a suggested fix. It supports 2D games on simple arcade physics or the Rapier physics engine, and 3D games drawn with Three.js on Rapier 3D.

To play, the agent runs ludra play with a list of timed inputs. The run is deterministic and headless, and it returns a timeline of events, a text (ASCII) map of the frame and, if asked, real rendered screenshots. ludra test checks conditions such as won == true and deaths == 0, and ludra review points out unfinished work, like a script with no test or the engine's default HUD. You can install it as a Claude Code plugin or run it from npm; it needs Node.js 22.18 or newer.

Limit: the game has to be built in Ludra's own format, so it's for new projects, not an existing Unity or Godot game. The README calls it early (v0.92); a single-file web build for sites such as itch.io, plus automatic level solving and fuzzing, are still on the roadmap.

Glitchless

Glitchless, from glitchless-gg, is observability software (it collects data on how a running game behaves) built for coding agents. Its README says it records frame times and suggests what caused each stutter, collects errors into grouped issues, and tracks where players die, get stuck or quit in frustration. It supports Three.js, Phaser, Babylon.js and PlayCanvas in the browser, plus Godot 4.5+, Unity 6.3 LTS and later, Unreal Engine 5.8 and GameMaker 2024.2+.

The agent reads that data through an MCP server (Model Context Protocol, the standard way to give an agent tools). For testing changes, glitchless-playtest plays fixed-seed runs of your game's autoplay bot in Chrome, compares the results with a saved baseline, and reports pass or fail. You can self-host it as a single Node server or use the hosted Glitchless Cloud.

Limit: you have to write the autoplay bot yourself. The README also says to compare runs made on the same machine, and that some data modes need a line in your game's privacy policy.

PlayCanvas Stage

PlayCanvas Stage is published by the PlayCanvas organization on GitHub. It's an editor you work in alongside Claude Code or Codex. Instead of describing an object, you click it (or drag over an area), and the agent gets its path in the scene, the 3D position you pointed at and an image of your view. When you move, rotate or scale things with the on-screen handles, the agent writes those changes into the source code. A StageCheck tool lets the agent load the app in headless Chrome and read its diagnostics.

It needs Node.js 22.18+, Chrome or Chromium, and apps on PlayCanvas Engine 2.23 or later. Limit: it's for PlayCanvas only, and the README notes that its local background process stays running after the agent's session ends.

unity-playtest

Unity-Playtest-for-Claude, by GhazaGG, is a Claude Code skill that controls the Unity Editor and a development build through Unity's Pipeline CLI. Its README describes three kinds of check. Editor probes look for problems such as objects stuck inside colliders and missing references. Scripted Play Mode runs press keys through the Input System, so the game's real controls are exercised. Host-and-client runs add simulated latency and also send requests a genuine client couldn't make, to confirm the server refuses them. The result is a checklist marked pass, fail or skip.

It needs Unity 6 with the experimental com.unity.pipeline package, plus Netcode for GameObjects 2.x for multiplayer checks. Limit: it's an early release (v0.3.4), and the README says it has been tested on Windows. Its own evals found that the same model without the skill also caught the planted bugs; the skill's gains were fewer tool calls and not marking a visual check as passed from a screenshot.

gg-godot

gg-godot, by Richy-was-here, is a Claude Code plugin for Godot 4. It splits the work across seven agent roles, among them a planner, developer, reviewer and QA. A planner agent writes a contract describing each subsystem; a separate QA agent, which can't see the code or design documents, checks the subsystem against that contract using a disposable headless script. /gg:verify runs nine gates, from "the project loads headless" to "no debug prints", and /gg:autonomous works through phases without supervision.

Limit: Godot 4 only. For unattended runs you have to allow the agent to call git and Godot through Bash, and the plugin leaves look, sound and feel for you to judge.

UELRL

UELRL (Unreal Engine Live Reload, Linux), by urijaRom26, fills a gap: its README says Unreal's Live Coding feature isn't available on Linux. With the plugin, an agent can change the body of a C++ function and have the open editor run the new code in 2.8 to 5.2 seconds, timed on UE 5.8.4, with no editor restart. The editor and its MCP connection stay up, so the agent can edit, reload, play and read the log in one session, though Play In Editor has to be stopped before each reload.

Limit: Linux x64 and C++ projects only. Changes to headers, new classes or reflected properties still need a full build and restart, and the MCP route needs Epic's Unreal MCP plugin. For more on that plugin, see our guide to MCP servers for Unreal, Godot and Minecraft.

How to set up a playtest loop

1. Pick the tool for your engine. Use the list above; for an engine not covered, an MCP server that exposes screenshots and play controls is the nearest substitute.
2. Install it inside the agent. Ludra, Stage, unity-playtest, gg-godot and Glitchless all install as Claude Code plugins, and Stage and Glitchless also as Codex plugins. Glitchless and UELRL also provide a setup prompt you can paste into any agent.
3. Write "done" as checks before coding. Turn each feature into something a script can test: "score is 3 after the first room", "a client can't pick up a coin from across the room". Ludra's tests and unity-playtest's "How to test" input both work this way.
4. Make the agent run the checks after every change, not once at the end. Ludra's skill runs check after each edit; in gg-godot, any warning fails a /gg:verify gate.
5. Save a baseline. Record performance numbers before a change so the agent can compare after it, as glitchless-playtest --save baseline does.
6. Ask for evidence. Have the agent return the test output, screenshots or report, not just "it works".
7. Keep a human list. Note what a script can't judge (feel, art, audio, difficulty) and play those parts yourself. For the wider workflow, see how to vibe code a game.

Limits and caveats

AIGamer hasn't tested these tools. Everything above comes from each project's own README (and, for prices, the Glitchless pricing page) as of October 29, 2026. All six repositories were created between October 21 and 28, 2026, so expect rough edges and fast changes.

A passing test only proves what it checks. The Unity and Godot tools both leave feel and looks to a person, and the unity-playtest evals found that a model without the skill marked a door animation as working from one screenshot. Several tools also run local servers or background processes, or ask for broad shell permissions; read what each installs before allowing it.

FAQ

Can a coding agent really playtest a game?

It can run scripted checks: whether a level can be finished, whether something crashes, whether frame times got worse. It can't tell you whether the game is fun. The tools here treat that as a job for a person.

Which tool should I start with?

Start with the one for your engine. If you're starting a new 2D or 3D game and are happy to build it in Ludra, it covers checking, playing, testing and reviewing in one tool. For an existing game in Unity, Godot, Unreal, GameMaker or a web engine, Glitchless adds performance and crash data on top of whatever you already use.

Do these tools work with Codex or Cursor?

Some do. PlayCanvas Stage supports Claude Code and Codex. Glitchless has plugins for Codex and Cursor, and its setup prompt names Claude Code, Codex and Cursor. UELRL's prompt lists several agents, and Ludra runs from npm and adds agent instructions to each new project. unity-playtest and gg-godot are written for Claude Code.

Are they free?

All six are open source under the MIT license. Glitchless also offers a hosted Cloud version; on October 29, 2026, its pricing page listed a free tier of 5,000 play sessions a month and paid plans from $19 a month.