25MHz CPU塞下30辆会堵车的汽车

1994年的《Pizza Tycoon》在25MHz的386处理器上，同时跑着30辆会等红灯、会排队、会在路口互相谦让的小汽车。2024年的开发者花了14年才复刻出来——而且第一次搞出来的方案，比原版复杂了大概100倍。

这不是怀旧，是一堂关于"过度设计"的解剖课。

开源项目Pizza Legacy的作者最近写完交通系统后，把这段经历写了出来。他2010年就开始复刻这款DOS游戏，第一件事就是做了城市街道的近距离视角。但那个视角里的车流，直到2024年才终于跑起来。中间14年，他扔了至少三个完整方案。

2017年的那次尝试特别典型。他给每个地图格子做了占用追踪系统，每辆车移动前要先向网格申请权限，像抢火车票一样"预订"和"释放"位置。几辆像素小车，被他写成了分布式锁的并发教材。

系统越来越复杂，bug越来越多，乐趣越来越少。作者心里一直有个声音：原版游戏用25MHz CPU就能跑，我的i7在矫情什么？

原版代码的"作弊"艺术

答案藏在汇编代码里。作者花了很多年慢慢啃原始程序，最近两年还借助了大语言模型帮忙理解。看完之后的感受，用他自己的话说："我带着一脑袋现代概念冲进去：场景图、寻路算法、碰撞检测，当然还有用不完的CPU——然后全错了。"

《Pizza Tycoon》的城市地图是160×120的格子，每个格子对应一种地形。道路有两车道、T字路口、十字路口和弯道。现代开发者看到这种结构，本能反应是建图、算最短路径、做A*寻路。

原版程序根本没这么干。

核心洞察简单到有点侮辱人：车不需要知道去哪。每辆车的"大脑"只有一个变量——当前所在格子的"出口方向"。开到格子边缘时，查一下这个格子的类型，随机选一个合法出口，开过去。重复。

没有全局路径规划。没有"从A到B"的概念。每辆车就像一只在迷宫里乱爬的蚂蚁，只是这个迷宫的设计让它看起来像在通勤。

作者贴了一张原始地形文件的解析图：landsym.vga里的每个字节编码了行列位置，0x54表示第5列第4行——仓库的屋顶瓦片。这些30年前的像素块，构成了交通系统的全部"基础设施"。

"看起来像真的"比"真的是真的"便宜100倍

原版的车流有几个聪明的视觉欺骗。

第一，车永远不会掉头。道路格子只定义了前进方向，没有倒车选项。所以虽然路径是随机的，车流方向是固定的，看起来就像有目的地的通勤。

第二，路口的"谦让"规则极其简陋。不是真正的队列系统，而是简单的优先级：先到的先走，冲突时随机让行。偶尔会有车叠在一起——原版也有这个bug——但玩家_scroll地图时注意力分散，根本注意不到。

第三，车辆生成和销毁完全按屏幕区域管理。离开视野就删除，进入视野就按道路密度随机生成。没有"这座城市有500辆车"的模拟，只有"这块屏幕需要8辆车"的演出。

作者2017年的"网格锁"方案，试图解决车辆重叠问题。但原版根本不想解决这个问题——它用25MHz的预算，买了"足够好"的视觉效果。

现代开发者被工具惯坏了。我们有物理引擎、有ECS架构、有多线程调度，本能反应是把问题"正确"地解决。但1994年的程序员没有这些选项，他们被迫用剧场布景的思路做模拟：观众信了就够了，后台多乱都行。

LLM读汇编：考古工具的新用法

作者提到一个有趣的细节：他借助大语言模型理解汇编代码。这对LLM来说是个相对冷门的用例——不是写代码，是读代码，而且是读没有符号表的机器码。

效果出乎意料地好。"几年前这还是项令人兴奋的新技术"，作者写道。LLM能识别循环结构、函数边界、常见的DOS图形例程模式。当然需要人工验证，但比纯手动反汇编快了不止一个数量级。

这个细节本身也是个隐喻。2024年的开发者用AI工具，才能勉强跟上1994年程序员的效率思维。技术进步了两代，但某些解决问题的直觉——或者说，对"足够好"的嗅觉——似乎失传了。

Pizza Legacy项目现在开源在GitHub上。作者没说它能不能在25MHz CPU上运行，但提到了一个数字：他的最终实现，交通系统的CPU占用"可以忽略不计"。

14年，三次重写，从分布式锁到随机漫步。这个弯路的价值，可能不在于代码本身，而在于那个反复出现的自我质问：原版用25MHz就能跑，我在折腾什么？

游戏开发圈有个老笑话：玩家看到的永远是舞台正面。Pizza Tycoon的交通系统是这个笑话的极致版本——连舞台侧面都没有，只有几面会动的布景板。但25MHz的CPU上，它们演了30年通勤戏，没人退票。

现在的问题是：你手头的项目里，有多少"网格锁"正在悄悄膨胀？