The project's README from github.com/GamePhanesStudio/GamePhanes. As one markdown file: README.md.
Terminal-Bench for interactive game-engine development agents.
A Harbor-compatible benchmark for coding agents that build, debug, and repair games through terminal workspaces and executable runtime feedback.
Homepage · Benchmark · Task Registry · Issues · Discussions
Terminal benchmarks often stop at files, commands, and exit codes. Interactive software has a second truth: the project must import, launch, accept controlled input, change runtime state, and produce the intended behavior. GameForgeBench evaluates coding agents on that complete loop.
instruction -> inspect -> edit -> run -> observe -> diagnose -> repair -> verify
The benchmark target is a coding agent, not a player bot. Evaluator-controlled probes provide runtime evidence; the agent is judged on engineering work, debugging, behavior, and regression resistance.
The release corpus contains 81 completed executable tasks spanning Godot, Unity, Roblox, Minecraft, Unreal, Web, and generic engine projects. The tasks cover gameplay systems, engine/runtime work, UI and interaction, plugins, persistence, callbacks, build workflows, and delivery quality.
Each task is a self-contained contract with a starter project, a natural-language request, a reproducible environment, protected files, a reference solution, and executable acceptance checks. The public upload includes one representative task so the complete workflow can be inspected without downloading the full corpus.
| Task | Role | Runtime acceptance boundary |
|---|---|---|
godot-battle-status-bars-gloss |
Reference task | Replace flat HP/MP fills with glossy native textures; preserve layout, bounded ratios, and lifecycle behavior. |
The task starts with a compact Godot battle HUD whose HP and MP fills disappear into the background. The requested change sounds visual, but the acceptance boundary is engineering-focused:
TextureRect nodes and canonical resource bindings;The directory contains the starter project, instruction, rubric, native probe, Docker verifier, redacted provenance record, and reference solution.
Every contributed task follows the same portable directory shape:
task-name/
├── task.toml
├── instruction.md
├── environment/
│ ├── Dockerfile
│ └── project files
├── tests/
│ ├── test.sh
│ └── runtime probes and fixtures
└── solution/
└── reference implementation
task.toml: task metadata, schema version, timeouts, and resource limits.instruction.md: starting condition, requested outcome, constraints, and acceptance criteria without revealing the patch.environment/: pinned engine, operating system packages, project dependencies, and clean runtime entrypoint.tests/: benchmark-owned verification executed outside the candidate implementation.solution/: maintainer reference implementation used to prove solvability; never shown to the agent.Tasks must not depend on a contributor's local absolute path, private package registry, undisclosed asset, network download at evaluation time, or interactive GUI step.
Requires Godot 4.6.1 for local inspection and Docker for the hermetic verifier.
cd release/tasks/godot-battle-status-bars-gloss
godot --headless --path . --editor --quit
The task README contains the reference-workspace command and the Docker invocation. The verifier observes the running Godot project and writes a machine-readable result with per-check diagnostics.
GameForgeBench separates four layers of evidence:
This separation distinguishes a plausible file edit from a project that actually behaves correctly when the engine runs it.
A strong task has a narrow user-visible objective, a believable engineering problem, enough surface area for inspection and repair, deterministic evidence, and a meaningful regression boundary. It should reward understanding the project rather than string matching a known patch.
Reviewers reject tasks that can pass by deleting the gameplay loop, replacing the project with a stub, weakening the verifier, hard-coding the probe sequence, or relying on screenshots alone.
release/tasks/<task-name>/ using the format above.tests/test.sh executable and include a reference solution.The public repository is the inspectable trust layer: task contracts, starter projects, verifier design, reference examples, and reproducible reports. Private evaluation variants, collected agent trajectories, and service credentials are not published as benchmark answers.
GamePhanesStudio maintains the benchmark, task format, runtime adapters, and evaluation tooling. Contributions are welcome through issues, discussions, and pull requests.
MIT.
@software{gameforgebench2026,
author = {GamePhanesStudio},
title = {GameForgeBench},
year = {2026},
url = {https://github.com/GamePhanesStudio/GamePhanes},
license = {MIT}
}