
多人游戏应该获得超过 AWS Gamelift 容器的更多支持,作为它们的编排服务
从今年11月开始,亚马逊网络服务 (AWS) GameLift 现在支持完全托管的容器(整整 在我们抱怨它缺乏这些功能五年之后),这最终使开发者能够使用容器,比如 Docker 的容器,在 GameLift 的编排上部署他们的游戏服务器,以便托管和扩展多人游戏服务器。
我们来分析一下,并更重要地问一下——添加容器是否足够真正改善多人游戏的编排和玩家的在线游戏体验。
AWS Gamelift 的多人游戏容器是什么
通过使用亚马逊弹性 Kubernetes 服务 (EKS) 或与 GameLift 编排集成的弹性容器服务 (ECS),游戏开发者可以管理波动的玩家负载并简化部署。
这种设置允许开发者自定义游戏托管环境,自动扩展,并处理对多人游戏至关重要的复杂网络需求。
GameLift 还增强了玩家匹配和会话管理,提供优化玩家体验的工具。通过这种基于容器的服务架构,开发者获得了操作灵活性,更加专注于游戏玩法,而不那么专注于基础设施。
AWS 对 ECS 容器在 Gamelift 上的多人游戏没有说明的内容
AWS Gamelift 支持容器,但在游戏服务器编排优化的关键领域仍然缺乏透明度,这有助于工作室减少托管成本并最大化在线游戏体验——即分配、扩展、区域分布、匹配和集成与使用的简单性。
分配
首先,AWS 不清楚 Gamelift 中的分配是如何工作。
分配是虚拟机(VM)上游戏服务器占用的空间。除了对游戏工作室来说这是一个痛苦的集成过程外,这意味着优化虚拟机的游戏服务器“填充”以最大化每个 vCPU 的使用是一项挑战。
这种缺乏透明度意味着工作室为未使用的容量付费,以及额外的 DevOps 成本,因为需要管理补位。
其次,您仍然有至少 30% 的开销,因为 Gamelift 必须预热虚拟机,以便舰队容器可以启动容器。虽然您可以在 Gamelift 中设置较低的值,但这样会导致扩展期间长时间(即:破坏玩家体验的持续时间)的容量不足。
注意 Gamelift 的计算器;默认设置的开销为 10%,而我们从未在实际使用中看到过这样的情况,以及需要您的游戏二进制文件(和游戏模式)支持在几分钟内关闭的现货实例。
这具体意味着,如果您不使用足够大的服务器,就会导致不良的玩家体验,例如由于服务器超载而导致的延迟和掉帧。在那种情况下,您可能会更愿意使用对等网络(P2P)。
在 Edgegap,我们为自己能够为游戏开发者提供 优化他们的游戏服务器并分配他们的 vCPU 使用 以降低总体成本感到自豪。
扩展
AWS 没有明确其虚拟机的扩展是如何工作的。Gamelift 的主要价值主张是按需扩展虚拟机的能力,但他们在文档中根本没有提到这对容器的适用性。
如果他们预启动容器,那么我们又回到了扩展的问题;他们如何知道何时扩展,因为容器已经在机器上占用空间?
如果他们在运行中部署容器,这样的速度是多快(游戏服务器的垂直扩展),并且它在所选区域间是如何工作的(水平扩展)?
Edgegap 提供了按需容器部署,保证最高可达 40 个游戏服务器的部署,持续 60 分钟。AWS 是 Edgegap 的供应商之一,但它还使用 16 个供应商(截至撰写时)在所需位置进行垂直扩展。
此外,Edgegap “冷启动”服务器的平均时间为 3 秒——这意味着游戏服务器部署时更多的游戏时间和更少的等待时间。相比其他地方报告的 10 秒以上,显著提升了任何在线游戏的生活质量。
与 AWS 不同,Edgegap按需将您的游戏服务器部署到其 615 多个全球位置。虽然在美国东海岸的玩家在 AWS-US-East 进行扩展是很棒的,但实际上,您的游戏托管需要在全球范围内上下扩展,以为全球玩家提供良好的在线游戏体验。
区域分配
公共云,包括 AWS,让您为虚拟机(无论您是否运行游戏服务器)付费,您将不得不为希望在其中存在的每个区域付费。
想要 10 个区域,这将是“AA”或“三级独立游戏”的最低需求,以保持玩家享受游戏的延迟在足够低的水平?您需要至少支付 10 x C5 大型虚拟机的费用。
这种传统的托管方式意味着,即使您是完全支付的服务器中的共用租户,这也可能会轻松 提升您的成本 5-8 倍。
新一代游戏服务器托管编排服务,如 Edgegap,采用按使用付费的方式。它意味着您 仅在玩家游戏时付费(即,在部署期间)以全球相同的价格。在定价方面真正改变游戏规则。
此外,随着 Edgegap 利用全球最大的边缘网络,它能够相对于传统公共云编排提供 平均 58% 的延迟降低。
与匹配/大厅的使用
另一个挑战是您的匹配器或大厅需要选择哪个位置是最佳的。您必须在匹配器中创建区域,您尝试降低延迟(通过在 AWS 中添加区域),排队时间将会更长,因为您将无法进行跨区域匹配。
Edgegap 的匹配器是 默认情况下唯一具有基于延迟参数的匹配器,这有助于为您的玩家部署最低延迟的游戏服务器。
集成和使用的简便性
AWS 对简单性的定义是一篇关于解释其工作方式需要 10 页的博客文章。
不幸的现实是,它需要您集成和配置 Gamelift,这本身就是一个挑战,以及一整套将编排容器的 ECS。
一旦集成工作完成,这只是开始——您将需要至少 1 名工程师或 DevOps 来观察并管理您的流量的起伏。
此外,目前也不清楚您是否可以对每个容器执行自定义元素,例如,注入环境变量。
“及时”游戏服务器的优势在于加载数据,使用户生成内容(UGC)完全自定义,完全回避了这个问题。例如,六天的福尔哈吉 在游戏服务器部署期间加载其完全程序生成的地图,或者 HIBERWORLD 的数十万种 UGC 开发的游戏类型和地图。
容器是否足够 AWS Gamelift?
对于目前使用 Gamelift 的游戏,并希望因为它们的易用性而迁移到容器的情况,这也许足够了。
不幸的是,如果您想要一种更灵活的解决方案,使您能够以及时、按需的方式利用数百个位置(并且不必管理任何内容),您可能应该考虑新一代游戏服务器编排服务——包括 Edgegap。
书写者
Edgegap团队