# OpenGame: An Agentic Framework That Scaffolds and Repairs Web Games From a Prompt

> OpenGame is a TypeScript agentic coding framework from CUHK MMLab that turns a game prompt into a playable web build. Its Game Skill layer grows project templates and keeps a protocol of verified fixes, which is a different bet than asking a code agent to one-shot a game.

**leigest519/OpenGame** — OpenGame: Open Agentic Coding for Games

- Repository: https://github.com/leigest519/OpenGame
- Stars: 2,958 · Forks: 430
- Language: TypeScript
- License: Apache-2.0
- Published: 2026-09-24 · Updated: 2026-09-24 · Language: en
- Canonical page: https://hysenlabs.com/projects/leigest519-opengame

## The cross-file failure that OpenGame was built to absorb

Ask a general code agent to build a small browser game and the first files usually look fine. The trouble starts when the scene graph, the input loop and the asset loader stop agreeing with each other. The OpenGame abstract names this directly: agents "consistently stumble when asked to produce a fully playable game from a high-level design, collapsing under cross-file inconsistencies, broken scene wiring, and logical incoherence." That is a different failure class from a syntax error in one function, and it is the problem the project targets.

The intended user is a developer or researcher who wants a web game from a natural-language brief and is willing to run an agent loop rather than hand-write the scaffold. The README frames the output as browser games, not native builds. If your target is a Unity or Godot project, this is not the tool the repository describes.

## Game Skill: a template library plus a repair protocol

The mechanism the abstract puts at the centre is Game Skill, and it has two halves. The Template Skill is described as growing "a library of project skeletons from experience." The Debug Skill is described as maintaining "a living protocol of verified fixes." Read together, that means the framework does not start from a blank directory each time: it reuses skeletons it has already produced, and when it hits an integration error it consults fixes that were previously verified rather than inventing a patch on the spot.

That is a meaningful design choice, and it is also where the sharpest question sits. A library of skeletons and a protocol of fixes are only as good as the process that promotes an entry into them. The README describes the two components and their purpose but does not document the promotion criteria, the storage format, or how a bad entry gets removed. Treat the skill store as state you own and should inspect, not as a black box that improves on its own.

