[]

試しに書いてたプログラムが見づらくなってきたので設計からやり直し。主にメインループ内での実行、描写の管理について。要はゲームタスク処理。

必要な機能としては、

• 実行順の制御
• 描写順の制御

いろいろ書いてみたけどまとまらないのでこの部分はまた後で。

今考えてること：

仮にゲームオブジェクト内のインターフェース関数を
実行：update()　描写：draw()、それぞれの管理クラスをUpdateManager,DrawManagerとしておく。

• update()=ゲームオブジェクト内の内部状態の変化
• draw()=内部状態の情報から描写処理(内部状態は変化しない)

って考えるとupdate()内でDrawManagerに描写登録、DrawManagerは描写処理を出された物に対して適切な順序でdraw()するって形にした方がよさそう。実行処理と描写処理は何か対等の関係じゃない気がする。
利点としてはupdate()の時点では他の処理が終わってないので自分だけでは決められない、例えば描写順やカリング等に対してDrawManager側に全て処理を任せられること。適当なバウンディングボックスでも渡してやれば簡易シーングラフっぽい処理もできる？

コリジョン処理。衝突判定が必要なのは、ICollisionDetectableって感じのを継承してCollisionManagerに自分を登録、必要な時に処理を問い合わせる形になるはず。上記の描写に使うシーングラフっぽいものを利用できるかも。衝突判定が必要な物はそれほど多くない予定だけど。

Sceneクラス。上記UpdateManager,DrawManagerとか保持してる所。ここが中心になるはず。他にも機能がいろいろ。これ他のScene内に入れ子構造で実行できる必要もある？

SceneManagaerクラス。シーンが遷移するときなんかに、裏で事前に構築しといて、すぐに移行できるようにするための物。

後、Map、ハンドル保持、データ、オブジェクト間通信関係をどこに置くか考え中。Sceneクラスがでかくなりすぎる気がするのでその辺をうまく分けときたい。

追記：
やっぱupdate()側が描写要求を出すことによって描写を制御してるって考えるとManagerクラスが同列にあるってのはおかしいかも。あとSceneクラスごとに画面があるって感じになってる所。Sceneを入れ子構造にしたい場合、問題になる可能性が。Rendererクラス見たいなのをSceneより上の階層に置いといて、そこに描写要求出す形の方がいいかも。