物理演算協力ゲームのネットワーク化：LEGO® ボイジャーズ

2020年に設立されたライト・ブリック・スタジオは、職人技とプレイヤーの洞察に焦点を当てた独立系チームです。彼らの最新リリース『LEGO Voyagers』は、宇宙飛行士になる夢を追う二人の友人を描いた協力プレイアドベンチャーです。2025年9月15日に複数のプラットフォームでリリースされました。この体験は対話ではなく音とインタラクションに依存し、プレイヤーがプレイを通じて物語を感じ取れるようにしている。

オンライン協力プレイ機能は開発後期に追加されたため、チームにとって一意の課題が生じた。LEGO Voyagersの主任プログラマーであるカスパー・ホネンズ・デ・リヒテンベルクとプログラマーのダニエル・ザストロウに、物理演算を重視したプロジェクトへのオンライン協力プレイ機能の追加について話を聞いた。

LEGO Voyagersを開発する上での主な目標は何でしたか？

カスパー・ホーネンズ・デ・リヒテンベルク（KHdL）：私たちは、感情を呼び起こし、強力な協力体験をサポートする楽しいゲームをビルドすることを目指しました。

ダニエル・ザストロウ（DZ）：私たちの目標は、レゴ遊びの本質を捉えることでした。友達と一緒に楽しむこと、実際のレゴブロックになったような感覚をできるだけ味わうこと、そして物語を共に体験する冒険に出かけることです。

どのシステムが実装において最も技術的に困難でしたか？

KHdL:開発途中でのオンラインプレイ追加は、既存のアートとデザインワークフローを維持する必要があったことを意味した。チームが中断なく制作を続けられるよう、オブジェクトやシーンを自動で換算するツールを構築しました。

DZ:アタッチメントシステムのネットワーク化が最も困難だった。どんなレンガも無数の方法で繋がることができ、二人のプレイヤーが同時に相互作用できる。オンラインプレイ向けにゲームを開発していなかったため、ホストがアクションを有効にできる一方でクライアントが待機できるように、ロジックの大部分を書き直しました。また、レンガの接続部分の遷移を滑らかにして待ち時間を隠しました。

NVIDIA PhysXは、ネットワーク上で複数のバラバラなレゴブロックを同期させるのにどのように貢献したのか？

DZ:我々は完全な決定論を追い求めなかった。各クライアントは物理演算をローカルでシミュレーションした後、視覚的な一貫性を保つため、ネットワーク更新に向けてオブジェクトを微調整した。カタパルトのような高速シナリオでは純粋な物理演算は信頼性が低いため、着地後は決定論的軌道を使用し、その後PhysXを再有効化しました。このハイブリッドは不具合なく物理的な感触を保った。

GameObjectsとRelay向けのNetcode for GameObjectsは、どのようにネットワークワークフローを効率化しましたか？

KHdL:Netcode for GameObjectsとRelayのNetcodeにより、ネットワークインフラをゼロから構築することなく、オンライン協力プレイを迅速に実現できます。オンラインプレイは開発後期に追加されたため、ゲームプレイに集中できる安定した基盤が必要でした。パッケージを開いてカスタマイズできることは極めて重要であり、特にNGOワークフローが手動変更を前提としていた場合に、自動シーン変換のスピード向上に大きく寄与した。その柔軟性のおかげで、開発の終盤にバグを修正し問題を解決し、最終的にゲームをリリースすることができました。

DZ:デザイナーはオフラインでの作業を継続でき、自動化されたシーン変換ツールにより、全員を一つの共有シーンに強制的に集める必要がなくなります。また、ネットワークレイヤーの安定性に影響を与えることなく、いくつかのワークフロー調整を行いました。

クロスプラットフォームの性能ターゲットは、物理演算とネットワーク実装にどのような影響を与えましたか？

KHdL:LEGO Voyagersは物理演算に大きく依存しているため、パフォーマンスはネットワークの安定性に直接影響を与えた。Nintendo Switch®では、物理演算のフレームレートを30fpsに設定しました。そのため、モデル崩壊処理、低詳細度アセットや影の使用、水表現などの負荷の高い特徴の簡略化など、関連するあらゆる要素を慎重に最適化しました。照明のベイクとモデルの崩壊は自動的であったが、手動でトリガーされた。

DZ:システム視点では、物理演算の負荷が予測可能な状態を維持し、ロードがかかってもネットワークのインタラクションが劣化しないようにする必要があった。スクリプトを最適化し、必要に応じて負荷の高いシステムを再実装しました。また、Unityのジョブシステムを用いた物理演算の並列化により、キャスト、トリガー、シグナリングの処理が大幅に改善されました。これにより物理演算とネットワーク更新の反応性を維持するための余裕が生まれました。

KHdL:各シーンをプロファイリングし、フレーム落ちを追跡し、パフォーマンスがターゲット値を安定して達成するまで最適化を続けた。これらの数値を達成することは不可欠だった——単なる見た目のためだけでなく、物理演算とネットワークが同期を保ち、プレイヤーにとって信頼性のある操作感を実現するためである。

振り返ってみて、どのようなネットワークの手法を変えたいですか？

DZ:もっと早くからネットワークの開始を開始すべきだった。オンラインプレイを追加した時点で、ゲームはほぼ完成していた。デザイナーたちはローカル協力プレイで完璧に機能するシーンやメカニクスを構築していたが、その裏側では同じメカニクスを異なる方法で実装することが多かった。それらをネットワーク接続しようとした際、こうした不整合が大きな問題となった——たとえゲーム内では全てが同一の外観をしていたとしても。

KHdL:例えば、3つの異なるレバースクリプトがありました。デザイナーがゲームプレイを早期にプロトタイプ化すると、そうした複製は自然に発生する。しかし共有構造体がなければ、特にネットワーク処理において後々摩擦係数が高くなる。

DZ:事前のリファクタリングなしでは、同じメカニズムの複数バージョンに対応せざるを得なかった。ネットワーク接続はアーキテクチャ上の問題を公開する——一貫性が極めて重要であり、さもなければあらゆる特徴が特例となる。

KHdL:早い段階で軽量なネットワーク構造体を採用していれば、助けになっただろう。共有基盤の上に新機能を構築することで、自動変換やツールの効果が大幅に向上します。

DZ:もう一つの課題は、物理演算ベースの設計そのものだった。それは私たちが望んでいたゲームプレイを実現したが、ネットワーク処理をより困難にした。自由にプロトタイプを作成することと、技術的な安定性のために仕様をロックすることの間には、常に緊張関係が存在する。振り返ってみれば、実験的段階から構造体への遷移をより明確にすべきだった。

KHdL:それはバランスだ。チームとしてその会話をもっと早く開始していれば、多くの苦労を避けられただろう。

クロスプラットフォーム対応の協力プレイゲームにおけるネットワーク処理のコツを共有してください。

DZ:実行と検証を分離する。クライアントにアクションを実行させつつ、検証はホストまたはサーバー側で保持する。それらの責任が絡み合うと、ネットワーク構築ははるかに困難になり、脆弱で過度に複雑なコードにつながります。必要がなければ、100%の決定論を無理に押し付けないでください。外観と使い心地が自然な一貫性を目指しましょう。

KHdL:ゲームの文脈に合わせて設計することも重要です。LEGO Voyagersはカジュアルな協力プレイ体験であり、柔軟に対応できる。完璧な同期が常に要件とは限らない。

Made with Unityで作成されたプロジェクトの詳細については、リソースページをご覧ください。

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