unity多人_导航Unity的多人Netcode过渡

unity多人

该博客的最新更新时间为2020年4月27日。 (This blog was last updated, 27th April 2020.)

As many of you know, we put UNet into maintenance mode because we believe there is a better way forward with our new connected games stack. Since this announcement, we have learned that many of our developers need guidance about the best path for their game during this transition period. In this post we’ve consolidated key questions you’ll need to answer and highlighted how you can make critical decisions about your networking stack.

众所周知，我们将 UNet置于维护模式是因为我们相信使用新的联网游戏堆栈有更好的方法。自从发布此公告以来，我们了解到，在过渡期间，我们的许多开发人员都需要有关其最佳游戏途径的指导。在本文中，我们综合了您需要回答的关键问题，并重点介绍了如何对网络堆栈做出关键决策。

As you see at the bottom of the flowchart, you have many options, ranging from continuing to use UNet as-is, to targeting our new DOTS based Netcode (efficient, high-level netcode) and Unity Transport Package (lower-level networking stack). Which option you choose depends on the specific needs of your game. In this blog, we’ll walk you through each question and how you should think about them.

如流程图底部所示，您有许多选择，从继续按原样使用UNet到针对我们基于新DOTS的Netcode(高效，高级网络代码)和Unity Transport Package(低级网络堆栈) )。选择哪个选项取决于游戏的特定需求。在此博客中，我们将引导您完成每个问题以及您如何考虑它们。

规模 (Scale)

When we talk about the scale of a multiplayer game, we most frequently refer to the maximum number of players in a single session or connected to a single server. In this case, peer-to-peer (P2P) topologies typically struggle when you attempt to sync more than 24 players at a time, so for sessions supporting 25 or more players, we recommend moving to a dedicated game server (DGS) topology.

当我们谈论多人游戏的规模时，我们最常指的是单个会话或连接到单个服务器的最大玩家数。在这种情况下，当您尝试一次同步超过24个玩家时，对等(P2P)拓扑通常会遇到困难，因此对于支持25个或更多玩家的会话，我们建议移至专用游戏服务器(DGS)拓扑。

Beyond this, even on a DGS, the power and scalability of the server runtime also matters. For example, the FPS Sample leverages Unity’s “headless” server runtime, and we’ve tested the ability to synchronize up to 80 connected game clients using its sample netcode; we should note that this Sample is not yet using the latest transport, so please pull latest libraries for your game. However, the Unity “headless” runtime is not as efficient or scalable as our future DOTS server runtime, and it is likely difficult to scale the server much beyond that player count. At 80+ players per session, you’ll either need to become an early adopter of the new DOTS-Netcode and Unity Transport Package (UTP), or investigate creating your own stack. One additional note, scale can also be measured by number of networked objects or AI (i.e. nonplayer characters), so for example, if your world requires synchronizing 500+ objects or AI, you will also likely need to move to the new DOTS-Netcode and UTP, and likely consider ensuring deterministic simulation with the new stateless physics.

除此之外，即使在DGS上，服务器运行时的功能和可伸缩性也很重要。例如， FPS示例利用Unity的“无头”服务器运行时，并且我们已经测试了使用示例网络代码同步多达80个已连接游戏客户端的功能；我们应该注意，此示例尚未使用最新的传输方式，因此 请为您的游戏选择最新的库 。但是，Unity“无头”运行时的效率或可伸缩性不如我们未来的DOTS服务器运行时，并且可能很难将服务器扩展到超出播放器数量的程度。每节课有80多个播放器，您要么需要成为新的DOTS-Netcode和Unity Transport Package(UTP)的早期采用者，要么研究创建自己的堆栈。另外要注意的是，比例尺也可以通过联网对象或AI(即非玩家角色)的数量来衡量，因此，例如，如果您的世界需要同步500多个对象或AI，那么您可能还需要迁移到新的DOTS-Netcode和UTP，并可能考虑使用新的无状态物理学来确保确定性仿真。

作弊 (Cheating)

The next question to consider for your game is the likelihood of cheating. In general, the more popular your game becomes, the more likely it is that the game client will be hacked to provide unfair advantages. Even games that are not direct player-vs-player (PvP) still encounter cheating, for example, when you incorporate mechanics like:

下一个要考虑的问题是作弊的可能性。通常，您的游戏越受欢迎，该游戏客户端被黑以提供不公平优势的可能性就越大。即使不是直接玩家对玩家(PvP)的游戏也仍然会遭受欺骗，例如，当您合并以下机制时：

