鲍苍颈迟测とスマートフォンアプリの最适化
109 likes54,720 views
"COLOPL UnityNight" (2012/04/13開催) の発表資料です。 Unityを用いたスマートフォン向けゲーム開発の体制や、"Kuma the Bear"ブランドで発表している各ゲームの制作時の最適化について説明させていただきました。
![基本のターゲットプラットフォーム
Armv6 Armv7
遅い。iOS4.2で動く
[v6 + v7]はバイナリがでかいのでv6 N/A
GL ES1.1 のみで。
とほぼ同じだが、
やや遅い。実行環境にゆらぎが少ない。
動作速度は早い、海外製の一部端末
ほぼ全てのArmのAndroid端末で稼働。
が対象外となってしまう。
iOS4.3からの対応。早い。
N/A
GL ES2.0 3G/iOS4.2以下は完全に切り捨て。
端末によって、性能のゆらぎが大きい。
端末によって、性能のゆらぎが大きい。
かなり遅くなる事も。
対応端末を多くするために省サイズを意識して、
ミニマム構成での動作を想定した作りに！
11](https://image.slidesharecdn.com/coloplunitynight-120416233602-phpapp02/85/Unity-11-320.jpg)
More Related Content
What's hot (20)
Similar to 鲍苍颈迟测とスマートフォンアプリの最适化 (20)
![[120915] igda sig indie9](https://cdn.slidesharecdn.com/ss_thumbnails/120915igdasig-indie9-121223044418-phpapp01-thumbnail.jpg?width=560&fit=bounds)
Recently uploaded (11)
鲍苍颈迟测とスマートフォンアプリの最适化
- 1. COLOPL Unity night! 鲍苍颈迟测とスマートフォンアプリの最适化 Kuma the bear準備室 2012年４月 ?2012 COLOPL, Inc. All Rights Reserved.
- 2. Boot Camp帰りの皆様 おつかれさまでした！ 2
- 3. Kuma the bearとは??? オフラインで動作するアプリである事 デバイスや通信環境に依存しないプラットフォームとして。 できるだけ多くの端末をカバーするため。 グローバルである事 App Store / Google Playのプラットフォームで展開する以上、 ローカライズも積極的に。 ゲームとして面白いものである事 スマートフォンデバイスの性能から、携帯の付加機能のゲームではな く、ゲームプラットフォームそのものとして考える。 3
- 4. Kuma the bearタイトルのご紹介 きらきらドロップ! the射的! リズムコイン! わっさーゾンビ! 4
- 5. Kuma the bear新タイトル「むしアミ！」 むしvs女の子 13種類の敵キャラ 6種類のウェポン 5種類のサブウェポンを組み合わ ジフル せて、戦うディフェンス系シュー 普段はフィギュアだけど ティングゲーム！ むしから家を守るため立 ち上がった！ 武器選択?主人公のステータス振 り分け可能！ 全300ステージ、かなりやりごた えあります！ 5
- 6. という訳で??? ものづくりのお話 6
- 7. Kuma the bearタイトルのメンバー こんな感じで一つのプロジェクトを回しています！ 基本はスモールチーム(3-4人) プロジェクト初動は、 ?エンジニアがプロトタイピング ?ディレクターとデザイナーが企画を ディレクター 固める 後半に別のプログラマーがジョイン プログラマー デザイナー 意思決定は早く！ 3Dモデラー プロジェクト終盤は皆で プログラマー ゲームバランスの調整 みんなUnityを使ってます！ 7
- 8. Kuma the bearのメンバー 技術のメンバーはUnityを中心にメンバーの特性(バックグラウンド)を生かす！ iOS Unityそのものに ネイティブ周り 超詳しい に強い AssetStoreオタク iTunes Connect Android ネイティブ周り ３Dに強い に強い コンシューマー Google play あがり Unity EditorScript でツール作り GLとか解ってる チームメンバーのUnityに関するナレッジはフラットに！ 8
- 11. 基本のターゲットプラットフォーム Armv6 Armv7 遅い。iOS4.2で動く [v6 + v7]はバイナリがでかいのでv6 N/A GL ES1.1 のみで。 とほぼ同じだが、 やや遅い。実行環境にゆらぎが少ない。 動作速度は早い、海外製の一部端末 ほぼ全てのArmのAndroid端末で稼働。 が対象外となってしまう。 iOS4.3からの対応。早い。 N/A GL ES2.0 3G/iOS4.2以下は完全に切り捨て。 端末によって、性能のゆらぎが大きい。 端末によって、性能のゆらぎが大きい。 かなり遅くなる事も。 対応端末を多くするために省サイズを意識して、 ミニマム構成での動作を想定した作りに！ 11
- 12. 基本のターゲットプラットフォーム 参考までに、リファレンス機 Galaxy S 2010年10月発売 iPhone 3GS 2009年 6月 12
- 13. ところが、3月7に がらりと変わりました。 13
- 14. App Storeの3G回線ダウンロード制限が 20MBから50MBに! 14
- 15. アプリの省サイズ化小技とか、 お話ししようかと思いましたが 今回は割愛します！ でも、アプリの省サイズ化には努めましょう。 テクスチャサイズとかパフォーマンスに影響しますので。 15
- 17. リズムコイン！ 2012年 2月 17
- 18. リズムコイン?～ここでハマった～ 問題 その1. 全体的に遅い、もっさりしている。 ? Pro?lerで見ると、CPU UsageがほとんどPhysics関係。 問題 その2. フィーバーモード突入時に一部Android端末で落ちる。 ? クマの後ろで出しているRenderTextureが原因じゃないか？ 18
- 19. リズムコイン?～問題その１?物理系が遅い～ 問題 その1. 全体的に遅い、もっさりしている。 ? Pro?lerで見ると、CPU UsageがほとんどPhysics関係。 疑いその1. Mesh Colliderの頂点数が多いんじゃない？ Primitive Colliderではどうしようもできないので、 8面のCollider用のMeshを別途作成 ?結果ほんの少しだけ軽くなったけど、基本は変わらない！ 疑いその2. そもそもコインが重くって場に残り過ぎなのが問題では？ コインのPhysics Materialの摩擦係数を軽くして、土台から流れやすくする 事で、結果的に衝突回数を減らせて、Physicsの抱える問題を解決！ ?当たり！軽くなったけど、ゲームバランスをもう一度見直す事に。 パフォーマンス調整でゲームバランスへの影響をする事は多いので段階 的にパフォーマンスチェックも随時すべし！ 19
- 20. リズムコイン?～問題その１?突如落ちる～ 問題 その2. フィーバーモード突入時に一部Android端末で落ちる。 ? クマの後ろで出しているRendererテクスチャが原因じゃないか？ どうやらテクスチャの初期化で落ちるのは GalaxyS?で再現性が取れた。 ?動的にスクリーンのMaterialにSetTextureをし ていたのが問題。 ?初期化のタイミングでRenderTextureを割り当 てて、動作中にActiveのON/OFFで切り替えるよ うにした。 RendereTextureの使用そのものを控えるべきですが、 その他?IS03 など一度に複数のRenderTextureが使えない端末もありました。 GPUに依存するところが大きいです。 20
- 21. わっさーゾンビ！ 2012年 3月 21
- 22. わっさーゾンビ！?～ここでハマった～ 問題 その1. ここでも全体的に遅い、もっさりしている。 ? Skinned Mesh Renderer 使っているしDrawCall 数はゾンビの数 だけ発生。あと、やはりPhysicsが重い。 問題 その2. 実時間ベースでのゲームバランス調整は正直きつい。 ?ツールやシミュレーションベースの方法を使ってテスト。 問題 その3. iOS上でプチフリが発生。 (iPad / iPhone 3GS / iPhone4 ) ?データ保存のポーリングの中で発生。 22
- 23. わっさーゾンビ?～ パフォーマンス調整～ 問題 その1. ここでも全体的に遅い、もっさりしている。 ? Skinned Mesh Renderer 使っているしDrawCall 数はゾンビの数 だけ発生。Physicsも遅い。 ? ボーン入りのキャラクターアニメーショ ンを使っている都合上、 SkinnedMeshRenderer を切る事は不可 能。 ? キャラクターはRigidBody同士の衝突と なっているが、既にプリミティブのCollider となっている。 ? やや乱暴だが、Time設定のFixedDeltaTimeを調整する事で Physics.simulateの演算回数を減らす事で対応。 その他アプリケーションのフレームレート上限を30に指定。描画コスト減。 アクション性?物理特性がゲーム性に影響しないタイトルにのみ使用可能 23
- 24. わっさーゾンビ?～ ゲームバランス調整～ 問題 その2. 実時間ベースでのゲームバランス調整は正直きつい。 ?ツールやシミュレーションベースの方法を使ってテスト。 ?Time.timeScaleでの設定でx倍速モードでテストできるように構成をしてお く。 ?シミュレーター上からゲームの進行ログをConsoleだけでなく、CSVではけ るようにしておく。経過時間とイベント発生をグラフ化して、ゲーム内の進行状 況に偏りが出ないようにする。 段階の箇所で なんらかのイベ ント発生 24
- 25. わっさーゾンビ?～iOSでの問題～ 問題 その3. iOS上でプチフリが発生。 (iPad / iPhone 3GS / iPhone4 ) ?データ保存のポーリングの中で発生。 ?ゲームの特性上、PlayerPrefsが肥大化、 またゲームの特性上更新頻度が上がってしまった事が原因。 ?PlayerPrefsの保存は全ての処理が一時停止するため、まず は保存の項目の省サイズ化に努める。 ?OnApplicationPauseとOnApplicationQuitできちんとセー ブしてあげれば、問題無し。 ポーリングでデータ保存すると、壊す可能性も否定できないた め要注意！ 25
- 26. むしアミ！ 2012年 4月 26
- 27. むしアミ！?～ここでハマった～ 問題 その1. ここでも全体的に遅い、もっさりしている。 ? Skinned Mesh Renderer 使っているしDrawCall 数はむしの数だ け発生。あと、やはりPhysicsが重い。 問題 その2. 全ステージ３００ステージ ?Inspector上からの調整は正直難しい。 CSV必要でやる事に決めた。 27
- 28. むしアミ！?～パフォーマンスチューニング～ 問題 その1. やっぱり遅い。 ?今回もキャラクターはSkinned Mesh Renderer使っています。 Physicsは衝突はさせていませんが、Triggerには使ったりしています。 ?Physicsの計算をはしょったりFPSを落としたりできない！ ?やられやポイント取得などのエフェクトの拡大縮小などをモデルとアニメー ションが行われいたため そこでのDrawCallをバッチングさせるために、テクスチャのO?setアニメー ションなどで実装。演出もEzGUIで実装。 ?Draw Callのバッチングが効くケースと効かないケースを しっかり把握しておく事。 ?全体的に敵の流れが良くなるように、ゲームのバランスを調整。 ?結果として真っ向勝負せず、パフォーマンスを改善。 28
- 29. むしアミ！?～ステージ調整～ 問題 その2. 全ステージ３００ステージ ?Inspector上からの調整は誤入力などがでそうで、正直怖い。 CSV必要でやる事に決めた。 ?Export / Import スクリプトをEditorスクリプトで調整。 パフォーマンスを考慮して、EditorスクリプトからPrefabを書き換え る形に。 ?Excelでグラフ化しながら大雑把に調整。 ?300ステージでのパラメータ入力にあたり、難易度にゆらぎ?誤入力 が出ないように、Editorスクリプト上でバリデーションを実装。 Inspectorでの配列操作は100くらいまでが上限かと、、 それ以上のパラメーターはCSVとの連携が可視化の意味でオススメ！ 29
- 30. あとは、小技と贰锄骋鲍滨罢颈辫蝉を绍介 30
- 31. EzGUI Localize Tips! その1 フォントスプライトシートの出力でMac上であれば、 BMGlyphかGlyphDesignerで。 両方ともEzGUI用のExport設定あり。 文字の装飾はGlyphDesignerが奇麗に出せるので、こちらを推奨します！ 31
- 32. EzGUI Localize Tips! その２ GUIのスプライトシートは無圧縮16bit画像につき、メモリの圧迫サイズが大きいので システム言語環境に応じて初期化のタイミングで、Resources.LoadしてMaterialの MainTextureを変更する。言語間の共通のUIはそのまま共有。 日本語版のGUIリソース 英語版のGUIリソース 32
- 33. Android メモリ小技 Androidの実行メモリの使用量につき、OSによりActivityが終了させられる事 があります。 メモリの使用量は、AdmobなどNativeまわりもう考慮してUnity単体で 100MB以下までおさえる必要があります。 端末のタスクマネージャーに表示される数字については、端末毎に異なった数字 がかえってくるので、あてにはなりません。（Galaxy S2とか） adb shell top | grep package name adbを使えば、正しいメモリ使用量が取得できますので、adbを使って実際のメモリ の使用量として参考にしてください。 33
- 34. Android Native連携 小技 プロジェクト序盤ではUnityから直接APKを作っていて問題ありませんが、 後半では、Native側の連携が重要となり、なおかつ実機テストが必要となります。 いちいちEclipseを通してのパッケージングは面倒くさいので、UnityBuild後に Ant でコマンドラインビルドをするようにしました。 UNITY_PROJECT=~/Documents/unity/title/ ECLIPSE_PROJECT=~/Documents/Eclipse/title/ cp -r ${UNITY_PROJECT}/Temp/StagingArea/assets ${ECLIPSE_PROJECT} ant clean ant release Unity3.5では、Temp以下のコピーがうまく動かない問題がありましたが、 Unity3.5.1ではOK。 InAppBillingのテストなど署名つきビルドをする時には、署名のパスフレーズも Build.propertiesに書いておけば入力しないで済むので超便利！ 34
- 35. まとめ 1.パフォーマンスがらみは直面から勝負するよりも分析。 またSCMで必ずさかのぼれるようにして、原因の差分を比べる。 Pro?ler, Instruments,OpenGL ES Perfomance Detective, adbを駆使。 2.特定の問題の出やすい端末を把握しておく事が必要。 IS03, Arrows X , Infobar , Galaxy , iPhone3GS ... more 3.UnityのEditorScriptはエクスポート?インポートだけでなく、 パラメーターとの調整にもバリデーションにも使える。 汎用性の高いものを目指しがちだけど、プロジェクト毎でも起こす価値がある。 SerializeしてInspectorでの調整は便利だけど、数の多い配列はCSVも考慮して。 4.ゲームとしての面白みにこだわるための近道は常に確保。 AssetStoreは眺めるだけで楽しいもんです。 5.ツールを作るのはプログラマ的に、超楽しい。 35
- 36. クマベアチームはメンバー募集中です。 スマートフォンのゲーム好きなプログラマーの人 スマートフォンで勝負したい3Dモデラーの人 スマートフォンUIにこだわりあるデザイナーの人 WELCOME! 36
- 37. 本日はお忙しい中ご来場いただき 誠にありがとうございました。 See you next time! 37