ピアツーピアマルチプレイヤーのヒット作『Ship of Fools』による Fika Productions の船出
Fika Productions は、協力型ローグライトゲームの市場ギャップを埋めるにあたり、ローカル協力モードに狙いを定めていました。そんなさなか、2020 年が発生したのです。今回、リードゲームプレイプログラマーの Daniel Carmichael 氏と開発者の Yannick Vanderloo 氏にお話を伺い、ゲーム業界にとって複雑な時期に『Ship of Fools』を市場に送り出すために解決しなければならなかった開発上の課題について深堀りしました。
『Ship of Fools』の開発のきっかけについて教えてください。チームに海運関係に詳しい方がいたのでしょうか？
Daniel 氏：私たちのインスピレーションは、何よりもまず、協力的なローグライトという市場のギャップを埋めることでした。私たちはみんなローグライトというジャンルのファンで、素晴らしいローグライトゲームはたくさんあるけれど、協力プレイの部分を上手く実装できているものはないと感じていたのです。
テーマ的な面では船というものにすごく惹かれました。船そのものが沈めば、乗組員も全員一緒に沈むからです。船を浮かせるために協力し合うことが、核となるメインのアイデアでした。海運関係に詳しいメンバーはいませんでしたし、もちろん海の生き物もチームにいません。
タコも船乗りも、このゲームの開発には関わっていなかったのですね。なるほど。皆さんにとって、市場調査とはどのようなものでしたか？
Daniel 氏：私たちの市場調査は、Reddit 上のちょっとした調査活動にすぎませんでしたが、たくさんの学びを得ることができました。ローカル協力プレイやローグライトに関する 25～30 のサブレディットで、「協力プレイのローグライトゲームを成功させるには何が必要だと思いますか？」という質問をしたんです。多くの提案を受け取り、それらを文書にまとめ、重複している内容やテーマを探しました。このプロセスを通して、私達のアイデアをいくつか検証しつつ、新しいアイデアも得ることができました。
『Ship of Fools』の開発において、一番楽しかった瞬間はどのようなものでしたか？
Daniel 氏：オフィス内で、ちょっとしたギャグが流行ったんです。小さな機能を実装し終えるたびに誰かが「ゲームが完成したぞ！」と言うというものでした。そしてある日、ゲームのとても重要な部分をマージした後、私がプレイテストを行いました。みんなに「販売できるゲームが完成したぞ！」と言った時のことはずっと忘れないと思います。それは私たちにとって、とても誇らしい瞬間でした。
このゲームのマルチプレイヤー開発において特に困難だった点と、それを乗り越えた方法を教えてください。
Yannick 氏：ゲームにおけるネットワーキングは、ホストかクライアントのどちらかがすべてをコントロールする場合、簡単であることが多いです。しかし、いくつかの要素をローカルプレイヤーが、他の要素をゲームホストがマネージするような形でコントロールを分ける必要がある場合、色々と難しくなります。
このセットアップにおいて、飛び道具の実装が特に大変でした。発射したときに素早く飛んでいく感じを出したかったのですが、そのためには多くのシナリオを考慮する必要がありました。さらに、敵が反撃してきてプレイヤーがショットを撃ち落とすような場面においては綿密にインタラクションを計画し、高遅延の状況においても、すべてのプレイヤーにとって適切に感じられる形で実装できるようにしなくてはなりませんでした。考慮すべきエッジケースは山ほどありました。特に、双方のプレイヤーにとって迅速かつ高反応にする方法についてはです。
Daniel 氏：もうひとつの大きな問題はネットワーキングでした。私たちは実に 1 年半もの間、オンラインプレイのことは一切考えず、ローカルでの協力プレイ用にゲームを開発していました。そんな時、パンデミックが発生したのです。突然誰もが家にいることを余儀なくされ、顔を合わせて遊ぶことができなくなったため、ローカルモードだけで作られたゲームはあまり意味をなさなくなってしまいました。
元々、私たちは対面して一緒に遊ぶ雰囲気を大切にしていました。それこそがゲームの核だったのです。しかしパンデミック発生の影響でパブリッシャーに「オンラインモードも実装しよう」と言われ、「よし、やろう」ということになりました。結局オンラインプレイのためにゲームのあらゆる部分を調整しながら、1 年分の作業をやり直さなければならなかったような感じです。
これは開発者仲間へのちょっとしたアドバイスなんですが、100％ 乗り気ではなかったとしても、最初から常にオンラインプレイを念頭に置いておくことをおすすめします。一般的に、オンラインプレイのことを考えながらゲームをデザインするのは堅実な選択です。それに、オンラインモードを後から無理やりねじ込むより、必要に応じてオンラインモードを削除するほうがずっと簡単です。
飛び道具の管理について詳しく教えてください。また、Netcode for GameObjects はどのように活用されたのでしょうか？
Yannick 氏：私たちのゲームのネットワーキングは、結果的にユニークな展開を伴いました。Netcode for GameObjects を使用した、一般的なセットアップは行っていません。その代わりに、オブジェクトがクライアント側とホスト側の双方に存在しており、それぞれがお互いのアクションを認識し、いつ、どちらがコントロールしているかを把握するような形を採用しています。双方が常に会話を交わし、お互いの状況について報告し合っているようなイメージです。
例えば、弾丸が発射される場面では、ホスト側のターゲットに弾丸が命中すると、ゲームはクライアントが命中を確認するのを待ちます。クライアントは命中したことを確認するかもしれませんし、「躱した」あるいは「弾丸を撃ち返した」と言ってくるかもしれません。クライアントの反応次第で、ゲーム側が結果を調整し、双方の状態を同期します。
このセットアップによって、多くの柔軟性が生まれます。クライアント側のプレイヤーは、弾丸がそれるなど、自分の行動に対する反応を即座に見ることができてゲームに手応えを感じられます。しかし、最終的な結果はホストの入力に基づいて調整する必要があるので、不一致があった場合は最初のリアクションがオーバーライドされることもあります。
権限が行ったり来たりする可能性のある、ちょっとしたダンスのようなものです。最終的に、最もシンプルな解決策は、各サイドにやるべき事をやらせた後、相手側からのフィードバックに基づいて出てきた相違点を調整することだとわかりました。ホストとクライアントの両方がゲームの流れに貢献できるようにする、協力型のプロセスなのです。
読者の皆さん向けに、少し視覚的な説明をしましょう。
最初の画像にマルチプレイヤーのセットアップが映っています。私は左側でホストの Todd を操作しており、友人が右側でクライアントの Hink としてプレイしています。
すると、カニのようなエネミーが飛び出し、弾丸を発射してきます。ここでは連携が鍵になり、ホストとクライアントの両方が、リモートプロシージャコールを介して情報を受け取ります。弾丸は両プレイヤーに見えていますが、それが船に当たるかそれるかはプレイヤーの反応次第であり、ホストは最終的な結果を確認するためにクライアントの入力を待つ必要があります。
最後に、Hink としてプレイしているクライアントが弾丸をそらすとどうなるかを見てみましょう。レイテンシが高い場合は少し遅延があるので、最初はホストがボートに弾丸が当たっているように見えるかもしれませんが、これはクライアントの反応が確認されれば修正されます。こうすることで、クライアントはラグを感じることなく、彼らの行動はあたかもリアルタイムでプレイしているかのようにホストによってミラーリングされ、ゲームが同期され続けるのです。
プレイヤーがその場の雰囲気に身を任せながらシュートを決めたり、攻撃をかわしたりしているとき、ゲームが即座に反応し、マルチプレイヤー体験がシームレスに感じられるようにするのが目的です。
他に何か具体的なことはありませんか？読者が大きな教訓として持ち帰ることができることがあれば是非教えてください。
Daniel 氏：私たちは多くの難題にぶつかりましたが、中でもメモリ管理が大きな課題でした。特に、本作はチーム全員にとって初めてのマルチプレイヤーゲームであったため、アセンブリと Addressables について学ぶのはとても大変でした。
面白いことに、私たちのゲームはそれほどアセットが多いわけでもないのに、ロード時間が 2 分に達したことがあったんです。これは小さいゲームでは通常ありえないことです。これがプレイヤーたちの怒りを買ったのは間違いありません。
かくして、私たちは、メモリやアセット面を合理化するのが重要であることを大変な形で学びました。最初から基本はしっかり抑えておくべきだったんです。
Addressables についてはどうでしょうか？そこでの具体的な学びについて教えてください。
Yannick 氏：Addressables への対応はわりと簡単でした。アセットを、同時にロードする辻褄が合うような形でグループ分けするんです。そうすれば、特定のシーンで使われてすらいないもののせいでゲームの処理が重くなることがなくなります。
例えば、私たちのゲームにはさまざまなセクターがあり、それぞれに固有のエネミーやシーン、風景があります。当初はすべてを 1 つの巨大なグループにまとめていましたが、それですとロード時間がとんでもないことになりました。そこで、効率化のためにセクター別にアセットをグループ化し始めたんです。これにより、必要に応じてエネミーだけ、あるいはセクターの風景だけをロードすることができるようになり、最終的にすべてがより効率的でスムーズになりました。
ネットワーキングに Netcode for GameObjects（NGO）を使うことを選んだのは何故ですか？
Yannick 氏：ネットワーキングにおいて NGO を採用した主な理由は、Unity によってサポートされているからです。つまり、プラットフォームとともに進化し、私達にとって非常に重要な、長期的なサポートを得られる可能性が高いというわけです。それに、NGO には私たちが必要としていた機能がすべて揃っていました。
私たちが一番重要視していたのは、将来の売上やプレイヤー数が不透明なゲームにとっては大きな問題である、サーバーコストを避けるためのピアツーピア接続の存在です。NGO を使うことは、現在のニーズと将来の発展の両方に関して、安全な選択肢だと確信していました。Unity のエコシステム内にとどまり、私たちのゲームの長期的なサポートを確保することは、賢い選択だと思ったんです。
『Ship of Fools』の今後の予定について教えてください。
これまでに、フレッシュなコンテンツを満載した 2 つの大型アップデートを実装し、2 つのDLCを発売し、個性的な新キャラクターも導入しました。DLCの購入は完全に任意で、より多くの選択肢を与えてくれるものになります。たとえ購入しなかったとしても、プレイヤーに取り残されたと感じさせることはありません。一番クールな点としては、これらの主要なコンテンツ更新は完全無料であり、私たちが知る限りはユーザーにもとても好評でした。
将来の展開についても色々と計画はしていますが、今はまだ企業秘密とさせてください。今後のアップデートについて発表する準備ができ次第、すぐにお知らせします。
マルチプレイヤー向けの開発に興味がおありですか？「Unity ゲーミングレポート 2024」のマルチプレイヤーセクションでは、成功を収めたスタジオからのインサイト、より多くのスタジオがマルチプレイヤーゲームを開発している理由がわかる新鮮なデータ、そして皆さんと皆さんのチームが時代の最先端を行くためのヒントを数多く得ることができます。
