W
AI-Wiki

AI · 源文件

入库前的原始上传文件存档。点击左侧文件名可预览文件内容。

Godogen 这个神器,让普通人也能开始做 Godot 游戏.md9.5 KBit/ai/Godogen 这个神器,让普通人也能开始做 Godot 游戏.md
---
title: "Godogen 这个神器,让普通人也能开始做 Godot 游戏"
source_url: "https://mp.weixin.qq.com/s/G3JCU8CPRSuPG7T4jv2gGw"
source_site: "mp.weixin.qq.com"
clipped_at: "2026-07-06T10:48:47.102401+00:00"
clipper: "aiwiki-url-ingest"
extractor: "weixin_static"
source_strategy: "normal_web_clip"
source_strategy_label: "普通网页抓取"
author: "数字生命刘同学"
---

# Godogen 这个神器,让普通人也能开始做 Godot 游戏

最近看了一个挺有意思的开源项目,叫 Godogen。

一句话讲,它不是一个游戏项目,而是一个「游戏项目生成器」。

你先用 Godogen 生成一个新的 Godot 项目,然后在这个新项目里让 Codex 接管开发。Codex 会根据自然语言描述,规划游戏、写代码、生成项目结构、运行 Godot、截图检查,再继续修问题。

也就是说,它想解决的不是「让 AI 写一段游戏代码」,而是「让 AI 跑完一套游戏开发流水线」。

这点很关键。

因为游戏开发最麻烦的地方,从来不只是写代码。

你要有项目结构,要有场景树,要有输入系统,要有 UI,要有角色、敌人、关卡、胜负条件,还要能真的跑起来。

更麻烦的是,有时候代码能编译,但画面是错的。

角色没显示。

镜头位置不对。

UI 挡住画面。

敌人生成在奇怪的位置。

所以 Godogen 的核心价值,是把 Codex 从一个写代码助手,往「能根据运行结果继续修项目的开发搭子」推了一步。

如果你只看 Godot \+ Codex,流程其实很清楚。

你不要直接在 Godogen 源仓库里做游戏。

这个仓库是源码库,用来发布运行时项目。

正确流程是这样。

- 

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

```

```
执行完以后,它会生成一个新的游戏目录。

- 

```
~/my-godot-game
```

```

```
里面大概会有这些东西。

- 
- 
- 
- 
- 

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

```

```
这些才是 Codex 真正会用到的东西。

然后进入新项目。

- 

```
cd ~/my-godot-game
```

```

```
打开 Codex,输入。

- 

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

```

```
这时候 Codex 会读取 `.agents/skills/` 里的技能说明,按 Godot 项目的方式开始生成游戏。

Godot \+ Codex 这条线,安装重点有几个。

Godot 必须用 .NET 版。

普通 Godot 不行,因为这个仓库的 Godot 输出是 C\# 项目。

你需要确认。

- 

```
godot --version dotnet --version
```

```

```
`dotnet` 建议是 9\.x。

Godot 需要能无头启动。

- 

```
godot --headless --quit
```

```

```
如果这里报 C\# assembly 相关错误,大概率是 Godot .NET 安装不完整,或者 `GodotSharp/` 没有和 Godot 可执行文件放在一起。

另外,`publish.sh` 是 Bash 脚本,会用到 `python3`、`rsync`、`chmod` 这些东西。

所以 Windows 用户建议直接用 WSL。

别硬在 PowerShell 里折腾。

最短安装路径大概是这样。

- 

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

```

```
确认没问题后,在 Godogen 源仓库里执行。

关键

- 

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

```

```
再进入生成的新项目。

- 

```
cd ~/my-godot-game
```

```

```
然后用 Codex。

- 

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

```

```
第一次测试不要写太复杂。

不要一上来就开放世界、联机、背包、技能树、剧情系统全都要。

先做一个小闭环。

比如:

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

```
做一个 2D 横版跳跃游戏,有三枚金币、一个敌人、一个终点门
```
先确认这条流水线能跑通。

能生成项目。

能编译。

能启动 Godot。

能截图。

能根据问题继续修。

这比一开始追求大而全重要得多。

具体可以怎么用,我觉得有三个场景比较典型。

场景一,独立开发者的周末原型。

很多独立开发者平时都有一堆玩法想法,但真正动手的时候,成本很高。

比如你突然想到一个点子,做一个俯视角地牢射击游戏,玩家每清完一个房间就能三选一升级,敌人一波比一波强。

如果从零开始,你要建 Godot 项目,要搭输入,要写角色控制,要做敌人 AI,要做 UI,要做战斗结算。

一个周末可能光搭架子就过去了。

用 Godogen \+ Codex 的价值,是先让它生成一个能跑的小闭环。

- 

```
$godogen 做一个俯视角地牢射击原型,玩家 WASD 移动,鼠标瞄准射击,每个房间生成 5 个敌人,清完后出现三选一升级,完成 3 个房间后胜利
```

