タスクシステム総合スレ part3

**名前は開発中のものです。** · 2008/11/09(日) 11:51:40

タスクシステムについての議論、相談、質問、雑談などのスレです

part2 http://pc11.2ch.net/test/read.cgi/gamedev/1196711513/
part1 http://pc11.2ch.net/test/read.cgi/gamedev/1173708588/

**名前は開発中のものです。** · 2009/01/13(火) 00:49:41

>>534
何が言いたいのか分からない。
管理クラスはupdate関数を呼ぶだけだし、呼ばれたほうは自分自身が何者かを知ってる。

**名前は開発中のものです。** · 2009/01/13(火) 00:50:45

何もないわけないだろう。ないならこんなに大騒ぎするはずないじゃん

**名前は開発中のものです。** · 2009/01/13(火) 00:53:10

かつての制限ありまくりのハードではっての前提ならなんかいいことあるんじゃないの？

**名前は開発中のものです。** · 2009/01/13(火) 01:01:17

>>534
は？
ごった煮リストから判別して特有の処理を呼び出す話をしてるんだよ
なんで共通のupdateの話をするの？

**名前は開発中のものです。** · 2009/01/13(火) 01:05:48

>>537ｰ538
あると思うならそれをいうべきだろ
ただ、あるんじゃないの？って認識の人が書き込む場面ではないだろ

**名前は開発中のものです。** · 2009/01/13(火) 01:13:01

>>539
必要な分はリストに入れる前にあらかじめメンバ変数として持っておくんだよ。
わざわざリストから取り出す必要はないし、型を改めて判別する必要もない。
リストから取り出すならdynamic_castだとも書いてある。
同じこと書かせないでくれ。分からない部分があるならそこをピンポイントで聞いてくれよ。

**名前は開発中のものです。** · 2009/01/13(火) 01:35:34

>>540
いやおれは>>497と同意見なだけだが

何をするためのものか整理してから話したら？ってこと

**名前は開発中のものです。** · 2009/01/13(火) 01:44:29

>>530
タスク厨を定義するにはタスクシステムを定義しなければならないのだが
>2にしても書籍にしてもゆらぎが大きく、絶対的な権威も不在、
且つ個々の理解もばらばらでコンセンサスがとれないのが現状。
>520は松浦大先生を権威として祭上げたいみたいだけど
その話題に触れているのは今のところ>521だけ。

**名前は開発中のものです。** · 2009/01/13(火) 02:33:11

>>530
いるいる。たーくさんいる。ここ5～6年内はゲー専新卒の子だけじゃなくて
四大工学系新卒の子が説明会や集団面接で>>2を熱く語ったりする。臆面もなく。
他の子が目を白黒させてる。

沢山　：　oO（え、ナニそれ？何？それ知ってないとヤヴァイ？あとでググろっと）
少数　：　oO（プギャー）

など、様々な表情が観察できて面白い

まぁ最終段階で残る子はこんなもんこれっぽっちも知らなかったりするし
知ってても「だからナニ？」みたいな子ばっかだから
新人研修の段階で更生させる手間はゼロだしどうでもいいんだけどね

>>543
松浦御大の功績は認めるべきだよ。Cマガにおける特集記事とその後の連載記事
そして禿パブから出版された数々の書籍、これらによってタスクシステムという
呼称をその実装と共に伝道し、素人プログラマの間で爆発的に普及させた

それ以前にタスクシステムなんて単語を駆使する学生や子供は稀有だった。
X68界隈の草の根BBSみたいな閉じた狭いコミュニティでヲタ同士でコソコソ
やってただけ

松浦御大の教えに染まった子が増えたことで2DSTGを作る子も増えた。まぁ全てが悪いわけじゃない

**名前は開発中のものです。** · 2009/01/13(火) 03:10:52

>>544の前半
ニュースの映像でさえ本物かどうか疑わないといけない時代に
唐突にそんな逸話だけ出されてもねえ。
前にオカルトとかエセ科学とか言ってる人がいたからじゃないけど
検証可能性を担保できる話をしようよ。

**名前は開発中のものです。** · 2009/01/13(火) 07:57:07

>>541
わかんねぇ奴だな
たとえばクラスＡとＢがあったときクラスＢだけがもつmoveBメソッドを呼びたかったと
したらまずごった煮リストの取り出した要素がクラスＡかＢか判断する必要があんだろが
じゃねーとＢにしかないメソッドなんだから呼べないだろ

**名前は開発中のものです。** · 2009/01/13(火) 08:35:28

>>546
dynamic_cast の意味しらべるのオススメ

まあ、ゲーム開発だと RTTI はたいてい切ってるんだけどね

**名前は開発中のものです。** · 2009/01/13(火) 08:37:32

ちょっと訂正。

ゲーム開発 → コンソールでのゲーム開発

360, PS3 世代ならもういいかも。

**名前は開発中のものです。** · 2009/01/13(火) 09:47:27

タスクシステムなコードを昔見たとき

char data[256];

DataA *p = (Data A *)data;

こんな感じで領域確保してキャストして利用してたのは
C++から入った自分としてはへーと思ったな

**名前は開発中のものです。** · 2009/01/13(火) 10:08:51

頭悪い子のほうの撲殺天使の人暇だったんだな

**名前は開発中のものです。** · 2009/01/13(火) 10:43:44

>>539
＞ごった煮リストから判別して特有の処理を呼び出す話をしてるんだよ
＞なんで共通のupdateの話をするの？

>>546
＞したらまずごった煮リストの取り出した要素がクラスＡかＢか
＞判断する必要があんだろが
＞じゃねーとＢにしかないメソッドなんだから呼べないだろ

