“NieR”の独特な世界観を表現するために　エンジニア、デザイナーのイテレーションを素早くした“Rapid開発”

3Dや2Dを織り交ぜた独特な世界観『NieR Re[in]carnation』の開発

杉浦優介氏（以下、杉浦）：それでは「NieR Re[in]carnationの開発」と題して、株式会社アプリボットの杉浦から発表します。こういった場で発表するのが初めてなので温かい目で見てください。

まず自己紹介をします。私の名前は杉浦優介と申します。所属はアプリボットのNieR Re[in]carnation開発チームです。Unityのクライアントエンジニアとして、ゲーム全般のUIを担当したあと、通信部分やゲームのメインフロー部分を担当しています。新卒でサイバーエージェントに入社して今年で3年目です。

発表するのはこのような内容です。新しくリリースされた『NieR Re[in]carnation』の開発について説明したいと思います。まず始めに『NieR Re[in]carnation』についてです。『NieR Re[in]carnation』は（2021年）2月18日にリリースされた新作のスマートフォンゲームです。おかげさまで100万ダウンロード（※取材当時）を突破しました。ありがとうございます。これはそのキービジュアルです。

ゲームの特徴は、ニーアシリーズの最新作であることです。ニーアシリーズは主に家庭用ゲーム機用に発売されてきた『NieR Gestalt』『NieR RepliCant』『NieR:Automata』に続く作品です。今回はその最新作として、スマートフォン向けに開発を行いました。

ニーアシリーズ全体の特徴の1つが、ヨコオタロウさんが手掛ける独特なストーリーです。『NieR Re[in]carnation』はそのストーリーを表現するために3Dや2Dを織り交ぜた作品となっていて、独特な世界観を表現しています。

プランナーとエンジニア間のイテレーションを少なくするようにした

これが本作品の3D探索部分である「ケージ」と呼ばれるものです。写真は実際のゲーム内のものです。次にこれが各キャラクターごとのストーリーを掘り下げるパートである「メモリー」です。2Dを使った表現で、各キャラクターの独特な世界観を作っています。最後にこれが本作の戦闘システム部分です。戦闘システムはコマンドバトルで3Dで表現しています。

今回はこれらがどのように作られているのかを、とても広く浅くですが紹介したいと思います。まずはじめに、開発ツールとイベントマップについて紹介します。本作品は、先ほど述べたようにストーリーが売りであり、よりこだわった演出を作りやすい環境を作る必要がありました。また、ストーリー上で登場するギミックなどは同じ機能や組み合わせのものが多く、使い回しやすい仕組みを作る必要がありました。

そのため、本作ではノードベースの開発ツールを自作して、それをふんだんに活用しています。1つ目はBehaviour Treeです。ご存知の方も多いかもしれませんが、ゲーム内ロジックを作成するのに適している仕組みです。左の図のように、HPがいくつだったらという条件を表すノードと、実際の行動を行うアクションノードの組み合わせでロジックを作成します。これらを本作品ではエディタ拡張で実装して、主に戦闘システムの敵AIなどで利用しています。

次にイベントエディタです。これは、一般的にはステートマシンと呼ばれる状態管理に適した仕組みです。左の図のように、ゲーム全体の流れを各ノードの組み合わせで表現します。Behaviour Treeも同様ですが、一度作ったノードは使い回せるので、開発の終盤になるほど作らなくてはいけない機能を減らせるというメリットがあります。これもエディタ拡張で自作していて、主に先ほど紹介したストーリー部分で利用しています。

次にイベントマップについて説明します。イベントマップとは、イベントエディタを活用して作成したストーリーを表現するためのマップで、本作品のストーリーはほぼすべてこの仕組みで作られています。エンジニアが作成したノードを利用して、プランナーがイベントエディタを用いてストーリーの流れや演出を表現して、それをアセットとして配信することで、各ストーリーを管理しています。

表現したいストーリーの流れや演出をプランナーさんが完結して作れるため、プランナーとエンジニア間でのイテレーションが少なく、素早く量産できるのが強みです。

次に、ゲームの戦闘システムやシナリオパート以外の部分の、アウトゲームの作り方を説明します。本作品はとにかくUIにこだわりたいという思いがあり、イテレーションを素早く回してクオリティを上げていく必要がありました。また、エンジニアリング面では誰が書いてもコードの内容があまり変わらないような仕組みを作って、量産しやすくしたいという思想がありました。

さらにUIアニメーションにもこだわりたいというデザイナーの意見をもとに、UIアニメーションの動きは基本的にはデザイナーさんが完結して作れるようにする必要がありました。

「Rapid開発」と命名。効率化のために仕組みを作成