```

```
你不一定指望它一次做成最终版本。

但只要它能把玩家移动、敌人、房间、升级、胜利条件这些核心逻辑先跑起来,这个原型就已经有价值了。

独立开发最怕的不是想法不够。

是想法永远停在脑子里。

场景二,教育机构的编程教学。

如果你是教编程、教游戏开发、教 AI 应用的机构,Godogen 这种项目其实很适合做课堂演示。

以前教学生做游戏,老师需要提前准备大量模板。

学生一上来还没理解游戏逻辑,就先被工程配置、资源路径、脚本挂载这些东西劝退了。

Godot 本身已经算友好了,但对纯新手来说,还是有门槛。

Godogen \+ Codex 可以把课堂重点往前推一点。

比如老师可以让学生先用自然语言描述一个小游戏。

- 

```
$godogen 做一个接金币小游戏,玩家左右移动接金币,接到加分,漏掉扣生命,生命为 0 游戏结束
```

```

```
然后让学生观察 Codex 生成了哪些脚本,Godot 场景是怎么组织的,输入是怎么接的,UI 是怎么刷新的。

这样学生不是只看 PPT。

而是看到一个从需求到项目的完整过程。

更关键的是,老师可以反过来讲代码。

为什么玩家移动要放在 Player 脚本里。

为什么分数和生命需要一个状态管理。

为什么 UI 不应该和游戏逻辑绑死。

这比直接讲抽象概念更容易懂。

场景三,游戏策划的快速验证。

很多游戏策划的问题,不是不会想玩法,而是想法很难被快速验证。

一个机制听起来很有趣,但真正玩起来可能很无聊。

一个数值设计看起来合理,但放到场景里可能节奏很怪。

一个战斗规则在文档里写了 5 页,但程序还没排期,没人知道它到底好不好玩。

Godogen \+ Codex 可以先做低保真验证。

比如策划想验证一个简单机制。

- 

```
$godogen 做一个 2D 生存小游戏,玩家不能攻击,只能移动躲避敌人,每 10 秒随机获得一个被动能力,存活 60 秒胜利
```

```

```
这个 Demo 不需要美术精致。

也不需要系统完整。

它只需要回答一个问题。

这个核心循环有没有意思?

如果 5 分钟玩下来就觉得无聊,那这个方案可以早点改。

如果原型里已经能感受到一点爽感,再进入正式开发就更有底气。

对策划来说,这种工具最大的价值不是替代程序。

而是把很多「纸面争论」变成「跑起来看看」。

这个项目适合三类人。

一类是 AI 创作者,想用 Codex 做一个能跑的互动作品。

一类是独立开发者,想快速验证一个玩法原型。

一类是游戏策划,想把想法先变成 Demo,而不是等程序排期。

但它不适合完全不想碰环境的人。

因为 Godot \+ .NET \+ Codex \+ Bash 这一套,还是有门槛。

你至少要能接受命令行,能看报错,能装 SDK,能理解源仓库和生成项目不是一回事。

我觉得 Godogen 最值得关注的点,不是「一句话生成游戏」这个标题。

这个说法太容易让人误会。

真正值得关注的是,它把游戏开发拆成了一套 Agent 能执行的流程。

自然语言需求。

项目发布。

技能加载。

代码生成。

引擎运行。

截图检查。

问题修复。

这才是它和普通 AI 写代码最大的区别。

普通 AI 写代码,经常停在「我觉得我写好了」。

Godogen 试图往前走一步,让 AI 去看运行结果。

游戏开发里,这一步非常重要。

因为玩家不关心代码看起来优不优雅。

玩家只关心画面里那个角色能不能动,按钮能不能点,敌人是不是正常出现。

所以如果你想试 Godot \+ Codex,我建议按这个顺序来。

准备环境。

- 

```
python3 rsync Godot 4 .NET .NET 9 SDK Codex
```

```

```
发布项目。

- 

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

```

```
进入项目。

- 

```
cd ~/my-godot-game
```

```

```
让 Codex 开始。

- 

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

```

```
如果能跑通,再慢慢加需求。

这东西不是魔法。

但它是一个很实在的方向。

以前你跟 AI 说做游戏,更多是在赌模型一次性写对。

现在这类项目开始把重点放到流程上。

让 AI 不只是生成,而是运行、观察、修正。

这才是真正接近生产的地方。

![](https://mmbiz.qpic.cn/mmbiz_png/ER9cbEcnBFpe3cIe0uYkzAsgMicdSgl8eicMcKq9ePsib0gFdyGTEnxErLAIUeNckWqKS3RmJEhhxkCKXfvd6F74eoa1IAiazdG8SC1q7JnNEKw/640?wx_fmt=png&from=appmsg) 
/ 作者,刘同学