タスクシステム総合スレ 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/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ページや書籍があまりに多いので、俺は
「世間ではこういうものがタスクシステムと呼ばれるようになったのか。じゃあタスクシステムという言葉を
職場内で使うのも止めよう。」ということでタスクシステムという呼称を使うのやめちゃった

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

タスクシステム信者にお伺いしたいことがございますが
class A;
class B {
A *obj;
};
が理解できますか？

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

モニタ機能って、なんか、わざわざ発生させた問題に対策を用意して
対策を売り込むとか、マッチポンプじゃないの？

普通に組んで、普通にデバッガ使うのと何が違うの？

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

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

揚げ足を取るようで申し訳ないのですが
Observer パターンというものがございます
http://ja.wikipedia.org/wiki/Observer_%E3%83%91%E3%82%BF%E3%83%BC%E3%83%B3

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

>>635
了解しました。あなたとは同業者っぽいね。

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

>>636
コンポジションがどうかしたの？
まぁタスクシステム（>>2）信者じゃないから反応する理由はないんだけど
>>2とは全く異なる、自社製のマイクロカーネルがタスクシステムと呼ばれてたもんでね
まぁ、どうでもいい田舎モンのローカル用語だから実態が違うのは当然だし
世間様の前で「これがタスクシステムだ！」なんて絶叫したりしないから俺は心配ない。はず

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

>>640
いや、なに
一流と呼ばれている方が私のコンポジションだらけのソースを
わけわからんとおっしゃいまして
彼はタスクシステムを理解できていたようで
疑問に思っていた次第であります

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

>>638
GoFのデザパタに関する知識は後付け・付け焼刃のハンパなもんだけど
揚げ足をとられてる実感が全くないので詳しく頼むわ

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

>>642
>呼称を使うのやめちゃった
最後まで読んでおりませんでした
私の論理的ミスです
申し訳ございません

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

実際、>>619はタスクシステムで組んでるとぶち当たる問題を的確に表現してるな
これを問題と意識せずに華麗にスルーしてしまうとタスクシステムを使い続けるようになるんだろう
まずいものはまずいとちゃんと認識したほうがいい

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

>>632
1. Yes. コピペ上等の精神で乗り切る、はダメ？
　まぁ呼び出し側にdelete書く利点も探せば結構あるかと。もし欠点以上に利点探せたならラッキー。
　例えば、
　・こっちのがクラスの単体テストしやすそう
　・deleteを一気に1フレームでやらずに残り時間に応じて分散させたい場合に
　　ゲームオブジェクト内のステートだけではタイミングを判断できないかもしれない。
　　でも呼び出し側でなら制御できるかも。
　・複数行の見栄えが嫌なら関数化してお勧め処理として一緒に付けとけば軽減可能

2. 子タスクは無しの方向で。全部同列、同位の存在にする。
　タスクという概念上はどれも全部「処理」。親子の概念なし。
　処理順序はupdate()の記述順序で指定。

　親子タスクは無いけれど親子データとか親子オブジェクトは欲しい。
　それは単なるオブジェクト間の通信に帰着可能だと思うので
　下のupdate()群のように等価に置き換えできないでしょか。
void 1フレーム分の処理(void)
{
　　...
　　m_task_update_player.update();
　　m_task_follow_player_option.update(); // player->isdead()ならoption->set_state(PLAYER_DEAD);したり
　　m_task_follow_player_lasershot.update()
　　m_task_delete_player.update();
　　m_task_delete_option.update();　//need_delete()ならdeleteしたり
　　m_task_delete_lasershot.update();
　　...
　　m_task_draw_option.update();　//もしくは死亡アニメーション終わったらdeleteしたり
　　...
}

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

>>645
> 1. Yes. コピペ上等の精神で乗り切る、はダメ？

・類似コードなのに再利用できない
・同じ処理内容のコードが複数の箇所に現われる

のは、プログラムの書き方がおかしいからだということを
もっと意識しておいたほうがいいと思うよ。

>　・deleteを一気に1フレームでやらずに残り時間に応じて分散させたい場合に
>　　ゲームオブジェクト内のステートだけではタイミングを判断できないかもしれない。

