ターン制ストラテジーの方程式を 4 人のチームで再構築した RESEARCH and DESTROY の特徴

あなたは Unreal Engine を使用してすばやくプロトタイプを作成し、トップクラスの品質のゲームを開発した印象的な経験について、ウェブサイトで書かれていますね。Unreal Engine を使用することで、どのようにそれを実現できたか説明していただけますか？

Daniel Markiewicz 氏:これまでこういったインタビューですでに出た話かどうかはわかりませんが、Unreal Engine にはほとんどすべてが揃っていると思うんです。おそらく、このプロジェクトを開始したときにはいくつか足りないものもありました (当時の マーケットプレイス が今みたいになっていればよかったのですが！)。しかし、3D ゲームを作成するなら、Unreal Engine は、実用的なプロトタイプを数週間で作成可能な充実したツールボックスです。また、作成する内容によっては数日で完成するでしょう。

特に ブループリント を使用すれば、新しいゲームプレイ機能のプロトタイプ作成は簡単です。非常に便利なサンプル プロジェクトが含まれているので、もし付属していなければシステムを理解するのが難しい内容でも簡単に把握できるようになっています。Shooter Game は、私にとって究極のカンニング ペーパーでした。

ゲームを Tokyo Indie Fest と Bitsummit に出品している間にプレイヤーへの調査を行われていたようですが、こういったプレイ後の調査で判明した内容は、ゲームの進化にどのような影響を及ぼしましたか？

Chris Willacy 氏：2 つのイベントでのフィードバックは、全体としてポジティブなものだったので、基本的な方針をなくしたり作り直したりする必要はありませんでしたが、すぐに修正しなければならないことが明らかな問題がいくつかありました。たとえば、武器の初期バージョンの 1 つに Test Tube Launcher というものがありますが、これは 非常に 破壊力のある爆発を起こす一方でリロードに時間がかかりました。また、Alt-Fire モードでは状況に応じてシールドになります。爆発モードでは仲間を攻撃してしまうことがあまりに多く、シールド モードはすぐに使われなくなってしまうことを確認しました。同様の問題は、多数ありました。骨組みは作ったものの、仕上げはまだ粗かったのです。明らかにまだ対応が必要でした。

新しいプレイヤーにゲームを試してもらうたびに、新しいことが学べます。ある程度、自分を信じることは必要ですが、ほとんどの場合はそこから離れて、新しいプレイヤーの行動の理由を理解しなければなりません。プライドをなくすような努力が必要なので、1 ～ 2 回、あるいは 3 回目でも受け入れがたいことがあるかもしれません。しかし、こういった新しい観点は不可欠です。そんな観点がなければ、経験と一握りの人々の感覚を頼りにゲームを作成するだけで終わっていたことでしょう。そうなれば、非常に悲惨なことです。

最終的に、こうしたフィードバックによって私たちは正しい道を進んでいることを確認できましたが、プレイヤーがゲームを進めやすくするための補助的なシステムがまだ必要でした。その道のりは簡単ではありませんでしたが、こういった多数の問題を解決していく能力は豊富でした。

Gajentaan 氏：ゲームを出品し、実際に体験してもらうことで重要なことを 1 つ学びました。時間の仕組みがユニークなため、直接説明すると多くの時間がかかってしまったのです。そこで、イベントの後ですぐにスタンドアローンのチュートリアル ミッションを作成しました。デモ版でも完全版でも、それ以来メイン メニューから常にアクセス可能になっています。自宅にゲームがあって、訪ねてきた友達とローカルの協力プレイをしたい場合があるとしましょう。友達にこのチュートリアルを数分プレイしてもらえば、ゲームの仕組みを完全に理解してもらえます。

Markiewicz 氏：不意に仲間を攻撃してしまうと誰もが例外なくそれを面白がっていたので、人間というものの恐ろしさも学ぶことができました。

RESEARCH and DESTROY に Unreal Engine を利用する決め手となったのは何ですか？

Willacy 氏：この 3 人で、合わせて 30 年～ 40 年あまりをさまざまな Unreal Engine の経験に費やしてきたので、Unreal Engine の利用を議論しないはずもありませんでした。利用するという決定は当然の流れと考えています。Unreal Engine の専門知識を他のスタジオに提供することで、ここ 6 年間で RESEARCH and DESTROY の資金ができ、あらゆるプロジェクトに携わることでさらに知識を身に付けています。制作の初期に完了した内容については、新しい手法やより良い手法を知ったことで開発期間中に 1 ～ 2 回やり直したものもあります。

Unreal Engine をゲームに利用するうえで魅力となる特別な要素はありましたか？

Markiewicz 氏：クロスプラットフォームの機能を備えていることです。この機能は「昼間の仕事」でクライアントのプロジェクトをサポートする際にいつも利用していたものです。

Willacy 氏：「時期」と「理由」さえ把握することができれば、さまざまなルールで行う日々の算術演算の処理も、その「方法」は Unreal Engine に任せることができると気づきました。私は数学があまり得意ではないので、これは非常に大きなことです。

Gajentaan 氏：Unreal Engine は、アーティストにとってすばらしいツールです。ソース アセットは比較的小規模でシンプルにも関わらず、コンテンツにバラエティを加える方法は常に豊富です。

克服した設計上の課題の中で、紹介していただけるものはありますか？

Willacy 氏：設計上の課題のほとんどは、小規模なチームが控えめな予算で、野心にあふれたタイトルを作ろうとしているために生まれていると思います。

私にとって最も大きかった設計上の課題は、たくさんある武器やガジェット、ゲームプレイのアクション要素を、すべてうまくまとめ上げることでした。設計の一部として、多数のゲームプレイが突然発生することがありましたが、これは予期しない形で武器やガジェットが相互作用のようなものを起こすことによるものでした。

