タスクシステム総合スレ 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/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

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

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

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

>>2はVSYNC信号をトリガーに循環リストの全要素・全ゲームオブジェクトを総ナメしてupdate() 関数を呼び出す
ここで注意が必要なのは「システム」を自称する>>2は何故か一本糞の循環リストしか持ってないっつーこと。
そしてVSYNC信号が発生する度に、相手の都合なんてお構いなしに、呼び出される必要があろうが無かろうが関係なく

　　　　　　　　　　　　　　【問答無用でとりあえず全てのゲームオブジェクトを叩き起こす】

「ねーVSYNC信号発生したよ？起きなさいよ。やることない？やることない？あるならやれよ早く。無いなら処理返せよ早くホラ」

これポーリング処理。一本糞リストしか持たない>>2がオブザーバ・パターンだとか言ってる時点で何かがおかしい

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

chain of responsibilityがタスクシステム(に使われている)と言うなら
まだほんの少しはわかるが、>>667 はただの馬鹿にしか見えない。

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

>>665
＞正確には

正確に言え。

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

どうやらデザパタはただのノイズだったようで

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

>>671
ttp://diary.imou.to/~AoiMoe/2008.12/early.html#2008.12.02_s01_p04
> ．タスクシステム - 私も検索してみたけど、タスクなんてご大層なもんではなくて単なる
> コールバックキューに見える。私のような GUI 屋とかはむしろこの手の仕組みは
> 自家薬籠中のもんで、タイムクリティカルじゃないことをやるには便利。実装は簡単そうに
> 見えて結構奥が深いので手を出さないのが無難。趣味のプログラミングとしては
> 実によい題材だけど。線形リストの奥深さを知れ。

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

引用して何がいいたいのかわからない
見えるなんて表現してる人の言葉使わずにデザパタからきっちり説明したまえ
第一そのリンク先の人の言葉なんて誰が保証してくれんの？

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

ちなみに別にデザパタを説明してほしいわけじゃなくて
なぜそのパターンがタスクシステムだと考えたのか？ってとこな
ま、それが説明できてもそのパターンの効果をみるとそれがタスクシステムの利点とイコールか？
って言われると全く見当違いな気がすんだけどな
俺の勘だけど

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

>>678
> タスクシステムの利点
詳しく

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

>>679
俺はアンチタスク派なんだけど
あえていうとごった煮で引数の同じ関数を一気に実行できるとこじゃね？
利点ていうと違うな
俺はこんなことしちゃいけない派

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

そうすると基底クラス関数よんじゃだめなの？とか言われそうだが
そうじゃなくて
本当は引数で渡すべき処理をグローバル変数やシングルトン使ってやりとりするのが駄目

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

ID:f259EVPA
ID:KNFisALs
ID:8MTRCkQM

・・・。ずーっと観察してるがやっぱグダグダだなお前
もう少しよく長考してから書き込めよ

＞デザインパターン自体なにも利点のないものが入ってるし疑わしい

ほう。kwsk。（どうせシングルトンのこと言ってるんだろう）

＞正確にはデザインパターンのゲームプログラムへの適用が適切がどうかわからない

素直に「デザパタ分かりませんので噛み砕いて説明してくださいお願いします」
って頭下げればいいんじゃないのお前

＞両方とも目的と適用可能性の説明がゲームオブジェクトとかけ離れていて全く理解不能
＞どこがわからないとかじゃなくて共通箇所が欠片もみあたらない

んー。イベントドリブンな仕組みを作るとオブザーバのようなものになるわけだが
>>2は搭載してないけどな。（ユーザーに丸投げてる）

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

まぁ、>>2におけるイベントといえるものはVSYNCくらいだな。これだけ。
ゲームオブジェクトにとっては全く足りない。

ゲームの基本プログラムはメッセージ駆動システムの体をなすことが多い。
衝突・タイマー・etcetc。システム側で提供することが望ましいものは沢山ある
>>2はなにひとつ提供しない。ユーザー側で実装することになる

ある時間に覚醒するジョブがあるとすると、ユーザーは毎フレーム呼び出される度に
自らグローバルタイマをチェックするか、自前のカウンタをデクリメントして時間が到来したか
チェックする。

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

