开发
- 使用 LocalMultiplayerAgent (LMA) 在本地工作站上进行迭代测试。这既节省时间又节省成本，同时由于所有产物都在本地运行，也简化了调试。该工具已开源，欢迎贡献和增强。有关使用它的更多详细信息，请参见此处
- 使用计划设置具体的调度计划，以节省 standingBy 服务器成本。例如，如果所有测试和验证都是在工作时间进行的，可以将计划设置为仅在工作时间内保留 standingBy 服务器。设置计划不产生额外费用。
- 使用 VmMetrics 或您自己的分析器来确定在您所选 SKU 的单个虚拟机中可以打包多少个游戏服务器。
- 使用服务器日志和崩溃转储进行深入分析。
发布准备
- 将您的分配请求调整为面向生成别名。它们有助于在服务器更新过程中将游戏客户端无缝迁移到较新的游戏服务器，还可以帮助管理配额问题（稍后讨论）。
- 使用 QoS 信标跟踪游戏客户端最近的区域，并利用该信息进行分配。这些还可以与 PlayFab 匹配结合使用，将具有相似延迟的客户端分组在一起，并为它们分配最近的服务器。
- 充分利用 PlayFab MPS 的完整地理覆盖范围，以确保游戏服务器始终位于玩家附近。考虑在一个地理区域内使用多个区域，以在发生区域性故障时提供更高的可用性。例如，在 NorthEurope 和 WestEurope 都有服务器，并在分配请求中（按优先级顺序）指定这两个区域，可以让在一个区域失败的分配在列表中的下一个区域成功。
- 请确保您已请求并获得了为游戏服务器选择的虚拟机 SKU 的配额批准。
- 可能存在您的游戏服务器所选的虚拟机 SKU 并非在游戏预定发布的所有区域中都可用的情况。在这种情况下，可以使用别名按 SKU 和区域拆分生成，或在单个生成中使用区域覆盖，仅为这些区域选择不同的虚拟机 SKU。
- 使用动态 StandingBy 根据需求扩展游戏服务器。这与默认的静态 standingBy 配置相结合，可以提供一种经济高效的方式来应对发布期间的高需求。
发布日
- 通过 PlayFab Game Manager 中的仪表板和事件流跟踪您游戏的成功发布。花些时间庆祝一下，这是您应得的！
发布后
- 游戏往往会形成一个需求节奏，可以再次编排为计划。使用计划与动态 StandingBy 相结合，实现经济高效的发布后游戏扩展。
- 使用生成别名进行游戏服务器更新，并逐渐将流量转移到新的游戏体验。