タスクシステム総合スレ 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/07(水) 00:21:50

その共通部分を抽出したものがタスクシステムだと思っていたんだが・・・

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

>>458
残念だがそのシナリオを選択する（orデカイ声で叫ぶ）のは遅すぎだな。というか無理がありすぎるな

>>2（特にLogicianLord。拡散の元凶）と>>2を誤読したゲッベルス（松浦大先生。拡散させた偉大な男）
およびその忠実な部下（熱烈な読者）は、パンピー(neutralな人)たちに対して、奇妙なまでに一致した
偏った「とあるヘンテコリン実装」でもってタスクシステム（？）なるものを解説しネット・雑誌・書籍で
流布した。流布し尽くした。2009年現在、ネット上で>>458説を提唱するのは完全に手遅れといえる

タスクシステムという言葉は>>2に代表される、極めて特徴的な、奇異なまでに一致したヘンテコリン実装

　　　　　　　「TCBがプライオリティをサブルーチンアドレスでディスパッチなのです＞＜」

と完全に癒着している。もう引き剥がせない。OoOやマルチコアプロセッサの普及により>>2の実装が
obsoleteといえるならば、タスクシステムという呼称もまたこの味噌が付いた実装と共に成仏することになる

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

ところで次スレからは書籍もテンプレに入れようぜ、戦犯としてw
Cマガ2004/12「ゲームのためのタスクシステム」松浦
単行本「シューティングゲームプログラミング」松浦
「Windowsプロフェッショナルゲームプログラミング2」やね

これだけ？

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

>>459
じゃあ実際はどんなのが使われてるのか教えてください。
まったく違うものなんですか？
オブジェクトの種類ごとに持つデータが違うとか、
オブジェクトのデータのメモリ管理方法が違うとか、単一のリストじゃないとか、
そんなのは違いのうちに入らないと思うよ。

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

>>459
オイ、コラァ！
「ヘンテコリン」はお前とお前のキチガイじみた駄文だろーが
やたら人を見下した態度をとっているが、具体的論理展開は全く無し。
典型的なチキンだな。

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

>>457
シーン遷移とシーン管理。
あれはひとつクラス作って使い方を決めときゃどんなゲームでも鉄板では？

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

>>461
> じゃあ実際はどんなのが使われてるのか教えてください。
過去ログぐらい嫁

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

上で議論した気にってるやつはC++を使いこなせてない。
不必要に全部のオブジェクトを１個のリストに乗せる必要もない。

Cとは縁を切るところからはじめるんだ。

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

ただの倉庫ならどう作っても同じ
俺たちが作りたいのは電動車庫なんだ

ボタンを押せば欲しいものが出てくる仕組み
Javaではリスナー、Cではタスクシステム、C++ならコンテナ、DelphiならTList
みんな完璧じゃないけど一工夫してある

ただの線形リストとタスクシステムの違いはデータにメッセージを送ると能動的に処理が走ること
プログラム側からデータを触ってやらないといけない線形リストだとデータがグローバル変数と
同じように扱われ保守性が落ちる

タスクリストはただの線形リストではない

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

>>464
過去ログ読んでも同じような煽りしか無いじゃないかw

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

>>466
ただの線形リストでも要素がクラスインスタンスなら、その「タスクシステムの違い」ってのは
無くなるね。

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

>>466
何言ってるかわかんない
結局ありがちなごった煮リストなんだろ？
違いをもたせるなよ(笑)

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

>>469
おまえはまずデザパタとエフェクティブC++を読め。

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

>>470
やだよ
そんなの役に立たないもん

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

ニートは金ないから本薦めるても無駄

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

デザパタは結城浩さんのがわかりやすくていいな

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

デザパタ自体俺の理論と合わない
ああいうごちゃごちゃしたソース組んで悦に浸ってるのは下手っぴ

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

開発遅延中のAチーム（古参と愉快な仲間達）の応援要員としてマスターアップ直後の我々Bチームに
声がかかった。ババを引いたBチームのプログラマ2名（メインとサブ（私））はションボリしながら
Aチームのサブプログラマから具体的な状況説明を受けている。開発の終盤になって再現性に乏しい
メモリ破壊系のバグに悩まされてるのだという

Aチームの仲良し古参二人組（ディレクターとメインプログラマ）は現在、開発の遅延に業を煮やした
営業部長に呼び出されて会議室でコッテリ絞られている

