FINAL FANTASY Record Keeperのマスターデータを支える技術

Copyright (C) DeNA Co.,Ltd. All Rights Reserved.
第6回 DeNAゲーム開発勉強会
DeNA史上最大級！
FINAL FANTASY Record Keeperの
マスターデータを支える技術
2015/08/24
GDI 渋川よしき

お前だれよ？
 前職
⁃ 自動車会社の社内SE
 現職
⁃ 社内ゲームエンジン用のフレームワーク
(クライアント用もサーバ用も)作ったり、
開発支援ツール作ったりいわゆる社内SE
⁃ たまにゲーム開発を手伝ったりもします。
渋川よしき
 プログラミング
 C++とかPythonとかGolangとかJavaScriptとか
 本
 つまみぐい勉強法、アート・オブ・コミュニティ(翻訳)、
Mobageを支える技術、オブジェクト指向JavaScript(翻訳)、
ポモドーロ・テクニック入門(翻訳)、etc

新書出ました！
 JavaScriptの、最速クライアント用MVCフレームワークの本です！
⁃ 速いのが好きな人や、変化が多いブラウザ周辺技術に疲れた人に
オススメ
 電子書籍のみです
 表紙は黒ムツの仲間
⁃ 南オセアニアの深海魚
⁃ 最大75cm
⁃ 確認された最高齢は
100歳を超えるとか

マスタデータとは？
 ゲームを支える要素
⁃ プログラム
⁃ アセット
• 画像とか2Dアニメーションとか3Dモデルとか音楽とか
⁃ マスタデータ
• プログラム・アセット以外
• シナリオ、テキスト、敵の強さなどのパラメータ
• レベルデザイン(3Dアクションのマップ)的なものはあまりマスターデータ
とは言わないかも・・・

マスタデータとは？
 ゲームを支える要素
⁃ プログラム →プログラマ
⁃ アセット →アーティスト
• 画像とか2Dアニメーションとか3Dモデルとか音楽とか
⁃ マスタデータ→ゲームデザイナ
• プログラム・アセット以外
• シナリオ、テキスト、敵の強さなどのパラメータ
• レベルデザイン(3Dアクションのマップ)的なものはあまりマスターデータ
とは言わないかも・・・

マスターデータの役割
 ユーザのプレイサイクルをデザインする
⁃ ユーザ体験のうち、UIとか画像とか音楽のような目や耳で感じる
以外のところ全般
• ステージクリアや、レベルアップのテンポだったり
• アイテムや必殺技、魔法などの種類とか性能だったり
• 敵の強さの調整だったり
• 会話やチュートリアルなどの説明だったり
 モバイルのオンラインゲームでは特に大事
⁃ 新しいイベントやステージを(アプリ本体の更新なしに)追加したり
⁃ ユーザが挫折しやすいポイントがあれば、それを修正したり

マスターデータの役割
 ユーザのプレイサイクルをデザインする
⁃ ユーザ体験のうち、UIとか画像とか音楽のような目や耳で感じる
以外のところ全般
• ステージクリアや、レベルアップのテンポだったり
• アイテムや必殺技、魔法などの種類とか性能だったり
• 敵の強さの調整だったり
• 会話やチュートリアルなどの説明だったり
 モバイルのオンラインゲームでは特に大事
⁃ 新しいイベントやステージを(アプリ本体の更新なしに)追加したり
⁃ ユーザが挫折しやすいポイントがあれば、それを修正したり
今日は、比較的スポットのあたりにくい
マスターデータの運用改善の紹介をします

Final Fantasy Record Keeper
 DeNA社内でもっとも複雑※なマスターデータを持つゲーム
⁃ すでに確立された世界観を持つ
• 炎耐性とか、弱点属性とか、前後列、カウンター専用技、ボスの状態の変
化など、かなり複雑な要素が満載だが、ユーザはすでにFFの世界を熟知し
ているので、ほぼフルスペックのFFのメカニズムが実装されている
⁃ しかも、各シリーズの最小公倍数
• 元ネタがあるので、コンテンツ追加の速度は速い！
• スクウェアエニックス社様の大事なIPであるため、文言やアニメーション
の監修もきちんと行う体制になっている
⁃ 開発が並列
• イベントが常に数本走っている
• イベントの開発も常に数本並行で走っている
• 機能追加も並列で！
※ 何人かのチームメンバーにインタビューした結果

マスターデータ運用で悲鳴があがり始める前(2014/11ごろ)
 Google Spreadsheetを使っている
