設計アプローチ

目的

このページでは、Reactive Entity Sets（RES）がGPU InstancerやECSなどの他のエンティティ管理ソリューションとどのように異なるかを説明します。これらの違いを理解することで、プロジェクトに適したツールを選択できるようになります。

異なる目標のための異なるツール

RES、GPU Instancer、ECSはすべて有効なソリューションですが、最適化する対象が異なります。

観点 GPU Instancer / ECS Reactive Entity Sets
主な目標 最大パフォーマンス 観測可能性とデバッグのしやすさ
最適化対象 毎フレーム処理 変更通知
複雑さ 高 低
ワークフロー変更 大きい 最小限

どちらが「優れている」かという話ではありません。それぞれのアプローチは異なるプロジェクトニーズに対応しています。

各アプローチを検討するタイミング

GPU Instancer

類似したオブジェクトを最小限のオーバーヘッドで数千個レンダリングするのに最適です。

  • 草、木、岩、パーティクル
  • 個別の状態追跡が不要なオブジェクト
  • パフォーマンスが重要な視覚要素

ECS（Entity Component System）

大量のエンティティで最大スループットが必要なプロジェクトに最適です。

  • 毎フレーム処理される数千のエンティティ
  • 新しいパラダイムを学ぶ意欲のあるチーム
  • 1ミリ秒単位が重要なプロジェクト

Reactive Entity Sets

開発速度とデバッグのしやすさを優先するプロジェクトに最適です。

  • 中程度のエンティティ数（数百から数千程度）
  • GameObjectワークフローを維持したいチーム
  • 観測可能な状態変更が重要なプロジェクト
  • 高速なイテレーションとデバッグが優先事項

RESが優先すること

RESは開発者体験を最適化するために意図的なトレードオフを行っています。

観測可能性

すべての状態変更がイベントです。何が、いつ、なぜ変更されたかを常に確認できます。

// すべての変更が観測可能なイベントをトリガー
entitySet.UpdateData(enemyId, state => {
    state.Health -= damage;
    return state;
});
// → OnDataChangedが発火
// → エンティティごとのサブスクライバーに通知
// → Inspectorで変更を確認可能

デバッグのしやすさ

RESはUnityのエディタと深く統合しており、以下のモニタリング機能を備えています。

  • Play Mode中にTable Viewですべてのエンティティ状態を確認
  • どのエンティティが登録されているか追跡
  • リアルタイムでイベントフローを監視
  • ブラックボックス的な動作がない

予測可能性

データの変更は確実に反映され、通知されます。

  • サイレントな変更がない
  • 見逃されるアップデートがない
  • 明確な因果関係

アーキテクチャの強制

RESは自然にデータとロジックの明確な分離につながります。

State（struct）     : データのみ
計算ロジック        : 純粋関数
RES                 : ストレージと通知
GameObject          : 可視化

ワークフローの利点

RESの主な利点の一つは、使い慣れたGameObjectワークフローを維持できることです。

ECSワークフロー 

従来のMonoBehaviour → Entity/Component/Systemに変換
                     → 新しいメンタルモデル
                     → 異なるデバッグツール
                     → 大きな学習曲線

RESワークフロー 

従来のMonoBehaviour → RES統合を追加
                     → 同じメンタルモデル
                     → 同じInspectorデバッグ
                     → 段階的な導入が可能

RESは段階的に導入できます。まず1つのシステムで試し、うまくいけば拡大します。

パフォーマンス特性

RESは内部的にSparse Setデータ構造を使用しています。

操作 時間計算量
Register O(1)
Unregister O(1)
GetData O(1)
SetData O(1)
イテレーション O(n)

RESは、エンティティ数に対して変更頻度が低い場合に効率的です。

RESが優れている場合

  • フレームあたりのエンティティ変更が10%未満
  • エンティティ数が中程度（数百から数千程度）
  • 複数のシステムが同じ状態変更に反応する

代替案を検討する場合

  • すべてのエンティティが毎フレーム更新される
  • エンティティ数が数万に達する
  • 生のパフォーマンスが最優先事項

まとめ

アプローチ 最適化対象 適している場合
GPU Instancer レンダリングパフォーマンス 類似した視覚オブジェクトが多数
ECS 処理スループット 大量のエンティティ、毎フレーム更新
RES 開発者体験 観測可能な状態、デバッグのしやすさ、段階的導入

RESはGPU InstancerやECSを置き換えようとしているわけではありません。開発速度、デバッグのしやすさ、保守性がフレームレートの最後の一滴を絞り出すことよりも重要なプロジェクトに向けて、異なるニッチを埋めています。

次のステップ

This site uses Just the Docs, a documentation theme for Jekyll.