W
AI-Wiki
SOURCE

Godogen 这个神器，让普通人也能开始做 Godot 游戏 摘要

文档概览

这篇文章介绍的核心对象是 Godogen，但作者一开始就强调一个容易被误解的点：它不是一个游戏项目本身，而是一个用于生成新的 Godot 游戏项目的“项目生成器”。

作者给出的理解框架很明确：先用 Godogen 生成一个新的目标项目，再在这个生成后的项目中让 Codex 接管开发。Codex 接到自然语言需求后，不只是“写一段代码”，而是会按 Godot 项目的方式去规划结构、编写代码、运行引擎、截图检查结果，并继续修问题。

因此，文章真正强调的不是“AI 一句话生成游戏”这种标题党式卖点，而是 AI 游戏开发流水线代理 的方向：让 AI 尽量跑完整个游戏开发闭环，而不是停留在静态代码生成阶段。

关键事实

Godogen 的定位：不是游戏，而是游戏项目生成器

作者用一句话概括 Godogen：它不是一个游戏项目，而是一个「游戏项目生成器」。

这一定义非常关键，因为它直接决定了正确的使用方式：

  • 不要把 Godogen 源仓库当作你要直接开发游戏的地方。
  • 源仓库的作用是“发布”出一个新的可开发项目。
  • 真正让 Codex 参与开发的，是发布生成后的目标项目目录。

作者认为，Godogen 想解决的问题也不是“让 AI 写一段游戏代码”，而是“让 AI 跑完一套游戏开发流水线”。

正确工作流：先发布新项目，再进入新项目开发

文中明确提醒：不要直接在 Godogen 源仓库里做游戏。正确流程是先在源仓库执行发布命令：

./publish.sh --engine godot --agent codex --out ~/my-godot-game

执行后，会生成一个新的游戏目录，例如：

~/my-godot-game

然后再进入这个新项目目录：

cd ~/my-godot-game

接下来才是在这个生成项目里打开 Codex，并输入类似下面的自然语言需求：

$godogen 做一个 2D 平台跳跃游戏，有玩家移动、跳跃、金币、敌人、血量和胜利条件

也就是说，Godogen 的使用模式不是“在原仓库里改代码”，而是“原仓库负责产出一个带好 Agent 配置、技能和钩子的目标项目”。

生成项目里供 Codex 使用的关键文件与目录

作者列出了生成后的项目中，Codex 真正会用到的一组关键文件和目录：

  • AGENTS.md
  • .agents/skills/godogen/
  • .agents/skills/godot-api/
  • .codex/hooks/
  • .gitignore

文章的意思很明确：这些内容才是 Codex 在目标项目中理解开发规则、读取技能说明、调用工作流钩子的重要基础。

其中，.agents/skills/ 下的技能说明尤其关键。作者明确写到，当用户在生成项目里输入 $godogen ... 形式的自然语言需求后，Codex 会读取这些技能说明，并“按 Godot 项目的方式开始生成游戏”。

这使 Godogen 更接近一种“给 AI 准备好工程上下文和执行规范”的包装层，也和 AI 编码代理审美技能包 这种把经验打包为代理可读技能的思路相呼应。

使用方式：在生成项目中通过 $godogen 提交自然语言需求

文章展示的标准交互形式，是在生成项目里直接给 Codex 输入 $godogen ... 命令，例如：

$godogen 做一个俯视角射击游戏，玩家 WASD 移动，鼠标瞄准，敌人会追踪玩家，击杀后加分，达到 100 分胜利

或者：

$godogen 做一个简单完整的 2D Godot 小游戏

作者强调，Codex 在这个过程中不是盲写代码，而是会结合技能目录、Godot 项目结构和后续运行反馈来构建游戏。

Godogen 与普通 AI 写代码的核心差异

