25MHz CPU跑活城市交通，全靠偷懒

1994年，一台主频25MHz的386电脑上，《Pizza Tycoon》的城市街景里，二三十辆小车在街道上穿梭：它们会在路口排队，遇到拐角随机转向，偶尔还会堵成一团，活生生像个真城市。2010年，开发者启动这款游戏的开源复刻项目，最先搞定了街景渲染，可让小车跑起来这件事，却卡了14年。他试过给每个道路格子做占用跟踪，搞出一套共享锁系统，结果小车动个像素都要来回同步；也试过给每辆车做全局路径规划，最后系统复杂到自己都理不清。明明原版在25MHz上跑得顺畅，为什么现代复刻反而越做越复杂？

不给车装导航，让地图指路

直到他扒开原版游戏的汇编代码，才发现当年的开发者玩了个“偷懒”的巧劲：车根本不知道自己要去哪。

整个城市地图被拆成16×16像素的瓦片，每个瓦片自带固定的通行方向——比如有的瓦片只能左到右走，有的只能上到下，拐角瓦片则标注了可转向的方向。小车只要“看一眼”脚下的瓦片，就知道该往哪动，完全不需要提前规划路径。遇到拐角时，它就抛个“硬币”：50%概率直行，50%概率转向，再加上“不能连续左转”的简单规则，交通流就显得自然而不混乱。

你可以把这想象成一个没有导航的迷宫，每个路口都立着清晰的路牌——走哪条路不是车决定的，是路牌说了算。但真实的机制比这更精确：小车每帧只移动1个像素，只有当它走完一整个16像素的瓦片时，才会读取下一个瓦片的方向，更新自己的行驶路径。这种“频繁简单移动+稀疏复杂计算”的分层设计，把最耗算力的逻辑压缩到了1/16的频率。

碰撞检测：先筛再查，不行就等

复刻时最头疼的碰撞检测，原版的解法更是简单到离谱：用最朴素的两两检查，但每一步都在“偷懒”。

现代游戏里，碰撞检测可能会用上空间划分、物理引擎，甚至机器学习预测，但原版直接用了O(n²)的暴力解法——每辆车都要和其他所有车检查会不会撞上。但它加了一个关键的“早退”逻辑：先看对方的行驶方向，因为道路都是单向的，往东走的车和往西走的车根本不可能在同一条路上，直接跳过检查；同方向的车再看是不是在同一条车道，不是也直接跳过。最后真正需要算坐标的，往往只有寥寥几对。

如果真的要撞上怎么办？原版也不搞什么刹车、减速的物理模拟，直接给被堵的小车设一个10帧的等待计时器——等10帧再动。就这么一个简单的规则，反而模拟出了最真实的堵车：前车不动，后车就排队，前车走了，队伍依次往前挪。

这种思路就像学校食堂打饭：先看是不是自己的窗口，不是就直接走；是同一窗口的，再看前面有没有人，有人就等会儿。没有复杂的取号系统，却能保证秩序。

车的生死：看不见就“转世重生”

原版的车辆生命周期管理，同样透着“够用就好”的智慧。

当小车开出屏幕边缘，它不会被销毁再重新生成，而是直接“转世”到对面的道路上——换个颜色，掉个头继续开。这种设计省掉了复杂的车辆创建、销毁逻辑，也保证了屏幕上的车辆数量始终稳定。而车辆的生成也只盯着当前屏幕里的直路瓦片，根据区域的交通密度随机生成，地图滚动时，新露出的区域再按同样规则补上车。

这就像你站在路边看车，开过去的车你忘了，新开来的车你也不会纠结它从哪来——只要路上一直有车，你就会觉得这是个热闹的城市。原版开发者根本不关心车的“一生”，只关心玩家能看到的“当下”。

当开发者终于复刻出和原版一样流畅的交通时，他意识到自己之前的误区：总想着用现代的复杂技术去还原效果，却忘了当年的开发者是在“戴着镣铐跳舞”——25MHz的CPU容不下多余的计算，只能把每一分算力都用在刀刃上。

现在的我们拥有远超当年的硬件，却常常陷入“为复杂而复杂”的怪圈：明明简单规则就能解决的问题，非要套上最先进的算法；明明够用就好的体验，非要追求极致的精确。

少即是多，从来不是一句空话。在这个算力过剩的时代，当年那些“偷懒”的设计，反而成了最珍贵的启示：真正的高效，不是用复杂技术解决问题，而是用最少的规则，满足最核心的需求。