Search Unity

コネクティッドゲームの開発に伴う課題の解決に向かう取り組みの一環として、Unity がまず注力したのは、リアルタイムな多人数参加型ゲームです。Unity は、この分野を「民主化する」ための過去の取り組みの中から多くのことを学びました。何よりもまず、優れた新技術を構築するためには、ひとつひとつのステップにおいて皆様のフィードバックが必要です。ですから、新しい取り組みを開始するにあたっては、皆さまにもフィードバックを寄せて新技術構築のプロセスにご参加くださることを願っています。同時に Unity からは、頻繁な更新と高い透明性を提供してゆくことをお約束します。

先日の UNet の廃止に関するブログ記事の掲載後に寄せられたフィードバックから、今後は私たちの計画に関する情報をより詳しくご提供する必要があるということが明らかになりました。これを踏まえて、本記事では、私たちの長期的なビジョン関してと、今秋公開の最初のリリースについて、両方の情報をご紹介していきたいと思います。

ネットワーキング ― パフォーマンスとスケーラビリティ

長期的なビジョン

「苦労せずにハイパフォーマンスを実現」 ― これは、Job System(マルチスレッド処理)、Burst コンパイラー(Unity ゲームコードに特化)、Entity Component System(データ指向のゲームコード)など、現在進行中のいくつかの機能の背後にあるコンセプトです。これらの機能を組み合わせれば、パフォーマンスを桁違いに向上させる大幅な改善を実現することができます。

こうした各種機能が共に開発されることで、Unity は、スケールに関わらず実質的にどんなゲームにも対応可能となります。大きなマップも、多数の動的オブジェクトや AI も、そして多数のプレイヤーのネットワーク化も すべてが実行可能になります。

この新しい枠組みの中では、ネットワーク化された環境におけるコンポーネントの有効化が格段に行い易くなります。さらに、高度に構造化された ECS のデータによって、デルタ圧縮や補間など、高度なシミュレーションのための洗練されたソリューションが実現可能になります。

現在、以下の基本方針を念頭に置き、新しいネットワーキングスタックの構築を進めています。

  • 透明性 ― パッケージによって、4 か月毎のメジャーリリース時以外にも、新しいソリューション用のソースコードの提供や、プレビュー版として更新バージョンの迅速な提供を可能にする。ゲームのニーズに応じてネットワーキング用ソリューションのデバッグと拡張が行える。
  • モジュール性 ― モノリシックなライブラリは、(おそらく不要である機能のために)オーバーヘッドを不必要に追加する。したがって、基本の Transport 以外の新しい機能はすべて個々に分かれた形でオプションとして提供される。
  • パフォーマンスとスケーラビリティ ― パフォーマンスは Unity の全機能に求められる重要な要件であり、ネットワーキングは Unity の目指す「苦労せずにハイパフォーマンスを実現」というビジョンに実現のために重要な役割を担っている。Unity は、サービス提供開始時点から、ネットワーキングをモダンなゲームのニーズに合わせてスケーリング可能にする形でサービスを提供する。
  • (コネクティッドゲームに)特化したアーキテクチャ ― すべてのタイプのゲームにおいて理想的な唯一のソリューションというものは存在しない。したがって Unity は、FPS、リアルタイムストラテジー、格闘ゲームなど、それぞれのタイプのゲームで使用されている一般的なネットワーク・アーキタイプに対して、別々のソリューションを作成する。まず最初に、FPS ゲームで一般的に使用されるクライアント側予測モデルに焦点を合わせて取り組む。

短期的な計画

近い将来のリリースに向け、新しいネットワーキングスタックをゼロから構築しています。手始めは、ごく最小限のトランスポート層(プレビューパッケージとしてソースと共に提供される UDP ベースの送信/受信機能)の開発です。デフォルトで含まれる API は、Job System と互換性があり、ECS ベースのゲームに適合するように最適化されたものとなる予定ですが、いずれも必須とは考えていません。この第 1 段階のリリースは、必要最小限の機能のみを備えたものになります。実際に皆様のゲームに使用するに足りるものにするには、今後追加して行かなければならない重要な要素(信頼性、シーケンシングなど)が数多くあります。

