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

修改于10/2217 浏览

《公交公司》开发者日志 02 · 每位乘客，都真的被送到目的地

这一期聊城市与乘客。听起来是最基础的系统，但恰恰是这里藏着我们踩过最深的坑。

一、乘客不是数字，是一条计划

在很多模拟游戏里，「乘客」就是一个计数：来了 N 个人，运力够就消掉。

我们没这么做。每位乘客身上带着一条真实的行程计划：

出发站、目的站；
经过哪些线路、在哪一站换乘；
当前在第几段、这一段该上哪辆车。

而且规则很严格：只有线路真的把他送到目的站，才算送达。经过、路过都不算。

车上每个座位格子里显示的是乘客的目的站编号，站台上候车方块里显示的也是目的站编号。玩家扫一眼就能知道：这辆车接下来该往哪开、哪个站的人在等什么。

二、站台方块为什么有红黑两色

站台上每个候车方块有两种颜色，这是我们刻意保留的语义：

颜色含义

深墨色该目的地已有可乘路线，正常等待

红色该目的地暂无路线，需要玩家处理

红色方块是「这里有人去不了」，是玩家该动手的信号。后面做视觉极简的时候，我们差点把颜色语义砍掉——这是整个视觉重设计里最容易被弄丢的一层信息，所以写进方案时专门加了「不可为极简牺牲」的条款。

三、坑一：乘客为什么永远等不到车

有一次测试发现：5 号站有乘客要去 3 号和 7 号站，金线的车来回跑了很多趟，一辆都不接他。

明明有可行路径：5→4（金线）→2（红线）→3（蓝线）。但游戏就是不让他走。

查了半天，根因不在「登车逻辑」，而在路线规划：

我们的路径规划只支持一次换乘——实现方式是两重循环，先找直达，再枚举「第一条线 × 第二条线 × 换乘站」。上面那条路径需要两次换乘（三段），枚举不出来，于是 plan 是空的。

而更隐蔽的是：同一个假设散落在三个地方——

规划的两重循环假设最多换乘一次；
登车条件写死「最多两次上车」；
换乘统计只认「换乘 1 次」。

三者一致地错，所以不会报错、不会崩，只会表现为「乘客不上车」。

修复方案是把问题看成带权最短路：

状态 =（站点，上一条乘坐的线路）；
边 =「在一条线上从 A 到 B」，可行性与成本复用已有的行程计算；
换乘时加一个固定代价，所以最短路不会绕回去重复乘同一条线，换乘次数天然不超过线路数。

规模其实很小（站点数 × 线路数，当时也就 90 个状态），线性扫描就够，不需要额外的数据结构。直达仍然走原来的快速路径，命中即返回。

顺带把登车和统计里的硬上限一起放开了。

四、坑二：「预约」被当成了「锁定」

第二个坑更反直觉。

玩家反馈：站 4 有两位乘客，一辆空的红车开过来，掉头走了，一个都没接。

探针打出来的状态是：车与乘客在线路、方向、站点上全部匹配，却判为不可登车。原因是登车条件里有一句：

and (leg.busId == 0 or leg.busId == bus.id)

busId 是「下一段预约到的那辆具体车」。于是乘客的第二段被锁死在某一辆车上——那辆车没来之前，任何同线、同向、同起点的车都被拒绝。

但「预约」的本意只是确认下一段确实有车，不是「只能坐这一辆」。一旦那辆车被延迟或安排回收，乘客就在站台上白等。

修改后，判据从「下一段预约到车了吗」变成「下一段的线路有车吗」：

下一段状态旧行为新行为

预约到具体车放行放行

线路有车，但那辆车在旧班次收尾/空驶转场拒载本段放行

线路根本没有车拒载本段拒载本段（不变）

一句话总结这次修复的教训：「暂时不可用」不等于「不可服务」。判据应该是「资源是否存在」，而不是「此刻是否就绪」。

五、坑三：被「冻住」的候车段

这个坑最有意思，因为我们第一次判断错了方向。

现象是「反复改线后，车停在旧版本不再接管新线路」。我们照着这个描述去查车，查了很久没结果。

后来加了诊断追踪（把每帧的车状态和乘客状态并排打印），才抓到决定性的一行：

车6(线3@站4 方向-1 normal svcV4) 乘客38(去11 在站4 已登2 段3) 段=线3 版本2

逐项对比：线路吻合、方向吻合、站点吻合，只有版本对不上（车是 V4，乘客的段停在 V2）。

所以根本不是「车不接管」，而是乘客的计划被冻住了。根因是一句看似合理的提前返回：

if trip.boardings > 0 then return end

原意是「乘客已经出发了，剩余行程不该被普通重规划改写」。但这句把乘客尚未开始的候车段版本也一起冻结了。线路改版后，所有车都接管了新版本，而该段仍停在旧版本号，版本永远对不上 → 乘客在站台无限期等待。

修复的关键是区分对象：

段的状态处理理由

在途不动当前段正被承运，改写会让乘客中途改乘

候车 + 有车承接保持冻结那辆车还要把它送完

候车 + 无车承接同步到当前版本没人送它，冻结版本纯属死锁

同一个「冻结」策略，用在不同状态的对象上，结果完全相反。

六、这一期最大的教训

不是某个具体 bug，而是方法论上的三条：

现象描述错了会误导修复方向。我们一开始把问题记成「车卡住」，方向完全错了。后来要求：描述现象前，先确认观测工具本身没影响结果。
只有车或只有乘客的状态都不够。只看车，看到的是「车经过却不接」；只看乘客，看到的是「一直在等」。把两者的字段并排打出来，svcV4 vs 版本2 才一眼可见。
测试不变量要跟着模型一起改。我们有好几条测试断言编码了「最多一次换乘」「预约即锁定」这类旧假设。产品逻辑一放宽，这些断言反而会拦住正确的修复。

猜你想搜

聚光灯游戏创作挑战开发者日志2

聚光灯游戏创作挑战

9.1

8.8