两个AI用React盖楼，3秒后楼塌了

一个物理引擎，两个AI对手，无限种塌房方式。开发者把这场实验搬上浏览器，结果连React的渲染管线都在颤抖。

这不是游戏，是前端架构的极限压力测试。

项目代号「混沌建筑师」（Architects of Chaos），核心设定简单到近乎粗暴：两个AI代理轮流堆方块，比谁更高、更稳。但实现层面的麻烦，从第一行代码就开始发酵。

技术栈选型本身就像走钢丝。React负责UI层，Matter.js（一款2D物理引擎）处理刚体碰撞、重力和摩擦力。两者本该各安其位，直到开发者发现——物理世界的「真相」和React的「状态快照」根本活在两个时区。

Matter.js的物理模拟以60帧/秒的速度狂奔，每一毫秒都在重新计算位置、速度和角动量。React的渲染周期却被调度器（Scheduler）拿捏，批量更新、优先级抢占、并发特性（Concurrent Features）随时可能插队。让这两者同步，相当于让F1赛车和共享单车并排等红灯。

游戏循环：一场跨线程的谈判

解决方案藏在GameCanvas.tsx的useEffect里。开发者搭了一个中央游戏循环，用setInterval以100毫秒为周期强行「拉齐」双方进度。

代码结构长这样：Matter.Runner启动物理引擎，独立线程模拟世界；setInterval meanwhile（同时）检查游戏状态——是否暂停、当前阶段、双方代理的实时指标。每次循环，updateAgentMetrics函数被调用两次，分别计算Fortress Architect和High-Rise Maverick的得分。

「SETTLING」阶段的设计尤其值得玩味。玩家放下方块后，系统不会立即进入下一轮，而是等待所有刚体速度低于0.1像素/帧。这个阈值是经验值：设太高，轻微晃动会无限拖延；设太低，地震或碰撞后的余震会让游戏卡死。开发者没有解释0.1是怎么来的，但GitHub提交记录显示，这个数值经历过17次调整。

物理引擎的「确定性」和React的「声明式」在此短兵相接。前者要求精确控制时间步长，后者鼓励开发者忘掉时间、专注状态。两者的缝合点——那个100毫秒的setInterval——成了整栋大厦的地基裂缝。

实时稳定性指标：比高度更残酷的评分

多数堆叠游戏只看高度，「混沌建筑师」引入了实时稳定性仪表盘（Real-Time Stability Gauge）。这个设计把项目从「休闲小游戏」推向了「结构工程模拟器」。

仪表盘计算逻辑未完全开源，但已知它综合了三个物理属性：质心偏移量、支撑面投影面积、关键连接点的应力分布。当稳定性跌破30%，UI进入CRITICAL状态——红色脉冲警告，方块边缘出现裂纹贴图，背景音混入金属扭曲的低频噪音。

这套反馈系统的技术实现比想象中重。Matter.js的Body对象自带mass和position属性，但「结构完整性」不是原生概念。开发者需要遍历所有刚体，构建邻接图，计算每个节点的力矩平衡。这些运算被塞进100毫秒的游戏循环，和React的重新渲染抢主线程。

性能数据没有公开，但代码里藏着线索：updateAgentMetrics被标记为「可能触发长时间任务」，注释建议未来迁移到Web Worker。换句话说，现在的实现是在透支浏览器的宽容度。

两个AI的建造哲学：保守派与冒险家

AI代理的设计暴露了开发者的恶趣味。Fortress Architect（堡垒建筑师）和High-Rise Maverick（高层狂徒）共享同一套感知接口，决策逻辑却截然相反。

堡垒建筑师的策略写死在src/logic/ai.ts里：计算己方所有方块的平均X坐标，在新位置加入随机抖动（jitter），最终落点被钳制在地块边界内。这套算法的本质是用「历史质量的中心」预测「未来稳定的区域」——统计学意义上的回归保守。

高层狂徒的代码未完整展示，但从命名和上下文推断，它可能优先选择最高可附着点，哪怕悬挑比例超标。两种哲学对抗时，常见画面是：一方稳扎稳打造出敦实金字塔，另一方在边缘疯狂试探，最终触发连锁坍塌。

环境挑战模块（Environmental Challenges）进一步放大了这种对抗的戏剧性。Slippery Ground降低地面摩擦系数，Earthquakes注入随机冲量，The Storm施加水平风力。难度系数（Difficulty）不仅控制灾害频率，还调节物理参数的极值——高难度下的地震可能一次性施加50倍重力的横向加速度。

这些效果不是视觉装饰。Matter.js的Engine.world.gravity和Body.applyForce被实时改写，意味着AI必须在运行时重新评估所有已放置方块的稳定性。堡垒建筑师的「历史中心」策略在地震后可能瞬间失效，高层狂徒的冒险结构反而因悬挑摆动卸掉部分应力。

React的隐秘成本：为什么不用Unity

选择React+Matter.js而非Unity或Unreal，这个技术决策本身值得拆解。开发者在博客中承认，初衷是「验证浏览器原生技术栈的边界」——翻译成人话：想看看不用下载安装包、不依赖WebAssembly转译，纯前端能撑到什么程度。

代价是显性的。Unity的物理模块和渲染管线深度集成，FixedUpdate和Update的时序由引擎严格保证。React的并发特性（Concurrent Features）却可能任意暂停、恢复或丢弃渲染任务。开发者用useRef缓存Matter.js的engine实例，用useEffect的清理函数停止Runner，这些都是在React的「函数式纯度」和物理引擎的「副作用地狱」之间走平衡木。

更隐蔽的问题在状态管理。React的setState是异步的，但物理模拟需要立即响应。代码中出现了直接修改ref.current的「违规操作」——这在React文档里被标记为「仅用于逃逸舱口」。整个项目建立在大量「应该避免」的实践之上，却因此跑通了。

这种「脏」实现或许正是实验的价值所在。它证明了浏览器技术栈的弹性：哪怕用最不合适的工具组合，只要理解底层机制，仍然可以交付可玩的体验。代价是代码的可维护性——另一位开发者接手后，可能需要一周才能理清哪个状态是「真相之源」。

项目目前托管在GitHub，演示链接可直接在移动端浏览器打开。加载时间约3秒，首次渲染后物理模拟稳定在55-60帧。但开发者没有披露内存占用数据，长时间运行后的垃圾回收（GC）抖动也未被提及。

「混沌建筑师」不会成为商业产品，它的目标受众是技术同行——那些正在评估Web技术栈边界、犹豫是否引入Unity负载的前端团队。演示的价值不在于玩法深度，而在于它把「不可行」的边界往后推了一格。

最后一个细节：实时稳定性仪表盘的裂纹贴图，在CRITICAL状态下会随时间扩展。但代码显示，这个动画用CSS transition实现，和物理模拟完全解耦。视觉上的「即将崩塌」和物理上的「实际崩塌」是两个独立系统，玩家却被设计引导着相信它们是联动的。这个小小的欺骗，或许是整个项目最诚实的地方。

如果让你用这套技术栈复刻《桥梁工程师》，你会把物理运算迁到Web Worker，还是接受主线程的卡顿风险？