背景

OpenGame 是 CUHK MMLab 在 2026 年 4 月发布的开源智能体框架,目标是让用户用一段自然语言描述生成一个可运行、可交互的 Web 游戏。项目论文为 OpenGame: Open Agentic Coding for Games,官方代码仓库在 leigest519/OpenGame

它解决的问题不是“让大模型写一段游戏代码”,而是让 Agent 完成一整个游戏工程:选择技术模板、生成多个文件、维护游戏状态、处理资源、启动构建、检查运行错误,并反复修复到可玩状态。这个目标比普通代码生成更难,因为游戏开发同时依赖实时循环、输入系统、碰撞逻辑、场景连接、资源加载和 UI 状态。

截至 2026-05-06,OpenGame 已经公开框架代码和演示项目,npm release 仍在准备中,官方推荐从源码安装。

结论

OpenGame 的核心价值可以概括为三点:

  1. 它把“游戏生成”从单次代码补全变成了端到端 Agent 流程。
  2. 它用 Game Skill 管理模板选择和调试经验,降低跨文件工程崩坏的概率。
  3. 它用 OpenGame-Bench 的思路把可玩性纳入评估,而不是只看代码能否编译。

如果你想快速生成 Web 小游戏原型、验证玩法、做 AI 生成式游戏开发实验,OpenGame 值得关注。如果你要生产级商业游戏,它更适合作为原型工具和研究框架,而不是直接替代完整游戏团队。

系统架构

OpenGame 可以拆成四层来看:

用户提示词
OpenGame CLI / Agent Runtime
Game Skill
  ├── Template Skill:选择 Canvas、Phaser、Three.js 等项目模板
  └── Debug Skill:运行、检测、定位、修复构建和交互问题
Web Game Project
  ├── 源码
  ├── 资源
  ├── 配置
  └── 可运行页面

CLI 与 Agent Runtime

OpenGame 当前主要通过命令行运行。用户传入一个 prompt,Agent 在目标目录中生成游戏项目,并在必要时修改文件、修复错误、输出运行方式。

官方示例:

opengame -p "Build a Snake clone with WASD controls and a dark theme." --yolo

这里的 --yolo 允许 Agent 执行 shell 命令。普通试验环境可以使用,但如果目录中有重要文件,建议先在空目录或临时目录中运行。

Game Skill

Game Skill 是 OpenGame 的关键设计。它不是一个单独的模型,而是一套可复用、可演进的 Agent 能力,主要包含两部分。

Template Skill 负责项目骨架。它会根据需求选择合适的游戏技术栈,例如基础 Canvas、Phaser 或 Three.js,并生成相对稳定的项目结构。这样可以减少模型从零创建工程时常见的目录混乱、入口文件缺失、资源路径错误等问题。

Debug Skill 负责验证和修复。游戏生成后,它会通过构建、运行、浏览器执行、控制台错误和交互状态来发现问题,再把修复经验沉淀成可复用协议。这个思路比只修语法错误更重要,因为很多游戏问题是“能编译但不能玩”。

模型使用现状

OpenGame 论文中提到过 GameCoder-27B:一个面向游戏开发训练的代码模型。论文里的训练路径包括:

  1. 持续预训练,让模型吸收游戏开发代码和引擎知识。
  2. 监督微调,让模型学习项目搭建、API 使用和错误修复轨迹。
  3. 基于执行反馈的强化学习,把实际可玩性作为奖励信号的一部分。

但从当前公开资料看,截至 2026-05-06,我没有找到可直接下载使用的 GameCoder-27B 权重、模型仓库或稳定推理入口。也就是说,它更像论文中的专用模型方向和实验设定,不应该在实操文档里写成“用户现在可以直接安装使用”的组件。

实际落地时,OpenGame 主要依赖 OpenAI-compatible API 后面的通用大模型能力。你可以把它理解成:

  • OpenGame 提供 Agent 流程、项目模板、调试协议和游戏生成工具链。
  • 具体写代码、改代码、理解需求的能力来自你配置的大模型。
  • 当前可操作的关键不是下载 GameCoder-27B,而是选择一个足够强、支持长上下文、代码能力稳定的 OpenAI-compatible 模型。

因此在本地试用时,优先把 OPENAI_API_KEYOPENAI_BASE_URLOPENAI_MODEL 配好,用现有大模型跑通流程;等官方后续公开专用模型或推理服务后,再考虑切换。

OpenGame-Bench

OpenGame-Bench 是论文中用于评估游戏生成 Agent 的 benchmark。它关注三个维度:

维度关注点
Build Health项目是否能安装、构建、启动
Visual Usability画面、UI、交互元素是否正常渲染
Intent Alignment最终玩法是否符合用户最初描述

这个评估方向很关键。普通代码 benchmark 通常看测试是否通过,但游戏是交互式应用,真正的问题经常出现在浏览器运行、输入响应、资源加载、状态推进和胜负条件上。

安装

OpenGame 当前推荐从源码安装。

环境要求

node --version

建议使用 Node.js 20 或更高版本。

从源码安装

git clone https://github.com/leigest519/OpenGame.git
cd OpenGame
npm install
npm run build
npm link

安装完成后,系统 PATH 中会出现 opengame 命令:

opengame --help

配置

OpenGame 的 Agent Runtime 支持 OpenAI-compatible API,可以通过环境变量配置:

export OPENAI_API_KEY="your-api-key-here"
export OPENAI_BASE_URL="https://api.openai.com/v1"
export OPENAI_MODEL="gpt-4o"

如果你使用 OpenRouter、本地模型服务或兼容 OpenAI API 的推理网关,把 OPENAI_BASE_URLOPENAI_MODEL 改成对应值即可。