それは、まったく逆だと思う。deleteしているのが一カ所に集中していれば、1フレームでN回以上は
deleteしないという処理を書くのはたやすいけど、deleteしている部分が分散していたら
そんな処理を書くのはとても面倒。

> 親子タスクは無いけれど親子データとか親子オブジェクトは欲しい。
>　それは単なるオブジェクト間の通信に帰着可能だと思うので
> 下のupdate()群のように等価に置き換えできないでしょか。

そのコードのどこにオブジェクト間の通信のコードがあるのかわからない。
あと、その1フレーム分の処理、updateを書き忘れたり、新たに動かすものが増えるごとに
新たにその関数のなかにupdateを呼び出すコードを追加しなくてはならない。

これだといわゆる従来のタスクシステム(>>2)と比べても大幅に劣っている。

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

そういえば >>613 でゲームオブジェクトとからタスクを分離させた着想の元は
>>553 のレスの
>ゲームオブジェクトをupdateのみを持つ別のクラスで包む
だったかも。
それと「template使ったら何かがきれいに書けるかも！」という思い付きがなぜか混ざった。
昨晩は酔っ払っておりました。

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

>>646
>・類似コードなのに再利用できない
>・同じ処理内容のコードが複数の箇所に現われる
・類似コードは単に似てるだけ。同一のコードではないので再利用できないのは当然。
・同じ処理内容のコードは関数化するべき。これはその通りです。そうするべきです。
　関数化した後、その関数の呼び出し記述がゲーム毎に存在するのはOKですよね？

> それは、まったく逆だと思う。deleteしているのが一カ所に集中していれば、1フレームでN回以上は
> deleteしないという処理を書くのはたやすいけど、deleteしている部分が分散していたら
> そんな処理を書くのはとても面倒。
呼び出し側に様々なオブジェクトのdeleteがまとまって延々と記述されているのに対し、
複数のゲームオブジェクト内にdeleteが記述されるためにdeleteが分散しているしていると認識することも可能。
分散しているのはどっちかという認識が私と違っているようです。

> そのコードのどこにオブジェクト間の通信のコードがあるのかわからない。
m_task_follow_player_option.update(); // player->isdead()ならoption->set_state(PLAYER_DEAD);したり
m_task_follow_player_lasershot.update()

> あと、その1フレーム分の処理、updateを書き忘れたり、新たに動かすものが増えるごとに
> 新たにその関数のなかにupdateを呼び出すコードを追加しなくてはならない。
update書き忘れはnew TaskA()の書き忘れと同等のものです。バグです。数が増えたことを問題視している？
　・update呼び出しコードを挿入
　・tskmgr->add(new TaskA(), PRIORITY_A)というコードを挿入
コードの追加はどちらも必須。しかしPRIORITY_Aという優先度の定義が数値だとして既に
　#define PRIORITY_CHARA 123
　#define PRIORITY_BG 124
と定義されていた場合、
　#define PRIORITY_A 123.5
はできないのでは？　運用でカバー？

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

>>648　は何が言いたいのかよくわかんないのでもう帰ることにするよ。最後まで相手できなくてごめんね。

2chを久々に見にきて、たまたま面白そうな話題だったからちょっと首つっこんでみただけなんだ。

しかし2chって面白いね。ID:1fr/EvSg みたいなベテランプログラマと、 ID:OfSsMU0e みたいな
ド素人(気を悪くしたらごめんね)とがひとつのスレで議論してたりするんだね。新鮮だった。

俺は大手ゲーム会社でかれこれ15年ぐらいプログラム書いてきてるんだけど、従来のタスクシステム( >>2 )は
出発点としては意味があると思うね。それをフレームワークとしてどう発展させていくかという問題はあるけどね。

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

>>649
整理して言えずごめんなさいね
ド素人には気は悪くしましたがタスクデバッガのようなものとか私作れないのでまぁ仕方ない。
何年も実業務に携わってる人にケチつける気は毛頭ないです。

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

生存タスクを列挙したりとか、生成・解放のログを取ったりとかは普通にやるよね。
それ以上のことは普通のデバッガで十分じゃない？