これと並行して、新しい Transport の上にビルドされた、完全なソースコードを含む FPS サンプルゲームの公開も予定されています。これには、クライアント側予測・補間・デルタ圧縮用の、製品版への使用に耐えるクオリティのサンプルコードも含まれます。 他のアーキタイプに関しても、後に第 1 段階のリリースが予定されています。

ホステッド型専用サーバー:一貫性と安全性

長期的なビジョン

リアルタイム・マルチプレイヤーのトポロジーを分析した結果、リアルタイムなマルチプレイヤー(多人数参加型)ゲームに最善の選択肢は専用ゲームサーバー(DGS)モデルであるという結論に至りました。なぜなら、このモデルには以下のようなメリットがあるからです。

  • 一貫性 ― 処理とロジックが、制御可能なリソースに移動されます。これにより、接続品質の予測が可能となり、遅延が大きく影響するゲームにおいて「ホストに有利になってしまう」問題を無くすことができます。
  • スケーラビリティ ― ピアツーピア接続の場合、ゲームインスタンス 1 つにつき多数のプレイヤーを扱うのは困難(一般的には多くても十数人が限界)ですが、DGS なら、より強力なマシンで遥かに多い人数に対応可能です。
  • 安全性 ― サーバー権威型コードは、すでに起こった不正を検知するのではなく、チートを予防することを可能にします。
  • 迅速なイテレーション ― マルチプレイヤーゲームの場合、公開後であっても調整のために甚大なイテレーションが必要になることが往々にしてあります。しかし、DGS モデルの場合、サーバー上のみで実行されているロジックの更新には、(認定が必要になることもある)クライアント側のパッチが不要です。

これは、Unity が Multiplay を Unity ファミリーに迎え入れた主な理由のひとつです。彼らの定評ある専用サーバーのオーケストレーションの技術は、デベロッパーが自身のゲームのニーズに合わせてサーバーフリートのスケーリングをシームレスに行うことが可能となります。また Multiplay は、ベアメタルクラウドとクラウドバースティングを組み合わせたハイブリッド型のホスティングによって、スケールに応じてコストを最適化します。彼らの技術は、すでに『PUBG』『タイタンフォール 2』『Gang Beasts』その他多くのゲームで、エンジンに依存しない企業カスタムのソリューションに使用された実績があります。Multiplay についての詳細は、Unite Berlin 2018 で行われた Multiplay についての講演の録画(英語)をご視聴ください。


短期的な計画

私たちは現在、誰もが簡単に利用できるように Multiplay の技術を Unity のエコシステムに統合させることに集中しています。近い将来、離れた場所にいるチームメンバーや友人と協力してゲームテストを行うために使用できるゲームホスティングサービスの開発が可能になります。最初のアルファ版には、フリートのプロビジョニング、Linux サーバービルドのアップロードとデプロイ、Server Query Protocol のパッケージ、サーバーの状況をモニタリングするための単純なステータス情報とログ収集が含まれる予定です。

マッチメイキング ― 柔軟なロジックとシームレスな統合

長期的なビジョン

マッチメイキングは、ゲームの楽しみを最大化させるために特定のプレイヤー同士を結び付ける(マッチングする)機能ですが、これを上手に行うのは簡単なことではありません。当然のことながら、目的やマッチング規則はゲームによって異なるため、そのすべてに対応し得る柔軟さを備えた唯一のソリューションを生むのは困難です。

Unity は、Google との共同開発によるオープンソースのマッチメイキングプロジェクト『Open Match』を Unite Berlin で発表しました。これは、上述の問題の解決に向けた第一歩です。このプロジェクトは、拡張性を最優先させたデザインとスケーラビリティの提供を目的としています。皆様のプロジェクトのニーズに合わせて自由にマッチングのロジックおよびオーケストレーションモジュールのカスタマイズが可能になっています。