むしろ、デザパタはお前>>682のが理解してないよ
だってオブザーバーの目的って
あるオブジェクトが状態を変えたときに、それに依存するすべてのオブジェクトに自動的にそのことが知らされ略
って奴だぜ
目的は本当にそれでいいの？
仕組みとコードだけ拾ってテキトーに適用したでしょ？違う？
そうでもないとこの適用はありえないよね？

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

>>684
>>2が一切サポートしない機能の話しになるからアレだが
指揮システムが必要なゲームはこんな感じになるよ。結果的にな

・中隊本部の信号弾（赤）を合図に状況開始
・班長の拳に注目セヨ。拳を振ったら停止・全周警戒

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

AIで動く敵軍にチート情報を与えるようなエンティティをマップに配置することもある
ゾーンアラームなど。プレイヤーが指定された範囲内に侵入すると
登録された敵分隊に警報が発令され、指定された戦術行動を取らせる
そのエリアのパトロールに向かわせる、など

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

威勢はいいが反応が悪いな。
上ではかなりジャンルが偏った例をあげたが似たような仕掛けは
いろんなゲームで登場する。特に後者のAI補助用のエンティティ。

まぁ、なんだ。【ありえない】とか簡単に言い切る前に長考しろってこと

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

http://www.nicovideo.jp/watch/sm2078250
3分30ぐらいまで見てると、タスクシステムが登場するぜｗｗｗ
（序盤音量とかいろいろ注意）

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

>>686
特殊な例あげて正当化しやがって(笑)
そもそもそれじゃそいうことしないオブジェクトに対しては全く意味ないってことでいいの？

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

いちいちageんなクズ共

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

携帯からだとsageっていれんの面倒なんだよもん

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

sの時点でsageが候補に出るおれの携帯って・・・

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

>>689
マップ上にセンサーを配置するのが特殊とな？
ゲームバランスをコントロールするために、あるいは演出のために
空間内にセンサーを配置する、という選択肢をレベルデザイナーに
与えるのは特殊とな？

んー、興味深いな。

キミはいつもどういう人数構成でどんなゲームを作ってるんだい？

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

マップの話なんかしてないよ
どうつながったのかしらないけど
頭おかしいんと違う？

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

>　　　　　　　『目的は本当にそれでいいの？』
>　　　　　　　『仕組みとコードだけ拾ってテキトーに適用したでしょ？違う？』
>　　　　　　　『そうでもないとこの適用はありえないよね？』

簡単にありえないとか言い切るってすごいね
視野狭窄で自己中で思考停止。病気じゃないの？

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

だけどデザパタのObserverの動機を読むと
ソースの記述だけ似てたから適用してみた感は強いな
デザパタの説明だとあくまでオブジェクト間の依存関係について説明してるのに
目的や動機を全く読まずに形だけ自分のソースに適用してしまった感はぬぐえない
これはデザパタをよく読んでみればわかる

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

うん。デザパタについての理解不足は当然あるだろうね
俺はデザパタ用語は自発的には使わない。専らヒアリング専門なんだ。
デザパタ用語を駆使する人とのコミュニケーションを成立させるための
リテラシーとして頭の片隅に置いてる程度。至らぬところは素直に
ごめんなさいする用意はある

さて、詳しそうな人が出てきたので質問してみますよ

>>696
お、そう見えますか…
前記したとおり、まぁ結果的に後付でオブザーバーなんじゃないのと感じただけで
GoFのデザパタありきで仕事するほどの大した者じゃあございません。
手元にデザパタ本があるので念のため再読しておりますが
動機も含めて符号していると理解しているのでもう少し具体的に説明しますよ

センサー（Subject）は、登録されてるゲームオブジェクト(Observer)に
【俺の縄張りに何かが入ってきた】を通知するだけの存在です
そのイベントに対する具体的な行動（処理）は登録されている
各ゲームオブジェクトに委ねられております

Observerが地雷原のコントローラであれば、これが起爆のトリガーになります。
野鳥の群れ（のリーダー）であれば、驚いて飛び立ちます。
前記した歩兵部隊の分隊であれば、分隊長(Observer)が各班長に具体的な
行動を指示します。

このようにリスナーは多様です