6 人のチームが『LEGO® Builder's Journey』をわずか 3 か月で Apple Vision Pro に移植した方法

Apple Arcade で最初にリリースされた Light Brick Studio の没入型マルチプラットフォームパズルゲーム『LEGO Builder's Journey』は、着実に勢いを増しています。空間コンピューティングの新時代を受け入れ、このタイトルを Apple Vision Pro に移植した Light Brick Studio が学んだこととは？

混合現実（MR）プロジェクトに初めて取り組むスタジオが、どのようにして他のプラットフォームでのゲームプレイ体験を維持しつつ、Apple Vision Pro の没入感を実現したのでしょうか？

レゴ®ブロックは実際の物理的な製品であるため、Light Brick Studio は、プレイヤーと室内のゲームプレイ要素の相互作用体験を作り出すことの難しさを認識していました。このゲームの Apple Vision Pro 版をリリースするにあたり、時間的な制約もありました。同チームは、2D インターフェースの他のプラットフォームへの移植を 1〜2 か月で完了させていたものの、空間コンピューティングという新たな領域では、3 か月というタイムラインはギリギリのスケジュールでした。

新しい次元をナビゲート

「ゲームとゲームプレイデザインに対するプラットフォームの限界が分かれば、ほぼどんな体験でも作り出すことができます」と、Light Brick Studios でテクニカルリードを務める Mikkel Fredborg 氏は説明します。

チームにとって、ゲームを visionOS に移植することは、「ゲームをスムーズに実行させ、機能を最大限活用するという技術的な挑戦」でした。これは、元々平面だった UI 要素を部屋の中に配置するためのユーザーインターフェース（UI）の全面的な再設計など、複数の技術的な修正を実装する必要があることを意味しました。また、チームはレンダリングツールやメソッドをアップデートし、最終製品のビジュアル品質と没入感を実現する必要がありました。Unity と RealityKit 両方のシステムのバランスを同時に取らなければならないことは、パフォーマンス最適化のさらなる障壁となりました。

「これまでにもさまざまな移植作業を行ってきましたが、Apple Vision Pro は今までのプラットフォームとはだいぶ異なるため、今回が一番大変でした」と、Light Brick Studio のマネージングディレクターである Karsten Lund 氏は言います。「我々が期待されていたのは、どこまで体験を向上させられるかということだったのですが、非常にうまくいきました」

成果

• Apple Vision Pro 向けにゲームの 80 のレベルと 60,353 個の LEGO ブロックを 100 日未満で構築
• Unity PolySpatial チームのサポートにより、開発の遅れを数週間短縮
• すべてのゲームプレイエリアをそのまま維持しつつ、ゲーム全体の流れは変更せずに特定のパフォーマンス最適化のみを実施
• プレイヤーのゲーム進行に応じて没入感が深まるオープンな混合現実（MR）スタイルで、スムーズな移行を実現

Nintendo Switch は任天堂の登録商標です。

UIとゲームプレイデザインの再構築

『LEGO Builder's Journey』は最小限の UI で成り立っており、セーブしたゲームのロードやレベルの再スタートなどのアクション用のボタンは多くても 20 個しかありません。そのため、UI の再構築は多くの他のゲームよりも負担の少ない作業でした。Unity 上で UI の再設計を行い、ゲームオブジェクトにコライダーをアタッチして、visionOS のデザイン言語を模倣しながら、入力が適切に機能するようにしました。

また、チームは体の動きの柔軟性を考慮する必要がありました。UI を除いたゲーム内のすべての要素が、レゴ®デジタルデザイナーというツールを使って、LEGO ブロックから作られています。チームは常に 3D 空間を 2D サーフェス上でシミュレートしようとしてきましたが、Apple Vision Pro の場合、プレイヤーがどこにでも移動できるということを考慮する必要がありました。完全な 360 度体験を実現するため、チームはモデルジオメトリに穴があったりしないよう、特定のアングルからのみ見ることを意図して設計された既存モデルを再構築しました。また、ドローコールを減らすため、複数のメッシュを結合して単一のゲームオブジェクトにまとめました。

Fredborg 氏は、「私たちは、プレイヤーが周囲を歩き回れることを考慮し、モデルの 360 度最適化を行いました。ゲームにブロックをインポートした際、内部のジオメトリをすべて取り除いたので、見ることがない内部のディテールもすべて取り除きました。私たちは、社内で使っていた自動化ツールを調整して、完全なシミュレーション体験で機能させることができました」

Bounded モードでの配置管理