Unity は現在、Open Match を中核としたマネージドのマッチメーカーを構築中です。Open Match が進化・改良されるに従ってこの品質も向上し続けます。また、Unity デベロッパーの皆様は以下の付加的なメリットも得られます。

  • 完全なマネージド型のサービス ― Unity が 皆様に代わってマッチメーカーサービスの実行・スケーリング・運営を行うので、皆様はゲームの開発に集中することができます。
  • スケーラブルなゲームサーバーのホスティング ― Unity のマッチメーカーがデフォルトで Multiplay のオーケストレーション技術とシームレスに統合され、プレイを希望するプレイヤーの人数に応じてゲームホスティングサーバーの許容量をスケーリング(上げ下げ)することが可能になります。つまり Unity デベロッパーは、このサービスさえ利用すれば、複雑なサーバーのライフサイクルについて学ぶ必要がなくなります。
  • アクセシビリティ ― このマネージド型サービスの将来的なバージョンでは、ゲーム開発者がカスタムロジックを記述せずに遅延・スキル・待機時間のバランス調整を行える、シンプルですぐに使用できるオプションを提供する予定です。
  • カスタマイズ性 ― 通常よりもさらにカスタマイズを要するゲームのために、マネージド環境で完全にカスタマイズ可能なマッチングロジックが 2019 年に実現されます。このマッチングロジックは標準の Unity C# 言語で記述され、Unity 環境内からご自分のマッチメーカーにデプロイすることができます。これにより、既成のソリューションで事足りない場合には、自分のゲーム専用のマッチングロジックをカスタマイズできるという大きな安心感を得ることができます。

短期的な計画

先週公開された Open Match v0.1 は、今すぐご利用いただけます。Unity は今後も引き続き、Google やコミュニティの皆様と共に、機能と品質の両面においてこのソリューションを改良すべく尽力してまいります。

これと同時に、マネージド型マッチメーカーの最初のバージョンも近い将来に Unity のエコシステム内にリリース予定となっています。これは、プレイヤーカウント設定、サーバー割り当てとのシームレスな統合、クライアントライブラリのパッケージ、自動デプロイ機能などを提供します。最初のバージョンでは、設定のプレイヤーカウント(人数)に達するとサーバーがシームレスに割り当てられ、ゲームのクライアントがそのサーバーに接続されます。

サーバーランタイム ― コストとモジュール性

長期的なビジョン

専用サーバーをホストする場合に一般的に聞かれる最も大きな懸念事項は、コストに関するものです。Google Cloud のようなパブリックなクラウド環境内におけるコストは、仮想マシンの仕様、使用時間、使用されているネットワーク回線の容量(送信/egress)、OS のライセンス料の組み合わせによって決まります。コストを削減するには、以下を行う必要があります。

  • サーバーランタイムが必要とする消費プロファイルを最小化することで、最小限の仕様の仮想マシンで、最高パフォーマンスでの安定したゲーム実行を可能にする。
  • 「プレイヤーの需要を満たすためにゲームによって必要とされる時にのみサーバーの起動と割り当てを行う」方式のサーバーオーケストレーションとマッチメイキングによって、

  • サーバー使用時間を最小化する
  • 直前のフレームから変更のあった最も関連性の高いデータのみを送信する素晴らしいシミュレーションコード(デルタ圧縮など)で、

  • ネットワーク回線容量を最小化する
  • サーバーを Linux OS で実行することで、プロプライエタリな OS の高額なライセンス料を回避する。
  • ゲームが、ベアメタルサーバーの安定したベースラインからメリットを享受できる程度の規模の経済性を実現したら、ベアメタルとクラウドバースティングを組み合わせる

これら 5 点のうち最後の 4 点のためのソリューションについては、すでにご説明しました、そしてサーバーランタイム消費プロファイルも、現在、Unity が非常に注力しているもののひとつです。私たちは、新しいパッケージ管理のシステム(パッケージマネージャー)が完全に実装されれば、デベロッパーが Unity をサーバーランタイムとしてごく小さなプロファイルで実行できるようになると考えています。この最小限のプロファイルによって、ゲームの目的に合わせて必要なパッケージのみを含めることが可能になります。

