Cedec2013 report 探検ドリランドにおけるギルドバトル開発体制とその裏側について

探検ドリランドにおける

ギルドバトル開発体制と

その裏側について

CEDEC2013 REPORT

Speaker

グリー株式会社開発本部エンジニア

田沼 修平

探検ドリランドについて

● GREE Platform 上で遊べるカードゲーム● 多人数参加型のイベントの基盤としてギルドを

導入● 20人 x 20人 で 30分

ギルドバトルの開発体制

● ４週間で新イベントを作ろう● 全10名のイベント専門ユニット

○ プロデューサー○ ゲームデザイナ x 3○ アートディレクター○ サーバエンジニア x 3○ UIエンジニア○ テクニカルアート

機能要件

● 最大20人参加● ギルド内のコミュニケーション● ギルド間のマッチング処理● ギルド間のバトル機能● バトル画面（LWF）● ランキング集計● スクラッチから4週間

スケジュール

● ギルド機能開発：2週間● ギルドバトル開発：2.5週間● バトルLWF開発：3週間

Dev Tools

● Github Enterprise○ v3 API で通知しまくり

● Jenkins○ CI & LWF の自動ビルド

● Atlassian JIRA○ Issue Tracking○ 結構カスタマイズしている

● Vagrant○ 新しいアーキテクチャ等の実験向け

● LWF & TypeScript○ HTML5ゲームを楽して作る

相談することから始めよう

● チーム全体でミッションとゴールを理解し合う● 早期にお互いの信頼を築く● 常に意思決定。駄目だったらすぐリカバリ

計測することから始めよう（負荷見積もり）

● MAU, DAU からイベントへの参加者数を推定● ギルドバトルで扱うデータ量の計算

○ 1ギルド最大20人 x 2ギルド○ 1ユーザカード情報15枚 x 参加者数○ その他諸々

メンバーが受け入れられる現実的なプロ

ジェクト運用を採用

● 強烈なVelocityを生むために個人裁量を大きく● 自由の代わりに責任を明確に● 誰のための開発なのか？を意識

ギルドバトルの説明

● お客様がゲームを遊ぶまでのおさらい○ 携帯電話からパケット交換機を通してHTTP通信を行う

■ Infrastructure Layer / Application Layer■ PHPで処理して結果を返す

○ 最大40人参加（1ギルド最大20人）■ デッキ等の総合値により前衛、後衛の役割が決定す

る○ 定刻（12時、18時、21時）に開始

■ 開催時間は30分○ 相手に攻撃して得られるポイントで勝敗が決定

ギルドバトルの説明

● ゲームのサイクル○ 通常の探検

■ ダンジョン探検 => キングモンスター遭遇 => 協力して倒す

○ ギルドバトル開始■ 通常の探検 ＋ 相手ギルドに攻撃、ギルドモンスター

に攻撃■ APがなくなると相手へ攻撃したりHPの回復ができな

くなってしまう■ キングモンスター討伐でAP回復アイテムが一定確

率でドロップ

ギルドバトルの説明

● APを消費して相手に攻撃。ダメージ量に応じてDP獲得

● より多くのDPを獲得したギルドの勝ち● 一定の条件を満たすとギルドモンスター出現

○ 倒すとダメージに応じてボーナスアイテム獲得○ ギルドモンスター登場後は相手より多くダメージをたたき

出すことが重要○ ボーナスアイテムはバッチで自動的に登録

● メンバーと戦略を考えて戦うのが勝利のカギ○ コンボやギルド技等も重要なファクター

LWF

● Lightweight SWF● GREEが提供するOSSのライブラリ● publish swf => convert swf to lwf format =>

rendering● フラッシュでいい感じのアニメーションを作っても

らって publish for lwf● LWFを利用することでゲームを作ることに注力

できる● HTML5でのLWF再生の流れ

○ LWF binary data を DLし、必要リソースを順次取得

LWF