Around that core, the repository layout shows a conventional TypeScript monorepo: packages/ for workspaces, integration-tests/ and agent-test/ for test harnesses, docs/ and docs-site/ for documentation, and scripts/ for build and start entry points. The package.json declares workspaces packages/* and agent-test, which tells you the CLI and the core are separate publishable units.

## Installing OpenGame and generating a first game

The README's badge requires Node.js 20.0.0 or newer, and package.json repeats that as engines.node. The Makefile is the shortest path from a clone to a running CLI: make install wraps npm install, and make start wraps npm run start. The start script itself is cross-env node scripts/start.js, so you can call npm run start directly and skip make.

```bash
make install
make start
```

Before the agent can do anything, it needs model credentials. The .env.example is explicit that OpenGame ships no default credentials and will not call a third-party API unless you provide a key. It also states the resolution order: the OPENGAME_<MODALITY>_* environment variables win, then ~/.qwen/settings.json under openGame.providers.<modality>, then legacy upstream variables such as DASHSCOPE_API_KEY. Four generative API kinds are configured independently, so you can mix providers per modality. The main agent LLM is separate from that system and uses the existing OpenAI-compatible flow, configurable interactively with the /auth command.

```bash
cp .env.example .env
# edit .env and set your own keys for each modality you need
```

If you would rather not build from source, the Makefile includes run-npx, which runs npx https://github.com/leigest519/OpenGame. That is described in the Makefile as the way to test the published package, and it is the closest thing to an installer the repository offers. There is no separate install page in the README; it points at the project page and the arXiv paper for background.

For a container path, the Dockerfile builds in a node:20-slim builder stage, runs npm ci, builds the workspaces, packs the CLI and core tarballs, then installs them globally in a runtime stage whose CMD is opengame. The package.json config block names the sandbox image as ghcr.io/leigest519/opengame:0.6.0, matching the version field. Note the naming: the image belongs to the leigest519 namespace, while the npm package is scoped @opengame/opengame.

## Where the documentation stops short

There are no retrieved releases for this repository, and the README's news section lists a single entry dated 2026-04-21 announcing the framework. The last push to the default branch was on 2026-09-03, so the code is moving, but a reader looking for a tagged release to pin should know that the documentation does not provide one. Version 0.6.0 in package.json is the only version identifier available.

The bigger gap is operational. The README does not document rollback, and it does not describe how to undo a Game Skill entry that produced a bad skeleton or a fix that turned out to be wrong. For a system whose whole premise is accumulating reusable artifacts across runs, that is the limitation to weigh before you point it at a project you care about. The .env.example also notes that the legacy upstream variables are "kept for backward compatibility but undocumented," which is a hint that configuration surface has drifted from its documentation.

Cost is another constraint the README does not resolve. Four independently configured modalities means four potential billing relationships, and the agent loop can call them repeatedly during a generation run. Nothing in the README or .env.example gives a per-run token or spend estimate.

## OpenGame-Bench and the verification problem

The abstract makes an argument that is worth taking seriously: verifying interactive playability is harder than checking static code. OpenGame-Bench is the project's answer, scoring agentic game generation along Build Health, Visual Usability and Intent Alignment, using headless browser execution and VLM judging across 150 game prompts. The claim attached to it is a state-of-the-art result, which is a claim about the paper's evaluation setup rather than something a reader can confirm from the repository alone.

As a design idea, the three axes are more informative than a single score. Build Health catches the project that does not compile. Visual Usability catches the build that compiles into a blank canvas. Intent Alignment catches the game that runs but ignores the brief. The VLM judging step is also the softest part of the pipeline, since a model grading visual output introduces its own variance. If you plan to reuse OpenGame-Bench for your own comparisons, that judging layer is the piece to inspect first.

The playable demos in the README show the intended output range: a side-scrolling platformer, a turn-based card battler, and a two-player quiz fighter, each paired with the prompt that produced it and a downloadable source archive. Those archives are the most concrete evidence available for what a finished run looks like on disk.

## How OpenGame differs from a general-purpose coding agent

The obvious alternative is a general coding agent such as the upstream qwen-code flow that OpenGame itself builds on, or any comparable CLI agent. The difference is not the model. It is the domain layer. A general agent asked for a game will plan, write files and iterate on errors, but it begins each session with no accumulated knowledge of which skeleton layouts hold up or which integration failures recur.

OpenGame's bet is that game creation has enough repeated structure to justify a persistent skill store, and that repair knowledge is worth keeping separately from generation. That is a real architectural distinction, and it is the reason to pick this project over a general agent. The trade-off is the inverse: a general agent has no skill store to corrupt, no promotion criteria to audit, and no domain-specific state to migrate between versions. If your work is a one-off prototype, the general agent is simpler. If you are producing many web games with overlapping structure, the accumulation is the point.

A second comparison is to game engines with their own scripting layers. Those give you a stable runtime and a documented editor, but they do not generate the project from a prompt. OpenGame sits upstream of that, producing the code a browser can run.

## Licence, maintenance and what an upgrade costs

OpenGame is Apache-2.0, which permits commercial use and modification and includes an explicit patent grant. That is a permissive choice, and it means the framework can be embedded in a commercial pipeline. It does not settle the licence status of anything the agent generates, and it does not cover the model providers you configure: each of the four modality APIs carries its own terms, and the .env.example is clear that those keys are yours. This is not legal advice; the interaction between generated game assets and your provider agreements is the part to check with counsel.

On maintenance, the last push was on 2026-09-03, so the repository is not archived and is being touched. There are no retrieved releases, so upgrades are likely to mean tracking the default branch or the version in package.json rather than moving between tags. The Dockerfile and the sandboxImageUri both carry 0.6.0, which suggests the image tag and the package version are meant to move together; an upgrade that changes one without the other is a mismatch worth catching early. The Makefile's preflight target, which runs formatting, linting and tests, is the cheapest way to check that a pulled change builds in your environment before you run a generation.

## Conclusion

Adopt OpenGame if you want an agent loop that scaffolds a web game project and accumulates fixes across runs, and you are willing to supply your own model keys and a Node.js 20 or newer environment. Skip it if you need a stable, versioned release, a documented rollback path, or support for native engines such as Unity or Godot; the README and package metadata do not describe any of those. Before committing, verify three things: that your chosen providers work under the OPENGAME_<MODALITY>_* variables, that the sandbox image tag ghcr.io/leigest519/opengame:0.6.0 matches the package version you install, and that the Game Skill artifacts persist somewhere your team controls.

## FAQ

### What is OpenGame?

OpenGame is an open-source agentic framework for end-to-end web game creation from a prompt, built in TypeScript and released under Apache-2.0. Its core is Game Skill, made up of a Template Skill that grows a library of project skeletons and a Debug Skill that maintains a protocol of verified fixes.

### What Node.js version does OpenGame require?

The README badge and the engines field in package.json both require Node.js 20.0.0 or newer. The Dockerfile builds on node:20-slim for both the builder and runtime stages.

### Does OpenGame ship with model API keys?

No. The .env.example states that all keys belong to you, that OpenGame ships no default credentials, and that it will not call a third-party API unless you provide a key. Four kinds of generative API are configured independently under the OPENGAME_<MODALITY>_* variables.

### What is OpenGame-Bench?

OpenGame-Bench is an evaluation pipeline described in the abstract that scores agentic game generation along Build Health, Visual Usability and Intent Alignment, using headless browser execution and VLM judging across 150 game prompts.

## Sources

- [Issues](https://github.com/leigest519/OpenGame/issues)
- [leigest519/OpenGame on GitHub](https://github.com/leigest519/OpenGame)
- [License: Apache-2.0](https://github.com/leigest519/OpenGame/blob/main/LICENSE)
- [README](https://github.com/leigest519/OpenGame/blob/main/README.md)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/leigest519-opengame