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

**名前は開発中のものです。** · 2008/12/29(月) 11:21:47

ひらしょーさんになにそれ？だれきみ？ってあしらわれたショックで
気が狂ってしまったん？

**名前は開発中のものです。** · 2008/12/29(月) 13:33:00

自分の言葉で論破できなかった厨房が、お墨付きをもらって狂喜してるだけにしか見えない。

**名前は開発中のものです。** · 2008/12/29(月) 18:17:39

ま、そういうくだらない連中のノイズ成分くらい除去できないと駄目だと思うけどね
ひらしょーさんひらしょーさん言ってる子供達もどうせついこの間までは
たすくしすてむさいこー松浦先生大好き尊敬しちゃうとか言ってたはずなわけで

風見鶏を右へ左へ引きずり回すのは楽しいよね。そろそろ>>2擁護始めるか

**名前は開発中のものです。** · 2008/12/29(月) 20:02:06

その問題のやねうらおとやらは、お前たちの何倍ものプログラミング能力があって、
お前たちの何倍も稼いでいるようだけどな

**名前は開発中のものです。** · 2008/12/29(月) 20:29:38

やねうらおが何だのかんだのと喚いてるのはpmocky一名だろう

**名前は開発中のものです。** · 2008/12/30(火) 10:15:13

pmokyな。奴がこんなとこで粘着する性格とも思えないが。

**名前は開発中のものです。** · 2008/12/30(火) 20:27:11

本人乙。やねうらおと何があったのか知らんが
あちこちのスレで発作的ESPでやね探知する度に私怨コピペ張るなよ
マ板にスレ立てるなり民事調停するなり労基に駆け込めよ

**名前は開発中のものです。** · 2008/12/30(火) 20:29:06

と思ったらスレあんのかよ。あのオッサンの界隈は相変わらず賑やかだね

**名前は開発中のものです。** · 2008/12/30(火) 21:29:05

松浦先生はエフェクトの人？
やねうらおなんかと比べるのは失礼だろ(笑)

**名前は開発中のものです。** · 2008/12/30(火) 22:17:02

どう見てもそのやねうらおとやらののほうが格上だがな。

松浦先生の最新刊
ゲームアルゴリズムレシピ for JavaScript (単行本) 2008/11　発売。
Amazon.co.jp ランキング: 本で131,156位

一方、同時期に発売されたやねうらおとやらの

ひなた先生が教えるデバッグが256倍速くなるテクニック 2008/11 発売。
Amazon.co.jp ランキング: 本で652位

私怨か何だか知らんがいい加減、見苦しいよ。

**名前は開発中のものです。** · 2008/12/30(火) 22:25:35

本読んでみりゃわかるのに

**名前は開発中のものです。** · 2008/12/31(水) 01:04:00

大掃除も終わったし、一杯ひっかけながらちょっとポエムを書いてみるのねー

多数のジョブを並行、並列に処理する能力は科学計算、軍事、宇宙開発など様々な分野で必要とされた。
特にリアルタイムという要求は軍事や宇宙開発と絡むことが多かった

【2DSTGの礎を探る】

第2次大戦中、米海軍がMITに艦攻のフライトシミュレータの基礎研究を依頼した。
海軍は風洞試験の結果をリアルタイムで再現する航空機解析・空力数値計算を希望していた。
当初MITはアナログコンピュータでこれを試み、後に海軍の提案でデジタルコンピュータの
開発に注力しWhirlwind I を作る。しかしその頃には軍はコンピュータを航空機解析よりも
戦術情報処理や指揮統制業務の能力向上に役立てることに関心が移っていたという

おりしもソ連がファットマンをコピーしたと思われるプルトニウム爆弾の実験（RDS-1）を成功させ
米国内が大騒ぎしていた時期でもあり、Tu-4長距離爆撃機による米本土への核攻撃も可能（※）と
分析されていた。空軍はこれに備えるために地上要撃管制(GCI)の連結と自動化に取り組んでいた。
空力計算の数値積分結果を逐次・リアルタイムでベクタースキャン型CRTに投影し・可視化しようと
していたMITのシステムは空軍の要求に堪えるものと評価され、Whirlwind I は防空システム用
コンピュータのプロトタイプとなる。ニューイングランドのGCIのデータを電話回線経由でMITに転送し
Whirlwind1がこれをリアルタイム処理するというデモンストレーションが成功し、Whirlwind1をベースに
大規模化したコンピュータAN/FSQ-7として正式化され、IBMが主契約をゲットして量産した。
http://www.mitre.org/about/photo_archives/sage_photo.html

**名前は開発中のものです。** · 2008/12/31(水) 01:05:23

