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

Android端末はバラエティに富んでいるCPUアーキテクチャ グラフィックス サウンド

ARM(v7-a, v8-a,…)

MIPS(mips32r2)

Intel(x86, x86_64)

ImgTec(Power VR)

ARM(Mali)

QUALCOMM(Adreno)

NVIDIA(Tegra)

QUALCOMM

Wolfson

Texas Instruments

YAMAHA

そして多くのOSバージョンと端末ベンダー固有のドライバ群…

多くのデバイスでテストする←必然

テスト用端末の中で何が起こっているかを早期に掴むことは重要

社内テスト端末限定の機能としてアプリ実行状況モニタリングサービスを作った

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

サウンド重視のモバイルゲーム設計

通常の「システムクロック=正義」実装だと音ズレが激しくて詰む

90秒程度の曲再生で最終的に250ms以上ズレるとかざら

→音飛びを検出し、ゲーム進行ロジックを音飛び結果に対して補正する

やってみると…

ある曲の再生時間誤差計測例 (Y軸=再生位置-システムクロック)

Xperia acro HD/4.0.4

Galaxy Nexus/4.2.2

Galaxy S4/4.2.2

0ms

83ms

-83ms

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

OSとドライバの限界

端末とOSバージョンの組み合わせ、負荷状況で出力タイミングが変わる

Android 4.1以降(現実的には4.2以降)ではLow Latency Audioを利用できる

全パターン網羅するのは基本的に無理筋

全体のズレを許容した上で最善を求めるのが良い筋

プレイアビリティに強く関わるのは 大きな差よりもジッタ(ゆらぎ)

このままゲームに使うと…

フレームが飛んでガックガク

蛇行運転で酔うような感覚

3フレーム以上飛ぶケースがある

50ms(3f)+

※前掲図の時間軸拡大

ジッタ低減策を投入サウンド再生時間とシステムクロックの情報をブレンド

「ゲームとして都合の良い、一貫性のあるタイムスタンプ」を生成

音飛び時もスムージングをかける

サウンド起因のタイムスタンプ差を1フレーム以下に収めた(元の30%弱)

13ms(～1f)

今後

限定的に利用しているLow Latency Audioを、より広い範囲の端末で利用できるようにサウンドライブラリを改修

Android 4.4の新機能を利用してサウンド出力時間差をある程度把握して改善に活かせないか調査中

https://github.com/KLab/PlaygroundOSS のissuesなどでご意見ください

宣伝

オーディオの話と、AndroidにおけるDRMの話を”Effective Android”に寄稿しました

他にも熱いトピック目白押しなのでぜひお買い求め下さい http://tatsu-zine.com/books/effective-android