GMOアプリクラウドは、6月15日、GMOインターネットグループが運営するコミュニケーションスペース「GMO Yours」にて、「ゲーム開発と技術力」をテーマとしたイベントとして、「現場のエンジニアが語る『Fate/Grand Order』の開発技術からアップデートに関するノウハウまで一挙公開」を開催した。
本イベントでは、ゲーム運営や開発に関わっている方々を対象に、『Fate/Grand Order』の開発をリリース当初から支えるサーバーエンジニアと、ディライトワークスの技術力向上のために、日々課題に取り組んでいるテクニカルディレクターによる「面白いゲームの作り方」や「海外展開に向けた取組み」について技術的側面から講演を行った。
本稿では、ディライトワークスの今井守生氏が登壇した、第一部「定期的な更新、かつ長期的な運営を行っていくための開発手法」についての内容をレポートしていく。
第一部では、2015年7月のリリース後、新しいイベントや新しい機能、既存機能の不具合修正などの更新を繰り返してきた『Fate/Grand Order』において、今井氏が開発・運営を続ける中で感じた「定期的な更新、かつ長期的な運営」をしていく上で大事なことについて、データ構造の設計方針などの観点からトークを展開した。
■今井 守生 氏（ディライトワークス株式会社）
ディライトワークス株式会社 サーバーサイドプログラマ。大学卒業後、システムエンジニアとして就職。その後、ゲーム会社に転職し、スマートフォン向けゲームの開発を担当。2014年からディライトワークスにて『Fate/Grand Order』のサーバ側プログラムを担当。
▲まず今井氏は、ディライトワークスについての紹介を行った。2014年に設立されたディライトワークスの社員数は現在150名以上で、これまでに『Fate/Grand Order』や『バンドやろうぜ！』などのタイトルを開発している。
続いて、講演のテーマでもある『Fate/Grand Order』を紹介した。2015年7月に配信を開始した本タイトルは、2017年5月までに900万ダウンロードを突破。App StoreやGoogle Playのセールスランキングで度々1位を獲得しているほどの人気作だ。
■定期的な更新について
ここからはいよいよ開発の具体的な話へ。『Fate/Grand Order』では、ほぼ毎週、マスタデータとアセットバンドルの更新を行っている。ここでは、小～中規模のイベントやキャンペーンを始めるためのアップデートとして、アプリ更新なしで開始できるイベント・キャンペーンや、軽微な不具合修正はこれにあたる。
また、約1ヶ月に1度、アプリ更新による大規模なイベントや新章のためのアップデートを行っている。新しいイベントやメインシナリオで使用する機能、恒常的な新機能、既存機能の改善、大きな不具合修正はこのタイミングで実施している。
続いて、今井氏は上記スケジュールのように更新頻度が高い中、どのようにしてマスタデータを管理しているかを説明した。
【マスタデータの要件】
1.入力はExcelが良い
マージができない、重いといった欠点はあるが、多くの開発者が使い慣れているというところで最終的にはExcelが良いとのこと。
2.複数人で入力する
アップデートの頻度が高いほどひとりで対応するのは難しくなるため、複数人で作業にあたっている。
▲例として、イベント用とクエスト用にファイルを分けてデータを管理しているとの話。クエストに関しては入力内容が多いので、アップデートごとにファイルを分けているという。
3.ほぼ毎週、本番マスタデータのアップデートを行う
4.複数のアップデートの開発を並行して行う
1、2カ月先、または1週間先のアップデート開発を並行して行っている。
5.なるべく1つのExcelにまとめたいテーブルがいくつかある
様々なテーブルから参照されているテーブルは複数のExcelに分けず、ひとつのExcelにまとめて同じシートにする。
6.未来のアップデート内容を配信しない
未公開のサーヴァントや次のイベントの情報が漏れてはならない。クライアントが表示を制限すれば良いというわけではなく、マスタデータはクライアントに送った時点で解析されるリスクがあるため、そもそも配信しないという仕組みが必要。
▲ひとつのシートにデータをまとめつつ、段階的にリリースをしていきたいという意図から、シート内に区切り文字（タグ）を入れて分割している。
▲また、Excelファイルは内製ツールでCSVファイルにコンバートした際に、それぞれのタグでフォルダが出力されるようになっているとのこと。
▲これにより、フォルダを指定した状態でマスタデータを更新することで段階的なリリースを可能にしている。この方法なら、アップデートごとの差分確認を行いやすいほか、複数のQAを同時に進めることができる。
以上、マスタデータの管理についてのワークフローをまとめると下図のようになる。
さらに、「特定の日時から、新しいイベントやキャンペーンをメンテナンスを入れずに始めたい」という要件が追加されるケースでは、下記のようにして対応していると説明した。
「ユーザ全員のポイントの合計値（もしくは与えたダメージや撃破数の合計値）が、特定の値に達したら次のクエストを配信したい」、「そのクエストが配信される前に解析されてはいけない」の2つの要件を満たすためには下記のように対応している。
▲過去には、この要件に対して手動でマスタデータの更新を行い対応していたが、作業が深夜になることもあり辛いというところから自動化を検討して今の形になっているとのこと。
ここからは、「データ構造の管理方法」について説明。
▲例として、「value」カラムを追加したい場合、「value」カラムを追加した後に別バージョンの定義書として保管して管理している。
▲バージョンを指定してmigrateツールを実行することで該当のDB構造に即座に切り替え可能にしている。
ここまでの内容を今井氏は、下記のようにまとめた。
・「段階的にリリースしていくための管理方法」を工夫する
・管理方法に正解はなく、そのプロジェクトの要件に合った方法を選択する
■長期的な運営について
続いて、長期的な運営を見越したうえでデータ構造をどのように設計するかという設計方針についてトークを展開。ここでは、クエスト解放条件のマスタデータを例として話を進めた。下図の例では、案1と案2のような形が考えられるが、ここで今井氏は「本当に用件はそれだけでしょうか？」と疑問を呈する。
例1.クエスト開放条件
というのも、運営を続けていく以上、「今は」要件がそれだけでも運営を続けるうちに必ず増えていくのだという。
▲要件が増えた際、強引に対応しようとするとカラムが増え無駄なデータが溜まってしまう。
では、拡張性のない状態を打破するためにはどのようにすれば良いのか。今井氏は次のように解説した。
▲クエストマスタと開放条件マスタを別々に分け、必要な条件のみを定義する。さらに、開放条件マスタは条件タイプを指定することで条件IDの意味が変わるようになっているため、無駄なデータが減り、拡張しやすい構造にしている。
また、上記の手法ではOR条件に対応できないため、「条件グループの追加」や「特性クエストグループクリアというタイプを作成して条件IDで別マスタを参照」、「条件IDを配列で作成する」といった方法で対処することが可能であると紹介した。
例2.クエスト報酬アイコン
2つ目の例は、クエストボードの報酬アイコンについて。『Fate/Grand Order』では、報酬のアイコンをそのまま表示することもあれば、汎用的な宝箱を表示することもある。また、報酬が2種類ある場合はアイコンを交互に表示している。
これには、アイコンIDが0かどうかで場合分けをしている。
▲例として、報酬アイコンIDに1以上の数字が設定されていた場合、その数字に紐付くアイコンが表示される。0の場合は、実際にクエストに設定されている報酬IDから報酬マスタを参照してアイコンを表示している。
最後に今井氏は長期的な運営を見越したうえでのデータ構造について、下記のようにまとめた。
・マスタデータは「拡張可能な構造」を考え、汎用的に対応できるようにする
※今日話した内容はあくまでも一例
・これまでの要望などから、「後々必要となりそうな拡張」を想定する
特に、『Fate/Grand Order』では、メインシナリオ中の特殊なイベントを実現するために、特殊な実装が必要になることが多いという（※例えば、特定のクエストをクリアするとサーヴァントの真名が判明するなど）。また、新規イベントでは毎回必ず新しい機能が必要になる。
さらに今井氏は様々なことを想定して設計しても、どうしても想定外の事象は出てくると語る。実例として、サーバプログラムとマスタデータで問題を解決しなければならなかった状況に直面した際の対処法を紹介した。
・リリース前日、かつリリース日はずらせない
・とあるクエストにて、挑戦するたびに約2分のムービーを見る必要がある
・ムービーのスキップ機能を入れるにはアプリ側の改修が必要
・iOS審査を出し直す猶予はない
▲問題となっているクエストを全く同じ内容で、ムービーありの「クエストX」とムービーなしの「クエストX’」の2つを用意することで解決したという。
これについて今井氏は、「ゲームを遊びやすくするためには時には強引な実装で対応」することも必要だとした。ただし、これは極端にサーバに負荷をかけない範囲であることを付け加えた。
本講演の最後には、長期運営におけるプログラマとしての心構えを紹介して講演の締めとした。
既存機能での代用
「特定のサーヴァントでないと出撃できない」という機能を活かして、「サポートでしか出撃できないクエスト」を実現した。用途は異なるが、”出撃を制限する”という意味で近い意味を持つため上手く拡張に繋げられている。このように、『Fate/Grand Order』では、新機能を実装する前に既に似たような機能が入っていないかをチェックしている。
仕様変更の提案
新機能の実装依頼があった際、言われたとおりに実装して似たような機能が増えたり、工数がかかったりすることは避けたい事象である。そこで必要になるのは、新機能の「意図」を理解することが重要であると説明した。
【本講演のまとめ～定期的な更新、かつ長期的な運営のために】
・各アップデートごとのマスタデータの管理はしっかりと行う
・新機能の開発時は拡張性を考慮して設計する
→既存機能の拡張で実現できないかも同時に考える
・最終的には「ゲームとして面白いか」を判断基準として、時には強引な実装で対応する
→すべては「長く愛されるゲーム」にするために…
（取材・文 編集部：山岡広樹）
