Game Development and Automation @ Agile Sapporo 2018 #1

YOUとゲームと自動化と
株式会社コールド・フュージョン
テッダーマイケル
Technical Director / CEO
アジャイル札幌 2018年1回目
2018年2月28日 (水)

出身：アメリカ（フロリダ州オーランド市）
仕事：ゲーム開発、3Dエンジン開発、オーディオ/DSP開発、ネットワーク開発、CEO
言語： C++14、PHP、TypeScript、アセンブラ（x86/x64/ARM/MIPS)
趣味：デモシーン（Tokyo Demo Festの主催者）、チップチューン、VR、AWS、宇宙
16歳で高校卒業、University of Central Florida大学に入学
1993年大学インターンでVR開発を始めて、「Virtopia」をSIGGRAPH 1994で公開
1997年 Nintendo 64のエミュレータを作成、ゲーム業界に入る
2000年日本（東京）へ移動
2005年沖縄へ移動
2012年株式会社コールド・フュージョンを設立
2013年札幌へ移動
2017年東京ゲームショウに出展、自社オリジナルのスマホ向けゲーム
「クリスタル・クラッシュ」(iOS / Android / Kindle Fire)を配信
テッダーマイケル (41歳)
michael.tedder42
@_Falken
Falken42
自己紹介

テッダーマイケル
Technical Director / CEO
北海道札幌市
福本章
Game Design / Art Director
東京都
Eike “Romeo Knight” Steffen
Music / Sound Director
ドイツデュッセルドルフ市

Cold Fusion エンジン
➤ クロスプラットフォーム: Windows / Linux / macOS / iOS / Android (全7つのCPUアーキテクチャ)
➤ 完全マルチスレッド化: パフォーマンスを最優先のため、複数CPUスレッドとGPU処理を並列化
➤ レンダリング: VulkanのAPIデザインを利用し、現在はOpenGL 4.1とGLES 3対応
➤ 並列化と最適化のパフォーマンスでCPU処理は低い → スマホでバッテリー消費と発生する熱が少ない
➤ 言語: 99.9% C++14 (ラムダ式最高！)、残りはObjective-C++ (macOS/iOS)とJava (Android)

クリスタル・クラッシュ【超攻撃的パズル合戦！】
➤ 瞬間的な考察力と判断力を必要とする、パズルとアクションが合体したリアルタイムオンライン対戦ゲーム
➤ Cold Fusion エンジンを利用、Tokyo Game Show 2017の3ヶ月前でゲーム開発を始めた
➤ AWS EC2でユーザー管理とランキングAPI (PHP) / ゲームのロービーサーバーとリアルタイム対戦通信 (C++)

めんどくさいこと①
➤ ５つのプラットフォームのビルドに対してのコンパイルとテスト
➤ CFエンジンはソースファイル1200個くらい（ライブラリ含め）
➤ コンパイラもOSによって違う（WindowsはVisual Studio、macOS/iOSはXcode等）

めんどくさいこと①
➤ PCをそれぞれ立ち上げて、手動でビルドし、exeファイルを実行すると大変な作業量
➤ ５つのプラットフォームのビルドに対してのコンパイルとテスト
➤ CFエンジンはソースファイル1200個くらい（ライブラリ含め）
➤ コンパイラもOSによって違う（WindowsはVisual Studio、macOS/iOSはXcode等）

めんどくさいこと②
➤ アプリ配信にて必要な大量の情報（メタデータ）
➤ アプリ説明、アイコン、キーワード、サポート情報、スクリーンショット、プレビュー動画（端末比率ごとに）
➤ 言語ごとに、そしてストアごとに・・・
➤ Web UIはどうしても手動なので、間違いしやすい

めんどくさいこと
全部自動化にする！

buildbotの紹介
➤ JenkinsやGitLabと同じような継続的インテグレーション(CI)ツール
➤ 何らかのイベントで何かのタスク（プロセス）を実行
➤ 例：ソースコードのリポへのコミット/プッシュに対してはコンパイルする

buildbotの紹介
➤ コンパイルだけではなく、スクリプトも実行可能

