W
AI-Wiki
ENTITY

Godogen

定义

Godogen 是文中介绍的一个开源项目，但它不是一个最终游戏项目，也不是普通意义上的代码模板仓库。

更准确地说，它是一个面向 Godot 的游戏项目生成器：先由 Godogen 生成一个新的 Godot 项目骨架，再让 Codex 在这个新项目里接管后续开发。

它想解决的重点，也不是“让 AI 写一段游戏代码”，而是把自然语言需求、项目结构生成、代码编写、引擎运行、截图检查、问题修复这些步骤串成一条可执行的 AI 游戏开发流水线代理|游戏开发流水线。

身份边界

Godogen 的边界需要特别说明：

  • 它不是你直接拿来开发游戏的源仓库。
  • 它不是单个可运行游戏。
  • 它不是只提供几份示例脚本的静态模板。
  • 它的职责是发布出一个新的目标项目目录，让 AI 代理在那个目录里工作。

因此，真正的游戏开发环境不在 Godogen 源仓库本身，而在它生成出来的新目录中。

正确使用方式

文中的正确流程，是在 Godogen 源仓库里执行发布脚本，而不是直接在源仓库里写游戏：

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

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

~/my-godot-game

之后应该进入这个新目录：

cd ~/my-godot-game

然后再打开 Codex，在新项目目录中发出类似下面的提示：

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

也就是说：

  • publish.sh 在源仓库里执行。
  • Codex 真正工作的上下文，在生成后的新项目目录里。
  • 不应把 Godogen 源仓库误当成待开发游戏本体。

生成项目中的关键组成

文中明确提到，生成出来的新项目目录中，大致会包含以下关键文件或目录：

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

这些内容才是 Codex 真正会读取和使用的部分。

其中可以据文意理解为：

  • AGENTS.md：提供代理工作说明或项目级行为约束。
  • .agents/skills/godogen/：放置与 Godogen 工作流相关的技能说明。
  • .agents/skills/godot-api/：放置面向 Godot API 的技能说明。
  • .codex/hooks/：提供与 Codex 运行流程配合的 hooks。
  • .gitignore：用于项目版本控制时的忽略规则。

与 Codex 的配合方式

Godogen 的工作方式不是“自己把完整游戏一次性吐出来”，而是为 Codex 准备一个适合接管的 Godot 项目环境。

用户进入新项目目录后，可以直接输入 $godogen ... 风格的自然语言需求，例如：

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

这时，Codex 会读取 .agents/skills/ 中的技能说明，按 Godot 项目的组织方式生成内容。

文中对这条链路的描述包括：

  • 规划游戏结构。
  • 写代码。
  • 生成项目结构。
  • 运行 Godot。
  • 截图检查结果。
  • 根据发现的问题继续修复。

这也是它区别于普通 AI 写代码的重要地方：普通 AI 往往停在“我觉得我写好了”，而 Godogen 这类方案尝试把 AI 推向“运行、观察、修正”的闭环，更接近 Godot AI 原型闭环。

技术约束

必须使用 Godot .NET 版

文中强调，Godogen 的 Godot 输出是 C# 项目，因此必须使用 Godot .NET 版，普通版 Godot 不行。

这是一个硬性约束，不是可选优化项。

可用以下命令检查环境：

godot --version
dotnet --version

其中 dotnet 文中建议使用 9.x。

Godot 需要支持无头启动

还需要确认 Godot 可以无头运行：

godot --headless --quit

如果这里报出 C# assembly 相关错误，文中给出的高概率原因有两个：

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

发布脚本依赖 Bash 工具链

publish.sh 是 Bash 脚本，会用到：

  • python3
  • rsync
  • chmod

因此文中明确建议 Windows 用户直接使用 WSL，而不要硬在 PowerShell 里折腾。

最短检查路径可先确认这些命令可用：

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

角色职责

在整条流程中，Godogen 的职责主要有三层：

  1. 发布项目：从源仓库生成新的目标游戏目录。
  2. 注入代理工作环境：放入 AGENTS.md、skills、hooks 等文件，让 Codex 知道该如何以 Godot 项目方式工作。
  3. 把开发重点从单次代码生成推进到流程闭环：让 AI 有机会围绕运行结果继续修正项目，而不是只输出静态代码片段。

换句话说，Godogen 不是游戏内容本身，而是给 Codex 准备“可接管的游戏工程起点”。

使用建议与边界

文中建议，第一次测试不要一上来就给非常复杂的需求，例如开放世界、联机、背包、技能树、剧情系统同时要求。

更合理的方式是先做一个小闭环，确认整条链路能跑通：

  • 能生成项目。
  • 能编译。
  • 能启动 Godot。
  • 能截图。
  • 能根据问题继续修。

适合的第一批任务示例包括：

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

或：

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

这说明 Godogen 并不是“魔法式一句话直接产出成熟大作”的工具，它仍然要求用户理解基本环境、能看报错、能接受命令行，并知道“源仓库”和“生成项目”不是一回事。

适用人群

根据原文，Godogen 比较适合三类人：

  • 想用 Codex 做可运行互动作品的 AI 创作者。
  • 想快速验证玩法原型的独立开发者。