Bﾒｲﾝ：　「全オブジェクトのヘッダにTCBとかいう管理領域があるな。前後ノードのアドレスに
　　　　　　プライオリティに関数ポインタ、と…。呼び出される関数はreturnする前に管理領域の
　　　　　　　関数ポインタを書き換えてるな。この関数群は人力で分割したジョブステップだな…すごい数だ」
私　　.：　「ええ…」

そこへAチームの古参2名が戻ってきた

Aﾒｲﾝ：　『使いたいか！テツオ（Bチームのメインプログラマ）！』
Bﾒｲﾝ：　「あ、どうも。使いたいも何も、もはやこれでいくしかないでしょう」
Aﾒｲﾝ：　『俺用に改良したタスクシステムだ、ピーキー過ぎてお前ら（Bチーム）には無理だよ！』
B全員：　('-`)｡oO（こんなの使ってるほうが気が知れないよ）
Bﾒｲﾝ：　「ところで、このオブジェクト群を呼び出してるモニタ側のソースも見せてもらえますか。」
Aﾒｲﾝ：　『ははっ！欲しけりゃな。お前もデカイのひとつ分捕りな！』
Bﾒｲﾝ：　「あ、いや、我々は社長の指示でこちらに来てます。休暇返上で急遽編入されました」
Aﾒｲﾝ：　『そんな話は聞いてないぞ！・・・くっ・・・しょうがない、これだよホレ！』
Bﾒｲﾝ：　「あの、僕のforeach一行じゃなくてその、モニタデバッガライブラリはどこですか。
　　　　　　つまりその、状況を監視・可視化してくれるツール群とかあるのでしょう？」
Aﾒｲﾝ：　『そんなもんねーよ！やっとモーターのコイルが暖まってきたところだぜ。デバッグ続けるぞお前等！』
Aｽﾀｯﾌ：　『オーッ！』『ダーッ！』
B全員：　('A`)｡oO（・・・）

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

>>475←こいつＮＧ余裕でした

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

>>466
コードで語ってくれ

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

た

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

す

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

け

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

な

**名前は開発中のものです。** · 2009/01/10(土) 22:56:42

ん！？

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

>>471
読まずに役に立たないだと？

EffectiveC++が役に立たないというならおまえがC++をまったく
使えてないか完全に仕様を理解しているのどちらかでしかない。

C++を理解してデザパタイランというなら頭おかしい。
そのまま流用する必要は無いが、似たようなものを作ることになるのは目に見えてる。

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

>>483
>EffectiveC++が役に立たないというならおまえがC++をまったく
>C++を理解してデザパタイランというなら頭おかしい
これ好きな人ってだいたいセットで好きだよね

ただ、毎回「これ駄目っていう奴は馬鹿」みたいな雰囲気あるから言わなかったけど
正直、これ何がいいの？って思うようになった

俺もはじめの頃はＣ言語勉強してそのままＣ＋＋に来て
仕事でＣ＋＋で組んでるけど正直、クラスのメリットってよくわかんないんだよね

っていうかよくわからなくなった
ちなみにプログラム経験１２～１３年
Ｃ言語とＣ＋＋では仕事ではＣ＋＋しか使ったことない

>C++を理解してデザパタイランというなら頭おかしい
そうか？
具体的に何がいいの？
俺は実際に使いたがる奴の行動見てたけど
なんでそんな無駄な構造にしたのか上司と衝突ばっかり起こしてて苦労が多そうな奴だなと思った

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

ダメなやつが使ってるからダメとかいったら何も残らないじゃない。
C言語ではダメなやつは苦労してないの？

どう使えばよいか判らないといってると理解したけども、それでいいのかな？

ユーザーがアクセスできない関数や変数を構造体にもてるだけでも十分メリットだと思うけど。
仕事で頼まれているモノはそうやって制限されてない？　使う側の工夫って使われる側には
見えないものなのよね。

**名前は開発中のものです。** · 2009/01/11(日) 00:05:02

あ、でもイラネって言ってるやつに無理に使ってもらう言語でもないな。
アセンブラに慣れてたら、Cを覚える必要ないわ。

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

>>485-486
なんの説明もしてないの自分でわかるよね？
他の奴等もだいたいこんな感じで逃げる
それかわけのわからんリンク貼って終了

書籍読んでもこれがこうよくなるって言ってもそのメリットがメリットに感じないし
C言語で書いたソースとC++で書いたソースを比べると
意外とC言語で書いたソースのほうがよく見えたりするよ
ていうかほとんどの場合、大して変わらない

**名前は開発中のものです。** · 2009/01/11(日) 00:49:50

それはどういう分野のソフトウェアを作ってるかによる。
例えばコールバックを多用するフレームワークを扱う場合はCでは面倒すぎる。
しかし昨今のコンシューマゲームでさえC++で開発が当たり前だ。
多分問題はオブジェクト指向原理主義的な野郎がいるってことだろう。

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

>>486
アクセス制限とデザパタとは関係ないような。
簡単に構造が説明できる(直感的に理解出来る)、非常に良く使われる構造である、統一的に機能を追加できる(またはそのようにする、そして楽)
のうち最低でもいずれかが実現できてることがデザパタの意義・・・かな？
逆に、これがどれも実現できてないのにデザパタ使いました、では
たとえパターンの構造通りになっていたり、また適切にアクセス制限がされていても本質からずれてる。

>>484の>なんでそんな無駄な構造にしたのか上司と衝突ばっかり起こしてて苦労が多そうな奴だなと思った
ってのもなんか多そう。中途半端に理解したデザパタは一番の害悪。果たして他人にぱっと説明できるのかと。

と、中途半端にデザパタを読んだ自分が言ってみる。

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

デザパタか
strategy?　ああ、lambdaと高階関数に珍妙な名前つけた奴ね
って奴にはまあ要らねーのかもな

Cは面倒くさいだろ流石に
と思うが、C++はC++で別の意味で面倒くさいんだよな
大して表現力ねーくせに無駄に複雑でな

**名前は開発中のものです。** · 2009/01/11(日) 09:05:10

>>466
流用性の無い足手まといイベントハンドラが増えただけにしか見えない。
あと戻り値はグローバル変数で渡すの？

//もともと必要な処理（ゲームオブジェクトクラス１個分）
class PlayerCharacter {
public:
　　bool init(const Chara_t *);
　　void update_frame(const Key_t *);
　　Point_t get_position(void);
　　CharaType_e get_charatype(void);
　　void release(void);
};

//以下タスクシステム用追加記述
typedef struct {
　　EventType_e type;
　　union {
　　　　Chara_t *init;
　　　　Key_t *update;
　　};
} Event_t;
typedef enum {
　　EVT_INIT,
　　EVT_UPDATE,
　　EVT_GETPOS,
　　EVT_GETCHARATYPE,
　　EVT_RELEASE,
} EventType_e;

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

自分はいわゆるタスクシステムがどんな構造なのかよくわからんので色々気になったので読んでみた。
>>2のサイト先だと単なる動的配列(リスト構造)。別に『優先順位つきリスト構造』で説明が事足りる。
(全体長を固定する・またはノード自体をnewすることストを抑えたいならリスト構造2つ。事実上メモリ監視がついて回るのでこうなるが。)
で、色々読んでるといわゆるタスクシステムでは構造自体が重要なのではなく、メモリ使用の監視が主題ってのはなんとなくわかった。
だからメモリ監視にかかわる構造が必要でリスト構造に比べ多少複雑になってる、と。

つまりタスクシステムは

・ゲームを管理する構造△
・メモリの使用量など監視する構造○

タスクシステム自体の話は以上で完結するのよね。

タスク同士間の情報のやり取りやイベントハンドラ云々ってのはタスクシステム自体の話じゃなくて、
リスト構造で管理したときそれぞれのノード間のやりとりをどう管理するかって話でしょ？ふと思った。

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

仮にタスクシステムの主題がメモリ管理だとして、じゃあタスクシステムから主題じゃないはずのタスクの概念を取り除いたら後に残ったものは果たしてタスクシステム？
メモリ管理システムでは？

メモリ単位管理システムと処理単位管理システムがもともと癒着しているタスクシステムというものを選択した時点で、既にタスクとかノードという概念の使用を選択したことになっている。
ノードという概念の使用を強制されるならノード間のやりとりをどう管理するかの検討も必須の話かなぁとか。

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

>>493
もちろん。
ただ、どうもこのスレはタスクシステムのどこの仕様決まりきってて、決まりきってないどこを議論すべきなのかが混沌としてるから。

例えばこのスレでもずっとタスクシステムはリスト構造じゃねぇ、という意見が殆どを占めていて俺リスト乙。的な流れが多い。
確かにタスクシステムはリスト構造ではない、は正しいが、
ノード間のやり取りを議論しようとしたら、リスト構造を踏まえて、というかハードを意識しなければリスト構造なのでそこで語るのは正解。
つまりその手の話は俺リストの話をするべき。

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

>>494
「ノード間のやり取りを議論しようとするならその前にまずは俺リストの話をするべき。」
と受け取ったけど、ノードから見た通信インタフェースなんて
　　1.グローバル変数直接アクセス
　　2.メッセージングとかイベントハンドラ的な仕組み
　　3.move, update, drawなど数を絞った仮想関数インタフェース
の3つ位しか思いつかない。しかも2, 3は表現が違うだけでやってることは等価だと思うので実質1もしくは2・3の２種類のみ。
グローバル変数を使用禁止とするなら2・3の手法一択。

乱暴に言えば、タスクシステムの意義は2・3をゲームオブジェクト単位に導入することを強制する意義と等価だとして話を絞ってしまえば
どのようななんちゃって俺タスクシステム・俺リストを使っていようが全く関係無く話できると思う。っていうか話終わると思う。
もっとおおざっぱに行こうじぇ

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

だよなぁ・・・。
うちら2人だけじゃいまいち不安だが、タスクシステムに関することってそんな感じだよね。

・タスクシステムはメモリ管理機能のある優先順位つきリスト構造
→メモリ管理およびリスト構造自体は決まりきった構造なので議論の余地なし。
→リスト構造のノード間のやり取りもメソッド等の使用であることは自明。

となるとかなりの部分はソースコードとして確定できそう。

で、まだでてきてない部分はこんなところか。
・具体的なメソッドややり取りはどのように管理するべきか。
煮詰めりゃ最適解は出せそう。

・タスクは別のタスクを追加しうる。生成したタスクはどうリスト構造に渡すか。
1、処理関数の戻り値として。追加の仕方はリスト構造自体を処理している誰かに委ねる。
2_A、リスト構造をタスク内でフィールドで保持。
2_B、処理関数がリスト構造自体を引数にとって内部で処理。
まぁ、2_Bが好きです、私は。

・タスクは例えばどんな塊なのか、どんなインタフェースを持つべきなのか。
これは色々考えられそう。
シーン管理はリスト構造の外側でしてるとして、他は全部リスト構造内で処理していると思いたい。優先順位機能搭載してるわけだし。
こっちも煮詰めりゃある程度解がでそう。

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

いや、普通に C++ で仮想関数とコンテナ使って組めって。
もっと言うと、コンテナにする必要だって常にあるわけじゃない。
普通にメンバに持ってれば十分、っていうかそっちのほうがわかりやすいこともあるだろ。

そうでないなら、「タスクシステム」とやらで解決される問題を挙げてから話してくれないか？

**名前は開発中のものです。** · 2009/01/12(月) 00:34:41

>>496
俺はタスクシステムやめとけ派
タスク化をゲームオブジェクト単位に導入することを強制する意義は無いと思う。
メソッドの数を絞らなきゃいけないのがきつい。その最大最悪の制約の解消の目処も立ってないうちから
他の特徴を生かす方向を先に検討するとかは順序が違うと思う。

メモリ管理が重要じゃなくなったのならタスクシステムやめてそれ以前に戻るとか、
タスク化の適用対象をゲームオブジェクト以外にするとどうなるかとか考えて、まずは最大の制約を取り除くのが先じゃない？
ここがダメなら他の機能の利点なんて全部ふっとぶ凶悪な制約だと思うよ＞通信の抽象化＆全体共通化強制

例えばフレームワークの内部実装だけに適用する。
例えばもっとたくさん、座標管理（なんちゃって）タスクシステム、当たり判定管理（なんちゃって）タスクシステム、UI管理（なんちゃって）タスクシステム、...を作って組み合わせる。
例えばシーンと呼ばれる枠組みだけに適用してみるなどなど考えてくと、タスクシステムという形を残す必然性がなくなった。俺の場合。

**名前は開発中のものです。** · 2009/01/12(月) 02:16:26

というかC++はタスクシステムをさらに豪華にしたものだからC++を極めろ。

**名前は開発中のものです。** · 2009/01/12(月) 03:55:30

>>498
タスクを管理するクラスからの呼び出しだけ同じにしておけば、
別にメソッドの数を絞る必要はないと思うけど。

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

一番シンプルな形がいわゆるタスクシステムで、
それをそのまま使ってる人はいないんじゃないの？

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

>>498,501見たいな流れに持ってくから話題がループするんだろ

>>498
色々勘違いしてるし、いってる意味がわからん部分がある。
1、タスクシステムの是非についてまったく話していない。結局タスクシステムの定番の形がどんな形なのかというのが知りたい。まだ定番の形は決定できる部分があるだろう。
2、順序が違う周りは何がどう違うのかさっぱりわからない。少なくともoopの設計の仕方ならば、オブジェクトを先になんとなくまとめ、メッセージを決めていくのもありなのだが。
それともいきなりソースコードレベルでびしっと決めるつもりだろうか？
3、ゲームオブジェクトでは抽象的過ぎる。それに含まれる具体例が最低3つぐらいあげてほしい。この定義により恐ろしいほど処理の範疇が変わる。
4、メモリ管理周りの話。何度もいうように、リスト構造のやり取りについて語ってる。タスクシステムについて語っていないと思う。まぁこちらの言い方も悪かったか。

それはそうとして、最後の話の構造、あれ思ったより拡張性低くね？仕様変更に迫られたときに耐えられないべ。
本来プログラムの構造はマトリョーシカ状にして、設計の修正が必要な場合の修正項目を最小限に抑えるべきだと思うんだが、ありゃ管理クラスが色々やりすぎてる気がする。

>>500
よくやる。つまりnode.run()みたいに一枚はさんでから、具体的な処理構造を実行するってことか。

>>501
多分この意見もかなりこのスレの流れでループしてるんじゃ無かろうか。だからもう少し話を進めて確定したい。

**名前は開発中のものです。** · 2009/01/12(月) 20:03:59

ID:JZO5iyFx ＝ ID:YXD0YS+N　　なのか？なんか至る所がおかしいな

>>492
＞>>2のサイト先だと単なる動的配列(リスト構造)

どこが動的配列なのか分からない。インターフェースも実装も動的配列ではない。

＞構造自体が重要なのではなく、メモリ使用の監視が主題ってのはなんとなくわかった。
＞だからメモリ監視にかかわる構造が必要でリスト構造に比べ多少複雑になってる、と。

悪いが意味が分からない。何を読んでその結論に至ったのか、アンカーを全部列挙してくれ

＞つまりタスクシステムは
＞
＞・ゲームを管理する構造△
＞・メモリの使用量など監視する構造○
＞
＞タスクシステム自体の話は以上で完結するのよね。

ならばそれはただのメモリプールでありアロケータの一種であり、それ以上でもそれ以下でもなく
タスクシステムなどと名乗る理由は微塵もないわけだから、お前は速やかにタスクシステムという
呼称を使うのをやめたらどうなのか。なぜタスクシステムという何処の馬の骨かも分からない田舎侍の
ローカル用語に固執するのか理解できない

**名前は開発中のものです。** · 2009/01/12(月) 20:27:55

>>492
＞タスク同士間の情報のやり取りやイベントハンドラ云々ってのはタスクシステム自体の話じゃなくて、
＞リスト構造で管理したときそれぞれのノード間のやりとりをどう管理するかって話でしょ？ふと思った

悪いが何を言ってるのか全く意味が分からない。

マルチタスクシステムにおいてはタスクとはジョブステップでありシステム内部の処理単位だ。
「システム内部の処理単位」同士の通信手段が提供するのはマルチタスクシステムにおいては当然のこと。

にもかかわらずタスクシステムとかいうものにおいては
「それは関係ないから関係ないからタスクシステム自体の話じゃないから」という。全部ユーザーに丸投げか。
ならばなんなのそれは。ってことだな。ジョブエントリのリストをなめてディスパッチしていく。ただの順次処理、
バッチ処理するだけの仕組み。それだけ。後は全部ユーザーまかせ

　　　【タスクシステム自体の話は以上で完結するのよね】

**名前は開発中のものです。** · 2009/01/12(月) 20:37:00

>>493
＞ただ、どうもこのスレはタスクシステムのどこの仕様決まりきってて、決まりきってないどこを議論すべきなのかが混沌としてるから。

だから>>2だろ。書籍なら逆引き本だろ。現場を経験した人間が解説してる唯一の文献だ。

＞例えばこのスレでもずっとタスクシステムはリスト構造じゃねぇ、という意見が殆どを占めていて
＞確かにタスクシステムはリスト構造ではない、は正しいが、

どこをどう見ても>>2が使ってるのはintrusiveな（侵入式の、内部収納の）連結リストだが
リスト構造じゃねぇとかほざいてる知的障害のアンカー全部列挙してくれ

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

それでいいんじゃないの？
そもそもタスクシステムが何のために出てきたのか、目的がなんなのかで話がぜんぜん異なる。

**名前は開発中のものです。** · 2009/01/12(月) 20:47:23

×>>493
○>>494

＞ノード間のやり取りを議論しようとしたら、リスト構造を踏まえて、というかハードを意識しなければリスト構造なのでそこで語るのは正解。
＞つまりその手の話は俺リストの話をするべき。

ハードを意識するも糞も何も>>2も逆引き本も連結リスト使ってるだろ。
正解も何も連結リストでしか語ってねーよ。馬鹿みたいに何でもかんでも線形リスト。木もグラフもない。
連結リストを使ってないタスクシステムに関する資料、文献がどこにあるのか教えてくれ

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

>>496
＞・タスクシステムはメモリ管理機能のある優先順位つきリスト構造
＞→メモリ管理およびリスト構造自体は決まりきった構造なので議論の余地なし。
＞→リスト構造のノード間のやり取りもメソッド等の使用であることは自明。
＞
＞となるとかなりの部分はソースコードとして確定できそう。

【メモリ管理機能のある優先順位つきリスト構造】

それが現代のビデオゲームの中核部として【自己主張する】に相応しいメカニズムだと思う？
そういうものにタスクシステムって名前は釣り合うと思う？名は体を成してると思う？
そもそも名前が致命的に腐ってると思わない？タスク-システムだよ？
仕事システム？システム内部の処理単位システム？ハァ？って感じだよな
マルチでもなければシングルでもない。何なのお前？何がしたいの？って感じしない？

ワークロードをモニターできないしデッドラインに間に合うようにスケジューリングする仕組みもない
ゴミだろ。

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

>>496
＞・具体的なメソッドややり取りはどのように管理するべきか。
＞煮詰めりゃ最適解は出せそう。

おそらく出ない。タスクシステムが常に敗北するのは、あらゆる粒度の処理に対して同じインターフェースどころか
同じ実装でもって全て解決してしまおうとする、極めて理想主義・原理主義的なアホ共の玩具に成り下がったことに
由来する。処理の粒度に応じて解は異なるということに気づかない限り、ハードを無視した机上の議論で終わる

例えば細粒度な処理をディスパッチするためにタスク厨はなぜかサブルーチンアドレス経由で処理を呼ぶ。
現代においてはちょっと珍しい発想だ。本来ならステートメントを使うべきでありこれはif文やswitch-case文。
タスク厨が完全に時代に乗り遅れたフェードアウトオヤジ状態であることが完全確実に決定的なのは
関数アドレス経由の関数呼び出しが常に最高に速いと思い込んでることだ

一事が万事、それ以外のことも8bitマイコン時代の常識を現代に適用とするはず

ところでOO厨とタスク厨の親和性が極めて高いというのも面白いよね。静的型付け言語のセオリーをまっこうから
否定する>>2を、OO厨は「斬新だ」と感じるらしい。理解できない世界だよね

**名前は開発中のものです。** · 2009/01/12(月) 21:41:05

>>504
こっちも話の進め方が悪かったけど、まったくといっていいほどこっちのいいたい事、主題にしたいことが伝わってないことはわかる。
俺説明下手かなぁ・・・。

とりあえず技術的な部分だけ。

・動的配列は、要素数が自由に変更できる配列である。リスト構造は動的配列とみなせる。と思ってるが。
・メモリ云々に関して。>>2の4番目のサイトとか?つまり当時クラスを使用しない実装において、ワークエリア固定は、ただの副産物だったのか。ということ。

他は、まぁ読み返してこっちがいいたかったことを察してくれ、多分それで解決する。めんどい。

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

>>509
そこに誰もがうすうす感じてるから進まないんだろう、話が。
あらゆる処理、をかなり狭めることで最適解というか妥協解は示せると思うよ。

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

>>510
動的配列を実装する選択肢のひとつは連結リストを使うこと
だが、>>2のインターフェースは動的配列ではない。

リストだが動的配列ではない

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

タスクシステムという言葉を使い続ける限り、そいつの背後には>>2に代表される
時代錯誤的なヘッポコプログラムの影が常に付きまとう。これはもはや不可避だ
このレッテル貼りを早い段階から否定しなかった「タスクシステム大好き人間」の
落ち度だ。（おそらく彼らは>>2が現実と乖離してるということに気づいていなかった）

>>2から脱却した議論がしたいならタスクシステムという言葉を使うのをやめ
このスレを使うのをやめるべきだ。構造スレなら俺も別人になれる

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

>>512補足
実装においても、当時のハードウェア構成から固定長メモリプールが多用された
ゆえに実装レベルでも動的配列とはいえない。ヒープという概念がないRAMちょびっとの
ハードで動的配列を提供することに意味はないし、>>2もやってない

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

>>496
＞まぁ、2_Bが好きです、私は。

それは構わない。
が、システムと銘打ってるにも関わらず、ユーザーにシステム側の実装を周知しなければならない。
つまりユーザーは、自分が記述したジョブをシステム内部の処理単位であるタスクなるものに分割し
それが格納されるシステム内部のコンテナが連結リストであることを知る必要があり、更にそれを
直接に操作することを強要される

2_Bなら、システムが提供するのはintrusiveな連結リストのコンテナだけであり、後の全ては
ユーザーの創意工夫で構築される。「俺はシステムだ！」と主張させるには無理がある

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

>>500
絞る必要は無いんだけど、結果的に意図せずとも数絞っちゃうというか。
メソッド変更の度に全タスク修正するの面倒になってそのうち必要最小限でいいやとか思い始める。
「update(), draw()だけあればいいや。おっなんか洗練された感じ？」とか。で1～3つ位に絞られる。

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

>>516
非常に的を射ているような気がする

無理になんでもかんでも共用し一般化しようとする結果、肉も骨も削る人間がいる。
直行性だの何だのは結構なのだが、それを過剰に追求するからおかしくなる。
肉も骨も削って何がなんだか分からなくなったものを作り上げた人間は
>>2にシンパシーを感じ、これを愛するのではないか

「俺は間違ってない！過去のナ○コの偉大なプログラマーも俺と同じことやってる！」

いいえ、それは違います。ということは今更指摘するまでもないよな

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

それはクラスに型があるが故の制限だろ？
タスクシステムに責任を押し付ける筋合いの物じゃないと思うが……。
クラスでやるにしてもEventListener interface風に実装する等回避策はある。
（タスクシステムはクラスと違って記憶領域と関数が1対1で対応する必要もないし）

どうも副次的な制限ばかりでタスクシステムの本題に入らないな。
行き当たりばったりに実装してみて行き詰ったら「タスクシステムが悪い」となっている風に見える。

タスクシステムは何をするべきか、何をさせるべきか。
それをキッチリ決めてからじゃないと
実装してから利点を探すような真似は生産的じゃないと思うんだぜ？

タスク管理の実装に必要なものは
・
・
・
だから～という実装は有効

みたいにしようぜ
必要は発明の母っていうし新タスクシステム開発できたら素敵やん？

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

ところでDOOMやQUAKE等一線級のゲームソースがオープンソースとして公開されているけど
タスク管理はどのような実装になっているんだぜ？

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

>>518
2009年現在、ネット上ではタスクシステムというキーワードは>>2に代表される
珍妙実装と絡み合ってる。実装ありきだ。これを今更否定するのは至難だと思うよ

彼らは何故か2DSTGで、通常弾も敵も何もかも全部同じリストにぶち込んで舐める。

否定するならば、Cマガジンで松浦大先生（タスクシステムエヴァンジェリスト）が
下々の民草に対して「プロのゲームプログラマはこうやってるのぜ！」と絶叫した
（2001年だっけ？）時点で、大々的に反抗作戦を展開するべきだったな

**名前は開発中のものです。** · 2009/01/12(月) 23:10:15

>>520
当時は「なんだこいつ馬鹿じゃね? こんなの誰も信じねーよ」と思ってて
こんなに厨が拡大再生産されるとは微塵も思ってなかったんだ…

**名前は開発中のものです。** · 2009/01/12(月) 23:11:20

>>502
1.タスクシステムの是非＝タスク化をゲームオブジェクト単位に導入することを強制することの是非
　ちょっと分かりにくいか。
　タスクシステムの是非＝既定のメソッド2～3個だけしかゲームオブジェクトに使用できない呪いを自らに課す是非
　でも可。１クラス決まった型のメソッド３個までしか使えないんだよ？極悪すぐる。この１点を問題ないと言い切れるならもう習うより慣れろかもね。
　後付けだけど条件。グローバル変数は無し。引数で全変数一気渡しも無し。
2.見た目がどんなにおいしいそうなものでも、腐ってたら食べないでしょ？
　その腐ってる点を指摘したつもり。どれだけあなたがおいしいところの話をしようよといっても腐ってると分かってる人はそんな気になれない。
　どうせ食べたら腹壊すって分かってて無駄だから。ふぐの毒に置き換えてもいい。
　それでもそのおいしそうなものについて議論したいならまずは腐ってるとこを取り除く努力をして安全性をアピールするのが先。おいしいとこ議論はその後、の順の方が人が集まりやすい。
　>少なくともoopの設計の仕方ならば、オブジェクトを先になんとなくまとめ、メッセージを決めていくのもありなのだが。
　タスク、リスト構造のやり取り等を先になんとなく以上の熱意で明確化しようとしている矛盾
3.STGで言えば自機、敵機、自機弾、敵機弾、ボス、背景オブジェクト、...
　ミニゲーム１つでいいから作ってみると、なるほど使ってみたくなる言葉
4. >>504 さんの言う通り

>本来プログラムの構造はマトリョーシカ状にして、
外から３番目の人形と８番目、あっ違った、今は９番目の人形同士で情報やりとりしたいんだ。
ってデザイナーに言われたらどうするの？　4-8番目の人形に専用のメソッド用意して穴あけるの？　グローバル変数で空間ワープするの？　いや、この設計では無理って言うの？
ライブラリラッパー関数までだよ、それは。俺はシーンクラスに色々やらせる方がかっこいいと思う。ダサかっこいい。昔ながらのKISS.

説明下手は少しあるけどまぁ伝わる。それよりも聞き下手。
察した上でそれを主題にすべきでないと理由付きで伝えてくれてる親切な人だらけだよ。今日は。人多いっしょ？　俺もびっくりだこれ。
多分それ気づかないと解決しない。

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

>>516
えーと、俺が言いたいのは、管理クラスから呼ばれるメソッドさえ共通にしておけば、
それぞれのクラス毎に、それぞれのクラス特有のメソッドを追加しても問題ないってことなんだけど。
１つのクラスに修正が生じたからといって、全てのクラスを修正する必要はないよ。

**名前は開発中のものです。** · 2009/01/12(月) 23:24:44

現状は>>498が言うことがすべてだよなぁ
折角わかりやすいのに>>502の的外れな指摘がなーんか嫌な感じだよ
意味がわからない
お前の言ってることのが意味分からないよ
ほぼ共通してる認識をわざとはぐらかしてる

**名前は開発中のものです。** · 2009/01/12(月) 23:28:36

>>523
ごった煮状態のインスタンスの型をどうやって判別する気？

**名前は開発中のものです。** · 2009/01/12(月) 23:42:16

ダウンキャストか型タグでしょ

**名前は開発中のものです。** · 2009/01/12(月) 23:43:05

×ダウンキャスト
○dynamic_cast<>
ね、すまん

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

>>512,514
把握。でもリスト長は変わってるから動的配列と呼べなくも無いと思うが・・・まぁどうでもいいや。重要ではない。

ところでa2k+/ICzよ、自分でいってるじゃないか。

>>513で。当時制限があった、ゆえにメモリ管理が必要だった。それがタスクシステムだ。時代錯誤だ。
だから『タスクシステムの主題がメモリ管理』は外れちゃいないと思う。

>>515で。タスクシステムからメモリ管理を取り除いたら、リスト構造しか残らない。タスクシステム特有の部分は議論する余地がない。
だから俺リストについて語るべきなんじゃん。

>>520で。結局タスクシステムって言葉を使い続ける限り、メモリ管理＋リスト構造しないとだめなんだよ。
だからその片割れであるリスト構造について語ろうっていってるわけだよ。
(まー自分がゲーム作る場合、メモリ管理とかいらんからほんとにリスト構造だけだけど。利用できそうな方向に話を持っていきたいだけ。)

ごめんなさい、結論としては具体的なノードのやり取りとか、どんな処理がノードとなるのか、とかそんな話がしたかっただけです。

**名前は開発中のものです。** · 2009/01/12(月) 23:49:34

>>525
最初から、必要とするクラスのメンバ変数にしておけばいい。
一旦抽象化してリストに入れたものを取り出して型を判別する必要はないと思う。
まあ、管理クラスに探してもらってdynamic_castでもいいけど。

**名前は開発中のものです。** · 2009/01/12(月) 23:49:39

というかa2k+/ICzの言うタスク厨ってここにいるの？
いないもの相手に頑張っても意味ないよ

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

読むのが追いつかん・・・
>>522
>聞き下手。あぁ理解。>>524のその通り。ごめんなさい。今度から何度かちゃんと読み直します。
となると、話の流れは>>498から>>523とつながってるのか。

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

495と498もつながってるから466からじゃね？
9uopTdxyとT/lMy2Wwは俺

**497** · 2009/01/13(火) 00:21:26

いわんこっちゃない。
大事なことだからもっかい言うぜ。

「タスクシステム」とやらで解決される問題を挙げてから話してくれないか？

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

>>529
リストでも配列でもいいけど
それが何か判別できなきゃ処理できないじゃん

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

>>533
何もないな
updateとかdrawをまとめて呼びたいとかその程度のくだらない仕組み

解決される問題はupdateとかdrawをゲームオブジェクトごとに書かなくて済むただそれだけ

**名前は開発中のものです。** · 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

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