Search Unity

多くの皆様はすでにご承知のことと存じますが、Unity は新しいコネクティッドゲームスタックにより大きな将来性があると判断したため、UNet はメンテナンスモードになりました。この発表を行って以来、多くの開発者の皆様より、移行期間中のゲームの扱いに関するガイダンスをご希望される声が寄せられました。本記事では、ネットワーキングスタックに関する重要な決定を皆様それぞれに行っていただけるように、皆様にご確認いただく必要のある主な質問事項をまとめたガイドをお届けします。

下のフローチャートの下部に、「UNet をそのまま使い続ける」から「新しい DOTS-Netcode(効率性の高い高水準 Netcode)および Unity Transport Package(低水準ネットワーキングスタック)の使用に切り替える」まで、多数の選択肢が用意されています。皆様のゲームの独自のニーズに合わせて最終的な選択を行ってください。以下、それぞれの質問(確認事項)について、その考え方も含めてご説明します。

スケール

マルチプレイヤーゲームの「スケール」(規模)と言うと、最も一般的には、単一のセッションにおけるプレイヤーの最大人数、あるいは単一のサーバーに接続されたプレイヤーの最大人数のことを指します。この場合、ピアツーピア(P2P)トポロジーでは一度に 24 人を超えるプレイヤーを同期しようとすると問題が生じることが多いため、25 人以上のプレイヤーに対応するセッションに関しては、専用ゲームサーバー(DGS)トポロジーへの移行が推奨されます。

これを大幅に超える数になると、DGS であっても、サーバーランタイムの性能とスケーラビリティが影響してきます。例えば『FPS Sample』 はクラシックな Unity の「ヘッドレスな」サーバーランタイムを使用しています。Unity では、そのサンプル Netcode を使用して、最大 80 のコネクティッドゲームクライアントを同期する性能のテストを行いました。しかし、このランタイムは、Unity の将来的な DOTS サーバーランタイムよりも効率性とスケーラビリティが低く、これを大幅に超えるプレイヤー数にまでサーバーをスケールするのは恐らく困難です。各セッションのプレイヤー数が 80 を超える場合は、新しい DOTS-Netcode と Unity Transport Package(UTP)のアーリーアダプターになられるか、独自スタックの開発を検討していただく必要があります。

また追記として、スケールはネットワーク接続されたオブジェクトや AI(非プレイヤーキャラクター)の数でも測ることができます。したがって例えば 500 個以上のオブジェクトや AI の同期が必要なワールドの場合も、恐らく新しい DOTS-Netcode および UTP への移行が必要となり、新しいステートレスな物理システムによって決定論的シミュレーションを可能にすることをご検討されることになるでしょう。

 

チート

ゲームに関して次に確認すべき事項は、チートの可能性です。一般的に、ゲームが人気になればなるほど、ゲームのクライアントがハックされて不正なアドバンテージが提供される可能性が高くなります。チートは、直接のプレイヤー対プレイヤー(PvP)のゲームだけではなく、例えば以下のような仕組みを導入したゲームなどにも起こり得ます。

  • ペイゲート ― プレイヤーがパスやアイテムを購入するまでコンテンツへのアクセスを制限する
  • リーダーボード/トーナメント ― チートのインセンティブとなる間接的な競争
  • 名誉となるアイテム/レアなアイテム ― 獲得しにくいアイテム

公開コンサートなどの体験にはチートのインセンティブがないため通常は不正が起こりません。しかし、人気の出たゲームの多くが、開発者の予想を遥かに超えたチート問題に悩んでいます。

クライアントのハックやチートが発生する場合の最善の策は、「サーバー権威」を使ってそれを完全に防止することです。サーバー権威を使用した場合、「誰が死んだ」「誰が勝った」「どの戦利品が獲得された」などがサーバーコードによって決定されるので、ゲームクライアントがハックされてもその最悪の影響が他のプレイヤーに及びません。最も問題となりやすいデータがサーバーによって決定されるためです。

一方 P2P トポロジーでは、ゲームクライアントがデータへの権威を持つので、開発者に取れる対策は、データをクラウドに送信し、それに対してルールを適用してチートを検知し、チートを行ったプレイヤーのバン(アクセス禁止)を試みることしかありません。残念ながら、このようなルールを解析して回避することを楽しむ一部の巧妙なゲーマーが存在するため、開発者が「もぐらたたきゲーム」のようなもどかしい状況に陥ることもしばしばあります。ほとんどの場合においては、収益の得られる公正なゲームを確実に実現できる最もシンプルで効果的なソリューションは、DGS トポロジーです。

 

レイテンシ

ここで、ゲームの「レイテンシ耐性」について触れる必要があります。ネットワーク上の他のプレイヤーから更新を取得するのに 1 秒間掛かるとしたら、プレイヤー体験にどのように影響するでしょうか。「ラグがある」感覚が強くなり、プレイヤーがゲームを止めてしまうでしょうか?これが「レイテンシ耐性」です ― つまり、プレイヤー体験が「楽しめない」「プレイしたくない」ものにならない限界の、そのゲームに許容される(耐えられる)最大のレイテンシーです。

