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

修改于10/2227 浏览综合

《公交公司》开发者日志 1 · 我不开车，我让这座城市坐得上公交

本届聚光灯 GameJam 的主题是**「涌现」**。这篇日志想聊聊：我们怎么理解这两个字，又怎么把它变成一张会自己长出问题的地图。

一、先说「涌现」这件事

看到主题的第一反应是「做一个惊喜时刻」，但这个方向很快就放弃了——预设好的惊喜不叫涌现，那叫演出。

我们更认同另一种理解：设计一堆各自简单、但会互相作用的规则，然后让结果自己长出来。

于是有了《公交公司》这个方向：

城市不断成长，每个人都有想去的地方。

你不驾驶公交，你让这座城市坐得上公交。

玩家是公交公司的线路规划员，不是司机。你能做的是连接站点、规划线路、分配有限的车辆、组织换乘——然后眼睁睁看着这些决定在几十秒后变成站台上越堆越高的候车人群。

二、为什么是公交

坦白说，玩法结构的起点是《模拟地铁》。但我们很清楚不能照搬，所以在第一版设计文档里就写死了一条差异化：

线路和道路是两个不同层次。

城市道路是淡灰色的，它决定公交能在哪里开；
公交线路是彩色的，它决定哪些站点得到服务。

这句话看起来像美术描述，其实是玩法核心。玩家画线是在组织道路上的服务，不是拖一条线就凭空修出一条能穿越城市的轨道。同一条街道、同一座桥，可以被好几条线路共用，于是自然产生了共同瓶颈——这是后面所有拥堵问题的物理来源。

三、我们希望玩家先后感受到三件事

这是设计文档里最硬的约束，功能做不做，先看它服务哪一条：

建成感——第一次连线后，立刻看见公交开始服务，乘客上车、到站、下车。
理解感——出现积压时，玩家能区分是「线路不通」「车太少」「线路太长」还是「换乘瓶颈」。
挽救感——调整真的有效，积压和警戒可以被亲眼看着缓解。

第三条尤其重要。很多模拟游戏的通病是：玩家做错了但不知道为什么错，改对了也不知道为什么对。我们要求诊断必须指向真实证据，而不是弹一句「运力不足」。

四、核心循环长这样

观察站点与乘客目的地

↓

规划线路、分配公交

↓

公交接客、乘客换乘、实际抵达

↓

城市出现新站点和更多需求

↓

旧线路变长／车辆不足／换乘站积压

↓

暂停诊断，重组网络

↓

恢复运营，验证队列与送达是否改善

注意倒数第二步是暂停。这是刻意的：我们不想做一款考验手速的实时游戏，而是一款「可以停下来想」的游戏。

五、一个典型的决策长什么样

新住宅区出现了，你把旧线路延长过去。

新住宅获得服务了——但原线路的往返距离变长，车回来的更慢，旧住宅的等车时间开始上升。这时你有三个选择：

继续维持长线，再加一辆车；
把远端拆成支线，通过共同站点换乘；
调整线路顺序，减少绕行。

关键在于：这三个方案谁对谁错，不是脚本判定的，而是由真实的线路长度、车辆数量、乘客行程算出来的。同一个局面，换个城市布局，正确答案就可能反过来。

六、我们刻意不做的东西

写在这里，是为了提醒自己别跑偏：

不做首屏就有几十项政策的交通控制台；
不用「点击升级后送达数直接 +5」这种抽象加分；
不把历史等待时间当成永久危险——已经送达的人，不该继续让站点失控；
不同时开发修路系统和公交公司系统。

最后一条踩过坑。第一版差点做成「既能修路又能开公交」，画面上很热闹，但玩家的每个决策都变得不清晰。砍掉修路之后，玩法反而立住了。

七、目前的进展

游戏已经能跑通完整的一局：18 个站点逐站开放、3 种车型、5 条线路资格、换乘枢纽、环线与往返两种线路形态、10 步新手教学、以及短局/中局/成长/周历四种节奏。

下一期日志会聊城市和乘客——包括我们为了让「每位乘客真的被送到目的地」这件事成立，在路径规划上踩过的一个很隐蔽的坑。

猜你想搜

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

聚光灯游戏创作挑战

9.1

9.0