cedec 2015 cocos2d-x と社内基盤の付き合い方...

Copyright Drecom Co., Ltd. All Rights Reserved. 1

Cocos2d-x と社内基盤の付き合い方～アップストリームファーストを目指して～

株式会社ドリコム高橋成人木元将輝


理想な付き合い方

photo by Brett Sayer

付き合い方


難しい

photo by greg westfall

難しい！


痩せたこともありました

photo by Hometown Beauty

痩せちゃうこともありました


自社メンテも考えました

自社メンテもしてみました

photo by Florian F

色々あったけど共に歩むことにしました。

photo by Aurélien Buttin


Cocos2d-x の話です、念のため


アップストリームへの道のりの話

photo by Kevin Dinkel

今日の話はアップストリーム開発

へ至る道のり


目的

lCocos2d-x のアップストリーム開発を採用した理由を展開

l他の方がどう付き合っていっているか共有したい


Agenda

lモバイルゲームと社内基盤l次の社内基盤lオープンソースとの付き合い方lCocos2d-x を利用する


Agenda



社内基盤その名は

Bisque


l2013年開発開始


Bisque の目的

lネイティブシフト

lネイティブ環境の整備


bisque 以前のネイティブ開発環境

liOS- Cocos2d-iphone

lAndroid- Cocos2d-android


bisque 以前のネイティブ開発環境(2)

l言語が違う- Objective-C- Java

l開発効率が良くない


次のフレームワーク


Cocos2d-x 対応プラットフォーム

iOS


Cocos2d-x 特徴

H/W アクセラレータネイティブコード

高速高速


なぜ選ばれたの？

Android

iOS

閲覧可能

改変可能

コスト削減

オープンソース


満たせたのは Cocos2d-x でした

v2.0.4 採用


Cocos2d-x の長所と短所

ゲーム以外の機能

ほぼゼロレイヤ階層

レンダリング

画像フォーマットの表示

ゲーム機能に特化


短所を補う

UIウィジェット

速度

アプリ内課金

暗号処理

サウンド・システム

演出

足りない

未熟レイヤ階層

レンダリング

画像フォーマットの表示

ゲーム機能に特化


当時の切り札

WebView

Webゲームで培ったノウハウ

レンダリング、レイアウト


bisqueで担保

足りないもの

UIウィジェット速度

アプリ内課金暗号処理

足りないもの

足りないもの

サウンドシステム演出

未熟なもの足りないものUX向上

足りないもの

切り札

WebView

Copyright Drecom Co., Ltd. All Rights Reserved.


崖っぷちバスターズ® で利用しています崖っぷちバスターズ®は、壁を壊して、敵を崖から突き落す、新感覚のぶっ放し協力バトルゲームです。GPS連動したエリアバトルでスコアランキングを競い、エリアNo.1になることで、そのエリアを制圧しながら拡大していくことができます。また、最大4人で遊べるマルチプレイ機能を搭載!仲間と連携して必殺技を繰り出せば、敵に大ダメージを与えることができます。手に汗握るバトルが繰り広げられる、「みんなで遊べるゲーム」の決定版です。


Bisque の目的

lネイティブシフト- ◯ ネイティブアプリのリリース

lネイティブ環境の整備- ◯ Cocos2d-x でコスト削減- ◯ 足りない機能は追加

photo by Erik Schepers

2015年次のフェーズへ


新たなる要望

利用する機能を選びたい

ライセンス未使用 3rd party libは表記を避けたい

1

パーミッション未使用機能の許可を避けたい

パッケージサイズのシェイプアップ少しでもサイズを減らしたい


新たなる要望

ゲーム以外のアプリでの活用暗号化処理のみを利用したい

2

Cocos2d-x を新しくしたいv2.0.4 は既に3年前(!)

3


• UIWidgetというのができた• レンダリング性能の向上• 3D 演出の追加• C++11

Cocos2d-x の状況

v2 v3

新しい演出や体験• 古い• 情報自体がもう少ない

• 開発スピード低下


状況整理

機能選択

ゲーム以外のアプリで利用

バージョンアップ

機能全部載せ×

Cocos2d-x付のコードを含んだバイナリ△

バージョン v2.0.4 固定×


Agenda