ペースの速いゲーム(PC やコンソールの FPS ゲームなど)におけるクライアント間の通信時間は通常、150 ミリ秒未満(理想的には 50~100 ミリ秒未満)である必要があります。この場合、P2P Relay がプレイヤーごとの予測レイテンシーのおよそ倍となり、レイテンシーを 200 ミリ秒未満に抑えられないことが往々にしてあるため、DGS トポロジーが必要となります。

ペースの「若干速い」ゲームの一部はその中間程度となり、P2P トポロジーでも対応可能な場合があります。例えば、一部のモバイルデバイス向けシューティングゲームは、最大 200-250 ミリ秒のレイテンシーが許容されます。指入力の精度に限界があるため、そもそものゲームのペースを若干遅くする必要があるからです。このような場合、チートの可能性が低くてプレイヤー数のスケール(規模)が小さいゲームであれば、UNet LLAPI とサードパーティ製の Relay(Photon や Steam など)で事足りることもあります。

これ以外のほとんどのゲームにおいては(一部のカードゲームも含め)、レイテンシ耐性は 1 秒を超えられません。このため「UNet」(HLAPI + Relay)のソリューションでは、アクティブなリレーデータセンターからのプレイヤーの距離によっては、プレイヤー体験の質が非常に低くなる可能性があります。このシステムを選択すべきゲームは稀です。

 

公開時期

DGS トポロジーを採用される場合、ゲームの公開予定時期が重要になります。時期によって採用可能な選択肢が変わるためです。以下の概要をご確認ください。

  • 現時点 ― Unity Transport Package and Reliabilityプレビュー版として入手可能となっています。これは、サーバー権威ゲームの高水準 Netcode(クライアント上での前方予測、サーバー上でのラグ補償など)用に『FPS Sample』 のサンプルコードと併用可能です。新しい Transport はプレビュー版の段階ですので、より安定した API サーフェスがすぐに必要な場合は、この代わりに LLAPI をご使用いただくことも可能です。
  • 今秋(今年の第 3 四半期)― プレビュー版 DOTS-Netcode が今秋公開の予定です。これはエンティティのシリアライゼーション、デルタ圧縮、前方予測、補間を含むサーバー権威スタックを提供します。プレビュー版ですので、スタックが検証済みの状態になるまでは、API サーフェスに互換性を破る変更が加えられる可能性があります。
  • 来春/夏(来年の第 2 四半期)― 製品版への使用に耐え得る DOTS-Netcode ― DOTS-Netcode および UTP が十分に安定して機能が完全に搭載された、製品版への使用に耐え得るリリースは、来春または夏に予定されています。この時までには、安定性の高い API サーフェスとテクノロジースタック、また改良されたドキュメンテーションが入手可能となる予定です。

