Unityの検索機能

Unity でしてはいけないこと: 回避すべき最もよくあるミス

最終更新:2018 年 12 月

このページで学べる内容:このガイドは、開発中に参考にしていただくことをお勧めします。Unity フィールドエンジニアの Valentin Simonov による有益なヒントに従えばスマートで効率の良い開発パイプラインを構築することが可能です。そして、最終的には元と比べると一層パフォーマンスに優れたコンテンツとなって、リリースすることができるようになります。

プランニング

このフェーズで下した判断は開発サイクルの後期では変更困難となるため、いかなるソフトウェア開発プロジェクトにとっても最高に重要な部分となります。

プロジェクト開始前のリサーチが不十分

  • すべてのターゲット・プラットフォームで搭載予定の全機能が実際に動作するか確認する。

プロジェクトの対象として最低限動作を保証するデバイスが指定されていない

  • 最低限コンテンツの動作を保証するデバイスを明確にする
  • 開発チームとQAチームが利用可能。
  • これを行うと、現実的なパフォーマンスとフレーム予算を設定することができる。

フレームとアセットの予算は早くから設定しない。

  • 以下に対して予算を設定します:
    • モデル — ターゲットデバイスはいくつの頂点をレンダリングできるのか
    • アセット — モデルやテクスチャはどのくらいのディテールにするのか
    • スクリプトとレンダリング — ロジック、レンダリング、エフェクトやサブシステムなどについて、フレームのうち何パーセント占めているか

詳しくは以下のリンクからご参照ください:

グラフィックパフォーマンスの最適化

パフォーマンス最適化のためのキャラクターのモデリング

シーンの分割およびプレハブの分割は早い段階で設定しない。

... あるいは (つまり) 全員が同じシーンで作業する。

  • レベルを (追加でロードされた) シーンに分割する。
  • 個別のオブジェクトをプレハブに移動し、個別のシーンで編集を行う。
  • メインシーンのロッキング機構に同意する。

アセットパイプラインプロセスの計画が不十分

このプロセスは、アーティストからの仕様にしたがって、アセットをプロジェクトに取り込むことです。

  • 可能であれば、このプロセスを効率化し実行するために最初からテクニカルアーティストを入れる。
  • アセットのフォーマットと仕様に関する明確なガイドラインを定義する。
  • インポート時間のテストを追加する。

詳しくは以下のリンクからご参照ください:

アートアセットベストプラクティスガイド

Unity アセットのインポート

ビルドとQAプロセスのスケジュール表を持っていない

  • ビルドマシンをセットアップするか、Unity Teams を有効にしてセットアップする。
  • どうやって機能をリリースビルドへ公開するのか
  • 新しいビルドはどのようにテストされるのか
  • これらのテストは自動化されてるか
  • 統計情報は記録されているか

Unity のセットアップ(Cloud Build)

初期プロトタイプの後では、プロジェクトは最初から開始されない

プロトタイプを構築して管理部門による承認を受けた後に、1 から作成を開始することを強くお勧めします。

  • プロトタイピングの間に行われた決定は、通常スピードを優先する
  • ゲームを数多くのヒントとコツ(hacks)などに基づくのは、どのプロジェクトにとっても良いスタートとはいえない。

Unity-best-practices-planning

開発作業

開発中の間違った手順やミスによって、チーム全体の作業効率を下げ、最終製品のクオリティを低下させます。

バージョンコントロールが正しく設定されていない

  • テキストのシリアライゼーションを使用 (デフォルトでは Unity)
  • ビルトインのYAMLマージツールをセットアップする。SmartMerge の詳細はこちら
  • コミットをフックする。詳しくはこちらを参照。

キャッシュサーバーの不使用

静的データは JSON または XML ファイルに保存されている

  • この結果、ロードが遅くなる。
  • 解析するとゴミが生成される。
  • 代わりに、ビルトインされている静的データを取得するためににカスタムエディターツールで ScriptableObject を使用する。

このプロジェクトには、未使用のアセット、プラグイン、複製されたライブラリなどが含まれている

プロジェクトの未使用のアセットがゲームに組み込まれる可能性は非常に高いです。プロジェクトにゴミを残さないようにしましょう。バージョン管理システムをセットアップする場合、ファイルの復元は簡単であるべきです。

  • プロジェクトにドラッグするアセットストアから入手したアセットがどんな依存関係なのかを確認する。プロジェクト内に5種の JSON ライブラリがあることに気づき驚く可能性がある。
  • 初期のプロトタイプの古いアセットやスクリプトに注意
  • 古いアセットを「削除済み」フォルダに移動したとしても、ゲームに組み込まれているリソースとスクリプトは変わらずそのままであることに注意