buildbotの紹介
➤ buildbotはpython使ってるので、pythonが動くプラットフォームで利用可能
➤ コンパイルだけではなく、スクリプトも実行可能

buildbotの紹介
➤ マスターとワーカーを設置して、マスターがワーカーにタスクを振る
➤ ワーカーのタスクのログ出力、タスク進行などは全てマスターに転送、メール / Web / Slackで見れる
(※buildbotのHPより)

CFでbuildbotの事例
➤ buildbotマスターはEC2のt2.microに設置
➤ 社内のiMac(1台)にVirtualBox VMを2つ
➤ Windows 10 (buildbotワーカー)
➤ Ubuntu 16.04 (buildbotワーカー)
➤ iMacにもbuildbotワーカー
➤ XcodeでmacOS/iOSビルドが必要のため、iMac
は欠かせない
➤ 今後はVMをEC2インスタンスに移動予定

➤ gitリポジトリへのコミット / プッシュ
➤ buildbotマスターはgitリポの更新を判断
➤ 5つのプラットフォームのワーカーが同時にビルド
➤ 黄色は実行中、青色は正常、赤はエラー発生 / テスト
失敗

➤ Windowsプラットフォームのビルドステップ:
➤ git更新 / gitハッシュをソースにつける
➤ デバッグ版をコンパイル (32/64 bit)
➤ デバッグ版のテストをコンパイル (32/64 bit)
➤ デバッグ版のテストを実行 (32/64 bit)
➤ リリース版をコンパイル (32/64 bit)
➤ リリース版のテストをコンパイル (32/64 bit)
➤ リリース版のテストを実行 (32/64 bit)

➤ 全プラットフォームは同じようにデバッグ版
とリリース版のコンパイルとテスト
➤ iOSとAndroidのテストは実機を使用
➤ USBでiMacに繋いてるiPodとKindle
➤ iOSは「ios-deploy」ツールで実行
➤ Androidは普通に「adb」で実行

➤ CFエンジンのテストが全てOKの場合はゲーム
コンパイルが自動的に行う
➤ ゲームのリリース版を配信用に準備される
➤ iOSはアーカイブから.ipaを作成
➤ Androidは.apkを電子署名をつける
➤ ワーカーはそれぞれのプラットフォームの実
行ファイルをDropboxへコピー

fastlaneの紹介
(※fastlaneのHPより)
➤ アプリのスクリーンショットを自動撮影
➤ 複数言語対応
➤ 各アプリストアの公開API利用してデプロイ
➤ ベータ版をテスターへ
➤ リリース版を公開ストアページへ
➤ アプリ証明書の自動電子署名付け

fastlaneの紹介
(※fastlaneのHPより)
➤ つまり、アプリ公開する前にテスターに配信
➤ iTunes ConnectはTestFlight
➤ Google Playはアルファ/ベータトラックある
➤ アプリのスクリーンショットを自動撮影
➤ 複数言語対応
➤ 各アプリストアの公開API利用してデプロイ
➤ ベータ版をテスターへ
➤ リリース版を公開ストアページへ
➤ アプリ証明書の自動電子署名付け

CFでfastlaneの事例
➤ buildbotにfastlaneを統合
➤ fastlane設定とメタデータはゲームのgitリポに
➤ Dropboxにコピーされた実行ファイルをデプロイ
➤ iOS .ipaはiTunes Connectへ
➤ Android .apkはGoogle Playへ

➤ 10~15分程度でビルドは配信され、テスターが
自分の端末にダウンロードできる
➤ buildbotにfastlaneを統合
➤ fastlane設定とメタデータはゲームのgitリポに
➤ Dropboxにコピーされた実行ファイルをデプロイ
➤ iOS .ipaはiTunes Connectへ
➤ Android .apkはGoogle Playへ

➤ 実際ゲームのチェックを行い、調整し、再ビルド
➤ デザイナーさんとフィードバックが早くて細かい
調整ができる

➤ 実際ゲームのチェックを行い、調整し、再ビルド
➤ デザイナーさんとフィードバックが早くて細かい
調整ができる
➤ PC版はある程度テスト可能けど、タッチ画面
触る感覚は実機が必要

