Embed Size (px)
Citation preview
探検ドリランドにおける
ギルドバトル開発体制と
その裏側について
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を使うことで本当に必要なゲーム開発に注力できる
● チームにあったプロジェクト運用で幸せな開発を