現状の bisque 構成

bisque

課金 sqlite3

サウンド暗号処理

v2.0.4


現状の bisque 構成

lbisque ソースファイル- Cocos2d-x の proj ファイルで管理

lbisque 機能- ソースコードはモジュール化済み- ビルド周りは一枚岩状態- 機能選択はできるが、ちょっと面倒


bisque 機能の分離

課金 sqlite3


bisque

core

v2.0.4


bisque 機能の分離(2)

l機能の分離- 必須機能を Core 化- 選択可能機能をモジュール化

lBisque の Core 部分と機能毎にproj ファイルを用意

l欲しい機能だけ選べる


Cocos2d-x からの独立

課金 sqlite3


bisque

v2.0.4

core


Cocos2d-x からの独立(2)

lBisque Core の proj ファイルを別管理

lCocos2d-x と分離し、bisque と Cocos2-d x を同列モジュール化にした


before

bisque

課金 sqlite3


v2.0.4


after

課金 sqlite3


bisque

core

v2.0.4


モジュール化

lbisque core と Cocos2d-x を同列モジュール化し、対等な立場へ

lbisque 内でも一部機能をサブモジュールとして選択できるようにした。


例: sqlite3 使わないよ

課金 sqlite3


bisque

core

v2.0.4


sqlite3 さようなら

課金


bisque

core

v2.0.4


例: 暗号処理だけ使いたいよ

課金 sqlite3


bisque

core

v2.0.4


Cocos2d-x さようなら

課金 sqlite3


bisque

core


利用しない機能さようなら

暗号処理

bisque

core


暗号処理こんにちは

暗号処理

bisque

core


Cocos2d-x と疎結合になったので…

課金 sqlite3


bisque

v2.0.4

core


例: こういうのも悪くない

課金 sqlite3


bisque

core


例: 大変そうだけどもこういうのもあり

課金 sqlite3


bisque

core


フレームワークの選択肢が広がる！！

課金 sqlite3


bisque

core


もちろんバージョンアップも楽に！

課金 sqlite3


bisque

v3.x

core


コンセプト

機能選択



サブモジュール化で利用機能を選択可能に◯


bisque 独立により必要最低限のバイナリ◯


残りタスク

機能選択



◯


サブモジュール化で利用機能を選択可能に

bisque 独立により必要最低限のバイナリ◯

あとは Cocos2d-x のバージョンアップだけ！

これは簡単そう！

photo by Paul Hocksenar


Cocos2d-x バージョン要望

EngRD RD

バージョン固定したい

運用中アプリの安定化

最新を使いたい

最新機能の調査

すべてのバージョン

アプリ開発者へ機能提供

photo by Paul Hocksenar

バージョンアップだけじゃ足りなかったよ…


バージョン選択が必要だ

機能選択


バージョン選択

◯


サブモジュール化で利用機能を選択可能に

必要最低限のバイナリ◯


バージョン選択要件

l全バージョンを選択できる

l全バージョンに自社機能を簡単に入れられる

l上記2つを低コストで実現できる


バージョン選択状況

lCocos2d-x のメインストリームは常に変化し続ける

lCocos2d-x のソースコードを変更するとバージョンアップ時に支障をきたす

lかと言って変更しないわけには…

photo by Jason Corneveaux

自社の機能を追加しながら、メインストリームの最新を追いかけるうまい方法って

あるの？


あるんです



Linux


• オープンソース(GPL v2)• 複数アーキテクチャ対応• 世界で最も成功している OSS プロジェクトの一つ


Linux


リリース間隔2～3ヶ月

変更コード200万行以上

参加企業200社以上

アップストリーム開発


Agenda




オープンソースソフトウェアに対して企業が行ったソースコード修正を元のオープンソースプロジェクトに還流させるプロセス

アップストリームファーストは還流を第一優先で考えること

photo by Alan Doyle

アップストリームへ還流(イメージ図)



自社特有の処理は自社でメンテナンスし汎用化可能なソースコードを還流する

リリースを追いながら自社の処理も追加できる開発手法



修正を還流するためメインストリームの最新を追いかける必要があり、バージョン変更のコストを下げるのが必須になる

バージョン変更のコストを抑えられる