2 つの Fire モードを備えた 9 個の武器があり、武器 1 個につき 8 個のアップグレードの組み合わせがあります。さらにそれぞれ 2 個のアップグレードが可能な 9 つのガジェットも存在し、それらが互いに異なる影響を及ぼします。この数の多さには頭が痛くなりました。ありがたいことに、これを自分だけで解決する必要はありませんでした。他のメンバーは優れた設計センスを持っており、チームが小規模なおかげでアイデアを出し合い、ワークフローを滞らせることなく協力して進めることができました。

具体的な例としては、戦いのデータを外部のスプレッドシートに一元化しました。レベル設計を担当しているのは私だけだったので、敵のスポーン システムを記述し、具体的な戦いに利用できる形で、すぐにイテレーションに活用できるものが必要だったのです。スプレッドシートと Unreal Engine のデータ インポート システムを活用することで、戦いのロードが多すぎたり少なすぎたりする問題をすばやく視覚化できたのです。グラフにし、UE4 の読み取り可能なリンクの配列にし、インポート前に検証したりすることができました。これにより、プロジェクト全体で、数週間、あるいは数か月分の作業を省略することができました。
データ主導のアプローチを取るなら UE4 が非常に優れており、多くの時間を節約できます。

他の例を挙げると、私はチームのオーディオ担当なのですが、バックグラウンド ミュージックを作成するほど膨大な時間はありませんでした。そのため、ターンやコントロールしているキャラクター、ゲームプレイ イベントなどによって変化するダイナミックなシステムを思いついたのです。これには最初は UE の Time Synth を使用していましたが、その後 Quartz を使用するようになりました。Quartz は私がこれまでずっと待ち望んでいた機能です。頭の中で思いを巡らしていたものを作ることができましたが、どういうわけか 15 年もの間実現はできていなかったので、これは本当に嬉しいことでした。できれば、今後のプロジェクトでもさらに利用してみたいと思っています。

Markiewicz 氏：このゲームの中核的要素となっているのは、キャラクターの時間がなくなると、動かなくなってしまうことです。走っているときでも、飛んでいるときでも、落ちているときでも、キルされて体がぐにゃぐにゃしている最中でもこれは変わりません。キャラクターは行動を停止しなければなりませんが、すぐに再開できます。これが最終的に、予想していたよりも大きな課題になりました。オンラインのマルチプレイヤーではなおさらのことです。

たとえば、オオカミ人間を爆発で空中に打ち上げたとします。「どうしてそんなひどいことを。ひとり親で 2 人の子どもがいるオオカミ人間になんてことをするんだ？」と思っている間に、オオカミ人間は空中で動きを止め、すべてラグドール物理によって決定される姿勢を取ります。プレイ中はキャラクターが多くなることがあり、爆発もたくさん起きます。そのため、ラグドール物理で動きを止めたキャラクターだらけになる可能性もあるのです。

システムを実装した当初、ネットワーク経由でそれらを同期することはまったく私たちのカードにありませんでした。私はいくつかのアプローチを試してみたのですが、まったくうまくいくことはなく、ネットワークの状態が悪いとこれは特に顕著でした。ほとんどのゲームに当てはまることですが、キャラクターがキルされるとラグドール物理はそこに突然適用されます。その点で、これはほとんどの場合表面的なことです。 

このゲームではさらに時間を取って、爆発の最中で動きを止めているオオカミ人間に対し、ヘッドショットを狙うこともできるのです (やっぱりひどいことをしますね)。最終的にこの問題は、すべての武器のヒット検出の権限をクライアント側に与えることで解決しました。つまり、仕組みとしては、ヒットの有無をクライアントが判定し、それをサーバーに知らせます。ヒットの有無をサーバーが判定する通常のパターンとは異なります。もしこれが勝敗を競い合うゲームであれば、チートのためのワームを多数増やす可能性につながってしまいますが、それに関してはあまり心配していません。ここで最も重要なのは、クライアント側のプレイヤーが空中で止まっている敵の頭部に狙いを定めたのなら、ホスト側ではわずかにその頭部の位置が異なっていたとしても、必ずヒットしなければならないということです。それによってホスト側のプレイヤーに多少の違和感を感じられることがあってもかまいません。シューティングを行っているプレイヤーの体験の方を優先しているからです。

次世代のハードウェアや Unreal Engine の長期的な可能性について、最も期待することは何ですか？

Willacy 氏：個人的には、 UE5 の MetaSounds を利用できることを楽しみにしています。オーディオを作るのが好きなので、皆さんにはぜひ RESEARCH and DESTROY のオーディオを体験していただきたいと思います。MetaSounds があれば、ゲームプレイにうまくマッチする、さらにマニアックなオーディオが作れそうです。

ハードウェアについては、ゲーム作成に必要な作業を忙しくしなくてすむ日が来ることを願うばかりです。UE5 の新機能の一部と足並みを揃えて進化する新しいハードウェアが出てくれば、その最初の一歩を踏み出せるのではないかと思っています。

Markiewicz 氏：Nanite を最新のコンソール (や PC) と組み合わせるとロード時間が高速になるので、ゲームプレイでのそのスケールの可能性 (およびそこからのダイナミックな変化) には本当に期待しています。

貴重なお話をありがとうございました。Implausible Industries や RESEARCH and DESTROY の詳細はどこで確認できるでしょうか？

Implausible Industries の詳細については、 http://implausibleindustries.com/ を、また、 RESEARCH and DESTROY の詳細については、 https://rad-official.com/ をご覧ください。