《公交公司》开发者日志6

修改于10/2224 浏览综合

《公交公司》开发者日志 06 · 上线冲刺：地图、排行榜、存档与教学收敛

这一篇记录上线前的最后一轮开发。做完这四件事，游戏就正式发布了。

游戏地址：https://www.taptap.cn/app/965953

这一期聊四件事：地图选择、排行榜、自动存档、教学优化。它们看起来是四个独立功能，其实都在解决同一个问题——让玩家能真正「开始玩」，并且玩得下去。

这四件事做完，《公交公司》才算是准备好上线了。

一、地图选择：先把「地图」这个概念从代码里拆出来

起因：一个按钮决定的命运

上线前的首页只有一个「开始游戏」按钮，点下去固定进入 18 站成长局。玩家不能选战场，也没法为不同拓扑的城市做准备。

但真正的问题在数据结构，而不是 UI：

「地图」在这款游戏里，当时根本不是一个独立概念。

站点表、边表、桥梁、初始开放站，全部硬编码在「模式」的分支里。growth/weekly 走 18 站扩展图，short/middle 走 12 站基础图，tutorial 走 6 站教学图。

也就是说：「换地图」等价于「换模式」。

想做「选地图」，必须先把地图从模式里拆出来。

拆法：让 mapId 成为独立参数

新建一张地图注册表，把站点和道路数据变成声明式定义：

Maps.DEFS.riverside = {

id = "riverside",

name = "滨江",

stations = { { name = "松林社区", kind = "home", x = 190, y = 250 }, … },

edges = { … },

bridges = { 8, 14 },

lineCount = 5,

}

然后让 mapId 沿着 mode/seed 的透传链一路走下去——建世界、重建、存档全部带上它。

这里有个必须说清楚的边界：这一期 mapId 只对成长局生效。教学、中局、短局、周历各自回到固定图。为什么？因为周历的事件表是写死站号的（「第 3 周开放 17、18 号站」），换一张站数不同的图，它会去取一个不存在的站点，运行中直接崩。

这个坑是加第二张图之后才暴露的：玩家在棋盘城用成长局玩，中途切「周历」模式，程序沿用 mapId="starter" 去建 16 站图，而周历剧本要开 17、18 号站 —— 取到 nil，崩。

修复只有一行：进世界时，非成长局强制把 mapId 清空，回默认图。

第二张图：棋盘城

有了选图功能，自然要有一张**「第一眼就懂」**的入门图。于是新增「棋盘城」：

4×4 规整方格，16 站，24 条边，无桥、无对角线；
从中心三站的 L 形向外一圈圈生长，每波新站必与已开站相邻；
开局极小：1 辆车、1 条线、3 个站（对比滨江的 4 车 / 3 线 / 5 站）。

原来的 18 站图降为「滨江 · 进阶」，保留双桥瓶颈、5 条线、3 种车型。

这里有个设计上的选择值得说：入门的「易」，不靠砍时长。

两张图的局长都是 600 模拟秒，都是每 40 秒开一个新站，成长弧线完全对齐。棋盘城的「易」来自：

开局极小（1 车 1 线，玩家不会被资源淹没）；
无桥（没有瓶颈，怎么改线都通，容错高）；
线路最多 4 条，不引入快速公交（只引入大容量）。

难度是靠机制的减法降下来的，不是靠稀客流或短时长。这样从入门图毕业到滨江，玩家面对的是同一套规则、更复杂的拓扑。

二、自动存档：为什么必须走云

一个把本地文件判了死刑的场景

需求很简单：刷新页面后还能接着玩。

但 Web（WASM）上，本地 File 写在内存文件系统里，页面一刷新就没了。而「刷新后还能继续」恰恰是核心场景——本地文件存档在这款游戏里没有意义。

所以存储走 clientCloud，按 TapTap 账号在服务端持久化。

存档最难的不是「存」，是「恢复后世界还得是活的」

朴素地逐表转 JSON 会复制对象、打断仿真。有三处对象同一性必须重建：

乘客：站台候车列表、车内货舱、世界乘客表，必须是同一张表；
服务：车指向的服务对象，必须就是服务注册表里的那一张；
道路队列：不存队列本身，加载时由车辆位置重建。

第 2 条踩过一次：服务表的键是 bus.service.id，不是 bus.lineId。两者在正常情况下相等，但换线失败的分支会把 lineId 写成 service.id，并不总是相等。存错键，读档后车就挂到了错误的服务上。

cjson 的两个陷阱

稀疏整数键：world.trips 在滤掉已送达乘客后会变得稀疏，而 cjson 对「键不连续的数字表」往返不可靠。一律序列化成记录数组，加载时重建键表。
math.huge：有些站点标记是「永不到来」，值是 math.huge，JSON 无法编码。读取侧本来就是「取不到就当无穷大」，所以编码前统一过滤掉非有限值即可。

只存「还在路上的人」

world.trips 只增不减（每个乘客一条，永不清），跑长局会撑爆存档体积。

裁剪依据是：已送达的乘客不再被任何逻辑读取。所以只存「候车 ∪ 在途」，体积收敛到「站点容量 + 车队容量」。

两个真实踩的坑

坑 1：把云判成不存在。

守卫最初写的是 if type(clientCloud) ~= "table" then return nil end。但 clientCloud 是引擎绑定对象，Lua 侧是 userdata 不是 table。于是明明有云，却被判成「没有云」，白回落到内存后端——表现就是「返回首页后没有继续游戏」。

正确的存在性判断只有一种：

if not clientCloud then ... end -- ✅

坑 2：一个跨场景存活的标志。

修完上面这个，返回首页仍然显示「开始游戏」。查下来是：点「开始游戏」时记录了一个「当时没存档」的探测标志，返回首页时正确渲染成「继续游戏」，但下一帧主循环看到那个陈旧标志，又把按钮打回了「开始游戏」。

教训：凡是「回调只写标志、由每帧 Update 消费」的模式，标志的生命周期必须和它所属的那块界面同生共死，否则跨场景会串味。

存档节奏

两条触发：真实秒计时器（12 秒）是主保证；有结构变更（改线、投车、开站）时提前落盘。

为什么不能只靠「有变更才存」？因为时钟推进、车辆移动、上下车、需求生成都不算结构变更——纯靠变更触发会漏掉大部分进度。