上記を踏まえると、2019 年の第 4 四半期より早い時期に公開を予定されている方は、現時点で可能な選択肢のみご利用可能となります。すでに一部の開発者の方々が、新しい Unity Transport Package and Reliability と『FPS Sample』をベースにした独自の Netcode を併用されているので、その選択肢もご検討いただけます。これが困難な場合は、Photon Bolt など、DGS ゲームに使用できる可能性のある他の既製(OTS)のソリューションもあります。([注]これらの OTS オプションの品質は、まだ Unity によって検証されていません。

2020 年の第 3 四半期より早い時期に公開を予定されている方は、今秋から DOTS-Netcode のプレビュー版の導入を開始していただけますが、その後数か月間は API サーフェスに互換性を破る変更が加えられる可能性があります。これが差し支えなければ、アーリーアダプターになってテクノロジースタックを将来に備えることが最善の選択肢です。そうでない場合は、他の選択肢をご検討ください。

2020 年の第 3 四半期以降に公開を予定されている方は、新しいスタックを使用されることをお勧めします。2020 年末以降は、フルサポートの Unity ネットワーキングスタックはこれのみとなります。追記として、新しい Netcode は DOTS テクノロジーに強く依存しており、これを使用される開発者の皆様は少なくとも、クラシックなゲームオブジェクトコードと新しい ECS コードを使用してハイブリッドゲームを問題なく作成できる必要があります。このワークフローは徐々に改善される予定ですが、アーリーアダプターの方は、(現在の UNet Netcode よりも)使い勝手が落ちる状態でご使用いただかなければならないことをご了承ください。

今すぐにゲームのプロトタイピングを行いたいと考えています。今すぐ開始するにはどうしたら良いですか?

この答えは、上のフローチャートから導き出された結果によって変わります。

  1. P2P トポロジー ― UNet および Relay サービスが現段階で提供されており、UNet は 2019.4 LTS でサポートが 2 年間継続されます。Unity Relay は少なくとも 2022 年までは継続されます。これらの選択肢がご自分のゲームに適合すれば、ご採用いただいて問題ないでしょう。
  2. DGS トポロジー ― 将来の DOTS-Netcode へ最も円滑に移行するには、今すぐ Preview UTP と『FPS Sample』のサンプル Netcode を使用してスタートされることをお勧めします。FPS Netcode は DOTS を明示的に使用していませんが、is ECS を考慮して構築されており、効率的に開始するためのたたき台としてお使いいただけます。効率性とスケールがそれほど重要ではなく、完成度の高い API サーフェスが今すぐ必要な場合は、Photon Bolt や Forge などの他のサードパーティー製 Netcode スタックでのプロトタイピングをご検討ください。

今後に向けて

Unity では今後、コネクティッドゲームの将来に向けての取り組みを進めて参ります。私達は、高性能かつスケーラブルで、唯一無二の安定したコネクティッドゲームの制作を支えるエンド・ツー・エンドのソリューションを確立に力を注いでいます。今後も本ブログやフォーラムにて、DOTS-Netcode や UTP、マッチメイキングなどのサービスの開発の進捗状況を開発者がお伝えして参りますので、どうぞお見逃しなく!

66 コメント

コメントの配信登録

コメント受付を終了しました。

  1. awesome. does the fps sample use the new dots havok physics?

  2. You know in around 2014-2015 I was hearing about UNet. I was exicited. I waited soo long for it. And after it was released I had only problems with it. This time I will not let it happen again. It throw me years back because I could not release the game what I wanted to make.
    I already started my own network system now. Ofc it takes time too but its less code.. and implemented my ideas and my needs. The best part is.. I can seperate server and client to make dedicated (console) server. It is super advanced.

    The game Rust is good example. They just took raknet and made own system with it.

  3. You guys are never learning, but thanks god that we have Steamworks and Photon services today so we can stay away from your failure attemtps of making something in the networking area since 2014 when UNet was introduced.

    1. I started to wrote my own network system. Its pretty well. I am really against Photon. Whats wrong with this one (Unity)?

  4. Bla bla bla promises everywhere to add virtual value to Unity. I guess in two years you’ll discard the new networking code and introduce a new one…

  5. Glad to see an acclaration for the current situation. I will like to have more information about the new DOTs net code. Maybe more example or blogs post that helps

  6. Unity recommends Photon Bolt in their blog, what a time to be alive.

  7. The Monarch

    6月 15, 2019 7:17 am

    This is terrible advice. The best advice is to use steamworks.net. Honestly, with all the new features coming in Steamworks 1.44, enhanced latency using the Steam back end, etc, I think the use case for DOTS networking is limited to non-steam games.

    Steamworks.net has already made this obsolete.

  8. I’m sick of it all! I can not wait anymore. I’m leaving

  9. Why would P2P have a HIGHER latency than a dedicated server? P2P could be on a local network, that would beat any server based solution?

    1. Brandi House

      6月 14, 2019 9:48 pm

      These are ballpark figures based on real games’s data and experiences – largely assuming non-LAN scenarios. Agreed that in a LAN-based game (like VR installations), direct P2P could be much faster as long as the scale remains low. For large-scale LAN-based installations, we recommend a server that is hosted locally to achieve the best results.

  10. Until Unity sorts our their networking, I recommend everyone to check out Mirror. It’s free, open-source (some of the cleanest code I’ve seen) and there is an active community.

  11. I have a question what is the future of P2P with Unity? Acording to graph there is none (after 2 years it will be removed and you can only use your own custom netcode).

    Can new DOTS netcode be used for P2P game?
    For coop games (<= 4 players) dedicated servers could be overkill.

    1. Brandi House

      6月 14, 2019 9:50 pm

      For P2P games, many plan to run the server code alongside the client and adopt a client-server P2P model, so in this case, much of the new netcode could still be used. It’s still TBD if we create a new Relay, extend the life of the old one, or find another alternative.

      1. So basically the answer is that there is no P2P plans.

  12. Yannick Comte

    6月 14, 2019 7:30 am

    Your post is unclear and probably very clumsy.. If I read well, that means all projects using the HLAPI have very bad performances and you know that since the begining. I understand you want to change everything in Unity, but you’re doing things bad, especially with communication.

    So today if I want to make a multiplayer game with Unity there are not many options:
    – Trying to open the FPS Sample, it’s heavy, so I’ll loose so much time to use something that will change in 3 months
    – Using the UNet’s low level API
    – Doing something by myself
    – Don’t use the high level API because it’s very bad, we understood thank you
    – Using a 3rd solution, but what about LAN?

    When Unity 5 was released, you removed the old network API because it was so bad.. Today you’re doing the same thing BUT without any valid solution. You can’t ask us to spend so many time in the FPS sample. Is that really serious? A big company like this asking to its customers to look at a project to find themself how to use multiplayer?

    Unfortunatly, this is the same type of communication of all sides. SRP is really not ready for production, we still have to wait, months to have something to use in production BUT you encourage us to use it, even if the label preview is on it.

  13. Robert Cummings

    6月 14, 2019 4:35 am

    The elephant in the room would probably be “does it work with existing monobehaviour projects?” and the answer would be….?

    1. Brandi House

      6月 14, 2019 9:53 pm

      The honest answer is that we’re still working on this actively today; it’s our goal to support “hybrid” games that blend classic Unity objects with new DOTS systems, but until we’ve determined the best path to get there, we don’t want to promise more.

      1. Robert Cummings

        6月 16, 2019 2:10 pm

        Thank you for your patient and clear response, I hope others can show you the same courtesy regarding these matters.

  14. I’m really excited about the DOTS networking future, and I’m not as pessimistic as most others in this thread, but there is something I’d like to point out even though it might come off as rude. It’s not my intention to be rude but I think it needs to be said. When Unity starts a presentation or blog post about networking and proceeds to talk about their server-hosting ambitions, it makes a lot of people in the community very uneasy. The main reason for that is this:

    Server hosting is not *the* big problem that needs to be solved. Not even by a long shot. People are already perfectly okay with using Amazon or Google to host their servers, and they don’t feel like they need any help in that department. What they do desperately need help with is network game programming. They need a networking framework that makes it easy to make lag-compensated, client-predicted, cheat-proof, esports-grade online games, and they have been needing that for years.

    1. Brandi House

      6月 14, 2019 9:55 pm

      It was not our intention to imply server hosting is the biggest challenge; we hear your feedback that building a game that connects players efficiently is the most urgent challenge. Thanks for making this clear.

      1. Leonardo Garcia

        6月 17, 2019 3:41 am

        Hello Brandi excuse me I’m a super noob in this and I’m learning Unity and i’m really bad at it anyway I have some tutorials about how to use basic multiplayer but now this are obsolete or not recommended, even this tutorials I have let me with a lot of questions (I’m not engineer nor study nothing related), and thanks to the information above I understand that the new complete multiplayer System, “DOTS-Netcode” will be available in 2020 3Q, that’s good to me because is a fair time to let me study how to make it work and understand the system so finally my question is can you please give a list of subjects, books , or similar to study, so that I put good base so I can understand easily the DOTS-Netcode and work with it when its Out, because like I said i’m really bad and looks like it’s gonna take me a lot of time to catch this, so for me it’s no bad the long wait, thanks in advance!

  15. So the go-forward solution for now is: “go and spend weeks digesting the thousands of lines of netcode in the FPS sample”?

    1. Let me reply to myself because I feel a little like a dummy. I failed to make the distinction between the DOTS-Netcode and the current Low Level Transport API. So I guess the high level API being made available in preview in the fall gives me a little bit of hope — there’s just nothing to look at currently, right? The only thing available at the moment to “see” or try out is what is available in the FPS sample.

  16. I’ll believe it when it hasn’t been unceremoniously abandoned like all the other networking stacks.

  17. Chris Burns

    6月 14, 2019 1:08 am

    Let’s see if I have this right. First trying to revoke editor licenses from competitor network services. Would be easy to chalk that up to mistaken legalese (clearly the clause was meant to cover streaming game services, and not managed hosting providers), but you were calling them on the phone and telling them “ooooo you’re in trouuuuble”. Meanwhile you were busy deprecating UNet, which I understand as it’s an untestable, maintenance nightmare. If you only you had either a test harness for MonoBehaviour (I had to make my own), or your own engineers had used your so called “humble object” pattern, which the rest of the world simple knows as “not being terrible at coding”. It WAS salvageable though. Nonetheless it’s hard to fault for for making it all OSS, which is indeed generous. But now it’s fully deprecated yet you have no alternative except this understaffed undertaking. Well cheers to the team for producing anything, to be honest. Of course they can iterate on it from here, but clearly you are spread thin and your networking is just one of the places it shows. I’m cheering you on from the bleachers, but I’m not seeing much that inspires confidence. I’m not buying licenses to grandiose future plans, as ideas are worthless without implementations.

    1. A game devv

      6月 14, 2019 5:33 am

      Dude, seriously? This was debunked over and over again, ad nauseam.
      “revoke editor licenses from competitor network services” Completely false. This was FUD from SpatialOS and spread around the net by angry arm chair lawyers.
      “Meanwhile you were busy deprecating UNet” which is in 2022. And there will be plenty of options by then.
      “yet you have no alternative except this understaffed undertaking” There are tons of alternatives, including Dark Rift, Photon Pun, Bolt.

      1. Chris Burns

        6月 14, 2019 6:52 am

        “More than a year ago, we told Improbable in person that they were in violation of our Terms of Service or EULA.”
        “Two weeks ago we took the action of turning off Improbable’s Unity Editor license keys”
        These are statements in a blog in Jan by Joachim Ante. Is he incorrect about this also? Can you explain which parts exactly are FUD? My facts are from the unity side of the story, if we are willing to forgive me misremembering the in person communication as being a phone call. That’s my bad.

        The deprecation warnings from the compiler seemed fairly clear cut about it being deprecated, as did the support article on the deprecation with the specific timeline. Does “busy deprecating something” not mean “very occupied with the deprecation of something”? Also note, deprecation and removal are not the same thing. Deprecation is more or less synonymous with discouraging, the idea being that you – as the API consumer – can’t say you weren’t warned that it might be removed at some point or that it’s not the optimal API to use. Obviously not a great choice for a new software project, right?

        “you have no alternative except this understaffed undertaking” where “you” in this context means Unity Technologies. You disagree and then proceed to list a series of paid alternatives by third party devs. Gotcha, I know about each of those. I know some of the developers even. Some of those solutions are INCREDIBLE netcode, to be sure. Clearly everyone should be coughing up money for something from Exit Games, provided it fits their needs. But those are not Unity solutions, they are solutions which happen to exist in the Unity ecosystem. That’s all I meant …. not that “no solutions exist at all rawrrrrrrrrrrr”. More the point was “wow you are pooching networking a second time, with a large community just waiting, because of what appears to be an under-allocation resources”.

        Maybe I’m totally wrong in something I’ve said, but it doesn’t seem that you’ve pointed anything out yet. Except possibly the phone call. Maybe there was a phone call and maybe not, but my point didn’t rely on whether or not telephony was the transport.

    2. i don’t see how their clash is related to what we have today, so what you saying is not really a helpful feedback

      the things that make me sad is 32 reliable packets in flight, locked receive to 60hz and fps oriented development progress while Photon is rolled out Quantum which seems really exciting for almost any kind of deterministic multiplayer games

      in comparison to what Unity made in 8 months is not what I expected

      1. Chris Burns

        6月 14, 2019 7:10 am

        Certainly we agree on quantum. Amazing stuff. I’m not sure I ever asked about how long that took to dev, so I’m equally unsure how to compare it against Unity’s work. I think Unity will get to that level, or close, eventually. They have the resources for it. But also when you reach a certain level of players, determinism starts to become rough. There are too many inputs to sync. Obvious though where it works, it is awesome.

        I agree also that my statements are not constructive feedback, but merely pointing out what a long strange trip it’s been. And meant not as a kick in the crotch but more a “grrrrrrr I want you to succeed so why aren’t you?!” kinda way. But maybe I’ve got it all wrong about resource allocation and timings for everything to line up internally. Maybe they have it well handled and I just don’t see it that way from the outside.

  18. From where you got those numbers? This graph doesn’t make any sense really, players count is an undefined factor, it can mean 1,000 messages per second or 100,000 of workload depending on a project, it can mean 1,000 CPU clock cycles or 100,000 per frame/iteration per client/player. The scalability section doesn’t carry any valuable information.

    Same thing with the latency, from where 200 ms comes? What this 200 ms means? Network latency? Wireless or wired? What’s the nature of this latency? Processing latency? It doesn’t carry any valuable information as well.

    I’m sorry but your DOTS netcode is FPS-specific feature-limited immature package that you crafted for about half of the year (or more…), and it doesn’t solve a single problem of the current situation with networking in Unity at all. Not even close. You can keep pushing snapshots interpolation, questionable codegen implementations, and other high-level abstractions on top of plain UDP sockets, but how it helps to an average customer?

    1. Sorry but even though you have a point regarding the vagueness of the data in this post, you can’t just say something like your last paragraph without suggesting a clear plan as to what they should do instead.

      Genre-specific network architectures are necessary for quality and performance. Codegen is the way pretty much all networking frameworks handle ease-of-use problems. Snapshot interpolation 100% makes sense and I don’t know what your problem is with it. “A layer on top of UDP” is exactly what a networking API should be.

      And if all else fails, you have the transport layer to make your own custom solutions. So where is the problem? This solution will be suitable for nearly all online games except MMOs and RTSs. Just like UE4’s networking which allowed plenty of teams to make successful online games

      1. > Sorry but even though you have a point regarding the vagueness of the data in this post, you can’t just say something like your last paragraph without suggesting a clear plan as to what they should do instead.

        Say whaaat? A person who suggests using Photon Bolt over anything perfectly know what should be done for the general-purpose product, but Unity invests money into servers hosting company instead of software.

        I don’t know what you are trying to say in other paragraphs it’s absolutely out of the context of the original question.

        1. We’re not talking about server hosting solutions; we’re talking about the viability of where the wip “Multiplayer” repo on github is going.

          Give me a clear breakdown of what’s wrong with it and what should be changed

        2. a> We’re not talking about server hosting solutions; we’re talking about the viability of where the wip “Multiplayer” repo on github is going.

          Then learn what Photon Bolt is, at first, before starting a discussion regarding the package on GitHub repository.

          > Give me a clear breakdown of what’s wrong with it and what should be changed

          You are drunk or you just can’t read? Where did I say that something should be changed there? Re-read the original question and think twice before wasting my time with another pointless reply.

        3. >Then learn what Photon Bolt is
          I know exactly what Bolt is

          >Re-read the original question and think twice before wasting my time with another pointless reply.
          Your question was “You can keep pushing snapshots interpolation, questionable codegen implementations, and other high-level abstractions on top of plain UDP sockets, but how it helps to an average customer?”. You are talking about the “Multiplayer” repo here and you seem to have a problem with it because you ask how it’s helping us. Explain why “Multiplayer” repo is not helping us.

          >Where did I say that something should be changed there?
          So you think the effort put on “Multiplayer” is not helpful, and now you’re saying nothing should be changed? Explain.

        4. > I know exactly what Bolt is

          So why you keep asking pointless questions?

        5. I repeat:
          You literally said that DOTS Multiplayer repo wasn’t helpful. And now you have to explain that statement.

          This is not a pointless question; it’s a question that is problematic to you because you now realize that you were misguided and you’re looking for ways to avoid answering.

          Photon Bolt is a networking framework that supports dedicated and client-hosted servers. It has state replication and tools for prediction & lag compensation. In many ways, it is similar to what DOTS Multiplayer wants to do, except the latter will have better performance for sure. But you have an unexplained problem with DOTS Multiplayer for some reason.

          I am answering all of your questions and you are avoiding all of mine. This is because you are completely unable to answer my questions. Go ahead and keep embarrassing yourself showing the world that you can’t answer

        6. You really love to talk with yourself, don’t you? Asking questing and giving answers yourself, seems like a progress on the topic.

          > In many ways, it is similar to what DOTS Multiplayer wants to do

          Whoops.

        7. I’m done trying to get answers out of you, but I think by now you have very clearly established that you do not know the first thing about networking.

          As explained by my posts and Chris Burns below
          – you do not understand what latency is because you think there’s a difference between a wired 200ms and wireless 200ms
          – you very laughably cite “mature” transports like ValveSockets, Yojimbo and ENet as an example of why you think “layers built on UDP” are not good…. but you didn’t even realize that these 3 are all “layers built on UDP”
          – You are absolutely incapable of explaining what you need in a networking framework

        8. It was a constructive discussion, thanks. See ya after the next half of this year.

    2. Chris Burns

      6月 14, 2019 2:20 am

      If this graph doesn’t make sense, it’s not for the reasons you have listed. Not that I actually want to defend Unity at this point, but now I am compelled.

      I’m not sure where your idea that player count does not represent a specific set of network messages. A high quality networked simulation will attempt to assemble a single outbound message per user per ‘tick’ or ‘frame’ if you like, but not to be confused with a render frame. How it accomplishes that can vary, but that is the goal. So no … 1 player does not mean maybe 10 or maybe 100 msgs per frame unless your netcode is extremely basic. You will know exactly the amount of messages and it will be 1 or a very low number, or else, again, your netcode is extremely basic. You are correct that the amount of CPU is quite variable depending on implementation, but notice the graph doesn’t try to factor CPU at all. If you are making your own server, you will factor that and provide X compute across N games. If you are using Unity’s service they will have already factored CPU for you.

      Latency …. this a blog post about networking. What do you think they mean by latency? Latency is not measured in terms of whether you are wired or wireless or using a tin can with a string attached. That is irrelevant. It is generally a measurement of the time it takes for packets to reach the remote endpoint from your network interface (aka whatever hardware on your computer is sending the data). Where does 200ms come from? Did you not read the Latency section below the graph? They bothered to explain this to you, but perhaps you didn’t bother to read it and felt you were asking a rhetorical question? Many (but not all) games start to fall apart after the 200ms point. Generally games are designed around a maximum acceptable latency so if you know yours then you can follow the chart. Maybe it’s not 200ms but it’s probably also not 200s.

      Lastly, I don’t see DOTS as FPS specific, but OK. The only part I can get behind here is “feature-limited immature package”, but I bet in some ways it’s already ahead of whatever your alternative was a month ago. That is unless you were going to pay money for something in which case you could get anything in between OK and *extremely* well crafted netcode. How is the “average user” going to figure out how to leverage a high performance, low level entity component framework without something like cecil to rewrite their code, or codegen to write their code? Then what if the system changes. Codegen is the optimal solution and as far as I’ve seen is fairly standard. You describe your data and the codegen figures out how to compress it and hands you back finished code for that. From there you can further optimize it if you know better, but more often the case will be that you don’t. This is all very weird because I’ve never seen someone say protobuf is dumb for doing this exact thing, but maybe it’s because the people implementing it aren’t “average users”? I assume by that we mean novice coders. No judgement, just facts. Unity is all about empowering those folk to make cool stuff.

      “high-level abstractions on top of plain UDP sockets” you just described almost every API for networked simulation in history

      1. > “high-level abstractions on top of plain UDP sockets” you just described almost every API for networked simulation in history

        Learn mature protocols and transport layers such as Valve’s sockets, Yojimbo, ENet and so on before saying something like this.

        I didn’t read the wall of text that you’ve written, sorry, but I hope you have fun.

        1. Philippe St-Amand

          6月 14, 2019 4:37 am

          You realize that Valve’s sockets, Yojimbo, and ENet are literally “high-level abstraction layers over UDP sockets”, right?

          See for yourself:
          https://github.com/networkprotocol/yojimbo – “Encrypted and signed packets sent over UDP”
          http://enet.bespin.org/Features.html – “ENet thus attempts to address these issues and provide a single, uniform protocol layered over UDP”
          https://github.com/ValveSoftware/GameNetworkingSockets – Just look at the code

        2. Chris Burns

          6月 14, 2019 5:46 am

          I know enet inside and out. I have the benefit of over 20 years of low level IO and networking experience in C. enet is a very outdated, 1990s style IO model using the poll() API, which happens to be the slowest of all the IO APIs. Also enet is JUST UDP sockets, with a higher level abstraction over them.

          In the more advanced netcode, the unreliability of UDP is handled at the application layer, and not at the transport layer. The conclusion I am drawing here is that you are mainly parroting things you’ve read and barely or not at all understood. Clearly you are dealing with challenges absorbing simple written information, whether from lack of desire or ability is the only unclear part. Also seems you might have a “tired of living in mom’s basement complex” which is causing all this hostility? Or maybe you aren’t even there yet :D

          My diagnosis is that you don’t have a bright future in really any form of development environment, and you are going to badly need that codegen you tried to rail on. But I actually do hope you succeed in making something cool. Good luck, man!

        3. > I know enet inside and out. I have the benefit of over 20 years of low level IO and networking experience in C. enet is a very outdated, 1990s style IO model using the poll() API, which happens to be the slowest of all the IO APIs.

          Well, you have no idea what you are talking about for your 20 years old experience, my friend. Poll() is used there for efficient waiting of a single UDP non-blocking socket to avoid the overhead of communicating with the kernel when the socket has nothing to read instead of spinning and checking it. Open Google and start learning basics or at least take a look into the source code of modern transport like Valve’s GameNetworkingSockets where a similar technique is used.

          > Also enet is JUST UDP sockets, with a higher level abstraction over them.

          No. It’s a full-featured protocol encapsulated into UDP, unlike Unity’s creation which provides only basic reliability layer with sequencing that involves head-of-line blocking.

          Your experience collapses so quickly…

        4. Chris Burns

          6月 14, 2019 3:35 pm

          Get ready for more than anyone ever wanted to know about enet ………

          “No. It’s a full-featured protocol encapsulated into UDP”
          I think you meant: Yes you are right that it is an abstraction, but it also features a reliability layer with reliable ordered mode, unlike Unity. “abstraction over UDP sockets” and “reliablity layer with full reliable ordered” are not mutually exclusive.

          “avoid the overhead of communicating with the kernel …”
          If you mean “avoid the overhead of additional unneeded IO syscalls” then it’s true, but that’s not exactly what enet does.
          If you mean “poll can be called without resulting in a syscall” then no, it basically cant. If the parameters are invalid (eg. struct pollfd *fds param is not the compile time size known to glibc), then the glibc poll wrapper can possibly avoid a syscall. This will not be the case in enet, or really anyone’s code.

          “… when the socket has nothing to read instead of spinning and checking it”.
          This is how poll is used generally, but there are caveats and also this isn’t quite how enet uses it.
          One of the drawbacks to poll is that your thread can be spuriously awakened by certain signals. But it’s not bad with only one file descriptor.
          In a way mentioning poll was a trap, since enet won’t even call poll if your enet_host_service timeout is 0, which I have seen several implementations use. Also enet does not exactly use poll to avoid syscalls, since it calls it at the *end* of enet_host_service. And the call will only happen if all sendmsg and recvmsg calls return EWOULDBLOCK and your timeout is large enough that there’s still something left for enet to sleep on.

          So yes, enet is outdated and it does not achieve optimum efficiency. Does it totally suck? Well, not for what it is intended for, though there are better transports. Is it good enough? Probably yes, but not for much outside the gaming world. That’s all long moved on to libs with asynchronous IO, threading, and event loops built in eg. asio, aws-c-io, libuv. Regardless of what many seem to think, the challenge of realtime networked simulations does not strain your server’s network IO, and some solutions don’t use a transport reliability layer at all. Reliability can reside in the application layer where decisions on whether and what to retransmit can actually be made. The problem is almost always in how to shrink the amount of data you are transmitting each tick to fit within the MTU in such a way that it’s fast enough not to fall behind the tick rate, or to support X games per server. For this you will end up with something like a priority / LOD system or determinism and only sync inputs or some other solution.

          Anyway I was wrong about your future as a dev. And I apologize talking trash in first place. You definitely have the persistence, but you have a level of certainty surrounding some things that doesn’t align with your knowledge. If you push past that you will go farther and faster. Also if either yojimbo or steam sockets have a C API I’ll review, since they’re both bsd 3clause.

        5. I didn’t read another wall of text that you’ve written sorry don’t have time to explain that you have no clue how things are works there, my friend. But maybe someday you will learn…

        6. Sorry reading text and code and understanding OS level IO APIs is hard :( Ask mom and dad for help?

          Let’s recall how you started down this road of proving you might be the most ignorant person to ever try networking:
          You: “What this 200 ms means? Network latency? Wireless or wired? What’s the nature of this latency? Processing latency?”

          Definitely it means wireless latency + processing latency. You are on your way to stardom buddy :D Never stop pretend you know anything of substance … its going REALLY well so far ;)

        7. > You realize that Valve’s sockets, Yojimbo, and ENet are literally “high-level abstraction layers over UDP sockets”, right?

          Obviously? Of course they abstract sockets, I said somewhere that they don’t or what?

          What I’m saying is that the difference between the Unity transport and any of those libraries is like a small fish versus whale.

        8. You said: “You can keep pushing snapshots interpolation, questionable codegen implementations, and other high-level abstractions on top of plain UDP sockets, but how it helps to an average customer”

          When I pointed out that almost every game network library in history is an abstraction over plain UDP sockets, you doubled down on your argument and provided a list of libraries that use plain UDP sockets. What you transmit over UDP does not transform the socket into something other than a UDP socket. I think you must know that, but you are just trying to climb out of a hole by digging harder.

          I have worked with libraries that deliver all the high level features you want from Unity, not as a customer but as an implementer of the native IO layer. Those libraries did NOT have reliability implemented at the transport level AT ALL. If you think that is necessary then you are mistaken, though it’s clearly a commonly demanded feature. I understand the appeal, and I don’t fault anyone for wanting it.

        9. In the case of ENet, you don’t need its socket abstractions to use the protocol with WebRTC for example or with any custom sockets. You don’t understand the difference between two simple things what is a networking library and what is a network protocol.

        10. One more time for homebrew network programmers: Unity’s new transport is a plain UDP sockets without a protocol which means without: a secure connection association/handshakes, network conditions estimation and adaptation, flow/congestion control, recovery from data corruption, protection against denial-of-service and man-in-the-middle attacks, and many other essential stuff that makes a network protocol what it’s called.

          I’m not impressed with your attempts to explain something more or less adequately, you better start reading books instead or take a few professional courses.

        11. Chris Burns

          6月 21, 2019 7:23 am

          Let’s recap ….
          Me: “high-level abstractions on top of plain UDP sockets” you just described almost every API for networked simulation in history
          You: Learn mature protocols and transport layers such as Valve’s sockets, Yojimbo, ENet and so on before saying something like this.

          Me: enet is JUST UDP sockets, with a higher level abstraction over them
          You: No. It’s a full-featured protocol encapsulated into UDP

          Phillipe: You realize that Valve’s sockets, Yojimbo, and ENet are literally “high-level abstraction layers over UDP sockets”, right?
          You: Obviously? Of course they abstract sockets, I said somewhere that they don’t or what?
          Yes, you literally did say that. Twice. But wait …. you are gonna basically say it again

          You: Unity’s new transport is a plain UDP sockets without a protocol which means …….
          You just did it again. You are confusing a socket with library features built over the socket. When your mistake is pointed out, you begin to explain (using 0 facts) how everyone else must be the idiot and they should google and read some books.

          You: You don’t understand the difference between two simple things what is a networking library and what is a network protocol.
          You merely *think* I don’t understand. You continue to misuse or confuse these concepts:
          – UDP protocol
          – UDP sockets
          – higher level protocols built over UDP sockets/protocol
          – abstraction

          “plain UDP sockets” obviously means something to you that it does not mean to me or anyone I’ve worked with. You have now explained what you think it means. I disagree. A socket is just an identifier for you to perform IO calls. You are SAYING the word sockets, but what you MEAN is not the concept of sockets. You get that’s what is happening, right?

        12. Recap is much simpler: you don’t understand the basics of network programming and you are a liar.

          Show your LinkedIn/Upwork page or anything else that proves you as “I have the benefit of over 20 years of low level IO and networking experience”.

          Then we’ll have a talk. For now you argue like a kid.

        13. So far you’ve gone from “what is latency? wired or wireless?” to “you need to learn modern libs” to “you need to google the basics” to “enet doesnt use just UDP sockets” to “you need to read some books” to “you are a liar”. Here are the facts:
          OSI Layer 3: IP
          OSI Layer 4: UDP
          OSI Layer 5 to 7: Everything you have talked about or *meant* to talk about

          Somehow you are talking about layer 5-7, but you are using terms that denote concepts from below, like “UDP socket”. You stated that enet implements a reliability layer which is why its not just UDP sockets. Yes obviously it features reliability. But its reliability layer is not implemented at OSI layer 4, therefore everything it does boils down to just payloads over UDP sockets. You obviously know this on some level in your own way, so I don’t get what the charade is about. Layer 4 != Layer 5 or 6 or 7.

          You are doing a poor job of proving it, but you clearly have a thinly veiled personal stake in believing I don’t know ANYTHING. Where I merely believe you misspoke, or are confused about some relatively minor details in the grand scheme. Honestly, I’m fine with you just telling everyone who will listen how some guy in the comments of a Unity blog post:
          – lied about being over 40
          – lied about having a career in C and networking IO
          – wasn’t even willing to prove himself a non lying liar to a troll who wanted to see his upwork of all things

        14. I still don’t see anything that approves your ” 20 years of low level IO and networking experience”?

    3. NoExecute, what do you actually want for unity networking?

      1. What people want: networking “archetypes”, with an option for full determinism, animator support, straightforward synchronization of custom data across connections, a transport layer with secure connection association and communication with the support of various delivery types or transport-agnostic modules (the second option would be perfect where byte arrays or Unity’s abstraction can be used back and forth).

  19. James Velasquez

    6月 13, 2019 10:39 pm

    How does the new model work with free and plus unity users

  20. This is getting really old. You are creating blog post every 1 and half year with all the plans and roadmaps for unity networking, yet you were unable to deliver any of it. Look at your git history of your new transport layer in last year… it was barely touched. If you want to see how networking is done you might look at your competition as that’s example of how it is done properly. Until unity is able to show something worth a while I would recommend you to use one of the available transports with you own hlapi otherwise you will end up rewriting you network code over and over. Unity networking is a joke atm but Im ready to be proven wrong…

  21. Niklas Werner

    6月 13, 2019 9:46 pm

    Agree with previous comments, please provide plenty of well documented examples when DOTS-Netcode gets released.

  22. Philippe St-Amand

    6月 13, 2019 9:24 pm

    I think you guys will have to deal with a lot of people who are angry at DOTS and who would want all new features to not be built for DOTS, but I’m here to show my full support for this new direction Unity is taking and I’m convinced people will soon realize that DOTS isn’t this big bad inaccessible monster that they think it is. The participation of asset store publishers will be key to the adoption of DOTS, I think

    I’ve been heavily invested in studying and implementing online architectures in the past years (Quake 3, Tribes 2, Overwatch, UE4, Halo Reach, CSGO, etc….), and looking at the Multiplayer repo on Github, it seems like it’s really going in the right direction

    I’m under the impression that it borrows concepts from the Tribes 2 model (“Ghosting” of objects) and from rollback networking (“Simulation” systems). Can you share some of your thoughts on the networking model of DOTS networking, even if not everything is set in stone?

  23. Please have plenty of example ready when the Preview is released.

  24. All I ask is have plenty of examples ready when the Preview releases.

  25. This was much needed, and is extremely helpful.