モバイルゲームにおけるマスターデータ運用事例

こんにちは。Wright Flyer Studios部のにしだ(@hosi_mo)です。LINE タワーライジングのメインプログラマを担当しています。

こんかいは趣向を変えて、“モバイルゲームにおけるマスターデータ運用事例"という題で、タワーライジングでのマスターデータの運用まわりについてお話しいたします。

ゲームの実装はこちらを参照ください。slideshare : http://www.slideshare.net/greetech/towerrising

※この投稿は GREE Advent Calendar 2015の18日目の記事です。

 

マスターデータとは

マスターデータとは、ゲーム内で不変の共通パラメータ群のことを指します。モバイルゲームにおいては、アプリのバイナリアップデートをせずにゲームに反映できるよう、起動時に最新のマスターデータを引っ張ってくることが多いです。ExcelやGoogle Spread Sheetにプランナーがパラメータを入力して、jsonなどに変換してゲームに反映させます。

素直に実装した場合の、マスターデータの流れは以下です

1. プランナーがシナリオ、パラメータ等をxlsに入力する
2. プランナーがExcelを専用レポジトリにpushする (図参照 : ①)
3. Jenkinsがhookでjobを発行する (図参照 : ②)
4. jobがScriptを叩いて コンバートする (図参照 : ③)
5. マスターデータレポジトリに自動でpushされる (図参照 : ④)
6. Client / Serverエンジニアが適宜submoduleをpullする

Unityなプロジェクトでは、EditorScript経由でAssetBundle化したマスターデータと、ScriptableObject, サーバ向けデータ(cvsなど)を出力するケースもあるかとおもいます。
まずは、入力ツールの選定についてお話しします。
 

ツールの選定 : Excel vs Google Spread Sheet

弊社で実績のあるマスターデータ管理ツールは、ExcelとGoogle Spread Sheetです。

それぞれ、過去に担当したプロダクトで利用した経験がありましたので、それぞれ利用した上での利点欠点をまとめてみました(主観です)

(i)Excel

Excelをjsonやtsvなど、プロダクトに合わせたデータ形式に変換するスクリプトを書きます。

利点

Excelで一元管理することで、プランナ－の使い慣れた環境を提供する。
マクロが優秀

欠点

差分が確認しづらい(githubでExcelファイルのdiffがそもそも見れない)
同時に編集が出来ない
履歴が追いづらい

 

(ii)Google Spread Sheet

Google Apps Script経由でプロダクトに合わせたデータ形式に変換します。

利点

同時編集が可能
リビジョンが追える

欠点

プランナ－に不評だった(ブラウザで巨大なテーブルいじるのには限界が…)
Google Spread Sheet側が調子の悪いタイミングで、ちょうどマスターデータの緊急リリースが入ったときに祈るしかなかった

 

たまにいるExcelを極めたプランナ－の作業を邪魔したくなかったり、リリースのタイミングでGASが調子悪かったりした経験をふまえて、弊社のネイティブゲーム事業においては、Excelでのマスターデータ入力がいまの主流となっています。

 

よくある/ぶちあたる事例

