上一篇文章整理了 OpenGame 的基本概念：它可以把自然语言提示词转成一个可运行的 Web 游戏工程。但如果只在命令行里执行 opengame -p "..." --yolo，很快会遇到几个工程问题：

• 生成任务耗时长，需要队列和状态追踪。
• Agent 输出很多日志，需要实时可视化。
• 游戏不是“一次生成就结束”，需要 GDD 审核、分阶段实现、失败修复、版本迭代。
• 生成结果需要可预览、可试玩、可换皮，而不是只留在本地目录。
• 失败原因需要结构化，否则很难知道是 API 中断、构建失败、资源缺失，还是画面质量不过关。

所以我设计了一个 opengame-web-console：它不是简单包一层按钮，而是把 OpenGame SDK 放进一个任务化、可观察、可修复、可迭代的控制中心。

结论

这个控制中心的核心设计可以概括为一句话：

前端只负责提交需求和观察状态，后端把每一次游戏生成封装成任务，任务运行时负责规划、调用 SDK、执行门禁、自动修复、沉淀版本。

整体链路如下：

用户提示词
  ↓
Web Console
  ↓
POST /api/tasks
  ↓
TaskService 创建任务记录与 workspace
  ↓
TaskQueue 串行调度
  ↓
TaskRunner 调用 @opengame/sdk
  ↓
OpenGame Agent 在 workspace 中生成游戏
  ↓
Playable / Visual Gate
  ↓
成功：保存 previewEntry，可预览、试玩、迭代、换皮
失败：记录 failureReason，生成修复 prompt，可重试

为什么不是直接调用 CLI

直接调用 CLI 适合本地实验，但不适合做“控制中心”。控制中心需要解决的是长期运行问题：

因此控制中心的第一原则是：不要把 OpenGame 当成一个一次性命令，而要当成一个异步任务运行时。

技术栈

控制中心使用的技术栈比较克制：

运行时数据默认放在：

data/
├── app.db
└── runs/
    └── <taskId>/
        ├── workspace/
        └── events.jsonl

这里的 workspace/ 是每个任务的独立生成目录，events.jsonl 是任务运行日志。

组件设计

前端组件

前端围绕一个 Workbench 展开：

Workbench
├── TaskCreateForm        # 创建任务：标题、提示词、自动/半自动、full/mvp
├── TaskList              # 任务队列
├── StatusBadge           # 状态展示
├── GddReviewPanel        # 半自动模式下审核 GDD
├── TaskPipelineReport    # M1-M4 与 Gate 报告
├── TaskQualityReport     # 可玩性与视觉质量报告
├── TaskPreviewPanel      # iframe 预览
├── TaskPlayLink          # 打开沉浸式试玩页
├── VersionIterateForm    # 基于当前版本继续迭代
├── VersionList           # 版本链
├── SkinManager           # 导出占位资源包、上传换皮包
└── TaskLogPanel          # 实时日志

前端不直接碰 OpenGame SDK。它只调用控制中心 API，并通过 SSE 或定时刷新同步任务状态。

后端组件

后端核心组件如下：

Container
├── env                  # 数据目录配置
├── db                   # SQLite
├── TaskRepository       # tasks 表读写
├── GameRepository       # games 与版本链
├── WorkspaceManager     # 为 task 创建 workspace
├── TaskQueue            # 串行队列
├── SdkClient            # @opengame/sdk 封装
├── TaskRunner           # SDK 流式消息转 TaskEvent
├── TaskService          # 任务生命周期编排
├── PlayableChecker      # 浏览器可玩性检查
├── VisualQualityChecker # 视觉与资源质量检查
└── SkinService          # 换皮与资源包

其中 TaskService 是最重要的编排层。它不负责具体写游戏代码，而是负责决定什么时候规划、什么时候实现、什么时候检查、什么时候修复、什么时候把任务标记为成功或失败。

API 设计

控制中心 API 可以分为五类。

任务 API

GET  /api/tasks
POST /api/tasks
GET  /api/tasks/:taskId
POST /api/tasks/:taskId/retry
GET  /api/tasks/events
GET  /api/tasks/:taskId/events

创建任务的请求体：

{
  "title": "太空塔防",
  "prompt": "创建一个太空主题塔防游戏...",
  "automationMode": "auto",
  "pipelineMode": "full"
}

automationMode 有两种：

pipelineMode 也有两种：

GDD API

GET  /api/tasks/:taskId/gdd
PUT  /api/tasks/:taskId/gdd
POST /api/tasks/:taskId/gdd/approve

半自动模式下，任务会先进入 awaiting_gdd_review。用户可以在页面里编辑 GDD，再点击确认，后端才继续进入实现阶段。

预览与试玩 API