文章反复强调 Godogen 的真正价值，不是“让 AI 写代码”，而是“让 AI 跑流程”。作者特别指出，游戏开发最麻烦的地方从来不只是写代码，还包括：

  • 项目结构
  • 场景树
  • 输入系统
  • UI
  • 角色、敌人、关卡、胜负条件
  • 项目是否真的能跑起来
  • 画面是否正确

作者还举了一些游戏开发中很常见、但静态代码检查无法解决的问题：

  • 代码能编译，但角色没显示
  • 镜头位置不对
  • UI 挡住画面
  • 敌人生成在奇怪的位置

所以 Godogen 的关键推进，是把 Codex 从“写代码助手”推进成“能根据运行结果继续修项目的开发搭子”。

作者后文把这一流程进一步拆开，指出 Godogen 值得关注的不是“一句话生成游戏”这个说法，而是它把游戏开发拆成了一套 Agent 可执行步骤：

  • 自然语言需求
  • 项目发布
  • 技能加载
  • 代码生成
  • 引擎运行
  • 截图检查
  • 问题修复

这与普通 AI 编码最大的区别在于：普通 AI 常停在“我觉得我写好了”，而 Godogen 试图让 AI 去看运行结果，再继续修正。这一点可以视为 Godot AI 原型闭环 的典型形态。

重要细节

环境要求

文章给出了一组非常具体的环境约束。

1. Godot 必须是 .NET 版

作者明确说：普通 Godot 不行，因为这个仓库输出的是 C# 项目。因此必须使用 Godot 的 .NET 版本。

文中建议先确认版本：

godot --version
dotnet --version

2. 建议使用 .NET 9.x

文章给出的建议是：dotnet 最好使用 9.x。

这不是泛泛而谈的“装个 .NET 就行”，而是带版本倾向的建议，意味着作者认为这一工作流与较新的 .NET SDK 组合更稳妥。

3. Godot 需要支持无头运行

作者特别强调，Godot 需要能执行无头启动测试：

godot --headless --quit

这一步的重要性在于，Godogen 的闭环里不只是生成代码，还要能够运行引擎，后续还涉及截图检查与继续修复。因此无头运行能力是自动化流水线成立的前提之一。

常见安装排查点

如果执行无头命令时报 C# assembly 相关错误，作者给出两个高概率原因：

  • Godot .NET 安装不完整
  • GodotSharp/ 没有和 Godot 可执行文件放在一起

这是文中较为具体的排错信息，说明问题不只是“环境不对”，而是很可能出在 Godot .NET 组件安装完整性，或 GodotSharp/ 与可执行文件的相对位置上。

脚本依赖与 Windows 使用建议

文章还强调了 publish.sh 的运行前提：它是一个 Bash 脚本，会用到：

  • python3
  • rsync
  • chmod

因此作者给出的建议非常直接：Windows 用户更适合直接用 WSL，不要硬在 PowerShell 里折腾。

这实际上是在提示一个边界条件：即便 Godogen 面向“普通人也能开始做 Godot 游戏”，它也并不是零门槛图形化工具，底层仍然要求用户接受命令行与 Unix 风格工具链。

最短安装路径与基础检查

作者给出了一组最短检查路径，建议先确认这些工具都能正常工作：

python3 --version
rsync --version
dotnet --version
godot --version

确认这些基础环境没问题后，再在源仓库中执行发布命令：

./publish.sh --engine godot --agent codex --out ~/my-godot-game

然后进入生成的新项目：

cd ~/my-godot-game

最后再用 Codex 通过 $godogen 开始生成。

文章给出的使用建议

第一次测试不要把需求写得过大

作者明确提醒，第一次测试这条流水线时，不要一上来就要求：

  • 开放世界
  • 联机
  • 背包
  • 技能树
  • 剧情系统
  • 全都同时具备

相反，应该先做一个“小闭环”。作者给出的例子包括：

做一个 2D 打砖块游戏，有开始界面、分数、生命、胜利和失败界面

以及：

做一个 2D 横版跳跃游戏，有三枚金币、一个敌人、一个终点门