リストの個々のオブジェクトはupdateメソッドを保有している
で、そのupdateメソッドは自分が何者か知っているわけで
わざわざ型の判別をする必要はないだろ

**名前は開発中のものです。** · 2009/01/13(火) 10:58:08

オブジェクト間の相互作用の話をしているんだと思うよ

相手が自明ならキャストは普通は要らない
敵の中で～なもの、といった風に条件付でスキャンしたいのなら
型の判別とキャストがいるだろう

代数データ型が使える言語ならもっと型安全にヴァリアントな型を
扱えるが、C++なら結局はキャストするしかない

で、「ごった煮リスト」とは言うが、実際には例えばTaskだのGameObjectだの
というインタフェースを継承したクラス群になるわけだろうから
型を判別する方法なんぞいくらでもある

言語組み込み機能なら、何度も言われているようにdynamic_cast
そうでなければ、例えば自分が誰かを示すメソッド等を、統一したインタフェース
として持たせればいいだけだ
なんも難しい話じゃないはずだが

**名前は開発中のものです。** · 2009/01/13(火) 11:11:47

>>546
こっちの話はすぐわかるからいける。多分>>551はリストのノード自体が多態性してる。
ゲームオブジェクトをupdateのみを持つ別のクラスで包むか、
ゲームオブジェクト自体がupdateをもち、オーバーライドしてupdate内で自分のメンバを呼んでいるんだろう。

ところで、タスクですべきことがゲームオブジェクトのupdate、positionの取得、など個々の場合
>>491みたいなEventTaskでやるべきことを判別する必要がある・・・で合ってる?

**名前は開発中のものです。** · 2009/01/13(火) 11:38:16

オブジェクトのグループ／階層がはっきりしているのなら
少なくともリストよりはツリーがいいように思う

全体も走査できるし
特定のグループに限定したいのなら、サブツリーを走査すればいい
フラットなリストでmap/filterを毎度やるよりは効率的だろう

多態とダウンキャストは、C++でOOやるなら宿命みたいなもんだから、
そこを突っ込んでみても仕方がない

**名前は開発中のものです。** · 2009/01/13(火) 12:52:30

型の判別が必要ってのはいいかい？
全く同じメソッドもってたって型を判別する必要あるな
自機、敵、自弾、敵弾の内、敵と敵弾だけに絞りたい場合なんかも型を判別する必要あるよな
こんときやらなきゃいけないのは一斉検索だろ？
んで処理をするもんとしないもんといちいち判別しながら処理しないといけないわけよ
何が言いたいかってーと
ごった煮である利点は少ないよねってことよ

ツリーも惜しいけどそれでもやはり意味がない

続く

**名前は開発中のものです。** · 2009/01/13(火) 13:00:10

>>555
「どうやって型を判別するんだよ」とか言ってるから
型なんか簡単に判別できるだろ、とだけ言っただけで
別にタスクシステムとやらを褒め称えてるわけじゃないんだけどね

ツリーも、少なくともフラットなリストよりはマシだろうってだけね

**名前は開発中のものです。** · 2009/01/13(火) 13:09:33

＞ごった煮である利点は少ないよねってことよ
それはゲームによるでしょ
過去に作った横スクロールアクション、ＲＰＧでごった煮採用だが、全然困らん
逆にオブジェクトごとにリスト用意するのはメンドイ
ま、弾幕シューティングしか作らないような御仁は分けた方がいいのかもしれないな

**名前は開発中のものです。** · 2009/01/13(火) 13:17:38

なんとなくすれちがいポイントがみえてきた

・入り口のメソッドだけあわせておけばあとはオブジェクトが自発的に処理すりゃいいだろ派

・オブジェクトの相互作用はまとめてかいたほうがいいだろJK。
　そうすると個別のオブジェクトの区別が必要だから1つに束ねると効率悪いだろ。

こんなかんじ？
まあ、両者ごもっとも。

俺なら今ならふつうに富豪的アプローチだな。
一連の処理を行う構造と、検索・相互作用用の構造は別の形でもったほうがいい。

・大枠は前者的思想でつくってメインループを回す。
　イベント処理＞状態変更＞画面更新
　とかそういう単位

・親に、自分以外のオブジェクトの検索をしやすいような辞書的構造を
　別途整備する。オブジェクトはこれを参照して自分の動作を決める

・複雑な処理は親の専用のロジックで辞書を直接総なめするような操作を
　作って、これ自体を処理オブジェクトとして一連の処理に投入するようにする

こんなかんじ？

**名前は開発中のものです。** · 2009/01/13(火) 13:28:07

>>546
なんで答えてることを無視して同じ質問するの？
C++を知らないのかな？　もう一回だけ説明するよ。
これでわからなければC++の入門サイトでも見てくれ。

リストから取り出す必要があるなら、何度も言うようにdynamic_castな。
void update(TaskManager &tm) {
　ClassB *b = dynamic_cast<ClassB *>(tm.getTask("ClassB"));
　if(b) b->moveB();
}

＞たとえばクラスＡとＢがあったときクラスＢだけがもつmoveBメソッドを呼びたかったと
で、こういう場合、クラスBとそれを使うクラスの間には何らかの関係があるわけだから、
クラスＢ(へのポインタ)を、『タスクリストに追加する前に』、それを必要とするクラスのメンバ変数にするんだよ。
class Hoge : public Task {
private:
　ClassB *b;
protected:
　void update(TaskManager &tm) {
　　if(!b) {
　　　b = new ClassB();
　　　tm.addTask(b);
　　}
　　b->moveB();
　}
};
bの初期化のタイミング（Hogeのコンストラクタか、updateを最初に呼ばれたときか、
別にinit関数を作るか……）は好きにしてくれ。

