5.5 打包发布与上线复盘：全书方法论的一次真演练

核心结论

发布不是"最后一周的冲刺"，而是全书所有纪律的总验收：时间盒（0101）决定你何时停手、架构（0102）决定你打包稳不稳、数据表（04 章）让你能热更新、性能账本（0504）决定你不会被差评淹没。这一篇把发布流程串起来，并附上我上线三个月后的复盘。

发布四周倒计时

最重要的纪律：T-4 周功能冻结之后，任何新功能都问"能不能放到第一个更新里"。90% 的答案是"能"。

Steam 上架清单（PC 独立项目）

预告片的铁律：前 5 秒放最爽的瞬间。玩家刷页的平均停留时间就是这 5 秒。

上线 90 天复盘（真实数字脱敏）

一个反直觉的结论：上线后最救命的系统是数据表驱动（04 章）与镜头反馈选项（0304），不是任何"高技术"功能。维护期的需求是"改得动"。

我会改的三件事（给新人的诚实建议）

1. 更早做试玩 demo：拖到 T-1 周的 demo 吸来了最多反馈，但也最来不及改。M2 就该有可玩 demo。
2. 崩溃上报再早一个月：内部测试期就上崩溃收集（0503 的机制），上线第一天就有参照系。
3. 砍功能时更冷酷：发布前 3 个被砍的系统，事后没有一个玩家提到。你担心的"缺功能"，玩家根本没注意。

与全系列的收束

这本书的原点是"独立项目让多系统协作"，终点是"把游戏交到玩家手里"。全书的所有方法论——时间盒、分层、Tag/事件、数据表、对象池、复制分层、预算账本——都在最后这五篇文章里跑了一遍：

• 分层与事件让联机只动了 L4 一层。
• 数据表让两周一个 BOSS。
• 预算账本让 EA 评价里没有人说"掉帧"。
• 反馈层让差评第一条当晚就能修。

心得：独立项目上线那天没有什么激动人心的瞬间——只有疲惫的早晨、一杯咖啡和"居然真的发了"的恍惚。真正的激动在 90 天后：看玩家在玩你的系统、看数据表改一行就有新内容、看你写下的纪律真的陪你走完了全程。这本书如果只记住一句话：把纪律当系统，把系统当工具，把工具交给自己。