一款 1999 年的游戏，为什么还在给今天的开发者上性能课

1999 年的 PC，内存不富裕，CPU 也远没有今天这么阔气。《过山车大亨》（RollerCoaster Tycoon）却能在那样的机器上，稳稳地模拟一个热闹的主题公园：成群结队的游客、排队的游乐设施、巡逻的维修工、商店定价、园区评价、路径拥堵……这一切同时发生，画面还不怎么掉帧。二十多年后，很多同类建造模拟游戏反而还会在“几千个小人同屏”这件事上气喘吁吁。

最近，开发者 Lars Thiessen 在一篇长文中拆解了《过山车大亨》背后的技术细节。因为原始源码从未公开，今天外界能看到的“内部结构”，主要来自开源重制项目 OpenRCT2——这是一个基于多年逆向工程、尽可能忠实复现原作逻辑的项目。它像一把考古学家的小刷子，把这款传奇作品的优化哲学，一点点从尘土里刷了出来。

汇编当然厉害，但神话不止于“手写机器码”

提到《过山车大亨》，最常见的说法就是：它几乎通篇用汇编语言写成。放在 1999 年，这已经不是行业主流了。更早的《毁灭战士》大部分都已经使用 C 语言，只有少量关键部分保留汇编。也就是说，Chris Sawyer 在一个大家逐渐离开汇编的时代，反而沿着这条更艰苦的路走到了极致。

这确实带来了性能优势。那个年代的编译器远没有今天聪明，很多现在交给编译器自动完成的优化，当年真得靠程序员自己一条条抠出来。你可以把它理解成手工打磨引擎零件：费时、费力，但打磨好了，车就是跑得更顺。Sawyer 不只是“写得底层”，而是“写得很抠”。在 OpenRCT2 的复现逻辑里，连游戏里不同金额的数据，都按照可能出现的最大数值被分配了不同字节大小。整个公园总价值用 4 字节，商店商品的价格只用 1 字节。今天看，这种做法甚至有点偏执，但在当年的缓存、内存和总线条件下，偏执有时就是效率。

不过，如果把《过山车大亨》的成功全部归功于汇编，那就太小看它了。今天的编译器已经足够强大，很多“手写汇编必胜”的场景早就不存在了。真正让这款游戏站上神坛的，不只是语言，而是一整套围绕性能展开的工程思维：每个变量都不浪费，每次计算都尽量省，每个系统都先问一句——这件事真的值得让 CPU 去做吗？

把公式写给 CPU 看，这是一种快要失传的本事

在《过山车大亨》的代码逻辑里，经常能看到位移操作，也就是用 << 和 >> 替代乘除法。左移两位等于乘以 4，右移三位等于除以 8。对今天的大多数应用开发者来说，这几乎像一堂上古计算机组成原理复习课；但在当年，这种技巧是真能省时间的。

有意思的地方不只是“用了位移”，而是“为什么能这么频繁地用位移”。因为位移只适合 2、4、8、16 这种 2 的幂次计算。如果一个游戏到处都能这么写，通常说明它的很多数值公式，从一开始就是按 CPU 喜欢的方式设计的。换句话说，Sawyer 不是等设计定完了再去优化，而是在设计阶段就和机器“商量好了”。

这件事放到今天，其实很罕见。现代游戏开发流程更像流水线：策划提需求，程序实现，美术包装，测试修 bug。数值设计往往先考虑体验，再考虑技术可行性。很少有策划会为了性能，把一个系数从 9.5 改成 8；程序员也未必有权力这么提。可在《过山车大亨》这里，设计师和程序员本来就是同一个人。于是我们看到一种今天越来越少见的状态：玩法不是压着技术跑，技术也不是被动给玩法擦屁股，而是两者从源头就捆在一起。

这也是为什么我觉得，这篇拆解文章最打动人的地方，并不是“哇，老游戏代码写得真狠”，而是它让人重新意识到，性能优化不是项目后期的消防演习，而是产品设计的一部分。很多今天被抱怨“优化太差”的软件和游戏，问题可能根本不在程序员不努力，而在于设计阶段压根没有把性能当回事。

真正高明的地方：它把“算不起”变成了“看起来就该这样”

《过山车大亨》最经典的一刀，砍在寻路系统上。