>>386続き
多数の敵機を捕捉・追跡しながら迅速・適切に邀撃戦力を配当する（意思決定をサポートする）
SAGEシステムが50年代から本格運用された。これは後にICBMによる全面核戦争を想定した
防衛システムや海軍機動部隊の艦隊防空システムなどの礎となる。
SAGEコントロールルームのオペレータはベクタースキャン型CRTとライトペンの組み合わせによるGUIで
直感的な操作を行なうことができた。この技術はCADの礎となった。（アーケードのガンシューもこれ）
SAGEは逐次更新されF-102デルタダガー邀撃機のオートパイロットやCIM-10ボマーク長距離SAMの
中間指令誘導もできるようになった。こうしたリモートコントロールの技術は宇宙機やUAVの礎となる

（※）ソ連はそのころB-29の劣化コピーであるTu-4を配備していたがその航続距離はB-29よりも
　　　劣っていたことが後に判明する。片道切符で欧州の主要都市を核攻撃する能力はあったが
　　　米本土まで出張る能力はなかった。後にターボプロップ式の超長距離大型爆撃機（Tu-95：ベア）
　　　の配備が始まってようやく片道切符であればモスクワ-ワシントンDC間を無給油で核爆弾を
　　　お届け可能となった。
　　　米国はTu-4の航続距離とTu-95の保有数を過剰に見積もり、戦術情報処理・指揮統制業務の
　　　自動化や超音速でぶっ飛んでいく邀撃戦闘機や長距離SAMなどの研究開発に多額のお金を
　　　投じることとなる

この防空システムで培われた技術はIBMやDECのメインフレームの礎にもなった。特に後者の
PDPシリーズにとってWhirlwind I は直系の親筋にあたる。MITの学生が作ったSpace War!などに
代表されるベクタースキャン型CRTのSTGはPDPシリーズで作られた

（終わり。寝る）

**名前は開発中のものです。** · 2008/12/31(水) 05:08:08

キチガイだな
華麗にスルーして次の話題ドゾ

**名前は開発中のものです。** · 2008/12/31(水) 05:30:43

>>386-387
最後にSpaceWarにつながるのかｗ
あのソースってパブリックドメインなんだよね
ダウソして解析しようとしたことあるんだがPDPの
アセンブリコードの読み方が分からなくて投げた

**名前は開発中のものです。** · 2008/12/31(水) 07:04:20

WikipediaのSAGE半自動式防空管制組織のページを開いたら

＞50万行にも及ぶアセンブリ言語で書かれた

（ д ）ﾟ　ﾟ　ｽﾎﾟｰﾝ

**名前は開発中のものです。** · 2008/12/31(水) 08:38:28

・SFCでゲーム一本3万行を超えた記憶がない。ような気がする

・AN/FSQ-7の命令セットがどんなものか知らんのでアレだけど
　きっちりかっちり設計して50万行か。保守が大変だったろうね

・別の視点で見るとそれだけ巨大そうなシステムがアセンブリ言語で
　"たったの50万行"で動いてた、ということにちょっと驚いてみたーり

・昭和20年代でコンピュータが戦闘機を遠隔操作とかやばい。冷戦やばい

・MITやばい

**名前は開発中のものです。** · 2008/12/31(水) 11:25:14

PDP-11ならUnix V6関係で解説とかあるけどな。
ttp://www.tom-yam.or.jp/2238/asm.html
これとか手がかりになるかな。

先日もサンタクロース追跡で大活躍したNORADのシステムの祖先の話やね。
トラックボールの発祥もそれだったから、ミサイルコマンドの源流もそこか。
こまかい所だがDECのはミニコンピュータね。それにしても何かの引き写しじゃなくて
自分で書いとるのかいオッサン？　データプロセッシング分野と比べて
リアルタイムアプリケーションの話は文献が無いと思うのだが。

**名前は開発中のものです。** · 2008/12/31(水) 16:41:55

スレ違いじゃないの？

**名前は開発中のものです。** · 2008/12/31(水) 23:47:47

ワイヤーフレームの図形描画に対応してたのか
ゲームを作りたくなる気持ちが分かる気もするな

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

関係無いよね
スレと

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

コンピューターが沢山の爆撃機（敵オブジェクト）の振る舞いを監視して
飛行データから未来位置や爆撃目標到達時刻を予測して人に教えて
迎撃機やミサイル（味方オブジェクト）に向かうべき座標を指示する・・・か

まさにリアルDEFCONだな

写真にディスプレイの記号解説あるな
各オブジェクトが所有するステートが垣間見れて面白いな

POINT OF ORIGIN
ALTITUDE
DIRECTION
SPEED
IDENTITY
TRACK NUMBER
FLIGHT PLAN NUMBER
CORRELATION STATUS
TYPE OF AIRCRAFT
FLIGHT SIZE

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