GET /api/tasks/:taskId/preview
GET /api/tasks/:taskId/preview/assets/*
GET /api/tasks/:taskId/play
GET /tasks/:taskId/play

preview 是嵌在控制台里的预览，play 是更沉浸的试玩页。控制台不会要求用户进入服务器目录找 index.html，而是把生成产物代理成 Web 路由。

版本 API

GET  /api/tasks/:taskId/versions
POST /api/tasks/:taskId/iterate
POST /api/tasks/:taskId/versions/:versionId/promote

每次迭代不是覆盖原任务，而是复制旧 workspace，生成一个新版本任务：

V1 workspace
  ↓ clone
V2 workspace
  ↓ 修改 prompt：基于 V1 做增量需求
V2 进入任务队列

这样可以保留历史版本，也可以随时把某个版本提升为当前版本。

换皮 API

GET  /api/tasks/:taskId/skin/placeholders
POST /api/tasks/:taskId/skin
GET  /api/tasks/:taskId/skin/active/*

生成游戏时，Agent 会被要求创建 skin-manifest.json，声明哪些 PNG 资源可以替换。控制中心可以导出占位资源包，用户替换后上传 zip，后端会创建一个新的成功版本。

任务状态机

任务状态设计如下：

queued
  ↓
running
  ├─ planning
  │   ├─ auto       → m1_mvp
  │   └─ semi_auto  → awaiting_gdd_review
  │                    ↓ approve
  │                  queued → running
  ├─ m1_mvp
  ├─ m2_complete_loop
  ├─ m3_visual_audio
  ├─ m4_polish
  ├─ final_gate
  └─ repair
      ↓
succeeded / failed

状态字段分两层：

• status 表示任务总体状态，例如 queued、running、awaiting_gdd_review、succeeded、failed。
• currentStage 表示当前流水线阶段，例如 planning、m1_mvp、repair。

这样 UI 可以同时展示“任务还在 running”和“现在跑到 M3 visual/audio”。

生成流水线

控制中心把一次生成拆成规划和实现两大段。

1. Planning：先写 GDD

Planning 阶段只做一件事：根据用户 prompt 生成 docs/opengame-gdd.md。

用户 prompt
  ↓
buildOpenGamePlanningPrompt()
  ↓
@opengame/sdk 在 planning-workspace 运行
  ↓
输出 docs/opengame-gdd.md
  ↓
复制到主 workspace

这里有一个小设计：规划阶段运行在 planning-workspace，不是直接在主 workspace 里写。这样可以避免规划 Agent 误生成实现文件。规划完成后，只把 GDD 文档复制回主 workspace。

如果文件没写成功，系统还会尝试从 Agent 输出中的标记恢复：

BEGIN_OPENGAME_GDD
...
END_OPENGAME_GDD

这能降低“Agent 说它写了文件，但文件实际不存在”的失败率。

2. M1-M4：分阶段实现

完整模式会跑四个实现阶段：

每个阶段都会把 GDD、用户原始需求、上一阶段门禁证据一起喂给 Agent：

GDD + userPrompt + stageGoals + previousEvidence
  ↓
buildOpenGameStagePrompt()
  ↓
TaskRunner 调用 @opengame/sdk
  ↓
Agent 修改 workspace
  ↓
Gate 检查
  ↓
通过则进入下一阶段
失败则进入 repair

这个设计的好处是让 Agent 不必一次性完成所有要求。M1 先保可玩，M2 补完整循环，M3 做表现，M4 做收尾。

SDK 调用设计

控制中心通过 SdkClient 封装 @opengame/sdk：

TaskRunner
  ↓
SdkClient.runTask({ prompt, cwd })
  ↓
query({
  prompt,
  options: {
    cwd,
    permissionMode: "yolo",
    debug: true,
    mcpServers: {
      "opengame-assets": assetServer
    }
  }
})

关键点有三个：

1. cwd 指向任务 workspace，Agent 的所有文件操作都限制在这个任务目录里。
2. permissionMode: "yolo" 允许 Agent 在任务目录内执行必要命令，适合受控的服务器环境。
3. 注入 opengame-assets MCP Server，让 Agent 可以调用 generate_game_asset 生成 PNG 游戏资源。

TaskRunner 会把 SDK 的流式消息转成统一的 TaskEvent：

SDK stream message
  ↓
mapSdkMessageToTaskEvents()
  ↓
task.log / task.completed / task.failed
  ↓
写入 events.jsonl
  ↓
通过 SSE 推送到前端

为了避免任务卡死，TaskRunner 还做了两层超时：

• idle timeout：一段时间没有新消息，认为 SDK 卡住。
• wall timeout：单次尝试总运行时间超限。

对 API 中断和 timeout 这类可重试错误，最多尝试 3 次。

实时日志设计

日志有两条路径：

TaskEvent
  ├── append events.jsonl       # 持久化
  └── emitTaskEvent()           # 内存事件总线
        ↓
      /api/tasks/events         # 全局 SSE
      /api/tasks/:id/events     # 单任务 SSE
        ↓
      TaskLogPanel / Workbench

为什么既要 JSONL，又要 SSE？

• SSE 负责实时体验。
• JSONL 负责刷新后还能看到历史日志。
• 如果 SSE 推送失败，不应该影响任务执行，所以日志写入也是 best effort。

质量门禁

一次 Agent 生成结束后，控制中心不会立刻标记成功，而是跑 gate。

Static Preview Gate

先检查是否能找到可预览入口：

npm run build
  ↓
resolvePreviewEntry()
  ↓
index.html / dist/index.html / 其他可预览入口

如果找不到入口，任务失败，失败原因会归类为 build_failed 或相关类型。

Playable Gate

Playable Gate 会启动一个临时预览服务器，再用 Playwright 打开页面：

startPreviewServer()
  ↓
Playwright chromium
  ↓
监听页面错误、console error、资源 404
  ↓
检查 Loading 是否消失
  ↓
检查 canvas 是否空白

这一步解决的是“能构建但不能玩”的问题。

Visual Gate

Visual Gate 更偏游戏观感：

打开预览页
  ↓
截图
  ↓
采样 canvas 像素
  ↓
检查 skin-manifest.json
  ↓
检查 PNG 是否存在、尺寸是否足够、是否被实际引用

它会拒绝几类结果：

• 没有 canvas。
• canvas 全空白。
• canvas 颜色过于单一，看起来像占位图。
• 没有 skin-manifest.json。
• manifest 里的资源缺失。
• active asset 不是 PNG。
• 资源太小或未被游戏引用。

自动修复逻辑

如果 Gate 失败，控制中心不会马上结束，而是进入 repair：

Gate failed
  ↓
buildOpenGameRepairPrompt(errorMessage, gddDraft, stage)
  ↓
Agent 在原 workspace 中修复
  ↓
再次运行 Gate
  ↓
最多修复 2 次

修复 prompt 的核心要求是：

• 不要从零重写。
• 在现有 workspace 中做最小修复。
• 保证 preview entry 存在。
• 保证所有本地 script、style、image、skin asset 都存在。
• 如果是视觉质量失败，就补 PNG、改布局、修按钮反馈。
• 如果是缺资源，就优先创建缺失路径。

对“预览 HTML 引用了不存在的本地资源”这种问题，还有专门的 targeted repair prompt，要求 Agent 先创建这些精确路径，避免越修越偏。

资源生成 MCP

控制中心为 OpenGame SDK 注入了一个 generate_game_asset 工具：

Agent
  ↓ call generate_game_asset
  ↓
Asset MCP Server
  ↓
Image Provider
  ├── tongyi
  ├── doubao
  ├── openai-compat
  └── n1n
  ↓
写入 workspace 内 PNG 文件

工具入参包括：

{
  "prompt": "space tower turret",
  "outputPath": "public/skins/active/turret.png",
  "size": "1024*1024",
  "kind": "sprite",
  "transparentBackground": true,
  "styleGuide": "dark sci-fi pixel art",
  "negativePrompt": "text, logo, watermark"
}

如果图片 provider 超时、限流或临时失败，系统会用 sharp 生成一个 fallback PNG。这样任务不会因为图片服务偶发不可用而完全中断。

版本链设计

游戏生成成功后，它不只是一个 task，也是一个 game version。

games
└── gameId
    ├── V1 taskId
    ├── V2 taskId
    └── V3 taskId

当用户基于某个版本继续迭代时：

选择 V1
  ↓
输入 changeNote
  ↓
复制 V1 workspace 到 version-2
  ↓
构造迭代 prompt
  ↓
创建 V2 task
  ↓
进入同一套队列与 Gate

这个设计比“覆盖式修改”稳很多。每次迭代都有完整产物、日志、质量报告和回退路径。

换皮设计

换皮不是让用户直接上传任意图片覆盖目录，而是依赖 skin-manifest.json。

manifest 结构大致是：

{
  "version": 1,
  "assets": [
    {
      "key": "player",
      "label": "玩家角色",
      "path": "public/skins/active/player.png",
      "placeholderPath": "public/skins/placeholders/player.png",
      "mimeType": "image/png"
    }
  ]
}

控制中心可以：

1. 根据 manifest 导出占位资源 zip。
2. 用户替换 zip 内同路径 PNG。
3. 上传 zip。
4. 后端复制当前 workspace。
5. 只替换 manifest 中声明的资源。
6. 重新 npm run build。
7. 创建一个新的成功版本。

换皮本质上也是版本迭代，只是它不调用大模型。

失败分类

失败不能只存一段错误文本。控制中心会把失败归类为 failureReason，例如：

结构化失败原因有两个作用：

• UI 可以显示更友好的失败说明。
• retry 可以判断从哪个阶段恢复，例如只重跑 gate，还是回到 planning。

进程重启恢复

服务启动时会扫描所有 running 任务：

server boot
  ↓
recoverRunningTasks()
  ↓
running → failed
  ↓
failureReason = recovered
  ↓
写入 task.failed 日志

这样做很朴素，但非常重要。因为 Node 进程重启后，内存里的队列已经没了，继续显示 running 会误导用户。把它们标记为可解释的失败状态，再允许用户 retry，是更可靠的选择。

总体逻辑图

完整控制中心可以这样理解：

┌────────────────────┐
│     React UI        │
│ create/list/log/play│
└─────────┬──────────┘
          │ HTTP / SSE
          ▼
┌────────────────────┐
│   Next.js API       │
│ route handlers      │
└─────────┬──────────┘
          │
          ▼
┌────────────────────┐
│   TaskService       │
│ lifecycle director  │
└──────┬───────┬──────┘
       │       │
       │       ├──────────────┐
       ▼       ▼              ▼
┌──────────┐ ┌──────────┐ ┌───────────────┐
│ SQLite   │ │ JSONL Log│ │ Workspace FS  │
└──────────┘ └──────────┘ └───────────────┘
       │
       ▼
┌────────────────────┐
│    TaskQueue        │
└─────────┬──────────┘
          ▼
┌────────────────────┐
│    TaskRunner       │
└─────────┬──────────┘
          ▼
┌────────────────────┐
│  @opengame/sdk      │
│  + asset MCP        │
└─────────┬──────────┘
          ▼
┌────────────────────┐
│ Generated Web Game  │
└─────────┬──────────┘
          ▼
┌────────────────────┐
│ Playable/Visual Gate│
└──────┬────────┬─────┘
       │        │
       ▼        ▼
  succeeded   repair / failed

设计取舍

1. 串行队列，而不是并发队列

当前实现使用单队列串行执行。这样吞吐低一些，但更稳：

• 避免多个 Agent 同时抢 CPU、网络和图片 provider。
• 避免 Playwright 与构建进程把服务器打满。
• 更容易定位日志和失败原因。

等单任务链路稳定后，再考虑按资源配额做并发。

2. 本地 SQLite，而不是一开始上 PostgreSQL

控制中心首先是单机工具，SQLite 足够简单可靠。任务元数据放 SQLite，产物放文件系统，日志放 JSONL，正好符合静态产物生成场景。

如果后续要多人使用、分布式队列、多机执行，再迁到 PostgreSQL + Redis Queue 会更合适。

3. Gate 失败自动修复，但限制次数

自动修复有价值，但不能无限循环。当前最多修复 2 次。这样可以覆盖资源缺失、构建小错误、空白画面等常见问题，同时避免 Agent 在错误方向上无限消耗。

4. 半自动 GDD 审核是必要入口

全自动适合快速试验，但复杂游戏最好先审 GDD。GDD 是后续 M1-M4 的源头，如果需求理解错了，后面生成得越完整，返工越重。

小结

OpenGame Web 控制中心真正解决的不是“给命令行加一个网页按钮”，而是把 AI 生成游戏这件事产品化：

• 用任务队列承接长耗时生成。
• 用 GDD 把模糊需求变成工程计划。
• 用 M1-M4 把一次性生成拆成可控阶段。
• 用 Playwright 和视觉检查把“可玩”变成门禁。
• 用 repair prompt 把失败转成下一轮修复输入。
• 用版本链和换皮把一次生成变成可持续迭代。

这套设计也可以迁移到其他 Agent 应用：只要任务耗时长、结果需要验收、失败需要自动修复，就应该把 Agent 调用包进类似的控制中心，而不是停留在一次性脚本调用。

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_KEY、OPENAI_BASE_URL 和 OPENAI_MODEL 配好，用现有大模型跑通流程；等官方后续公开专用模型或推理服务后，再考虑切换。

OpenGame-Bench

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

这个评估方向很关键。普通代码 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_URL 和 OPENAI_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 至少包含以下内容：

一个更工程化的 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 这类框架的验收标准更接近真实应用：能不能打开、能不能玩、是否符合设计意图。这个方向对游戏开发有价值，对更广义的前端应用、仿真工具和交互式产品生成也有启发。

参考

• OpenGame Project Page
• GitHub: leigest519/OpenGame
• arXiv: OpenGame: Open Agentic Coding for Games
• Hugging Face Papers: OpenGame