Excelでマスターデータを入稿し、デプロイする流れをそのまま実装すると以下のケースにぶちあたります(ぶちあたりました

• Develop環境、QA環境、本番環境でそれぞれマスターデータを出し分けしたいと言われる
• マスターデータのバージョンごとの差分が見たいと言われる
• データ入力ミスったら教えて欲しい
• 複数人で同時にマスターデータを触れるようにしたい
• などなど

 

単にマスターデータを入稿するなにかしらのJobをJenkinsにやってもらうだけでは不十分で、運用するうちにさまざまな要望がエンジニアに寄せられました。

運用中に、これらの要望を受けて少しずつ改善をしてきました。次項で、いま現在のタワーライジングにおけるマスターデータの入稿フローの概要と、改善内容をお話しさせていただきます。

 

現在のマスターデータ運用

現在のタワーライジングでのマスターデータの入稿の流れは以下です。差分を太字にしておきました。

1. プランナ－がシナリオ、パラメータ等をExcelに入力する
2. Excelファイルの保存イベントがhookされてcsvが吐き出される (図参照 : ①)
3. プランナ－がExcelとcsvを専用レポジトリにpushする (図参照 : ②)
4. JenkinsがhookでConvertするjobを発行する (図参照 : ③)
5. jobがScriptを叩いて jsonへコンバートする (図参照 : ④)
6. マスターデータレポジトリに自動でpushされる (図参照 : ⑤)
7. Jenkinsがhookでバリデーションのjobを発行する (図参照 : ⑥)
8. Validatorスクリプトがjsonファイルを検証する (図参照 : ⑦)
9. 結果を通知チャットへ送信する (図参照 : ⑧)
10. Client / Serverエンジニアが適宜submoduleをpullする

詳細な改善点を以下で紹介します。

 

改善 : 差分が見れない

Excelの形式をxlsmに移行し、Excelアプリケーションの保存イベントをhookして、シートに変更があると自動でcsvを吐き出すようにしました。

タワーライジングチームでは、実装担当のエンジニア(Mac)も、プランナ－を始めとする企画職(Windows)もExcelファイルをいじるため、Mac・Windows問わず同じ形式のcsvを出力するVBAを実装し、Excelの中に仕込んでいます。

これにより、プランナ－がExcelを変更してレポジトリにpushする際に自動でcsvもpushされ、github上で差分が追えるようになりました。

 

改善 : データ入力ミスったら教えて欲しい

理想的には、ルールベースでマスターデータのシートごとにリレーションを考慮したバリデーションする素敵なツールが存在することでしたが、そんな夢は叶わずに泥臭い運用をしています。

お手製のValidator(実装はなんでも良いのですが、うちではRubyで頑張っています)が動いていて、マスターデータにカラムが追加されたり、定義が増えたり、企画から要望があるごとに、エンジニアが手動でValidatorにif文を追加しています。エンジニアの優しさ、ホスピタリティによって支えられています(辛)

最新のrooは、xlsmの読み込みも対応しているので助かります。
https://github.com/roo-rb/roo
 

改善 : 環境ごとの切り分けがしたい

Excelを分割して入稿しても、出力時にマージしてマスターに反映するようにしました。

itemというマスターデータに12/18から反映したいレコードがあることを想定すると、下記の図のように差分レコードのみ別ファイルで作成して、レポジトリにpushすると、自動でマージされて出力されます。

これにより、例えば下記のようなファイル分割によって担当者ごとでファイルを分けて入稿したり、

• item_data_original.xlsm
• item_data_nishida.xlsm
• item_data_tanaka.xlsm

下記のようにイベント施策のデータのみ入稿するといった作業が可能になりました。

• event_data_original.xlsm
• event_data_xmas.xlsm
• event_data_new_year_2016.xlsm

また、開発環境ごとに違うマスターデータを反映したい場合も、好きな差分ファイルのみそれぞれの環境にpushすれば反映されるようになりました。

 

通知

Engineer x プランナ－のチャットを作成
マスターのvalidationで不正なデータがあるとチャットで通知するようにしました(よくある手法ですが、、)

おまけの通知

ついでに作った機能なのですが、最強装備の組み合わせ検索による攻撃力の最強装備セット、防御力の最強装備セットのような装備の組み合わせをそれぞれのパラメータごと(HP, 攻撃力、防御力など)にチャット通知する機能をつくりました。ただでさえパラメータインフレゲーであるタワーライジングなので、プランナ－にかなり喜ばれました。(予期せぬ組み合わせでパラメータインフレしていないか精査できて良い)とのことです。

上記に示したさまざまな細かな改善によって、ヒューマンエラーを減らしつつ、複数人の同時入稿を実現しました。

 

で、どうなの

以下にまとめました。まだ改善の余地はあるので、日々形を変えて理想の運用形態を探ろうと思います。

これはいいぞ

• Excelの分割入稿はそれなりに使える
• Validatorのおかげでエンジニアもプランナーも心穏やかに過ごせる

これはてごわい

• githubでCSV眺めるのは、やっぱり辛い。1000行超えるようなCSVのカラム追加した時のdiffはブラウザが固まる
• ValidatorとConverterは一緒のjobにまとめたほうがイテレーション早くなりそうだが以下の理由で断念
• Validatorの速度が出なかった
• 開発中でマスターデータの構造を変えている時にValidatorがこけてConverterが止まるのはよろしくない

 

おわりに

タワーライジングにおいてのマスターデータの入稿の現状を紹介させていただきました。泥臭い構成ですが、弊社のネイティブゲーム事業においてのマスターデータの入稿については、プロダクトごとのカスタマイズはあれど、概ね同じような流れになっております。

いやいや、もっと良いツール・方法がある、などございましたら是非ご共有いただけると助かります！

他社さまの素晴らしい事例も紹介させていただきます
DeNAさんがGASを駆使してスプレッドシートでスマートにやりきっていて素敵そうです。
http://www.slideshare.net/dena_study/final-fantasy-record-keeper

 

さいごに、私事ではありますが、きょうはぼくの誕生日です！(プレゼントお待ちしてます)
 

明日の記事は、後藤さんのいけててヤバいプロトコルのお話です。お楽しみに！
あと一週間、はっぴーはっきんぐ！