CORRELATIONって辞書引くと相互関係、相関関係となるけど
自機僚機とか親子（発射母機とミサイル）とかそういうもの？

んービル一棟分の真空管コンピューターでSTG作ってみたいわ

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

スレ違いやめろ

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

スレ違いどころか、板違いだな。
昔話用の板あるんだから、そっち行けよ。

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

>>397
なるほど・・・・・ちゃんとFSMしてるんだな
超プロプライエタリな世界だからソースは無論非公開だろうけど
仕様からおおよそのところが想像できておもろいな

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

>>396→>>396-397

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

sageずに書き込みしてる>>374,375,383,385,388,393,395,398 が、
底抜けの馬鹿だと言うことはよくわかった

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

全然関係無い内容じゃん
引用するにしてもスレと内容の説明責任ぐらい果たしていけよ
垂れ流しが酷いし
タスクシステムと関係無いじゃん
関連してると思ってるって自分だけの思い込みで強引に話を無駄に広げてるんだろうけど
ちょっとオナニーが酷く生臭いよ

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

編隊飛行が表現できるなら木構造になるし
ロックオンした目標が複数あればグラフ構造にもなるな

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

>>403
わかってないのお前ひとりだけじゃん。
お前が底抜けの馬鹿だからわからないだけで・・・

**名前は開発中のものです。** · 2009/01/01(木) 16:17:14

板違いスレ違いを続けるのはそろそろどうかと思うんだな。

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

全然関係無いよね
なんか
わからないんだ？ﾌﾟｷﾞｬｰ(笑)
的な流れにして説明責任果たそうとしない流れにしがちだけど
現実、仕事となったらここが一番大事だしその後の理論がどんなに立派でも糞とカワンネ
仮に関連してたとしてもこれ関連性を説明するの滅茶苦茶大変だぜ

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

訂正。わかってないの、>>406,407のお前ら二人だけだよ。

大馬鹿はお前ら二人。

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

触んないほうがいいんじゃない？

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

>>404
こういうのってHFSMみたいな記述になるのかしら

ツリーの各ノードがFSMっていうイメージでいいのかな＞HFSM

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

HFSMは状態の木構造、状態の中にさらに状態がある
みたいなものじゃなかったっけ（ちがったかな）
編隊のリーダーと部下みたいなFSM同士の主従関係とか
組織のヒエラルキーをあらわす木構造の場合は
単に木構造のコンテナにFSMが入ってればいいだけなので
HFSMとは違うかもだ

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

>>408
そんなこと言って難しい部分は説明できないから逃げる気でしょ？
職場でもこんなわけのわからないもの採用させるなんていったら大変なのはそこだよ
逆に批判をかわすのもわけわかんないこと叫んでかわせばいいけど
そうゆうこと馴れると技術者として死ぬよ
批判する側に説明責任の押し付けゴッコ始めていつもかわすけど
そもそもなんの関連もないの明らかじゃん

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

>>412
何度でも言うがわかってないのお前ら馬鹿二人だけなんだよ。

なんなら周りのプログラマにこのスレ見せて聞いてみなよ。

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

説明責任放棄する奴は二言目には必ずそういう
関係無いから関連を説明しろっていってるだけじゃん

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

>>414
馬鹿すぎて周りに友達いねーのか。それは可哀想に。

**名前は開発中のものです。** · 2009/01/02(金) 07:00:34

>>386-387
すげぇな
飛行機や対空ミッソー飛ばしてもデッドライン（敵が目標上空に着く時間）までに
敵とご対面させてやらなきゃ全部パーだよな？

リアルタイムシステムだな。しかもかなりハードな

**名前は開発中のものです。** · 2009/01/02(金) 16:48:56

匿名でも記名でもi君の人を見下した態度は相変わらずだな

**名前は開発中のものです。** · 2009/01/02(金) 20:57:49

>>411
㌧ｸｽ。なるほど。状態に子あ孫があるのか

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

で、代替案はまだ出ないの？

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

代替案？
なんの？
こんなもん使わなきゃいいだろ
普通に必要なだけ処理書いて引数で必要なもんだけ渡せよ

**名前は開発中のものです。** · 2009/01/04(日) 09:29:42

つまり420は配列派というわけですね？

**名前は開発中のものです。** · 2009/01/04(日) 09:42:16

アホか

オブジェクト指向で普通に書けばいいだろヴォケ

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

配列はインスタンスの話だろ
多分

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

Taskをモナドにしよう

**名前は開発中のものです。** · 2009/01/04(日) 15:08:16

オブジェクト指向で普通に書いたらタスクシステムだけど？

**名前は開発中のものです。** · 2009/01/04(日) 16:24:39

オブジェクト指向プログラミングでは双方向リストをガチガチに手書きするのが
普通なんですかそうですか。

