The public repository exposes 1 release task, not the full 81-task corpus
GamePhanes currently calls the project GameForgeBench and describes 81 completed executable tasks across Godot, Unity, Roblox, Minecraft, Unreal, web, and generic engine projects. The important qualifier arrives in the same README: the public upload includes one representative release task. That makes the repository useful for inspecting the format and verifier design, but it does not let an outside team reproduce a score across the stated corpus. Anyone comparing coding agents should separate the disclosed task contract from the undisclosed evaluation set.
The target is a coding agent working through a terminal, not a bot learning to play. A task provides a starter project, instructions, an environment, protected tests, and a reference solution. The evaluator then checks artifacts, engine startup, behavior, and diagnostic output. This is a sensible response to a weakness in patch-only benchmarks: a scene file can look plausible while the game fails to import, or a fix can pass a string check while breaking state after the second update.
What happened when we ran it
Our sandbox installed commit 252aed7 in 11 seconds, added 0 packages, and occupied 51 MB on disk. The repository had no build script or target, so the lab skipped that step rather than inventing one. Node's test runner completed in 8 seconds with 25 passed and 0 failed. Npm audit reported 0 known vulnerabilities. Those numbers make the JavaScript layer easy to inspect on a fresh Node 22 container.
The lab also counted 245 files and about 4,977 lines of source, with 2 CI workflow files and a tests directory. Its scan reported no Dockerfile, while the public sample task documents a Docker verifier inside its own environment directory. That distinction matters: the package itself has almost no dependency friction, but running the featured acceptance path still means supplying Godot 4.6.1 and Docker. The 25 passing Node tests do not measure agent quality across the private task pool.
The Godot 4.6.1 sample tests behavior that file checks miss
The public release task asks an agent to replace flat HP and MP fills in a Godot battle HUD. Its contract fixes the bars at 62x6, expects separate textures, and checks independent 25% and 75% fill results from specified status values. It also probes negative and over-maximum inputs, repeated updates, and a second scene instance. These are concrete acceptance boundaries. A candidate cannot satisfy them merely by placing the expected filename in a scene.
The verifier divides the result into 5 checks covering import, scene binding, workspace integrity, runtime behavior, and texture properties. It measures the supplied SVGs for a bright upper area, a darker lower area, and distinct HP and MP colors. That is a better test of a visual repair than screenshot matching alone. Still, the task includes its reference solution and public probe, so the project correctly labels it an inspectable development specimen rather than a sealed score.
Version 0.1 records runtime evidence but does not isolate private sessions
GamePhanes uses prefixed JSON events from a Godot harness, then applies rule-based assertions to the resulting stream. The runner can record terminal commands, patches, runtime observations, and evaluator reports as a trajectory. External agent frameworks own the model loop. That keeps the benchmark focused on execution evidence and lets an integration use the runner as a feedback source without adopting a particular agent framework.
The architecture document is unusually direct about what v0.1 does not supply. There is no claimed container-backed session gateway enforcing filesystem boundaries, outbound network policy, CPU and memory quotas, reset behavior, or protection for private evaluator files. Those controls are described as requirements before private tasks are exposed. A team can use the current local runner for public development, but production evaluation needs an isolation layer outside this repository.
Seven public examples demonstrate contracts, not repair scores
The quality guide says all 7 gallery entries are reference_environment tasks, meaning their projects work and their public harnesses prove the runtime contract. It names the first repair task as a public development specimen and says it does not count as a sealed benchmark score. This wording is careful, but it also limits what a buyer can verify. The public material demonstrates how scoring works; it does not provide the hidden fixtures, failed and successful author trajectories, or production results needed to judge benchmark difficulty.
The open-core document draws the commercial boundary in plain terms. CLI code, contracts, example projects, public harnesses, and reproducibility tools are public. Private task variants, customer projects, hidden evaluators, calibration systems, rollout data, and hosted workers may remain closed. That can preserve test secrecy, but it puts trust in the operator. If you need an entirely public dataset and evaluator for published comparisons, the 81-task claim is not enough on its own.
A September 6 push shows activity, while 0 open threads show no support record
GitHub showed 536 stars and 0 open issues or pull requests, with the last push on September 6, 2026. The repository was created on August 21 and the fetched commit history contained two entries on the default branch. No GitHub release was listed, even though the package metadata says version 0.1.0. This is active code, but far too new and quiet to judge maintainer response, release cadence, or compatibility discipline.
Terminal-Bench is the closer alternative when the workload spans general terminal tasks and Harbor compatibility matters. SWE-bench is a better fit when you want evaluation based on real repository issues and patch resolution. GamePhanes earns a place beside them only when engine state and controlled runtime input are the point. Today, its strongest use is as a compact reference for writing Godot acceptance contracts, not as proof that one agent outperforms another across 81 hidden tasks.