在超级智能时代制作游戏：首个可玩版本的计划

一个游戏想法可能在玩家看到之前，先经过好几个智能体。一个设计关卡，一个编写代码，另一个检查构建结果。有价值的成果不是更多文件，而是有人能够完成一局，并愿意再玩一局。

先用简短的约定写清要做什么、怎样验收。本页的免费简报工具会询问玩家操作、目标、结束条件、视角、控制方式和首个目标平台。它会导出供人分享的 Markdown 简报，以及可供其他工具使用的 JSON 计划。这两份文件是制作游戏的起点。

这里的“超级智能”是什么意思

超级智能是未来的一种可能性。今天的 AI 助手或智能体已经能够参与游戏项目，但把产品称作“SI 游戏引擎”，并不能证明它能独立设计、制作、测试和发布好游戏。要看工具能读取什么、修改什么、能否运行游戏，以及每次修改后能展示哪些结果。

现有工作方式各有具体能力。Godot 文档介绍了通过命令行运行和导出项目，便于重复检查构建结果。Unity 的 Assistant 软件包文档介绍了只查询的 Ask 模式，以及可按权限操作场景对象和资源的 Agent 模式。Epic 的 Unreal MCP 文档将其列为实验性的编辑器功能，可向兼容的智能体提供工具，功能和 API 仍可能变化。应根据它们今天在实际项目中的表现作选择。

确定首个可玩版本

描述完整的一局，而不是最终游戏的全部功能。写明玩家控制谁、要做什么、怎样获胜、什么情况会结束，以及如何重新开始。只选一个场景和一个目标平台。商店、多关卡、账号、多人模式和长篇故事可以留到以后，除非它们是核心操作必需的部分。

写出一句可以直接用于制作的话：“穿过一条街，收集三颗火花，不碰到推车并到达门口。”再补齐横向视角、键盘控制、浏览器构建版本、胜负反馈和重开操作。视觉方向可以指导制作，但第一个里程碑应是可玩的一局。

示例：Lantern Run

设想一个名叫 Lantern Run 的小型横向游戏。玩家控制快递员穿过雨中的街道，绕开水坑并收集三颗火花。带着三颗火花抵达门口就获胜；碰到移动的推车则结束本局。首个版本只需一条街、一个角色、三颗火花、一辆推车、可见的计数器和重开操作。

交接任务时，附上任何人都能观察的检查项：

1. 打开浏览器构建版本。游戏场景正常加载，没有阻止游玩的错误。
2. 使用键盘。角色能移动、绕开水坑、收集火花；计数器随之变化。
3. 不足三颗火花时到达门口。游戏不会宣布获胜。
4. 带着三颗火花到达门口。游戏明确显示胜利。
5. 碰到推车。本局结束并给出清楚反馈。重开后可以开始新的一局。
6. 在编辑器外打开导出的版本。请第一次接触游戏的人不看说明，独立完成一局。

这些检查项不规定代码或引擎，只说明运行中的游戏需要达到什么结果。若某项未通过，下一步该改什么就很清楚。

为这个版本选择引擎

根据游戏本身的需求比较引擎：视角、输入方式、目标平台、导出流程以及是否能取得项目文件。在投入长期制作前，先做一次小规模导出。浏览器和桌面平台的配置与输入要求可能不同；请核对你实际使用的引擎版本的说明。

如果想用 Summer 制作，可以阅读 AI 游戏引擎指南、Godot AI 智能体指南和 MCP 设置页面。这些页面解释 Summer 的工作方式。本页的简报也可用于其他引擎。交接时保留原始项目和导出包，让其他人能检查成品。

把可验证的工作交给智能体

将简报交给智能体，每次只安排一项任务。“让快递员能用键盘移动，并展示运行中的场景”就容易检查。要求对方列出修改过的文件、运行或构建结果，以及尚未解决的问题。每次重要修改后，自己也要玩一遍。

在简报旁维护素材清单。每加入一张图片、一个模型、一段声音或一种字体，就记录其来源和所依据的许可或条款。若来源或允许的用途不明确，应在发布前替换。

测试并发布你验证过的版本

先在编辑器内执行检查项，再在目标平台上用导出的版本完整玩一局。留意失效的输入、缺失的文件、难读的提示、声音问题，以及重新开始后仍残留的旧状态。观察新玩家游玩，不解释规则，记下他们首先尝试什么、在哪里停下。

如果构建版本未通过，就把下一项工作缩小为一个可观察的修复，并再次测试。通过后，你就有了首个可玩版本，也有依据决定接下来增加什么。未来的 AI 也许能承担更多制作工作；当前最重要的验证仍很简单：一个人能打开游戏、理解操作、完成一局，并选择再玩一局。