反復行動にはマニュアル作業が必要

  • 反復タスクごとにスクリプトを自動化する必要がある。
  • どのシーンからでもゲームやインタラクティブコンテンツを「再生」できることを確認する。
  • 構築プロセスのすべてのステップを自動化することで、アプリケーションをボタン 1 つで Cloud Build またはローカルで構築できるようにする。

エディター内からのみ行うプロジェクトのプロファイリング

  • 常にターゲットデバイス上でコンテンツのプロファイルを行うようにする。エディターのみでプロファイルした場合、実際のパフォーマンスのボトルネックを見逃してしまう可能性がある。

Unity プロファイラー

内蔵のプラットフォームに固有のプロファイリングツールとデバッグツールの両方を使用しない。

詳しくは以下のリンクからご参照ください:

パフォーマンス最適化全般

シェーダーのプロファイリングと最適化に関するヒント

Unity のフレームデバッガー

プロファイリングおよび最適化を行うのは開発サイクル中では遅すぎる

  • プロファイリングを待つ時間が長くなればなるほど、パフォーマンスコストが高くなる可能性がある。
  • 早い段階でプロファイリングを始めて、プロジェクトがフレーム、メモリ、ディスクサイズなどの予算に収まるようにする。

最適化はテストデータに基づいてない

  • 実際のボトルネックを最適化していることを確認する。
  • 指定された上記のツールを使用して、正しいデータを収集する。

ターゲットプラットフォームに関する知識が不十分

  • ターゲットプラットフォームについて十分な知識があるようにする
  • デスクトップ、モバイル、コンソールなどのプラットフォームには、かなり異なるボトルネックがある。

Unity のベストプラクティス(開発)

アセットの設定

アセット (モデル、テクスチャ、サウンド) は、ゲームの大部分を占めます。プロジェクト内のメッシュが1つでも間違っていたら、プログラマーが行ったすべての最適化を無効化することができます。

スプライトアトラスが正しく設定されていない

  • サードパーティのツール(TexturePacker など)を使用し Unity でアトラスか、グループスプライトを作成する。これでゲームでのドローコールの回数が減らせる。

テクスチャ設定が正しく設定されていない

  • ターゲットプラットフォームの正しいテクスチャ設定かはっきり確かめること:
    • プラットフォームはどんな圧縮をサポートするのか
    • テクスチャ設定でミップマップは必要か。
  • セットアップで示されている形で AssetPostprocessor API を使用し、 を使用して新しいテクスチャーにまつわる設定を適用できるように自動化するセットアップを行う。
  • アーティストが間違った設定でテクスチャをコミットするのを防ぐ。

Unity アセットのインポート設定

アセットバンドルに重複したテクスチャが含まれる

  • アセットバンドルのビルドシステムのセットアップは間違えやすいもの(特にテクスチャが重複する場合)。こちらから良いガイドラインを入手しよう。
  • アセットバンドルブラウザを使用して依存関係を追跡する。

Unity のベストプラクティス(アセットの設定)

プログラミング

コードアーキテクチャや開発における雑な作業やミスにより、開発の生産性を低下させます。

コードは非常に難解でついていけない

  • Abstract Enterprise コードはめったに正当性が示されない。
  • コードを推論するのが難しくなる。
  • つまり、より遅く実行され、IL2CPP はより多くのコードを生成する必要がある。