自社でメンテナンス


自社でメンテナンス

l追加した処理をメンテし続ける

lアップストリームが verup- 自社の変更点をすべて移行- 時間がたつほど移行対象が増える

lこれはうまく行った例


自社でメンテナンス(2)



lバージョンアップがうまくいくとは限らない

l同じバージョンを使い続ける可能性も…

lバージョンアップは新しいフレームワークを作成する時



lメリット- 変更のスピードが速い- やりたい放題

lデメリット- 変更すればするほど verup が困難- 独自フレームワーク化- 新機能が利用できない


アップストリーム開発(2)

l自社の処理をメインラインへ還流

l対象プロジェクトが verup- 最小限の自社の変更点を移行- 移行対象は減らせる



l新機能を利用可能

l最新版を追える状況になる

lバージョンアップは Cocos2d-x を利用する過程でしかない



lメリット- 最新版を追いやすい- 新機能が利用可能- (受け入れられれば)メンテコスト減

lデメリット- 追い続けなければいけない- 反映されるまで遅い(保障もなし)

photo by Sudhamshu Hebbar

アップストリーム開発採用基準

はどうやった？


アップストリーム開発採用判断基準

lオープンさ

l機能追加の頻度

lプロジェクトの熱量

lスポンサー


はどう？

オープンさどうして？プロジェクトの進捗が見えるのでプロジェクトの方向性を見通しやすい。そのため追いかけやすい環境になる。

Trello でリリースのロードマップ提示github 上で進捗管理オープンさは十分


はどう？

追加機能の頻度どうして？機能追加があるからこそアップストリームを追う利点がある。追加機能がないのであれば追う必要はない。

バージョンアップ時に5～10万行追加新機能・新プラットフォームの対応最新版を追う利点はある


はどう？

プロジェクトの熱量どうして？参加する開発者が多いことで機能追加の勢いや品質の高さにも影響する。

github の Pull Request が 100件以上Cocos2d-x のフォーラムも活発


はどう？

スポンサーどうして？実績がないと契約されない。(お金👌の関係 is シビア)安定したプロダクト運用を要求される。数が多いに越したことはない。

SoC メーカから携帯端末メーカ、パブリッシャーまでスポンサー、パートナーシップを組んでいる。

photo by Brett Sayer

Cocos2d-x とはどう付き合っている？


github 自社gitlab

clonepull

Cocos2d-x と付き合うブランチ戦略


Cocos2d-x と付き合うブランチ戦略(2)

lgithub から clone, pull してリポジトリを同期する

l自社ブランチをリリースタグから作成、変更点追加

l前ブランチから変更点を merge

lリリース毎に繰り返す


ブランチ戦略の利点

lgithub と同期しながら変更点を自社で管理し続けられる

lgit リポジトリが同期しているので Cocos2d-x メインストリームへ送付する Pull request 作成が低コストになる


アプリケーションでの利用方法

アプリ自社gitlab

Classes

Resources

proj 群

cocos2d submodule v3.3v3.4v3.5


アプリケーションでの利用方法(2)

lアプリ内の Cocos2d-x ディレクトリを git サブモジュールとして扱う

l利用したいバージョンのブランチを指定する


この利用方法の利点

lアプリケーション側で利用するCocos2d-x のバージョン変更が気軽になる。

lアプリケーションを開発しつつCocos2d-x のソース修正が可能Pull Request 作成が低コストになる


アップストリーム開発を採用したので

lCocos2d-x の最新版が利用可能

lバージョンも利用可能な土壌が出来上がった。

l変更を還流するので社外の人もハッピー(になる予定)


バージョン選択

アップストリームでバージョン選択可能に◯

コンセプト

機能選択


◯サブモジュール化で利用機能を選択可能に

◯bisque 独立により必要最低限のバイナリ


Agenda



Cocos2d-x 2.xから3.xで大きく変化した事


・C++11準拠

・3D機能

・描画処理

・ローカルストレージ機能

・スクリプト関連


・C++11準拠

・3D機能

・描画処理



・C++11準拠


・C++11準拠

・3D機能

・描画処理



・3D機能


・C++11準拠

・3D機能

・描画処理



・描画処理


・C++11準拠

・3D機能

・描画処理