资源生成配置

除了主推理模型,OpenGame 还可以对接图片、音频、视频和推理类 provider。官方 README 中提到的配置方式类似:

export OPENGAME_IMAGE_PROVIDER=tongyi
export OPENGAME_IMAGE_API_KEY="sk-..."

不同模态可以分别配置 provider。这样做的好处是:游戏逻辑可以用一个模型生成,图片或音频资源可以交给更适合的服务生成。

设置文件

OpenGame 支持通过环境变量、CLI 参数和 settings 文件配置。当前仓库中仍保留 .qwen/settings.json 这类路径命名,这是继承上游 Agent Runtime 的兼容设计,官方说明后续可能迁移到 .opengame

快速运行

建议先在空目录中试验:

mkdir -p ~/agent-test/games/snake-demo
cd ~/agent-test/games/snake-demo
opengame -p "Create a dark-themed snake game controlled by WASD. Add score, pause, restart, and increasing speed." --yolo

运行完成后,根据命令行输出打开生成的 index.html,或者执行项目中给出的 dev server 命令。官方 demo 的本地运行方式通常是:

npm install
npm run dev

然后访问:

http://localhost:5173

Prompt 编写建议

OpenGame 的输入越像产品需求文档,成功率越高。建议 prompt 至少包含以下内容:

类型示例
游戏类型横版动作、塔防、卡牌、答题格斗、双摇杆射击
核心循环收集资源、建造防御、击败一波敌人、进入下一关
输入方式WASD、方向键、鼠标点击、双人键盘
关卡规则三个关卡、每关一个 Boss、失败后可重新开始
UI 要素血条、分数、技能冷却、暂停按钮、结算面板
美术风格16-bit pixel art、暗黑科幻、手绘、低多边形
验收标准能开始、能移动、能攻击、能失败、能胜利、能重开

一个更工程化的 prompt 示例:

Create a Phaser web game: a top-down survival shooter.
The player moves with WASD and aims with mouse.
Enemies spawn in waves every 20 seconds.
Add health, score, pause, restart, and a victory screen after wave 5.
Use dark sci-fi pixel art style.
Acceptance criteria: the game must start from a menu, the player can move and shoot, enemies can damage the player, defeated enemies increase score, and the restart button resets all state.

工程实践

先生成小原型

不要一开始就要求开放世界、复杂经济系统、多人同步和长剧情。更好的做法是先生成一个可玩的核心循环,再逐步扩展关卡、资源、角色和数值。

把验收标准写进 prompt

游戏生成最大的坑不是“代码无法运行”,而是“运行了但不像你要的游戏”。把可验证条件写清楚,例如:

  • 开始菜单必须能进入游戏。
  • 玩家死亡后必须出现结算页。
  • 重新开始必须清空敌人、分数和计时器。
  • 移动端不要求支持,或者明确要求支持触控。

保留生成记录

每次生成后建议保存:

  • 原始 prompt
  • 生成的源码
  • 运行截图
  • 控制台错误
  • 修改记录

这样后续可以比较不同 prompt、模型和 provider 的效果,也方便把成功经验沉淀为模板。

注意版权边界

官方 demo 中展示了很多知名 IP 风格的游戏示例。自己实验时可以用“类似 90 年代街机像素风”“科幻赏金猎人”等描述来表达风格,避免直接把受版权保护的角色、名称、剧情和素材用于公开发布或商业项目。

适用场景

OpenGame 适合:

  • 快速做 Web 游戏原型
  • 测试玩法创意
  • 研究代码 Agent 如何处理复杂交互项目
  • 构建游戏生成 benchmark
  • 给 Phaser、Canvas、Three.js 项目生成初始骨架
  • 教学场景中演示从需求到可运行应用的完整链路

暂时不适合:

  • 直接生成大型商业游戏
  • 对物理、联网、性能和资产管线要求极高的项目
  • 强版权 IP 的公开复刻
  • 没有人工验收的自动上线流程

常见问题

1. OpenGame 是 no-code 工具吗?

不是。它更像“代码生成 Agent + 游戏开发技能 + 自动调试流程”。最终产物仍然是可编辑的 Web 游戏源码。

2. 现在能直接使用 GameCoder-27B 吗?

目前不建议把 GameCoder-27B 当作可直接下载部署的依赖来规划。公开资料里能看到论文对它的描述,但我没有找到稳定可用的模型权重或下载入口。实际使用 OpenGame 时,重点是配置 OpenAI-compatible API,让 OpenGame 调用你选择的大模型完成代码生成和调试。

3. 为什么强调 Web 游戏?

Web 游戏更容易自动构建、启动和用 headless browser 验证。相比 Unity 或 Unreal,浏览器环境更适合 Agent 做端到端执行反馈。

4. --yolo 安全吗?

--yolo 会让 Agent 执行 shell 命令。建议只在隔离目录、临时目录或容器中使用,不要在含有重要文件的目录里直接运行。

5. 生成的游戏能不能商用?

需要分别检查代码许可证、生成素材来源、模型服务条款,以及 prompt 中是否包含受版权保护的 IP。OpenGame 仓库本身使用 Apache-2.0 license,但生成内容的权利边界还要看具体素材和模型服务。

小结

OpenGame 的意义不只是“AI 写小游戏”。它把智能体软件工程推进到一个更难的交互式场景:多文件、一致状态、实时循环、视觉反馈和用户输入必须同时成立。

如果说普通代码 Agent 的验收标准是“能不能编译、测试能不能过”,OpenGame 这类框架的验收标准更接近真实应用:能不能打开、能不能玩、是否符合设计意图。这个方向对游戏开发有价值,对更广义的前端应用、仿真工具和交互式产品生成也有启发。

参考