以降のレスは呼んでる暇がないので、既にフォローされてたらごめん。

**名前は開発中のものです。** · 2009/01/13(火) 13:49:36

>>559
型判定の方法は論点じゃないから dynamic_cast の話は放置しておk

**名前は開発中のものです。** · 2009/01/13(火) 20:22:42

まともな人がいて助かる
型の判別方法は問題じゃ無い

続き

結局、型は判別しなきゃいけないんだよ
だったら別にまとめることなくね？
まとめた処理がしたかったらそんときだけ必要なもんだけ入れたポインタリストでも作ればいいんじゃないの？
わざわざごった煮にする意味がわかんないね
次の行動にターゲットが必要になった時点で共通仕様の縛りのせいでかなり悩まなきゃいけないじゃん
グローバル変数使ったり、生きてるか死んでるか不明のポインタをゲームオブジェクトが保持るとかいう
かなりアフォな構造になるじゃん

**名前は開発中のものです。** · 2009/01/13(火) 20:39:48

もうさ、タスクシステム勉強会を開いてそこで議論したほうがよくね？

**名前は開発中のものです。** · 2009/01/13(火) 21:15:46

ごった煮にしなければいけないなんて決まりはない。
リスト、ツリーに色々種類があるのと同じ。
使いやすいように各自工夫すればいい。

**名前は開発中のものです。** · 2009/01/13(火) 22:38:35

>>563
結局、タスクシステムって何？　どこまで「工夫」したら、タスクシステムじゃなくなるの？

**名前は開発中のものです。** · 2009/01/13(火) 22:42:14

単なる名称だからタスクシステムでもなんでもいいんだよね。
最近はフレームワークとか言ってる。

**名前は開発中のものです。** · 2009/01/13(火) 23:45:59

引数なくしてグローバル変数やシングルトンでやり取りされるのが一番困る
バグったら最後
誰もバグとれないくせに使い続けるんだもんなぁ・・・

**名前は開発中のものです。** · 2009/01/14(水) 00:48:21

上位階層の改修を前提にするのは賛成しかねる

**523とか** · 2009/01/14(水) 01:11:41

判別方法は関係ない？
>>525,534,539,546
俺には、一貫して型の判別方法を聞かれているようにしか読めなかったんだが。
じゃあ、俺は一体何について聞かれていたんだ？

**名前は開発中のものです。** · 2009/01/14(水) 01:22:41

ポリモーフィズムのポの字も知らない馬鹿はスルーしろってことじゃねえの

**名前は開発中のものです。** · 2009/01/14(水) 01:45:38

>>525,534,539,546
特有の処理についてもっとkwsk

>>566
>引数なくしてグローバル変数やシングルトンでやり取りされるのが一番困る
何をやり取りされるのが困るかkwsk

**名前は開発中のものです。** · 2009/01/14(水) 03:06:10

>>568
うーん・・・たぶん。こういうことだろう。

>>561は、たとえば衝突判定とかするときに、結局型判定(というか属性判定)するじゃない。
たとえば自機と敵機が同じリスト構造内にいても、自機⇔敵機衝突判定するときに、
リスト構造内を検索、その際にゲームオブジェクトが自機なのか敵機なのか属性判定する事は避けられない。
といいたいんだと思う。

だから多態性とか継承とかとはまったく別の問題だよーってことじゃね。>>558見てわかった。

>・入り口のメソッドだけあわせておけばあとはオブジェクトが自発的に処理すりゃいいだろ派
これが俺や>>568が言ってたこと。

>・オブジェクトの相互作用はまとめてかいたほうがいいだろJK。
　そうすると個別のオブジェクトの区別が必要だから1つに束ねると効率悪いだろ。
これが>>561がいってたこと。

たぶん。

・敵リスト
・自機リスト
・背景リスト
みたく属性ごとにリストを分ければ、衝突判定等の記述がシンプルにかける。全部ごった煮にするとかけねーよってことか。

**名前は開発中のものです。** · 2009/01/14(水) 03:10:43

なんだか同じことの繰り返しで対話にならないっぽいので、
他の人から何もなければひとまずこれで引くわ。

>>555
＞自機、敵、自弾、敵弾の内、敵と敵弾だけに絞りたい場合なんかも型を判別する必要あるよな
最初から敵を管理するクラス、敵弾を管理するクラスを用意すればいい。
「タスク」レベルまで抽象化したものをわざわざ判別して取り出す必要はない。
使用頻度が低いとか、必要かどうか前もって分からないとかだったら、
後から取り出しても別に構わないとは思うけど。

>>561
＞まとめた処理がしたかったらそんときだけ必要なもんだけ入れたポインタリストでも作ればいいんじゃないの？
これはそのとおり。タスクリストは「毎フレーム（優先度順に）処理関数を呼ぶ」
「親子関係を持ち、親が死ぬと子も死ぬ」処理を行うためのもの。
（メモリ管理云々は、個人的にはタスク処理とは別の話だと思う）
積極的に他の目的のために使おうとするからおかしなことになる。

>>561の後半は何が言いたいのかまったく分からん。
「次の行動にターゲットが必要にな」るってのはどういうこと？

生きてるか死んでるか不明のポインタって、まだ必要なポインタが
解放されてるかもってこと？　それは構造関係なくただのバグじゃん。