⁃ 外部キー・主キーのような仕組みをGoogle Apps Scriptで実現
⁃ 社内でも実績のある仕組み
• かつてはExcelをリポジトリに入れてたりもしてたが、共同編集のしやすさ
から、今はGoogle Spreadsheetが主流
 Jenkinsを使った運用の仕組みは整備されていた
⁃ マスタデータのcsvを所定の場所に置いてスクリプトを起動すると、
整合性チェックを行ってテストサーバに投入したり、問題なさそう
ならgithub:eにプルリクエストを送ったりできた
⁃ 将来必要だけど今はいらないデータを行ごとにフィルタする機能

外部キー・主キーのような仕組みの例
※なお、このシートはツールのテスト用に大分昔にコピーしたものなので
実際のゲーム内のデータとは異なります
 わかりやすい名前で入力して、CSV生成時に主キーに置き換える仕組み

実際のマスターデータ
※シート間の関係を分析してみた結果
⁃ ゲームプレイに関わる部分のみ
⁃ 関連を複雑にする要素は一部抜いてます 10

FINAL FANTASY Record Keeperの開発の複雑さ
 そもそもデータが複雑で量が多い
⁃ データだけで多くの調整ができるようになっている
• 味方や敵の強さの調整
• 演出の調整
• イベントの追加
• ダンジョンに出現する敵のセットの定義とか配置とか
 同時にたくさんのチームが走る
⁃ 開発チームごとにスキーマを変更して追加のデータを増やしたい！
ということがよくおきる

少しずつ複雑化・・・
 クエスト機能(選択式チュートリアル)入れるよね
 レベルキャップ(50まで)を外す限界突破機能を入れよう
⁃ 限界突破したらレコードマテリアが使えるようにしよう
⁃ レコードマテリア装備したらいろいろな効果が
 必殺技付き武器を提供しよう
⁃ 熟練度を上げると、必殺技をマスターするよ
⁃ 超必殺技つけたらステータスアップあるよ
⁃ ☆5装備の鍛錬あるよ！☆5武器合成で武器のステータス上がるよ
 敵にHPゲージ付けよう
 BRABRAコラボイベントで音楽室を追加しよう
 ブレイク技が強いからボスに耐性つけよう

さまざまな問題が発生・・・
Google
Spreadsheet
Google
Spreadsheet
Google
Spreadsheet
Google
Apps Script
Jenkins
normalize
& check
デプロイ
スクリプト
CSV 1
/db/data/src
開発用
MySQL
CSV 2
/db/data/master
github:e
CSV 3 (dump)
/db/data/dump
本番
MySQL
ひとつのマスターデータを各開発ブラ
ンチで利用している
● 他のチームの変更(不具合)の影
響で作業が止まる
● 気軽に変更できない
ここに来ないと分か
らないエラーも多い
•必要なスプレッドシートを手でひとつずつ出力
•CSVの依存関係を手で解決
•時間がかかる (1時間程度)
•タイムアウトで仕事ができない(とくに夕方)
コンフリクト発生時に
修正が難しい

発生した課題
 複数人でもスプレッドシートのファイルは1つ
⁃ 変なデータを入れてしまうとデータ不整合のエラーで、
全チームの作業が止まってしまう
 エクスポートに時間がかかった
⁃ まっさらな状態からやろうとすると1時間近くかかる
⁃ 変更中に誰かが作業すると結果が変わってしまう
⁃ 調整が大変なので、シート構造変更をやろうとするとエンジニアの
MPがゼロになる
 カラム数が極端に多いシートも出てきた
⁃ 行数が5桁のシートを開くとブラウザが重い・落ちる
 Google Apps Scriptがタイムアウト
⁃ データ数が多くなってきたら、すねて処理してくれない
• 夕方の成功率が50%を切る(巨大なシートだと80%以上失敗)
⁃ Google Apps Scriptは自力でマルチスレッド化できないので遅い

マスターデータが問題を起こすと・・・
 データのエクスポートができない
⁃ データチェックは厳格に行われているがエラーがわかりにくかった
⁃ ログが大量に出力されていて、何が問題かを探すのも大変だった
⁃ 結果として、データ構造に詳しいエンジニアへの問い合わせが
増えて、昼ごはんをお昼に食べれないほど忙しい日々が・・・
たすけて
たすけてひー

マスターデータが問題を起こすと・・・
 データのエクスポートができない