・ローカスストレージ機能


・C++11準拠

・3D機能

・描画処理


・スクリプト関連・スクリプト関連


・C++11準拠

・3D機能

・描画処理


・スクリプト関連他にも色々

FileUtil

Font

MathLib

3D Socket

MySQL

ScriptBind


・C++11準拠

・3D機能

・描画処理



・描画処理


Director

drawScene()

Scene

addChild()

visit()

Sprite

visit()

draw()

OpenGL ES API

glDrawArrays()version2


Director

drawScene()

render()

Scene

addChild()

visit()

render()

Sprite

visit()

draw()

Renderer

addCommand()

render()

drawXXXX()

OpenGL ES API

glDrawElements()

version3


Director

drawScene()

render()

Scene

addChild()

visit()

render()

Sprite

visit()

draw()

Renderer

addCommand()

render()

drawXXXX()

OpenGL ES API

glDrawElements()

RenderCommand

RenderCommand

version3


Director

drawScene()

render()

Scene

addChild()

visit()

render()

Sprite

visit()

draw()

Renderer

addCommand()

render()

drawXXXX()

OpenGL ES API

glDrawArrays()

glDrawElements()

RenderCommand

RenderCommand

version2version3


・Rendererクラスの追加

・Drawメソッドの変更

・Draw Callに関する変更



・基本的にglDrawArraysはglDrawElementsへ変更



・基本的にglDrawArraysはglDrawElementsへ変更

・VAO/VBOの積極的な利用



・RendererにQueueされたRenderCommandをまとめてソート、実行する描画処理

Renderer

RenderCommand

RenderCommand

RenderCommand

Sprite::draw() OpenGL ES API

glDrawElements()Sprite::draw()Sprite::draw()




・RenderCommandによる振る舞いの変化




・RenderCommandによる振る舞いの変化TrianglesCommand CustomCommand BatchCommand

GroupCommand MeshCommand QuadCommand




・RenderCommandによる振る舞いの変化

・Global/Local Z Orderの概念



・RendererのQueueに対してRenderCommandを追加

Sprite::draw() glDrawArrays()version2




Sprite::draw() glDrawArrays()

RendererSprite::draw() glDrawElements()

version2

version3




・CustomCommandによるコールバック処理Renderer

Sprite::draw()Sprite::callback() glDrawElements()


Cocos2d-xを利用する上でのパフォーマンス・チューニング


・アップストリーム開発を行う上で

・メインストリームに対応していく




・原則としてCocos2d-xのソースコードには手を入れない




・原則としてCocos2d-xのソースコードには手を入れない

・バグ修正やチューニングはpull request等で積極的に展開していく


・Cocos2d-xとの付き合い方

・そもそもCocos2d-x自体はパフォーマンス重視というよりも実装コストの軽減や汎用性を重視している


・Cocos2d-xとの付き合い方

・そもそもCocos2d-x自体はパフォーマンス重視というよりも実装コストの軽減や汎用性を重視している

・Cocos2d-xの機能を最大限に利用しながらパフォーマンスの改善を目指す


・パフォーマンス・チューニング上の前提

・Cocos2d-xで実装されている機能を利用する為、グラフィックスAPIはOpenGL ESを利用




iOSAppleA7Metal

Android-

Vulkan




・2Dのコマ割りアニメーションによる表現手法に対して問題と成り得る箇所を探る


・CPU側の問題

・GPU側の問題

・CPU/GPU共通の問題


・CPU側の問題

・Draw Callの問題


・CPU側の問題