● ギルドバトルでのLWF○ 外部LWF、Resource の Load○ 初期状態（一定間隔ごとに通信）○ 攻撃APIのRequest, Response から適切なAnimation

を表示

● LWFの便利機能○ ImageMap

■ パラメータで画像の変更が簡単に指定できる■ バトル開催時間に応じて背景を変更する等

● LWFはゲーム制作で楽をするツール○ LWFを使うことで短期間でゲームのUI等を作ることが可

能○ 柔軟なScriptingによる操作も可能で思いのまま

バックエンドについて

● システムは基本的に PHP + MySQL + Flare(KVS) で構成

● 既存の構成を生かしてGvG機能を作成する必要がある

● データ要素○ BattleInfo x 1：現在のバトル情報○ Guild x 2○ User x (20 * 2)○ Card x (15 * 40)

MySQLで構築した場合の問題点

● Insert / Update / Select すべてが強烈に走る● Replication は Single Thread● Slaveの遅延が起きることが簡単に予測できる● 最適化したテーブルスキーマが仕様変更で再

設計とか目も当てられない

Flareを使うことの意義

● 長年自社開発、運用してきたKVSでノウハウがある

● 細部実装まで把握、運用面での信頼性が高い● partition分割機能でスケールさせやすい。マル

チコアを活かせる● データの永続化が行えるのでメインのストレー

ジとしても使える

SQLで処理するかPHPで処理するか

● メンテナンス性を考えてPHPでの処理にする○ 多数の複雑なSQLを短期間で正しく評価し続けるのは

困難○ 保存時の競合の問題さえ解決できれば大部分はクリア

可能■ 当然相性が悪い操作もあるのでそこはケースによる

○ ただし、データ構造が大きめになってしまうので、１回のリクエストあたりのトラフィックは増大する

○ メリット■ 領域を切り分けて考えられる■ データを取得さえできれば再現が確実にできる

トラフィック増加により見えてくるSoftware IRQ 問題

● ソフトウェア割り込みが多くなることの要因○ データは1パケットの大きさに収まるように分割される○ 大きなデータであれば分割数が多くパケットの数が増え

る

● 高負荷なサービスではアプリケーションを作る側でもNetworkの知識が求められる

対策

● データサイズを減らす、リクエストを束ねる○ 1回のHttp Requestで発生するKVSの操作を最適化

■ Memcached なら mget を使う、等■ たいていの場合、複数回getを呼ぶよりppsは下がる■ mget はライブラリの実装によるのでどのような挙動

をするか把握することは大事

対策

● どうやってデータサイズを減らすか○ Google Protocol Buffers

■ PBでの数値は可変長整数のエンコードなので小さい値と相性が良い

■ PHPを基準に考えた時にClassのSerializationで一番使いやすい

■ 機能面、速度面で優秀（型の不一致で悩むこともない）● パフォーマンスは実装で決まるので多言語の値はあくまで参考

■ 制限がある構造を使うので複雑になりすぎない■ 遭遇する問題

● PBは各バイトごとに関数を呼ぶような処理なので、Pure PHPだと遅すぎる

● 特にPHPは関数実行がオーバーヘッドになりがち● バッチ処理を扱う上で問題になりPure PHPのPBは使えなかった

対策

● どうやってデータサイズを減らすか○ Serializeでも圧縮すれば運用し続けられるか

■ 圧縮率が悪化した場合にトラフィックが増加する■ バッチ処理等の実行に時間がかかる■ データサイズさえコントロールできれば行けそう

最終的にはトータルバランスが重要

● 運用担当がメンテできないものはダメ○ 実装を知らないKVSとか使うべきではない

● PBを使って得られる速度

覚えていってほしいこと

● 大規模環境ではプロダクト開発側においてもNetworkやKernelなどの知識が必要になってきている

● LWFを使うことで本当に必要なゲーム開発に注力できる

● チームにあったプロジェクト運用で幸せな開発を