ああ、念の為書いとくけど、別にタスクシステムを（他の方法より）
優れた方法だと言うつもりもないし、ましてや薦める意図はまったくないよ。
既に他の方法を確立しているならそれを使えばいいし、初心者なら
テクニックに走らず、ゲームの構造をそのままクラスにしたほうがいいと思う。
ただ、自分で制限つけたり、他の目的に使おうとしたりして、
「使いにくい」「利点がない」ってのはどうかと思っただけ。

**名前は開発中のものです。** · 2009/01/14(水) 04:33:34

>>571
>>525がそういう意味だとは思えないし、もしそうだったとしても、それについては
「それを必要とするクラスのメンバ変数として持てば、判別の必要はない」と何度も答えてる。
もちろん、「敵の種類」とかの判別は必要になるだろうけど、
それは「ごった煮リストからの判別」とはまったく別の話だよね。

つか、「個別のオブジェクトの区別が必要だから1つに束ねると効率悪い」はそもそも順番が逆で､
同じように扱いたいから１つに束ねたのに、個別のオブジェクトに戻そうとするから効率が悪くなる。
それに、オブジェクトが自発的に（見えるように）updateするのと、そのupdate関数内で
関連するオブジェクトを（個別のオブジェクトとして）利用するのは、別に背反することじゃない。

**名前は開発中のものです。** · 2009/01/14(水) 06:12:22

>>572-573
長ｗ
駄目だよ
レス自体誰も前提にもってない話が勝手に常識のように入ってるし
自分の妄想だけで話進めて俺と会話するつもりもない感じ
いいたいことまとめないとレスつけないよ

**名前は開発中のものです。** · 2009/01/14(水) 06:16:11

だいたい判別する必要あるじゃん
何がねぇんだよ
オブジェクト内に別オブジェクトの型なんかごちゃまぜにアクセスできたら
そもそもカプセル化も糞もねーじゃん
自機クラス内で敵クラスにも弾クラスにもアクセスできる時点でオブジェクト指向破綻してんじゃん
もう言ってることおかしい

**名前は開発中のものです。** · 2009/01/14(水) 08:54:18

>>575
コンポジットというものがあってな
もうしょうがなからぺにっぺにっでにっしんさせるね

**名前は開発中のものです。** · 2009/01/14(水) 10:11:36

OOスタイルで構文解析機を書けば「ごった煮」なASTになるわけだが……
DOMぐらい知らんのか？

まあ、dynamic_castすら知らないぐらいだから仕方がないね

**名前は開発中のものです。** · 2009/01/14(水) 14:21:56

ごめん俺DOMナメてたわ

リックドム。なんちて

**名前は開発中のものです。** · 2009/01/14(水) 18:21:13

dynamic_cast未サポートのコンパイラが普通にあることすら知らないぐらいだから話合わないのも仕方がないね

**名前は開発中のものです。** · 2009/01/14(水) 18:27:56

dynamic_castが使えないのなら、型タグに相当するものを実装すればいいだけだよ
Cのunionならいつもやることだろうに、アホか

**名前は開発中のものです。** · 2009/01/14(水) 19:02:01

え？
そんなコンパイラをお使いで？
相当のマゾでつね
D どんなもんだい
O オレは
M マゾっ気100%だぜ

**名前は開発中のものです。** · 2009/01/14(水) 19:45:31

>>580
union使ったら型システムに穴が空くジャン
できることなら使わずきれいに済ませたいジャン

>>581
それはさすがに釣る気みなぎりすぎｗｗｗ

**名前は開発中のものです。** · 2009/01/14(水) 20:15:23

また、全然関係無いレスばっかりつける
ちょっと前も型の判別方法なんて問題じゃないってのに
キャストキャスト連呼してる恥ずかしい奴がいたけどにたようなのしかいないのか？

**名前は開発中のものです。** · 2009/01/14(水) 20:44:37

>>583
いや、それは>>525が「型の判別方法わからん」とか言ってるから
何人かが教えてやってただけだろ……

**名前は開発中のものです。** · 2009/01/14(水) 20:49:28

>>582
Cなら仕方ないだろ
unionの類を使わずにLispインタプリタでも組んでみたらどうだ？

C++にしても、代数データ型はないのだし、ポリモーフィズムの手段が
継承なのだから、ダウンキャストはある程度宿命であり必要悪だ
無論、それを最低限に抑えることが望ましいがな

**名前は開発中のものです。** · 2009/01/14(水) 20:58:47

>>585
はぁ？なんのための必要悪なの？
そもそもベタ書きでゲーム作ったことあるのかすら怪しいね
だってゲーム作って複雑になるところとキャスト云々って全然関係無いもん

**名前は開発中のものです。** · 2009/01/14(水) 21:08:00

>>583
ごめんよ
以前dynamic_castが使えない環境でゲームプログラム書くことがあったから動的キャスト必須は移植性を考えるとありえないという頭があった。
あとunionは宗教上の理由で滅多に使えないので型タグ相当も小資源で作ることができない。これは俺のポリシー。
ライブラリ内なら使うかも。

そういう条件下だと性能の良し悪しとか概念の洗練度なんて議論とは全く別次元で、簡単に一意に解答が定まってしまう。
　「オブジェクト群を１つに束ねることは不可能」
って。
そういう立場の人もいるかもと頭の片隅にでも置いとくと怒りが安らぐかもしれない。

union使える宗教の人とかdynamic_cast使える環境が大前提の人にとっては有用な議論なんだろうなぁ、きっと。

**名前は開発中のものです。** · 2009/01/14(水) 21:16:40

