Wishfullyは『Planet of Lana II』を各プラットフォームで同時リリースした

『Planet of Lana II』は、2018年にヨーテボリで設立されたスウェーデンのインディースタジオ「Wishfully」の開発者によって開発された、映画のようなパズルアドベンチャーゲームです。PC、Xbox、PlayStation®、Nintendo Switch™をはじめ、次世代ハードウェアに至るまで、その体験を提供することは、技術的に大きな課題となっています。

スタジオ共同責任者兼クリエイティブディレクターのアダム・スティャルンリュス氏、シニアプログラマーのエドヴァルド・ルットストローム氏、リードプログラマーのマティアス・ヴァルグレン氏にインタビューを行い、彼らがどのようにコードベースを統合し、ビルドパイプラインをスケーリングし、PCとコンソールを同時にリリースしながらほとんどのプラットフォームで60fpsを実現するためにゲームを最適化したのかについて詳しく話を伺いました。

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

『Planet of Lana II』の概要と、マルチプラットフォームプロジェクトとしての規模を共有していただけますか？

アダム・スティャルンリュス：『Planet of Lana II』は前作をベースに、コンテンツ量を約2倍に増やし、スケールも拡大しています。前作はXboxとPC向けに発売された後、他のプラットフォームへ移植されましたが、続編はPC、Xbox One、Xbox Series X|S、PlayStation 4、PlayStation 5、Nintendo Switch向けに、各プラットフォームでの同時リリースを目指して開発されました。2026年3月5日にリリースしました。

本作は、ラナと相棒のムイが、パズル、プラットフォームアクション、ステルス要素を融合させたストーリー主導型の冒険を繰り広げるパズル・アドベンチャーゲームです。ゲームプレイの核心は、ラナとムイが相互作用することであり、ナラティブは前作の世界観と競合構造をさらに掘り下げています。

チームは、複数のプラットフォームでの同時リリースに向けたVisionを策定するにあたり、どのようなアプローチをとったのでしょうか。また、プラットフォームのラインナップはどのような要因によって決定されたのでしょうか。

AS:続編の開発にあたっては、マルチプラットフォーム対応を最優先とする姿勢で臨み、前作のプラットフォーム抽象化技術やツールを基盤としてビルドしました。私たちの目標は、開発の早い段階からすべてのターゲットプラットフォームで継続的ビルドを実行し、パフォーマンスのテストと改善を開発期間を通じて行えるようにすることでした。そうすることで、その作業を最終段階まで先送りせずに済むようにしたのです。

今回のプラットフォームラインナップ（PC、Xbox、PlayStation、Nintendo Switch）は、前作のリリース実績と、全プラットフォームでの同時発売を実現するという目標に基づき選定しました。これをサポートするため、私たちは既存のツールやワークフローをイテレーションを重ね、すべてのターゲットプラットフォームで互換性を維持することは依然として困難ではあったものの、チーム全体が早い段階からパフォーマンス向上に貢献できるようにしました。

貴社の技術アーキテクチャは、プラットフォーム固有のコードのサイロ化を招くことなく、効率的なマルチプラットフォームのビルドとDeploymentをどのようにサポートしましたか？

マティアス・ワーグレン：プラットフォームの分岐を避けるため、プラットフォームごとのフォーク版を作らず、最初のゲームから引き継いだ共有のプラットフォーム抽象化レイヤーの上で、単一のUnityプロジェクトを使用して開発を行いました。別々のコードベースを維持する代わりに、コンパイル時の定義、条件分岐システム、およびツールを活用して、プラットフォーム間の違いに対応しました。

また、プラットフォームごとにアセットを含めるか除外するかを選択できるコンテンツフィルタリングツールを導入したほか、デバイスごとに調整可能な段階的な品質および詳細レベルも導入しました。Unityのビルトイン設定に加え、よりきめ細かなコントロールを可能にする独自の品質管理システムを追加しました。

AS:この設定により、デザイナーや開発者は、すべての要素を単一のパイプラインで統一したまま、ターゲットデバイスごとにコンテンツやパフォーマンスを調整できるようになりました。これにより、制作期間を通じてビルドの効率性と管理しやすさが維持されました。

すべてのプラットフォームへのデプロイをサポートしつつ、ビルドのボトルネックを回避するために、ビルドパイプラインをどのように構築しましたか？

エドヴァルド・ルットストローム：私たちは早い段階からビルドパイプラインを優先し、TeamCityと専用のビルドエージェントを用いたオンプレミス環境の構築から開始しました。これにより、開発者のマシンでのビルドを排除し、リソースの競合を回避しました。プロジェクトの終盤には、ビルドエージェントの数を増やしたパブリッシャー管理のインフラへ移行しました。これにより、すべてのプラットフォームでの夜間自動ビルドが可能になり、ボトルネックが解消されました。

また、すべてのプラットフォームで公開デモをサポートする必要があり、その結果、ビルドの複雑さが増し、実質的にビルドの数が2倍になりました。同じリポジトリとプロジェクト内で、ビルドフラグを使用してデモ版とフルバージョンの区別を定義し、ビルド時にデモ版以外のコンテンツをストリッピングすることで、この処理を行いました。技術的にはうまく機能しましたが、ビルドの量を管理すること、特にQA部門がデバッグ版とリリース版の両方を必要としていたため、大きなオーバーヘッドとなってしまいました。

