描画以外のコスト / The whole frame, not just rendering
ゲーム全体のフレーム構成
ここまでの Primer は主に絵を作る側（Draw / GPU）の話でした。でも1フレームには、絵を出すより前にやることが山ほどあります ── Tick・物理・アニメーション・AI・当たり判定・ネットワーク・オーディオ、そして時々やってくるガベージコレクション。これらは全部Game スレッド（CPU）の仕事で、GPUがどれだけ速くてもここが詰まればフレームは落ちます。この章は「描画以外がフレームをどう食うか」を組み立てて確かめます。
Game Thread
Tick / Physics
GC hitch
1% Low
まず用語だけ — 読む前の30秒
Game スレッド game thread
絵を出す前に「何が起きるか」を計算するCPUの担当。描画以外はほぼ全部ここ。
Tick tick
毎フレーム各アクターを更新する処理。数が多いほど積み上がる代表格。
ガベージコレクション GC
不要になったオブジェクトを回収する処理。時々走り、その瞬間だけ重い。
ヒッチ / スパイク hitch / spike
平均は出ているのに一瞬だけ極端に遅れる、あのカクつき。
1% Low 1% low
遅い方から1%のフレームのfps。体感の滑らかさは平均よりこちらで決まる。
レプリケーション replication
マルチプレイで状態を同期する処理。人数・更新頻度でGameスレッドを食う。
※ 各語の詳しい定義は、ページ末尾の用語集にもあります。
§1 — Not just rendering
フレームは「絵」だけでできていない
Primer 08 で stat unit の Game / Draw / GPU を見ました。このうち Draw と GPU は「絵を出す」担当。残りの Game は「絵を出す前に、この世界で何が起きるか」を全部計算する担当です。そしてこの Game スレッドの中身は、実はとても混み合っています。
Actor Tick
全アクターの毎フレーム更新
キャラ・敵・拾える物…配置した物すべてが毎フレーム自分を更新する。数がそのまま重さ。
Physics
物理シミュレーション
剛体・衝突・ラグドール。ボディ数と当たり判定の数で伸びる。サブステップで更に重く。
Animation / AI
骨の計算・思考
スケルタルメッシュのポーズ評価、ビヘイビアツリー、パス探索。キャラ数に比例。
GC / Streaming
時々くる重い処理
ガベージコレクションやレベルストリーミング。毎フレームではないが、走る瞬間だけ跳ねる。
よくある誤解
「重い＝グラフィックスが豪華すぎる」とは限りません。絵は軽いのに Game スレッドが律速という状況は普通に起こります。その場合、テクスチャを落としても影を切ってもfpsは1msも上がりません ── 直すべきは Tick やロジックの側です。§2 で、描画以外だけでフレームがどう埋まるかを組み立ててみます。
§2 — Building the game thread
Game スレッドを積み上げる
シーンに置く物の量を動かすと、Game スレッドの各処理がどれだけ時間を食うか（下の積み上げ帯）と、それが描画側（Draw+GPU=固定8ms）と比べてどちらが律速かが分かります。描画は一切変えていないのに、置く物を増やすだけでフレームが予算(16.7ms)を超えていくのを見てください。
1フレームの内訳（横軸 = 0〜28ms）
Game スレッド— ms
描画（Draw + GPU・固定）— ms
0↑ 16.7ms = 60fps 予算28ms
ここでの Frame は「Game と 描画の長い方」＝ Primer 08 と同じ並行パイプラインの考え方です。Game スレッドが 8ms を超えた瞬間から、fps を決めるのは描画ではなく Game 側に移ります。
§3 — Spikes & the 1% low
平均60fpsなのにカクつく理由
Game スレッドのコストには2種類あります ── 毎フレーム一定の「地の重さ」と、時々どかっと来る重さ。後者の代表がガベージコレクション(GC)やアセットのロード。平均fpsは涼しい顔でも、その一瞬だけフレームが跳ねてヒッチ（カクつき）になる。体感の滑らかさは平均ではなく1% Lowで決まります。下のグラフで、スパイクの間隔と大きさを動かしてみてください。
「平均は高いのに 1% Low が低い」＝ヒッチ持ち。スパイクを小さく（GC対象を減らす・オブジェクトを使い回す）するか、インクリメンタルGCで1回の負荷を複数フレームに散らすと、1% Low が持ち上がって体感が滑らかになります。
§4 — In UE
UEでの計測と、Gameスレッドの定石
Primer 08 の stat unit で Game が律速と分かったら、次はその中身を掘ります。Game スレッドの定石は「毎フレームやることを減らす」に尽きます。
stat game / stat gc
中身を見る
stat game で Tick・物理などの内訳、stat gc でGCの頻度と時間を確認。Insights の Game Thread トラックはさらに詳細。
Tick を減らす
そもそも動かさない
要らないアクターは Tick を切る、頻度を落とす（Tick Interval）、イベント駆動に変える。数千の毎フレーム更新が一番の敵。
Significance / LOD
遠い物は手を抜く
Significance Manager で遠い/重要でない物の更新頻度を落とす。アニメも距離でLOD（骨計算を間引く）。描画の
LOD (06) と同じ発想をロジック側にも。
GC / メモリ対策
スパイクを散らす
オブジェクトを頻繁に生成/破棄せず使い回す（プーリング）、GC対象を減らす、インクリメンタルGCで1回の負荷を分割。§3 の 1% Low がここで効く。
これで一周 ── Primer 01〜08 が「絵を出す仕組みと、遅いときの直し方」なら、この 09 は「絵を出す前にCPUがやっている全部」。Primer 08 の stat unit で Game が律速と出たとき、次に開くべきはこのページです。