>>584
それは>>523が特有のメソッドを追加しても問題ないっていうから
特有のメソッドを読んだら型判定が必要になって
ごった煮リストにしておくメリットねーぞって話のつもりだった

が、読み返してみるとたしかに型判定知らないアフォみたいだなｗスマンコｗ
でも問題はそこじゃないんだ

**名前は開発中のものです。** · 2009/01/15(木) 09:09:38

>>572
> これはそのとおり。タスクリストは「毎フレーム（優先度順に）処理関数を呼ぶ」
> 「親子関係を持ち、親が死ぬと子も死ぬ」処理を行うためのもの。

それって、単に子インスタンスをメンバ変数で持つだけで良いんじゃね？

class Enemy;
class Player;
class Scene {
　Player player_;
　std::list<Enemy> enemies_;
public:
　void exec() { PlayerExec(); EnemyExec(); HitCheck(); ... }
};

タスクって何？

**名前は開発中のものです。** · 2009/01/15(木) 12:21:31

>>587
なんだか俺がdynamic_cast云々の発端っぽいので一応言っておくけど。
dynamic_castは「型の判別方法」を聞かれたから答えただけで、
必要なものは元の型のままメンバ変数として持てば、
通常、dynamic_castが必要になる場面はないよ。

>>589
それでいいよ。
別にそういう書き方を否定してないよね。

**名前は開発中のものです。** · 2009/01/15(木) 12:42:59

>>590
>589 で十分だと言いながら、 >572 を読む限りあんたは何かの目的を持って
ごった煮リストにつなぐ（ことがある）んだろ？
しかもそれが初心者にはおすすめできない「テクニック」であると言うじゃないか。

それは何のためなのか、どんなメリットがあるのか、あるいはどんな問題が解決されるのか
ってのがこのスレ的には主題だと思うんだ。

**名前は開発中のものです。** · 2009/01/15(木) 20:17:43

まず、タスクシステムによって解決する問題をはっきりさせるほうが先じゃね？

**名前は開発中のものです。** · 2009/01/15(木) 22:01:19

>>592
>>535

**名前は開発中のものです。** · 2009/01/15(木) 22:28:38

裏山で出土した石器を明日の仕事でどうやって使うか話し合うスレはここですか？

**名前は開発中のものです。** · 2009/01/15(木) 22:46:56

>>594
なんて適切な表現だ

**名前は開発中のものです。** · 2009/01/15(木) 23:31:42

>>594
いいえ。そういう話し合いを望んでいる人間で、現状で生存確認が取れてるのは数人だけ。
筆頭は確定君。「確定」で検索しなさい。

村人達がとっくの昔に遺棄し朽ち果て忘れ去られたはずの山道、というか舗装もされてない獣道。
ある日ハーメルンの笛吹き男が現れこの獣道の入り口だけをお色直しして純真向くな都会の若者達を
招き入れるようになりました。

　「さぁおいで。夢の国へ続く道だよ。通行料代わりに私の本を買ってきなさいピーヒャララ♪」

その獣道は先に進めば進むほど細く険しくなる茨の道。落石や崩落で寸断され死人も出た危険な道。
今では村には国道や高速道路や鉄道が整備されトンネルで一直線に隣村や町に行けるようになり
その危険な獣道を使う村人はもういません。沢山の若者達が嬉しそうに入っていく様子を村人達は
とても不思議そうに眺めていました。「都会の若者が考えるこたわがんねなぁ」
ある村人は興味本位でその疑問を入山する若者に問いかけました。すると若者は快活に答えました

　「え、知らないんですか。可搬性と拡張性に優れた素晴らしい世界へ続く道ですよ。これ確定です」

村人は意味がよくわかりませんでしたが、戻ってきたら旅の感想を聞かせてくれると若者が約束
してくれたので楽しみに待つことにしました。しかし待てど待てどその純真無垢な若者が帰ってくる
ことはありませんでした

**名前は開発中のものです。** · 2009/01/16(金) 00:30:47

タスクシステムって名前じゃなけりゃ
こんなにまで議論の対象にならなかったと思うんだけどなぁ

名前を初めて聞いたときどんなすごいシステムなんだろうと思ったが、
詳細見てしょぼさ加減に思わず吹いたよｗｗｗ

タスクと聞くとOSをイメージしてしまうし、
システムとかたいそうな名前付けてる割には
パターンやイディオムレベルの構造だしな

**名前は開発中のものです。** · 2009/01/16(金) 00:49:04

>>597
そういうことなんだけど、それを理解できずに荒らす人がいるんだよね。
だからそういう人をこのスレに閉じ込めてるんでしょ。

**名前は開発中のものです。** · 2009/01/16(金) 01:04:30

タスク信者を荒らし認定すんなカス

**名前は開発中のものです。** · 2009/01/16(金) 01:07:52

タスク信者乙

**名前は開発中のものです。** · 2009/01/16(金) 07:37:53

タスク信者は
プログラム言語に型なんかないほうが扱いやすいって言ってるのと同じだよね
実際、タスクシステム使って組むと思いっきり型邪魔だしね

**名前は開発中のものです。** · 2009/01/16(金) 08:38:19

タスク信者はあいかわらずソースを出さないので相手にしない

**名前は開発中のものです。** · 2009/01/16(金) 09:33:58

タスクシステムに似た仰々しい名前を教えるね
「コントロールブレイク」
ミンナニハナイショダヨ

**名前は開発中のものです。** · 2009/01/16(金) 12:05:28

>>596
>今では村には国道や高速道路や鉄道が整備されトンネルで一直線に隣村や町に行けるようになり

詳しく

