LR

開発日誌

―リトル・リコレクターのメンバーが、それぞれの目線で開発の様子をお届けします―

ストライプ
icon

#35 「最適化の取り組み 前編」

こんにちは。プログラマーの堀内です。

今回は、『リトルリコレクター』の最適化に取り組むにあたり、なぜ最適化が必要になったのか、またどのような点がボトルネックになりやすいのかといった概要をお話しできればと思います。 プログラミング寄りの内容になりますが、できるだけ噛み砕いて説明します。


はじめに最適化がなぜ必要になったのかをお話していきたいと思ます。 まずこのゲームのジャンルが、アクションゲームということもあり快適にプレイをしてもらうためには、"60FPS"は絶対に欲しいという要望がありました。

※FPS = 1秒間にどれだけ処理を行えるかの値

やはり今どきのゲーム、ましてジャンルがアクションとなると繊細な操作が求められるので、FPSが低かったりする場合キャラクターが思うように操作出来なかったりなど色々とプレイする際に弊害が出てきます。 実際にSwitchでプレイをしてみたところ45~50FPSしか出ておらず安定もしていないので、非常にプレイしづらい状況になっていました。 これはプレイ体験が落ちてしまうということで、開発も少し落ち着いてきつつある今しかないということで最適化に着手しました。 最適化をやらないにしても、今後要素が増えればそれだけ負荷は上がっていくため、早い段階で問題を把握しておく必要があります。


前置きが長くなりましたが本題に入ります。 まずプログラマー以外の人は、最適化?って人が多いかと思います。 ざっくりと説明をすると「ゲームが滑らかに動くように、内部の無駄を減らし、必要なものだけを効率よく実行すること」になります。

例えばキャラクター周りで

「必要のないオブジェクトまで毎フレーム更新していた」 「画面に見えてない背景も描画していた」

などを減らしていき、限られた16ms(60FPSの1フレームで使える時間)の中に処理を収めていくイメージです。

最適化は始める前に重要なことがあります、それは「計測をすること」です。 勘ではなく、実際に何がどれだけ重たい(負荷をかけている)のかをデータで把握することが最も重要です。 これを怠るとどこから手を付けて良いかわからず前に進めません。

今回の計測には主に以下を使いました。

  • Unity Profiler (Unityで開発していたら一番使うと思います)
  • RenderDoc (描画処理デバッグ用ソフトウェア)
  • Switch実機でのCPU/GPUの処理時間

これらを使って調査し、どの部分が重たいのかを特定して最適化箇所を絞って行きます。

加えて、ゲームを作る際どこがボトルネックになりやすいかも把握しておくと調査しやすくなります。 実際にどのあたりがボトルネックになりやすいのか例をいくつか上げます。

  1. キャラクターや敵、沢山の計算をするオブジェクトが多すぎる
  2. 描画対象が多すぎる(マテリアルやシェーダーの違いにより、まとめて描画出来ない状態)
  3. 半透明やポストエフェクトの描画負荷が高い(Bloom, Blur... etc)
  4. UIのキャンバスが静的なUIと動的なUIで別れておらず再計算されている
  5. 毎フレームメモリ確保やGC(ガベージコレクション)が走っている
  6. プレイ中にI/O(Input / Output)処理で大きなデータを読み込もうとしている

※I/O(Input / Output)とはストレージからのデータ読み込みや書き込みなどの処理を指します

ゲームが重かった場合は、これらと測定した値を比較して見るのも良いと思います。 今回は最適化全体の考え方と、調査の入口となる部分の紹介に留めました。

次回以降では、「どこをどう直したのか」「なぜそれで軽くなったのか」等といった点を、解説していけたらと思います。

page top