开发日志 06｜走向交付：我们留下了什么，又还欠什么

修改于4 小时前5 浏览综合包含 AI 合成内容

《神的沙盘》21 天创作挑战开发日志 · 第 6 篇阶段回望：依据截至 2026 年 10 月 18 日的开发材料整理。本篇记录第一版交付的范围冻结决定；提交与审核结果仍以实际凭证为准。

写到系列最后一篇，我们终于能说清一件事：第一版交付什么、不交付什么。

这个区别不只是措辞。开发中最容易混淆的几件事，恰好是写完代码、构建成功、测试通过、玩家看懂，以及正式交付。而这一次，我们第一次被迫把“不交付”也写进日志——因为有一个花了大量时间的模块，最终没能进入第一版。

因此，这篇既记录已经留下的成果，也如实写下两件让我们不太舒服的事：一个被误判拖住的模式，和一次代价远超预期的技术选择。

咕咕的前瞻与调研打开了主题，少川的持续策划与原型让项目有了骨架。起星的提案带来了观察推演与补给方式的比较，预言家的动物交互材料把需求、搬种与接口依赖具体化。队长兼任集成、卡牌经济与操作 UI，也把合作问题落实到状态与交付边界。

这些贡献可以按已有材料介绍，具体代码、资产与投入仍应逐项核对，不能由一张五人职责表推断全部成员已经完成分工。

游戏真正留下的主线，是有限干预、环境回应、发现与补牌，以及带着遗产继续旅程。土地声音和提取不是另一款游戏，星球也不只是好看的标题装饰，它们都需要回到这条主线接受检查。

我们不把卡牌、模块或构建次数当作完成度百分比。回到最初的承诺，至少需要核对下面六件事：

这个表不是六项全通过的证明。它让我们知道，收尾应该补的是哪一种证据，而不是继续增加哪一种功能。

第一版交付里，没有「咕咕模式」。

这不是因为它的想法不好。恰恰相反，从最开始，咕咕就提出了这个项目里最有辨识度的一支方向：不做卡牌施法，而是随时拖动、查看、维护、升级的一颗地球——玩家不是去点“完成生态链”，而是看着一颗星球自己长出秩序。它和主题“涌现”是最贴的。

它最终没进第一版，是我们自己的判断失误，链条大致是这样：

环节	发生了什么
起点	咕咕模式最初被当成卡牌主线的延伸去做，而不是独立玩法
第一次误判	把“用卡牌改造养护”当成可行路径，投入了一轮实现
第二次误判	发现方向不对后，又把它改成独立养护模式，等于推翻重来
第三次误判	为了让它“像主界面”，反复调整大陆表现与配色，来回返工数轮
结果	到范围冻结时，它仍然只到“能跑通基本循环”，达不到可交付的完成度

真正的问题不在某一轮改错，而在于我们没有及早承认它是一个独立玩法。如果一开始就把它当作独立模式立项，它需要的是一套自己的交互、自己的存档、自己的验收标准——而不是挂在卡牌主线下面反复改。把它当成支线，就一直在用支线的预算做主线量级的东西，最后两头都不够。

现在的状态是：它的核心循环已经跑通（球面观察、拖动、补水、地形抬升、多大陆生态、独立存档），但没有经过首次玩家验证，也没有达到“第一版可以让玩家安心上手”的程度。所以第一版交付不带它。

我们把它保留在仓库里，不是删掉，而是明确标注为未交付的支线。它值一个独立的立项决定，而不是在一次范围冻结里被匆忙塞进去。

10 月 7 日的记录里，一个卡牌拖拽模块已经写进项目，却没有登记到资源清单里，运行时出现模块找不到。

它提醒我们：本地文件存在和发行包可以加载，是两次不同的确认。新增模块、动态引用与默认入口，都要在真正构建后的路径里验收，不能只检查源码目录。

10 月 10 日，干旱计数未入档的问题被修复；10 月 11 日，区域持续效果也补充到了存档中。

这两类状态不一定直接显示在画面上，却会决定读档后的湿度、生长和衰退。漏掉它们，就可能让“何时保存”改变世界接下来的命运。

修复的意义，是让恢复更接近原世界继续运行，不只是读回几棵树。但历史修复通过，也不能替代最终版本的完整保存回归。

新增机制会改变旧测试的前提。湿度衰减变了、卡牌数量增加了，原先写死的断言就可能失效。这类红灯需要更新测试，不是关闭机制让它重新变绿。

另一些失败依赖前序状态，隔离用例又不能复现。10 月 11 日的记录中就保留了待定位问题：既不能确认是回归，也不能排除。

我们需要的是分类、复现和解释，而不是把所有失败都称为旧测试，或者把所有历史通过都累加成当前全绿。报告也应标清版本、配置与权威批次。

这是本次开发里最贵的一个教训，也是最该被记住的。

项目早期，我们把大量精力投入到一个自研的通用 Lua 游戏框架（仓库里的 gf/）上——它有自己的一整套目录、测试与工具链。它一度看起来很像“正经工程该有的样子”：模块化、有测试、有规范。

但它和这个游戏的真实关系是：《神的沙盘》运行时几乎不用它。游戏实际依赖的是引擎自带的 urhox-libs，而 gf/ 是被蒸馏出来、又移出去的通用框架。我们为它写了大量代码与测试，却基本没有变成玩家能看到的体验。

代价不只是那部分代码本身。更贵的是它带来的连锁反应：

连锁反应	后果
目录与概念变多	每次改动都要先分清“这是游戏代码还是框架代码”
上下文变长	后续每一轮对话都要先理解这套自建结构，成本被反复放大
返工变多	咕咕模式等支线又在上面叠加，进一步加深了耦合与重来