**名前は開発中のものです。** · 2009/01/16(金) 15:33:43

1ヵ月ぐらい住み着いてる抽象的な話で煙に巻く君だ。
放置推奨。

**名前は開発中のものです。** · 2009/01/16(金) 16:31:33

托鉢癖の乞食には酷く癇に障るものらしいよ

**名前は開発中のものです。** · 2009/01/16(金) 16:58:27

>>606
韓国語でおｋ

**名前は開発中のものです。** · 2009/01/16(金) 18:18:09

??? ???

**名前は開発中のものです。** · 2009/01/17(土) 00:19:12

型安全なタスクシステムってC++のtemplateとか使えばできるかな？
無理？

**名前は開発中のものです。** · 2009/01/17(土) 00:20:32

>>609
コード書いてみ

**名前は開発中のものです。** · 2009/01/17(土) 00:44:48

>>609
templateはあくまでコンパイル時の・静的なポリモーフィズムが実現できるだけでしょ

**名前は開発中のものです。** · 2009/01/17(土) 01:43:07

>>609
>>2じゃなくて（ごった煮にはしないで）素直に組む場合
型別で管理クラスを作るのにテンプレートは便利

**名前は開発中のものです。** · 2009/01/17(土) 13:05:26

レスThanks. 利点ありそうなので書いてみた。
でもtemplate自体さっき調べながら書いたのでコンパイル通るかすら怪しい。そこは注意。
あとタスク化の対象をオブジェクトではなく関係性にしてみた。「自機」、「自機弾」でなく、「自機弾生成」のくくり。動詞？
typedef struct {
　　std::list<CPlayer *> *m_player;
　　std::list<CEnemy *> *m_enemy1;
} PlayerEnemy1_t;
std::list<CPlayer *> m_player;
std::list<CEnemy1 *> m_enemy1;
std::list<CBulletPlayer1 *> m_bullet_player1;
std::list<CBulletEnemy1 *> m_bullet_enemy1;
PlayerEnemy_t m_player_enemy;
Task<PlayerEnemy_t, (*collisionPlayerEnemy)(PlayerEnemy_t *)> m_task_collision_player_enemy;
Task<PlayerPBullet1_t, (*generatePlayerBullet)(PlayerPBullet1_t *)> m_task_generate_playerbullet;
template<class Tdata, class Talgorithm> class Task : public ITask {
private:
　　Tdata *m_data;
　　Talgorithm *m_algorithm;
public:
　　void set(Tdata *data, Talgorithm *algorithm) {
　　　　m_data = data;
　　　　m_algorithm = algorithm;
　　}
　　virtual void update(void) {
　　　　m_algorithm(m_data);
　　}
};

**名前は開発中のものです。** · 2009/01/17(土) 15:40:02

>>613
通りすがりだけど、そのlistが持っているCPlayer*とかは誰が解体するの？

普通のタスクシステムなら、タスクシステムが解体を保証するだろうし、
さもなくば、auto_ptrなりshared_ptrなりを使うのが普通だと思うのだが。

解体責任を明確にする上でもタスクシステムは有効なのだが、
そのことは理解してる？

あと、C++なんだから、structをtypedefするのやめようよ。
それとtemplateの部分、何がしたいのかわからない。

**名前は開発中のものです。** · 2009/01/17(土) 16:06:08

吹きそうにやるからタスクシステムって言うのやめてくれwww

**名前は開発中のものです。** · 2009/01/17(土) 16:16:24

>>613
ちょっとまて
それが何を目的としたどんな問題を解消するのか
それを宣言してから先へ進んでくれ

**名前は開発中のものです。** · 2009/01/17(土) 17:01:51

>>615
話が進まなくなる。
なにか名前がないと会話できないだろ。
フレームワークだけ先に浸透しちゃったから、それぞれが勝手に名前付けてるんだよ。
>>２の人たちは、できるだけ統一したいから、多数派っぽいタスクシステムって名前を使ってるだけじゃないかな。

**名前は開発中のものです。** · 2009/01/17(土) 18:04:41

>>613
ESPを使ったところ、処理単位の粒度を粗くしようとしているのかな。と読み取ってみた

>>614
まぁ>>613のコードがスマポ使ったほうがよさげというのは同意だけど
俺のESPによるとそれは枝葉末節の話のような気がする

ところでその枝葉末節について思うこと

＞普通のタスクシステムなら、タスクシステムが解体を保証するだろうし
＞（中略）解体責任を明確にする上でもタスクシステムは有効

①キミのタスクシステムというのが何なのか知らんので
　⇒>>2みたいにひとつの循環リストに全オブジェクトをぶち込んでると仮定
②解体というのが具体的に何（ゲーム上の生死なのかリソース開放なのか）か知らんので
　⇒リソース（メモリ、OSから発行されたデバイス等のインターフェース、etc）の開放と仮定
③>>2の循環リストが何でソートされてんのか知らんので
　⇒差分処理の順序（>>2のプライオリティ？）でソートされてると仮定

以上の仮定のもとでレスを書くと、キミは
「全部入りの循環リストを舐めれば全リソースを開放できるから>>2は解体を保証してるのだ」と言ってるのね。
ところで>>2の循環リストは第一義にはゲームの処理の手続き、差分処理の順序を表わすものなんだよね？
単に全部入りのコンテナだからという理由でリソース開放用にこれを流用するの？

**名前は開発中のものです。** · 2009/01/17(土) 18:07:08

