16

我们需要开发一款具有实时性能的多人游戏。这需要在全球范围内工作（美国、欧洲、亚洲的服务器），并支持巨大的流量。使用 Google Cloud 服务进行托管。

我们正在考虑像 Jam with Chrome、Chrome Maze 或 Cube Slam 这样的参考。

游戏 ：

  • 2 名玩家挑战比赛
  • 我们需要同时显示2名玩家的进度
  • 每场比赛可能持续大约 30 到 45 秒

主办：

我们显然会在 AppEngine 上托管网站，自动扩展，但正在考虑两种实时服务器解决方案：

  1. 使用带有 Compute Engine 的 websocket 服务器

    就像他们使用 Chrome、Maze 等为 Jam 所做的那样。
    开发我们自己的 websocket 服务器（技术待定），部署在欧洲、美国、亚洲的数据中心，处理扩展，它们之间的同步，计算服务器上的延迟问题和客户等。
    但这在技术上很有挑战性，因为我们的时间很短，而且现在还缺少一个管理员系统和网络人员。

  2. 或者使用 Channel API

    我们理解它不是 websocket 平台，实时性能较低。
    但这对我们和我们拥有的时间来说会更加简单和安全。
    所以，我们也想了解更多。

无论如何，我们认为我们可以在前端使用一些图形技巧，让它看起来像实时的，但这真的取决于我们是否有 100~500ms 或 500ms~10s 的延迟。

一些问题 ：

  • 不同解决方案的延迟范围值是什么样的？
    （带有 Chrome 的 Jam 使用 GCE 获得了 100 毫秒，Channel API 可以达到几秒钟吗？）
  • Channel API 服务器如何处理高流量，扩展如何工作，延迟会变得非常高吗？（没有关于频道文档的信息？）
  • 如果法国的人和美国的人一起玩，连接到不同的服务器，等待他们同步，如何处理？
  • 有什么建议或经验可以分享吗？
  • 有什么有趣的阅读或观看吗？（看到一些但不是很精确）
  • 还有其他解决方案吗？

感谢您的任何帮助评论！

编辑：

  • 只有 2 个玩家连接在一起，可能来自不同的世界区域，不需要广播。
  • 我们可以找到一些前端技巧来避免服务器端处理。这是两个玩家之间的比赛，所以我们实际上只需要比较他们的进度，真正的获胜者决议并不那么重要，因为没有真正的东西可以获胜，这更多是为了好玩。
4

3 回答 3

20

如果您需要服务器来处理数据：

我肯定会在 Compute Engine 上使用 websockets！

Channels API 慢得多，而且非常不可预测（延迟因消息而异）！数据必须发送到 Channels 服务器，后者将其发送到 App Engine 实例，该实例必须向 Channels 服务器发出请求，然后将消息推送到客户端。如果您想降低延迟，那里发生的事情太多了！

这是 Channels API 压力测试：
http
: //channelapistresstest.appspot.com/ 尝试多次单击“发送 5”按钮，您会看到延迟数上升到几秒钟。

Channels API 在重负载下也相当昂贵（它可能无法很好地扩展，即使 Google 当然可以通过更多实例来解决这个问题）。

在降低延迟时，地理位置非常重要。借助 Compute Engine 上的 websocket 服务器，您可以将欧洲访问者发送到谷歌的欧洲数据中心，并将您的美国访问者发送到美国数据中心（使用 AppEngine 将提供的地理位置标头）。您无法使用 Channels API（或应用程序引擎，您的所有消息都通过它中继）进行此类控制。也许 Google 有用于 Channels API 的边缘服务器（我不知道），但如果您的 AppEngine 实例位于地球的另一端，那没关系。

如果您不需要服务器来处理数据：

您应该与 WebRTC 建立对等连接，直接在用户的浏览器之间发送内容。这就是 Cube Slam 所做的。（WebRTC 需要一些初始握手（“信号”），以便两个对等方可以找到彼此，并且 Channels API 可以很好地用于该握手，这只是建立对等连接的几条消息。）

WebRTC DataChannels API 会给你一个很好的类似 websocket 的接口，比如在对channel.onmessage = function(e) { yadayada()... };等channel.send("yadayada");点之间发送你的数据。

有时，WebRTC 无法建立对等连接。然后它将回退到 TURN 服务器，该服务器在对等点之间中继流量。Cube Slam 正在使用在 ComputeEngine 上运行的 TURN 服务器（在欧洲和美国都可以降低延迟），但这只是当真正的点对点无法实现时的后备方案。

于 2013-06-13T22:06:28.417 回答
2

阿尔弗雷德的回答是我提出的问题中最好的。非常感谢 ！

但是，我忘了提几个重点，范围发生了一些变化：

  • 我们的开发时间很少（大约只有 1 周）
  • 这是针对仅持续 3 周的活动（我们需要在几个月后将其保持在线，但这并不像我们需要一个持久的架构）
  • 我们需要让它在更广泛的浏览器用户中运行（WebRTC 目前仅在 Chrome 和 Firefox 上运行）

根据这些观点，我们最终提出了第三种解决方案：
使用实时 PAAS。

由于我们不需要可靠的后端开发人员和系统/网络管理员，因此开发起来更容易、更快、更便宜，而且我们可以更专注于项目而不是基础设施和平台。

有一些服务看起来不错，已经在全球范围内托管 MMO RPG 和类似的服务，具有低延迟和良好的扩展系统。
以下是提供者列表：
https ://github.com/leggetter/realtime-web-technologies-guide/blob/master/guide.md

于 2013-06-17T12:21:05.487 回答
2

它还取决于其他因素，例如可扩展性。

Ingress 是建立在应用程序引擎之上的，并且偶尔会出现缓存故障，这令人印象深刻。

请记住，频道 api 正在使用talk.Google，这是建立环聊的服务。可扩展和实时。

就个人而言，如果您的流量水平不稳定且不可预测，请使用应用引擎。如果您认为它可以控制和可预测，请使用计算引擎或其他东西。

于 2013-06-16T05:54:31.650 回答