・Draw Callの問題glBlendFunc(GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA);glUseProgram(program);glUniformMatrix4fv(umvp, 1, GL_FALSE, current.mat);glUniform1i(utxt, BQBORDER_SAMPLER);glBindTexture(GL_TEXTURE_2D, texture[i]);glBindBuffer(GL_ARRAY_BUFFER, vbo[i]);glEnableVertexAttribArray(kCCVertexAttrib_Position);glEnableVertexAttribArray(kCCVertexAttrib_Color);glEnableVertexAttribArray(kCCVertexAttrib_TexCoords);glVertexAttribPointer(kCCVertexAttrib_Position, 3, GL_FLOAT, GL_FALSE, sizeof(ccV3F_C4B_T2F), (GLvoid*)__builtin_offsetof(ccV3F_C4B_T2F, verticesglVertexAttribPointer(kCCVertexAttrib_Color, 4, GL_UNSIGNED_BYTE, GL_TRUE, sizeof(ccV3F_C4B_T2F), (GLvoid*)__builtin_offsetof(ccV3F_C4B_T2F, colorsglVertexAttribPointer(kCCVertexAttrib_TexCoords, 2, GL_FLOAT, GL_FALSE, sizeof(ccV3F_C4B_T2F), (GLvoid*)__builtin_offsetof(ccV3F_C4B_T2F, texCoordsglBindBuffer(GL_ELEMENT_ARRAY_BUFFER, eao);glDrawElements(GL_TRIANGLES, indexnum, GL_UNSIGNED_SHORT, 0);glBindBuffer(GL_ELEMENT_ARRAY_BUFFER, 0);glBindBuffer(GL_ARRAY_BUFFER, 0);

glDrawElements


・CPU側の問題

・Draw Callの問題

Draw Callに関するOpenGL ESのAPIは呼び出し回数がボトルネックに繋がる為呼び出し回数を抑える


・CPU側の問題

・Draw Callの問題glBlendFunc(GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA);glUseProgram(program);glUniformMatrix4fv(umvp, 1, GL_FALSE, current.mat);glUniform1i(utxt, BQBORDER_SAMPLER);glBindTexture(GL_TEXTURE_2D, texture[i]);glBindBuffer(GL_ARRAY_BUFFER, vbo[i]);glEnableVertexAttribArray(kCCVertexAttrib_Position);glEnableVertexAttribArray(kCCVertexAttrib_Color);glEnableVertexAttribArray(kCCVertexAttrib_TexCoords);glVertexAttribPointer(kCCVertexAttrib_Position, 3, GL_FLOAT, GL_FALSE, sizeof(ccV3F_C4B_T2F), (GLvoid*)__builtin_offsetof(ccV3F_C4B_T2F, verticesglVertexAttribPointer(kCCVertexAttrib_Color, 4, GL_UNSIGNED_BYTE, GL_TRUE, sizeof(ccV3F_C4B_T2F), (GLvoid*)__builtin_offsetof(ccV3F_C4B_T2F, colorsglVertexAttribPointer(kCCVertexAttrib_TexCoords, 2, GL_FLOAT, GL_FALSE, sizeof(ccV3F_C4B_T2F), (GLvoid*)__builtin_offsetof(ccV3F_C4B_T2F, texCoordsglBindBuffer(GL_ELEMENT_ARRAY_BUFFER, eao);glDrawElements(GL_TRIANGLES, indexnum, GL_UNSIGNED_SHORT, 0);glBindBuffer(GL_ELEMENT_ARRAY_BUFFER, 0);glBindBuffer(GL_ARRAY_BUFFER, 0);


・CPU側の問題

glBlendFunc(GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA);glUseProgram(program);glUniformMatrix4fv(umvp, 1, GL_FALSE, current.mat);glUniform1i(utxt, BQBORDER_SAMPLER);glBindTexture(GL_TEXTURE_2D, texture[i]);glBindBuffer(GL_ARRAY_BUFFER, vbo[i]);glEnableVertexAttribArray(kCCVertexAttrib_Position);glEnableVertexAttribArray(kCCVertexAttrib_Color);glEnableVertexAttribArray(kCCVertexAttrib_TexCoords);glVertexAttribPointer(kCCVertexAttrib_Position, 3, GL_FLOAT, GL_FALSE, sizeof(ccV3F_C4B_T2F), (GLvoid*)__builtin_offsetof(ccV3F_C4B_T2F, verticesglVertexAttribPointer(kCCVertexAttrib_Color, 4, GL_UNSIGNED_BYTE, GL_TRUE, sizeof(ccV3F_C4B_T2F), (GLvoid*)__builtin_offsetof(ccV3F_C4B_T2F, colorsglVertexAttribPointer(kCCVertexAttrib_TexCoords, 2, GL_FLOAT, GL_FALSE, sizeof(ccV3F_C4B_T2F), (GLvoid*)__builtin_offsetof(ccV3F_C4B_T2F, texCoordsglBindBuffer(GL_ELEMENT_ARRAY_BUFFER, eao);glDrawElements(GL_TRIANGLES, indexnum, GL_UNSIGNED_SHORT, 0);glBindBuffer(GL_ELEMENT_ARRAY_BUFFER, 0);glBindBuffer(GL_ARRAY_BUFFER, 0);

・Draw Callの問題（Cocos2d-x）

glDrawElements


・CPU側の問題



glDrawElements

Texture / Shader


・CPU側の問題



glDrawElements

Vertex


・CPU側の問題



glDrawElements

Vertex

Texture / Shader


・CPU側の問題

・CustomCommandによるコールバック処理





・CPU側の問題

・CustomCommandによるコールバック処理・Global/Local Z Orderの概念

RenderC

ommand

RenderC

ommand

RenderC

ommand

RenderC

ommand

RenderC

ommand

RenderC

ommand

RenderC

ommand

Custom

Command

RenderC

ommand

RenderC

ommand


・CPU側の問題

・CustomCommandによるコールバック処理





・CPU側の問題

・Cocos2d-xのversion3ではAPI呼び出し回数の削減に対する最適化はきちんと行われている

・Cocos2d-xの最適化の手法を理解した上で、手法に沿った手段を用いて実装を


・ピクセル処理の問題

・GPU側の問題


・ピクセル処理の問題

・オーバードロー・フラグメントシェーディング

・GPU側の問題


・ピクセル処理の問題「オーバードロー」

・1ピクセルに対して2回以上の描画処理

・GPU側の問題



・奥から手前への描画・アルファブレンド

・GPU側の問題



・奥から手前への描画・アルファブレンド=奥から手前への描画

・GPU側の問題



・奥から手前への描画・アルファブレンド→透過部分を最小限に

・GPU側の問題



・SpritePolygonの利用

・GPU側の問題


・ピクセル処理の問題「フラグメントシェーディング」

・シェーダーのパフォーマンス

・GPU側の問題


・ピクセル処理の問題「フラグメントシェーディング」

・シェーダーのパフォーマンス複雑な処理を避ける分岐の数を減らすループを無くす演算精度を下げる※

・GPU側の問題


・透過部分の範囲を狭く、重なりを浅く・SpritePolygonの利用を検討

・独自のシェーダーについての最適化・サードパーティのシェーダーの確認

・GPU側の問題

・オーバードロー

・フラグメントシェーディング


・GPUによって部分的にパフォーマンスが異なる最適なチューニング箇所が異なる

・Cocos2d-xを利用する上でもGPUの理解を

・GPU側の問題



・メモリ帯域幅の問題




・iPhone5：AppleA6で8.5GB/sec程度・iPhone5s：AppleA7で15GB/sec程度




・メモリとその帯域幅はCPU/GPUで共有

CPU GPU

MEM / VRAM




・メモリとその帯域幅はCPU/GPUで共有

CPU GPU

MEM / VRAM

マルチスレッドテクスチャ



オブジェクトサイズ/数の削減テクスチャサイズ/数の削減圧縮テクスチャの利用マルチテクスチャ等の再考




・CPUやGPUそれぞれの最適化だけでは解消されない問題

・パフォーマンスに大きな影響を与えるが、表面化しづらい


・CPU側の問題

・GPU側の問題



まとめ

ドッグイヤーと言われる程に技術の進歩が早くなっており、

photo by R∂lf Κλενγελ

ユーザの要求も増えてきています

photo by Matthias Ripp

それに伴い、アップストリーム開発

が選択肢になる機会が増えてきました

現在、アップストリーム開発を採用している企業

が少ないので、

Upstream します

アップストリーム開発に挑戦することにしました

photo by Patrik Theander

ぜひ、みなさまも参加してください

photo by Johan Larkander

photo by Tintin44

一人で悩まず、問題を共有しましょう

開発者間でWin-win の関係を築けたら幸いです

Any Questions?

photo by Matthias Ripp


ご静聴ありがとうございました


参考文献


参考文献

lオープンソースにおけるアップストリーム開発の意義

cedec 2015 cocos2d-x と社内基盤の付き合い方...

Technology