我刚刚发布了Acrophobia——实时多人口uzzle游戏——它在iOS和Android上可用——并想与大家分享在过去的一年中单独构建它时，我学到了什么。

**游戏: ** players随机看到谐元字母，比赛写出与这些字母匹配的幽默短语，然后投票最好的那一个。想像一下Jackbox样式的party游戏，但异步匹配，让你可以随时和陌生人一起玩。

**技术堆栈:** - 使用 React Native(Expo)进行跨平台的iOS/Android - Firebase（Firestore实时监听器，Cloud Functions，RTDB，用于在线状态） - 支持44种语言，具有全面的 i18n

我解决了以下有趣的技术挑战：

**1.实时匹配模式**
快速匹配分配房间使用一个加权匹配系统对用户偏好（语言，字母数，回合数等）。房间以匹配分数排名，因此玩家获得最佳匹配，而不是匹配第一个可用房间。

**2.基于在线状态的主机管理**
Firebase RTDB跟踪连接状态。当主机在公共房间断开连接时，系统自动将主机转移到另一个连接的玩家。如果没有连线人类玩家剩下，房间会自行销毁。私人房间即使在用户后台应用程序时也会被保存。

**3.在44种语言中可以在AI机器人随机匹配模式：play的bot**
每个机器人有一个独特的个性提示。它在房间设置语言中生成上下文短语—不是翻译的英语，但真正的母语中的笑话。类别（食品，时间，运动片等）增加了另一个约束层。

**4.将Firestore监听器加以伸缩：**
每个游戏屏幕使用实时监听器获取即刻更新的挑战是管理 listener生命周期——太多监听器 =expensive，太少 = 凝固的数据。最终在屏幕上使用scoped 的监听器并在解绑时积极清除。

**5. “陈旧房间”的问题**
玩家离开，放在后台，断开连接 — 房间积累起来。建了一个多层清除链条：即刻排除（公共房间）在断开连接时，5分钟的计划缓冲干净以及“还在等待？”对话，自动将闲置玩家从守候列表。

**我会如何不同: ** - 如果我用了一家游戏服务器来代替Firestore纯粹的游戏循环。Firestore有效的交易变得复杂
- 如果我在当天的应用商店截图局部化——苹果商店广告要求它们每个市场
- 不要在web版本上面更早进行构建，让分享和病毒循环更容易

很高兴回答关于架构，匹配系统或其他事情的任何问题。总是很好谈论工作室。

游戏：https://apps.apple.com/app/acrophobia-the-acronym-game/id6760745131