➤ 完成したビルドは各ストアのWeb UIで公開
➤ Google Play Developer Consoleは「Promote to Production
」ボタン1つで約1時間で世界中に公開
➤ iTunes Connectはアップルの審査あるため、サブミットし
てから１〜２日間が必要
➤ Web UI使わずにfastlaneでできるけど、大した作業ではない

➤ 残念ながらAmazon Developer ConsoleのAPIがまだ公開さ
れてないので、Kindleへのデプロイはすべて手動・・・
➤ 完成したビルドは各ストアのWeb UIで公開
➤ Google Play Developer Consoleは「Promote to Production
」ボタン1つで約1時間で世界中に公開
➤ iTunes Connectはアップルの審査あるため、サブミットし
てから１〜２日間が必要
➤ Web UI使わずにfastlaneでできるけど、大した作業ではない

ゲーム/スマホ開発での苦労

① 外部のライブラリはできるだけ利用しない

➤ 5つのプラットフォームで7つのCPUアーキテクチャでは全て正常に動くの保証
はなかなかない

➤ あるプラットフォームで動かない時のデバッグとサポートの時間（コスト）は
かかる

➤ 自作の物はプラットフォームベースが統一するので信頼があ
る
かかる

➤ とはいえ、プラットフォームに関係のないライブラリ（zlib, sqlite, openssl,
freetypeなど）は使うけど、どうしても修正は必要な時がある
かかる
➤ 自作の物はプラットフォームベースが統一するので信頼があ
る

② Androidで memset() のスタックオーバーフロー

➤ Androidの新しいOSバージョンではnativeコードの負担を減らすためOS側で色
々とサポートしてくれてる（いいこと）

➤ __aeabi_memset() という新しい関数はAPI 24から対応
➤ 普通のlibcの memset() 関数は直接 __aeabi_memset() を呼ぶ
➤ API 24より前の端末では当然存在しない（実行時dynamicリンクエラー発生）

➤ __aeabi_memset() という新しい関数はAPI 24から対応
➤ 普通のlibcの memset() 関数は直接 __aeabi_memset() を呼ぶ
➤ API 24より前の端末では当然存在しない（実行時dynamicリンクエラー発生）
➤ API 24より前の端末を対応するには・・・

void __aeabi_memset(void *dest, size_t n, int c)
__attribute__ ((weak))
{
u8 *pdst = static_cast<u8 *>(dest);
while (n--)
*pdst++ = c;
}
➤ API 24より前の端末を対応するにはweak関数を用意し、初期テストのためにシンプルなループで対応

➤ API 24より前の端末を対応するにはweak関数を用意し、初期テストのためにシンプルなループで対応
{
while (n--)
*pdst++ = c;
}
➤ デバッグ版で正常に動いたけど、リリース版で即クラッシュ・・・

➤ clangの最適化がループは memset() と同じコードと判断し、実際 memset() に置き換えられた
{
while (n--)
*pdst++ = c;
memset(dest, n, c); // clang最適化
}

➤ clangの最適化がループは memset() と同じコードと判断し、実際 memset() に置き換えられた
{
while (n--)
*pdst++ = c;
memset(dest, n, c); // clang最適化
}
➤ memset() → __aeabi_memset() → memset() → ・・・ → スタックオーバーフロー！

③ Androidでアプリがフォーカスを失うとGLESコンテクストが廃棄される

➤ フォーカス失うのはホームボタン押された時、電話着信など
➤ GLESコンテクストはGPU用のシェーダー、テクスチャのデータと設定などを管理する

➤ フォーカス戻ったら全てのアセットをGPUに再アップロードする必要がある
（再スタートに少しディレーかかる）

➤ フォーカス戻ったら全てのアセットをGPUに再アップロードする必要がある
（再スタートに少しディレーかかる）
➤ iOSではコンテクスト残してくれる（メモリがある限り、すぐアプリが再利用可能）

④ Androidでは端末ごとのGPUが違うので細かい対策することがある

➤ GPUは端末のモデルによって変わる、OSバージョンにもGLES対応がバラバラ

➤ シェダーコンパイラにバグも当たることはある

