参考資料
Inheritance based
- 継承関係 := 有向非循環グラフだが、ゲーム要素は必ずしも有向非循環グラフで表せるわけではない
- 継承はfriendの次に依存関係が大きく、変更しづらい
Component based
- EntityはComponentのコンテナ
- Componentはデータ(Attribute)とロジック(Behavior)に分離
- Attribute := キーバリューペア
- Behavior := onUpdate()とonMessage()関数を持つ型
- Entityの生成はData-Drivenにできる
Component間の依存関係への対処
- 依存するのがデータの場合は、そのデータをAttributeとしてBehaviorから分離することで除去
- 依存するのが振る舞いの場合は、その振る舞いに対応するメッセージを送信することで除去
- メッセージは同期呼び出しで即時実行される
- Attributeの変更通知システムは必要 := Attributeを直接変更するインターフェースにはしない
- BehaviorのonUpdate(), onMessage()の呼び出し順序は？
Postmortem
- このアーキテクチャへの対応、デバッグ、パフォーマンスにやや難有りだが、トータルではメリット大
- データ駆動生成は良い
- Behaviorの独立性が高いのは良い
- データの継承は良い（なんのこと？）
パフォーマンス
- onUpdate()とonMessage()はボトルネックとなりやすい
- 不要なonUpdate(), onMessage()の呼び出しを削減する
- 呼び出しをタイムスライスに分割する
- Attributeをキャッシュする
- 最後の最後にはハックを許容する
今後の改善
- Stateless behavior (Functional Reactive Programmingがこれに相当するか？)
- 並列化のためStateless behaviorのonUpdate()をバッチ実行する
- メッセージをキューに入れる
Attributeの実装
- キーの型は何にすべきか？文字列型？列挙型？クラス型？
- Attribute間の依存関係はどう解決すべきか？
- Attributeの変更通知の実装は？
別のアプローチ
- Componentは状態のみを持ち、振る舞いは持たない
- 振る舞いはSystemが持つ。逆にSystemはComponentごとの状態を持たない
- このアプローチだと、Component間の依存関係はSystemに移動するだけで除去できない
最終更新：2012年04月07日 23:47