Pay gates — limiting access to content until players have purchased a pass or item;

付款门 —在玩家购买通行证或物品之前限制对内容的访问；
Leaderboards/tournaments — indirect competition that adds an incentive to cheat;

排行榜/锦标赛 -间接竞争，增加了作弊的动机；
Prestigious/rare items — low-probability items that are difficult to attain.

著名/稀有物品 -难以达到的低概率物品。

Experiences such as a shared concert have no incentive to cheat and are typically safe from exploitation. However, we’ve found that many games that become a popular struggle with cheating much more than their developers originally expected.

共享音乐会之类的经历不会诱骗他人，而且通常不会被剥削。但是，我们发现许多游戏因其作弊行为而引起了人们的广泛反对，远远超出了开发人员的预期。

When hacked clients and cheating do occur, the best option is to prevent it entirely with “server authority”. With server authority, the server code decides who died, who won, what loot was awarded, etc., so even if the game client is hacked, the worst cases won’t reach other players since the most-contentious data will be determined by the server.

当黑客入侵的客户和作弊行为确实发生时，最好的选择是完全通过“服务器权限” 来阻止它。借助服务器权限，服务器代码可以确定谁死亡，谁赢得了胜利，获得了什么战利品等，因此，即使游戏客户端被黑客入侵，最坏的情况也不会传到其他玩家，因为最有争议的数据将由服务器。

In comparison, in P2P topologies, the game clients are the authority of their data, so in these cases, the best a developer can do is attempt to detect cheating by sending data to the cloud, running rules against it, and attempt to ban the players who cheated. Unfortunately, gamers are crafty and love to reverse-engineer these kinds of rules to work around them, so often the developer finds themselves in a frustrating game of whack-a-mole. In most cases, DGS topology is the simplest and ultimately most effective solution to ensure a fair game that can earn revenue.

相比之下，在P2P拓扑中，游戏客户端是其数据的权威，因此，在这些情况下，开发人员可以做的最好的事情是尝试通过将数据发送到云，运行规则来检测欺诈，并尝试禁止作弊的玩家。不幸的是，游戏玩家很狡猾，并且喜欢对这些规则进行****以解决这些规则，因此开发人员经常发现自己陷入了令人沮丧的w鼠游戏中。在大多数情况下，DGS拓扑是最简单且最终最有效的解决方案，可确保公平的游戏可以赚取收入。

潜伏 (Latency )

Now we need to talk about “latency tolerance” in your game. If it takes 1 second to get an update from the other networked players, how will the player experience feel? Will it feel so “laggy” that players quit? This is what we mean by “latency tolerance” – the maximum latency your game can tolerate before the experience becomes unenjoyable and unplayable.

现在我们需要谈谈您游戏中的“延迟容忍度”。如果需要1秒钟从其他联网播放器获取更新，那么播放器体验会如何？玩家会觉得自己很“懒惰”吗？这就是我们所说的“延迟容忍度”，即在体验变得令人不愉快和无法玩之前，游戏可以忍受的最大延迟。

Fast-paced games (like FPS games on PC/Console) usually require communication between clients to be less than 150ms, and ideally less than 50-100ms. In these cases, a DGS topology is required since a P2P Relay roughly doubles the expected latency per player, and frequently cannot ensure less than 200ms of latency consistently as a result.

快节奏的游戏(例如PC /控制台上的FPS游戏)通常要求客户端之间的通信时间小于150ms，理想情况下小于50-100ms。在这些情况下，需要DGS拓扑，因为P2P中继会使每个播放器的预期延迟大约加倍，并且经常不能确保始终少于200ms的延迟。

Some semi-fast paced games fall somewhere in-between and could be supported with a P2P topology. For example, some shooter games on a mobile device can tolerate up to 200-250ms latency since the limited precision of the “fat thumb” inputs already implies the game will need to be a bit slower paced. In these cases, UNet LLAPI with a 3rd-Party Relay (e.g. Photon or Steam) could be sufficient, assuming your game has a low likelihood of cheating and player scale is small.

一些半快节奏的游戏介于两者之间，并且可以通过P2P拓扑进行支持。例如，由于“胖拇指”输入的有限精度已经暗示了游戏将需要稍微慢一些，因此移动设备上的某些射击游戏可以忍受200-250ms的延迟。在这些情况下，假设您的游戏作弊的可能性很小并且玩家规模很小，那么带有第三方中继的UNet LLAPI(例如光子或Steam)就足够了。

