游戏开发不是我的日常工作。我白天开发企业软件，晚上做独立游戏。最近，我想为我的自动跑酷游戏 Trinity Rush 添加 20 人实时赛跑模式。

问题在于，我不想每个月花几百美元运行权威的游戏服务器。如果我老婆看到我爱好项目的 AWS 账单，我就要睡客厅的沙发。

所以我利用确定性种子和通过 Firebase 实时数据库传输的微小输入日志来模拟实时多人游戏。

  1. 无服务器物理计算
    Trinity Rush 是一款单手派对跑酷（你的 3 位英雄组成生命条；点击跳跃，空中点击使用技能）。由于物理是确定性的，我不需要服务器计算碰撞。当主机创建大厅（最多 20 人）时，他们生成一个随机的赛道种子和同步的开始时间戳（提前倒计时 3500 毫秒）。每部手机本地生成完全相同的障碍赛道。

  2. 以 12 字节点击事件代替 X/Y 坐标流
    如果对 20 名玩家的 60 帧位置向量进行流媒体传输，会超出 Firebase 免费额度。相反，我只记录按下/释放的时间戳（模拟毫秒）：{'t': tMs, 'k': press ? 1 : 0}。每 250 毫秒，客户端将该小批量刷新到 Firebase RTDB（关闭本地磁盘持久化，以保持纯内存）。

  3. 1.75 秒的观看模式和公开广播幻觉
    当你的派对被清除后，你会进入观看模式观看幸存者（如果大厅的主机打开公开广播，酒馆里的任何人都可以实时收看）。为防止网络抖动导致其他玩家出现位移，观看引擎使用 1.75 秒的延迟缓冲。你的手机读取幸存玩家的点击日志，并在共享种子地图上本地重放他们的输入。

表面上看起来像是一场混乱的 20 人实时赛（配有真人骷髅和烟花表情），但实际上只是手机之间传递几千字节的 JSON。1,000 个活跃匹配的服务器成本？$0。

如果你想测试网络代码（或想破坏它），游戏在 iOS 和 Android 上免费提供：
https://wono.dev/trinity-rush/get

很高兴回答任何关于 Flame 如何处理确定性固定步长循环或我如何组织 Firebase RTDB 监听器的问题！