Unity ECSのCohesionを計測・目視・判断に分けて評価する

実験カード

この実験で重要なのは、採用判断を一つの数値だけで説明しないことです。CPU Mainの差は体数によって方向が一致せず、各Runの範囲も重なりました。一方、固定条件の目視では局所的なまとまりがわずかに強く見えました。そこで、性能が改善したからではなく、狙った見た目を加えつつ既存の挙動を損なう問題が見つからなかったため、限定された初期値を採用しました。

結論

• 1,000体ではCohesion有効時のCPU Main平均差が+0.026 ms、5,000体では-0.086 msでした。
• 差の方向は一致せず、各条件3回のRun範囲も重なったため、負荷の増減は断定できません。
• Unityの予約メモリ平均は、どちらの体数でもCohesionの無効・有効で差がありませんでした。
• 固定seedの1,000体を同じ目標へ移動させた目視比較では、有効時の局所的なまとまりがわずかに強く見えました。
• 到着後約6秒まで、Cohesion有効時だけに現れる過密化、塊の膨張・収縮、中心を往復する振動は確認できませんでした。
• 加速度1.0は今回の最小Boids-liteに限る初期値です。一般的な推奨値でも、性能差を根拠にした値でもありません。

計測・観察・判断を分ける

実験結果を記事にするときは、次の三つを混ぜないようにします。

「見た目が良くなった」「平均値が変わった」「初期値に採用した」は、それぞれ別の主張です。平均値の小差を性能改善へ、短時間の目視を安定性の証明へ、個別プロジェクトの初期値を一般推奨へ読み替えないことが、このカードの中心です。

A/B計測の条件

同じWindows Standalone x64 Development Buildで、Cohesionだけを切り替えました。

計測前にはbatchmodeコンパイル、106件のEditModeテスト、Windows Development Build、可視Playerの全Runが正常終了することを確認しました。計測値はPlayer全体のフレーム指標であり、Cohesion処理だけをProfiler Markerで分離した値ではありません。

計測結果

次の値は各条件3回の平均です。

1,000体では有効時の平均が増え、5,000体では減っています。さらに、記録したRun間の範囲はどちらも重なりました。Cohesionの追加コストより、実行ごとの変動が同程度以上に現れている可能性があるため、現在の計測から「Cohesionで速くなった」「Cohesionで遅くなった」とは判断しません。

GPU FrameTimingには複数Runで非現実的な外れ値が出たため、結論には使いませんでした。取得できた指標をすべて採用するのではなく、信頼できない指標を除外したことも結果の一部です。

目視観察

目視比較では、固定seed 20260816から生成した1,000体を同じ画面座標の目標へ移動させました。Entity数を維持し、SeparationとAlignmentは有効、Cohesion加速度は1.0としています。目標指定から約0.5秒後の移動中と、到着後約6秒の状態を比較しました。

観察できたのは次の範囲です。

• Cohesion有効時は、無効時より局所的なまとまりがわずかに強く見えました。
• 到着後は両条件とも単一目標へ密集しました。
• 約6秒まで、有効時だけの過密化、塊の膨張・収縮、中心を往復する振動は確認できませんでした。
• 目標到着、Separationによる最小回避、既存の敵挙動を損なう表示上の問題は確認できませんでした。

これは目視所感です。局所密度、群れ形状、最近傍距離を数値化した評価ではありません。また、公開可能な同時比較の画像や動画が残っていないため、読者が見た目を追試できる証拠としては扱いません。「確認できなかった」は、記載した短時間と条件で問題を発見しなかったという意味に限ります。

採用判断

今回の最小Boids-liteでは、Cohesion加速度1.0を初期値として採用しました。Alignmentの2.0、Separationの6.0より弱くし、移動目標を主方向として保ちながら、味方を局所中心へわずかに寄せる位置づけです。

採用理由は、固定条件の目視で狙った変化があり、既存挙動を壊す表示上の問題が見つからなかったことです。CPU Mainの平均差は採用理由にしていません。異なる密度、近傍数、ゲームルール、描画負荷へ1.0をそのまま適用できるとは限りません。

小差を次の判断へつなげる

今回のように差の方向が揃わず、Run範囲も重なる場合は、平均値だけから機能の採否や最適化を決めない方が安全です。次の検証では、目的に応じて次を追加します。

• Run数を増やし、実行順を交互化またはランダム化する。
• 平均だけでなくpercentileや短時間のProfiler captureを確認する。
• Cohesion処理専用のProfiler Markerで、Player全体の変動から分離する。
• 両条件で同じ局所密度、最近傍距離、重なり数、到着時間を記録する。
• 公開可能な同一時刻の画像または動画を残し、目視所感を再確認できるようにする。

必要なのは、小差を無理に結論へ変えることではありません。計測では「まだ負荷差を断定できない」、観察では「限定条件で見た目が少し変わった」、判断では「現在の試作に初期値を置いた」と、確度の違う結果をそのまま残すことです。

注意点

• この結果は一つのWindows Development Player、記載したEntity数、各条件3回に限られます。
• CPU MainはPlayer全体の平均であり、Cohesion単体の実行時間ではありません。
• 予約メモリに差がないことは、一時Allocatorやフレーム内の割り当てまで同一であることを意味しません。
• 目視比較は定量評価ではなく、公開可能な画像・動画もありません。
• 約6秒問題が見えなかったことから、長時間安定性や別の目標配置を一般化できません。
• 加速度1.0は今回の構成上の判断であり、Unity ECSやBoids全般の推奨値ではありません。

関連資料

• Unity 6のWindows PlayerでECS 1,000〜5,000体を再現可能に計測する
• Unity ECSでSpatial indexを再利用した同陣営分離をA/B計測する
• Unityでアプリケーションをプロファイリングする