>>552
シンプルな相互作用と、シンプルなインスタンスなら簡単に書けて良いけど、
ちょっと規模が大きくなると辛そうな気はするな。

たとえば FPS だと、ヒット判定は総当りではなく BSP なり何なりで空間分割しないと
キツいが、こうなると TASK2() 使えない。もちろん"タスク”の枠組みでも書けなくは
ないが、ベタ書きより複雑になったら意味ないので。

メンバ変数全部 public も辛いかなぁ。アクセス保護の観点では、Star と Windows の
相互作用では m_x, m_y, m_w を readonly でアクセスしたいが、TASK1(Star) では
メンバ変数全部 read/writeしたい。

あとメンバ変数直接アクセスする仕組みだと、分割コンパイルにも支障が出るかなぁ。
処理が全部 Loop() に集中するから、こいつは Star や Window など全クラスの
定義を知っている必要がある。


また、Star などが単純で状態をほとんどもたないなら良いんだが、状態が複雑になると
外から直接メンバ変数を書き換えるのは危ない。たいていの場合、ヒット判定して、ヒット
してたら双方にメッセージを送っておくだけで、すぐには処理しない。で、後で自分の
Update() 処理の中でメッセージを受け取ってきて、自分の状態とメッセージを照合して
状態遷移する。

この辺の仕組みを入れようとすると、逆に複雑になりそうな気がする。


最後に欠点じゃないけど、タスクの派生クラスをどう扱うかは悩みどころだ。たとえば
Star を継承した Blackhole があったとして、こいつは TASK2(Star,Star) で参照される
べきか無視されるべきかの指定はあったほうが良いと思う。