最近在用 Cocos Creator 做一款竖屏小游戏《僵尸攻城》，把这次的制作过程整理一下，给同样想用 AI 做游戏的朋友参考。
先放目前的效果。角色页、关卡页、核心页已经搭起来了，可以切换背包页签、改选初始核心。真实战斗和完整的养成流程还在后续开发范围里。
目前的角色页、关卡页和核心页，均截自实际预览录屏。交互过程放在后面的动图里。
这次的分工是：前期用 Codex 制作和整理素材，写游戏设计、数值设计以及实施文档，再让 Game Agent 在 Creator 里完成场景、Prefab 和交互。我负责定需求、审方案、看效果。下面主要聊这几个环节怎么衔接。
先把素材准备到能直接用
做第一版，可以找一个玩法和界面结构比较明确的游戏作参考，再围绕它做主题换皮。角色放哪里、页面有哪些入口、战斗画面需要哪些层，都有参照，前期会省下不少反复试布局的时间。
接着让 Codex 按这个方向制作、处理和整理素材。这里有个很实际的问题：一张完整效果图好看，不代表它能直接拿来搭游戏。
背景、角色、按钮、装备槽、图标、选中态，要拆成能独立使用的资源。需要变化的文字和数字，后面交给 Label；按钮和面板再按布局组装。否则整张图铺上去，改一个金币数都得重新处理图片。
我在项目里单独留了 doc/资产说明。除了文件清单，还要写清楚每份素材用在哪、尺寸和锚点是什么、动画怎么播。这些资料会直接影响后面 Game Agent 搭场景的结果。
比如这次的敌人帧动画，播放顺序由动画表指定，不能简单按文件名排序；Spine 的 .skel、.atlas 和贴图要成套使用，图集引用也要对应。大厅角色与战斗角色各有自己的资源，不能看着长得像就混着用。
分包也在这一步整理。公共 UI、大厅、战斗角色、特效、各关地图分开，后面按页面和关卡加载。loadBundle 拿到包之后，再加载实际需要的资源，别在启动时把所有目录都 loadDir 一遍。
项目里的素材分包目录。大厅、战斗角色、特效、地图和公共 UI 各有自己的位置。
设计文档要把规则写清楚，数值要能算
《僵尸攻城》的战斗设计是：僵尸按波次进攻城门，玩家用步枪和核心技能防守，局内通过选卡强化，局外再做装备、宝石和研究成长。只把这些概念告诉 AI，离能写程序还差很多细节。
拿选卡来说：还没学会某个核心技能，能不能抽到它的强化卡？学习卡和强化卡怎么区分？局外研究解锁了一个词条，局内什么情况下才能出现？这些条件要写进规则，不能等抽卡代码写完了再补。
数值也是一样。最初列技能时，写几个“伤害 +60%”“额外发射一次”很容易；真正要做的是把它们放到同一套计算规则里。
这次我把普通增伤放在同一个加算池，独立倍率另算。举个简化的算例：同一伤害分量同时吃到两条普通增伤，分别是 30% 和 60%，那么这一段就是：
100 × (1 + 0.30 + 0.60) = 190
暴击、易伤、抗性等，再按各自的规则往下算。同一个宝石效果如果同时被“技能来源”和“元素”两个标签匹配到，只能算一次；两颗不同宝石各提供的效果，则都要保留。这个区别不提前写清楚，后面很容易重复加成，或者把本该生效的属性去掉。
我把说明文档和 JSON 数值表一起交给 Codex，并要求配独立算例。修改某条规则时，相关的技能、成长、经济和验收说明也要一起检查，避免文字改了，数据还在用旧版本。
设计文档和数值表放在一起。伤害规则、算例、技能、敌人、波次、经济分别维护，修改时可以互相对照。
这些检查能先排掉前后矛盾和计算错误，实际好不好玩，还是要等战斗接起来以后试玩调数值。
把设计拆成 Game Agent 能执行的任务
设计文档之后，我还会补一层实施文档。主要写这次做哪些页面、复用哪些素材和组件、业务状态由谁维护，以及做完怎么检查。
项目的脚本按职责分了四层：
framework 资源、音频、对象池等通用能力
game 游戏规则、计算和业务状态
view 界面展示与输入
app 启动和各模块装配
比如一个强化按钮，界面负责收集操作和显示结果，强化成本、属性变化、保存由业务层处理。按钮脚本里直接减金币、改攻击力，短期看着省事，后面别的页面也要用这套规则时，就很难保证一致。
UI 则尽量拆成独立 Prefab。整页、弹框、可复用卡片分别管理，已有的装备槽和核心卡继续复用。给 Game Agent 的任务里，要明确要求它阅读现有结构和资产说明，沿用项目里的模块，不要每接一个新功能就另写一套。
脚本按职责分层；核心卡、装备槽、背包页签和材料条目等界面元素，分别做成可复用的 Prefab。
这次我是先用 OpenSpec 把范围、设计和任务清单写下来，审核后再实施。工具可以换，但实施前把范围说清楚这件事很有用。尤其要写明这轮做到哪里：当前先做局外界面和交互，真实战斗后续再接，不能因为有了“开始游戏”按钮，就算战斗完成了。
一次做完一条能检查的交互
第一步先把角色、战斗、核心三页首屏和导航接起来，然后再补具体功能。这样每一轮都能进 Creator 看结果，也容易发现素材错用、布局遮挡、页面状态不同步这些问题。
背包页签切换，原速节选。空列表和材料列表各自显示对应内容。
初始核心改选就是一个小例子。点击一张卡，除了移动选中标记，还要保存选择、更新核心页的状态说明，并同步关卡页显示的初始核心。重新打开预览后，也应该保留刚才的选择。
改选初始核心，原速节选。这段展示卡片选中态和当前核心说明的变化；切页、重载另做检查。
这条流程里，我要求保存确认后再更新界面；保存失败时保留旧选择。检查时把“点选、切页、重载”走完，才能知道显示和存档是否一致。只看按钮有反馈，检查不到后面的这些问题。
Game Agent 在这一步会直接接触 Creator 里的节点、组件、资源和预览。下面是实际工作时的一段录屏，可以看到它读取项目、检查组件和控制台。
插件工作过程，原速节选；画面保留了当时的控制台报错。
开发过程中也会遇到脚本加载、组件登记、预览打不开等问题。代码检查通过、编辑器里的组件恢复、预览能正常操作，是几件需要分别确认的事。让 AI 读错误、查节点、记录当前结果，比只让它反复“再修一下”更容易判断卡在哪一步。
视觉验收也一样。参考图可以帮助确定布局，实际还是要看按钮能不能点、文字是否清楚、手机上有没有遮挡，切页后状态对不对。不能为了贴合一张静态效果图，把真实数据或正常动画改掉。
目前这套做法里，前期交给 Game Agent 的材料越具体，后面越容易检查：素材有用途，规则有数据，实施有范围，每个小功能都有明确的操作步骤。需要人拿主意的地方也很清楚——哪些玩法值得做、第一版做到多大、当前效果能不能接受。
这次用到的 Game Agent，官网有使用文档和其他演示，有兴趣可以看看：