サバイバルキッズにおけるスプリットスクリーンとゲームシェアネットワーキング
この夏、Unityは、パブリッシャーのパートナーであるKONAMIと密接に協力して作成した最初のゲームをリリースしました。サバイバルキッズは、初日からNintendo Switch™ 2タイトルとして発売されたクラシックな子供向けゲームの楽しいアップデートです。
ゲームは完全にUnity 6上で構築されているため、開発チームは新しいプラットフォームでゲームを発売するために新しいソフトウェアを使用していました - これは大きな挑戦でした。その上、ゲームはさまざまなネットワーク構成で楽しむことができるため、プロジェクトに取り組んでいる小さなUnityチームは、これらのオプションをサポートする堅牢なマルチプレイヤーアーキテクチャを構築する必要がありました。
サバイバルキッズのマルチプレイヤーネットワーキングストーリーの最初のエピソードをチェックしてください。ゲームのネットワークアーキテクチャの基本がどのように結びついたかを共有します。この投稿は、チームがゲームの画面分割とNintendo Switch 2のGameShare機能をどのように構築したかを示すためにこの基盤を拡張します。
Nintendo Switchは任天堂の商標です。
ゲームのネットワークアーキテクチャの多くの問題を解決した後、私たちは画面分割をどのように行うかを考え始めました。これはNetcode for Entitiesでは標準で提供されていません。これは異なる挑戦でした。画面分割では、1人以上のプレイヤーが必要ですが、それらのプレイヤーはクライアントに属しています。
Netcode for Entitiesは、クライアントごとに1人のプレイヤーがいることを前提としています - 別のゲームがあり、別のコンソールが接続されている場合、それには1人のプレイヤーがいます。それが変わり、実際に2人または3人のプレイヤーがいる場合、各個別のプレイヤーの入力を送信する方法はありません。それらは1つとして送信される必要があります。
私たちは、誰にも見えない仮想入力プレイヤーを効果的に作成しました。それは完全に見えませんが、最大4人のローカルプレイヤーのすべての入力を収集します（最終的には4人の画面分割は行いませんでしたが）。それは入ってくるすべての入力を管理し、その後、毎フレームすべての入力をサーバーに送信します。
ゲーム内では、プレイヤーは自分の入力を管理しません。想像上の仮想入力プレイヤーが、フレームの入力が何であるかを教えます。以前は、Netcode for Entitiesは、プレイヤーが自分の入力を取得し、その入力を使用してすべての動きを行う責任があると仮定していましたが、ここでは動きを行わず、他のすべてのための入力を保持する別のプレイヤーがいます。
画面分割はネットワークの観点からの主な課題でした。複数のカメラの問題を避けるために、最初のプレイヤーがいる間にカメラがそのままの状態で、周りを走る二人目のプレイヤーを用意しました。それはすぐにまとまりましたが、次に直面した問題は、二台目のカメラをどう設置するかということでした。画面の左側に一台のカメラを置き、右側にもう一台のカメラをどうやって保つか？UIの問題も解決しなければなりませんでした。なぜなら、あるプレイヤーだけが見ることができるUIがかなりあるからです。例えば、あるプレイヤーが丸太の前にいる場合、"この丸太を拾うにはXを押してください"という小さなプロンプトボタンが見えますが、もちろん他のプレイヤーにはそれを見せたくありません。
他のプレイヤーが近くにいるときにUIを隠す方法を考えなければなりませんでした。それにはレイヤーを使用しましたが、私たちの修正はネットワークよりもUIに関連していました。私たちは、より良いゲームプレイ体験のために、最終的にゲームを二人の画面分割プレイヤーにロックしたいと決めました。大画面であっても、ローカルプレイヤーは二人だけです。内部的には画面分割で四人できましたが、パフォーマンスのストレステストのためにそれをしばらく続けました。なぜなら、各プレイヤーが少しずつ処理を追加し、レンダリングを増やし、シミュレーションするプレイヤーがもう一人増えるからです。
Nintendo Switch 2の開発中の機能の一つはGameShareです。実際には、別のコンソールにビデオフィードを送信しています。実際には、ネットワークの観点からの画面分割です。ただし、システムは画面にレンダリングするのではなく、別のコンソールに一台のカメラを送信します。
私たちの四人用画面分割は、GameShareモードへのアプローチの基盤でした。パフォーマンスが問題ない限り、好きなだけプレイヤーを接続でき、ビデオをそのコンソールにストリーミングできます。四人用画面分割を行いたくなかった主な理由は、実際には画面サイズに関するものでした。巨大なテレビがない限り、ウィンドウを見るのは本当に難しいですが、自分のコンソールがあれば、ビデオをそこにストリーミングできます。
私たちは、GameShareで追加の三人目のプレイヤーをサポートできるように、二人用画面分割モードから差別化するために努力しました。ホストと二人のゲストを持ちながら、プレイヤーに素晴らしい体験とスムーズなパフォーマンスを提供できます。私たちはその基準を下げるつもりはありませんでしたが、画面分割アーキテクチャを使用してGameShareを動かすことができました。
私たちが追加した本当に役立つ機能の一つはデバッグコマンドでした。私たちは開発者用メニューを持っているので、ボタンを押してメニューを呼び出し、そこにコマンドを入力できます。これは便利で、たくさんのデバッグ作業を実行できました。最終ゲームからはすべてコンパイルされているので、もちろん誰も購入してプレイする最終ゲームではそれを行うことはできません。しかし、画面分割のモードの1つでは、メインプレイヤーを複製できることがありました。これにより、1つのコントローラーで両方のプレイヤーを操作する画面分割が可能になりました。これは、たくさんのコントローラーを用意することなく画面分割をテストする素晴らしい方法でした。これにより、テストが容易になりました。
画面分割の設定は、私たちが行った通常のネットワークコードも効果的に実行しました。プレイヤーが互いに分離されているため、サーバーはオンラインゲームがどのように機能するかを示す情報を送信します。しかし、別のクライアントにプレイヤーを接続せずにマルチプレイヤーモードでコードが機能するかどうかをテストすることも可能です。エディターで別のコントローラーを使って画面分割モードを起動してそこでプレイします。通常のオンラインゲームのプロキシとして画面分割でコードをテストできるため、新しいビルドを行う必要はありません。
私たちが本当に便利だと感じた別の2つのUnityツールがありましたが、プロジェクトの最後までそれらを使用しませんでした。Unity 6には、新しいマルチプレイヤー再生モードツールが含まれており、別のプレイヤービルドなしでテストできるようになります。
エディターを開くと、アートやその他の情報が非常に多いため、クリーンなプレイヤービルドを行うのに1時間以上かかります。リモートプレイヤーでコードをテストするには、少なくともそのくらいの時間を待つ必要があります。これは特に反復作業には適していません。しかし、マルチプレイヤー再生モードを使用すると、エディターの別の仮想バージョンのように別のウィンドウを効果的に立ち上げて接続できます。
エンティティ用のネットコードにも、悪いネットワーク接続をシミュレートするための再生モードツールがあります。特定のレベルのpingを指定してシミュレートできます。たとえば、300ミリ秒のping、空港で電話をノートPCに接続してゲームに接続する友人とプレイする際の非常にひどい往復をシミュレートします。その後、エディターでそれをテストして、どれだけ遅延があるか、または不安定であるかを確認できます。時々、データを失いパケットをドロップしているネットワーク接続ではそれが機能しませんでしたが、私たちはそれを簡単にシミュレートできました。
このテストは常に行われていました。しばらくの間、シミュレーターをオフにしてエディターでプレイすることを許可しないというルールがありました。すべてのプレイヤーは、完璧な接続でプレイすることはないため、何らかのシミュレートされた遅延でプレイする必要がありました。そのようにして、私たちは超高速のオフィスブロードバンドが代表的であると自分たちを欺くことは決してありませんでした。
結局、すべてのテストが実を結びました - 私たちは、非常に異なるネットワークとマルチプレイヤー設定で60 fpsのスムーズでパフォーマンスの良いゲームを提供することができました。ゲームのリリースから数週間が経ち、プレイヤーはロビーやリレーを通じてオンラインでの交流を続けており、家庭のネットワーク条件に関係なく、シームレスで堅牢なゲーム体験を楽しんでいることを願っています。
私たちのブログシリーズの他のエピソードを深く掘り下げてサバイバルキッズの制作をチェックしてください:
- "グラフィックスとレンダリングのヒントサバイバルキッズ"
- "レベルレイアウトと地形のワークフローサバイバルキッズ"
- "サバイバルキッズのマルチプレイヤーネットワークインフラの内部"
Unityで作られたプロジェクトについてもっと知りたい場合は、リソースページを訪れてください。