如果照常规思路设计，一个游客在园区里应该先决定“我想去玩过山车”或者“我想买汉堡”，然后系统再为他计算一条到目标位置的路径。这听起来合理，也很符合今天不少模拟经营游戏的直觉。但从技术上说，这几乎是最坏情况：你有几千个游客，就意味着可能要同时处理几千次复杂寻路。别说 1999 年的 PC，今天做不好照样会卡。

Sawyer 采取了一个近乎狡猾的办法：大多数游客根本不是“有目标地移动”，而是在路网上近乎盲走。他们沿着当前道路前进，到了岔路口再用一套非常轻量的规则随机选方向，顺便尽量避免死路。于是游客看起来像在逛公园，实际上系统省掉了海量昂贵的路径搜索。

你要是曾经长时间盯着某个游客看，就会发现这事确实挺离谱。一个人口渴了，不会主动找最近的饮料摊；他只是继续乱逛，碰巧路过才买。饿了也一样。站在“真实模拟”的标准看，这显然不够聪明；但站在“游戏运行”和“玩家感受”的角度看，它又恰好聪明得足够。因为大部分玩家并不会逐帧审问游客的内心活动，他们看到的是一个热闹、流动、有反馈的公园，而不是一个严格符合行为经济学的人类社会。

更妙的是，那些少数必须认真寻路的场景，比如维修工赶去修坏掉的设施，或游客准备离园，游戏也没有无条件放开算力，而是直接设了搜索上限。游客默认只搜索有限深度的岔路；超出这个范围，系统就可能直接返回“找不到路”。于是游戏里才会出现那个著名的游客抱怨：我找不到公园出口。

这不是 bug，某种程度上，这是性能策略写进了玩法文本。地图商店卖出的园区地图，还会提高游客的寻路深度，让他们更容易找到出口。你很少在今天的游戏里看到这么坦率、这么“设计即优化”的处理方式。它不试图把技术限制完全藏起来，反而把限制转化成了一个合理的游戏机制。坦白说，我很喜欢这种有点笨、但极其诚实的工程美学。

人挤人不碰撞：老游戏给今天行业的一记提醒

另一个特别有代表性的例子，是公园拥堵。

现实里的主题公园，游客会互相挡路、避让、排队、堵塞。如果在游戏里完整模拟这些行为，当然更真实；代价也同样真实——大量碰撞检测、避障计算、局部路径修正，CPU 立刻开始出汗。《过山车大亨》的处理方式简单到近乎无赖：游客彼此不会碰撞，也不尝试互相躲避。理论上，很多人甚至可以站在同一块路径格子上。

但玩家并不会因此失去“拥堵管理”的压力。因为虽然游客之间不碰撞，他们会感知附近人太多，并因此降低心情、发出抱怨。结果就是，从玩家视角看，“道路太挤会出问题”这个经营逻辑仍然成立；只是底层实现比真实交通模拟轻得多、快得多。

这给今天行业的启发其实很尖锐。过去几年，不少大型游戏和软件陷入一种默认前提：硬件年年升级，所以系统设计可以越来越奢侈。于是我们看到越来越多“功能很多，但一运行风扇起飞”的产品。可《过山车大亨》提醒我们，优化的上限，不在于你把每个算法榨得多干，而在于你是否愿意承认：有些“真实感”，对玩家或用户来说，根本不值那么多算力。

这也引出一个值得继续争论的问题：今天的游戏，是否过度追求“万物都要真实模拟”？从城市建造到生存模拟，从开放世界 NPC 到大模型驱动角色行为，行业越来越迷恋“更像真的”。问题是，像真的，和好玩的，常常不是一回事；更像真的，也不一定更值得算。很多项目最后卡在性能泥潭里，可能不是技术不够先进，而是野心没有经过取舍。

如果说 OpenRCT2 这样的项目在今天还有什么额外价值，那就是它不只是保存了一款经典游戏，也保存了一种几乎失传的开发态度：尊重机器，尊重限制，并且把限制当成创意的边界条件，而不是单纯的敌人。那种感觉有点像老派工程师修一块机械表，不追求堆料，而追求每一个齿轮都刚刚好。

回头看，《过山车大亨》之所以历久弥新，不只是因为它好玩，还因为它在一个资源稀缺的年代，给出了一个极其现代的答案：真正伟大的优化，不是把所有东西都算出来，而是准确判断哪些东西不必算。