第一个完整可玩版本

上一篇：为什么做完战斗还不算完成游戏

前五篇分别讨论了想法、协作、战斗规则、画面表现和局外流程。到了这一篇，不再增加新的系统，而是把已经完成的部分按照玩家真正经历的顺序重新走一遍。

从打开游戏开始，经过加载、选择阵营、进入 Home、准备战斗、产生胜负、领取奖励、升级能力，再回到下一关入口。这条路径如果能够连续成立，并且关闭游戏后仍能从正确位置继续，《Kibble Street TD》才拥有了第一个完整可玩版本。

“完整可玩”不是页面全部能够打开

一个项目里有首页、商店、升级和战斗页面，不代表它已经完整。页面只是入口，真正需要检查的是玩家的行动有没有前因后果。

对《Kibble Street TD》来说，“完整可玩”至少包含四件事：能够从没有存档的状态正常启动；玩家能够做出会被长期保留的选择；一场战斗的结果能够改变资源和进度；再次打开时，游戏能够恢复到与这些结果一致的状态。

这四件事缺少任何一项，体验都会断开。只能进入战场，是战斗原型；只能在页面间跳转，是界面原型；能够胜利但奖励不会进入下一场，则是一段没有后果的演示。

第一次打开，先建立玩家自己的起点

新玩家看到的是加载画面和阵营选择。此时游戏还没有默认替玩家决定猫或狗，也不会把选择只停留在按钮效果上。阵营确认后，选择与初始状态一起保存，随后才准备对应阵营的 Home。

新存档从第一关开始，KIBBLE 和 CANS 都是零；八种已启用的战斗道具各获得一件，让玩家可以在第一场战斗前体验准备环节，但不会提前获得可直接购买升级的货币。

进入 Home 后，玩家看到自己的阵营、资源、单位和 Stage 1 入口。只有入场动画结束并解除输入限制后，这个页面才算真正可操作。画面已经显示出来，与玩家已经能够安全点击，是两个不同的完成条件。

第一场战斗把前五篇内容接到了一起

点击 GO 后，玩家先进入战前准备，决定本场携带哪些道具；开始战斗后，通过持续恢复的能量召唤不同职责的单位。单位移动、寻找目标、攻击建筑，直到一方基地被摧毁。

这条路径看起来只是一组连续画面，背后却同时用到了前五篇已经讲过的全部内容：最初的猫狗对抗构想决定了题材；战斗规则决定谁能攻击谁；表现层把状态翻译成角色、动画和反馈；页面流程负责把玩家送进战场；存档则负责接住战斗结束后的变化。

胜负出现后，游戏先记录本场道具消耗，再处理关卡进度、KIBBLE 和适用的宝箱奖励，保存变化后才显示结果面板。CANS 来自宝箱奖励，并不是每场胜利都会固定发放的货币。玩家看到 VICTORY 时，结果已经不只是一段动画，而是能够被 Home 和升级页继续读取的新状态。

奖励只有进入下一次决定，才完成闭环

第一关胜利后，玩家可以继续下一关，也可以返回 Home。返回后，下一场入口变为后续关卡；刚刚获得的 KIBBLE 可以在余额满足条件时用于购买升级，转换成建筑、单位、能量或奖励能力的长期变化。

这一步让第一场战斗拥有了后果。玩家不是回到完全相同的起点，而是带着新的资源和进度再次做决定。升级后的等级会被保存，并参与之后的战斗配置；下一场胜负又会继续产生资源、推进关卡或促使玩家重新准备。

因此，完整闭环不是“Home—战斗—Home”三个页面首尾相接，而是前一次结果确实改变了后一次选择。

完整版本必须容纳分支，而不是只演示一条顺利路线

真正的玩家不会都走同一条路径。有人第一次进入，有人带着存档回来；有人选择狗阵营，有人选择猫阵营；战斗可能胜利，也可能失败；结算后可能继续、返回或者重试。

这些分支不能各自维护一套彼此无关的状态。胜利要推进下一关，失败要按照本场实际进度结算；返回 Home 后必须读到刚才的资源变化；关闭后重开不能重复赠送初始道具，也不能要求已经选过阵营的玩家重新选择。

只录制一条从开始到胜利的顺利路线，可以证明“曾经跑通过”；把新玩家、回流、两种阵营、胜负和返回选择交叉检查，才能证明它不是为演示临时拼出的单一路径。

能在编辑器里运行，还要能离开编辑器

编辑器预览适合快速修改和检查画面，但玩家最终接触的是构建后的应用。截至 2026 年 8 月 2 日的开发记录中，《Kibble Street TD》已经跑通过从游戏工程生成 iOS 工程、完成归档并导出应用包的链路。这证明游戏能够带着脚本、配置和资源离开开发环境。

不过，构建成功、完整可玩和准备发布仍然是三个不同结论。一次已经生成的安装包只能证明当时那份内容完成了构建；之后任何代码、配置或资源变化，都需要重新检查并重新构建，不能沿用旧产物替最新版本背书。

2026 年 8 月 2 日整理前六篇记录时，部分自动检查仍会因为资源格式和后续规则变化不同步而中断。因此，当时的记录只支持两个结论：完整游玩闭环已经成立，iOS 构建链路曾经跑通。它们不代表当前版本已经完成全部发布验收，也不代表 iOS 已经上架。当前商店状态见本文顶部的上线更新。

第一个版本是一条基线，不是项目终点

本系列前六篇从一句“猫和狗在街区对抗”的想法开始，到能够启动、选择、战斗、结算、成长和继续的版本结束。六篇内容合在一起，得到的不是六个孤立功能，而是一条可以反复运行、检查和继续修改的产品基线。

这条基线的价值，不只是终于有了可以展示的画面。它让后续改动有了明确参照：重做 UI 时不能破坏页面流程，替换动画时不能改写战斗状态，调整数值时必须重新验证完整循环，接入平台能力时也不能阻断已有体验。

完整可玩之后，项目仍然会经历大量返工。界面是否统一、资源是否适合真实屏幕、动画是否稳定、数值是否耐玩，这些都不是前六篇重点解决的问题，而是下一阶段真正开始的地方。

这个环节由谁负责

人负责定义“什么才算一个完整版本”，决定哪些路径必须成立，以及可玩、可构建和可发布之间的边界。

AI 负责沿着真实流程检查状态交接，整理多条测试路径，核对代码、配置、截图和构建产物是否支持同一个结论，并在证据不足时缩小表述范围。

引擎负责运行场景、加载资源和生成目标平台工程，但它不会自动证明游戏流程完整，也不会替开发者判断一次旧构建能否代表最新版本。

如果你想开始

先不要用“做完多少页面”衡量第一个版本。写下一条玩家可以实际完成的最短路径：从无存档启动，做出第一次选择，进入核心玩法，产生结果，把结果保存，再用这个结果做下一次决定。

然后为这条主线增加最少但必要的分支：再次启动、失败、重试、返回以及另一种核心选择。每条路径都要明确开始状态、玩家操作、状态变化和结束位置。

最后把三个结论分开记录：游戏流程是否完整、目标平台是否成功构建、当前候选是否完成发布验收。它们可以先后达成，但不能相互替代。