ゲーム設計続き

というか、
処理が終わるまで画面を更新する必要がない。
追加スレッドは一つでよい。
あたりまえですか？

で、柔軟なfps管理が必要なのね・・・

フェイズはスイッチをチェックして
関数を呼び出す関数である。
フェイズは一連のスイッチチェックのまとまりである。
フェイズの移行はポインタで行う。

あーうーなんか違うー

スイッチチェックが同じアニマの別動作を判断する場合、
チェックのグループ化が必要になる。
それはつまりクラス。
そうなると今度は、
フェイズ−＞アニマクラス−＞チェック
または、
フェイズ−＞アニマクラス−＞チェック用メンバ関数
となって階層が深くなりすぎる。うざい。

ああしかしこれは避けられないような気がする・・・

いっそのこと、クラス毎にフェイズ別の
チェック関数をつけてフェイズ関数とっぱらうとか。
論理的には綺麗だが把握しづれー
しかもフェイズによらず毎回、
各オブジェクトのチェック関数呼び出すはめに。
それはダメだ。
やっぱりチェックの絞り込みという点で、
フェイズによってチェック内容をすげ替えるのは必須。

ならばー

うむ。
結局は、
フェイズ−＞アニマクラス−＞チェック用メンバ関数−＞メンバ関数
か。
概念的には、

void FMap()
{
chara[0].check();
enemy[0].check();
background[0].check();
return;
}

みたいな。
配列オブジェクトの繰り返しはどうしよう。
てゆーかなんかいろいろ問題があるぞ。
フェイズ自体がメンバクラスを保持しないと
いろいろ面倒なことに・・・

そしてフェイズもクラス化か・・・
こうして絡めとられてゆくクラスの網・・・

そしてフェイズクラス内に、
アニマパラメータぶちまけたり。
モデリングの概念無視。
データの一蓮托生性でのみのクラス分け。
そしてその中には、
モデリングによって作られたクラスがごろごろ。
うぎゃー

戦う前から負けてます。

ま〜ちがってる〜そんなろんりは〜
ま〜ちがって〜る〜んだ〜
このせか〜いを〜

mokyu-