Laser Matrixにおける技術的およびパフォーマンスの問題を解決する
マリウス・トールヴァルドセン、マーチン・シヴェルトセン、シンドレ・アスキム・グロンヴォルが2016年にBreachを設立し、没入型ゲーム、XR体験、3Dシミュレーションを作成しました。過去9年間、請負スタジオはXRソリューションを提供しながら、自社のゲームも開発してきました。2024年、彼らはアイデアをブレインストーミングし、新しい内部プロジェクトを探しながらプロトタイピングを始めました。1つのゲームコンセプトはすぐに制作に入ってレーザー・マトリックスとなりました。
このタイトルは、フィットネス、楽しさ、未来的な挑戦が交差する混合現実パズルアクションゲームです。プレイヤーは光を使ったパズルを解き、移動するレーザーを避け、機敏さと知恵を使ってレベルを解除できます。
今日、チームはレーザー・マトリックスをメタクエストとAndroid XRで出荷しました。私たちはBreachのエンジニアリングディレクターであるアンドレアス・ウェイビーと、ゲーム開発者の1人であるジョナサン・ヨルゲンセンと一緒に座り、両プラットフォーム向けにゲームを構築することや、技術的およびパフォーマンスの課題をどのように克服したかについて話し合いました。
レーザー・マトリックスとは何ですか？
アンドレアス：レーザー・マトリックスはVRの動きのアクションパズルゲームです。非常にアーケード的で、あなたのリビングルームを素早く巧みに動き回らなければならない危険な迷路に変えることができます。
メタクエストとAndroid XRの実装プロセスはどのように機能しましたか？
アンドレアス：プロジェクトの最初からメタクエストとAndroid XRを同時に実装することはありませんでした。プロトタイプは最初はメタクエスト専用で始まりました。私たちはそのプラットフォームで広範に作業してきたので、すぐに立ち上げることができました。Android XRはこのプロトタイプを始めたときには存在しなかったので、開発プロセス中にポーティングを行うことになりました。
ジョナサン:私たちは、Metaの「ビルディングブロック」ツールを使ってラピッドプロトタイピングを始めました。それにより、コンセプトの検証がより便利になりました。最終的に、クロスプラットフォームXRを目指すことに気づき、ゲームをよりプラットフォームに依存しない方法で構造化することにしました。コアゲームプレイはプラットフォーム特有の機能に依存しないため、クロスプラットフォームに移行するのは簡単でした。
OpenXRでのハンドトラッキングを実装する際にどのようなステップを踏みましたか？
ジョナサン:私たちはOpenXRランタイムからリアルタイムトラッキングデータを読み取りました。データは抽象化レイヤーを通じて処理され、生データが位置と回転に変換され、それがハンドメッシュに適用されます。これらのハンドメッシュは、Unityのビルトインインタラクションシステムとインターフェースし、指で何かに触れるといった一般的なことのためのユーティリティを提供します。そして、最後に私たち自身のゲームプレイレイヤーがその上にあります。
すべてはその生データからの多層的な抽象化に関するものです。多くのXRゲームは似たようなニーズを持っているため、私たちはできるだけ安定した既存のソリューションを使用し、それらをきれいに結びつけるようにしました。Laser Matrixの場合、ハンドトラッキングに関して非標準的な側面はあまりありません。
チームはどのような技術的課題に直面しましたか？
アンドレアス：シーンと使用されるコンポーネントに関しては、かなり標準的なOpenXRのセットアップです。私たちは、手がトラッキングを失ったり得たりする瞬間に関する問題を回避し、そのフレームで異なる位置にスポーンする必要がありました。ある時点で、プレイヤーはハンドトラッキングを失い、それが原因でライフを失いました。
ジョナサン:ハンドトラッキングを考慮した設計は、より大きな課題の一つでした。手の異なる接触点がいくつかの問題を引き起こしました。ボタンを押すような通常の遅いペースのUIインタラクションには、より簡単です。しかし、レーザーマトリックスでは、常に体と頭を動かしているため、カメラベースの手のトラッキングの精度が低下する可能性があります。
アンドレアス：ゲームプレイの外のUIでは、レイキャスティングを使用するのではなく、指で触れる必要があるボタンを実装しました。私たちの経験では、手のトラッキングを使用したレイキャスティングは、素晴らしいプレイ体験を得るには十分に正確ではないため、これが役立ちました。
ジョナサン:「フラットスクリーン」ゲームでは、開発者はマウス、キーボード、コントローラーなどの入力の使用を制限できます。XRは異なります。なぜなら、ゲームは物理的な手を本当に止めることができないからです。例えば、レーザーマトリックスメニューのボタンはかなり平らで、手をボタンの奥まで突き刺すことができます。これは必ずしも設計する必要のないインタラクションであり、実際に何が起こるべきかは不明です。それは有効なボタンプレスですか？一般的に、より伝統的なユーザーインターフェースパターンをXRに翻訳すると、いくつかの興味深い影響があります。
チームはどのようなパフォーマンス関連の問題に直面しましたか？
アンドレアス：私たちの主なパフォーマンス問題はグラフィック面にあります。最初から、透明度のオーバードローとのバランスを見つけることが重要です。これは現在のゲームデザインにおける最大の課題の一つです。なぜなら、これらのボックスにアウトラインだけを使用すると、上や下を見たときにそれらがどこにあるかを見ることができ、何かと比較することができるからです。しかし、真っ直ぐ前を見て、壁からの距離や触れずに手をどれだけ伸ばせるかを理解しようとすると、それはより難しくなります。
ユーザーが同時に全体の迷路を見ることができ、戦略的な位置決定を行えるようにしたいので、透明度の解決策または代替案が必要であり、どちらもGPU集約型です。
ジョナサン:私たちのいくつかの解決策は、ゲームの最終的なビジュアルに影響を与えました。例えば、ゲームエリアの外側の黄色い境界線を変更しました。以前は、壁全体を覆う透明な黄色の色相がありましたが、エッジのみに減らし、完全に透明になるグラデーションフェードにしました。ゲームの境界線はプレイ中常に表示されるため、これによりオーバードローコールの数が一貫して減少し、フレーム時間の主な要因の一つとなりました。
プレイヤーがゲーム内で移動する際に避けようとしている赤いレーザキューブも見ました。それらの表面には正方形のグリッドパターンがあります。黄色の境界線キューブと同じアプローチを適用し、再度オーバードローを減らすことができるかもしれません。グリッドセルのエッジのみが完全にレンダリングされるため、セルを大きくし、平均してより多くの表面が完全に透明になるようにしました。
読み込みに関連するパフォーマンスの問題もありました。レベルが開始されるたびに大きなスパイクが発生しました。最初は、一般的にレベルの読み込みに関連していると考えていました。レーザーマトリックスレベルを読み込むということは、多くの異なる要素をスポーンさせる必要があることを意味します。しかし、原因は特に音楽でした。プロファイリングを通じて、システムが各レベルでオーディオを再読み込みしていることを発見しました。代わりにアプリケーションと一緒に音楽をプリロードするように設定したところ、スパイクが目立たなくなりました。
アンドレアス：私たちのパフォーマンスの問題のいくつかは、プロトタイプを製品ゲームに変えたために発生しました。システムを再構築すべきでした。
ビルド中に役立ったUnityのツールや機能は何ですか？
アンドレアス：Unityの利点は、1つのアセットと1つのコードを作成し、最初から複数のプラットフォームで機能させることができることです。
VFXグラフは素晴らしく、アーティスティックなセンスがない製品オーナーが視覚効果のイメージをスケッチすることを可能にしました。そこから、私たちのテクニカルアーティストと開発者がそれを磨きました。
ジョナサン:Shader Graphはゲーム制作に非常に価値のあるツールでした。ゲームの3D要素のほとんどは純粋なシェーダーです。いくつかの立方体、手、ボタンを除けば、このゲームには実際の3Dモデルはほとんどありません。
XRデバイスシミュレーターも多く使用されました。XRで作業する際、テストは長期的にはかなり身体的で負担がかかることがあります。すべてのステップ – 立ち上がる、ヘッドセットを装着する、動き回るなど – の間に、時間が本当に積み重なります。シミュレーターを設定し、マウス入力を使用してインタラクションを刺激することで、多くの時間とフラストレーションを節約しました。
アンドレアス：最初からXRデバイスシミュレーターが利用できたので、孤立してテストしやすい方法で新機能を開発したいと思いました。これにより、最初からよりモジュール化され、テスト可能なシステムを書くことが促され、コードの品質も向上しました。
ジョナサン:Unityプロファイラーも、パフォーマンスのスパイクがどこから来たのかを検出するのに重要でした。例えば、私が言及したオーディオ読み込みの問題では、プロファイラーがスパイクを特定し、その正確な時点でトリガーされた呼び出しを特定するのに役立ちました。この種の情報は、解決策を実装する際にどこから始めるべきかについて明確なヒントを与えることが多いです。
Unity 6の新機能やアップデートの中で最も有益だったものは何ですか？
ジョナサン:私たちはかなり多くのターゲットに対して、異なるコンテキストでビルドを行います。クロスプラットフォームで行く際、プラットフォーム固有の機能やサービスのために異なる構成を持つ必要があります。そのため、Unity 6でビルドプロファイルを持つ能力は、異なるプラットフォームに合わせてビルドを調整することを可能にしました。これを手動で行うのは面倒で、エラーが発生しやすいです。
どの主要なパフォーマンスベンチマークを持っていましたか？
ジョナサン:パフォーマンスの問題を指摘したとき、特に動きの病気のためにXRでは大きな問題であるため、平均fpsを測定し、フレームドロップを探しました。快適かどうかの明確な目標があります。
異なるキューブシェーダーのしきい値を調整することで、約10%のFPSを得ることができました。ゲームの最大数のキューブを描画したテスト環境でゲームをプロファイリングしました。これにより、テストのための非常に固定された信頼できるコンテキストが提供されました。
アンドレアス：パフォーマンスのために、私たちのハードリミットはMeta Quest 2で72 FPS、Meta Quest 3で90 FPSです。平均フレームレートの目標には達していますが、ユーザーが低い結果を得る状況を作り出すことができます。これは、最悪の場所に陥る可能性がある非常に特定のケースです。
ジョナサン:プロジェクトとチームのレベルでは、ここ数ヶ月で私たちの反復時間は非常に効率的になりました。会社として、私たちは品質保証プロセスを成熟させ、自動化スタックに結びつけ、現在私たちのフィードバックと修正サイクルは非常に速いです。私たちは、タスクのバックログが積み上がったり制御不能になったりしないように、問題に迅速に対処できています。
開発中にチームが異なることを望んでいたことはありますか？
アンドレアス：OpenXRをもう少し早く使い始めるべきでした。プロジェクトの初期に、プレイエリアの形状とサイズを定義するためにMetaのルームマークアップ機能を使用することを計画していました。それは機能しましたが、私たちが求めていたゲームプレイ機能を提供せず、また、私たちがまだ良い解決策を持っていないデザイン上の課題を開くことになりました。私たちは、ルームスキャンの議論中にそれに気づきました。そのシステムは早くに廃止すべきでした。なぜなら、私たちはそれを解決しようとしすぎたからです。さらに、振り返ってみると、プロトタイプコードが製品コードに進化したときに、そのシステムがデザインに役立たなくなったことを認識していれば、時間を節約できたでしょう。
Unityで作成されたプロジェクトについてもっと読むには、リソースページを訪れてください。