工作室

iScoot 由 Abdul 和 Ayas Alzenki 共同创立。游戏 iScoot 是一款设定在滑板公园中的多人社交体验。玩家可以加入会话、一起骑行，并在线上彼此陪伴。没有淘汰机制，也没有需要大规模服务器端高精度支持的目标循环。该体验以社交和休闲为核心，围绕“在场感”打造。目前演示版已在 Steam 上提供，游戏正接近抢先体验发布。

这一前提决定了基础设施需求的方方面面。会话规模较小，流量不可预测。优先事项是让玩家快速进入会话、在进入后保持体验响应流畅，并将成本控制在独立游戏可承受的范围内。

挑战

iScoot 之前的服务提供商采用舰队模型，这意味着它必须始终维持完整服务器运行。这使 iScoot 需要承担空闲服务器的成本，而对于一款按设计就是小规模、休闲会话的游戏来说，这是一种昂贵的运行方式。

正如 Abdul 所描述的：

“在该服务剥离给第三方之前，Unity 的 Multiplay 对我们这类游戏的运行方式来说成本很高，因为我们不得不保留过多的闲置容量。”

除了成本之外，团队还需要一种在缺乏后端基础设施经验的情况下也能真正运作的方案。这意味着要有清晰的文档、能够自然集成的匹配器，并且不需要从零构建编排逻辑。Abdul 评估了多个服务，每个都花了几天时间，但最终都卡住了。

解决方案

Edgegap 现代化的容器化编排让采用按对局绑定会话的游戏开发者能够按需即时部署每个游戏服务器——仅在请求游戏服务器时启动，在会话结束时关闭，从而优化资源使用与成本。这不同于传统的舰队式托管：工作室无论玩家是否在使用，都要预留并支付整组完整虚拟机或裸金属节点的费用。

对 iScoot 来说，这解锁了一个关键能力：能够以远小于舰队式平台要求的规模运行服务器。由于 Edgegap 的容器化基础设施可以分配部分 vCPU，而不是整台节点，小型社交休闲游戏的会话就可以按实际工作负载来定尺寸。

“它让我们能够运行的服务器规模比之前小大约 10 倍，这与 iScoot 更匹配。”

小型、即入即玩的会话仅在有玩家在线时运行，并且只为实际使用付费。这与 iScoot 的开发现实完美契合。

这次迁移本身也体现了小团队对基础设施合作伙伴的真实需求。文档覆盖了基础要点，而不要求 Abdul 先补齐分布式系统背景知识。匹配和部署模块之间的衔接方式也符合直觉。

“Edgegap 让迁移变得切实可行。文档很好，匹配器和部署模块也讲得通，我们大约一天就跑通了。在那之前，我们尝试了其他几个服务，每个都花了几天，但总是卡住。”

结论

iScoot 的迁移帮助工作室找到了与其游戏规模和商业现实相匹配的编排服务。一款拥有小型、即入即玩会话的社交休闲游戏并不需要大规模预留实例。它需要的是：玩家到来时服务器启动，玩家离开时服务器停止，中间没有成本。

Edgegap 的即时、容器化编排正好提供了这些：服务器运行规模仅为此前所需的十分之一、迁移只用了一天，以及正如 Abdul 所说，“看起来已经比我们之前的方案更契合。”

随着 iScoot 迈向抢先体验发布，工作室可以专注于其本该做的事情——打造有趣、社交化的滑板车体验，同时将底层基础设施交给 Edgegap 处理。