http://atnd.org/events/44622 の講演内容後半です

1. “Playground”とAndroid
- マルチPF対応ゲームエンジン内のAndroid対応 Kei Nakazawa(@muo_jp) / KLab Inc.

2. Android端末はバラエティに富んでいる
CPUアーキテクチャ
グラフィックス
サウンド
ARM(v7-a, v8-a,…)
QUALCOMM(Adreno)
QUALCOMM
NVIDIA(Tegra)
Wolfson
ImgTec(Power VR)
Texas Instruments
ARM(Mali)
YAMAHA
MIPS(mips32r2)
Intel(x86, x86_64)
そして多くのOSバージョンと端末ベンダー固有のドライバ群…

3. 多くのデバイスでテストする←必然
テスト用端末の中で何が起こって
いるかを早期に掴むことは重要
社内テスト端末限定の機能として
アプリ実行状況モニタリングサー
ビスを作った

4. 様々な端末でテストしているうちに
見えてきたこと

5. サウンド重視のモバイルゲーム設計
通常の「システムクロック=正義」実装だと音ズレが激しくて詰む
90秒程度の曲再生で最終的に250ms以上ズレるとかざら
→音飛びを検出し、ゲーム進行ロジックを音飛び結果に対して補正する
やってみると…

6. ある曲の再生時間誤差計測例
(Y軸=再生位置-システムクロック)
Xperia acro HD/4.0.4
Galaxy S4/4.2.2
83ms
0ms
-83ms
Galaxy Nexus/4.2.2

7. スピリチュアルやね。。。

8. OSとドライバの限界
端末とOSバージョンの組み合わせ、負荷状況で出力タイミングが変わる
Android 4.1以降(現実的には4.2以降)ではLow Latency Audioを利用できる
全パターン網羅するのは基本的に無理筋
全体のズレを許容した上で最善を求めるのが良い筋

9. プレイアビリティに強く関わるのは
大きな差よりもジッタ(ゆらぎ)
このままゲームに使うと…
50ms(3f)+
フレームが飛んでガックガク
蛇行運転で酔うような感覚
3フレーム以上飛ぶケースがある
※前掲図の時間軸拡大

10. ジッタ低減策を投入
サウンド再生時間とシステムクロッ
クの情報をブレンド
13ms(∼1f)
「ゲームとして都合の良い、一貫性
のあるタイムスタンプ」を生成
音飛び時もスムージングをかける
サウンド起因のタイムスタンプ差を
1フレーム以下に収めた(元の30%弱)

11. 今後
限定的に利用しているLow Latency Audioを、より広い範囲の端末で
利用できるようにサウンドライブラリを改修
Android 4.4の新機能を利用してサウンド出力時間差を
ある程度把握して改善に活かせないか調査中
https://github.com/KLab/PlaygroundOSS のissuesなどでご意見ください

12. 宣伝
オーディオの話と、AndroidにおけるDRMの話を
”Effective Android”に寄稿しました
他にも熱いトピック目白押しなので
ぜひお買い求め下さい
http://tatsu-zine.com/books/effective-android