Más contenido relacionado
La actualidad más candente (20)
Similar a Unityとスマートフォンアプリの最適化 (20)
Unityとスマートフォンアプリの最適化
- 3. Kuma the bearとは・・・
オフラインで動作するアプリである事
デバイスや通信環境に依存しないプラットフォームとして。
できるだけ多くの端末をカバーするため。
グローバルである事
App Store / Google Playのプラットフォームで展開する以上、
ローカライズも積極的に。
ゲームとして面白いものである事
スマートフォンデバイスの性能から、携帯の付加機能のゲームではな
く、ゲームプラットフォームそのものとして考える。
3
- 5. Kuma the bear新タイトル「むしアミ!」
むしvs女の子
13種類の敵キャラ
6種類のウェポン
5種類のサブウェポンを組み合わ
ジフル せて、戦うディフェンス系シュー
普段はフィギュアだけど ティングゲーム!
むしから家を守るため立
ち上がった!
武器選択・主人公のステータス振
り分け可能!
全300ステージ、かなりやりごた
えあります!
5
- 7. Kuma the bearタイトルのメンバー
こんな感じで一つのプロジェクトを回しています!
基本はスモールチーム(3-4人)
プロジェクト初動は、
・エンジニアがプロトタイピング
・ディレクターとデザイナーが企画を
ディレクター
固める
後半に別のプログラマーがジョイン
プログラマー デザイナー
意思決定は早く!
3Dモデラー プロジェクト終盤は皆で
プログラマー ゲームバランスの調整
みんなUnityを使ってます!
7
- 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
- 19. リズムコイン ∼問題その1 物理系が遅い∼
問題 その1. 全体的に遅い、もっさりしている。
➡ Profilerで見ると、CPU UsageがほとんどPhysics関係。
疑いその1. Mesh Colliderの頂点数が多いんじゃない?
Primitive Colliderではどうしようもできないので、
8面のCollider用のMeshを別途作成
➡結果ほんの少しだけ軽くなったけど、基本は変わらない!
疑いその2. そもそもコインが重くって場に残り過ぎなのが問題では?
コインのPhysics Materialの摩擦係数を軽くして、土台から流れやすくする
事で、結果的に衝突回数を減らせて、Physicsの抱える問題を解決!
➡当たり!軽くなったけど、ゲームバランスをもう一度見直す事に。
パフォーマンス調整でゲームバランスへの影響をする事は多いので段階
的にパフォーマンスチェックも随時すべし!
19
- 20. リズムコイン ∼問題その1 突如落ちる∼
問題 その2. フィーバーモード突入時に一部Android端末で落ちる。
➡ クマの後ろで出しているRendererテクスチャが原因じゃないか?
どうやらテクスチャの初期化で落ちるのは
GalaxyS で再現性が取れた。
➡動的にスクリーンのMaterialにSetTextureをし
ていたのが問題。
・初期化のタイミングでRenderTextureを割り当
てて、動作中にActiveのON/OFFで切り替えるよ
うにした。
RendereTextureの使用そのものを控えるべきですが、
その他 IS03 など一度に複数のRenderTextureが使えない端末もありました。
GPUに依存するところが大きいです。
20
- 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
- 28. むしアミ! ∼パフォーマンスチューニング∼
問題 その1. やっぱり遅い。
➡今回もキャラクターはSkinned Mesh Renderer使っています。
Physicsは衝突はさせていませんが、Triggerには使ったりしています。
➡Physicsの計算をはしょったりFPSを落としたりできない!
➡やられやポイント取得などのエフェクトの拡大縮小などをモデルとアニメー
ションが行われいたため
そこでのDrawCallをバッチングさせるために、テクスチャのOffsetアニメー
ションなどで実装。演出もEzGUIで実装。
➡Draw Callのバッチングが効くケースと効かないケースを
しっかり把握しておく事。
➡全体的に敵の流れが良くなるように、ゲームのバランスを調整。
➡結果として真っ向勝負せず、パフォーマンスを改善。
28
- 29. むしアミ! ∼ステージ調整∼
問題 その2. 全ステージ300ステージ
➡Inspector上からの調整は誤入力などがでそうで、正直怖い。
CSV必要でやる事に決めた。
➡Export / Import スクリプトをEditorスクリプトで調整。
パフォーマンスを考慮して、EditorスクリプトからPrefabを書き換え
る形に。
➡Excelでグラフ化しながら大雑把に調整。
➡300ステージでのパラメータ入力にあたり、難易度にゆらぎ・誤入力
が出ないように、Editorスクリプト上でバリデーションを実装。
Inspectorでの配列操作は100くらいまでが上限かと、、
それ以上のパラメーターはCSVとの連携が可視化の意味でオススメ!
29
- 31. EzGUI Localize Tips! その1
フォントスプライトシートの出力でMac上であれば、
BMGlyphかGlyphDesignerで。
両方ともEzGUI用のExport設定あり。
文字の装飾はGlyphDesignerが奇麗に出せるので、こちらを推奨します!
31
- 32. EzGUI Localize Tips! その2
GUIのスプライトシートは無圧縮16bit画像につき、メモリの圧迫サイズが大きいので
システム言語環境に応じて初期化のタイミングで、Resources.LoadしてMaterialの
MainTextureを変更する。言語間の共通のUIはそのまま共有。
日本語版のGUIリソース 英語版のGUIリソース
32