H3：发布与背景
4 月 5 日，xkcd 发布了《Machine》，这是与作者合作的第 15 个年度愚人节项目。它是一款多年来梦想的游戏，类似经典的《Incredible Machine》游戏风格的大型鲁布·戈德堡机器建造游戏，由 xkcd 读者创建的机器拼凑而成。更多细节查看Explain xkcd 的精彩介绍。这是在 3 周内构建《Machine》的故事及途中所学。

H3：早期策划
3 月深入探讨想法，从较兴奋的到最终确定让大家坐直的想法，即制作类似 2005 年经典病毒 GIF 的大型拼接机制，参考经典互联网 GIF 动画，但讨论中发现对漫画应是什么有不同核心信念，如球的来源、玩家互动方式等。

H3：从前的尝试中学习
最喜欢和最不喜欢的用户贡献内容互动漫画围绕用户贡献内容，如 2013 年的《Lorenz》和 2020 年的《Collector’s Edition》。《Collector’s Edition》游戏设计未达预期，存在初始视图混乱、玩家无足够动力精心放置贴纸、缺乏总体故事或目标等问题，说明集体画布要发挥作用需有共享上下文和目的。

H3：设计约束
确定构建大型协作弹珠掉落游戏，有太多选择，最终确定 3 个核心原则：

1. 以正确性为代价最大化玩家表达能力，考虑多种模拟方式，最终决定优先玩家构建灵活性，需积极 moderation。
2. 给玩家明确约束以鼓励有弹性、可互换的机器，接受 moderation 和不可预测机器后，设计更严格约束，通过地图生成器提供输入输出约束，让玩家实时反馈构建。
3. 机器应在 30 秒内达到稳定状态，决定 moderation 时间，使球 30 秒后过期，帮助玩家成功，简化 moderation。

H3：模拟与超现实
《Machine》架构有两大赌注，一是在设计约束下连接不同瓷砖成整体机器可行，二是通过快照显示大机器，只有可见区域模拟，初始状态为空时用快照填充，创建快照与 moderation UI 结合，效果远超预期，重置机器误差。

H3：用 React 和 DOM 渲染数千个球
基于 Rapier 物理引擎，创建自定义 React 上下文<PhysicsContext>管理物理对象，简化加载卸载瓷砖，利用 React 函数作为场景图，用 DOM 渲染，优化性能，如直接应用样式减少 diff，创建优化渲染器，进行绘制剔除。

H3：API 和 Moderation
后端由 davean 和 Kevin 用 Haskell 编写，以 redis 为存储，使用 OpenAPI 共享代码库类型，使用 TanStack Query 缓存和自动刷新机器。moderation UI 由[Ed White]设计，用于审核提交，使用有趣度评分排序候选瓷砖，存在提交设计与发布数量不平衡问题，添加模拟加速滑块节省 moderator 时间。

H3：对“Jamslunt Interfoggle”的欣赏
“Jamslunt Interfoggle”是作者喜爱的机器，展示了编辑器约束下意外的有趣结果，如上方的“Bouncy”机器偶尔会发送绿色球破坏蓝色球的堵塞，展现了人们使用项目的创意。目前仍有时间添加自己的设计到最终机器。可查看Machine 的源代码，有问题可在 Mastodon 上联系作者，可尝试实现机器的全全局模拟。