⁃ データチェックは厳格に行われているがエラーがわかりにくかった
⁃ ログが大量に出力されていて、何が問題かを探すのも大変だった
⁃ 結果として、データ構造に詳しいエンジニアへの問い合わせが
増えて、昼ごはんをお昼に食べれないほど忙しい日々が・・・
たすけて
たすけてひー
「高橋慧さんがお昼を昼に食べれる」
というのを目標に設定
20

開発規模に見合うスケール可能にする仕組みの導入を検討
1. 縦に長いシートをイベントや定常
などのリリース時期ごとに分割
2. スプレッドシートのファイル群を
グループ(フォルダ)に分ける
3. エクスポートするときにどのグ
ループを出すか、ゲームデザイ
ナーが選択できるようにする
4. 扱うファイル数が増えるので、一
括出力の仕組みが必要そう

改良1: バッチコマンドラインツール化
ファイル一覧
のシート取得
ファイル一覧で指定
された名前のファイル
のキーのリストを作成フォルダの全子要素の
キーと名前を取得
ファイルをダウンロード
ファイルをロードし、
JSONSheet /
JSONFormatを分析
•RefListTemplateを元に
値の置き換え
•CSV出力
 入力ファイルは変更なし
⁃ 運用しながらランニングチェンジ
 Golangを使いスレッドプールでとことん並列化した
⁃ コマンド一発で最新データを一括取得
⁃ 処理自体もずいぶん早い
⁃ ついでに、バイナリなのでアクセストークンとか秘匿できて良い

バッチコマンドラインツール化の結果
 読み込むシート一覧のシートを作成
⁃ 誰がやっても(企画でもエンジニアでも)、ほぼ同じ結果が即座に
得られるようになった
• 問題の追跡が楽になった
• 「データを通すため」の作業が減り、「良いゲームを作るため」の時間が
増えた。
• Jenkinsから呼んだり、コマンドラインから使ったり
⁃ テストサーバに投入するまでの時間が100倍ぐらい早くなった
 エラーメッセージや警告を日本語で出せるだけ出すようにした
⁃ 問題追跡をゲームデザイナーだけでできるように
⁃ 初めて実行した時は警告が4000件ぐらい出た

改良2: 並行開発のサポート
ダンジョン名リリース
カオス神殿定常
西の城定常
[初級]ナルシェエドガー・マッシュ
[初級]西の炭鉱エドガー・マッシュ
[初級]マルディアスエンサガ
[中級]マルディアスエンサガ
 同名シートでもリリース時期によって
ファイルを分割できるようにした
⁃ 「このイベントではどのファイルを組
み合わせるか？」というのは柔軟に設
定できるようになった
⁃ 開発始まったばかりの不安定なシート
の参照がスキップされるので、他の人
の影響で仕事が止まることが減った
⁃ ブラウザの負担も減ったダンジョン名リリース
カオス神殿定常
西の城定常
[初級]マルディアスエンサガ
[中級]マルディアスエンサガ
[初級]ナルシェエドガー・マッシュ
[初級]西の炭鉱エドガー・マッシュ

並行開発のサポートの実装(1)
ファイル一覧
のシート取得
ファイル一覧で指定
された名前のファイル
のキーのリストを作成フォルダの全子要素の
キーと名前を取得
ファイルをダウンロード
ファイルをロードし、
JSONSheet /
JSONFormatを分析
•RefListTemplateを元に
値の置き換え
•CSV出力
 バッチ化で土台ができていたので、少し改造して「シートを後からマー
ジ」できるようにした
⁃ 全イベント・定常が単一ファイルで管理していたときと、まったく同じCSVを
出せるようにしたので、後工程はそのまま変更なし
⁃ 2月末リリースのライトニングイベントから順次シート切り分け
⁃ ついでにIDが同じなら同名シート内で新しい情報で上書きできるように
同名のシートで
グループ化

並行開発のサポートの実装(2): Rel更新プログラムの改善
 今まではGoogle Apps Scriptで、
スプレッドシートの「データの検
証」機能を設定していた
⁃ 並列処理できないので遅い
⁃ よくタイムアウトで止まる
⁃ 1ファイルずつやらないといけない
データの検証
更新プログラム

 ここもバッチプログラムを作った
⁃ シートに設定するところはGASの方がやりやすかったので最終段はほぼそのまま
⁃ 情報取得してプルダウンメニューの項目リスト作成する部分はバッチ化と同じ
ライブラリを使って並列ダウンロード
⁃ GASは自前でスレッドは起こせないが、ウェブサービス化して並列してリクエス
トを投げれば並列処理できる(x10まで)
並行開発のサポートの実装(2): Rel更新プログラムの改善
データの検証
更新プログラム
30

