Cocos2d-x 3.0を使ったゲーム “消滅都市” の開発事例

Copyright © 2015 Wright Flyer Studios, Inc. All Right Reserved.
WRIGHT FLYER STUDIOS
Cocos2d-x 3.0を使用したゲーム
“消滅都市”の開発事例
Cocos2d-x talks #2 (March 13, 2015)

• 渡部晋司
– リードエンジニア
• 経歴
– 会津大学コンピュータ理工学部性能評価学講座
– 任天堂株式会社 (2007年～)
– グリー株式会社 (2012年～)
• GREE Platform事業
• 消滅都市
自己紹介

ゲーム紹介
• 現代を舞台にしたスマートフォンゲーム
– iOS & Android
• 2014年5月下旬にリリース
• おかげさまで350万ダウンロードぐらい
• CM放映中！

開発開始前の状況

開発体制
プロデューサー
1名
ディレクター
1名
PM
1名
クライアント
プログラマー
4名
サーバー
プログラマー
3名
アート
4名
テクニカル
アート
1名
合計17名
ゲーム
デザイナー
2名

スケジュール
2013年
10月
2014年
11月 12月 1月 2月 3月 4月 5月
プロト開
発
α開発
- 主要機能完成 -
β開発
- ひととおり
完成 -
全社
公開,
改善
QA
G
O
A
L
計7ヶ月
アジャイルQA

• 3Dゲームだと厳しそうだった
– 開発期間
– 開発メンバーの人数
• 本開発半年でのリリースが絶対条件
– ギャグかと思ったがマジだった
開発開始前の状況

• 開発メンバーの構成
– C や C++ の開発経験者が多かった
– Unityの開発経験者がいなかった
• Cocos2d-x
– 会社の内製プロダクトでは初の採用
– 少し触ってすぐに理解できた
– 中が見えている安心感
なぜ Cocos2d-x を選択したのか

• 消滅都市の開発開始当初
– 安定版 : 2.2.5
– 開発途中版 : 3.0 alpha0
• 判断基準
– 今後3.x系が主流になるのは見えてる
– ロンチ時に正式版が出ているのか？
Cocos2d-xのバージョン

• 使用したCocos2d-xの推移
– v2.2.5 (プロトタイプのみに使用)
– v3.0 alpha0 (本開発開始後)
– v3.0 beta2
– v3.0 rc1
• 消滅都市ロンチ時のCocos2d-x
– v3.0 rc1
– 必要なパッチのcherry-pick
– 幾つかの改造

• 苦労した点
– v2系とv3系だとクラスの名前が違う
– v3.0 betaでディレクトリ構成が変わる
– v3.0系最初の頃はやはり不安定だった
• バージョンアップが結構つらかった
– 作業に一週間弱程度かかった
– ロンチ以降はバージョンアップはしていない

Cocos2d-xとの付き合い方
-開発環境と周辺ライブラリ-

• ゲームエンジン…？
– というよりはゲームフレームワーク
– ツール類は標準のものがない
– 自由に組み合わせて使う
• 長所
– アプリ仕様やメンバー構成に応じて自由自在
– サードパーティSDKの組み込みやすさ
• 短所
– 組み合わせを考えるのが大変
– 仕組みのセットアップが必要になる
開発環境と周辺ライブラリ

• 消滅都市における選定基準
– 納期に間に合うこと (本開発期間半年)
– メンバーの能力が最大限活きること
– コストパフォーマンス
• 時間的な意味とお金的な意味での

• メインのコーディング環境
– C++ 11
– MacOSX + Xcode
– iOSデバイス or シミュレータで開発を行う
• Androidの開発環境
– IDE等は使用していない
– 問題が起こったらprintfデバッグ (笑)
• ※そもそもあまり問題が起こらなかった

• libdispatch
– バックグラウンド処理を書きやすく
– 主に通信関係の処理の部分で使用
• Cricket Audio
– マルチプラットフォーム
– 基本的な機能を備えている
– サポートが手厚い (英語のみ)
– 低コスト (無料 or 低額)
http://www.crickettechnology.com/