短期的な計画

現在私たちは、Unity Linux ランタイムの「ヘッドレス」なバージョンの最適化に集中的に取り組んでいます。具体的には、たとえば「ヘッドレス」モードで意図せず実行されてしまっているレンダリングやアニメーションやオーディオの再生をすべて見つけ出すなど、容易に行える方法でこれを行っています。私たちの目標は、現行の「ヘッドレス」バージョンの Unity で、メモリとビルドサイズと CPU 消費を最小限に抑えながら安定性と稼働時間を向上させることです。

バージョン 2018.3 では、デベロッパーのワークフローが改良され、すべてのスタンドアロンプレイヤー向けの新しいオプション「Server Build」が追加されました。これを使用するとデフォルトがヘッドレスになり、サーバースクリプトロジックを分離するための新しい UNITY_SERVER シンボルが使用できるようになります。

さいごに

  • コネクティッドゲームに関する詳細情報は、unity3d.com/connectedgames をご覧ください。
  • フィードバックがございましたら Connected Games のフォーラムの一番上の固定スレッドに、ぜひご投稿ください。
  • 一部の新技術をアルファ版でお試しになりたい方は、こちらからご連絡ください
  • 今後も本ブログで様々な話題をお届けしてまいりますので、ぜひお見逃しなく!

48 コメント