並行開発のサポートの結果
 新しいカラムの追加などは、イベントごとに行えるようにした
⁃ グループには親子関係があり、親の機能追加は子にも反映
 イベントリリースにあわせて途中からパラメータの変更をできるように
⁃ 例) イベントのキャラ配布にあわせて装備できる武器の
種類を増やしたい
⁃ →リリースタイミングで設定を上書きできるようにした。
 リリース後は？
⁃ カラム追加や上書きは大本のシートに移動する運用ルール
⁃ リリースされている現在の状態は大本のマスターにある、というの
が事故を防ぐのに大事

結果
 リリースしてから1ヶ月で1000回以上実行された
⁃ 900時間以上節約
⁃ といってもチームの人数が減ったわけではなく、負担が減ってその
分多くの調整が回せるようになった

目標も達成！

補助機能(1): ブラウザでプレビュー機能
 問題の追跡に使う
⁃ どのシートから出力されたか？ソースはどこファイルのどの行？
⁃ Relで設定した日本語の名前は何？
⁃ 出力設定はどのファイルから来たの？

補助機能(2): セル・文字単位のdiff表示機能
 カラム数が多いシートもあるし、カラム追加などでは全行差分になって
しまうので、プルリクエストのページだと差分を確認しにくい
 色はgithubに合わせた

補助機能(3): Google Spreadsheet用のblameコマンド
 シートの行ごとに、最終編集者と変更日時を表示

さらなる機能追加とか高速化とか
 リリース時期のフィルタ機能を内部に取り込んだ
⁃ それまではPerlスクリプトでエクスポート後にフィルタしていた
⁃ ツール内部にこの仕組みを取り込むことで、有効なデータかどうか
を判断して、より厳しいチェックが可能になった
• 警告・エラーと二種類メッセージを用意していたが、最終的に「別シート
で同一IDのものを上書きした」以外はすべてエラーになった
• エラーは日本語で出すようにしています
 Golangのxlsxパースは遅いしメモリ食う
⁃ zlib+XMLのパースで、ファイル変更がなくても40秒近くかかる
• Jenkinsサーバ上で、たまにOOMキラーに・・・
⁃ JSON+LZ4(高速な圧縮アルゴリズム)でキャッシュして15秒に
⁃ MessagePack+LZ4でキャッシュすると6秒ぐらいに

ぶっちゃけGolangどうよ？
 スクリプト言語並に書きやすいC/C++
⁃ 速度は十分(xml, jsonのパース以外は)だし並列化しやすい
• 同じことをC/C++でやろうとすると結構ツライ
• 「C++と違ってその日のやる気が生産性に影響しない良い言語」(同僚談)
⁃ IntelliJ IDEA + golangプラグインで開発はしやすかった
⁃ ライブラリも多い
⁃ クロスコンパイルがしやすいのが良い
• Jenkins用(Linux)やデザイナー用(Windows)、エンジニア用(Mac)を
簡単に作ってリリース
⁃ コンパイル時チェックが厳密なのでいじりやすい
• ロジック以外のテストはそんなに書かなくても困らない
• 社内ツールは要望や報告が来て1ヶ月ぶりにコード触るとかが多いので楽
 とはいえ、Jenkins上や開発環境上のツールとしてしか運用していない
ので、サービス運用のノウハウはまだなし
⁃ DeNAで「バリバリ使ってます」とはまだ言えない・・・
⁃ USは使ってます

まとめ
 チーム規模に負けない仕組みを整備した
⁃ 運用を止めずに大幅なワークフローの変更を行った
⁃ 開発期間におけるデータ入力の手間を大分減らすことができた
• きちんとお昼にお昼ごはんを食べられるようになった
⁃ 効率アップは10%じゃなくて10〜100倍だと仕事の流れが変わる
 運用しつづけていくタイトルにおいて、企画とシステム開発は両輪
⁃ プログラマの人は、エディタとかの話好きだよね？
⁃ 企画側も仕組みをがっつり整備していくことで運用がしやすくなる
 他の運用中・新規タイトルにも絶賛水平展開中
40

FINAL FANTASY Record Keeperのマスターデータを支える技術

More Related Content

FINAL FANTASY Record Keeperのマスターデータを支える技術