皆さん、こんにちは。
本日からUnity Advent Calender 2012の始まりです。
現在(2012/12/1)もまだ空きがあるので気軽にご参加ください！
-
今日はUnity4.0のドキュメントに追加されたPractical Guide to Optimization for Mobilesについて連々と書いていきます。
モバイル端末のための最適化ガイド
今からの話は、ゲーム開発者が新たにモバイルゲームを作成するためのガイドです。企画段階でのプロトタイプのゲームや、既存のプロジェクトを移植する際に、モバイル端末上で快適に実行させる、または、スペックの低いPC、WebPlayer用のゲームを作成する人にとって、とても有用な情報になります。
最適化についてのトピックは広範囲で、貴方のゲームは多くのものに依存していると思います。なのでこのガイドは製品の品質を保証するために一歩一歩進んでいくガイドよりもイントロダクションやリファレンスとして読んでいただくことがベストです。
全てのモバイル端末は皆同じではない
iOS側ではA4チップを基準としています。これはiPad/iPhone3GS/iPodTouchに使用されています。
Android側ではNexus OneやAndroid2.3を基準にしています。これは2010年にリリースされたもので、今となっては非常に遅くスペックも低いものですが、市場の大部分を占めています。なのでこれらの端末もサポートを行わないといけません。
モバイル端末は、はるかに遅いがそれと同様に速い部分を持っています。それは、モバイル端末の計算処理能力は凄まじい速さで向上していることです。モバイルGPUの新世代の登場によって5倍もの速さになりましたがこれは前例がないわけではありません。またPC業界と比較してもこの成長速度は速いです。
iOS端末の仕様についての概要はthe Hardware pageを御覧ください。
あなたが最新/将来のデバイス向けに最新の技術を使って開発をしたい場合、簡単に様々な問題を解決できるかもしれません。詳しくはFuture Mobile Devicesを御覧ください。
非常に性能の低いiPhone3GやiPod Touchについては特に注意をはらって最適化を行わないといけません。ですが、それらの端末は発売から2年以上経過しており、所持率はとても少ないのです。これらの人々に向けて多くの時間を割くことが得策でしょうか？古い端末のサポートは行わないことも1つの手だと思います。
デザイン面で最適化を行う。これは最終ステップではない
英国のコンピュータ科学者「マイケル A. ジャクソン」という人物がいますが、彼のプログラムの最適化ルールについて多くの人が引用して紹介をしています。
プログラミング最適化の最初のルール: プログラミングの最適化を最初にするな。
プログラミング最適化の2番目のルール(専門家向け。専門としてる人以外は必ずしも守る必要はない。): まだプログラミングの最適化をするな。
この彼の理論的根拠は、コンピュータの性能が向上し、処理速度が向上していることを考えれば、プログラマがどうやってコーディングしたかは関係なく、それは十分速く動くという見込みが高いことにありました。
それに加え、極度に最適化をし過ぎてしまうと、全体的に複雑になってしまったり、あなたができる事に制限を掛けてしまったり、多くのバグを生み出してしまう可能性があります。
一般的には、この考えを採用しても良いのですが、モバイルゲームの開発となると他に考慮しなければいけない部分が出てきます。現在、市場に出回っているハードウェアは、普段私達が触っているコンピュータ(PC)に比べて非常に多くの制限が掛けられてしまっています。したがって、最初から最適化を行うということは、単に複雑なリスクを負い、デバイスの稼働バランスが取れなくなり、実行されない危険性を負うだけなのです。
話が長くなりましたが、このガイドはあなたの浅薄な状況に対して、これから指摘する最適化の話が非常に助けになることだと思います。
最適化 : プログラマに限らない話
アーティストはプラットフォームの制限と、その制限を回避する方法を知っておく必要があります。それにより、クリエイティブな選択を行うことが出来、作業のやり直しも必要がなくなるでしょう。
- もしゲームデザインが雰囲気や照明をベイクせずにテクスチャに描画するのなら、多くの責任はアーティストにかかることになります。
- 何かをベイク出来るときはいつでもアーティストはリアルレンダリングの代わりにベイク用のコンテンツを生成することができます。これはアーティストの技術的限界を突破して作業ができることになります。
あなたの思い通り、スムーズに実行するために、ゲームのデザインを作成する
ゲームの一般的なパフォーマンスの話、あなたのゲームの最適化でベストなデザインの方法を説明します。また、既にプロジェクトが稼働している場合でも、最適化を行う必要があるかどうかについて、把握する方法も説明をします。
早い段階から頻繁にProfilerを使用する
どこに最適化の時間をかければいいのか、些細な影響のことにどれだけの時間を浪費するのか。この判断を手助けしてくれるのでプロファイリングはとても重要です。
レンダリングはGPU上でハンドルされる方法のため、フレームのレンダリングにかかる時間はCPUにプラスされた時間ではありません。GPUに必要な時間はCPUとGPUで比べると、最も処理が長くなります。
CPUが処理を遅くしているのであれば、シェーダーについての最適化を行なっても意味がありません。また、GPUが処理を遅くしているのであれば物理学とスクリプトを最適化しても意味がありません。
ゲームの一部が異なる部分はよく違うものとして実行されるので、もしかしたらスクリプトのためだけに100ミリ秒のフレームを引き起こしてしまう可能性があります。また、他の部分で同じような処理の減速を引き起こす可能性もあります。しかしそれは何かのためにレンダリングされているからです。なので、せめて、あなたのゲームを最適化したいのであれば、どこがボトルネックになっているか知っておく必要があります。
Unity Profiler (Proのみ)
プラットフォームがiOS/Androidの場合でもUnityのプロファイラを使用することができます。使用する方法についてはProfiler guideを御覧ください。
Profilerの内部
プロファイラのテキストデータは30フレームごとに吐き出されます。それはあなたのゲームがどれだけ遅いかを把握するのにも役立ちます。物理学、スクリプト、レンダリングの詳細についてあまり詳しく触れることはできませんが、スクリプトかレンダラーが原因ということはわかります。
更に詳しい動作について知りたいのであればInternal Profiler pageをご覧下さい。
Profilerは大抵の場合レンダリングについて示される
Profilerはレンダリングを除いては大抵の場合スクリプトについて示される
目次
- Practical Guide to Optimization for Mobiles - Future & High End Devices
- Practical Guide to Optimization for Mobiles - Graphics Methods
- Practical Guide to Optimization for Mobiles - Scripting and Gameplay Methods
- Practical Guide to Optimization for Mobiles - Rendering Optimizations
- Practical Guide to Optimization for Mobiles - Optimizing Scripts