MW：このパイプラインは移植性を考慮して設計しました。インフラを移行する際、コードベースやビルドスクリプトを変更する必要がなかったため、遷移はスムーズに進み、開発に支障をきたすことはありませんでした。

複数のプラットフォーム固有の最適化が並行して開発される中で、安定性を確保するためにどのようなインテグレーション戦略が採用されたのでしょうか？

MW：共有の品質レベルと強力な有効な検証ツールを組み合わせることで、安定性を実現しました。Unity エディター内で直接シミュレーションを行うことができる、プラットフォーム対応の品質モードを実装しました。これにより、デザイナーやアーティストはプロジェクトを分岐させることなく、さまざまなハードウェア上でコンテンツがどのように動作するかをプレビューできるようになりました。

また、チェックポイントをステップで確認し、スクリーンショットをキャプチャし、パフォーマンス指標をオーバーレイ表示する自動化ツールも構築しました。これにより、チームは変更が各ターゲットプラットフォームにどのような影響を与えるかを常に把握できるようになり、コードベースの安定性を保ちつつ並行してイテレーションを進めることが可能になった。

マルチプラットフォーム向けのビルドを効率化し、アセットの複製を削減するために、アセットパイプラインをどのように構築しましたか？

ER:コンテンツのバンドルに重点を置いたアプローチから脱却しました。アセットの複製を避けるのは困難であることが判明した。特に、ゲーム全体でバイオームのコンテンツを再利用していたため、明確な分離を行うことは現実的ではなかった。

その代わりに、よりコントロールされたアセットパイプラインを採用しました。オーディオ処理はFMODの分離されたバンクで行い、ビジュアル処理はスプライトアトラスで行いました。さまざまなハードウェア構成に対応するため、アセットのストリッピングとアトラスのサイズ制限に重点を置き、これにより、余分な複製を生じさせることなくメモリ使用量を削減しました。

このアプローチにより、ビルドをシンプルに保ちつつ、デバイス間で予測可能な読み込み動作と安定したメモリ使用量を確保することができました。

C# Job SystemとBurstコンパイラーを活用したゲームプレイシステムは、どのようにマルチプラットフォームのビルドとDeploymentをサポートしたのでしょうか？

ER:いくつかの対象システムにおいて、UnityのC# Job SystemとBurstコンパイラーを採用しました。主に、火、熱、水を扱う要素シミュレーションと、雪のデフォーメーションシステムです。

これらのシステムは、範囲が明確に定義され、データ中心に設計されていたため、特別な処理を必要とすることなく、異なるハードウェア間でもスムーズに移植することができました。クラッシュやレースコンディションは発生しなかったため、標準的なジョブシステムのベストプラクティスで十分でした。

プロファイリングデータをどのように活用して、ビルド設定やプラットフォーム固有の最適化に反映させましたか？

MW：すべてのプラットフォームにおける開発ビルド間のプロファイリングを活用し、自動化されたスナップショットを用いて、レベルごとの問題箇所を特定しました。開始時点で各プラットフォームを個別に調整するのではなく、まずはすべてのターゲットプラットフォームにメリットをもたらす改善に注力し、必要に応じて特定のボトルネックを最適化しました。

ER:まず、低スペックのベースライン実行から始め、品質を損なわないよう最適化を行いながら、CPUのボトルネック、場合によってはGPUのボトルネックに対処しました。その取り組みが実を結び、ほとんどのターゲットプラットフォームで60fpsを達成することができました。また、アセットの読み込みとメモリ使用量を管理するために、メモリプロファイリングを多用しました。

AS:それは延々と続くループだった。プロファイリングを行い、ドローコールやフレームレートの低下といった問題を特定し、最適化を施し、そのプロセスを繰り返しました。やがて、この取り組みは、デザイナーがパフォーマンス上のコンストレイントを早い段階で把握できるようになるというワークフローへと発展し、その結果、開発の終盤における手戻りが減少しました。

ナビゲーションシステムを、複数のプラットフォームで効率的に展開し、一貫したパフォーマンスを発揮できるよう、どのように設定・構築しましたか？

MW：静的および動的なナビメッシュボリュームを組み合わせて使用し、事前計算されたデータとランタイムの柔軟性のバランスをとりました。品質設定を通じてプラットフォームごとにナビゲーション設定を調整したことで、一貫した動作を維持しつつ、デバイスごとの精度とパフォーマンスコストを制御することができました。

今になって振り返ってみると、どのような点を変えるでしょうか。また、複数のプラットフォームでの同時リリースを計画しているチームには、どのようなアドバイスをしますか？

ER:改善したい点の一つは、ビルドパイプラインにおけるパッチ作成の自動化です。手作業で行うのは時間がかかり、スケーリングができませんでした。

私たちが得た最大の教訓は、最初からマルチプラットフォームで展開することだ。すべてのターゲットプラットフォームで早期にビルドとテストを行い、最適化を後回しにしないこと。また、セーブデータ、実績、ユーザー管理といった共通機能を単一のAPIで統合するプラットフォーム抽象化レイヤーも開発しました。これにより、各実装が独立して管理され、コードベースの他の部分に影響を与えることなく、新しいプラットフォームのサポートが容易になりました。

Unityを使って制作されたプロジェクトについて詳しく知りたい場合は、「リソース」ページをご覧ください。