• LWF for Cocos2d-x
– FlashデータをCocos2d-x上で再生
• 消滅都市での使用部分
– ゲーム中のキャラクター
– 攻撃エフェクト
– ガチャの演出

Cocos2d-xとの付き合い方
-UI制作環境-

• UI作成の環境整備
– ゲームの画面数が多い
– UI制作スピードがプロジェクトの成否を左右
• Cocos2d-x向けのUIツール
– Cocos Builder
– Cocos Studio (旧称 : CocoStudio)
– などなど
UI制作環境

• 新しいツールを覚えるのは負担…
– そもそも画面デザインはPhotoshopで作る
– 作ったのをツール上で再配置？するの？え？
• 最初からPhotoshopで作れればいい
– JSXでレイヤー構造をエクスポートする
UI制作環境

UI制作環境
PhotoshopによるUI制作

UI制作環境
psdファイルのレイヤー構造

UI制作環境
UI部分のプログラムを実装してゲーム画面に

• UI系アニメーション
– Photoshopで全体的な画面構成は出来た
– でもアニメーション付けは無理
• プログラマが適当につけた
– 雰囲気で
– 長さとか距離とかカーブとか適当に空気読んで
– あまりにも酷い時はダメだししてもらう
UI制作環境

• デザイナーの意向がそのままゲームに
– ゲーム画面を直感的に作りこめた
– 新しくツールを覚える必要がなかった
• イマイチ
– テクスチャがアトラス化されない (未対応)
• やれば出来るけど本気出してないだけ
– フォントの見た目が若干違う
– エクスポートが遅い
• 横展開
– Cocos2d-xで開発中の他ゲームでも使用
– レイヤー構造仕様にデザイナが慣れつつある
UI制作環境

パフォーマンス関連

• 消滅都市はアクションゲーム
– ぬるぬる動く状態(60FPS)を目指したい
• パフォーマンス
– CPU, GPU
– データ入出力 (ディスク、ネットワークetc)
– メモリ消費量
• 重要なこと
– パフォーマンスに囚われるとゲームは出ない
– 消滅都市は4月～5月に最適化を実施

• CPUパフォーマンスの向上
– Xcode Instrumentsを使用して調査
• アプリ側のコードでの問題を修正
– オブジェクトの頻繁な作成と削除
• Sprite / Node → うまく使いまわす
• ゲーム用のオブジェクト
– ゲーム中にディスクアクセスをしていた
– 見えていないLWFアニメーションが動いてた

• パーティクルエフェクトを削除
– ちょっとCPU的な負荷が大きかった
– Cocos2d-xの最新版でどうなってるかな？
– LWFアニメーションで代替
• SpriteBatchNodeの明示的な使用
– ドローコールを削減する機能
– 自動にドローコールをまとめる機能がある
• Cocos2d-x 3.x系以降
– 明示的に使うとCPU負荷が下がった

• GPUのパフォーマンス調査ツール
– Xcode
• フレームデバッガ機能
• Instruments
– Adreno Profiler
– PerfHUD ES

• GPUパフォーマンスの向上
– 頂点 (2Dゲームの場合はほぼ考慮不要)
– ピクセルフィル (大きく影響)
– ドローコール数
• CPU最適化によっても…？
– GPUがCPUの熱の影響を受ける
– OS側から周波数ダウンのペナルティ
• アプリ側が割り込む隙は無い

• 消滅都市において見えてきた問題
– 無駄な透明レイヤーが表示されてた (oh…)
– ピクセルのオーバードローが多かった
• ステージ背景の描画方法を工夫して対処
– ドローコールがまとまっていなかった
• 階層構造にしてしまった影響

• 高速シェーダの追加
– ごく一部の端末に効果がある
– Cocos2d-xの機能が制限される
Cocos2d-xデフォルトのフラグメントシェーダ
(出力色) = (テクスチャ色) × (頂点色)
高速化版
(出力色) = (テクスチャ色)