➤ ユーザーの端末のバグは当然直せない・・・
➤ OSアップデートで期待しても、ユーザーはアプリが落ちるしか見ない（
悪いレビュー残す可能性大）
➤ シェダーコンパイラにバグも当たることはある

out vec4 outputColor;
in vec2 uv;
uniform sampler2D tex0;
uniform vec3 lightboxData;
void main() {
if (uv.x < lightboxData.x) {
if (lightboxData.y > 0.0) {
vec2 tuv = vec2(uv.x + (1.0 - lightboxData.x), uv.y);
outputColor = texture(tex0, tuv);
} else {
outputColor = vec4(0.0, 0.0, 0.0, 0.0);
}
} else {
if (lightboxData.z > 0.0) {
vec2 tuv = vec2(uv.x - lightboxData.x, uv.y);
} else {
outputColor = vec4(0.0, 0.0, 0.0, 0.0);
}
}
}

out vec4 outputColor;
in vec2 uv;
uniform vec3 lightboxData;
void main() {
if (uv.x < lightboxData.x) {
if (lightboxData.y > 0.0) {
vec2 tuv = vec2(uv.x + (1.0 - lightboxData.x), uv.y);
} else {
outputColor = vec4(0.0, 0.0, 0.0, 0.0);
}
} else {
if (lightboxData.z > 0.0) {
vec2 tuv = vec2(uv.x - lightboxData.x, uv.y); // tuv is already defined
} else {
outputColor = vec4(0.0, 0.0, 0.0, 0.0);
}
}
}

⑤ Androidではオーディオドライバの対応は端末ごとにバラバラ

➤ 16チャンネルを同時に再生できる端末はある

➤ ただ、4チャンネルしか同時に再生できる端末もある（最新端末でも！）

➤ 自作でオーディオミクシングを行うことでどの端末でも欲しい結果は出る
➤ ただ、4チャンネルしか同時に再生できる端末もある（最新端末でも！）

⑥ Xcode 8から9にアップデートしたらiOS .ipaが即クラッシュ問題

➤ ローカルでデバッグ版、リリース版は正常に動く

➤ TestFlightでダウンロードする.ipaは起動すると即クラッシュ

➤ TestFlightでダウンロードする.ipaは起動すると即クラッシュ
➤ 2週間ほどのデバッグとAppleとの連絡やりとりでいくつの条件が重ねたことでツ
ールのバグ発生が判明：
➤ CFエンジン内でのグローバルoperator new / deleteの置き換え
➤ 「JSON for Modern C++」の外部ライブラリのstd::allocator使い方
➤ .ipaアーカイブの時にしか行わないAppleのstripツールの不具合

➤ stripツールはデファルトパラメータでグローバルoperator new/deleteはdynamic link用のexportテ
ーブルに出ていなかった

➤ stripのオプションをデファルトから変える（strip -u -r）とグローバルoperator new/deleteはexport
テーブルに出るようになった

➤ stripのオプションをデファルトから変える（strip -u -r）とグローバルoperator new/deleteはexport
テーブルに出るようになった
➤ ゲームは正常に動くようになった！

まとめ
➤ 繰り返してることをすぐに自動化にするとあとで得する

まとめ
➤ buildbotとfastlaneのお陰で「クリスタル・クラッシュ」開発中
のチームフィードバックが早く取れて、約3ヶ月で作り上げた

まとめ
➤ エンジン開発は本当に楽しいけど、端末の断片化問題で時間は
かかって色々と苦労はする

まとめ
➤ エンジン開発は本当に楽しいけど、端末の断片化問題で時間は
かかって色々と苦労はする
➤ 覚悟してない方は作ってあるエンジンを利用した方が近道！

クリスタル・クラッシュ【超攻撃的パズル合戦！】 (iOS / Android / Kindle)

ご清聴ありがとうございます！

Game Development and Automation @ Agile Sapporo 2018 #1

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Game Development and Automation @ Agile Sapporo 2018 #1

Similar to Game Development and Automation @ Agile Sapporo 2018 #1 (20)

Game Development and Automation @ Agile Sapporo 2018 #1

Editor's Notes