初期段階で、チームは定義されたボリューム内で作業するという制約がある Bounded モードでデザインを行うことを決定しました。そのボリュームの範囲外で作業しようとすると、要素は切り取られ、見えなくなってしまいます。チームは、プレイヤーが何らかの操作を行わない限り、プレイヤーの頭、目、手の位置や向きに関する情報を提供しない Bounded モードの制約を受け入れることにしました。プレイヤーが指でつまむジェスチャーをすると、ゲームは手の位置と相互作用中のオブジェクトを認識します。指でつまむジェスチャーが終了すると、情報も終了します。その意味では、プレイヤーが画面をタッチしている時だけ情報が伝わるタッチスクリーンに似ています。

「私たちはプレイヤーが何を見ているか分からなかったため、これは大きな変化でした。当社のゲームプレイではブロックを選択するのにブロックを見る必要があるため尚更です」と Fredborg 氏は言います。「こういった制約をすべて解決した後は、非常に上手く動作し、システムにも適合しました。この方法での操作は、全体的に一貫したユーザー体験につながるため、最終的にとても良い結果を生み出しました」

MaterialX シェーダーの調整

『LEGO Builder's Journey』の初期バージョンでは、チームは Unity の軽量レンダーパイプライン（LWRP）のカスタムバージョンを使用していましたが、その後 Xbox および PlayStation への移植にあたり、HD レンダーパイプライン（HDRP）に移行しました。Apple Vision Pro では、まずすべてをユニバーサルレンダーパイプライン（URP）と Shader Graph ベースに変換し、その後 Apple の RealityKit に移行する必要がありました。

そのために、Shader Graph で作成されたシェーダーを RealityKit で読み込める MaterialX シェーダーに変換しました。しかし、ここでチームは問題に直面しました。結果が十分に最適化されておらず、当初の想定よりも多くの作業が必要であることが判明したのです。

チームは手作業による最適化を計画しましたが、スケールに対応するには、プロセスの自動化が必要であることが分かりました。シェーダーに手動でパッチを当て、重複したコードを見つけ、そのコードのセクションを置き換えることで、コードが一度だけ実行されるようにしました。「スムーズに動作させるのに非常に苦労しました」と Fredborg 氏は言います。「ただ、PolySpatial チームは最適化に向けて取り組み、素晴らしい仕事をしています」

最適なライトの特定

ゲームの納期までの期間が短かったため、チームはすぐにソリューションを見つける必要がありました。「我々はゲームの現実感を高めつつも、リアルタイムライトとシャドウをサポートするソリューションを見つける必要がありました」と Fredborg 氏は述べます。「これは大きな変化の 1 つでした」

当初、Apple Vision Pro の画像ベースのライティングを使用し、プラスチックやさまざまなバリエーションなど、追加したいマテリアルに正しく適用することを目指していました。ブロックについた指紋や傷など、対応が難しい要素にも対処しなければなりませんでした。

元々初期の iPhone 向けに開発されたゲームであったため、ライティングは非常にシンプルです。チームはボリュームテクスチャ（アンビエントオクルージョンがベイクされた 3D テクスチャ）を使用することで、シーン内のどこからでもサンプルを取得できるようにしました。ポイントをサンプリングし、アンビエントオクルージョンがどのくらい生じているかを分析しました。Apple Vision Pro では 3D テクスチャがサポートされていないため、ボリュームテクスチャを 2D テクスチャに変換し、手動でサンプリングを行う必要がありました。現在、このプロセスは PolySpatial で自動化されていますが、Light Brick Studio チームが作業を開始した時点では利用できませんでした。

チームは最初に、プラスチックブロックシェーディングとこのボリュームテクスチャサンプリングシステムを使用し始めました。次に、リアルタイムライトを組み込みました。そして、ボリュームテクスチャがシーン全体を包み込むにつれて、外部のライティングを変更する必要がありました。開発を始めた当初は、画像ベースのライティングを上書きすることができなかったため、別のキューブマップをサンプリングし、RealityKit の画像ベースのライティングによるライトをフェードアウトする必要がありました。

「我々が成し遂げたかったことを正式に実装する方法はありませんでしたが、RealityKit に送信する前に、ブロックの滑らかさを低下させ、他のさまざまな値を上げることで対処する方法を見つけました」と Fredborg 氏は説明します。「現在は、PolySpatial と RealityKit で画像ベースのライティングの上書きが可能になったため、開発者にとってこの作業はより容易なものになりました」と Fredborg は説明します。

ソフトシャドウの作成

また、Light Brick Studio チームは、影に関するソリューションを見つける必要がありました。Apple Vision Pro では、特定の要素に影を追加することはできますが、標準的な方法ではありません。これを実現するため、チームは Unity で影をハイトマップまたは深度マップとしてレンダリングし、それを RealityKit に送信して再サンプリングしました。Unity の Metal バックエンドでシーンをシャドウマップとしてレンダリングし、その結果を RealityKit のレンダリング側に渡しました。

