五一假期比较闲。2026年的AI编码已经非常成熟了，上次尝试游戏开发还是去年年初尝试unity，距今已经很久了。我开始思考在AI coding盛行的年代，游戏开发是否也大幅提效了呢。于是我开始寻找搜索使用codex进行游戏开发的人是怎么做的。

在了解了一些信息以后，我尝试用codex + godot快速撸了个游戏原型。大概花了12小时，AI的确大幅提升了人的效率。我想在没有AI的年代，快速撸一个这样的demo可能需要一个月乃至数个月。

Godot is better

关于Unity，2026年3月31日Unity国际版停止向大陆地区服务。国区特供版Unity一言难尽，不赘述了。而2026年的Godot已经是一个相当出色的游戏开发引擎了。对于个人开发者来说，它很轻量，并且比Unity和UE更加ai friendly，除了不好找工作没有什么其他缺点。

我先花3-4小时过了一遍Godot的官方文档的Quick Start，GDScript是一个类Python的脚本语言，上手起来很快。

Godot很轻量，启动和调试都非常快，一秒就可以启动游戏。这让我后悔没有早点使用Godot，我实际上并不需要unity那些很重的功能。

然后就是接入godot-mcp(https://github.com/Coding-Solo/godot-mcp)，可以让codex方便一点操纵godot去debug去看ouput。

此外，Godot场景文件也是文本化的，很适合AI操控。

游戏循环

这次我选择的游戏主题是在末日开餐厅，白天的战斗循环是打怪->收集物品->打怪->…->结束，夜晚的做菜循环是拿某种物品 -> 放置在某种操作台上 -> 拿 -> 放置 -> … -> 结束。当然还有一个大循环，让白天和黑夜交替，直到结束。

我和Codex讨论了我的想法，让它给我出了一个策划案。这里参考Anthropic的《Building a C compiler with a team of parallel Claudes》，那篇有争议的文章，让codex把任务拆分成16个step，写入progress.txt.每个会话处理一个step并且标记完成。我让Codex自己写了个脚本去循环创建新会话，每次的Prompt就是“处理下一个任务”。每隔三步要求它开一个review会话。

这样很快速地出了一个没有美术素材的原型。

素材替换

然后就是要求codex帮我生成一份需要替换的美术资源list，然后要求codex spawn subagent（为了并行快一点）去批量imagege然后替换图片素材。这个过程需要人的干预，很容易美术风格无法统一。

必须显式告诉它用imagegen，它很容易偷懒用代码画简陋的图。

关于音乐，我用suno生成了一些BGM，生成音乐的prompt也可以让Codex帮你写一批。

这里需要用英文提示词，我一开始用中文提示词出来的音乐都是古风的，虽然我prompt里没有半点和古风相关的要求，我百思不得其解，后来猜测是提示词语言问题，翻译成英文果然风格正常了。

与codex对话去微调

做到这一步以后就很难自动化了，需要不断测试再下指令微调。

我想第一是Codex目前还不能帮我顺利地完成端到端的测试，游戏战斗实时性很高，模型thinking很慢，模型也很难去尝试一些离经叛道的玩法。第二是模型对文本敏感度高，对图片敏感度低，它对于UI对不齐这种问题不是很敏感，对于违反操作直觉的UI设计以及关卡设计它完全看不出问题。第三游戏这种创作本身是带有强烈个人风格的东西，它属于创作，没有标准答案。

写一个C编译器是有标准的，可以编译过某些项目。性能足够好，很适合去奖励去RL。但是成熟的游戏很难有一个固定的奖励机制告诉模型什么是好。（虽然Anthropic的Harness design for long-running application development 中认为也有一些因素是可以打分量化的）

其次即使是GPT-Image-2，AI出图的风格也不是很稳定，多张图的风格没办法完全一致。即使我给了很多提示以及要求它参考已有风格。我想之后比较合适的工作流程是我先给个草图->AI细化->我再去PS统一风格。

关于token消耗，我日常编程是开了个codex 100刀的套餐，最近奥特曼给了双倍额度。但是在本次开发的不断对话过程中我发现xhigh + fast很快顶不住了，然后我切到了mid + fast，后来发现额度还是不够，只能关闭fast用mid跑。

信心

我想最大的好处是它给了我信心，AI给独立游戏开发带来了令我震撼的效率提升。

这让我相信即使我的业余时间很少，我也能在几个月内上架一款游戏。让我来试试吧。

2026/05/06