ecs-design

ECS の設計原則

Roblox における jecs の設計ガイダンスです。

基本的な考え方

ECS を列指向データベースとして考えてください。

データベース	ECS
テーブル	アーキタイプ（一意のコンポーネントの組み合わせ）
列	コンポーネント型
行	エンティティ
クエリ	システムの反復処理

設計上の問い：「これ専用のデータベース列を作るでしょうか？」

基本リファレンス

トピック	説明	リファレンス
データベースモデル	列指向データベースとしての ECS、正規化、断片化	core-database-model
クエリ設計	複数エンティティのクエリ、制約の分解、走査	core-query-design

ベストプラクティス

トピック	説明	リファレンス
コンポーネント設計	粒度の判断、分割・統合する場面、タグとデータの使い分け	best-practices-components
システム設計	単一責任、不要な処理の回避、順序付け、データフロー	best-practices-systems
エンティティ設計	エンティティを作成する場面、遅延作成、スケーリングのパターン	best-practices-entities

すばやく判断するためのガイド

質問	回答
これはエンティティにすべきですか？	時間とともに変化するインスタンスごとの状態が必要な場合に限ります
分割すべきですか、統合すべきですか？	「A は必要だが B は必要ないシステムがあるでしょうか？」
タグにすべきですか、データコンポーネントにすべきですか？	安定した分類にはタグ（追加・削除は自由）、状態にはデータを使います
リレーションシップとエンティティ参照のどちらにすべきですか？	逆引きが必要ならリレーションシップ、それ以外はエンティティメンバーを使います
断片化は悪いことですか？	数千のアーキタイプがあり、かつ広範囲にクエリする場合に限ります
DOD が重要になるのはいつですか？	数千のエンティティを毎フレーム処理し、CPU がボトルネックになる場合

よくある間違い

間違い	問題点	対策
モノリシックなコンポーネント	キャッシュの無駄、密結合	アクセスパターンごとに分割します
コンポーネントの過度な細分化	クエリの複雑化、不正な状態	意味上の単位で統合します
大きなエンティティへの頻繁な追加・削除	すべてのコンポーネントデータがコピーされます	代わりにデータコンポーネントを変更します
あらゆるリンクにリレーションシップを使う	利点がないまま断片化します	順方向のみならエンティティメンバーを使います
システム内にキャッシュ済みクエリを置く	毎フレーム新しいキャッシュが作成されます	モジュールのスコープでキャッシュ済みクエリを作成します

主要な原則

1. アクセスパターンごとにコンポーネントを構成する — システムが必要とするデータをまとめます
2. アーキタイプの遷移ではデータがコピーされる — コンポーネントを追加または削除すると、すべてのデータが新しいアーキタイプにコピーされます。小さなエンティティでは低コストですが、大きなエンティティでは高コストです
3. エンティティのメンバーとリレーションシップ — 前方検索にはエンティティのメンバーを、逆引きやグループ化にはリレーションシップを使用します
4. クエリはモジュールスコープでキャッシュする — システム内で .cached() を呼び出さないでください
5. クエリでフィルタリングする — コード内の条件分岐ではなく、with/without を使用します
6. フラグメンテーションが役立つ場合もあります — リレーションシップを使うと、グループ化されたクエリを効率的に実行できます