コネクティッドゲームの開発に伴う課題の解決に向かう取り組みの一環として、Unity がまず注力したのは、リアルタイムな多人数参加型ゲームです。Unity は、この分野を「民主化する」ための過去の取り組みの中から多くのことを学びました。何よりもまず、優れた新技術を構築するためには、ひとつひとつのステップにおいて皆様のフィードバックが必要です。ですから、新しい取り組みを開始するにあたっては、皆さまにもフィードバックを寄せて新技術構築のプロセスにご参加くださることを願っています。同時に Unity からは、頻繁な更新と高い透明性を提供してゆくことをお約束します。
先日の UNet の廃止に関するブログ記事の掲載後に寄せられたフィードバックから、今後は私たちの計画に関する情報をより詳しくご提供する必要があるということが明らかになりました。これを踏まえて、本記事では、私たちの長期的なビジョン関してと、今秋公開の最初のリリースについて、両方の情報をご紹介していきたいと思います。
長期的なビジョン
「苦労せずにハイパフォーマンスを実現」 ― これは、Job System(マルチスレッド処理)、Burst コンパイラー(Unity ゲームコードに特化)、Entity Component System(データ指向のゲームコード)など、現在進行中のいくつかの機能の背後にあるコンセプトです。これらの機能を組み合わせれば、パフォーマンスを桁違いに向上させる大幅な改善を実現することができます。
こうした各種機能が共に開発されることで、Unity は、スケールに関わらず実質的にどんなゲームにも対応可能となります。大きなマップも、多数の動的オブジェクトや AI も、そして多数のプレイヤーのネットワーク化も すべてが実行可能になります。
この新しい枠組みの中では、ネットワーク化された環境におけるコンポーネントの有効化が格段に行い易くなります。さらに、高度に構造化された ECS のデータによって、デルタ圧縮や補間など、高度なシミュレーションのための洗練されたソリューションが実現可能になります。
現在、以下の基本方針を念頭に置き、新しいネットワーキングスタックの構築を進めています。
短期的な計画
近い将来のリリースに向け、新しいネットワーキングスタックをゼロから構築しています。手始めは、ごく最小限のトランスポート層(プレビューパッケージとしてソースと共に提供される UDP ベースの送信/受信機能)の開発です。デフォルトで含まれる API は、Job System と互換性があり、ECS ベースのゲームに適合するように最適化されたものとなる予定ですが、いずれも必須とは考えていません。この第 1 段階のリリースは、必要最小限の機能のみを備えたものになります。実際に皆様のゲームに使用するに足りるものにするには、今後追加して行かなければならない重要な要素(信頼性、シーケンシングなど)が数多くあります。
これと並行して、新しい Transport の上にビルドされた、完全なソースコードを含む FPS サンプルゲームの公開も予定されています。これには、クライアント側予測・補間・デルタ圧縮用の、製品版への使用に耐えるクオリティのサンプルコードも含まれます。 他のアーキタイプに関しても、後に第 1 段階のリリースが予定されています。
長期的なビジョン
リアルタイム・マルチプレイヤーのトポロジーを分析した結果、リアルタイムなマルチプレイヤー(多人数参加型)ゲームに最善の選択肢は専用ゲームサーバー(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 デベロッパーの皆様は以下の付加的なメリットも得られます。
短期的な計画
先週公開された Open Match v0.1 は、今すぐご利用いただけます。Unity は今後も引き続き、Google やコミュニティの皆様と共に、機能と品質の両面においてこのソリューションを改良すべく尽力してまいります。
これと同時に、マネージド型マッチメーカーの最初のバージョンも近い将来に Unity のエコシステム内にリリース予定となっています。これは、プレイヤーカウント設定、サーバー割り当てとのシームレスな統合、クライアントライブラリのパッケージ、自動デプロイ機能などを提供します。最初のバージョンでは、設定のプレイヤーカウント(人数)に達するとサーバーがシームレスに割り当てられ、ゲームのクライアントがそのサーバーに接続されます。
長期的なビジョン
専用サーバーをホストする場合に一般的に聞かれる最も大きな懸念事項は、コストに関するものです。Google Cloud のようなパブリックなクラウド環境内におけるコストは、仮想マシンの仕様、使用時間、使用されているネットワーク回線の容量(送信/egress)、OS のライセンス料の組み合わせによって決まります。コストを削減するには、以下を行う必要があります。
「プレイヤーの需要を満たすためにゲームによって必要とされる時にのみサーバーの起動と割り当てを行う」方式のサーバーオーケストレーションとマッチメイキングによって、
直前のフレームから変更のあった最も関連性の高いデータのみを送信する素晴らしいシミュレーションコード(デルタ圧縮など)で、
これら 5 点のうち最後の 4 点のためのソリューションについては、すでにご説明しました、そしてサーバーランタイム消費プロファイルも、現在、Unity が非常に注力しているもののひとつです。私たちは、新しいパッケージ管理のシステム(パッケージマネージャー)が完全に実装されれば、デベロッパーが Unity をサーバーランタイムとしてごく小さなプロファイルで実行できるようになると考えています。この最小限のプロファイルによって、ゲームの目的に合わせて必要なパッケージのみを含めることが可能になります。
短期的な計画
現在私たちは、Unity Linux ランタイムの「ヘッドレス」なバージョンの最適化に集中的に取り組んでいます。具体的には、たとえば「ヘッドレス」モードで意図せず実行されてしまっているレンダリングやアニメーションやオーディオの再生をすべて見つけ出すなど、容易に行える方法でこれを行っています。私たちの目標は、現行の「ヘッドレス」バージョンの Unity で、メモリとビルドサイズと CPU 消費を最小限に抑えながら安定性と稼働時間を向上させることです。
バージョン 2018.3 では、デベロッパーのワークフローが改良され、すべてのスタンドアロンプレイヤー向けの新しいオプション「Server Build」が追加されました。これを使用するとデフォルトがヘッドレスになり、サーバースクリプトロジックを分離するための新しい UNITY_SERVER シンボルが使用できるようになります。