游戏开发

背景 上一篇文章整理了 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 是 CUHK MMLab 在 2026 年 4 月发布的开源智能体框架，目标是让用户用一段自然语言描述生成一个可运行、可交互的 Web 游戏。项目论文为 OpenGame: Open Agentic Coding for Games，官方代码仓库在 leigest519/OpenGame。 它解决的问题不是“让大模型写一段游戏代码”，而是让 Agent 完成一整个游戏工程：选择技术模板、生成多个文件、维护游戏状态、处理资源、启动构建、检查运行错误，并反复修复到可玩状态。这个目标比普通代码生成更难，因为游戏开发同时依赖实时循环、输入系统、碰撞逻辑、场景连接、资源加载和 UI 状态。 截至 2026-05-06，OpenGame 已经公开框架代码和演示项目，npm release 仍在准备中，官方推荐从源码安装。 结论 OpenGame 的核心价值可以概括为三点： 它把“游戏生成”从单次代码补全变成了端到端 Agent 流程。 它用 Game Skill 管理模板选择和调试经验，降低跨文件工程崩坏的概率。 它用 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 在目标目录中生成游戏项目，并在必要时修改文件、修复错误、输出运行方式。 ...