Fateシリーズ初のスマホRPGはこうして作られた…『Fate/Grand Order』開発裏側が語られたセミナーを取材
クリーク・アンド・リバー社<4763>は、4月23日（土）、Unityエンジニアを対象に、TYPE-MOON/FGO ProjectによるFate新作RPG『Fate/Grand Order』とのコラボレーションセミナー「デザイン塾」を開催した。
これまで「デザイン塾」は、『白猫プロジェクト』『FINAL FANTASY Record Keeper』など人気コンテンツとのコラボレーションを実施してきた。
今回はディライトワークス株式会社が開発・運営を手掛ける『Fate/Grand Order』のエンジニアを講師として迎え、キャラクターの魅力をより輝かせる“Unityの活用術”についての講演が行われた。本稿では、人気ゲームの開発裏側が語られた講演模様を取材。
■アニメーションの制作過程も公開 きめ細やかな作業でブラッシュアップ
本講演では、『Fate/Grand Order』の開発・運営を手掛けるディライトワークスより、安生真氏、荻野洋氏の2名が登壇。キャラクターの魅力を表現するため、独自の手法でUnityを活用しているという同社のノウハウを解説してくれた。
▲安生真氏（写真左）、荻野洋氏（写真右）
はじめに安生氏より、本作におけるデザインのフローが語られた。はじめに『Fate』シリーズのシナリオを担当する奈須きのこ氏を中心とした各先生方から届くキャラ設定をもとに、ディライトワークスが動きのコンテを作る。このとき、コンテは原作を手掛けるTYPE-MOONで制作してもらっているという。これは、ディライトワークスでコンテを作ると、モーションの表現ができる、できないの線引きを無意識のうちにしてしまい、表現のハードルを設定しないための取り組みとのことだ。
▲ニコラ・テスラを題材に解説。テスラは3段階の進化を備えている。最初から描き起こしかつ、細かい装飾品があるため、パーツなどを分割しながら制作していったという。また、ゲーム内に登場するバトル中のキャラクターは、原作の等身より少し縮めているとのこと。
▲ラフ・線画・着色など、どの工程においてもTYPE-MOONのチェックが入るようだが、こうした定期的な確認のおかげで、キャラクターに起こる微妙なデザインの不安定さを、素早く見つけて修正できるようだ。安生氏は、「新キャラはもちろんですが、既出キャラクターは、ファンが抱くイメージが強いです。そこと齟齬（そご）が起こらないようにして、キャラクターのデザインやエフェクトを考慮します」と言葉を添えた。
デザインが出来上がったら、続いて動きを付けていく工程に。これまでの『Fate』を題材としたゲームでは、バストアップのノベルゲームを筆頭に、2Dキャラクターが活躍するミニゲームや、デフォルメ3Dのアクションゲーム、本格3D対戦格闘ゲームなど、多岐にわたる表現方法でユーザーを楽しませてきた。そして『Fate/Grand Order』では、スマホの表現力を考慮してビルボードを使用。
主に使用したツールでは、バトル実装においてPlayMaker、uSequencer。Unity環境をある程度学習する必要はあるが、慣れればプランナーでも十分に動画のモーション修正などが可能とのこと。その後は、出来上がったモーションを一度動画にして、遷移や作画を1コマずつチェックしていく。
ビルボードで表現するキャラクターの絵はセルルック、いわゆるテレビアニメ調の表現となる。フルコマではなく、動きを簡略化しセル画の枚数を減らしたリミテッドアニメの手法で動きを付けていく。そのため、決してヌルヌルと動かなくても、タメ・動き出し・ノビ・ノコシなど、しっかりメリハリの付いた動きを実現し、結果的にキャラクターの特徴が出やすく、印象に残りやすいようになった。
▲アニメーションの制作過程。赤線で動き、速度、高さなどを細かく指摘。既存キャラクターの場合はTYPE-MOONからの修正があるものの、初登場キャラの場合はライターやデザイナーと密に相談して決めていくという。「細かい修正のため、何が変わっているか一見では分かりにくいかと思いますが、確かに修正を通して良くなっています。地味な作業かもしれませんが、少しでもキャラクターが魅力的に見られるように意識しています」と安生氏。
▲TYPE-MOONから貰うアニメーションの絵コンテ。安生氏は絵コンテに対して、「最初は技術的な制約を忘れて、キャラクターにどういう動きをしてほしいのか描いてもらいます」と、原作の雰囲気を踏襲する形の制作フローを語った。
また、動きに関しては、ローンチ当初は一般的なゲーム制作と同様に、量産しやすい共通点を持たせて武器タイプ別に動きを記号化していく手法を取っていたとのこと。しかし、運営していくにつれて、遊んでいるユーザーの人数はもとより、各サーヴァントを始めとした登場キャラクターへの熱い思いが想像以上となり、今後登場するサーヴァントは出来るだけ動きを共通化しないことに方針を変えたという。
もちろん、動き（モーション）の非共通化をするのは、並大抵のことではない。当初管理していたフォルダも武器別に11個ほどだったが、こちらがキャラクターの名前フォルダに変わり段々と増えていったことを苦笑いしながら語ってくれた。確かに大変ではあるが、安生氏いわく「こういう動きをしたら格好いいよね、可愛いよねと、開発側もユーザーさんもしっかり納得できるような動きを目指すのは大事なことです」と言葉を添えた。
ちなみに、一部のユーザーからは「モーションが良くない」という意見も寄せられるという。本来ならば段々と良くなっているはずなのだが、じつはモーションのバリエーションが少ないローンチ当初のサーヴァントのことを指しているという。日を追うごとに動きが良くなってくる新しいサーヴァントに対して、より初期のサーヴァントが相対的に悪く見えてしまう問題があったようだ。
ちなみに現在は、アルトリアやギルガメッシュなど、初期サーヴァントの改修を行い、大変好評を得ているとのこと。今後も初期サーヴァントについては改修していくようだ。
■データ量を増やさず見た目を変える
続いて荻野氏が登壇し、上記のキャラクターやアニメーションなどを、どのように実装していくのかを語ってくれた。はじめにスクリーンに映したのは、開発初期のバトル画面だ。
▲当初は、2D背景で1対1で戦う構成だった。キャラクターの等身を検討した際も3～5等身を作成し、試行錯誤を繰り返しながら制作したという。
当初、平面的なキャラクターを動かす際に、多関節2Dキャラを動かすソフトウェア「Spine」を使うことを検討したが、3D空間で派手な動きをさせづらいことに気付く。特に横方向に槍を振り回すキャラクターなど、手前と奥に動きのあるキャラクターが難しいとのこと。
そこでSpineの使用を諦めて、3Dアニメーションソフトウェア「Maya」に切り替えることにした。
▲こちらがMayaで制作されたランサーのクー・フーリン。一見、平面にも見えるが……。
▲実際はメッシュを重ね合わせて“平面っぽく”制作されている。槍など横に振り回す武器は、3Dになっている。Mayaのエクスポーターで出力したfbxをほぼそのまま使用しているとのこと。
さて、基本的なモーション制作のフローも出来上がったが、開発側からは「もう少し動きが欲しい」ということになった。髪の毛の揺れなどはループアニメで解決できるが、キャラクターにエフェクトが表示される「インビジブル・エア」の問題にぶつかる。インビジブル・エアとは、登場キャラクターの武器を覆うオーラのようなもの。Mayaのみでは表現不可能、Unityでは制作可能とのことだが、Mayaでバトルキャラを作っているメンバーがUnity未経験という問題に。
これらはエフェクトをパッケージする「プレハブ」を後載せする形で解決。たとえば、右手、左手、頭など、何かをくっつける可能性がある部分にダミーノードを埋め込み、そのノードにプレハブ（エフェクト）をぶら下げるスクリプトを書くといった具合だ。
▲テスラの場合は、右手にエフェクトを乗せる。キャラクターの表現力が上がり、プレハブなので動かし放題に。
ここでひと段落かと思いきや、次なる問題は「データを増やさず見た目を変える」という要望が挙がった。というのも、ほぼ全てのキャラクターは三段階の進化を備えており、進化するごとにカードやバトルキャラもすべて絵が変わるようになっている。ただ、開発側からの要望としては、進化用の絵柄は増やしてもデータ量を増やさないで欲しいとのことだった。
そこで荻野氏は、テクスチャに進化分の素材（デザイン）を全て詰め込み、プログラムで表示・非表示を切り替える手法をとった。ボーン（骨組み）は極力共通化、テクスチャサイズは当初の1024×1024から、現在は2048×2048となっている。
▲こちらは3段階進化を全て表示している状態となる。3段階の進化分が入っていることもあり、心配されるのは負荷がかかること。しかし、必要のないデータは非表示にしているため、描写負荷に関してはおおむねかからないとのことだ。「テクスチャに関しては、画像の入ったものと、スカスカのものとでは、メモリのなかでは特に違いはありません」と荻野氏。
また、前述しているように、バトルキャラのモーションに関しては、出来る限りキャラごとにユニークにするとのことだったが、これらを“アプリ更新無し”という要望が降りてきたという。そこで用いたのは、コードを書かずにロジックが組めるUnityの有名アセット「PlayMaker」。主な使用フローとしては、はじめにデザイナーがMayaでバトルキャラ及び（攻撃）エフェクトを作成。続いて、PlayMakerのアクション（アニメ再生、音声再生、エフェクト生成など）をプログラマで書く。最後にUnityエンジニアが、それらを使って動きをつけて仕上げていく。
▲樹形図のように拡がるPlayMakerは、アクションに応じてキャラクターの次の動作に関わってくる。たとえば、このタイミングに来たらカメラを敵に向けてみたり、攻撃のタイミングでエフェクトが出たりなど、その設定・条件は多岐にわたる。
▲ちなみに、こちらはギルガメッシュのPlayMaker。一画面に収まらず、右にスクロールしていくこと、これの1.5倍はまだあるという。攻撃回数や立ち位置など考慮すると、様々な条件が必要となるため、1キャラとはいえこれほどの量となる。
見て分かるように、非常に気が遠くなるような作業だが、荻野氏は「面倒だが柔軟」とコメント。基本的な使い方としては、アニメーションの指定場所まで来たら次に進み、エフェクト表示や音声再生、移動などを行うのみだが、行動が多いキャラが増えてきたのが大変になっているという。ただ、Unityエンジニアいわく「実際に動いたところを見ると楽しい」とやりがいを覗かせた。
最後に起きた問題点は、宝具シーン。
▲宝具とは、サーヴァントが持つ切り札。いわばバトルにて鍵を握る必殺技のようなもの。キャラクターのカットインが入るほか、多彩なモーションにド派手なエフェクトが特徴な、ゲーム上で一番の見せ場シーンといってもいいだろう。
じつはこの宝具、PlayMakerで表現しようともなかなか実現が難しい。そもそもド派手な演出がゆえ、どこで何が起こっているか分かりづらい。それに伴い位置合わせ、タイミング合わせなどが柔軟に出来ないことが挙げられるという。PlayMakerはある意味特殊技能、それらを持たないデザイナーでも作れる必要があるのだ。
そこで活用したのは、Unityアセットの「uSequencer」。カットシーンエディタの機能を持つuSequencerは、シーンに置いたものを動かしたり、タイミングによって音を鳴らしたり出来るという。横軸が時間のタイムラインで編集できるので分かりやすく、よくあるゲーム内のデモシーンなどでも活用されるとのこと。
▲表示されるエフェクト・カットインをシーンに全部置き…
▲それらをuSequencerに割り当てて、あとはひたすらタイミング通りに動かしていく。
「宝具制作環境」を用意したことで、Unityエンジニアの工数を大幅に軽減することができたほか、スムーズな開発フローの構築にも繋がった。
また、荻野氏よりUnityエンジニアの役割についても語られた。いまいち定義がはっきりしないUnityエンジニア。プログラマーっぽいが、デザイナーのようなプランナーの側面も持つ。当然Unityはある程度使用できないとダメだが、実際にどのような業務をやるのか。
▲『Fate/Grand Order』におけるUnityエンジニアがやることの一部。その業務内容は多岐にわたる。
荻野氏は、現在の仕事に関して、絶え間ない『Fate』愛の重要性に触れつつも、「最終的には努力と根性ですが、工夫出来ることは色々とあります。臨機応変に」とコメントし、講演を締めくくった。
