GameComponent
名前の通りゲームの部品。
Initialize と Update を持ってて、Game.Components に登録しとくと、明示的にUpdateとか呼ばなくても読んでよしなに処理してくれるそうな。
しかし、この時点でカプセル性持たせて考えると、用途が思い浮かばない。
DrawableGameComponent
作画機能を持ったGameComponent。
Drawで作画できるので、ゲームシーンをこれで分解・階層化したり、当たり判定とか他のオブジェクト間の相互作用がない画面部品に使えそう。(ADVなんかはそうね)
一応、フレーム数カウントとか、総ポリ数表示とか、ユーティリティ的には使いやすそう。
Service
Game.Services から登録削除可能。
システムで共有する情報とか、処理とか格納するコンテナ。と聞くと、なんかコンテクストクラスじゃね？とか思う(まぁコンテクストって言うとリソースも含むんだが)。
これで独立してて使い道なかった GameComponent を連携、、、、とか思った時期がありました。
翌々調べると、GameComponent の実行順序って指定できないのよね。基本は登録順。
なので、画面がカオスってる状態で、フラグ的な値を設定しても、そのフレームで相手のComponentに伝わるかは不明。最悪次のフレームで伝わると。
1/60 なんて誤差だろ！と言われればそれまで。でもアクションゲーとか、リアルタイム第一のゲームでそれは無い。
使えても当たり判定とか無い、画面上のオブジェクトが干渉し合わないシステム、、、、すると、ボードゲーとか、ADV、パズルなんかはこれでも十分実用に耐えそうな気はするよね。
追記
実行順序制御できた。
なんか UpdateOrder とか言うのがいて、値が小さい方から順に実行されとるｗ
＠作画に関しても、DrawOrder とかいうプロパティで順序制御できる。
とはいえ、カオスになってくるとここの値の管理も死ねそうな悪寒。
一応 Components 経由で自己も含めてGameComponentは削除できるっぽいし、シーンごとに管理GameComponent-MainGameComponent-SubComponent みたいに階層化したGameComponent 一括登録とかそういう構造化で逃れられるかな？
