要点： 「最後に最適化する」は、プロジェクトが認証で死ぬやり方です。パフォーマンス予算（コンテンツが作られる 前に合意されたフレーム時間とメモリの上限）、は、最適化を危機から日常のチェックに変えます。ポリゴンではなく ミリ秒を予算し、フレームをパイのように分け、三つの固定カメラで測り、作業が起きる場所に数字を見えるようにし、 シーンが赤くなったらコスト効率の順にレバーを引く。本記事は全システムを、適応できる開始数値とともに与えます。
ビスタは常に請求書：最大描画距離、すべてのシステムが一度に画面に、すべてのLODリングがアクティブ。この眺めを 予算せよ。廊下は自分で何とかする。
ポリゴンでなくフレーム時間を予算せよ
ポリゴン予算は遺物。現代のGPUは生の三角形のはるか前に、ドローコール、オーバードロー、影、メモリ 帯域で窒息する。あなたが実際に測るものを予算せよ：システムごと、眺めごとのミリ秒。
60 fpsのゲームはフレームあたり16.6 msを持つ；30 fpsでは33.3 ms。それが全予算で、すべてに分けられる： ゲームプレイ、物理、AI、VFX、UI、環境。環境のスライスはレンダリングとゲームプレイとの交渉。だがそれは数字で なければならない、合意され書かれた。さもなくば、あるシーンが「高すぎる」かどうかのあらゆる議論は好みと年功に 崩れる。フレーム時間の傍らに、それを縛る量に上限を与えよ：
- 眺めごとのドローコール（GPUが頭打ちになるはるか前にCPUを縛る）、
- ストリーミングゾーンごとのテクスチャとメッシュのメモリ（ストリームするかカクつくかを決める数字）、
- 眺めの中の影を落とすライト、
- オーバードローのホットスポット。植生とVFXがいつもの容疑者。
正確な上限はプラットフォームとエンジン次第だが、上限を持つという規律こそ、あなたが出荷するあらゆる プロジェクトに移るもの。間違いうる数字は、議論しかできない雰囲気に勝つ。
フレームをパイのように、ミリ秒で分けよ
各部門にスライスを与えよ（ゲームプレイ、VFX、UI、環境）、それから環境スライスをまた分けよ：地形、 植生、プロップ、水。「この森は高すぎるか？」が客観的な問いになる。
60 fpsタイトルの実行可能な開始分割、プロジェクトごとに再交渉：環境合計6〜8 ms、うち地形〜1.5、植生〜2〜2.5、 プロップと構造物〜1.5、水と大気〜1。要点はこの正確な数字ではない。森が2.5 msスライスに対して4 msを測るとき、 会話が「誰のせいか」でなく「どのレバーを引くか」になることだ。
スライスは過剰最適化への防御にもなる。それは本物で高くつく失敗だ。スライスの十分下に座るシステムは、余裕を 品質に使う招待であって、守るべきトロフィーではない。スライスのないチームは、最も声の大きいエンジニアが気づいた ものを最適化しがちで、それはめったに本当のボトルネックではない。円グラフが、ミリ秒が本当にどこへ行ったかを 教える。
三つの固定カメラで測れ
平均でなく、最悪の現実的な眺めを予算せよ。マップごとに三つの固定「予算カメラ」を選び（最悪ビスタ、 最も密な戦闘空間、最も賑やかな屋内）、毎回ちょうどそこで測れ。
ランダムな飛行はランダムな数字と反証不能な議論を生む。固定カメラは傾向線を生む：同じ眺めを週ごとに測ると、 リグレッションがいつどこに着地したか、誰に尋ねるべきかを正確に示す。最悪のビスタが主役に値するのは、それが すべてを一度に積むから。最大描画距離、すべてのLODリング、地形・水・空を同時に。ビスタで予算を保つマップは ほぼどこでも保つ；廊下はあなたにお世辞を言い、ビスタは真実を語る。
カメラ位置をマップに保存し、誰もが正確なショットを再現できるように。「ある角度で自分のマシンでは快調」はデータ ではない；「予算カメラ2が最低スペックで9.2 ms、先週の7.8から上昇」は容疑者付きのバグレポートだ。
作業が起きる場所に予算を見えるようにせよ
wikiの中の予算は死んでいる。それはセットドレッシング中のスタットオーバーレイ、コンテンツマージ前の 上限に対するチェック、そしてベイクがインスタンス数を突破しそうなときの警告として生きる。
アーティストはフィードバックが即時なら喜んで予算を守り、作業出荷の三か月後にバグチケットとして来ると憤慨する。 ツール側はここで静かだが決定的に重要だ：スキャッターとブレンディングがエンジンネイティブのプリミティブに ベイクするとき（Numivoがするように普通のインスタンスメッシュとfoliage）、あなたの既存の プロファイラがそれについて化粧なしの真実を語り、数字を濁すプラグインのランタイムはなく、あらゆる標準レバー （カル距離、LOD、インスタンス数）がそのまま適用される。ブラックボックス越しにしか測れない予算は、静かに信頼を やめる予算だ。
定着するレビューの周期
三つの予算カメラの週ごとのキャプチャ（五分）、コンテンツマージでの自動上限チェック、そして上限 自体の月ごとのレビュー。予算は見積もりであり、正直な改訂は沈黙の違反に勝つ。
- 週ごと： スタットをオンにして三つのカメラをスクリーンショット；フレーム時間とメモリを共有シートに記録。 傾向は一か月以内に現れ、スパイクは特定の週の作業を指す。
- マージ時： 自動チェックがシーンを上限と比較する。赤い数字は会話を開き、ビルドを壊さない。目標は意識で あって官僚主義ではなく、硬いブロックは人々にチェックを出し抜くことを教える。
- 月ごと： スライス自体を見直せ。プロジェクト中盤の現実は常にプリプロの推測と異なる；予算を公然と調整する ことが信頼性を保つ。皆が静かに無視する予算はないより悪い、チームに上限は芝居だと教えるから。
数字が赤くなったとき
コスト効率の順にレバーを引け。まずカル距離と影設定（数分、巨大な勝利）、次にLODとインポスター、 次にインスタンス数、そして最後にようやくアートそのもの。
最適化はトリアージであって解体ではない。アートは最後に崩せ。予算超過のビスタの大半は、プレイヤーが見られる 何かを削らねばならないずっと前に、見えない設定変更から緑に戻る。
高くつく間違いは、いきなり「木を半分削れ」に飛ぶことだ。密度は最も見えるレバーで、たいてい最も安くはない。 2 ms超過のビスタは、影距離とカル距離のチューニングだけで緑に戻るのが典型で、どちらもプレイヤーには不可視。 コンテンツ削除が最後の手段なのは、まさにプレイヤーが見られる唯一のレバーだから；梯子でそれより上の段はどれも アートの観点で無料だ。梯子を下れば、ミリ秒を取り戻しつつ見た目を保つ；下から上れば、無料の勝利を試す前に ゲームを醜くする。
盗む価値のある現場の数字
- 60 fpsのフレーム：16.6 ms。環境は典型的に6〜8 msを交渉する
- 実行可能な環境の下位分割：地形1.5 / 植生2〜2.5 / プロップ1.5 / 水と大気1（ms）
- マップごとの予算カメラ：3（ビスタ、戦闘、屋内）、マップに保存
- 週ごとの測定コスト：〜5分；価値：議論でなく傾向線
- 赤のときのレバー順：カリング → 影 → LOD → インスタンス → アート
ミニFAQ
環境予算は誰が所有する？ 名指しの一人（たいていテックアーティスト）、が測定を所有する；上限はレンダリングと 共同で所有する。所有者のない予算は一か月で民間伝承に朽ちる、「みんなが責任」は誰も測らない意味だから。
動的な時刻で予算はどう働く？ 各カメラで最も美しいでなく最悪の照明条件を測れ。長く斜めに走る影のある夜明けは しばしば正午の倍かかる；正午でしか保たない予算は半分の予算で、プレイヤーは高い時刻を見つける。
小さなインディー・プロジェクトにこの全部が要る？ 縮小せよ、廃止でなく。一つの予算カメラ、一つの上限（最低 スペックのマシンでのフレーム時間）、週ごとにチェック。五分の習慣こそ最後の月を救うもの。チーム規模によらず 失敗のモードは同一：コストを、直すのが高くつくときに発見すること。
メモリ対フレーム時間は？ それらは異なる失敗モードを持つ異なる予算だ。フレーム時間はFPSを落とし、メモリは ストリーミングをカクつきやクラッシュに落とす。両方を予算せよ；コンソールではメモリがしばしばより硬い上限で、 単に感じが悪いのでなく認証を落とすのはそちらだ。
予算は芸術性への制限ではない。美しいシーンが、プレイヤーが実際に持つハードウェアで60 fpsのまま美しく見える理由 だ。パフォーマンスを共有の設計制約として扱うチームは、それをラスボスとして扱うチームより美しいゲームを出荷する。