タスクシステム総合スレ 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/05(月) 03:19:03

あ、クズの所業ってのは>>2の各URLの中の人のことじゃないからな
そこで解説されてる手法（？）を祀り上げてるカルト信者のことな

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

×HSYNC毎に
○ライン毎に

**名前は開発中のものです。** · 2009/01/05(月) 08:26:50

>>432
>大昔に興味本位で測定した。AMDのAthlonXP（Bartonコア）で>>2を使うと速度は半分になった
面白いですね。比較対象ってどんな組み方のものですか？

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

いまどきのオブジェクト指向のメッセージ処理で多用される間接ジャンプを、
現代のプロセッサでは性能が出ないとか扱き下ろしている人がいるのは
このスレですか？

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

制御対象の計算粒度と数の特性ゆえに>>2は不利となる
パフォーマンスアナライザやプロファイラを使わず現実を見ずに先入観のみで
>>2はきっと良いに違いないと盲信するならエンジニアではない
エセ科学信仰とかカルト信仰に溺れる知的弱者だ

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

>>431
①か②を採用するかは
ゲームによって臨機応変に対処すればいいんじゃないかな
どちらか絶対という事はないと思う
弾幕シューティングなどは明らかに後者が適していると思う
自分が最近作ったゲームはシーン（メニュー、コンフィグ、ゲームプレイなど）すら
オブジェクト化した①を採用してみた

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

>>437
> パフォーマンスアナライザやプロファイラを使わず現実を見ずに先入観のみで
> >>2はきっと良いに違いないと盲信するならエンジニアではない
> エセ科学信仰とかカルト信仰に溺れる知的弱者だ

あっそう。

> 制御対象の計算粒度と数の特性ゆえに>>2は不利となる

と断言する根拠を是非パフォーマンスアナライザやプロファイラで示してね。

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

性能「だけ」で何かを論じるのはおかしくね？
性能だけで論じるなら早い話がC++とか消えろって話だよね

まあC++で書いてるなら
・擬似OOの実装を頑張らなくても、言語組み込み機能でタダで手に入る
・FSM作るのに関数ポインタのすげかえやマシンレベルの実行コード書き換えは
　用いない
・何でもかんでも一個のリストに繋げない
でしょうけれども

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

タスク同士で関連づけってどうやってる？

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

タスクシステムって１つのリスト限定なの？
じゃあ俺のタスクシステムじゃなかったんだｗ

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

>>438
そのごった煮状態ってなんかいいの？
ソース見る側としちゃ勘弁してほしい感じだけど

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

あけましておめでとうなのねー

>>387
IBMやDECのメインフレーム
↓
IBMのメインフレームやDECのミニコン

>>392
末尾のPDPミニコンの部分は記述ミス。ごめん
酩酊状態でタラタラ書いて校正せずにそのまま投げて寝ちゃった。
Whirlwind 1とSAGE防空システムに関しては英語文献が存在する
半世紀以上前の兵器システムの大凡の機能は教本に載っている。
どっかのmilドメインのサイトに幹部や技術系の中途採用試験（？）
対策用の参考資料が公開されている。詳細なパラメータは伏せてあるが
ぐぐればバシバシひっかかる

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

>>432
半分はないと思うよJK

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

>>441
めっちゃくちゃ複雑じゃね？
そこまでなったらもうバグのオンパレード状態で収集つかない希ガス

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

>>438
マルチコアなら②の方がいいと思う。
カプコンのMTフレームワークもそんな感じだったような。

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

>>443
ごった煮かもしれんが、並列処理ができるのがいいのよ
例えばタイトル画面表示中に、雪を降らせるなんてことも容易に実現できる
シーン式のゲームでもやろうと思えばできないことはないが面倒だろ
流石に全てのゲームジャンルでこの方法が適しているとは思わない

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

よくわからんが
より抽象度の高い話をすれば
「全てのゲームオブジェクトについて、1フレーム内でiterativeに処理を行いたい」
あるいは
「全てのゲームオブジェクトに、同じメッセージをブロードキャストしたい」
ことがあるかどうか、という話じゃなかろーか
あるのなら、それをリストに持っておくという実装もあるだろう

ただ、抽象的には欲しいのは「リスト」ではなく「反復子」のはずなので、
実装はどうとでもできるように思える

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

>>448
ジョブエントリのリストをなめて順次処理（バッチ処理）するだけの
コードをもって、これは並列処理できるのだと豪語するか。これいかに

バッチ処理するしか能のない粗末なコードをポンと渡して
それをユーザーに無理矢理に逐次処理に使わせておいて
（逐次・並行処理に必要な仕組みは全てユーザーに丸投げておいて）
どうだ便利だろこのソロモンの指輪は、並列処理できるんだぜ、なんといういとしいしと・・・
と陶酔するのは技術屋としてどうなの

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

>>448
何を言ってるのか本気でわからない
②で組んだことない？
仮にごった煮にしないでシーン？とゲームオブジェクトを別に管理したら
そっちのが扱いやすいだろ？
まとめるってことはアクセスするたびにそいつを判別するなんらかの仕組みが必要になるってことだし基本的には面倒が増えるよ
よほど一括で処理したいなにかがないとメリットはないと思うんだけど？

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

結論：

タスクシステム　＝　カオスで美麗で斬新な60FPS紙芝居の夢を追及している奴専用

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

うおおおおお！

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

アクセスするたびに判別が必要ならそれはタスクシステムじゃないじゃん？C++あたりで組むなんちゃってタスクシステムだよ

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

タスクシステムが賛否両論なのはきっと分割の粒度・観点とかの違いですよ。ええ。
と思いついたので分類してみた。C++なんちゃってタスクシステムの話

　1. マルチプロセス級：ゲームタスク、バッテリ残量監視タスク、...
　2. マルチスレッド級：入力監視タスク、ゲーム処理タスク、描画処理タスク、鳴音タスク、...
　3. 仮想関数インタフェース級：仮想update関数タスク、仮想move関数タスク、仮想draw関数タスク、仮想onkey関数タスク、...

・マルチプロセス級はほぼ関係無い処理だけど1台のPCにはともに入ってて欲しい位のとこで分割。.exe相当。
・マルチスレッド級は決まりきったデータ通信が発生する程度に関係のある処理で分割。
　通信を標準化するのもそう悪くないってとこで分けるのがミソかも（使ったこと無い俺）。
・仮想関数インタフェース級は関係性とか概念の違いとか無視してたまたま関数インタフェースが似た感じっぽいところを探して
　縦横無尽に共通化（抽象化）したもの。イベントハンドラの延長？
　仮想関数インタフェース自体の仕様変更耐性とか再利用性が最悪。最悪。最悪。
　それでいて性能も悪いかも。仮想関数ゆえにメモリキャッシュまわりとか？
　でも１画面ミニゲーム、画面エフェクト無し、凝ったギミック無しとかなら使い勝手良かったりする。
　グローバル変数が通常サイズのクラス１個分に収まる程度までが利点を享受できる適正規模？

2と3の間にゲームオブジェクトとかシーンオブジェクトとかで分けた「クラス分け級」を入れようとしたけどなんか無理だった。
3番と同じ気がしてしっくりこなかった。

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

実際のゲームってどういう設計が使われてるんだ？

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

そもそも実際のゲームには何か共通した設計というものがあるのか？

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