これらを踏まえてやったことを順番に説明します。本作品では「Rapid開発」という独自の命名をつけて、実機に最速でアウトゲームの全機能の遷移をつなげることを目指して開発しました。デザイナーが作成したPhotoshopの画面構成データに少し手を加えることで、UnityのPrefabに直接変換できる仕組みを作成しました。

また、見た目だけではなく、各ボタンやスクロールバーなどのパーツがそのまましっかりと動作する仕組みも追加しました。Step1からStep3の段階に分けて、作り直しのコストが最小限になるようにStep1、Step2でイテレーションをして、完成したもののみをStep3として実装しました。

次にアウトゲームの設計について説明します。設計は基本的にMVPパターンに沿ったシンプルな実装です。ピュアなuGUIは基本的には使わず、テキストやボタン、スクロールビューなどはラップするか自作をしています。例えば、ローカライズがとても簡単にできるテキストコンポーネントや、長押しや連打に対応したボタンコンポーネントなどを作りました。

さらに画面遷移の仕組みは、各画面をScreenという単位で管理して、遷移の履歴保持や画面の状態保持、各画面の生成破棄などの仕組み化を行っています。これは同じSGEの子会社であるQualiArtsの方が書いたブログを参考に作成しました。

次にUIアニメーションの作り方について説明します。本作品では、UnityのAnimatorとAnimation Clipを利用して、ほぼすべてのUIアニメーションを作成しました。これらを選択した理由は、社内にUnityにある程度慣れたUIデザイナーさんがいたことと、デザイナー側で細かい調整までしたUIアニメーションを作りたかったことが挙げられます。

エンジニアが指定するのは、各ヶ所のアニメーションでどれを再生するかというところまでで、実際の細かい動きなどはすべてUIデザイナーさんが完結して作れるようにしました。このやり方は、UIデザイナーさんが自由にアニメーションを作れるのでとても有用ですが、Tweenなどを活用したものに比べるとAnimation ClipのUIアニメーションはロードや処理の負荷が大きく、場合によっては向かないこともあるので注意してください。

独自のバグ報告機能で不具合を感知したら即時に共有

最後に、細かいシステム部分などをざっくりと紹介します。

まずアセット管理についてです。アセットの管理には、Perforceというツールを使用しました。これは大きなサイズのバイナリファイルの管理などに向いたツールで、本作品では非常に大きなサイズのモデルデータを多く取り扱っていたため、Perforceを採用しました。結果的に3Dモデルに加えて、今では2D画像など、アセットとして配信したいものはすべてPerforceを利用して管理しています。

次にアセットの配信は、SGE内で実績のあるAssetBundle配信基盤のOctoを利用しています。これは汎用的なロードやキャッシュの仕組みに加えて、アセットの管理画面なども提供しているため、SGEの多くのタイトルで利用されています。

次に通信回りです。通信はgRPCのUnary RPCsで行っています。クライアントとサーバーのリクエスト、レスポンスはProtocol Bufferを利用しているので、自動生成されます。さらにAPIの呼び出し部分も自動生成ができるようにして、型付きで統一的なインターフェイスを用意しています。マスタデータの管理には、先ほど河合さんが紹介したMasterMemoryを使用しています。

最後にデバッグ回りについて説明します。デバッグ回りは主にSRDebuggerを活用しています。SRDebuggerは、Unityのアセットストアにて購入が可能なデバッグメニュー作成ツールで、高い拡張性を持っています。今回のプロジェクトでは、バグ報告機能を独自で追加していて、ゲームをプレイしている中で怪しい挙動があった場合には、その時点のアプリ名やサーバー情報、スタックトレースなどバグの原因調査に必要な情報が即時にチャットツールなどに投稿されるようになっています。

とても駆け足になりましたが、今後もいろいろんなメンバーがいろいろんなところで『NieR Re[in]carnation』の開発について発表すると思うので、機会があればぜひそちらも聞いてみてください。これで発表を終わります。ご清聴ありがとうございました。

司会者：ありがとうございました。それではさっそく質疑応答に入っていきたいと思います。

司会者：質問をいただいたので、お好きに回答いたただければと思います。

杉浦：（イベントマップはどのような形式で管理されていますか？という質問に対して）イベントマップの出力は、ScriptableObjectではなくて独自のファイルですね。さっき言ったステートマシンファイルです。

司会者：ありがとうございます。

杉浦：「エディタ画面を見てみたい」はちょっと厳しいと思います。そうですね、プランナーもUnityをメチャクチャ触っていますね。デザイナーもさっき言ったように基本全員Unityを使って各画面を作っています。

司会者：ありがとうございます。質疑応答は以上です。杉浦さんありがとうございました。

杉浦：ありがとうございました。