**名前は開発中のものです。** · 2009/01/18(日) 02:57:06

>>609
デザインパターンのオブザーバーとかをスマートポインタあたりでくるんで使うと
だいたい良い感じにそうなると思うよ。

C++の機能を使えばタスクシステムとやらを作っても危険性はまったくなくなるのだが
どうもC言語から離れたくない人が多いみたいだ。

**名前は開発中のものです。** · 2009/01/18(日) 03:49:58

>>652
>C++の機能を使えばタスクシステムとやらを作っても危険性はまったくなくなるのだが
危険性じゃなくて意味がないってほうが言いたいけどな

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

ほとんどROMってるだけだけど、たまには俺も口を出そう。

何でも同等に扱うごった煮的アプローチが批判されてばかりいるけど、
昔のゲームみたいに敵/味方とはっきり分かれているのは別として
最近の自由度が高いゲームだと元々システム的にあらゆるオブジェクトが
ほとんど対等な扱いだったりするから、そういう状況で使うのは有りだと思う。

PCのゲームだとデータ改竄で普段なら有りえない現象を見たりできるけど、
実装がごった煮っぽい現象はたまに見るよ。

**名前は開発中のものです。** · 2009/01/18(日) 10:28:34

>>654
はぁ？そりゃゲームの仕様の話だろ？
なにいってんだよ
お前、いままでで一番ピントがズレてんだよ
たまに口挟むなんてやらないほうがいいぞ
ここで煽りあって議論してる奴等もピントはずしたらどうなるか
一応わかってレスつけてるからレスを返せるんだぞ

**名前は開発中のものです。** · 2009/01/18(日) 12:40:20

えらそうw

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

>>655
でもゲームの仕様、つまり実装目標を無視して構造を考えるって、極めて無意味っぽくね？
手段と目的が完全に逆転してる希ガス

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

>>657
は？仕様がごった煮だからごった煮でいいって？
アフォでしょ？相手にもしたくない驚愕すべきレベルだな

**名前は開発中のものです。** · 2009/01/19(月) 00:03:33

ここでタスクシステムの議論してる人らってそのタスクシステムをなにに使おうとしてるの？
何が便利になるの？

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

>>653
どっちにしろ出来上がったものはタスクを処理するシステムになる。意味がないもくそも
タスクシステムって名称を貶めたいだけだろうアホめ。

**名前は開発中のものです。** · 2009/01/19(月) 00:38:58

>>659
それが重要だよね

**名前は開発中のものです。** · 2009/01/19(月) 00:49:42

デザインパターンの本を読めばどう便利なのか書いてある

**名前は開発中のものです。** · 2009/01/19(月) 00:58:44

>>662
デザインパターン自体なにも利点のないものが入ってるし疑わしい
そもそもそれがゲームに適用できるのかどうかって検証も必要になると余計ややこしい
やっぱりたとえ話じゃなんの説明にもならないんだよ
説明する内容が複雑でその構造を説明するときにたとえ話はいいかも知れないけどね
この場合デザインパターンの例は役に立たないと思う

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

デザインパターンの使い方が判らんのか？

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

正確にはデザインパターンのゲームプログラムへの適用が適切がどうかわからない
デザインパターンはゲームの本じゃないからね
使ってる奴が間違った適用をしてたら意味ないし

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

なんでこのスレの人は抽象的な話しばっかするんだろう

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

ゲームプログラムとプログラムが違うと思ってる時点でへんな先入観を持っている。

デザインパターンのオブザーバーとストラテジーはまんまタスクシステムだよ。

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

オブザーバーとストラテジー？
両方とも目的と適用可能性の説明がゲームオブジェクトとかけ離れていて全く理解不能
どこがわからないとかじゃなくて共通箇所が欠片もみあたらない
パターン間違ってない？

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

いろんなオブジェクトにメッセージなげて処理してもらって
状況に応じてそれぞれのオブジェクトの中身が変わるんだろ？

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

>>667
デザパタを理解してないヤシは出てくんな。

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

オブザーバっていわゆるコールバックなんだぜ

こいつらがいっているタスクシステムにコールバックなんて単語でてきたか？