- タスクシステム
110 ：名前は開発中のものです。[sage]：2011/09/07(水) 01:06:48.32 ID:njRzaK7Q - >>108
なんでゲームやSTGに限ろうとするの？
ほとんどのアプリが、型ごとにリスト持ってて、必要に応じて更新ってスタイルだよ？
|
- タスクシステム
115 ：名前は開発中のものです。[sage]：2011/09/07(水) 01:35:34.18 ID:njRzaK7Q - これはもう石頭でどうしようもない。物事を勘違いしたまま突き進んじゃってる。
>いずれにせよ個体の種類と量が増えると、人間の頭ではワケワカメになると思うんだが。
ワケワカにならないように、違った型のオブジェクトを同じリストに突っ込まないようにするわけで。
ワケワカでOKってことはないでしょ？
>敵クラスについて、前処理、AI、後処理と分けていて、非常に複雑な印象を受ける。
>このように分ける必然性がわからない。
敵クラスの前処理とAI処理の間に、他クラスの別処理が入ってるのが味噌。
一回ずつオブジェクトをupdateでなめなめして、それで全ての処理が終わるとは限らないだろ？
>タスク登録時に優先順位（Priority）
それは、違った型のオブジェクトを同一のリストに入れるから必要になる仕組みであって、
苦肉の策であることを分かって言ってるのか？
そしてそんな貧弱な制御構造で、言語本来の制御構造と対等に立てるとでも？
|
- タスクシステム
116 ：名前は開発中のものです。[sage]：2011/09/07(水) 01:46:07.51 ID:njRzaK7Q - >１）呼ぶ側の構造をできるだけシンプルにする。
物事は上流で解決した方が良い。
>２）個体の状態の両端末、すわなち生存・消滅に関わるメカニズムを統一して単純化にする。
言ってる意味が良く分からんが、あえてエスパーすると、メモリアロケートの話ならアロケーターの仕事。
>３）個体同士の相互作用のメカニズムを統一して単純化する。
上流(メインループ部)を直接改造できる状況下においては、
相互作用は上流でするべき。
>>114
逆にタスクシステムを使うべきケースって何？
ああいったコールバックシステムは、
上流部が固定されている場合だけだと思うんだけど。
ゲームはメインループ部を自由に触れるよね？
リリース前なんだから。
|
- タスクシステム
118 ：名前は開発中のものです。[sage]：2011/09/07(水) 02:02:46.60 ID:njRzaK7Q - >>117
>>116のような記述がズラーーーーーーと並んだら、ワケワカメになるとは思わないか？
そこにズラーーーと書いてあることが、格ゲームオブジェクトのupdate関数に移るだけだから同じこと。
むしろ、分散されて余計わけが分からなくなる。
>率直に言うと、複雑な相互作用メカニズムになっているという気がするな。
あえて例で上げたまでだからね。
だけど、一回のupdateで全ての更新が終了するとは限らないだろ？
>例で示されている要件は、タスクシステムでもクリアされているんじゃないか。
二回のupdateが必要な場合はどうするの？
a->update1(); → 何かの処理 → a->update2();
C言語本来の制御構造なら、やりたいことをやりたい順で書けば済む。
タスクシステムだと、タスクシステムの仕様に制限される。
|
- タスクシステム
125 ：名前は開発中のものです。[sage]：2011/09/07(水) 12:39:30.24 ID:njRzaK7Q - 今の時代なら、
>１．ゲームオブジェクトを統一的に扱う。
はテンプレートでしょ。
|
- タスクシステム
127 ：名前は開発中のものです。[sage]：2011/09/07(水) 20:57:18.96 ID:njRzaK7Q - 違った種類のジョブを単一リストで管理する理由はないね。
上流の呼び出し部分が出来合いのもので、
改変が許されないのなら別だが。
|