Most other games (even some card games) cannot tolerate greater than 1s of latency, which is why our “UNet” (HLAPI + Relay) solution can lead to some very poor player experiences depending on how far the player is from an active relay datacenter. It’s rare that this system is the right choice for your game.

大多数其他游戏(甚至某些纸牌游戏)不能忍受超过1秒的延迟，这就是为什么我们的“ UNet”(HLAPI +中继)解决方案可能会导致某些非常差的玩家体验的原因，具体取决于玩家与活动中继数据中心的距离。很少有这种系统适合您的游戏。

启动窗口 (Launch Window)

Assuming that you’ve ended up with a DGS topology, we need to know when you hope for your game to launch, because your options will change based on what will be available. Here’s a high-level outline:

假设您最终获得了DGS拓扑，我们需要知道何时希望启动游戏，因为您的选择将根据可用的内容而改变。这是一个高级概述：

Right now: the Unity Transport Package and Reliability are available in preview, and this can be paired with the new DOTS Netcode preview. . Given the Preview state of these libraries, you could use LLAPI or external libraries instead if you need a more stable API surface immediately.

现在： 预览中提供 了Unity运输包和可靠性 ，并且可以与新的DOTS Netcode预览配对。。给定这些库的预览状态，如果您需要立即更稳定的API表面，则可以使用LLAPI或外部库。
Q2 2021: Production-quality DOTS-Netcode – we’re targeting a production-quality release in early 2021 for DOTS-Netcode and UTP to be sufficiently stable and full featured. By this time, developers should have a fairly stable API surface, tech stack, and better documentation.

2021年第二季度：生产质量的DOTS-Netcode –我们的目标是在2021年初发布DOTS-Netcode和UTP的生产质量，使其足够稳定并具有完整的功能。到此时，开发人员应该拥有一个相当稳定的API表面，技术堆栈和更好的文档。

So, if you plan to launch before Q2 2021, you should plan to use off-the-shelf (OTS) solutions, such as Forge, Photon or DarkRift 2, that may also work for DGS games (note: we have not verified the quality of these OTS options).

因此，如果您计划在2021年第二季度之前推出，则应计划使用现成的(OTS)解决方案，例如Forge，Photon或DarkRift 2，它们也可能适用于DGS游戏( 注意：我们尚未验证这些OTS选项的质量 )。

我今天想做我的游戏原型；我现在如何开始？ (I want to prototype my game today; how do I get started now?)

This is a tricky question and depends on your outcome in the flow chart above.

这是一个棘手的问题，取决于您在上述流程图中的结果。

P2P topologies: UNet and Relay services exist today, and UNet will remain supported in 2019.4 LTS for at least 2 years. The Unity Relay will remain active until at least 2022. If these options work for your game, it’s a fairly safe bet to go ahead and use them.

P2P拓扑 ：UNet和中继服务已存在，并且UNet将在2019.4 LTS中至少支持2年。 Unity Relay将一直保持活动状态，直到至少2022年。如果这些选项适用于您的游戏，那么继续使用它们是一个相当安全的选择。
DGS topologies: To ensure the smoothest transition to the future DOTS-Netcode, you can get started today using the Preview UTP and DOTS Netcode. If efficiency and scale aren’t as critical, and you want a mature API surface immediately, you can consider prototyping with other 3rd-party netcode stacks like Forge, DarkRift 2, or Photon.

DGS拓扑： 为了确保顺利过渡到未来的DOTS-Netcode，您可以立即使用Preview UTP和DOTS Netcode入门。如果效率和规模不是很关键，并且您想立即获得成熟的API表面，则可以考虑使用其他第三方网络代码栈(例如Forge，DarkRift 2或Photon)进行原型制作。

下一步是什么？ (What’s next?)

We appreciate your patience as we work on the future of connected games at Unity. We’re hard at work getting in place an end-to-end solution to help you make connected games that are performant, scalable, unique, and reliable. Stay tuned to the blogs and forums where we will be posting developer diaries keeping you up to date on our progress in developing services like DOTS-Netcode, UTP, matchmaking, and more!

感谢您耐心等待我们在Unity 上开发联网游戏的未来。我们正在努力建立端到端的解决方案，以帮助您制作高性能，可扩展，独特且可靠的联网游戏。请继续关注博客和论坛，我们将在其中发布开发人员日记，以使您随时了解我们在开发DOTS-Netcode，UTP，婚介等等服务方面的最新进展！

翻译自: https://blogs.unity3d.com/2019/06/13/navigating-unitys-multiplayer-netcode-transition/