沙盒 / 开放世界
🏦 场景与客户
一个做过几款小体量作品的工作室，立项一款沙盒生存建造游戏，目标平台 PC 抢先体验，后续移植主机。团队十五人左右，程序 5 人，美术 6 人。
项目原型跑得很顺，问题出在世界大了之后。玩家跑出初始区域，画面会卡顿一下；拆过的房子、挖过的地形、造过的建筑，重新回到该区域时有时会「复原」；更糟的是崩溃之后存档损坏，几十小时的存档直接作废。团队原来的存档是整份世界一次性写出，世界越大写得越慢，越容易在写的过程中崩掉。
📅 实施节奏
- 第 1–3 周：把世界按区块切分，定义每块的加载、卸载与持久化边界
- 第 4–6 周：改造成流式加载，玩家移动时后台预取前方区块，卸载远离的区块
- 第 7–9 周：存档改为增量记录——只写玩家改动过的部分，未改动区块按种子重建
- 第 10 周起：加入崩溃恢复与存档版本迁移，老存档在新版本能继续打开
🗝️ 方案要点
- 种子 + 改动：地形由种子确定生成，存档只记玩家改了什么。存档体积与世界大小基本脱钩
- 区块状态机：未加载、已加载、已修改、待卸载四态明确，避免同一块被两处同时写
- 原子写入：先写临时文件再整体替换，中途断电不会留下半截存档
- 版本迁移：存档带版本号，格式升级时走迁移脚本，不做「不兼容请重开」这种处理
⚖️ 选型与权衡
| 选择点 | 方案 | 权衡 |
|---|---|---|
| 世界持久化 | 种子 + 增量改动 | 存档小、加载快；代价是生成算法一旦改动，老存档的地形会跟着变，必须冻结生成逻辑 |
| 加载策略 | 流式预取 | 跑起来不卡；代价是内存占用上升，低配机器要放宽预取距离，画面边界更容易被看见 |
| 存档时机 | 定时 + 关键事件双触发 | 丢档风险低；代价是频繁写盘会造成帧率抖动，需要放在后台线程并做节流 |
| 多人同世界 | 主机权威 | 实现简单；代价是主机掉线全房受影响，且主机作弊难以约束 |
🚧 实施难点与排查
- 回到旧区域建筑消失：区块卸载时改动没落盘就被丢弃。改为卸载前强制持久化，并加一条校验
- 存档写着写着就崩：整份世界写入耗时过长，期间内存峰值过高。改增量后写入时间大幅缩短
- 同一区块被写两次：加载与流式预取有重叠区。靠区块状态机加锁后解决
- 版本升级后老存档打不开：早期没留版本号。补上版本字段并写迁移脚本，此后每次格式改动都必须带迁移
💵 成本与收益
- 成本：重构约 3 人 × 9 周；存档与加载不产生额外服务端费用
- 收益：存档从「几十小时不敢关」变成随时可退；因丢档导致的差评与退款明显减少
- 省钱的点：丢档类问题在抢先体验阶段杀伤力最大，一次大规模丢档足以毁掉口碑，前期投入划得来
🛡️ 风险与保障
- 存档安全：保留上一份可用存档作为回退点，新存档损坏可自动降级
- 防篡改：存档校验和防止被随意修改后引发不可预期的世界状态
- 性能下限：低配机器自动降低预取距离与区块精度，保证能玩
- 兼容承诺：明确存档在版本间的迁移策略，避免玩家因升级而弃坑
♾️ 可复用与演进
- 「区块切分 + 种子生成 + 增量存档」是所有大世界品类的地基，也可以用于关卡编辑器
- 演进方向：把改动记录做成可回放的编辑历史，支持世界回滚到任意时间点
- 再进一步：多人世界改为服务端权威，支持持久化公共服务器
