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/

unity多人