コメントの配信登録

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

  1. So will it be possible to use p2p for optimization purposes? Like if you have a small group of players that are far away from everyone else, they could be treated as a p2p group instead of having them all relay through the server?

  2. Hello,

    With your new Unity/Google Cloud multi-player system, what will be the maximum number of simultaneous players you will support in the same room at the same time?

    Right now im using PHOTON PUN multi-player system for Unity, its nice and easy to use, but seems it can only do maybe 6 to 10 players tops per room, i need way more than that, maybe 50 to 100 or even 1000. Can you guys swing that?

    Thanks!

    1. You should really check your code, sounds like you could use some optimizations. Our game warscrap.io has 10 players per room and over 20 bots + vehicles.

  3. What is the recommendation from Unity on starting a new project today for a networking heavy game? Work through everything in a networking free setup for now until the new Multiplayer Connected stuff is done, or something else?

  4. Hi guys, any plans on in editor client + server splitscreen like in Unreal 4?
    I feel like the need to build and launch a server any time you want to test anything is the major drawback and i’ve seen many people
    trying to work around it by building separate assemblies and what not.
    I don’t see any mention of that, is that being worked on?

  5. Tomas Pontes

    9月 20, 2018 3:07 am

    Authoritative server models are welcome since at UNET this is a big headache and a mess to reach. Glad to see that there will be an FPS sample, prediction and safety are the most important things to it.

    1. Thanks Tomas – looking forward to your feedback when the Alpha comes out soon.

  6. I don’t quite understand where this leaves me, I have very little experience in multiplayer, I built what I thought was a p2p authorative model in a game i’m making.

    the idea being is that a player is a host, but not a server, its a single screen game, all input values are fed to the host and the host moves the players, which is then authoratively sent back to the clients. there is a small delay but for the most part its working well.

    this was all done in UNET HLAPI and syncvars. matchmaking is being used but no servers are hosting the games.

    are we now saying this setup will no longer be possible or supported in the new networking system?

    1. In the new system, instead of running the server on local hardware (that is inherently hackable), it will be by default hosted on a separate box (either by Unity/Multiplay or by other means of your choosing).

  7. The big question – Will there still be a completely “Free” tier for those small “between friends” games that use <1GB / year as we currently have with the UNet servers? Alternatively, will we still have self-hosting options?

    1. The networking code is agnostic, so self-hosting is certainly possible. LAN multiplayer games are always free and will definitely be supported since it’s required for development purposes anyways. Beyond this, pricing is still something we are working on with our Google Cloud partners.

  8. This is truly great news. My studio are working on a multiplayer RTS that cannot work with lockstep because of the complexity of the game. Support for the server-authoritative client-predictive archetype will make our lives easier in the coming months.

    I would really like to know exactly where Unity now will make the API’s. What will we as a studio have to do for ourselves and what will we be able to do in Unity?

    1. If there are specific features you most need – please let us know! Our roadmap is still evolving, and there will be many more features even after the upcoming alpha release.

  9. I hope there is still peer to peer for small scale free non competitive project, I pray the sin and the moon, even the cloud and teh rain!

    1. For small games, you may want to consider LAN or local multiplayer. You may also be surprised by cloud hosting; you only pay for what you use since the servers spin up/down based on player demand.

  10. Michael House

    9月 13, 2018 2:33 pm

    At this point, I would love to see a post about what we should be doing right now to prepare for these changes. How should we architect now to avoid too much hassle in the future? What would a networking interface look like now that would/could work with both systems?

    For everyone that’s starting projects now that need networking, news of something so much better on the horizon is great but stressful. Multiplayer can be so deeply rooted in an application, it’s not something you want to completely refactor in a year.

    How do we create an application now, that is new-networking-ready?

    1. That is an excellent point and I’d like to hear something about this too.

    2. Hi Michael – there will be an alpha version to explore in more detail soon, and beyond that, we recommend using the LLAPI or other UDP-based transport. The API’s will be most similar on day-1.

  11. Great news, and I’d like to hear more about RTS archetype specificity. I am making a RTS right now, but have had to create an authoritative client-server using LLAPI. Unfortunately this will not scale when the number of players or units increases, and I’ve had to assume a low unit pop cap, using my own algorithms which send mostly deltas for moving units.

    My game uses Unity’s lovely pathfinding/flocking, and I also integrated the code Unity released which allows pathfinding on 3D objects generated at runtime. But because Unity’s internal logic isn’t deterministic this means making some sort of more traditional lockstep solution is out of reach right now. There have been deterministic lockstep solutions made with Unity… but not for my requirements, with pathfinding on dynamically generated 3D terrain at runtime!

    For my project, I do not want a dedicated server system. When AOE2HD came out even LAN games were routed through a dedicated server somewhere else… which meant playing a LAN game in a flat in London with a ping of over 200. Matchmaking sure, but dedicated servers hosting games will be too expensive for me as a lone indie dev.

    I’d just like to know if there’s anything you can tell me about how RTS or my specific case will be helped by these changes? I’m trying to make something innovative, but am having to deal with technical compromises I’d rather not have to make. Thanks.

    1. Brandi House

      9月 13, 2018 7:57 pm

      Hi Richard – nothing we’ve shared here is going to be immediately useful in an RTS-lockstep networking archetype. The baseline transport and parallel processing of ECS / Job System can help performance, but the simulation code for an RTS will not be a major focus until we feel great about the “server-authoritative client-prediction” archetype.

      As you mention, strict determinism is a BIG requirement, and it’s something we care a lot about. You’ll see big steps forward towards this over the next year, but depending on the timeline of your game, they may not be soon enough.

      1. Thank you very much for responding so quickly! I am glad to hear there will be progress towards determinism eventually, though I understand client-server model is more popular and a solid choice for many other games, so it makes sense for you to work on that first. If you could release some deterministic feature which would enable lockstep with Unity’s dynamic navmesh magic, that’d be really great!

  12. I am glad that you focus on “perfomance by default” and transparency. In my opinion you are going in the right way. I am sure you are already thinking on it but cross-plataform will be a nice adition!

    1. Brandi House

      9月 13, 2018 7:58 pm

      Thanks Adrian – agreed completely that cross-platform is a critical part of this story.

  13. Nigel Merritt

    9月 13, 2018 3:07 am

    As with the last post about the new networking system, this is entirely focused on games. Unity is increasingly used by businesses for non-gaming applications, many of which will use multi-user. These often cannot be cloud hosted and must be on separate (non-internet) connected networks. To extend on earlier questions, will there be full support for entirely lan based applications? And if I can sneak in another question – proper support for VR based multi-play?

    1. Brandi House

      9月 13, 2018 8:08 pm

      Hi Nigel – in the past we’ve struggled with focusing on solving too many use-cases at once, and the end result is that we often don’t solve any really well. Even games have a huge range of specific needs, so even within these, we’ve narrowed the initial focus to Real-time Multiplayer Session-based games that can use a “Server-authoritative client-prediction” networking archetype. This is certainly very specific, but a lot of the core challenges we solve in this use-case will speed our progress in future use-cases as we move forward.

      Per LAN-based connections, this will definitely be a supported development feature for the networking and server runtime, and I do not know of any reasons it couldn’t work as a production feature long-term. Services like matchmaking and orchestration are developed and designed for the cloud, but these aren’t particularly valuable for LAN-only games/applications anyways.

      VR is unique in that lagged frames and performance are of the highest importance. Locking a frame to wait for a network packet is just a bad idea no matter the connection speed (LAN or Cloud). Most VR multiplayer titles we’ve seen so far use the “server-authoritative client-prediction” model we are working on today – i.e. the game client continues to attempt to move forward with stale data and then corrects if/when incorrect assumptions were made. We’ve seen both DGS and LAN-based titles succeed.

  14. Is support for windows servers somewhere on the road map? I already have a windows infrastructure and that is the OS I am familiar with. So just wondering if that is coming or if it is not even being considered, thanks.

    1. Brandi House

      9月 13, 2018 8:51 pm

      Windows runtime will also support the “headless” player and will benefit similarly from some of the optimizations in progress today. However, cost reduction in a cloud environment by using Linux is great enough that our self-serve environment will focus on Linux for quite a while.

      We want to offer hosted servers at the lowest possible costs, and that will remain a top priority long-term.

  15. Hi,
    What percentage of the code will need to be changed to switch from unet to the futur API ?
    I am very slow dev, maybe when futur API comes my project “allmost” complete will not be really finished.
    will i need to change everything to make my project work when the next multiplayer code come ?

    1. Brandi House

      9月 13, 2018 8:14 pm

      If the majority of your code is written and working, it’s better to move forward as-is on 2018.3/4 LTS. This version of the API’s will be supported for at least 2 more years (critical fixes), and if you are relying on the Relay, it will remain live until 2020 or later. We’ll ensure there’s a sufficient migration path before that date.

      1. This answer sounds like there will be no nice solution to port existing UNET projects to the new networking library. If this is the case I think it’s very disappointing. Because it’s a punch in the face for projects who are created with existing UNET but still want to keep close to latest unity versions AND want to port to the new networking stack (for good reason).

  16. Joshua Rosen

    9月 12, 2018 7:39 pm

    As part of the effort to make the Unity dedicated servers run better on Linux, I’d love to see IL2CPP support for Linux builds. I’ve heard Unity engineers say in the forums that was put off because the Linux user base is very small, but that of course isn’t the case when you included dedicated servers. If you agree, please vote on my Unity Feedback submission https://feedback.unity3d.com/suggestions/il2cpp-for-linux-standalone-especially-useful-for-cloud-server-efficiency

    1. Brandi House

      9月 13, 2018 8:52 pm

      This is in the Roadmap! Linux support is increasing drastically at Unity today due to Server runtime requirements as well as non-games requirements.

      1. Joshua Rosen

        9月 18, 2018 9:05 pm

        Good to hear! Thanks for the reply. Looking forward to hearing more news on this :)

  17. An out of the box patching system would be awesome. I feel like that goes hand in hand with multiplayer games.

    1. Brandi House

      9月 12, 2018 8:46 pm

      Do you mean client or server patching, or both?

      We do have plans to support development and production versions of fleets, and we will figure out a good pathway for promoting a new server build to the production fleet. Sometimes when an update requires a change to both client and server, we will run into server compatibility constraints, so we will need an answer in both matchmaking and orchestration to ensure clients are only connected with server builds that support them. These are all somewhat complicated challenges, but they are on our radar!

      Client patching is largely determined by the platforms themselves. It’s unclear how much we at Unity can help improve this process, but we’re open to ideas!

      1. Sorry I should have been more specific. Desktop client patching would be amazing. I do understand that most games go through a platform such as steam or origin that provide the ability to update a game, but there are cases where a developer might choose not to. An out of the box desktop patching system someday would be pretty great!

  18. Joshua Rosenberg

    9月 12, 2018 2:38 pm

    Make sure you provide as many visual tools for non programmers as possible. i.e. a system where with nodes you connect sources of data (ie. player inventory, score to a user blob,) and another node connection taking that score and connecting it with a global ranking system.

  19. Robert Cummings

    9月 12, 2018 2:37 pm

    Hi Brandi and team!

    Great to know your plans. Can I help? Want to add it to my game in development. It might be difficult for you as it’s for console and not sure where support is there at the moment :)

    Thank you for the detail in the blog, it’s really nice that you go into detail, and I think we all want that.

    1. Brandi House

      9月 12, 2018 8:59 pm

      Thanks Robert! The very early alpha versions of this tech support desktop (PC/Mac with Linux DGS), and we’re hoping to provide updates as soon as possible to include mobile and console. We’d still love your feedback as soon as it makes sense to you, and we will be in alpha soon.

  20. Richard Kopelow

    9月 12, 2018 2:26 pm

    What if I want to build a client hosted game? Something small like a game jam project or local party game that I don’t want to be spinning up cloud hosting for. Given Unity is moving toward hosted game servers, how easy will it be in with the new architecture to locally host games?

    1. Isaac Surfraz

      9月 12, 2018 4:08 pm

      This is my main concern too, would be interested on what the answer is…

      1. Jérémy CROMBEZ

        9月 12, 2018 10:22 pm

        Unity being used a lot by small indie game developers, i’m also curious what is the plan for P2P.
        HLAPI is being deprecated and has been abandonned for a few years already, and the new system is focused on dedicated server, i feel like there will be a few more dark years for those games.
        I hope they just don’t hope everyone use the over expensive Photon solution…

    2. +1 for this

      It is crucial to still be able to do client-hosted games. Partly because it’s useful for development purposes, but also because sometimes it’s the best option for some games.

      I’d just like to be reassured that there will be no obligation to use Multiplay or Google Cloud or any of that with this new networking API, and we will remain free to choose whatever approach suits us best

      1. Brandi House

        9月 12, 2018 5:23 pm

        In this post, we didn’t talk much about anticipated development workflows, but we do know that local and LAN support are important for speed of iteration. This use-case will be supported regardless of where and how you host your game. You may host your game on any servers of your choosing, and we’ll provide fast workflows, fast set-up, and cost optimizations if you choose to use Unity’s orchestration and Matchmaking services.

        Production client-hosted games still fall into the P2P model that we’ve seen many/most games fail to succeed with, so it’s not an immediate priority for us to create a new Relay service to support it. However, there will be nothing in the networking and runtime preventing you from finding other pathways if you are certain this is the best option for your game.

        1. It is vitally important that players have access to the server software. One day, both Unity Technologies and Multiplay will no longer exist, and when that happens people should still be able to play their multiplayer games. Dependence on a third party for server hosting like this makes me really nervous.

          Unless I’m misunderstanding what is meant by the DSG model? (I hope I am)

        2. Brandi House

          9月 12, 2018 8:52 pm

          When you say “server software”, I’m assuming you mean the server runtime (i.e. the code running on a server). The server runtime is completely in the developers’ control – you can choose to use Unity headless runtime, or you can even create a custom server runtime. If at any time, Unity’s hosting service is no longer sufficient for your needs, you can take that runtime and host it wherever works best for you.

        3. Andrew Ackerman

          9月 13, 2018 1:37 am

          There’s a huge difference between P2P multiplayer and client-hosted dedicated server software. Without support for the latter, a lot of games will die due to official servers going down, dropping support, etc. And there are plenty of examples of successful games with that model, like ARK, Minecraft, Garry’s Mod, 7 Days to Die… hell, even the unofficial WoW hosting servers were crazy popular before Blizzard shut them down. There are much bigger things that make a game is unsuccessful than whether the dedicated server software is cloud-hosted or local-hosted.