• glClearの呼び出し
– レターボックスの範囲に留める
• 全体を塗らなくすることで高速化
– 一部の端末で効果がある
– 背景の絵などですべてのピクセルを塗る
• 塗り忘れると悲惨なことに
– Cocos2d-xを少し改造する必要

glEnable(GL_SCISSOR_TEST);
float bottomAreaHeight = viewRect.origin.y;
if (bottomAreaHeight != 0.0f) {
glScissor(0,0,frameSize.width, (int)bottomAreaHeight+1);
glClear(GL_COLOR_BUFFER_BIT);
}
// (中略)
glDisable(GL_SCISSOR_TEST);

• 圧縮テクスチャの使用
– メモリ消費量の低減 / 高速化
– 品質劣化が起こる
– 使用した箇所は限定的
• 背景
• エフェクト用テクスチャ
– 各GPUごとにテクスチャを用意
• アルファチャンネルも使用するため

• Android ハードウエアスケーラ
– (ほぼ？) ノーコストで引き伸ばしが可能
– 高解像度端末で効果大
• 特にタブレット向け
• FPS37→60弱まで改善した端末も
– API呼び出しによりバッファサイズを変更
• SDK : setFixedSize
• NDK : ANativeWindow_setBufferGeometry

– Cocos2d-xの改造が一部必要
• 最新版では？
– 改造方法 (コードは省略)
• JNI経由で物理サイズとバッファサイズ両方渡す
• GLViewProtocol::_screenSizeの意味を変える
• タッチ位置座標の計算方法を変更

– 物理ピクセル数依存の計算に注意
• getFrameSizeの意味が変わる
• 消滅都市のスワイプ判定はDPIで計算
– 消滅都市では3月末リリース予定

• フォントデータのスリム化
– 運用により肥大化していく問題
– テクスチャサイズを大きくすると
• メモリ消費量の増大
• 速度低下？ (実感としては無かった)
–8bppにしても内部で32bppに変換される
• Cocos2d-xを改造して8bppのまま扱えるように
• 最新版では？

• フォントデータのスリム化
– PNG_COLOR_TYPE_GRAY
– PixelFormat::I8からPixelFormat::A8に変更
• I8の場合、その後32bppに変換される
– フォントの場合のみA8を使用するように
• 引数としてフラグを追加

• 縁ありフォントの8bpp化
– Bitmap Font Generatorのオプション
– ビット単位データの意味を変えられる
• 4bitで縁、残り4bitでグリフ
– 階調が少なくなる
– 描画用シェーダの追加

float texVal =
texture2D(CC_Texture0, v_texCoord).a;
float intensity =
texVal > 0.5 ? texVal * 2.0 - 1.0 : 0.0;
vec4 color =
vec4(intensity, intensity, intensity,
texVal > 0.5 ? 1.0 : texVal * 2.0);
gl_FragColor = v_fragmentColor * color;

カスタムシェーダとゲーム内表現

• セピア色にする機能
– そんなに複雑なことはしてないのですぐできる
– ノベル画面の回想シーンで使用
– ※ネタバレ注意※ (ストーリーシナリオ4章)

• HSB調整シェーダ
– そんなに複雑なことは(以下略)
– 同一リソースをパラメータで色変え
– レーザーバリア演出で使用 (上級者向けスキル)

• シェーダ追加の注意点
– Androidでシェーダの再生成が必要
• EVENT_COME_TO_FOREGROUNDのハンドリング
– いろんなタイミングで発生
• スリープ復帰時
• クレードルに乗せたとき
– 独自アプリが立ち上がるものがある
– 忘れるとシェーダが無効なままゲーム続行
• クラッシュすることは無い
• 絵が崩れる

Cocos2d-xとアクションゲーム
-設計失敗談-

• 消滅都市
– グリー社内で初のCocos2d-xゲーム
• 社内にノウハウが少ない
– Cocos2d-xを使った「良い設計」とは…？
• Cocos2d-xの便利な機能 “runAction”
– これを使って書いていくのが”Cocos流”
– 消滅都市でもたくさん使っていました
– 普通のゲームではupdateで少しずつ更新