それってどこの世界のオブジェクト指向プログラミング？

**名前は開発中のものです。** · 2009/01/04(日) 16:48:53

リストかどうかって別に本質じゃないような。

>>2を見る限りでは、個々のタスクはただ一つ、「実行しろ」というメッセージにしか
反応しないオブジェクトのように見えます。

よって、オブジェクト間の相互作用のための手段は非常に限られるので、
C風に「リストを舐めて構造体の中身を直接のぞく」コーディングが行われていたのでは
ないでしょうか。
それは「OO」じゃないですよね。人のものを勝手に見るのではなく、
人に頼む、尋ねるのがOOのスタイルです。

それとも、実際にはタスクは複数のメッセージを処理するためのディスパッチャ
や関数テーブルを持っていたのでしょうか？
それならば、貧弱な言語／環境であるがゆえに
自分で型タグやオブジェクトID、メソッドテーブルを実装しなければならなかった
というだけで、OOであると言っていいと思います。

**名前は開発中のものです。** · 2009/01/04(日) 19:15:52

そういう、Cでオブジェクト指向を実現するためのテクニック
（有名どころではXtとかが使ってた）の真似事みたいなことは
してるけど、オブジェクト指向とはどうにも認めがたい。

タスクとキューはis-a関係じゃないしな。
（オブジェクト指向をCで、的にはそういうことをしてる）

秀和の本でだいぶ古いけど、「C言語ゲームプログラミング」が
それっぽいことをやっていたな。今見る価値がある本ではないが。

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

C++で普通に作ったらタスクシステムというものをわざわざ用意しなくてもいいのは事実。
単一のインスタンス構造に多数の関数ぶらさげてただけだし。

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

とんでもない神レベルの人ととんでもない馬鹿とが混在するのがこのスレの面白いところだな

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

>>429
あんまりその辺こだわってる奴ってもういないと思うぜ
オブジェクト指向云々とかあまり問題じゃない
たまに急に振る奴がいるけど別にクラスなんかあってもなくても同じ問題に直面する

ま、ＳＴＧだったら自機、敵、弾とあってそれぞれをクラスっていうか
オブジェクトにして必要な分のインスタンスを用意する

ここまではみんないっしょだろうし別にＣ言語風味に構造体定義して
インスタンス作っても別に大して変わらない

問題はインスタンスの扱いだと思うんだよね
①void*で一括して配列用意して（リストでもいいけど）newで確保して型覚えておいてキャストして使うか
（これがタスクシステムっぽいやつ？）
②型ごとに配列定義して地道に作っていくか
（これが正統派？）

まあ、微妙な違いはあれどこの２つのどっちかになるだろね
前者だと必要なところどころで型キャストして戻さなきゃいけないけど一括して扱える
後者だと型ごとに同じ処理を何度も書かなきゃいけないけどキャストとかする必要がない

ただ、①の方法で組むと一括処理にばっかりこだわって引数とか省略して
グローバル変数使うようになってバグが増えるのはたしか
②で組んだほうがソースもわかりやすい（と、俺は思う）
まあ、②は面倒だけど正統派？そんなイメージ（ただ、面倒っていっても実装的に面倒って話だからねぇ・・・）

とまあ、オブジェクト指向云々関係ないでしょｗ

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

一括して扱える、同じコードで扱えるというのはCPUにとっては全くうれしくない

闇鍋循環リストに全てを放り込む>>2が何故詰んでいるかというと
弾も敵もパーティクルもひとつのリストにぶち込み同じコードでディスパッチするから。
分岐先はほぼ予測不可能。>>2はハードウェアに分岐先を絞り込むヒントを与えない。
サブルーチンアドレスはフラットなFSMの状態変数を兼ねているため種類は膨大。
CPU内蔵の分岐先バッファは役に立たない。ループする度に分岐先予測ミスが発生し
ペナルティを受ける。毎度毎度ご丁寧にサブルーチンアドレスを参照してディスパッチ
オブジェクトの種類順（弾、敵、プレイヤーなど）にソートしても根本的な解決には
ならない。なぜならオブジェクトの種類が同じであっても状態が違えばサブルーチン
アドレスは違うのだから

大昔に興味本位で測定した。AMDのAthlonXP（Bartonコア）で>>2を使うと速度は半分になった

大昔の、アドレッシングモードの貧相な（かなり特徴的な）8bitCPU、それにOBJやBGを
HSYNC毎にアナログ映像信号に変換してCRTに出力してくれるハードワイアードロジック回路
を搭載したカスタムボードを中途半端に意識して、当時の神の業などと詐称して喧伝してる時点で
クズの所業だが、実際に走らせるハードの特性を完全に無視してるのだから輪をかけてクズといえる

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

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