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

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

**名前は開発中のものです。** · 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
はぁ？なんのための必要悪なの？
そもそもベタ書きでゲーム作ったことあるのかすら怪しいね
だってゲーム作って複雑になるところとキャスト云々って全然関係無いもん