• アクションゲームの部分でも多用
– 通常のupdate処理 + runActionを併用
– だんだんとワケガワカラナイヨ状態に…
• なぜ？
– 急に入るゲーム中の割り込み処理
– スキル発動時のカットイン演出
– チュートリアル
– ポーズボタン

• 割り込み対応 (ロンチ時)
– ノードに対してpause関数を使用して止める
• 問題が頻発
– 2回pauseしたあと1回resume
– 動き出すタイミングでない状態での開始
• その場しのぎのパッチで乗り切る
– だんだんとコードがカオス化
– QAで発覚するバグが頻発 (リリース遅延)
– 「俺、ゲーム部分触りたくない」と言われる

• 2014年秋にゲーム部分の全作り直し
– ほぼ「消滅都市２」に
– updateループによって動く設計に変更
• 止める場合はupdate呼び出さない
• いわゆる「普通のゲーム」の作り方
– runActionを使用しないように
• 引き続きゲーム画面以外では使用

• とは言えrunActionは便利！
– update駆動で停止再開系コードはスッキリ
– 軌道計算等の記述が面倒に…
• 裏ワザ？
– update駆動にしつつActionを使用する
– いいとこ取りできる

アクションの開始コード
pAction->startWithTarget(pSprite);
pAction->retain();
毎フレーム実行するコード
pAction->step(delta);
if (pAction->isDone()) {
pAction->release();
}

おまけ : iOS8とプチフリ問題

• iOS8以降でプチフリ問題が発生
– ゲーム開始5分後に1秒少々ハングする
– 以後、ゲームを再起動するまで起きなくなる
– アクションゲームでは致命的
• β版でも認識していた
– 正式版で直るだろうと放置
– 正式版でも起こってしまい絶望
– その後のバージョンアップでも直る気配がない
iOS8とプチフリ問題

• タイミングが悪かった (同時期)
– iOS8のリリース
– 消滅都市のランキング機能追加
• 「プチフリのせいで失敗」報告が続出
• 本当にごめんなさいぃぃ…(´；ω；｀)
• 原因全く掴めず
– 見当もつかない
– 辛く憂鬱な年末年始を過ごす

• 調査によって状況は判明
– EAGLContext presentRenderBuffer
– 制御が返ってこなくなる
• 30FPSに落とす実験
– プチフリが起こらなくなる(！)
– とは言え、クオリティが低すぎて話にならない
• 60FPSと30FPSの差異はなんだろう？
– presentRenderBufferにかかる時間

• 修正方法を検討
– CPU負荷が高過ぎるのか… ？
– GPU負荷が高過ぎるのか… ？
– メモリ消費量が多すぎるのか…？
– glFlushすると何とかなるのか…？
– 適当にsleep入れてみればいいか？ (ヤケクソ)

• 長期の調査によって修正方法が判明
if (_skipNextFrame) {
_skipNextFrame = false;
return;
}
CFTimeInterval frameStartTime = CACurrentMediaTime();
[EAGLContext setCurrentContext: [(CCEAGLView*)director->getOpenGLView()
->getEAGLView() context]];
director->mainLoop();
CFTimeInterval elapsed = CACurrentMediaTime() - frameStartTime;
CFTimeInterval frameTime = [(CADisplayLink*)_displayLink duration] *
[(CADisplayLink*)_displayLink frameInterval];
_skipNextFrame = ( frameTime < elapsed );

おまけ終わり
ここから本編です

• ネイティブゲーム開発者積極採用中
– 未だ見ぬIPを一緒に作り上げませんか？
本編 (宣伝)
詳細は http://jobs.gree.net/jp/ja/ まで！

WRIGHT FLYER STUDIOS
ご清聴ありがとうございました！
このあと懇親会をお楽しみください！

Cocos2d-x 3.0を使ったゲーム “消滅都市” の開発事例

Convert to study guideBETA

More Related Content

Cocos2d-x 3.0を使ったゲーム “消滅都市” の開発事例

Editor's Notes