>>614
常々思うのは、何で>>2は（>>2を擁護する人は）ひとつの循環リストを特別にユーザーオブジェクトに侵入させ
ごった煮の全部入りとし、更にはこれにいろんな責任を与えようとするのかってこと。そこに合理的理由はあるのかな。
単なる貧乏性なんじゃないのかと思うんだよね

順序と集合が共通だから、ということで複数の責任・役目を与えるのはまぁいいよ
でも>>614みたいに第一義にはゲーム更新処理用のコンテナをリソース管理の責任も与えようとするなら
集合は共通してるけど順序は違うんだよね。ソートしなおすんだろうね

あと別件で、以前に>>2は親が死ねば子も死ぬという死の連鎖を表現できるという人がいたけど
これを直接に表現するのは>>2の侵入式の循環リストではなく、ユーザー側で用意する親子関係を表わすツリーだよね。
で、必要ならそのツリーをトラバースした順序をもとに>>2の侵入式循環リストの当該箇所をソートしなおすんでしょう？
>>2は親子の死の連鎖とかぶっちゃけ関係ないよね。ユーザー側に丸投げしてるでしょ

何で普通の（つまり外部収納の）コンテナを役割毎に持たないの？リソース管理用ならリソース管理用
更新手続き用なら更新手続き用、親子関係なら親子関係用、機能を明確に分離できずに無闇に
癒着させるってのは、硬直して首が回らなくなる危険を犯すってことだよ。経験に裏打ちされたものがない人に
こういう貧乏j根性主導のコンテナ共同利用はオススメできないよ

**名前は開発中のものです。** · 2009/01/17(土) 18:09:41

わけわかんなくなるから想像や仮定を前提にして話を進めようとするのはやめてくれ。
わからないことは素直に聞けよ。答えが返ってこなければそこまでの話だ。

**名前は開発中のものです。** · 2009/01/17(土) 18:16:35

> ①キミのタスクシステムというのが何なのか知らんので
> 　⇒>>2みたいにひとつの循環リストに全オブジェクトをぶち込んでると仮定
> ②解体というのが具体的に何（ゲーム上の生死なのかリソース開放なのか）か知らんので
> 　⇒リソース（メモリ、OSから発行されたデバイス等のインターフェース、etc）の開放と仮定
> ③>>2の循環リストが何でソートされてんのか知らんので
> 　⇒差分処理の順序（>>2のプライオリティ？）でソートされてると仮定

とはいえこれは妥当な仮定だわな
解体はゲーム上のオブジェクトの死ではなくリソース開放だろ
>>2のプライオリティの使い方は処理順だ
これも一致してる

ま、仮定するまでもなく的中だろう

**名前は開発中のものです。** · 2009/01/17(土) 18:33:30

なんで妥当なの？
オブジェクトごとのリスト、優先度なし、ソートなし。
これはタスクシステムと言ってはいけない？

**名前は開発中のものです。** · 2009/01/17(土) 18:45:51

>>622
普通は優先度ありはデフォっぽい気がするけどねぇ
じゃないと全てを入れるリスト構造がまともに動くとは思えないし。

全部まとめるから優先順位が必要になるんだよなぁ・・・

**名前は開発中のものです。** · 2009/01/17(土) 19:05:28

http://codezine.jp/article/detail/297
ここにあるサンプルを見る限りでは
オブジェクトごとのリストというよりタスクのリスト（似たようなものかな
優先度あり
優先度によるタスクのソートあり
だが

オブジェクト指向でのタスクシステムで異論を唱えている方は
同じことをやっているが手段が違うといったところですかな

**名前は開発中のものです。** · 2009/01/17(土) 19:06:04

>>622
で？なんなのその聳え立つ一本糞コレクションは。
それでナニすんのおめぇ？食うの？食えんのか？え、食うの？

もう今となってはさ、タスクシステムとか言ってる奴って
こういうカスばっかなんだな。認めざるを得ないわ

**名前は開発中のものです。** · 2009/01/17(土) 19:08:03

>>621
いやいや >613 が >2 を理解しているとは限らないだろ。
少なくとも >613 からはそれは読み取れん。
むしろ >613 が >2 を理解している信者であるという仮定は >613 のコードからすると大胆すぎる。

そもそもこれまでの流れを見る限り信者もアンチもこのスレの住人が >2 を理解してるとは思えん。
俺もよくわからん。書いてることバラバラじゃねえか。

**名前は開発中のものです。** · 2009/01/17(土) 19:12:23

http://nullpo.vip2ch.com/ga26086.jpg

**名前は開発中のものです。** · 2009/01/17(土) 19:17:12

待てなんだこの図は
どこにこんなんあるんだｗ

**名前は開発中のものです。** · 2009/01/17(土) 19:18:01

>>614
for (i = m_player.begin(); i != m_player.end(); i++) {
　　if (i->is_need_delete()) {
　　　　delete(*i);
　　　　i = m_player.remove(i); //うろ覚え
　　}
}
こんな感じで呼び出し側が解体を保証することとする。責任は明確。

スマートポインタは.exeの終了時にdeleteし忘れてるのを勝手にやってくれるという程度のイメージしかない。
そんなのOSにまかせとけばいいと思う俺は趣味ゲームプログラマ。

templateの部分はTaskクラスをvirtualでなくtemplateで書いてみたというもの。
ゲームオブジェクトとタスクの癒着を引き剥がすことが出来てる感じがしないかと。
やりたいことはタスク化の焦点をオブジェクトだけでなく、関係性にも拡張したかった、んだと思う。
俺フィーリングで動いてるから自分でも明確な理由分からないｗｗ

ITaskはおまけ。無くてもいいのかも。
C++なんちゃってタスクシステムのを残しただけ。class ITask {public:virtual update(void)=0;};