「90 フレーム/秒 を維持する必要がある場合、レンダリングでプッシュできるものは限られてしまいます。「我々は、64 x 64 ピクセルの非常に小さなシャドウマップを作成し、ミップマップレベルを 1 つのテクスチャの RGBA チャンネルに統合しました。これにより、RealityKit で 1 つのサンプルでサンプリングし、ソフトシャドウのような効果を生み出すことができます」と Fredborg 氏は説明します。「ブロックがサーフェスに非常に近い場合、影はかなりシャープになりますが、離れている場合はソフトになります。我々はこれを 1 つのテクスチャサンプルで実現しました」

Unity のリアルタイムライトには、Shader Graph の PolySpatial Lighting Node を使用し、RealityKit への変換時に複数の Shader Graph ノードに拡張されました。

「RealityKit では、シェーダーを変更するには Shader Graph のようなインターフェースを使うしかありません」と Fredborg 氏は言います。チームは、Unity 側で Shader Graph を使用してカスタムコード関数を作成でき、特定のルールに従っている限り、後からでも MaterialX ノードグラフに変換できることがわかりました。「この点は本当に助かりました」と彼は続けます。「そうでなければ、Shader Graph がごちゃごちゃのカオス状態になっていたでしょうから」

90 FPS での最適化

チームが新しい次元にビジュアルを持ち込もうとする中、プラットフォームがスムーズに動作する状態を維持する上でいくつかのハードルに直面しました。開発は 2 部構成システムで、Unity から異なるレンダリング技術を持つ RealityKit にすべてを渡すようにしました。これは、Unity がゲームロジックを処理し、RealityKit がビジュアルのレンダリング処理を行うという仕組みで、90 FPS でスムーズに動作させるには最適化が必要でした。主な課題の 1 つは、ボトルネックが Unity 側にあるのか、RealityKit 側にあるのかを判断することでした。チームは、解決策を見つけるのに、何度も試行錯誤しました。

「当初、PolySpatial パッケージは、Unity で行っていることをすべて RealityKit に反映していました。そのため、すべてのゲームオブジェクトやトランスフォームが渡されており、当時は特定のレイヤーを送信または反映しないように設定することができませんでした。UI レンダリング、キャンバスレンダリング、アニメーターパーティクルシステムなど、すべてが反映されていたのです」と Fredborg 氏は説明します。「現在は、特定のレイヤーを追跡しないように設定できるフィルターがありますが、当時は、RealityKit 側で表示しないものをすべて削除する方法を考える必要がありました」

チームは、ゲームオブジェクト階層構造を最適化する必要がありました。他のプラットフォームでは、ブロックは 3 つ以上の連結されたゲームオブジェクトで構成されていますが、visionOS では、Unity と RealityKit 間のデータ転送の回数を減らすため、ブロックごとのゲームオブジェクトの数は最大 2 つとしました。これが非常にうまく機能し、チームに大きな成功をもたらしました。

また、ストップモーションアニメーションの強化も注目すべき点です。ゲームにはアニメーション化された滝が登場しますが、これはブロック上のメッシュを入れ替えることで再現していました。数百もの異なるゲームオブジェクトから構成されており、かなり動きが遅くなっていました。「最終的に、すべてのゲームオブジェクトに対して毎フレーム処理を行うのではなく、時間をずらして処理する方法を採用しました」と Fredborg 氏は言います。「滝の流れの間で数フレームごとに待機して実行するようにしたのです。これでかなり動きが改善しました」

最適なソリューションとパートナーの特定

Apple Vision Pro 向けの開発過程で、Light Brick Studio チームは、正しい結果を得るために、常に柔軟に対応し、問題を迅速に解決し、イテレーションを行う必要がありました。

「ゴーグルを実際に着けないと、わからないと思いますね」と Fredborg 氏は言います。「私たちはタッチと動きに集中するために、何度もビルドを行い、できるだけ多くのデバイスを使用することを推奨しています。Mac 上で動作するシミュレーターを使って、動作を体験することはできますが、入力が異なります。もっと物理的な感覚にフォーカスしたプラットフォームなんです」

最終的に、チームは完成したゲームにとても満足しました。この成功に一役買ったのが、強力なサポートパートナーとの連携です。「PolySpatial チームは、Slack でもディスカッションフォーラムでも、非常に良く対応してくれました」と彼は続けます。「問題に直面した際は、迅速にソリューションを提案してくれたりと、非常に頼りがいがありました。本当に協力的で、PolySpatial をより良い製品にしようと尽力していることが分かりました」

Unity 2022 LTS で Apple Vision Pro 向けに開発

Unity のパワフルなツールとワークフローを活用して魅力的な空間体験を構築するために、私たちがどのようにサポートできるか、Unity のチームにご相談ください。