アーキテクチャの規約は定義されていないか、あまりドキュメント化されていない:

  • コードを記述することで回避する。同じタスクを実行するために異なるメソッドを使用する。たとえば、以下のようなタスクに使用する:
    • フォーマットを設定 (ファイル、プロパティ、アセット)。
    • イベント (Unity イベント、C# イベント、SendMessage)
  • どのマネージャーがどのオブジェクトを担当するのか。

Unity フレームループを十分に理解することはできない

  • Awake、OnEnable、Update メソッドが呼び出されたとき。
  • コルーチンが更新されるとき。
  • どのように FixedUpdate が実行されるのか。

スクリプト初期化のロジックは、Unityの実行順序に依存する

  • 「これだけでも動作する」、あるいは 各スクリプトの実行順(Script Execution Order)を誤用する。

スクリプティングロジックやアニメーションのスクリプトを書く際にフレームレートは考慮されない

  • FPS に依存しないスクリプトには Time.deltaTime を使用する。

詳しくは以下のリンクからご参照ください:

Scriptable Objects を使って構築するための 3 つの方法

より優れたスクリプティング体験を

Unity のベストプラクティス(プログラミング)

CPU パフォーマンス

CPU 使用率が高くなるほどゲームプレイ時に「ラグ多発状態」となり、バッテリーの消費が早くなってしまいます。

Unity の CPU プロファイラー

Update() メソッドを持つスクリプトが多すぎる

  • ネイティブ - >マネージドコールには、ある程度のオーバーヘッドがあります。詳しくはこちらのブログ記事を参照してください。
  • 代わりに、カスタムマネージャーを使う

すべてのカスタムビヘイビアは、Update/Awake/Start メソッドが定義された抽象クラスから継承する

  • これで、すべてのスクリプトに Update() メソッドが追加された。

すべてのゲームシステムはフレームごとに更新される

  • ゲーム/コンテンツ内において、次のようなさまざまなシステムの更新頻度を定義しておく。
    • オブジェクトの移動
    • AI 機能とパス検索
    • ゲームステートをロギングおよび保存する
    • その他、「重くなる」システム。

頻繁に必要なオブジェクトへのデータや参照はキャッシュされない

頻繁に必要なデータをキャッシュに入れる

  • リフレクション
  • Find()
  • Camera.main
  • GetComponent()

頻繁にインスタンス化されるオブジェクトはプールされない

  • オブジェクトをインスタンス化するのが遅い。
  • ゲームの開始時にオブジェクトのプールを作成する
  • 新しいオブジェクトを作成する代わりに、オブジェクトを再利用する

メモリはどのフレームにも割り当てられる

  • フレームごとの小さな割り当てでも、いつかは GC スパイクを生じる
  • すべての割り当ての排除を試みる

割り当てのない代替手段の代わりに API のメモリ割り当てが使用される

  • LINQ
  • 文字列
  • 配列を返す Unity API:
    • Physics.RaycastAll, Mesh.vertices, GetComponents など

詳しくは以下のリンクからご参照ください:

C# のデータ構造と Unity API を使って最適に作業を行いましょう

Unity のベストプラクティス(CPU のパフォーマンス)

GPU パフォーマンス

GPU 使用率が高いほどフレームレートが低く、かつバッテリーの消耗が早くなり、さらにゲーム/コンテンツの「動作が重い」、と受けとめられてしまいます。

Unity の GPU プロファイラー

モバイルについて: このプロジェクトはオーバードローが大量に発生している

  • モバイル GPU は、毎秒大量のピクセルだけ描画することができる。
  • オーバードローは、モバイルにおける最大のパフォーマンスのボトルネックとなる
  • 不要なトランスペアレントの画像を描画しない。
  • 複雑なメッシュを用い、完全にトランスペアレントな領域をトリミングする。

モバイルについて:シェーダが複雑すぎる

  • Standard Shader をモバイルで使用しない。
  • 専用のカスタムシェーダーを作成する。
  • ローエンドのデバイスについては簡易版を使用するか、いくつかのエフェクトを無効にする。

多くのダイナミックライトはフォワードレンダリングで使用される

  • すべてのライトは、照らし出されたオブジェクトごとにレンダリングパスを追加する。

プロジェクトの間違った設定で動的バッチ処理が中断される。

  • オブジェクトが動的にバッチ処理されるには「類似」している必要がある。
  • フレームデバッガは、特定のオブジェクトがなぜバッチされなかったという情報を示している。

LOD が使用されていないか、正しく設定されていない

  • LOD の使用で追加的なオブジェクトのレンダリングリソースをより少なくできます。

詳しくは以下のリンクからご参照ください:

ドローコールがバッチ処理されない理由

モバイル最適化に関するベストプラクティス

Unity のベストプラクティス(GPU のパフォーマンス)

UI のパフォーマンス

Unity UI はアーティストにとって使いやすいツールです。ただし、間違って設定するのがむしろ容易であるため、多くの CPU と GPU のリソースを消費する状態になります。

Unity UI

異なる解像度とアスペクト比は考慮されない

  • 異なる解像度とアスペクト比のデバイスで UI のテストを行う
  • 異なるデバイスに異なる UI 画面を作成する方が良いときもある

アニメーション要素は同じ Canvas にある

  • 要素が変更されると、Canvas は新しく結合するメッシュを作成する必要がある
  • 複雑な Canvas について、コストがかかる場合がある
  • アニメーション要素を別々の Canvas に移動する

新しいウィンドウを「開く」ことは最適化されていない

  • 新しいウィンドウまたは UI の大きな塊(チャンク)が作成されると、ゲームには顕著なタイムラグが生じる。このエフェクトを最小限に抑えるようにする。
  • UI ウィンドウをより単純にする
  • UI を分割する
  • ウィンドウをキャッシュする

リストには膨大な量のアイテムが含まれている

  • 一度にすべてを作成する代わりに、リスト項目を動的に再利用する。
  • リストにネストされた Canvas を作る
  • こちらのようなオープンソースの実装

参照:

Unity UI の最適化に関するヒント

Unity のベストプラクティス(UI のパフォーマンス)

その他のリソース

今後のためにうかがいます。このコンテンツはいかがでしたか?

もっと読みたい いまいちです

Unity学習情報

Unity のエキスパートから技術とクリエイティブに関するノウハウを受け取りませんか?

サブスクライブ
OK

弊社のウェブサイトは最善のユーザー体験をお届けするためにクッキーを使用しています。詳細については、クッキーのポリシーのページをご覧ください。