**名前は開発中のものです。** · 2009/01/17(土) 19:20:42

>>623
言葉が悪かった。
オブジェクトの種類ごとにリストを分けるだけで、単純なものなら優先度が不要になる。
シューティングの弾だったらほとんど生成順に描画で問題ないでしょ。

**名前は開発中のものです。** · 2009/01/17(土) 19:21:16

>>618
> ところで>>2の循環リストは第一義にはゲームの処理の手続き、差分処理の順序を表わすものなんだよね？
> 単に全部入りのコンテナだからという理由でリソース開放用にこれを流用するの？

解体責任が分散すると解体忘れにつながるからC/C++で書くなら
(auto_ptrやshared_ptrを使わずに愚直に書くなら)全部入りのコンテナか、
あるいは、その周辺が解体責任を担うように設計するのは普通だと思うんだが。

>>619 は一理あるので否定はしない。

ただ、(俺が作ってきた)タスクシステムは、タスクの生成/解体まで
タスクシステムがその権限/責任を持っていて、タスクデバッガのようなものを
attachさせて、実行時に走っているタスクをwatchしたり、実行時にbreakを
かけて特定のタスクを生成を指示したりすることが出来る。

まあ、これは「タスクシステム」ではなく、「タスクに関するフレームワーク」と
呼ぶべきかも知れない。ともかく、これが使い回しが利いてとても便利なんだ。

特定のタスクがイレギュラーな構造になっているとこのフレームワークの
恩恵を受けられない。それが嫌なんだな。

まあいいや。たぶんこのスレの趣旨とは違うんだろうから、おとなしくROMっとくよ。

**名前は開発中のものです。** · 2009/01/17(土) 19:25:08

>>629
>for (i = m_player.begin(); i != m_player.end(); i++) {
>　　if (i->is_need_delete()) {
>　　　　delete(*i);
>　　　　i = m_player.remove(i); //うろ覚え
>　　}
>}
>こんな感じで呼び出し側が解体を保証することとする。責任は明確。

1. そのコード、呼び出し側に持つとゲームを作るごとに
コピペなりなんなりで書かないといけないんじゃ？

2. 親タスクが子タスクのstd::list<Child*>のようなものを持っていると、
親が死んだ子に対してアクセスしてしまう。これをどうやって防ぐの？

**名前は開発中のものです。** · 2009/01/17(土) 19:57:14

>>616
説明書き無くてスマソ。
Taskクラスをvirtualでなくtemplateで書いてみたらこうなったというもの。
目的ありきではなく、まず作っちゃったんだけど何かに使えないかなこれという感じ。
C++なんちゃってタスクシステムの欠点を解消できないかなと。

>>618
ESPどうも。そうっすね。処理単位の粒度関係で影響ありそう。
generatePlayerBullet()なんて本当に出来たらかっこいいと思いません？（というかもうやってる？）　多分内容はこう。
typedef struct {
　　std::list<CPlayer *> *player;
　　std::list<CBulletPlayer1 *> *bullet_player1;
} PlayerPBullet1_t;
void generatePlayerBullet(PlayerPBullet1_t *data)
{
　　for (i = data->player->begin(); i != data->player->end(); i++) {
　　　　if (i->need_generate_bullet1()) {
　　　　　　data->bullet_player1->push_back(new CBulletPlayer1(i->get_pos(), i->get_target_dir()));
　　　　}
　　}
}
void 1フレーム分の処理(void)
{
　　//Task<...>のsetは前もってどっかでやっとく
　　//ここで入力関係update
　　...
　　m_task_collision_player_enemy.update();
　　m_task_generate_playerbullet.update();
　　...
　　//ここで描画、サウンド関係update。（例）m_task_draw_player.update();
}
※update群はC++なんちゃってタスクシステム(ITask)でまとめるも良し。そのままでも良し。

**名前は開発中のものです。** · 2009/01/17(土) 19:58:56

>>628
私の趣味の画像でございます
お気にさわるようでしたら削除いたします

**名前は開発中のものです。** · 2009/01/17(土) 20:07:56

>>631
ごめん。相手を見誤ってた。俺は>>618で
ID:8YYLBgEpの言うタスクシステム＝>>2と仮定してたんだけどこれ間違いだね。

ID:8YYLBgEpの言うタスクシステムはゲームオブジェクトのモニタでもあるんだね。
（というかモニタ機能がむしろメインだろうと思う）

＞解体責任が分散すると解体忘れにつながるからC/C++で書くなら
＞(auto_ptrやshared_ptrを使わずに愚直に書くなら)全部入りのコンテナか、
＞あるいは、その周辺が解体責任を担うように設計するのは普通だと思うんだが。

これは同意。上記の仮定間違いに伴うすれ違いだった。具体的には
>>2の場合、ユーザーは（ゲームオブジェクトのジョブを書く奴は）TCBにかなり自由に頻繁に触るので
TCBのパラメータが全く信用ならない⇒解体には別の、外部収納のコンテナが欲しい
（デバッグ用モニタとしては別のアドレス空間に欲しい）という趣旨で書いたんだ

＞ただ、(俺が作ってきた)タスクシステムは、（後略）

全くもって同意。異論を挟む余地がない

以下蛇足

モニタ機能の記述が完全に欠如したタスクシステム解説のWEBページや書籍があまりに多いので、俺は
「世間ではこういうものがタスクシステムと呼ばれるようになったのか。じゃあタスクシステムという言葉を
職場内で使うのも止めよう。」ということでタスクシステムという呼称を使うのやめちゃった