タスクシステム総合スレ part3

タスクシステムについての議論、相談、質問、雑談などのスレです

part2 http://pc11.2ch.net/test/read.cgi/gamedev/1196711513/
part1 http://pc11.2ch.net/test/read.cgi/gamedev/1173708588/

White Paper - Programming
http://homepage3.nifty.com/moha/programming.html

タスクシステム
http://www5f.biglobe.ne.jp/~kenmo/program/task/task.html

CodeZine：本格的なシューティングゲームを実現するタスクシステム（タスクシステム，シューティング，ゲーム）
http://codezine.jp/a/article.aspx?aid=297

Logician Lord　…　【コンピュータゲームのからくり】
※ウェブアーカイブのキャッシュ
http://web.archive.org/web/20041009222313/www.hh.iij4u.or.jp/~peto/Games/games_top.html

１乙

1おつ


前スレ>>995を実行しようとしたら、
「MSVCP60D.ｄｌｌがみつかりません」って出て実行できんです。

同じく下記2ファイルがみつかりませんと出てきた

　　MSVCP60D.DLL
　　msvcrtd.dll

windows用の関数のスタブを用意したりして
linuxにてコンパイルして動作確認はできた
boost, boost build必須だけど…

boostはいらんな、
なんかCTextBuffer::Openで落ちるから色々調べてたときに使ってただけね
パスやらファイル名の問題で*.mqoが開けなかったときにぬるぽが発生して落ちてただけね
あとglutの初期化忘れとか

タスクシステムと全然関係無いですねゴメソ

>>4
それVC6のデバッグ版のDLLだな
うちは入ってるから気づかなかったが

>>995はリリース版でビルドしちゃれよ

>>8
もしくは CRT をスタティックリンク。

ここで10年前に買ったVC6の恩恵を初めて受けることになるとは

>MSVCP60D.ｄｌｌがみつかりません

だっせー！＞俺
すびばせんでした。再うｐしました。

http://uproda11.2ch-library.com/src/11133655.zip.shtml

DLキー task

修正項目
・実行ファイルを Release ビルド
・背景スクロールを実装してみた。
・データローダの別スレッド動作のテストなど

>>7
ｶﾞｯ!(AA略）

>linuxにてコンパイルして動作確認はできた
さすがゲーム板。いや、LinuxでブートCD配布とかできたらと思ってたので。

>前スレの人
・実行順制御よりオブジェクト相互の関係が重要

サンプルを組んでみて、そのあたりの解決が提示されているわけではなさそうですね。< タスクシステム

サンプルのなかで、プレーヤーオブジェクトをポインタで保持してたり、その弊害を
避けるためにフラグ立ててたりとけっしてスマートとはいいがたいような。

TCB+関数ポインタをクラスで置き換えるのは悪いとはいわないが、オブジェクトの
生成削除が頻繁に起こるゲームで、std::listで管理するのはどうかなと思いました。
手軽ではあるのだけど。

>前スレの人
＞実行順制御・描画順制御
まだ慣れていないので評価しにくいですが、サンプルではシナリオの読み込みとか優先度を高くしてありますね。それなりに意味はあるのか？

描画順制御についていえば、OpenGL を使っていても半透明オブジェクトの重ねがき
みたいに描画順をメンテする例もあるので、まあ、あれば使うかなと。
（爆発表現にちょっとつかってみた）

描画に関してはもっとちゃんとしたやり方があるように思いますが。

>>12
> オブジェクトの生成削除が頻繁に起こるゲーム
今時のマシンなら高がしれてるよ。エフェクトでパーティクル個別に new するとかだと、さすがに
氏ねと思うが。

>>14
>今時のマシンなら高がしれてるよ

CPU負荷や処理速度じゃなくて、サンプルの例だと、stl::list からオブジェクトを
削除する場合のトリッキーに見える処理がちょっといやらしいかなと思ったんですよ。

ただ、シーケンシャルな処理だと考えればそんなに問題もないのかな。

>>15
そういう話なら同意。というか、何でもかんでも一つのリストにつながなくても、ふつーに
std::list<Enemy> enemy_list;
std::list<Effect> effect_list;
と分けとけば良いのにね。

今時のマシンでもメモリ問題は意識すべきだよ。
少なくとも自分以外の人に遊んでもらえるゲームを作るつもりならね。
モジュールのライフスパンに応じて適切にヒープを分けるだけなんだから
最初からやれば手間はかからない。

今時はコンシューマゲーム機の開発者でさえもメモリ管理をおろそかにする未熟者が多い。
マスターアップ近くになってフラグメント化のためゲームがハング。
対策を練ろうにもグローバルでnew、deleteだったから全部書き直しするしかないという
実話もあるほど。

1GHz 512MB VRAM8MBで起動した
超絶スローで

>>17
CodeZine のサンプルはメモリ管理にこだわってたよね。
「タスクシステム」の要件にメモリ管理を加えるべきか、みたいな
話もあったけど。

>>18
>VRAM8M て、trio64とか？w
さすがにOpenGL のハードアクセラレーションないとちょっときついかと。

>>17
> 対策を練ろうにもグローバルでnew、deleteだったから全部書き直しするしかないという

なんでそうなるんだ？
「モジュールのライフスパンに応じて適切にヒープを分けるだけ」なんだろ？
後でもできるじゃん。

>>17
メモリの断片化が問題になるのは、極端にサイズが大きいものと小さいものを
同じヒープから確保する場合。

テクスチャ・モデル・モーション・サウンドなどのリソース類だけ分けておけば、
あとのゲーム制御用のインスタンスは気にせずグローバルなヒープから new,
delete で OK だよ。

そんなどんぶり勘定が許されるのは素人ゲーだけだよ
少なくともヒープ使用量の最大値は見積もれていないと
売り物にしてはいけないね。
フラグメント化対策の方法論なんて確立されているんだから
それをおろそかにするのは単なる手抜き以外の何者でもない。

まったくだ。

「おそいかも」とか「フラグメンテーションが発生するかも」なんていう
どんぶり勘定で面倒なメモリ管理コードなんて追加しちゃいけない。

「ここがおそいことがわかったから」「ここでフラグメントが問題になったから」と
言えるなら何か細工を入れてもいい。言えなきゃおとなしく new/delete 使っとけ。

問題になるまではGCやsmart_ptrを使っていてもおkと

いいよ
仕事でやってるやつはみんな何回も痛い目見てるから自然と神経質になる
問題が出ないうちから考えてもアタマでっかちになるだけ

>>23
> そんなどんぶり勘定が許されるのは素人ゲーだけだよ
気のせい。

newとdeleteはやたら使用メモリの全体量がわかりずらいな
mallocからしてロクなもんじゃなかった気がするけど
newとdeleteほどアフォ仕様じゃなかったよな
オーバーロードするといちいちそのヘッダ呼ばないと
newとかdeleteとか呼べないしで糞面倒くせぇ

せめてデバッガで見えれば助かるんだけどそういう機能ってないの？

>>28
ふつー ::operator new() ではなく、クラス内の operator new をオーバーロードするから、
必然的にヘッダ読み込むことになると思うが。

メモリ使用量は、使ってるライブラリによるな。俺は自前で書いたのがあるから、それを
使ってるけど。

タスクシステムと分岐予測やパイプラインの関係を考察してるようなサイトありませんかね？
ググッてもこのスレばかりヒットしますw

>>28
＞mallocからしてロクなもんじゃなかった気がするけど

それ実装対象・OS・ライブラリの組み合わせに依存した話
例えばおまいらが大好きなx86系PCとWindowsとVisualStudioの組み合わせの場合
VS付属のmalloc、デフォルトのnew/delete、STLのデフォルトアロケータの中身を見れば
どれもHeapAllocに行き着く

暇だった頃にベンチマークテストして遊んだけどHeapAllocが他のアロケータ
(GNU libc malloc、BSD Malloc、etc)と比べてロクでもないという感想にはならなかったな。
HeapAllocはおそらくDoug Lea Mallocそのものかその親戚筋に相当する実装だろうと思う。
>>28はdlmalloc系がロクなもんじゃないと言いたいの？それともヒープ使用量をモニターする
手段が見つからないからロクなもんじゃないと言いたいの？

>>22
＞極端にサイズが大きいものと小さいものを
＞同じヒープから確保する場合

「極端に生存期間が大きいものと小さいものを同じヒープから確保する場合」
も付け加えといとくれ

>>32だけど>>21で既に生存期間の話出てるね。文盲だね

ネトゲのサーバプログラムとかだとオブジェクトの生存期間の差はかなり強烈なものになるから
例えばWindows系ならHeapCreateとかで適切にヒープ領域を分けといたりするけれど、PCゲーの
クライアントプログラム限定の話ならぶっちゃけこんなの要らん

数ステージを巡回するデモンストレーションモードで数日間ぶん回してメモリ確保に失敗し始めたり
タスクマネージャのグラフが愉快な絵を描いてるとかNtQuerySystemInformationでログ取り続けたら
驚きの結果が、とかならフラグメンテーション云々の可能性を考えてもいいかもだが

そういう場合はステージ毎にHeapCreate/HeapDestroyでドバっと確保・ドバっと開放でもしとけばいい。
これならステージ中のオブジェクトはみんなHeapAlloc系使ってもフラグメントの心配いらね
弾とかパーティクルみたいなサイズ・生存期間共に粒度極小のオブジェクトを大量にばら撒く
ゴジャースなゲームなら表示MAX分だけドバっと確保したboost::pool使うか配列で順序なしのリスト
みたいなことやっとけばいいよ

ところでタスクシステム？ﾊｧ？って感じだな

>>31
俺はそんな難解な話してない
使ってるメモリの使用量がわからない・わかりにくいってただそんだけのこと
あと、メモリリークとかも全然わかんねぇ
IDEの問題になるけど分かる要素がないのがひでぇｌ

で、俺の知識だけだと自分でmallocをラップした関数を実装して
それに使用メモリの総量・使用メモリ状況やメモリリークなんかを
チェックできるようにしてるんだけど

この辺っていつまでたってもウンコじゃね？
とかそういうこと言ってる

（俺が知らないだけかもしれんが少なくともVCはウンコだと思う）

>>30
マジに最適化し出すと、関数の並び順とかまで見直す必要がある。PS2 のときには
キャッシュがマジ少なかったので、ライブラリチームは T15000 使って最適化してたけど、
今はそこまでやってないんじゃないかなぁ。

ゲームロジックはキャッシュミス起きまくりだが、そもそも大して CPU 使ってないので
気にしない。昔も今も。

>>33
パーティクルとかの小さなオブジェクトは STLport の node allocator 使ってた。メモリが
多少無駄になるけど、早いし断片化しないので。

>>34
確認するが、CRTデバッグヒープくらいは使ってるという前提でいいよな？
http://msdn.microsoft.com/ja-jp/library/974tc9t1(VS.80).aspx
その上で不満ということならもう少し詳しくお話をしてほしい

もし使ってないってんなら幾らなんでもネタだろう…（´-`）

>>37
こっちも確認するけど
それアフォがソース見てもわかる奴しかでない奴でしょ？
難しいリークだとアウトプットウィンドウに変なコードがずらずら出てもどこのコードが
リーク起こしてるかまったくわからない機能でしょ？
そんなの使えないよ

正直、その機能に頼るぐらいなら自分でmallocをラップしたほうがよっぽどいい

ちなみに使ってるのはこれ

_CrtSetDbgFlag(_CRTDBG_ALLOC_MEM_DF|_CRTDBG_LEAK_CHECK_DF);

なんでこれさ
こんなアフォなんだろうね
俺のいる会社の新人だってこんなアフォな機能作らないと思うよ
やっぱり俺の使い方間違ってる？
ってかそれとももうちょっといい使い方あんの？

さすがにこりゃねぇだろうと思った
だって自分でやればどこのソースのどのコードが使ってるメモリなのか
余裕でわかるようにできるじゃん
これまったくわかんねぇじゃん
動的（わからない法則がちょっとわかってないが）に確保したもんだとほぼお手上げじゃね？

飯くってた
>>36
node allocatorは良いものらしいね

>>38-39
把握した

WindowsだのVisual Studioなど言ったって、なんだよ結局はユーザープログラム固有の
モニタプログラム（システムモニタ（リソースモニタ）やジョブモニタ）を用意しなくちゃ
いけなくなるのかよバーローつー話だよな

通常、ゲーム開発用のフレームワークはデバッグ支援用のツール群とセットになってるけど
それに相当するサービスをVS標準機能に期待するのは難しいね

ま、同人ゲームとか、ここでタスクシステムすげぇすげぇ言ってる超小規模開発・個人開発なら
無用の機能だが

前>>969
（前略）だからコンテキストスイッチは不要では。

＞コンテキストスイッチは要らなくネ？

ゲームに要求される表現は多様化・高度化し続け、それに伴いゲーム内で処理されるジョブの粒度も多様化し
１イント内に処理すべきジョブ数も増大の一途をたどった。ジョブ（ゲームコード。例えばAI）を記述するスタッフも
増大し多様化した。時間ステップ毎に単純に数値積分していくだけのジョブばかりではなくなり、継続（continuation）
が必要なジョブが増えた。にも関わらずゲームの特性上個々のジョブはμsecオーダーで終了ないし中断することを
要求される。継続に必要な手続きをユーザープログラム側に丸投げする（ユーザープログラム側にリエントラントな
仕掛けを用意させる）原始的なFSMモデルのジョブ制御だけではお話にならなくなり、ファイバーやコルーチンのような
仕掛けも必要になった。これらのジョブの粒度はスレッドを使うには小さすぎ、また数も多すぎる

まぁ、同人ゲーやタスクシステムすげぇすげぇ言ってる超小規模開発・個人開発なら無用の機能ではあるが

ｽｹﾞｰ参考になってありがたいけど同人シュー制作者の俺にはテラコンプレックスｗ

（訂正）
----------------------------------------------------------
＞（前略）だからコンテキストスイッチは不要では。
＞
＞＞コンテキストスイッチは要らなくネ？
↓
＞（前略）だからコンテキストスイッチは不要では。
----------------------------------------------------------
＞１イント内に
↓
時間ステップ毎に
----------------------------------------------------------
（補足）
一部素人がタスクシステム（以下>>2と呼ぶ場合アリ）とか呼ぶものの実態が>>2程度のものであるという前提に立つならば
これは70年代のハードに依拠する簡素なゲームにとっては無難なジョブ制御プログラムとかモニタプログラムの【断片】だね
しか言いようがない。もはや今となってはね。
これは非常に簡素でオーソドックスなFSMモデルのジョブ制御であり、大昔から科学計算で頻繁に使われ
大昔の計算機、現代でも組み込み用途の超貧弱なマイコン（安いものなら50円前後。RAM数KBとROM数百KBの
ワンチップのやつ。半ば使い捨て）のために用意される超原始的なモニタプログラムにも見られる。
継続に必要な仕掛け、つまりコンテキストスイッチに必要な記述は全部ユーザープログラム側に丸投げ。
何もしてくれない。誰が書いても同じようなものになるってくらい凡庸な、道端の雑草並みのありふれた仕掛けだ。
でも「タスクシステム」という呼び方は珍しい。かなりエキセントリックだ。これは特定の職場内の固有名詞
ローカル用語の粋を出ることはないだろうね

>>41
ＡＩについてで実装できてるわけじゃないから強くは言えんけど
タスクシステムの構造を大きく変えるような手を入れなくてもできそうな気がする。

別スレッドで定期的にタスクを位置等のグループ毎に分割して、グループ内での状況を解析する。
そしてタスクに次に処理がきたときに、次にどう動かすか考えるの役立つ情報をセットする。
とかではだめですか。

>ゲームに要求される表現は多様化・高度化し続け

で、そんなリソース大量消費型ゲームと小規模DSゲームの売り上げが変わんなくて
涙目、という話ですね。わかります。

とかそんなつまらんイヤミはおいとくとして、タスクシステムのサンプル打ち込んで
おもしれーなとか言ってる俺には雲の上の話なんだけど、

>原始的なFSMモデルのジョブ制御だけではお話にならなくなり、

こういうところはなんとなく予想できるんだよ。ただ現実問題として

>同人ゲーやタスクシステムすげぇすげぇ言ってる超小規模開発・個人開発

が、手軽に手をだせる、楽チン開発できてウハウハなフレームワークってあるの？
どうせ勉強するんならそっちのほうがいいような気がすんだけど。

>>45
C++ でふつーにメインループ書いて、continuation っぽいこと必要な部分はスクリプト言語 + スタックレス VM で良いじゃん。lua とか。

Ｑ．【>>2のようなプログラムを「タスクシステム」と呼ぶことに固執し広めようとする人間がしばしば笑い者になるのは何故？】

技術は進歩し続け、計算機は猛烈な勢いで処理速度を向上させ、現代のナウいハードに依拠するナウいゲームを
作るために『『不可欠』』となったナウいフレームワークだのゲームエンジンだのと比べるともはやミジンコ級であり
お世辞にもシステムとはとても呼べない玩具みたいな代物であることは否めない
>>2のような小規模で簡素なFSMモデルのジョブ制御は、原始的なモニタプログラムといえるかもしれない。
しかし一般にOSを表す非プリエンプティブマルチタスクシステムとは明らかに異なる。共通項は非プリエンプティブ
という点だけでありコンテキストスイッチをサポートしていない（その責任をユーザープログラム側に丸投げ
してしまってる）時点でマルチタスクシステムとは明らかに異なる。マルチタスクという用語自体は1960年代半ば
オペレーティングシステムという用語と共に誕生した。UNIVACとかSystem/360のOSが出てきた時代の話。
エンジニアは用語の意味が輻輳を起こし意思疎通に齟齬が生じることを嫌う。OSが提供されないカスタムボードで
走るゲームプログラムの開発者なら兎も角、立派なOS下で走るゲームプログラムの開発者にとってタスクはプロセスだ。

>>2は、過去に「とある開発チームで使われていた原始的なモニタプログラム」が固有名詞として「タスクシステム」と
呼ばれていたのかもしれないね、程度の理解でいいと思う。当時のゲームプログラムはOSが提供されないカスタムボードで
走るものであり、ゲーム開発者自前のモニタプログラムを用意しハードの全てを自分でコントロールした

＃google2001の検索結果によると当時「タスクシステム」などと呼んでるページはほぼ皆無だったことが判明している
＃ほんの一部でその単語を使ってたページは出典としてLogician Lordを紹介していた。ネットで徐々に伝播しCマガで
＃松浦とかいう素人プログラマが出典を明記せずに紹介し急速に流布し広めた「タスクシステム」なる呼び方の出所は
＃Logician Lordだろうと思われる。これがネット発の「タスクシステム」なるものの出自だ。都市伝説と呼ぶに相応しい

>>46
スタックレス + lua でググった。
なるほど、いまどきはタスクシステム(FSM)でｶﾘｶﾘやる、やれるくらいの規模の開発
なら、単純なメインループとスクリプト言語のほうが楽だしパフォーマンスも出る
ってこと？

難点はあのパスカルくささに耐えねばならんとこかなあ。ﾆﾝﾄﾓｶﾝﾄﾓ。

>>48
状態遷移が複雑な部分、たとえばアクションゲームのプレイヤー制御とかは
C++ で書いといて、continuation あった方が楽な部分、たとえば「何秒後に
エフェクト発生」とかはスクリプトとかデータファイルで書くのがふつーじゃね？

>>42
必要ないものは取り入れる必要はない。コンプレックスは持つ必要ない。
俺も同人ゲーを作ったことあるが規模相応の簡素なコーディングで済ませてた。
いわゆるタスクシステムとか紹介されてるあのヘンテコな仕掛けも不要だった。プライオリティ？ハァ？って感じだ。
敵の配列が弾の配列があって。そんな感じだ。
タスクシステムを心の底から崇拝する人間が心の底から子バカにしている様子がたまに見受けられる
配列厨のコードそのものだ。

同人ゲームを悪く言うつもりで書いたわけではないのだが、もし>>40-41の「同人ゲーム〜」の部分が気に障るなら
そこは撤回する。すまなかった

>>49
luaはver4のころちょっとかじっただけなんだけど、スクリプト処理のために
組み込んでみようとは思ってたんで、考えてみるよ。ありがと。

>>44
多種多様な人間が多種多様なジョブ（ユーザープログラム）を記述することになると
「FSMモデルのみ」という拘束条件は必ず無理が生じる。これはやれば分かるという他ない
RAM数KBの組み込み用モジュールのモニタプログラムでもコンテキストスイッチをサポートしたがる。
FSMモデルでジョブを記述させると色々面倒くせーことになるから。説明するよりも組んでみたほうが
分かるという他ない

＞別スレッドで〜

よく分からんがコンテキストスイッチをサポートしたくないがためだけに
何やら複雑怪奇な仕組みを導入する話のような気がしてならない
素直にLuaとか使ったほうがいいよ。というか眠いばいばい

>>50
＞規模相応の簡素なコーディングで済ませてた
そこんとこがよくわからんのだよなあ。
単純な配列とループで組めて問題ないならぜんぜんOKでしょ。俺もそうする。

ただ、サンプルでも使ってる GLLib の人のサンプルソースは単純ループ
だけど、けっこうきつい印象を受けた。

俺も「タスクシステム」を採用するだけでバラ色の未来が開けるとは思わん
(まだかじっただけなんで実はすごい泥沼が待っているのかもしれない)けど、
そこそこ使いまわしが効いて、それなりに見通しがいいように思う。

要は適材適所じゃないかと思うんだが、用語を使うことすら非難するほどの
問題があるの？

＞何やら複雑怪奇な仕組みを導入する話のような気がしてならない

こういうのは、同意できるんだよね。
そこそこ便利そうだけど決してわかり易い仕組みとはいいにくいから、
なんか泥沼にはまりそうな気がする。

まあ、小学生の感想文ですまん。

タスクシステムが有効なのは小規模システムだな
メモリの単位がkまでの環境
Mになると不要

>>55
キャッシュじゃねーかw<k
あー、PICのプログラムとかそれっぽい。

AVRは俺の嫁

i君はルサンチマンに満ち溢れてるなｗ

>>48
Luaの文法が嫌いならSquirrelもいいよ。
ム板でスレタイ検索してみてくださいな。

>>53
自分の書いた文章で古い設計方法に名前がついたことにより
予期せぬ形でもてはやされるようになってしまった。
そのことに対する責任感から現代的な知識を伝えると共に
言葉狩りを行っている。

彼の行動はこのように解釈することもできる。あくまで妄想だが。

タスクシステムを使ってるプログラムの
メモリ・ポインタまわりのバグり具合はハンパじゃないな
フツーに書けとあれほど言ってるのにやって
ゲームと違うところでいっつも四苦八苦してるとなりのプロジェクト

あんまりポインタ周りのバグが酷いからプロジェクトをまたいだ会議で
原因を指摘してやったのにまだごにょごにょ言ってる
もう、お前（となりのプロジェクトのウンコリーダー）に逃げ場はねぇよ

グローバル変数とタスクシステムとポインタの悪用は絶対に全部セットなんだよな
タスクシステム使わないプロジェクトはグローバル変数も使わないしポインタの悪用もしない
だからプログラムがメインから必ず終えるし
組み込むべき箇所もすぐにわかる
第三者がきてもすぐに全体が把握できるってのはでかいね

もういい加減に信者も目を覚ますべき

メモリ、ポインタを怖がるってプロとしてどうなのｗ

馬鹿が触ったポインタほど怖いもんはねえぞ

確かにコンテキストスイッチがないとグローバル変数に頼らざるをえない。

コンテキストスイッチがあったところでスパゲティにする奴はするけどなw

nullポはいねぇがあ〜？

>>48
昔Delphi使ってたから、馴染みはあるんだけど、C/C++と併用すると間違うんだよね。
演算子とか。

>>60
あー、それは俺も気になった。
親クラスのメソッド呼んだら、内部で自分自身を削除してて戻ってきたところで落ちるとかw
俺がタコなだけなんだけど、基本的にポインタを多用するスタイルみたいだしな。
几帳面なやつ向きかも。実はちょっとびびってるw

それタスクシステムとかいうナニに限った話ではないと思うんだけどな
相互参照オブジェクト（インスタンス）の取り扱いについてのごく初歩的な
あらゆるプログラムに通じる基本的なお作法の話だと思うんだ

ポインタなくてもタスクシステム組めるけど？

>>66
んー、いいわけがましくなるけど、俺の場合、インスタンスの廃棄は生成した側
が責任をもつというスタイルだったんで、インスタンス自身が自分を廃棄する
という形式に慣れてないんだと思ったけど。

>>67
でも悪用するだろ？
しかもグローバル変数は使わないと恩恵（笑）は受けられないだろ？

所詮、アフォが飛びつく糞なアイテムよ

＞インスタンス自身が自分を廃棄

その廃棄っていうのは、自殺を決断したらメモリ開放まで一気に行ってるわけだよね？
タスクシステムとかいうナニにおけるインスタンス（というかエンティティなんだろうね）の
自殺のプロセスというのは、常にそういうもの（自殺を決意したらメモリ開放まで一気に決行）
と決まっているの？それとも君が読んだ何かしらの自称タスクシステムのサンプルコードの
実装がたまたまそうなっていたというだけなの？

>>70補足
＞（自殺を決意したらメモリ開放まで一気に決行）

なおかつ生みの親や己を参照するインスタンスに何ら通知する手段を提供しない。ね

>>68
＞俺の場合、インスタンスの廃棄は生成した側
＞が責任をもつというスタイルだったんで

これも同じく。自殺を決意したら生みの親に自分を殺してくれと依頼するような手続きは
タスクシステムと呼ばれるナニにおいては「存在しない」ということになってるのか、それとも
君が読んだ何かしらの自称タスクシステムのサンプルコードの実装がたまたまそういう
手続きを用意していなかっただけなのか

自称タスクシステムってどれもこれも俺俺システムで内容がバラッバラだよね

>>70
イテレータに矛盾が生じないような工夫はされてたけど、delete はdelete だったな。
まあ、それでも、たまたま、じゃないかと思うけど。入門用サンプルだし。

>>72
そうかー。もし良かったらそれのURLとか書籍名教えてくれないかな
いや、別に悪戯とかしないからさ

>いや、別に悪戯とかしないからさ
却ってこえーよw
こっちは勉強させてもらってる立場だからあんまりなー。
このスレを調べりゃわかるよ。

あー、ここに載ってるならいいや

＞却ってこえーよw

何にもしねーよ。入門用を謳う自称タスクシステムがいっぱいあるから
そのカオスを更に加速させて「タスクシステム」がどんどん
「口に出すだけで何とも居た堪れなくなるムードを醸し出すキーワード」
になっていく様はある意味で痛快だしな。

いっぱいあるから →　増殖するのは結構なことだ

ちょっと大げさかもしれないけど
コンテンツ産業に理解ある総理の下で
国策としてコンテンツ産業に力を入れようとしているのに
裾野を支える初心者が混乱に陥ることを喜ぶのは
日本人として恥ずかしくない?

タスクシステムすごくね？
いつも途中で破綻する俺でもゲーム作れた

>>77
そういう、いかれた自称上級者はいつの時代にもいた。

タスクシステムを使うようになってからというもの、周囲がボクを見る目が変わったね。

なんかこう一目置かれてるって感じ？

隠し切れない風格を醸してるせいかコミュニケーションにも微妙な距離が生まれるみたい。
こういう孤独も上級者ならではの悩みだよね

自由度が高い分だけめちゃめちゃ遅い点はあまりつっこまれない、なんで？

遅いって何が？

たぶんこの辺の話
http://pc11.2ch.net/test/read.cgi/tech/1217813098/985

仮想関数まで否定することになるな

なぜタスクシステムを嫌うのですか？（上位５回答）

１．名前が気に入らない
２．名前を付けた人物が気に入らない
３．名前の「システム」の部分が気に入らない
４．自由度が高いのが気に入らない
５．隣のプロジェクトが気に入らない

「気に入らないから叩かれてるに過ぎない」として批判を過小評価したがってる様子が
ひしひしと伝わってくるけど、そういうワンパターンなかわし方を続けるのってのもどうなんだろうね

カプの開発で大規模に作っちゃったもんが
タスクシステム使いまくりでバグりまくりなので
そもそもの構造からいってすでにまずいってことがわかると困る人がいるのです

>>86
いやいや、俺はタスク使わんし・・・
批判の仕方が感情的だっつってんの

タスク派も嫌タスク派も、なんで自分のやり方が一番いいと思えるんだ？

>>88
二つの方法ですでに開発したことがあって比較した上での結論

早いレスども

タスクシステムという名称は新しいものらしいけれど、
それ自体はかなり古い手法だろ？
当時対比されるべき「もう一つのやり方」は
アセンブリで非構造化の逐次プログラミングだったはず
当時のタスクの本質がコンポーネント指向にあったんだろうと考えれば
取り込む要素があると思いこそすれ、非難する気には全然ならないんだよね

なんつーか、フラッシュ使いがハイパーカードを非難してるようなモヤモヤを感じる

ギャラクシアン - Wikipedia
http://ja.wikipedia.org/wiki/%E3%82%AE%E3%83%A3%E3%83%A9%E3%82%AF%E3%82%B7%E3%82%A2%E3%83%B3

タスクシステムの初出は１９７０年代

ちなみに旧ナ○コ系の一部では
ジョブコン（ジョブコントローラー）と呼ばれていたらしい
他にも派閥によって呼び名が・・・おっとだれか来たようだ

>>87
以前このスレでも話が出たMTなんとかのことですか？

>>90
> 取り込む要素があると思いこそすれ、非難する気には全然ならないんだよね
C++ で仮想関数として取り込み済み。

70年代の技術でオブジェクト指向を表現したのがタスクシステム

別にゲームに限らず、関数ポインタ＋データブロックという構造はよく使われてたけどな。
UNIX のデバイスドライバとか UNIX V6 の頃から、こんな作りだ。

>>92
だっせー

当時としてはすごい技術だったという話は

・いまタスク使ってるやつは擁護になってないからスルー
・アンチはそんなの知ったことじゃないから叩く

技術史が好きなヤツにしか意味のない話です

だからタスクシステムの要点は
　　・メモリ管理
　　・タスク管理
だって言ったじゃん

メモリフラグメントに対して固定長データという回答を出したのがタスクシステムの功績
そして扱うべきデータがどんなデータであれ管理レベルでは等価である事がタスクシステムか否かの分岐点だと思うね

ちなみに継承＋多態はメモリ管理、タスク管理のどちらから見ても最悪なばかりか速度まで低下して何のメリットもない
プログラムも複雑化してタスクシステムより尚悪い

あと余計な事かもしれないけど、このスレが迷走しやすいのは「何を解決するのか」を定義しないで話を進めるからだよ
例えば「ジャンルにとらわれない万能オブジェクト管理システム」なんていう途方もない事であっても目的があるとないのでは
議論の濃さが全然違う

最後に何度も言ってるけど、・・・タスクシステムを使うには現在のPCはオーバースペックすぎると思うよ
HSPでよくみかける固定長配列での管理よりわかりやすく速度的にも有利なタスクシステムなんて見たことないし
有意な差が出るとも思えない

わけのわからんこと言い出すからレスが止まっちゃっただろ

>ちなみに継承＋多態はメモリ管理、タスク管理のどちらから見ても最悪なばかりか速度まで低下して何のメリットもない
>プログラムも複雑化してタスクシステムより尚悪い
お前は継承も使わずにプログラムしてんのか？

Cには継承ないよ
haskellには継承なんてないけどそれでも綺麗なコードの実用プログラムが沢山書かれてるよ

なんで唐突に Haskell が出てくるのかわからんが
deriving とか知らないのか？

で、必死になってメモリ管理とか叫んでるひととか、バカにしようと必死な人とかは
スルーしたほうがいい気がする。

>>99
＞タスクシステムっていうのは
＞　　・メモリ管理
＞　　・タスク管理
＞の2種類から構成されている

前スレログ読みましたが、クラスを使うとフラグメントが発生どうのとかよく分からない話をして
数人から突っ込まれてたID:IuSgJyHuさんですか？たぶんそうだろうかと私は思うのですが。
ところであなたの言う「タスクシステム」とやらは具体的に何なのでしょう。これと思う実装例が
あるならそれを示してくれませんか。人によって定義が千差万別の俺俺システム「タスクシステム」
ですから、その言葉を発する人間が登場する度にこうやって確認せざるをえないわけで。
このように、確固たる出典がない、言い方を変えれば権威が不在というのは不便なものです。
技術用語としての存在価値が疑問視され、所詮はローカル用語といわれるのも頷けます

＞メモリフラグメントに対して固定長データという回答を出したのがタスクシステムの功績

ん？70年代中期・末期において主記憶をページング方式で管理することに新規性があったと。
簡単のために操作対象を固定長に分割・管理する、つまり固定長レコード方式というものに
新規性があったと。そういうお考えで？
当時のソフトウェアエンジニアの通念というものが集計できるならば、あなたの考えは当時としても
非常に珍しい類のものだろうと思います。かなりエキセントリックだろうと思います

まぁ確かに、計算機についての基礎教養が欠乏、というかむしろ知的水準が絶望的に低い人間
にとっては世の中のあらゆる仕組みはあらゆる時代を通じて常に新規性に満ちた凄いテクノロジー
なのでしょうけど…
そういう知的弱者・情報弱者・底辺階級をターゲットにした功績話を絶叫するのはあなたの趣意ですか？

i君乙
あいかわらず厭味だねぇ

変わらぬ芸風も、また一興

>>101
今は継承を使わないのが流行り
おまえだってhasAにしてるんだろ？
特に深い継承はアンチパターンになりつつある
継承＋多態の効率の悪さはいわずもがな
ゲームで使っちゃいけません

>>102
継承は基本的に汚いコードになると思うよ
設計書は綺麗になるけど

>>104
ギャラクシアン以外をタスクシステムと呼んでるのは某よっちゃんいかの人だけだよ
固定長レコードというCOBOL的なものをゲームに持ち込んだのは新規性がある
そもそも固定長レコードはフラグメント解消のものではなかった
バナナでクギを打った所に新規性があるんだよ
トンカチあるから必要ないよねっていうのは別の話

>>107
"is a" 関係でも継承使わないってこと？それだと無理なコードにならない？

効率が悪いというけど、そもそもゲームで CPU 処理時間がボトルネックになること
すら稀なのに、さらにそのうち継承＋多態によるものは数％以下でしょ？
ヘビーなループ内では問題になることもあるだろうけど、はじめから使わない前提に
する必要は無いと思うよ。

>>107
> 今は継承を使わないのが流行り
実装継承とインターフェース継承を混同しとるな。

>>107
> 固定長レコードというCOBOL的なものをゲームに持ち込んだのは新規性がある

固定長レコードはそれよりずっと以前のパンチカード由来。例えば19世紀末のタビュレーティングマシン
そこから進化したユニットレコード装置とかPCS（パンチカードシステム）とか。（※）
この時点でパンチカードのレコード長は大抵【80カラム】。これが処理単位だった
それがそのままコンピュータの記憶装置に使われ、その後の記憶装置の仕様にも反映された
アセンブリ言語のプログラムは一行80カラム。データも同じく。メインフレームのRecord Oriented Filesystem
初期のFORTRAN、OSのジョブ制御言語、COBOLなどなど、あらゆる処理の単位としてこの【80カラム（バイト）】が
当然のごとく登場した

FORTRANが登場したのは1950年代の半ば
COBOLが登場したのは1950年代の末

（※）更に遡れば19世初頭のジャカール織機だとか18世紀末のオルゴールだとか色々あるかもだが

（訂正）
> アセンブリ言語のプログラムは一行80カラム。
　↓
アセンブリ言語のプログラムは80カラム単位でロードされた。
----------------------------------------------------------

>>170
> そもそも固定長レコードはフラグメント解消のものではなかった

固定長レコードとか固定長データとかいう構造（要するに配列）が大昔から現在まで色んなところで
便利に使われてるのはその取り扱いが、実装が、極めて単純だから。
例えば
・データの所在（番地）が容易に算出できる
　　先頭番地+オフセット。このオフセットがレコード長*レコード番号で済む。
　　処理が単純化できるし回路も単純化できる。つまり真空管数（トランジスタ数）を抑えられる
　　占有面積も重量も放熱設備も電気料金も抑えられる。
・外部フラグメンテーションの制御が簡単
　　記憶領域を【容易に】再利用できる
　　最大長を決めてるからデータ書き換え時には旧データに新データを直接上書きできる
などなど。頻繁に書き換えるデータにはどれも重要な特性。

固定長なデータ構造はそのメリットの大きさゆえに、デメリット（レコード内の無駄。内部フラグメンテーション）
が許容されるケースは多い。COBOLも、COBOLが登場する以前の事務処理プログラムも可変長データの大半は
最大サイズを決めたうえで固定長レコード、それを収束した固定長ブロックで格納した。
今のRDBや簡素なDBMも基本的には同じ

>>170
> バナナでクギを打った所に新規性があるんだよ
> トンカチあるから必要ないよねっていうのは別の話

その例え何かおかしくないか。常温バナナで釘を打つのは確かに斬新な愚行だが

規模がまるで違うものを指してトンカチと冷凍バナナという話をしているのかなと前向きに解釈してみるか

大昔には科学者もエンジニアもシステム屋もみんな今とは比べ物にならないくらい貧弱なハードでやり繰りしてた。
FORTRANやCOBOLが登場する以前の計算機を駆使する人間は多かれ少なかれ今で言うところのハッカーじみた
技能やバッドノウハウを身に付けて自前のサブプログラム群をシコシコ作って自前ライブラリ用意したりした。
FORTRAN登場後も初期のFORTRANコンパイラの最適化は不十分で最内周ループ処理など頻繁に呼び出す処理の
アセンブリコードを自分で書く利得は大きかった。（※）

これらは日本のビデオゲーム業界が隆盛を誇るずっと以前の話

つまり、ド貧弱な装備でシコシコ戦うことを強いられ、セコくて貧乏くさい高速化テクやリソース節約テクを駆使してたのは
何もゲーム業界固有の境遇・逆境だったわけじゃない。もしゲーム業界固有だなどと思い込んでる人間がいるなら
そいつはルサンチマン君だ

（※）その後BLAS、LAPACK、MPIなどなど先人の開発した優れたライブラリが沢山登場し
　　　FORTRANコンパイラの最適化機能もとても優秀なので自前でシコシコする必要なくなった

（訂正）
>>170
↓
>>107

＞規模がまるで違うものを指してトンカチと冷凍バナナ
↓
本来の用途がまるで違うものを指してトンカチと冷凍バナナ

>>108
俺も継承は使わないほうがいい派
実装とかインターフェイスとか関係無い
そのメソッドやメンバがどのクラスのものであるのかわからなくなるのが最大の害だと思う
しかもオーバーライト（？名前忘れた）されると今度は同じ名前のメソッドがあって
どれを呼んでるのか本格的にわからなくなる

どうしても使わなきゃならんのがMFCみたいな変態実装になってる場合
自分に内包してるモンを継承使って書き換えさせるウンコソース
これは仕方がない

でも、できるだけhas aの関係でまとめたほうがいいと思う

>114
ttp://www.bizlogic.co.jp/techinfo/reconsider/inherit.htm

>新人プログラマほど継承を乱用します．特に新人が好むのは、
>コードの再利用のための継承です．（中略）
>新しいサブクラスが必要になって定義しようとしたら、親ク
>ラスに不整合があることを発見して修正．すでに定義済のサ
>ブクラス群に影響が出るためそれらを修正．その影響がクラ
>スのクライアントに出ることに気づかず、バグが連発．修正
>を繰り返すうちに設計し本人しか理解できないような継承階層が完成･･･

ｲｲﾊﾅｼﾀﾞﾅｰ

耳の痛いことだが、とりあえずタスクシステムのせいじゃないと思うんだw

ギャラクシアン以外をタスクシステムとして認めない原理主義者が現れてスレ的には
おめでいたいことだが、狭量すぎやしないか？
とりあえずメモリ管理については
・当時はそもそも自前のメモリ管理以外存在しない。
・メモリに制約のあるシステムならタスクシステムでなくても必要
だから、タスクシステムの絶対条件じゃないと思うんだが。

そもそも当時と今とでは
「メモリ管理」って言葉が指すものがだいぶ違うからな。

今のゲーム開発だと
メモリ管理モジュールの綿密なアーキテクチャの設計と実装を主に指すけど、
当時のは「管理モジュール」なんて呼べないような極々シンプルなものだからな。

連投ｽﾏﾇ　ちと古いが、>>44
ttp://www.t-pot.com/program/140_GameAISeminar4/index.html
Haro2のAIは階層型FSMとやらで実現されているそうだ。

>>41によれば「タスクシステム=FSM」だそうだから、タスクシステムでできそうな
気がするというのもあながち的外れではないかもよ。

もっとも、50がいう配列厨もFSMの一実装じゃねーのと思うので
タスクシステム=FSM=配列厨となって自己矛盾じゃないのかとか思ったり。
なんかFSMの解釈間違ってる？

>>117
CUDAを調べてて思ったんだが、メモリ・ワークをどこにとるかでパフォーマンスが
大幅に違ったりするみたいだし、いまどきのゲームのメモリ管理ってそうなんだろうな

３スレ目になったが、今だに喧嘩腰じゃないと議論もできないのか・・・

>>120
喧嘩腰に見える？そりゃすまん。

ああいや、個人を指してるわけじゃなくて、
スレ全体の雰囲気のことを言ってる。

>>118
> >>41によれば「タスクシステム=FSM」だそうだから

>>41では「タスクシステム＝FSM」というような趣旨のコメントはしてない
>>41までは「ここでタスクシステムと呼ばれてるものが何なのか知らんけど」という立ち位置でコメントしてる。ただ
そのままの状態でポエムを書き続けるのは難しいんで>>43以降はみんなのテンプレ（？）と思われる>>2を引っ張り出し
「タスクシステムとは>>2」という前提（or仮定）のもとでコメントした

そして>>43以降(ID:mdtDWXyh、ID:U55fYg17)でも「タスクシステム＝FSM」という趣旨のコメントはしてない
【非常に簡素でオーソドックスなFSMモデルの】ジョブ制御、【小規模で簡素なFSMモデルの】ジョブ制御
というような書き方はしてたが。これ通じ難かったんかな。一応意味を補足するためにダラダラ書いたんだが。
与えられたCPU時間でジョブを細切れにして処理の継続(continuation)に必要な手続きをユーザーに丸投げする
原始的なジョブ制御な

「70年代のハードに依拠する簡素なゲームにとっては無難なジョブ制御プログラムとかモニタプログラムの【断片】だね」
とも書いてるが、「70年代のハード」をちょっと修正すると「70年代〜80年代初頭にかけて登場した典型的な実装対象（※1）と開発環境（※2）」

（※1）基本的には○MHzの8bitCPUに○KBのRAMに○KBのROMのマイコンボード
　　　　これにOBJ（とかBGとか★とか）の表示や（固定）サウンドの出力やコイン制御のための回路や各種スイッチ（のインターフェース）
　　　　あと必要なら大容量ROMのバンク切り替え回路、などなどを付加したカスタムボード。
（※2）ここでは、8or16bitPC（或はマイコンボードをカスタムしまくってデスクトップPC化したTK-80BS　みたいなやつ）と
　　　　簡素なリモートデバッガ、エディタ、クロスアセンブラ（別にハンドアセンブルでもいいけど）で構成されるもの

（訂正）
○MHzの8bitCPU
↓
○MHzの8or16bitCPU

>>123
そういう立ち位置なんだとすると余計にわからなくなるのよ。

>「ここでタスクシステムと呼ばれてるものが何なのか知らんけど」

という立ち位置の人間が、ゲーム開発者ローカルな用語である「タスクシステム」
という用語とそのスレッドで、

>タスクシステムすげぇすげぇ言ってる超小規模開発・個人開発なら

てな形で批判的な言説を繰り返す理由が。てっきり

>タスクシステムを心の底から崇拝する人間が心の底から子バカにしている様子がたまに見受けられる 配列厨のコードそのものだ。

という形で小ばかにされたことをこのスレにぶつけてるんだと思ったよw 俺の立場としては

>ゲームプログラムでは、複数の構造体変数を管理することにより、複数のキャラクタを
>管理できます。複数の構造体変数を管理するための方法は、構造体をリスト構造で管理
>する方法と構造体を配列で管理する方法の 2 種類あります。
ttp://msdn.microsoft.com/ja-jp/academic/cc998623.aspx
の実装方式の一つだろうという前提で、そのメリットデメリットに興味があってここに参加しているのだけども。
ちなみに上記の例でいえば、マイクロソフトは配列厨だなw

>>120,122
タスクの話題に限ったことじゃないけど
賛成か反対かの単純な対立に流れることは多いね。
わかりやすいから盛り上がるけど白熱しすぎて喧嘩になったりする。
でもその対立構造が正しいとは限らなくて
良い意見が喧嘩に埋もれてしまったり。

ゲーム製作技術板なのに技術の話じゃなくてすまん。

>>126
確かにそうだ。俺も何が対立軸なのかよくわからなくなってるよw
俺は情報系の人間じゃないんで、ゲームのオブジェクトの相互の振る舞いは
FSMの一形態と見なせるみたいな発言を単純に面白いなと感心するんだけど。

配列で線形リストも組めない雑魚が配列をバカにしてるのを見ると悲しくなるし、
そもそもタスクシステム（特にこのスレで主流の複雑な実装）は速度的に不利なんだから
素直に配列さんごめんなさいって言えばいいと思う

この3連休でタスクシステムの仕様についてまとめるように、以上。

>>128 が、>>123だとして、わからん、お前のいうことはわからん！（大滝秀ry

>配列で線形リストも組めない
どこかで queue を配列で組む入門例があったけど、そんなものじゃないだろうし、
だとしてもその線形リストで、まさかタスクシステムをつくるわけじゃなかろうし、わからん。

>雑魚が配列をバカにしてるのを見ると悲しくなるし
どのレスを指しているのか、わからん！

>このスレで主流の複雑な実装
どれだよ！>>43なんか、
>誰が書いても同じようなものになるってくらい凡庸な、道端の雑草並みのありふれた仕掛け
とかいってるぞ。凡庸でありふれて複雑て、どっちなんだよ。

>速度的に不利
いや、ロジックの部分は大して食いませんてば。最近のゲームはそうでもないのか？

>素直に配列さんごめんなさい
君が配列ラブなのだけはなんとなくわかったよ。ごめんな。

>>128は書いてる内容から明らかに雑魚だなｗ

>>129
いまどきのタスクシステムの仕様
１．クラス名、構造体名に「Task」を含む
２．描画物とそれ以外の処理を同列に扱える（ことがある）

これくらいじゃね

「ゲームプログラマになる前に覚えておきたい技術」
を読んだけどタスクシステムなんて使ってなかった
普通に配列使ってて、配列の上手な使い方がのってた

やっぱプロは配列を使うんだね

>>133
２ｃｈでしかでかい声は聞かない（マジで）

>>133
はいはい、配列さんごめんなさい。

>>133は、配列の利便性と構造体を使ったリストの有用性の違いがわかっていないようだ。
もう一度、データ構造を見直すことをお薦めする。

>>133
おま・・・リスト使うか配列使うかの話かよｗ
セガがリスト使わないなんてありえないから、安心して両方の使い方を覚えような
ついでに二分木やハッシュも覚えておくこと

配列　：　削除、追加時のコストが高い。検索が速い
リスト　：　削除、追加時のコストが安い。検索が遅い

リストは単純に舐めるだけでも遅い
ここで比べるべきなのはデータの検索（巡回）・追加・削除がゲーム中にどれだけ発生して
それを処理するにはどんなアルゴリズムとデータ構造がベターであるかだ

データの検索（巡回）よりも追加と削除のほうが多いゲームなどない
だからリストより配列のほうがゲームに適している

リストの有意点とはデータサイズの見積りをサボれるという一点に尽きる
たしかに配列のリサイズはゲーム中にはとても不可能だからこれは魅力だ
しかし、ゲームを製作する上で場面ごとに必要なメモリの見積もりなんてやって当たり前の話で
その程度の理由でリストを使うなんておかしい

以上の理由からゲームでリストを使う事はない


弾幕STG等ひたすら衝突判定を繰り返す場合なら
検索アルゴリズムの都合で配列よりツリーがベターな場合もある
（STG製作技術スレで話題になってたエリア別ツリー構造等。FPSでよく使われるが）
だから配列がベストとは言わないが少なくともリストに劣ることは無い

いつからリスト対配列になったんだ?
タスクシステムは固定長データが重要とか言い出した>99あたり?

つか>126じゃないけどその対決って
どうしても勝ち負けを決めないといけないようなことなの?

>>137
もっともらしくウソついてんじゃねーよ
わざと言ってんだろ。明らかに初学者に対して悪意のあるウソだな

>リストは単純に舐めるだけでも遅い
誤り。「単純に舐める」＝シーケンシャルアクセスに有意差はない。
配列が有利なのはランダムアクセスの場合。

>データの検索（巡回）よりも追加と削除のほうが多いゲームなどない
比較方法の誤り。巡回回数と挿入回数を単純に比較しても意味はない。
コストの違いは以下のようにO記法で考えると分かりやすい。

・シーケンシャルアクセス（巡回）のコスト
　配列はO(n)：要素数が増えると処理時間が増える
　リストもO(n)：要素数が増えると処理時間が増える
・ランダムアクセス（インデクス値でアクセス）のコスト
　配列はO(1)：要素数が増えても処理時間は変わらない
　リストはO(n)：要素数が増えると処理時間が増える
・挿入、削除のコスト
　配列はO(n)：要素数が増えると処理時間が増える
　リストはO(1)：要素数が増えても処理時間は変わらない

O(1)はO(n)に対して非常に有利なので、
ランダムアクセスがありそうなら配列を、挿入がありそうならリストを選ぶのが一般的。
どちらもありそうなら実際に処理時間を計測してみるのが良い。
処理時間とは別に、メモリのフラグメントを嫌ってリストを避けたい場合は、
データ本体は配列構造に置き、管理はＺソートされたリスト構造に、
というように両方を組み合わせる手法もある（C++オブジェクトをメモリプールするのと同じことだけどね）。

とにかく、初学者は「どっちが勝ち」みたいな議論に振り回されないこと。
ぶっちゃけ実際に動かしてみて問題がないなら、なんであれそのやり方は正しい。

ID:mdtDWXyh、ID:U55fYg17、Xvygn8lQ　だが…。どうしたもんかね。とりあえず俺にレスした人から順番にレスするか…

> ID:K7xBu4Cw、ID:gOWsGtVr

>>123の時点では↑この人の諸元と過去発言を把握できなかったがサンプル数が増えたおかげで大凡のところ見当が付いたわ。
まず俺の一連の書き込み（ ID:mdtDWXyh、ID:U55fYg17、Xvygn8lQ ）から「タスクシステム＝FSM」という解釈に至るのは難しい（※）
�@FSMの意味をよく理解していない�A人の話をよく聞いてないか�B意図的に歪曲して解釈しようと努めている、のどれかだろう。
�@ならFSMや有限状態機械でググレとしか言えんし�Aならちゃんと読んでくださいとしか言えんし�Bなら正直相手にしたくない

奇遇にも過去にこの人物と同じ解釈「タスクシステム＝FSM」を披露したのはルサンチマン君のID:SCRh4oL7ただ一人だ。
ID:K7xBu4Cw 、ID:gOWsGtVrがこれと同一人物なのか知る由も無いが、かなり似通った特徴的な思考・読解の持ち主だなとは思う。

さて、この人は更に>>130で「>>128 が、>>123だとして」という謎めいた仮定を持ち出してるのだが、なんでこうなるんだろうね…
俺の過去発言と照らし合わせれば無理があると容易に分かるはずだよな
この人は>>130で自らそれを説明してみせているにも関わらず、その仮定が真であるという前提のコメントを書くだけで
その仮定が偽であるという（当然あってしかるべき、より可能性の高い）前提のコメントは結局書くことはなかった。妙だね

　・ただ単にコミュニケーション能力の不足、悪意のない、無知、短気、舌足らずゆえにこういう尻切れトンボで終わった
　・「>>128 ＝>>123であってほしい。いやむしろそうあってくれ。頼む。これで終いにしよう」という願望の現われ

まぁ後者ならそのご期待には添えないとしか言えない
俺は配列に「さん」付けしてもらうことも、ましてや便所のラクガキにおいて初心者（？）に謝ってもらうことにも興味がない

（※）素直な思考の持ち主ならば、ゲームプログラムの中で【状態を保持し遷移する】ような要素、つまりFSMモデルを適用しやすいもの
としてまず初めに思い浮かぶものといえばシーン（オブジェクト）やエンティティだろう。そういったもの⊂FSMと解釈するならわかる

＃>>2そのものをFSMとして説明することはできるが、これを言い出したらプログラムも電子計算機も社会基盤も自然環境も惑星も
＃銀河も宇宙もFSMモデルで説明できるという話になる。ぬるま湯に溶かしたハナクソを構成する分子の振る舞いも、乾いて風化した
＃ハナクソ粉体の振る舞いもFSMモデルで滔々と説明できるという話になる。こういう話は埒外であり、するつもりはない

話が難しすぎてついていけません＞＜

>>140が誰と何の話をしてるのか全然わからんけど
>>2＝「ジョブコン」＝ＦＳＭという話は直感的で分かりやすいと思うぞ

てか名称「タスクシステム」は人によって定義が違うから使うな。議論が混乱する

ああ、>>140をフォローしたつもりが逆だったらしい
>>140はＦＳＭって言い方が抽象的すぎるっつってんのね？
了解。もう言わん

>>137
冗談だろって思って配列にしたら速くなった
たぶんキャッシュ周りも関係してる気もする

>>140
>�@FSMの意味をよく理解していない�A人の話をよく聞いてないか�B意図的に歪曲して解釈しようと努めている、
どれもそれなりにあてはまるとは思うが、あえていうなら�Aかなw

とりあえず�Bについてはそういう意図も一部あったんでそれは謝っとくよ。
ただ、前提として >>40,>>41で繰り返された

>ここでタスクシステムすげぇすげぇ言ってる

というような傾向は無いとはいわんけど（タスクシステムスレだし）、実装で苦労してるみたいな話が中心で、
mdtDWXyhが挑発的な言辞を繰り返さなきゃいかんほどかね？と思うけどな。

>「タスクシステム＝FSM」を披露したのはルサンチマン君のID:SCRh4oL7ただ一人だ。
これは順番が違う。同じレスを指してると思うんだけど、

(1)「タスクシステム＝FSMだ」という発言があった。
(2) そのあとに >>41で「原始的なFSMモデルのジョブ制御」という発言があった

ので、同一人物か同じ立場の人間が批判的な意味で FSMという単語を使ってるのかな？と思ったんだよ。意味合いは違うようだけどFSMという用語を使うレス自体が少なかったからそこは勘弁。

その上で、ゲーム上のオブジェクトの振る舞いをFSMモデルで捉えることはできるだろうけど、それは配列で構成されたゲームについても言えることで、タスクシステム（実装）批判につなげるのはおかしいんじゃないの？と皮肉ったつもりだったのよ。

ただまあ、タスクシステム（ジョブコンでもいいや）の適用範囲とか実装上の問題点と
か、そういう流れになってくれると嬉しいんで、「これで終わりにしてほしい」という
のも正直なところ。だからピンダッシュに反応しすぎた俺も悪い。もうだまっとく。

>>139と>>137のお話について横から首突っ込んで初学者向けにポエムを書いてみるか

実際の処理速度を語るとき、ランダムアクセスといったら、メモリアドレスを基準にしたランダムアクセスという話も当然絡んでくる
データ構造上の順番（連結リストなら繋がれた順番）を基準にしたらリニアアクセスだよ、といってもメモリアドレスを基準にしたら
ばっちりランダムアクセスになっていました、という状況も当然あり、この場合は処理する要素数と要素サイズと実装対象によっては
べらぼうなペナルティを受けたりする。ので

>>リストは単純に舐めるだけでも遅い
>誤り。「単純に舐める」＝シーケンシャルアクセスに有意差はない。

これは状況ごとにプロファイラなりアナライザにかけて検証してみないと分からないというツマラナイ結論に帰結する
ので

>とにかく、初学者は「どっちが勝ち」みたいな議論に振り回されないこと。
>ぶっちゃけ実際に動かしてみて問題がないなら、なんであれそのやり方は正しい。

だよな

（続く）

（続き）
ただし、連結リストを>>2のように使う場合と、ジョブの種類別に配列でデータを固めてる場合（※）を比較すると、前者は不利な状況に追い込まれる
>>2は何でもかんでもごった煮の連結リストでおまけに各要素は好き勝手にジョブを指定してくる。プライオリティ（？）とかいう変数を何に使うのか
知らないがこれでソートされてようが各要素で毎度毎度サブルーチンのアドレス（関数ポインタ）経由でジョブを実行させている
つまりハードウェアにとっては要素ごとに何のジョブを実行するのか予測が難しい。どのジョブが実行されるにせよ、その内容が大して代わり映え
のない超単純な数値積分であれば、分岐予測で速度を稼ぐハードウェアにとっては嫌がらせに近い仕掛けであり、ブチ切れる可能性が高い

○万のパーティクル（数千の通常弾に数千の煙に数千の閃光に数千のフラグメント）を撒き散らす物量ゲーとかなら、そういう要素には
>>2ではなくジョブの種類別に配列でデータを固めて一括処理するほうが速度が出やすくなる。
趣味プログラマであれば、今様のゲーマー仕様PCで実験してみればすぐに確認できる

（※）この手の配列厨コードは、Zソートを回避するあるいはCPUによるZソートを回避する色んな工夫とセットになる。
単純な加算合成だけでなく、アルファブレンドなしアルファテストのみテクスチャに描いてグレア処理して合成とか色々

>要素ごとに何のジョブを実行するのか予測が難しい

その辺は面白い、つか考えてなかったな。
以前、ビデオキャプチャしたYUY2をP4-2.4GHzでソフトRGB変換する、ってのをやってて、
30万ピクセルをfloat演算して1フレーム8msec.程度でで処理できてたから、いまさら数万の
オーダーでがたがたいうなよって思ってたけど、言われてみれば配列のシーケンシャル
処理に近いんで、キャッシュの効かなそうな処理なら、どのくらいで処理してるのか確
認すべきだな。

>プライオリティ（？）とかいう変数を何に使うのか 知らないが

これはメリットというより必要悪に近いんじゃないかな。ゲーム上のオブジェクトを
動的に生成するタイプのタスクシステムだと、処理順が不定になってしまうので、
プライオリティという形で処理順を明示できるようにしてある、みたいな。
そこまでして処理順を確定しないといけないような場面があるのかどうかは
ちょっとわからん。初心者なもんで。

処理順は固定じゃないと駄目なんだよ
壁当たりの判定を保持するような物体の当たりチェックは
普通の物体のチェックより後にやらないと
簡単にすり抜けが発生してしまう

俺、当たりのチェックだけはタスクシステム使ってようが
直書きしたほうが安全な気がする

プライオリティについては>>2のWhite PaperとLogician Lordでは
リストに連結されたタスクの中身が何なのかを示すために使われてる。
例えばここだな。

http://web.archive.org/web/20041012012504/www.hh.iij4u.or.jp/~peto/Games/task_03.html
>あらかじめ、優先度とタスクワークの構成を決めておきます。優先度は、例えば次のようになります。
>　* 0x1000: ジョイスティックの入力解析
>　* 0x2000: 自機の制御
>　* 0x3000〜0x3fff: 敵の制御
>　* 0x4000〜0x4fff: 背景の制御
>　* 0x5000: キャラクタ表示

一つのリストに纏めようとするからプライオリティなんてものが必要になる。
必要悪どころかはっきり悪だと言ってあげるよ。
この仕様だとタスクを増やすたびに追加すべき位置をサーチしなければならない。
またタスクの中身を知るために優先度を確認していかなければならない。

enemyはenemyリストに、backgroundはbackgroundリストに入れりゃいいんだよ。
別に配列でもいいが。

ピンキーネット所属の藤松みこを最初の辞職に追い込んだは
フリーで湯沢と言うビデオカメラマン（元アートハウスゴン社員）から陰部に指を挿入されたことが原因だ！。

当時現役だった彼女にはショックな出来事で事務所とメーカー巻き込んで大騒ぎ。
カメラマンは土下座しただけで金銭は請求されなかったのは何故か疑問だったが…。
（意外と優しい事務所だったりして…。）

普通は事務所から脅され賠償金を請求され業界追放に追いこまれるだろう！

ちなみにセクハラ事件でカメラマンの追放まで追い込んだ領家ゆあの前事務所とは雲泥の差だ。

また普段から公私混同するカメラマンとして有名だし次回彼の標的になる10代のアイドルが気になるところだ。

ttp://www.page.sannet.ne.jp/hirasho/diary/diary0811.html#30

>タスクシステムについて触れられてない、とか書かれているのを見つけた。
>何それ？おいしいの？直感的でない、変に抽象化されてデバグしにくい、実行順がコードの形で書かれておらずメンテしにくい、
>等々、どう考えてもあれが有効な場面があるとは思えない。使っている人を問いつめたことがあるが、結局利点は出てこなかった。
>一つ考えられるとすれば、独立性をきちんと保って各タスクを書いていればマルチスレッド対応がしやすそう、ということくらいか。
>しかし、どうせ複数タスクから同一のクラスインスタンスを参照してたり、妙なシングルトンやらグローバル変数を見てたり、
>依存関係が不適切なためにスケジューリングが複雑化したりするに違いなく、本当にマルチスレッド実行していい状態にあることを保障するのは容易ではない。
>よほど訓練されたチームでなければそんなことをする気にはまるでならない。

だからタスクシステムなんて聞くのは２ｃｈだけだって
ここの信者だけだよ威勢がいいのｗ
だって現場で聞いたことないもんｗ

大手ならどこでも通じる

>>158
そしたら下請けに流れてきてもおかしくないじゃん

俺は自分からは使わんが、他社の２回くらい見たぞ？
もちろん>>2そのままじゃなかったが、ネットでよく聞くから増えてんじゃね

つーかさー、NDSのサンプルよく読んでみろよ・・・
現場で見たことないって騒いでるやつはDS開発やったことないのか？

ｻﾀｰﾝしかやったこｔない

俺は、据え置き型ばっかり

ttp://www.page.sannet.ne.jp/hirasho/diary/diary0812.html#2
ひらしょ氏、今日の日記でも検討してるな。

いずれにしても銀の弾丸じゃないのは当然として、鉛の弾丸かどうかは微妙なところか。
否定派のつもりはないけどね俺。

>>163
いいなこの人
説明に難しい言葉を使わないようにしてるし
ちゃんと人に伝えようという文章に好感が持てる

たしかに
タスクシステムとは可搬性と再利用性に優れた素晴らしいシステムなんです
とか繰り返してた人たちの話よりよっぽど分かりやすい

ひらしょ氏の日記見て来ますたｗ

つか、ヒープのフラグメント避けるためにサイズの違うデータでも固定長メモリ確保するとか
俺が学生時代にごくナチュラルに作ったものだが・・・。メモリプールという言葉の存在すら知らないまま。
まずさ、ゲームで使われている技術なんて、3Dやら除けば全然大したことがなくて
独自性などどこにもなということを認識するべきじゃなかろうか。とりわけ今となっては。

> だからタスクシステムなんて聞くのは２ｃｈだけだって

昔のアマゲ周辺でそれなりに聞いたかな。某よっしん氏等も使ってた記憶が。
ただ、言葉は聞くけど実体は人それぞれという類のものだよね。
オブジェクトをリストで繋げて更新ルーチンへのポインタ保持してるだけで
俺がガンダムだって言っても、言葉の定義なんかないんだから自由なわけだしさ。
実際、昔言ってたタスクシステムもその程度の代物でしかなかったと思うんだよ。

そうだな、それでも、C++がまだ使われていなかった頃はそれなりに画期的、というのもちげーな
「ああこうすればいいのか」と人を感心させられる程度のものではあったかもしれない。
ひとつのテクニックとして名前をつけて呼ぶ価値があったと思うよ。10年以上前の話。

でも、今となってはこんな普通にC++で書けば自然にできるようなことをシステムなんてとても呼べないし、
それでもタスクシステムという名前にこだわってる人は、もっと高度な何かを語ってると思うんだが

何それ？っていうか、要らんよねぶっちゃけというか、コード見せれ、というか

俺としては、C・アセンブラ時代に言ってたタスクシステムが、ものすごいタイムラグを経て、
一部のアマチュアに、おかしな形で伝わってしまっただけじゃね？と思っているのだが。
もしそうだとすれば、素人を混乱させる有害情報でしかないので火消しが必要なレベルだと思う。

そうでないなら、とにかくコード見せて。

>164は>165を指してるんだよね。
http://pc11.2ch.net/test/read.cgi/gamedev/1036512390/860-862

そのスレ読んだ
LGPLを含むEXEがLGPLに感染してるなんてライセンス文読めば一目瞭然のことを
何とか超解釈で否定しようとしてる子が定期的に出没していて
その理屈は違くね？という人達が理詰めで外堀から確実に徐々に埋め立ててる
そんな感じ？

物事をひん曲げて解釈したがる人を諭すには
駄目押し気味でもああいうのも有効かなとはおもた

>>167
あのスレのレスは三行でまとめて欲しい

>>168
あのスレごちゃごちゃしすぎてて、自分で何書いたかさえ忘れる

ところで、感染しないライセンスなんて無いよ。例えパブリックドメインであっても。
結合したら二次著作物なんだから。

>>169
二次利用に縛りをかけないライセンスは存在する。

ていうか、パブリックドメインとは、だれのものでもない存在だから、
二次著作物とかそういう縛りもない、はず。

>>170
うーん、有名どころで二次利用に縛りをかけないライセンスを見たことないけどな。
少なくとも「本ライセンス文書を同封しろ」と書いてある。

パブリックドメインに関しては著作権者が権利放棄してるから、利用に縛りはないだろうけど。

>>169-170
おまえらあっちのスレでやれ。
>>168
むしろ逆効果にしか見えないのだが、
前スレで釣り宣言してたからそれで狙い通りなのだろう。

三次利用以降に縛りをかけない事、という縛りをかけてるものはあるな

数年前のとある同人STGのメイン関数。趣味だから何も考えてないね。仕方ないね
int _tmain(int argc, _TCHAR* argv[]){
　　boost::shared_ptr<GAMEENV> gameenv(new GAMEENV);　　　//D3D,SOUND,INPUT,USERDATA,etc
　　boost::scoped_ptr<SCENE> logo(new LOGO(gameenv));　　　　//ロゴ画面
　　boost::scoped_ptr<SCENE> demo(new DEMO(gameenv));　　　//デモ画面
　　boost::scoped_ptr<SCENE> title(new TITLE(gameenv));　　　　//タイトル画面
　　boost::scoped_ptr<SCENE> config(new CONFIG(gameenv));　 //コンフィグ画面
　　boost::scoped_ptr<SCENE> stage1(new STAGE1(gameenv));　//ステージ1
　　（…中略…）
　　boost::scoped_ptr<SCENE> stage8(new STAGE8(gameenv));　//ステージ8
　　boost::scoped_ptr<SCENE> ending(new ENDING(gameenv));　 //エンディング
　　logo->Run();　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　//ロゴ画面再生
　　try{
　　　　while(1){
　　　　　　demo->Run();　　　　　　　　　　　　　　　　　　　　　　　　　//デモ画面再生
　　　　　　switch(title->Run()){　　　　　　　　　　　　　　　　　　　　　//タイトル画面再生
　　　　　　case TITLEOPTIONTYPE_GAMESTART:　　　　　　　　　//ゲームスタート
　　　　　　　　try{　//STAGEEXCEPTIONTYPE_GAMEOVERという例外を投げるまでゲーム続行
　　　　　　　　　　stage1->Run();stage2->Run();stage3->Run();stage4->Run();
　　　　　　　　　　stage5->Run();stage6->Run();stage7->Run();stage8->Run();
　　　　　　　　　　ending->Run();　　　　　　　　　　　　　　　　　　　　 //エンディング画面再生
　　　　　　　　}catch(STAGEEXCEPTIONTYPE){;}break;　　　　　　 //GAMEOVER例外投げてきた
　　　　　　case TITLEOPTIONTYPE_CONFIG:　　　　　　　　　　　　//オプション画面再生
　　　　　　　　config->Run();break;
　　　　　　}
　　　　}
　　}
　　catch(GAMEEXCEPTIONTYPE){;}catch(...){return EXIT_FAILURE;}//糞ゲーだからやめるらしい
　　return EXIT_SUCCESS;
}

_tmainじゃなくて_tWinMainだったかな。よくおぼえてないや
各シーンはいわゆるベタベタの配列厨コード。元HSパーだから仕方ないね
でもメモリもGPUリソースもジャブジャブ使いまくったおかげで
見た目はバリバリのイケイケになったよ。動作も軽快だったよ。自惚れだね

>>174
たのむ
なにが言いたいのか最後に書いてくれ

俺が気になるのは、メインループが本当に必要なのかどうかだな
タスクシステムも、それ以外のＣ＋＋コードでも、なんでメインループ作るん？いらなくね？
普通に書けばいいじゃん（普通ってなによ）

stage1->Run()はstage1が終わるまで返ってこないんだろ。
いずれにせよゲームなんて毎フレームの同じ処理の繰り替えしなんだから
どこぞかにループは存在するのが当たり前だと思うが。

>>176が言う普通ってどんなコードなんだろうね

あーすまん
メインループはどんなプログラムにもあんね

なんかさ、１フレームごとに回るループを作るやり方と
作らないやり方（あちこちでupdateする）について
急に気になって言ってみたんだが
やっぱどっちでもいい気がしてきたからいいや

スレッド作るにしろなんにしろ
どこかでスケジューラが回ってるがな

>>179
> 作らないやり方（あちこちでupdateする）について
> 急に気になって言ってみたんだが

それは使ってるフレームワークが裏でループ回してupdate()呼んでるんだろ。
あるいは割り込み駆動の可能性もあるが。

>>175
＞見た目はバリバリのイケイケ
気になるな。

>>176
>たのむ
>なにが言いたいのか最後に書いてくれ

地域担当の教団勧誘員に>>174を見せると彼の顔はみるみる青ざめ、ついには目を背けてしまいました。
ただごとでない様子を感じ取った私は恐る恐るその訳を尋ねました。すると彼はおずおずと耳元で囁くのです。
「それはいけない。凶兆が見えます。そのようなものを作っていては遠からず仏罰が下るでしょう。南無妙法蓮華」
>>174は彼らの"先生"の教義に反する、知性体として恥ずべきお猿さんコードなのだそうです。私は狼狽してみました。
幼少の砌よりﾂｸﾗｰにしてHSPerである私の深層に眠る劣等感の残滓の存在をESPで見抜いたのか、彼は目を細め
「安心なさい。今からでも間に合う。私共のように三宝( 　*　 )に帰依なさい。そうすれば必ず道は開けますよ」
と仏様のような微笑みを湛えながらビール券とこの案内状をくれたのです

>>183続き
(∀・　*)【三宝】…■松浦本■やね本■逆引き本
┌──────────────────────────────────────────┐
│　【集会のご案内】　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　 　 　 　 　 　 　 　 　 │
│ 　 タスクシステム（>>2）こそ失われた聖杯、伝説の神器、至高のオーパーツ、現代のエクスカリバー　 |
│ 　 私どもの教団では、身も心も何もかも唯一無二のリンクリストに捧げることで驚きのTCBがプライ　 ｜
｜　　オリティすることをお約束します。奮ってご参加ください　　　　　　　　　　　　　 　 　 　 　 　 　 　 　 　 ｜
│　　タスクシステム総合スレ part3　　　　　　　　　　　　　　　　　　　　　　　　　　　　　 　 　 　 　 　 　 　 　 ｜
│　　http://pc11.2ch.net/test/read.cgi/gamedev/1226199100/l50　　　　　　　　　　 　 　 　 　 　 　 　 　 │
｜　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　 　 　 　 　 　 　 　 　 ｜
｜　【社説】反動分子の煽動記事に惑わされてはならない　　　　　　　　　　　　　 　 　 　 　 　 　 　 　 　 　 ｜
｜　　http://diary.imou.to/~AoiMoe/2008.12/early.html#2008.12.02　　　　　　　　　　　　　　　　 　 　 　 　 ｜
｜　　http://d.hatena.ne.jp/naoya2k/20081201　　　　　　　　　　　　　　　　　　　　　　　　　　　　 　 　 　 　 ｜
｜　　http://qo.sakuratan.com/2008/07/24/タスクシステムのこと。/　　　　　　　　　　　　　　　 　 　 　 　 ｜
｜　　万物を支配するは唯一無二のﾘﾝｸﾘｽﾄをおいて他に無く､秩序をもたらすはTCBのﾌﾟﾗｲｵﾘﾃｲのみ。｜
｜ 　 この崇高なる輪廻転生の法を冒涜し踏み躙る邪教徒共はママの愛情が足りなかったに違いない。 .|
｜　　敬虔なる信徒諸君は彼らの妄言に惑わされることなく修行に励みたまえ。そして最終解脱者となっ.｜
〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜

ビール券に弱い僕は誘われるままホイホイとこのスレにやって来たんだね

そろそろタスクシステム総合スレじゃなくて
ゲームシステム総合スレに名前変えね？
>>2を使ってる人は皆無なわけだし

いや、ここ隔離スレだから…

>>185
あー、ゲームシステム総合とか間抜けたスレタイいちいち考えなくていいから
既存スレちゃんとあるんで。こっちでは撲殺天使の人もあっちでは普通だから

ゲームにおけるデータ構造・クラス設計・パターン2
http://pc11.2ch.net/test/read.cgi/gamedev/1211544659/l50

既存スレからタスクシステムを隔離するためにこのスレは作られたんで
このスレが誘蛾灯として機能するにはこのスレタイは好都合この上ないんで
悪いけどお前が思ってる以上にそこそこ需要あるんだわ

＞>>2を使ってる人は皆無なわけだし

は？お前が憤死しても代わりは幾らでも湧いてくるから心配しなくていいって

やね本はプレミア付く程のレア物

>>166
何がいいたいかわからん。動的インスタンスリスト巡回アップデートwの具体的なメリットデメリットを指摘すればいいんじゃないか？
ttp://www.issei.org/
そのひらしょ氏の本を手伝ったらしいPGさんのブログ。タスクシステムらしきソースがある。
問い詰めた知人てこのひとかな？
例えば>>174をタスクシステムで書いたとして、単純に比較すればそりゃ
>直感的でない、変に抽象化されてデバグしにくい、実行順がコードの形で書かれておらずメンテしにくい
コードだと思うんだよ。んで、それでも使いたいメリットあるのか？て話だよな。

俺は本職のゲーム屋さんじゃないんで失礼かもしれないが、わかりにくいところもあるけど、
結構融通が利いて便利かもと思ったよ。
ためしにプロトタイプを作ってて、「ここで一発エフェクトが欲しいな」と思ったところで、new してリストにつなぐだけで動くってのはちょっと感心した。

あと、メインループ周りを作ってしまえば、そこをいじらなくても別のゲームが作れるのは
なれれば安心感があるな。
ただ、万人にお勧めできるかつと、それはちょっと難しいかもとは思う。

>>189
>ためしにプロトタイプを作ってて、「ここで一発エフェクトが欲しいな」と思ったところで、new してリストにつなぐだけで動くってのはちょっと感心した。
これホントは動かないのが普通なんだよ
裏でグローバル変数でつながってるからnewするだけで動くように見えるだけ
可能でしょ？そういうの？
本来あるべき手続きを見た目見えなくするもんだから
後で「え？そんなところと関係あるの？」っていう部分がボロボロ出てくる

結果これ以上ないデスマになる

>>190
レス早すぎるだろw
>後で「え？そんなところと関係あるの？」っていう部分がボロボロ出てくる

そういう不安は、まあ、あるな。自分が把握していられる範囲ならともかく、
「3日前のコードは他人のコード」な人（俺だ）とか。

＞裏でグローバル変数でつながってるから
これ、このスレでよく批判の対象になってるけど、俺が見た範囲では
それぞれ listはprivateにしたり一応保護する工夫をしているように見えるけど
「オブジェクト同士が相互参照できるならグローバルと同じで無意味」ってこと？

>>191
タスクシステム云々ってよりグローバル変数の駄目な理由そのものじゃん

>>189
> タスクシステムらしきソースがある。
どこに？

私は、いまどきのハードウェアならタスクシステムは捨てて、役割ごとに std::list<> なり
配列なり作った方が良いと思ってる。

http://www.issei.org/blog/archives/000225.html

>>193
名前欄入れてらっしゃるけど、ご本人様で？

そのエントリによると、新人研修でタスクシステムのようなものを教えてる
ところは実在するわけですかね。

散々タスクシステムを崇拝してきた人間も
ひらしょーさんの「なにそれ？」で完全に散ったなｗ

入門を脱したばかりの奴が入門記事を書く悪循環に、
ちょうどタスクシステムがはまっていた感はあったな。
CodeZineとか。

>>193
私は新人研修に関わってないので、どういう文脈で紹介されたのかは不明です。
研修中の息抜きで、単なる昔話してたのかも。

>>193 ありゃ？そのページをみて書いたんだけどw
釈迦に説法だと思うけど、一応、

・狭義のタスクシステム
　>>193のリンクで（ここにあるようなモノ）としているような古典的なもの
・広義のタスクシステム
　古典システムをクラスとstd::listなどで実装しなおしたもの

というような定義がこのスレでは何度か上がってて、オブジェクトの種類ごとに
リストを分けるべき、てな議論もあるんで、>>193のサンプルや、ほかに公開している
ものはその範疇かな、と思った。
　定義自体あいまいなところがあるので、タスクシステムと呼ばれたくない、
ということであれば申し訳ない。

毎フレームstd::listに繋がったメンバ関数を呼ぶだけのものに
システムとか名前つけること自体が厨臭くてダメだろ。

GUIアプリのデザインパターンとしてなんらかの名前があると思うんだけどなぁ

>>199
命名自体は思考の道具として必須だよ。
りんごを「りんご」と呼べないならそれをどう頭の中で扱うのか？

ただ、付ける名前の好き嫌いと妥当性はあるだろう。
自分の子供に「悪魔」と名づけたら批判される。
まあその程度なんだが。

大袈裟過ぎるのは確かなんだが
いまさらどうにもなんないよなぁ

>>202
タスクもシステムもOSを意識してしまう用語だからな。
言葉の意味的には >>92 のいう　ジョブコン（トローラ）の方がより厳密かなあ。

名前なんかどうでもいいじゃん、あほらしい

しかし、タスクシステムを崇拝してる奴等は
自分が学ぶ技術に名前や名称がほしかったんだろうな
理由はきっとそっちのほうがたしからしく見えるからかな？

でもそれもひらしょーさんの「なにそれ？」で
タスクシステムは世に通じない名称ということを実証するのに十分だったな
な〜む〜ｗ

ひらしょーさんと同じことを説明してくれてる人はたくさんいたけど
名称の魔力があったから信者はまったく聞き入れなかったよね

>>205
信者決め付け脳はウザい。

内なる敵と戦っているんだよ。

http://game.watch.impress.co.jp/docs/20070131/3dlp.htm
システムはどうかしらないけど、ゲーム業界でタスクは一般的になってると思うよ。
俺が書いたコードをソフトメーカーの人に見せたら、汎用タスクだねって言ってた。

>>208
まぁその記事の「タスク」は、MTフレームワークの用語としての「タスク」だと
思うが。

>>209
このスレで言ってるタスクシステムとなにが違うの？

「タスク」はプレーヤー、敵、カメラ(視点)、ライティングなどの同時多発的に発生する
ゲームを進行させる処理そのもののことを指す。
各タスクには、プレーヤータスクの更新処理、描画処理。
敵タスクの更新処理、描画処理といった形で「更新処理」、「描画処理」が存在する。

>>210
まあ、似たようなもんだろ

ただ、あんまりうまくいってねぇ気がするね
だってそんなもん作ったわりにそれほど見応えのあるソフト連投してねぇし

ジョブコンがアンチパターンである理由

１．グローバル変数（または静的クラス変数）を多用しがち
２．抽象的すぎる（シーン、入力処理、衝突判定、描画物などを同じ抽象レベルでリスト化できてしまう）
３．２のためにプライオリティ変数のような順序制御機構が別途必要になる
４．３のために処理の流れがコードから読み取りずらくなる（このスレの「ＦＳＭが云々」のくだりはこれを指摘している？）
５．配列の方が速い（ＣＰＵ最適化厨乙ｗいやマジでがんばれｗ）
６．ひらしょー先生が批判している（よく知らんけど・・・）

最近の流れだとこんな感じか？
個人的には４が致命的だと思うな

※２は、言い換えると「様々なコードの断片や描画物を、必要に応じて追加・削除できるオブジェクトとして
　同じ抽象レベルで扱える」というメリット的な言い方も出来るかも知れん

タスクシステム否定派　＝　人の意見に盲従するヘタレ

ということはわかった。

＞１．グローバル変数（または静的クラス変数）を多用しがち
変数の参照範囲は必要なだけ広く、そして最小範囲
タスクシステムだからこれが出来ないという理由はない
少なくともリストや配列を使った非タスクシステム比べて
変数の参照範囲を広くとる必要などない

＞２．抽象的すぎる（シーン、入力処理、衝突判定、
＞描画物などを同じ抽象レベルでリスト化できてしまう）
多態を使ったリスト巡回だと抽象レベルが一つ下がるけど
その為に、例えば後から「エフェクトクラスを追加しよう！」と
思ったときにクラスをさかのぼって親クラスを修正しなければならず
また、その親クラスから分岐した子クラスを編集する必要もある
タスクシステムはクラスでいう型を撤廃して、それをデータに
落とし込んでいるがそのおかげでコード修正の影響範囲を
局所化することに成功している

＞３．２のためにプライオリティ変数のような順序制御機構が別途必要になる
ZソートするのだってZ値必要じゃん
順番が必要なら�H・・・じゃなかった、値が必要なのは当然
どうしてもプライオリティ変数が嫌ならタスク追加時にソートしとけ
（プライオリティ変数使ってる人って毎フレームソートしてるの？バカなの？）

＞４．３のために処理の流れがコードから読み取りずらくなる
＞（このスレの「ＦＳＭが云々」のくだりはこれを指摘している？）
順序制御機構があるならコードは見やすいだろう
関数ポインタのせいで直感的ではないという指摘ならともかく

＞５．配列の方が速い（ＣＰＵ最適化厨乙ｗいやマジでがんばれｗ）
確かにタスク巡回（多目に見積もってもせいぜい数十万タスクだろう）を舐める速度が
数倍余計にかかっても今のCPUなら有意な差ではない
当たり判定やグラフィック描画との処理時間の割合が違いすぎる
確かにその通りだ
ただ、実際にどういった処理が行われるのか想像して欲しい
1. 現在のタスクから次のタスクが存在するポインタを参照する
2. 次のタスクをメモリに読み込む
3. 読み込んだタスクからデータを参照する
さて、データを参照したのは何回だろうか
しかも「次のアドレス」ではなく「指定したアドレス」から読み込むことがどれだけ不利なことか・・・・
リストと配列の速度差に関しては、実際にベンチを取った人には説明するまでもないと思う
たしかに実用上は大した差ではない
しかし、CPU時間は余り気味の現代社会においてもメモリ帯域はPS3ですら不足している昨今
リストを使ったプログラミングは複雑さが増しているばかりではなくソースも見づらくなり
その上速度まで低下していてはどうやって弁解する事ができるのか不可解である

＞６．ひらしょー先生が批判している（よく知らんけど・・・）
おまえら本買ってないだろ？
どうみてもタスクシステムです
本当にありがとうございました

最初は状態変数で分岐させてるけど、後半はタスクシステムじゃねーか

>順序制御機構があるならコードは見やすいだろう

ソースコードの流れる順番に処理が行われていないから読みずらいっつってんの
なんで見やすいって話になるんだよ
あと関数ポインタ／仮想関数／無名関数をアンチパターンとするのには同意しかねる


>おまえら本買ってないだろ？
>どうみてもタスクシステムです

ひらしょーは正直どうでもいいｗ

>>215
>変数の参照範囲は必要なだけ広く、そして最小範囲
>タスクシステムだからこれが出来ないという理由はない
>少なくともリストや配列を使った非タスクシステム比べて
>変数の参照範囲を広くとる必要などない
それってソースコード読む人にどうやって伝えるの？

>>215
> 少なくともリストや配列を使った非タスクシステム比べて
> 変数の参照範囲を広くとる必要などない
単一の型・固定長ブロックを使ったタスクシステムだと、依存関係を明示する
ために引数を使えないのが痛い。

Scene -> Map -> Character, Hit

たとえばクラス構造として Scene クラスが Map を包含し (メンバ変数名 Scene::map_)、
Map が Character (Map::character_) と Hit 判定処理 (Map::hit_) を包含してるとする。
これだと

Scene::exec() { map_.exec(*this); }
Map::exec(Scene& scene) {
　　for (int i = 0; i < character_.size(); ++i) { character_.exec(*this); }
　　hit_.hitCheck(*this);
}

こんな感じで、Scene <-> Map <-> Character, Hit の相互依存関係を明示できる。
Character から Hit にアクセスする場合は、いちど Hit::exec() から引数経由で
Map を呼び出して、それが Hit を呼び出す。

また、Scene から Map に公開するメンバ関数を制限したい場合には、Scene の
既定クラスとして純粋仮想関数だけ定義したクラスを用意し、それを Map::exec の
引数に渡せば OK。多少回りくどいが、メッセージのパスがシンプルになってコード
見れば一目瞭然になるので、バグは減るし追加処理を入れやすい。

単一型リストにしちゃうと引数型も当然単一になるから、引数で情報を渡すのが
不可能になって、結局グローバルな領域に情報を記録することになる。そうなると
いつ誰が読み書きするかわからないので、予期しないタイミングで予期しない処理を
されて泣くわけだ。

ゲームの場合は、プログラムの基本構造が「一定時間ごとに外から関数を呼ばれる
小さなオブジェクトの塊」になる。

このオブジェクトを単一リストに入れることで型システムや変数スコープの利点を捨るか、
あるいは複数のリストに入れることで仕様変更時のソースコードの変更範囲が大きくなる
のを諦めるかというのがトレードオフなんだろうね。

なんかいきなりジョブコン叩きをはじめた奴がいるが。

ジョブコンの利点は、コルーチンが実現できることだ、ってのは把握してる？

叩いているようには見えないし
そもそもコルーチンじゃないし
信者を装うにも無理がある

>>220
仕様変更が起こってもソースの変更範囲を小さくできるなんてメリットだとは思わないな。
それができるということは仕様とソースが乖離していること、乖離していくことを示している。

>>223
確かに仕様変更の中身に強く依存することなので
一般論としてしまうには無理があるな。
設計によって対応しやすい変更としにくい変更があるだろうから
それらを具体的に考えてみるのもいい。

>>223
> 仕様変更が起こってもソースの変更範囲を小さくできるなんてメリットだとは思わないな。
> それができるということは仕様とソースが乖離していること、乖離していくことを示している。

は？
仕様変更が起きた時に、ソースの変更範囲ができる限り小さくて済むように
（1つの仕様変更で変更すべき箇所が1箇所で済むように）実装するのは、
基本中の基本だぞ？

小さな仕様変更でソースのあちこちを変更しなければならないという状態のほうが、
仕様と乖離したソースだということになるはずだが？

>>225
ごめんよ。もちろん１つの仕様変更であちこち変更するのを基準に「小さく」って話を
してるわけじゃないんだ。

ある処理が依存する情報について変更があっても、グローバル変数を使っていれば
関数の引数には変更が現れなかったりする、そういう変更の小ささがメリットだとは思わない
って話。

>>226
同意
特にグローバル変数まで使って変更を強引に縮小することにメリットは全く無い

グローバル変数を使っていれば、明示的に引数などで渡す必要がない
struct 使っていれば、わざわざ setter, getter を使う必要がない

……それが通じるのは、アドレス空間 64KB の世界までだよな。

タスクシステム
ストラテジーパターン
FSM

違いがわかりません

タスクシステムはC言語より前に生まれたのでは

>>230
キミはＣ言語の誕生をいつと思ってるのカネ？

UNIX用に作られたくらいだった気がするので３０年前くらい？

http://www.ijinden.com/_c_12/Ken_Thompson/Pears_UNIX.html
１９７３年だな。

インベーダーは７８年で、PONが７２年か。
http://loderun.blog.so-net.ne.jp/2008-04-03-1

ゲーム上でのタスクは後になるのか。タスクの元になるものが更にあるかは知らないｗ

230を好意的に解釈すると

タスクシステムは(ゲーム開発に)C言語(が採用される)より前に生まれたのでは

C言語使うようになったのなんて90年代になってからだね。

>>208
汎用。これはとても便利な言葉だ
これは何にでも使えるね、というポジティブな意味に使えるし
これは何にもできないね、というネガティブな意味にも使える
どちらに重みが置かれるかはケースバイケースだが
仮に後者の重み係数が大きくても角が立たないという魅力的な言葉だ

面接に来てくれた若者のソースコードを眺めて
「これは何にもできない処理単位だね」とぶっきらぼうに言い放つ人間もいれば
「これは汎用的なタスクだね」とやんわりと当たり障りの無い表現で煙に巻く人間もいる
前者はある意味で分かりやすい圧迫釜賭けだが、後者には注意を払う必要がある

コミュニケーション能力の一端を見るためにわざと当たり障りの無い意味不明瞭な表現を使い
その背後に隠された意図を相手がどう読み取ってくるのかをじっと観察する人間もいるからだ

いちいち駆け引きしなきゃ話もできんようなやつとは
仕事したくないなあ

90年代？自分の記憶がソースかよ

>システムはどうかしらないけど、ゲーム業界でタスクは一般的になってると思うよ。

ジョブとタスクを明確に使い分けてた職場とジョブとタスクを混同してた職場があったようだけどねー
ソースだけ（部分的に）パクれても設計のノウハウ（なぜこれはこういう設計になってるのか等）まで
パクれなかった下っ端が中堅・下請けに再就職しても断片的で不完全な情報しか伝達されない
情報は確実に劣化する

長期大規模開発用に構築されたフレームワークは巨大だからリードプログラマをつかまえてこないと
その全容を正しく理解するのは難しいね
たとえタスク制御とジョブ制御が分離されてるコードを見たとしても、それがどうして分離されてたのか
分からなかったかもしれない。だからコンテキストスイッチ不要とかという話になり、ユーザーに直接タスクを
記述させて泥沼に陥ったりする。>>2はその典型じゃね？


という談話を聞いてきたHSPerでした

>>237訂正
>ユーザーに直接タスクを記述させて

ユーザーに直接、タスク（システム内部の処理単位）として振舞うようなジョブを記述させてる、だったかな

ジョブエントリの連結リストを走査して順次処理するだけの単純な仕掛けだから
スケジューリングがなってないしデッドラインに処理が完了するようマネージメントすることもできない
全てマニュアル操作。ユーザーに責任を押し付けてる。劣化ジョブコンとも

半年程うだうだやってようやくタスクシステム卒業できた気がする俺からのヒント。
これでこのスレからも卒業だ！

1. ハードに近い下のレイヤはイベントハンドラ使うけど、
　上のレイヤではイベントハンドラは（自分からは）使わない。

　上のレイヤではvoid enter_frame(void)、void display(void)のようなタイミング通知の意味しかない関数
　（C++ならメソッド）を用意しておいて、イベントハンドラからはそれを呼ぶだけに留める。
　データの受け渡しはあくまでも上主導で。
　下主導で上へとアクションかけるのは処理実行タイミング通知（関数呼び出し）だけ。
　入力データは下のレイヤでバッファリングしておいて上のレイヤが下に参照しに行く。相互参照を避けるため。
　タイミング通知の関数のタスクシステムとの違いは、それらの関数がプログラム中にただ一つずつしか存在しないこと。
　関数呼び出しされた側では、その関数内で１フレーム分の処理を手続き型言語丸出しで書いてＯＫ。
　例えばif文、switch文も関数呼び出しも他のインスタンスのメソッド呼び出しも自由自在だし、がんがん引数渡し可能。
　ゲームオブジェクト種別ごとに別の配列用意したりとかも普通にできるようになる。
　ウィンドウプログラムに入る前のC入門書のノリで普通にプログラム書ける。
（続く）

（続き）
2.ゲームプロジェクトとは別にライブラリプロジェクト作る。Visual C++ 2008 Express Editionでもライブラリ用のプロジェクト簡単に作れる。
　１つのプロジェクトで既にきれいに分けれていると思っててもプロジェクト分けると切れてなかったことに気づく。結構重要。
　ライブラリ化はよくある普通の部品化レベルでよい。
　フレームワーク作りはまだ止めとけ。部品化だけで十分役立つ。というかタスクシステム卒業したら部品化できる範囲が急激に広がるのでそれだけで十分手一杯になれる。


ハード触る処理とゲーム処理をごちゃまぜに一つの方式で扱おうとしてるといつまでもタスクシステムから逃れられないと思う。
ハードは割り込みあるから本質的にイベント駆動だけど、
ゲーム処理までそれに合わせる必要はない。手続き型言語丸出しでバッチ処理的にべた書き（1フレーム刻みだけど）できるし、そうすべき。
楽。チョー楽。
プログラム入門したての頃の楽しい感覚が蘇ってくるよ、べた書き。すいすい進むし、出来ることの幅がすごく広がる。

#プログラム構造の文献はCで完結するような原始的な領域の本が分かりやすくていいよ。組み込みとかの。SESSAME WGのとか。

おまえらやっぱり1度Java経験しといたほうがいいと思った

>>239-240
タスクシステム大好きっ子を締め上げたりしてる俺だが流石にお前は可哀相に思う

>>2なんざポーリング処理（全オブジェクトのちゃんこ鍋連結リストを巡回してディスパッチ）
するだけのヘッポコプログラムだから。イベント駆動云々なんてVSYNCトリガーにしてる以外は
関係ないから関係ないから。お前が言ってる事は

main(){
　　//ここで準備してね
　　while(1){
　　　　enter_frame();
　　　　display();　　　　
　　　　d3ddev->Present(VSYNC待ってから処理返してね);
　　}
　　//ここで後片付けしてね
}
enter_frame(){
　　//１フレーム分の処理を手続き型言語丸出しで書いてＯＫ。
　　//例えばif文、switch文も関数呼び出しも他のインスタンスのメソッド呼び出しも自由自在だし、がんがん引数渡し可能。
　　//ゲームオブジェクト種別ごとに別の配列用意したりとかも普通にできるようになる。
　　//ウィンドウプログラムに入る前のC入門書のノリで普通にプログラム書ける。
　　//ゲーム処理までそれに合わせる必要はない。手続き型言語丸出しでバッチ処理的にべた書き（1フレーム刻みだけど）できるし、そうすべき。
　　//楽。チョー楽。
　　//プログラム入門したての頃の楽しい感覚が蘇ってくるよ、べた書き。すいすい進むし、出来ることの幅がすごく広がる。
}
display(){
　　//上に同じ
}

これこそサイコー！って言ってるだけ。>>2のmain関数だって同じように書けるし。アホかお前。氏ね
抑制したつもりだったけどやっぱり無理でした

タスクシステムって単なるオブジェクト指向プログラミングなんじゃねーの？
時代に乗り遅れた奴らが悶絶してるスレにしか見えないｗ

>>243
オブジェクト指向のキモは、クラスの洗い出しと、クラス間の関連を見極めること。
何でもかんでもグローバル変数に書いて共有するのはダメだろ。

タスクシステムとグローバル変数には何の関連性もないし
タスクシステムがオブジェクト指向であるというのもそのとおり。

たんなる技術手法の１つでこれといった決まったルールが決まってない名称であるから
揚げ足取りがしやすいだけ。

デザパタより昔からあった手法だし、C++よりは古い。

クラスもなければプロトタイプでもない、CLOS のような多態のメカニズムもない。
どこがどうオブジェクト指向なんですかね。

>>243
１口にオブジェクト指向といってもメッセージングとオブジェクト主体の動的なものと、
構造体主体の静的なものとかがある。前者はスクリプト言語とか。C/C++は主に後者。

参考： http://d.hatena.ne.jp/sumim/20040525/p1

このスレの異常に不憫な嫌タスク厨を見てて
いつも思うことがあるんだが・・・




「神は自らタスクるものをタスク」

>>242
WM_LBUTTONDOWNとかWM_MOVINGとかWM_DESTROYみたいなイベントも扱う。
それら入出力関係・アプリ生存期間の制御関係のものと、ゲーム処理をいっしょくたに
扱える標準的インタフェースなんて作るなというのが主旨。
もし作ろうとすると
　1.イベントハンドラで統一
　2.やっぱ使い勝手悪いのでゲーム処理はenter_frame(), display(), move()の３つだけに集約
　　→タスクシステムいっちょあがり
となる。

あとenterframe()とdisplay()で分けたけど、よく考えたらenterframe()１個で足りるかも。
ゲーム処理は1フレームに1回、1つの関数呼ぶだけで足りるし。
というかenter_frame()さえもいらないかも。
どこかで誰かが全入出力デバイスの面倒見る必要は結局あるもんね。
俺はなんか分けてたからああ書いたけど。その辺はごめん。

重要なのは「入出力デバイス処理とゲーム処理は別物」ということ。
そして別物なので、「ゲーム処理にまでイベントハンドラ適用しようとすんな」ということ。
タスクシステム＝イベントハンドラ崩れorイベントハンドラの俺ゲーム最適化後というイメージを持ってる。
OSも昔とか組み込み系の貧弱な環境とかではユーザランドとOSの切り分け曖昧だったりOS無しで自前管理だったりするけど、
規模大きくなるとそれじゃ成立しなくなるのに似てるかも。

メインループとかの構造はそう、大体そんな感じでＯＫじゃね？　あんまそこは興味ない。
main関数からじゃなくいきなりイベントハンドラから始まる環境とかあるし、正直動けばそれでいい。
一応俺はそのd3ddev->Present()をdevice.wait_frame()に置き換えてその中でDispatchMessage()ぐるぐる回しつつ1フレーム待ってるやり方。

>>249
それってホーミングミサイルがターゲッティングした相手とか
キャラと移動床、移動床と固定壁の相互判定の処理とかって
どこ飛んでいっちゃってんの？

なんかワンフレのオブジェクトの独立した動作しか見えてなくね？

上記のことをそのシステム使って解決しようとすると
もう関数の引数でやりとりできないからグローバル変数使って回避するしかないっしょ？

>WM_LBUTTONDOWNとかWM_MOVINGとかWM_DESTROYみたいなイベントも扱う。
>それら入出力関係・アプリ生存期間の制御関係のものと、ゲーム処理をいっしょくたに
>扱える標準的インタフェースなんて作るなというのが主旨

HSPerも基本的にそう思うよー
http://pc11.2ch.net/test/read.cgi/gamedev/1227748699/181n

でも、これって>>2>>2卒業とは関係無い話だと思うよ
GUIに特化したOSのイベントシステムというものは
OS提供のGUI関連機能を積極的に使わない限りは
「どんなアプリにとっても」どうでもいい存在なんだし

そういう場合、どんなアプリでも
最低限のイベントに対応する処理を脇のほうで適当にこなしてるだけ

>>250はレス先間違えたｗ

>タスクシステム＝イベントハンドラ崩れorイベントハンドラの俺ゲーム最適化後というイメージを持ってる。

>>2にはイベントという概念はないしイベントディスパッチャもないよ
イベント駆動システムの体を成してないよ
>>2はジョブの連結リストを走査して全ての要素（ジョブ）をディスパッチしてる
つまり単純な順次処理しかしてくれないよ
イベントがあるとすれば、それはユーザー自身がジョブの中で記述しなければならないよ
>>2は何にもしてくれないよ

イベントというかメッセージだったかな
HSPerは頭よくないから使い分けがよくわかんないの

ケータイだからID違うのはしかたないね

>>242
不憫なやつだな、お前
なんかわかった気になっちゃってんだろうけど

２１世紀の高スペックハードが前提ならModernC++Designあたりの設計の方が当然良いっつの
まーおまえは配列が最高だと思ってるかも知れないから、これも分からないかも知れないが・・・ｗ
ジョブコンはハードべったりなコーディングのための実装（設計ではない）であって、
組み込みに近いハードで便利なんだよ
これを組み上げた故・深谷正一氏はナムコで神様って呼ばれてただろ

嫌タスク厨は、世の中に唯一の正しい答えがあるわけじゃないことを学んだ方がいいよ
様々な現場があり、また過去にあったことを理解しろ
多分２０年後には、C++自体が百害あって一利なしと言われているだろうが、
その時でも俺はC++を擁護するね
仕事ではC#かECMAScriptあたりを使っていたとしてもね
だから俺は今、タスクを擁護する
かつて世界をリードした日本のゲーム最盛期の技術として、価値あるものだ

あ、でもタスクしか使えない老害はそろそろ消えてくださいｗ
もうバブルは終わったんだよ。過去にしがみつくなｗｗｗ

モナドを使ったステートレスなタスクを考えてください

CPSでおｋ

久しぶりにのぞいたら例の本でふきあがってるのな
まだ続いてる？
いわゆるタスクシステム的な抽象度の高いオブジェクトがシステム最上層で一本だけのリストに
なってる系の設計の問題だと思う点はタスクの描画順序を変えようとしてプライオリティを変えると
その抽象度の高いクラスを継承するクラス全部リコンパイルするハメになるとこ
そして最近は複数バッファを使う技術を実装する途上で描画順序を変えなくてはならなくなることが多い
同一のリソースに複数回描画を要請することもある

本当のタスクシステムはリストではなくリングバッファ
リスト使うやつはまがい物

>>255
で、なんで急に「ジョブコン」の話を始めてるのかな？
俺は>>2の話をしたがお前はそれを「ジョブコン」の話だと思ってるのかな？
もしかしてお前、>>2＝「ジョブコン」だとでもいいたいのかな？まさかね

故人の名を引っ張り出して嘘を吐くなんてバチ当たりなこと、するわけないよね？

人として

723 名前： 遠藤雅伸 ★ 投稿日： 02/01/04 11:43 ID:???
>>720-722
　>>712の言っている「タスク」というのは、80年代初頭に深谷正一
氏が完成させた、通称「ジョブコントローラー」とか「オブジェクトコン
トローラー」とか言われているものだと思います。
　CRTのブランキングに同期して行われるインタラプト処理をトリガー
にして、60分の１秒単位で順次処理をマルチに行う構造ですね。

　今では誰もが使っているというか、既に時代遅れなのですが、当
時はプログラマに読者層がある雑誌などで、プログラムを解析して
紹介したりしてました。

描画順序を内包するから問題になるのであってそれは外にだせばいいだけだな
それでも複雑・特殊化した描画のシーケンスに対する柔軟性のなさは相変わらずだけど

業務用アプリでさえタスクシステムなのにお前らいつまでこんなネタを繰り広げてるんだよ

×タスクシステム
○イベント駆動

タスクシステム　＝　リアルタイム・ゲームにおける並列動作処理の基本アイデア

基本アイデアを否定するって、初心者掲示板においてどんだけ罰あたりなんだよ。

>>265
ゲームの基本アイデアは、

1. 定期的
2. 外部から駆動される

オブジェクトの集合でシステムを構成すること、だろう。固定長ブロックをポインタで
つないだ所謂タスクシステムは、その（特殊なケースに最適化された）例の一つ。

「定期的」オブジェクト：
　フレームワーク（タスクの生成／消滅／アクティブ化／非アクティブ化）

「外部から駆動される」オブジェクト：
　上記のフレームワークに乗っかった個々のタスク

・・・ということ？

結局、>>266の実体はタスクシステムなんでは？

デザパタより昔からあった手法だし、C++よりは古い。

イベント駆動とメッセージングOOPの組合せ程度じゃ
単なるよくあるGUIプログラミングの定石じゃない

>>267
for (;;) {
　player.exec(*this);
　std::for_each(enemies.begin(), enemies.end(), boost::bind(&Enemy::exec, ::_1, boost::ref(*this)));
　WaitVSync();
}

これだって VSync ごとに 1 回ずつ、各オブジェクトを呼び出してるわけで、
別に固定長ブロックをポインタでつないだ「タスクシステム」とやらに限った
話じゃない。

ポエマーだけど、人違いされたままなのは気に入らないので横合いからちょっかい出してみるのねー

>>255
ジョブ（プログラムとデータを関連付けたもの。要するにオブジェクト）の連結リストを巡回して実行するだけで
これこそが神の技だとかソロモンの指輪（どう見てもガチャガチャで入手した飴菓子のジュエルリングだが）だとかいって
ホルホルしてるウンコカルト教の信者のつまらないプライドをベキベキにへし折るためのちょっとしたアンチテーゼとして
「STGで弾とかパーティクルを大量に出すなら>>2より配列で素直に書いたほうがちょっぱやだけど何でそうしないの？」
みたいなこと書いたことあるけど、カルト教団からの脱会を決意をした子(>>239-240,>>249)に向かって阿呆とか死ねとか
言ったりはしないよ。目出度いことなんだからお赤飯を炊いてあげたいくらいだねー

ところで>>2には深谷氏の流派に見られた特徴的な記述が微塵も感じられないけど、君はどうして混ぜこぜに語るの？
異質な点をあげればキリないけど、端的な例をあげれば>>2にはコンテキストの保存や切り替え機構がないよね。
>>2書いた人はどいつもこいつもその必要性を微塵も感じてないんじゃないかな。ゆえに深谷氏の師事を受けた
人間ではないよ。まぁ優劣の話ではないのね。明らかに異質。完全に別物ってことなのね

>>257
それ、知らない人が読んでも意味がよく分からないと思うのねー
引用先で遠藤サンがおっしゃってる「順次処理」というのは、ジョブの処理内容のことだと思うのねー
別の言い方をすればジョブの内容はシーケンス制御ですよ、というお話だと思うのねー

これをマルチで行なう、というのは順次処理を行なうジョブ（複数個）、固定時間刻みで逐次処理することだと思うのねー
この逐次処理の処理単位は世間一般にはジョブステップとかタスクとか読ばれるのかもしれないのねー
luaのコルーチンと同じようにユーザーが挟み込んだ補助情報（yield文相当）で半自動的にジョブは分割されて
実行されるのねー。アセンブラでジョブを記述するにはとても使いやすかったのねー

×師事を受けた
○教えを授かった

△ジョブ（複数個）、固定時間刻みで
○ジョブ（複数個）を固定時間刻みで

一方で、>>238とか>>253の順次処理というのは連結リストに繋がれた順番の話だと思うのねー
繋がれた順番に実行するということ。つまり順次処理。バッチ処理だね

>>2はジョブをバッチ処理する機能しか積んでないというのは本当だね。それを>>2では無理やり逐次処理に使う。
逐次処理するための足りない部分は誰が面倒みるの？ユーザーが面倒見るんだよ。全部ね

×>>257
○>>261

酔っ払ってるとダメなのねー

これで>>261の引用元の遠藤サンが何で「タスク」という組み方を聞かれて「ジョブコン」のことだと推測したのか
が見えてくると思うのねー

可能性�@　：　「タスク」という組み方が>>2程度のものだとは露ほども考えてなかった。想定外にお粗末な>>2
可能性�A　：　メインフレームの基礎知識がある人間は「タスク」と言われたら「ジョブステップ」かなと思う
　　　　　　　　　言うまでもなく深谷氏を師事するものにとってジョブステップといえばアレである

ま、いずれにせよ。あの流派の人間に「ジョブコンとは>>2」なんて言い放ったら青筋立てて苦笑いすると思うのねー

>>271
> luaのコルーチンと同じようにユーザーが挟み込んだ補助情報（yield文相当）で半自動的にジョブは分割されて
> 実行されるのねー。アセンブラでジョブを記述するにはとても使いやすかったのねー
今でもコルーチンは便利だけど、その部分は C++ で書かずにスクリプト言語＋スタックレスの VM 使うよな。
昔はスクリプト言語なんて贅沢は言ってられなかったわけだが。

スクリプトも無節操に使うとグローバル変数、関数とかわんない

タスクシステム＞働いたら負けかなと思ってる

というか、ジョブコン（コルーチン）話はこのスレのスコープに入るわけ？

>>270
それってタスクシステムのアイデアを、そのままライブラリで厚化粧しただけじゃん

> ジョブコン（コルーチン）
は？

>>277
一般的には、スクリプトは C++ の単一のインスタンスに張り付ける。

たとえば Enemy クラスのメンバ変数としてスクリプトを張り付けて、
スクリプトからは Enemy クラスのメンバ関数の一部だけ呼べるように
する。

何でもかんでもスクリプトから呼べると、そりゃ破綻するわな。

スクリプトのほうが利点があるなら最初から全部スクリプトで作ればいいじゃない？

>>283
適材適所。大半を全部スクリプトで作ったほうが良いのは、アドベンチャー
ゲームぐらいじゃないかなぁ。

>>281
ジョブコン＝コルーチンって理解じゃ違うのか？

俺は>>279じゃないが
こういう結論になりそうな資料見たことある
内部の人間じゃないから分からんが・・・
なんか謎に包まれてんなあｗ

ジョブコンってコンテキストスイッチないじゃん
ただのステートマシン

>>286
http://game.2ch.net/gamedev/kako/1006/10061/1006184421.html の 810 を
100 回読んでこい。

あった
http://jp.youtube.com/watch?v=3JWl1IikUBE&feature=related

>>287 読んだ。
>スタックにプッシュしてあるリターンアドレスも含めた
>ＣＰＵコンテクストを復帰させて 各ジョブを呼び出す。
>ただし、リターンアドレスをポップする 形で呼び出すので、
> RTS で呼び出す訳ですが。

うは、なつかしいな。確かZ80で、RTS使うかわりに戻りアドレスをスタックに積んで
pop すると RTSよりマシンサイクルが少し速い、てな話だったような。

>>275
こういうの見ると、メインフレーム屋さんではなくて制御屋さんの発想な気がするけど。
マイコンのアセンブラだと、コンテキスト、というよりCPUのレジスタを保存する
とか普通の世界だったから、それを現代風にアレンジした「タスクシステム」で
考慮してないとしても卑下する必要はないと思うんだけどなあ。

かじっただけの俺がいうのもなんだが、あちこちのサイトで紹介されているタスク
システムの問題点は中途半端に汎用的で抽象化されているところじゃないかな。
ひとつのシステムで多用途に適用できるというのはPGの夢かもしれないけど、
ルーティンを嫌うアミューズメント用途にはちょっと無理があるような気がする。

やね本でこの手の技法を知った。
2年程実際に使ってて、今のところ大きな問題が出てないからまだ使ってる。
とはいえいろいろ小さな問題点や、
ハードのスペック故に浮き上がってきた問題も出てきた。
ただ、今は新しいやり方を覚えてソースを書き換える暇がないので、
じわじわと学びながら弄りながら変えていってるのが現状。
まあ不毛な喧嘩はともかく、
タスクシステムの問題点についてビシバシ突っ込んでくれるのは非常にありがたいので、
これからも話がズレない程度に熱く語ってくれ。

貴様に命令されるいわれはない

>>289
ありゃ、間違ってるな。てか、興味ない人はスルー願います。
>ただし、リターンアドレスをポップする
>形で呼び出すので、 RTS で呼び出す訳ですが。

z80でサブルーチンを CALL nn すると、現在の pc の次のアドレスを
スタックにプッシュして nn に飛ぶ。その先で rts すると、スタック
からアドレスを pc に読み込んで呼び出し元のアドレスの次の命令から
続くのが通常。上のはサブルーチン（タスク）を呼び出すのにその
逆をやってる。なんかの雑誌でみたことがあるな。
　メリットは覚えてないやw
　push でレジスタを退避させるのと一緒に使えて、速くて短い、とかかな。

>>292 は>>287を読んだだけで内容を理解できてないと思うから
ぐだぐだ書く前にちゃんと理解する努力をしろ。

>>293
まあ、そう突っかかんなよw
ではよく理解している293に教えて欲しいんだけど、

(1)「タスクシステム」いうだけで、なぜ271は
>ウンコカルト教の信者のつまらないプライドをベキベキにへし折るための
>ちょっとしたアンチテーゼ
みたいに口汚く否定しなければならないのか？

(2)「タスクシステム」がだめならジョブコンでどうかというと
>あの流派の人間に「ジョブコンとは>>2」なんて言い放ったら青筋立てて苦笑いする
みたいに必死に否定するのはなぜか？

(3) 青筋を立てているのは271ではないのか？

以上3点、ご教授いただければ幸いですw

なんつか、271はそれなりに知見のある人間にも見えるんだけどなぜ？って感じ。

定義ごっこウゼーからヤメロよ
名前なんて関係ねーよ

ポインタ保持
グローバル変数関数使いまくり

のソースは問答無用で糞コードなんだよ

>>290にはたぶん向いているんだろう。俺にはちょっと使いづらいかなと思った。
あんまり頭よくないんで、全体を把握しにくいコードでポインタを使いまわす
のはおっかないと思ったよ。

いずれにせよ、コストと手間を考えて手段を選ぶだけなんだから、手法のメリット
デメリットを論じるならともかく、使うだけで罵ったり赤飯炊いたりしてくれるのは
まあ、本筋と違うと思うんだけどなあ。

>>295
new 厳禁, malloc問題外かあ、そりゃ難儀だな。
295 はよほどでかいスタック使ってるんだろうなあ。すばらしい。

>>297
ああ、やっぱり馬鹿なんだｗ
馬鹿だから横文字連発して誰でもできる名称の定義にこだわってんのバレバレ
あー恥ずかしいｗ

>>294
>>271 は撲殺天使気取りのカルシウム足りてない人だから。以上

というかタスクシステムってちゃんと使えばTCBにキャラクタ固有のデータを
おくはずで、グローバル変数は回避するのが正しい使い方だと思うのだけどな。

ID:oW76AwO4
ID:9M4acoh9
ID:1VWYpijd
＞みたいに口汚く否定しなければならないのか？

↑（ﾟ∀｡）↓

＞>>271 は撲殺天使気取りのカルシウム足りてない人だから




ルサンチマン号…

>>299
自キャラクタのデータを TCB に置くのは当然として、タスク間の相互作用を
どう記述するかが問題。ヒット判定とかホーミング弾とか。

ここで、他タスクのポインタを持つと寿命管理でミスして dangling pointer 問題が
発生しがちだし、マネージャクラスみたいなものを作ろうとすると、グローバル変数
多用することになる気がするんだが、どう解決してるんだろ？

>>294
俺は271じゃないから271の考えてることはわからんよ。

でも>>2は、
・>>287のリンク先のジョブコンでの重要な要素（PCとSPが保存される）が消えてる
・CodeZineの記事はメモリ管理がキモすぎる
・TCBとスタックポインタというRTOSで使われる用語を全く別の一般的じゃない意味で使ってる
ので、ああいうのが代表的な解説になってるんじゃヤバいと思うよ。

俺はゲーム自体の出来がよければシステムなんてなんでもいいんだけどさ。

>>289
やぁどうも

>マイコンのアセンブラだと、コンテキスト、というよりCPUのレジスタを保存する
>とか普通の世界だったから

マイコンでcontinuationすることが普通だったのか
80年代初頭においてそうした普通があったというのは寡聞にして知らんので
是非ともご教示いただきたいです。よろしくです

>それを現代風にアレンジした「タスクシステム」で考慮してないとしても

「アレ」を現代風にアレンジすると>>2になるのか。見聞の狭い俺にとっては初耳だ。
現代風にアレンジするとcontinuationは必要なくなるという話も新鮮な響きだ。
「アレ」に必要な処理量と得られる利得（ユーザビリティ、etc）を鑑みたうえで
continuationを積極的に「省く」メリットを探してみたのだが不肖の俺には
荷が勝ちすぎるようだ。この辺りについても是非ご教示いただきたい
重ね重ねよろしく頼むよ

えーと。

確かに継続で間違いないんだが、マルチタスクなOSの（リアルタイム、
非リアルタイムを問わず）コンテキストの保存と復帰、まとめてディスパッチと
いう概念は、計算機の歴史としては割込みと同じくらい古い。確か
マルチプログラミングと呼んでいてOSより古いはず。
（というか、割込みの前と後で戻る所を次々すげ替えていけば、マルチタスクに
なる、よね）
現代的には、OSのスレッドサポートと、言語側の継続とかコルーチンとか、
という風に分かれちゃってるけど、マイコン時代にはアプリからモニタまで
全部ユーザが面倒を見るのが当然だったから、ジョブコンも別に大げさな
仕掛けにはならなかった、のだと思うわけだな。

> continuationを積極的に「省く」メリットを探してみたのだが不肖の俺には
> 荷が勝ちすぎるようだ。

確かにこっちは無理だw

文章長すぎる奴自重しろ
中身もねぇのにだらだら無駄に長い
ホントにプログラマーか？お前

>>302
> ・TCBとスタックポインタというRTOSで使われる用語を全く別の一般的じゃない意味で使ってる
> ので、ああいうのが代表的な解説になってるんじゃヤバいと思うよ。

TCBは痛いが、スタックポインタについては、メモリブロックのLIFOな管理技法に
使う用語として一般的なものだと思うが？
むしろアーキテクチャ用語のスタックしか思い浮かばないほうが視野が狭い。

>>305
継続を一言で説明できるのかお前は？

KEIZOKU？

継続 = continuation

>>304
やぁありがとう。非同期的に呼び出される割り込みハンドラはコンテキストの保存と復帰をするよね。すまん。
ところで割込みの起源の話があったので、Donald.E.KnuthのThe Art of Computer Programmingを
めくってみたところDYSEACというコンピュータが最初だそうだ。ぐぐってみたところ面白いページ発見

History and Overview of Interrupts and Interrupt Systems -- Mark Smotherman
http://www.cs.clemson.edu/~mark/interrupts.html

によると割り込みの始祖はUNIVAC1まで遡る。算術オーバーフローの例外処理。ソフトウェア割込み。
割り込みの一番おいしいところである外部割込み（ハードウェア割込み）はKnuthの言っていたDYSEACで
これは米商務省標準局データ処理システム部門電子計算機研究所が開発したもので、米陸軍の
移動式通信システム用として1954年から運用が始まったそうだ

米陸軍弾道研究所　報告書No.1115　国産電子計算機についての調査(第三回目)
http://ed-thelen.org/comp-hist/BRL61-d.html#DYSEAC
>(3) an interruption property which enables the machine to handle unscheduled ,job assignments
> which originate externally without advance notice and must be executed as soon as possible

DYSEACはマルチプログラミング（例えばI/O処理に計算機を独占させない）を実現していたと思われる。
Mark SmothermanによるとDMAもこいつが最初かもだそうだ。おもしろいね

ふむ。撲殺天使の人か別の人かわからんが、興味深い情報をありがたう。
mobile computer と書いてあるからびっくりしたが (carried in two tractor
trailers at 12 and 8 tons, respectively!) とすぐあとに書いてあった。
TRONチップとか、命令の実行に伴って起きる「例外・Exception」、外部入力
で起こされる「割込み・Interrupt」、OSの呼び出し等に使う「トラップ・Trap」と
使い分けてたりするね。
さて、いいかげんで昔のPC板行けと言われそうなので手短にポインタだけ
示すが、岩波講座情報科学1『情報科学の歩み』（高橋秀俊、1983）のp.48
によれば1959年にパラメトロンコンピュータPC-1に筆者らは割込み機能を
付けているが、「割込みという日本語も，英語の interrupt の訳ではなく，
われわれのグループで使いはじめたことばである．」だそうだ。
『コンピュータへの道』（高橋秀俊、1979）のpp.148〜151にも割込みの話が
出ている。

まだなげぇ、すげーなげぇ
少しは相手の反応をみるとか
ちょっとした気遣いは全くないのか？

誰も聞いてないことをベラベラベラベラよくしゃべるなぁ

スレチだが。面白かったよ俺には。
長いとか、よくしゃべるとか、批判の対象が違うだろ。
自分の興味のないこと＝誰も聞いてない としか受け取れないのか？
ただスレ違いなだけ

>>313
おお、じゃあ、適当なレス返してやれよｗ

>>289
悪い、出張してた。
うーん、おれが本来のジョブコンを理解できてないから変なこといってるのかもしれないけど、、
z80にしても6809にしても当時のマイコンのアセンブラ本とかみて、
マイコンでマルチタスクを実装する方法とかざらに載ってたと思うんだけど。
continuationという用語で説明されたかは覚えてない。
比較的あたらしいのはこんなのか？
http://www.ertl.jp/ITRON/Newsletter-J/itronnews19.html
これが雑誌に載ってたのを見た記憶がある。中身がぜんぜん違うならごめん。

で、俺が見たのはz80のアセンブラ本で、マルチタスクを実装するのに
win3.1みたいに自分でジョブを明け渡す方法と、割り込みを利用して
スイッチする方法がのってた。どっちにしてもなんらかの形で
レジスタの保存と復帰はあたりまえだよね？
んー、多分おれが的外れなことを言ってるんだろう。もう黙るわ。

黙るといっておきながらあれだが、
>>315は1992ってなってるな。80年初頭とは違いすぎるね。
だけど、マイコンでみんなやったことってメインフレームの真似事だったんだけどなあ。遠藤さんのスレの例の肝は、リロケータブルなプログラムの組みにくいz80で、RTSを
利用して実現したことだと感心したんだがな。まあいいや。

continuation(継続)とは、要するにコンテキストのようなものだが、
かなり抽象的な概念で、コンテキストとはプログラムの実行中の
一瞬の状態のことだが、継続とはその先にある計算全部を
ひっくるんだもの。ある種の高水準言語（特にScheme）では
一般概念。OSや機械語のレベルで直接扱うことはまずない
（というか高水準の概念）。
Googleで「継続」を検索すると上位10ページの半分弱は
これの説明なのでざっと見てみるといいかも。

「マイコン マルチタスク」で検索するとインタフェースのバックナンバー
目次がひっかかった。1984年9月号の特集が「Cとマルチタスク・モニタ」
なので、そういう記事だろう。多分。
ttp://www.cqpub.co.jp/interface/contents/198xindex.html

また、長文垂れ流しか
ホント無駄な奴等だな

>>318 おお、ありがと。1980年の
>12月号 特集◆リアルタイム制御用マルチ・タスク・モニタの研究

なんかもまんまだな。「非同期〜割り込みハンドラは」とか留保つけてるくらいだから
認めてもらえそうにもないが。いつのまにか
>continuationを積極的に「省く」
ことにされてるし。
このスレで continuation といえばマイクロスレッドとかファイバとかの話になるよね。
で、このスレでもおなじみのやねうらお氏がこんなのも用意してたりするわけだよ。
ttp://ml.tietew.jp/cppll/cppll/article/6196

でもさ、コンテキストスイッチングとかマイクロスレッドってc/c++標準の機能でもないし、実装にはそれなりに手間もかかるし、無いとまったくプログラムできないわけでもない。
そういうものをタスクシステムを紹介している>>2に包含してないからって駄目呼ばわりするのはどうなのよ。

黙るとかいいながらまた長文たれながしてるな。すまんね。>>319

おっとあぶない。コンテキストスイッチを setjump()/longjumpで実装することも
できるみたいだし、GNU pthを使ったコルーチンの例もあるから、c標準
で実現できないと書くとまた突っ込まれるな。もうぐだぐだだ。

馬鹿だろ
普通初見でプログラムみたらそういう状態が認識できるならそういう変数探すだろ
探してあればそれは読みやすいプログラム
ところがそれを無くそうとするとかいかにやねうらおの程度が低いかわかるな
あるべきところにあるソースのほうが俺はいいソースだと思うぜ

やねうらおまわりってさ
こういう普通の常識もわからない馬鹿ばっかりだから嫌いなんだよね
俺、俺が初心者のときから嫌な匂いしたわこいつら
俺ももう経験１０年だけど
こいつらってズレてんだよね
力入れる部分がさ

>>320
> そういうものをタスクシステムを紹介している>>2に包含してないからって駄目呼ばわりするのはどうなのよ。
じゃ、使うメリットが何もないじゃん。

>>322
このスレの流れと逆のこと言ってないか？

このスレの流れ的には、
ジョブコンにはコンテキストスイッチがあったのに、それの発展形を
事象するタスクシステムはそれを取っ払ってる。その結果、グローバル変数で
状態を持ってやったりしなきゃならない、バカじゃね？
ということになってるのに、なんで突然そのグローバル変数を賞賛するかね？

やねがズレてるのは俺も感じてるが、お前はもっとズレてる。

>>324
は？
グローバル変数を賞賛？
どこにそんなこと書いてあるの？
やねうらおまわりはあいかわらず馬鹿だな

> そういう状態が認識できるならそういう変数

って普通グローバル変数だろ。
グローバルじゃないにしてもstatic変数。実行させてみないと挙動が把握できない。

そういう変数じゃなくて、ブツ切りの挙動を上から下に並べて書けるのが、
継続とかコルーチンとかマイクロスレッドとかファイバを利用したテクニック。
それを頭からバカにしてるのがお前。

よくわからんが、FSMの状態変数のことを言っているんなら
クラスのメンバあたりが妥当で、別にグローバルやstaticである
必要は無いんじゃないの

>>326
はぁ？
思い込み激しすぎ
どこにそんなこと書いてあるの？

ポエマーはクリスマスの家族サービスも終わって一休み、一休み
あとは印刷屋に注文したブツが配送事故なく無事に現地に到着することを祈るだけだよ

∩∩
(・x・) 　 「パパは誰と戦ってるの？」

（@∀@）「パパはね、今フェードアウト2Dゾンビという怪人と戦ってるんだよ。
　　　　　この世に未練タラタラの8bit悪霊に取り憑かれた若者達を正気に戻すために
　　　　　作文を書いてるんだ。おやすみ」
∩∩
(・x・) 　 「ふーん、まぁがんばってね」


娘に絵本を読んで寝付かせた後にネットブックでちょっかい出しに来たのね。勤労家だね

>>289
>こういうの見ると、メインフレーム屋さんではなくて制御屋さんの発想な気がするけど

私がまだ下っ端だったころ、電機メーカーでプラントのプロセス制御用のシステム開発に
携わってた人とか、光学機器メーカーで組み込みシステムに携わってた人がいたのね
彼らは今で言うところのリードプログラマに相当する存在だった。俺を含む当時の若手は
彼らから色々教わったのねー

メインフレーム屋（？）とか制御屋（？）とか、そういう分類はよく知らないけど
（基幹業務システムの人とか組み込みシステムの人とかそういう分類で言ってるんだとは思うが）
そういうのに関係なく、当時コンピュータに携わってた人間は多かれ少なかれリタラシーとして
メインフレームのことは知ってたのね。学生時代、お手本となる本格的なコンピュータシステムといえば
その代表格はメインフレームとその弟分たち（オフコン、ミニコンとか）だったのね。教科書には
当たり前のように登場したし、卒研のためにメインフレームを使わせてもらえる贅沢環境を体験した奴も
いたのね。研究室単位ではミニコンのほうが多かったけど、それらのモニタやOSもメインフレームなどの
大型コンピュータのそれを踏襲してたのね

【メインフレームの基礎知識】って言ったのはそういうことなのね。教科書レベルの知識のお話

>>294
>(1)
別にぽまえさんがクリティカルヒットしたわけじゃないでしょ？
他人事ならニヤニヤしてればいいと思うのよねー

まぁ何度も言ってることだが、当時の実装対象の特性なんてこれっぽっちも知らない人間が
64bitマルチコアCPU＆9600GTクラスのビデオカード(DSPカード)搭載のモンスターPCを持ってたりする人間が
IDE付きの静的型付言語の開発環境（VS2008EEなど）+DirectXなどを使ってる人間が
ちゃんこ鍋循環リストにすべてを放り込んでバッチ処理するだけの（今となっては何とも珍妙でお粗末な）
仕掛け（>>2）をどうして神格化するのかおじさんは不思議で不思議で仕方が無いのよねー
「タスクシステム…いとしいしと…」と地底奥深くでひっそりと一人で、職場の中で囁くだけなら別にどうでもいいが
公衆の前で「>>2素晴らしい！神の業！すげーすげー！超参考になる！真似しないと！」と絶叫する奴は
相応の陵辱を受ける覚悟をしてもいいと思うのよねー

>>331
お前、なかなかわかってるなｗ

まぁこのスレを、公衆の前と思うかチラシの裏と思うかは人それぞれという気もする。

>>331
ハァ？、て感じだな。

一体、何を問題にして、何を前提にしているんだ？
一体、何を問題にして、何を前提にしているんだ？
一体、何を問題にして、何を前提にしているんだ？
一体、何を問題にして、何を前提にしているんだ？
一体、何を問題にして、何を前提にしているんだ？
一体、何を問題にして、何を前提にしているんだ？
一体、何を問題にして、何を前提にしているんだ？
一体、何を問題にして、何を前提にしているんだ？
一体、何を問題にして、何を前提にしているんだ？
一体、何を問題にして、何を前提にしているんだ？

私は、何かの縁で最近就職希望の学生さんの就職説明会（なのかしら）に立ち会う機会があった。
どこもかしこもみんな多忙で、こんなオサンが出張ることになった。フェードアウト窓際のふりをして
タラタラと講話をしていた。眠い話が終わると、ご質問ごじゃいますかーと進行のお兄さん（イケメン）が言う

想定どおり、痛くもかわいい質問が多くてにんまりうんじゃりしていたが、特にやべぇと思ったのが
タスクシステムがどうのとかいうゲー専の子だった。本物のフェードアウト2Dオヤジの講師にナニを
吹き込まれたのか知らないが私はゲー専に行く子はちょっと可哀想だなとそのとき思った。
彼には直接個人指導してやりたかったがそういうお時間はいただけなかった。まぁどうでもいいや

×フェードアウト窓際のふりをして
○フェードアウト窓際としては久しぶりの仕事なので

>>334 主要部だけ抜き出すとここだな。

オブジェクト指向の恩恵をふんだんに受けられる環境で開発してながら、
ちゃんこ鍋循環リストにすべてを放り込んでバッチ処理するだけの
（今となっては何とも珍妙でお粗末な）仕掛けをどうして神格化するのか？

>>335
やべｗ
ファンになりそうｗ

>>337
悪いが俺には、
「オブジェクト指向の恩恵をふんだんに受けられる環境」で
タスクシステム指向を否定する理屈が理解できない。

＞一体、何を問題にして、何を前提にしているんだ？

> ちゃんこ鍋循環リストにすべてを放り込んでバッチ処理するだけの
> （今となっては何とも珍妙でお粗末な）仕掛け

という評価を否定してみせろ＞ID:mDOQ1BG2

>>339
>タスクシステム指向を否定する理屈が理解できない
頭おかしいんだｗ

Lisp？＞ちゃんこ鍋循環リスト

Lispは何でもリストで、データとプログラムが同等で、
プログラムを生成するプログラムは常套手段ですが、
今や再評価される一方のモテ言語でつよｗ

Lispのリストは単方向リストで、普通は関数的に使うもの。
（まぁ副作用バリバリで使うこともあるけどな）

「タスクシステム」のリストは、双方向リストで、デク（Double Ended Queue）
と呼ばれるデータ構造。副作用バリバリで使うのが基本。

もうちょっと中身がわかるまで勉強してから出直してね。

あ、つまり、同じ「リスト」でもはっきり言って別物だよ、ってことね。

>>343
その説明だけだと、Lispがなぜ良いものでタスクシステムがなぜ
唾棄すきものかがさっぱり分からないのですが。

Lispと同一視して再評価すべきだ、みたいな話を持ち出したのはそっち。
俺はそれを否定しただけ。

静的型安全性が無い、コードがデータと同じで自己書き換えを行えてしまう、
といった動的性はLispにも当てはまることです。
Lispはconsセルをもとに、データ構造をどうとでも作れます。

>>346
タスクシステムを再評価すべきだとは「一言も」言っていませんよ。
そもそも>>342は半分以上ネタです。

が、「ちゃんこ鍋循環リスト」は、それで何かを貶したつもりになっているのなら
少々不適切なのでは？と愚考する次第です。

>>345
馬鹿じゃねぇの
話そらしてんじゃねぇよ

>>349
は？何から？

やねうらおの近くにいるとくだらない話術ばっかり達者になってくカスに成り下がるな
奴は所詮３Ｄも理解できないクズ
大きく複雑な仕組みを小さく単純な形に噛み砕くことはできない

本人すげー頑固で視野狭いしね
止まっちまう理由もわかる

確かに、一度は奴に傾倒しても、適度に距離を置いた奴は大成してるね。

>>349
プログラム全体を関数型で設計するなら、Lisp のリスト構造が適している。
ただゲームを組むのに関数型言語が合ってるとは思えんが。

>>352
そうだね
奴もすべてが駄目ってわけじゃないんだよね
でも結局、３Ｄができねぇってのは大きく複雑なものを小さく単純な形にできないってこと
これはプログラムの能力に直結する

小さいプログラムをこね回してる分にはどんな方法で何やったってなんでもできるんだよ
でも本当に複雑なものを管理するにはそれなりの力がいる

ごちゃごちゃいう前に３Ｄやってみろボケ
ってことだよね
まあ、ヤツにいえることはこういうことだよね

>>354
すげぇ理屈

もしかして昔奴の「クォータニオンどうこう」に騙されてたとかそんな理由？

>>355
いや、そんなの知らんけどｗ

>>340
タスクシステムにケチ付けてるとも読み取れる中途半端な書き込みしやがって。
ヘタレっぽい書き込みだから無視してもかまわないんだが、
看過するのはやや気が咎める。
相手してやってんだから、もっと具体的な話してみろや。
ほれ、どうしたんだ。

＞一体、何を問題にして、何を前提にしているんだ？
＞一体、何を問題にして、何を前提にしているんだ？
＞一体、何を問題にして、何を前提にしているんだ？
＞一体、何を問題にして、何を前提にしているんだ？
＞一体、何を問題にして、何を前提にしているんだ？
＞一体、何を問題にして、何を前提にしているんだ？
＞一体、何を問題にして、何を前提にしているんだ？
＞一体、何を問題にして、何を前提にしているんだ？
＞一体、何を問題にして、何を前提にしているんだ？
＞一体、何を問題にして、何を前提にしているんだ？

ねーねー聞いていい？
この人がケチ付けられたと火病ってる「タスクシステム」ってナニ？
え、>>2なの？マジで>>2なの？すごくね？まじシステムって感じ

ひらしょーさんに「タスクシステム？なにそれ？」って言われた時点で
こいつらはもう死んでる
この単語がだれにも通用しないってことがわかっただけでもいいだろもうｗ

違うな

ぼくのかんがえたぼくのたすくしすてむをばかにするやつはゆるさない
ぼくのたすくしすてむはぼくがぼくであることのあかし、ぼくのあいでんててーそのもの
ぼくのたすくしすてむにけちつけるやつはぼくをひていしようとするやつだ

　　　　　　だ　か　ら　っ　ぜ　っ　た　い　っ　ゆ　　る　　さ　　な　　い　　っ　っ　

ということだと思うぞ
タスクシステムという単語を使って突っ突くとどっかの誰かが癇癪を起こすのだ
わくわくするだろ

おまえら横入りでレスすんな。>>360は>>358あてなんだからね
ひらしょーはしごとしろ

ID:mDOQ1BG2だけど、
「嫌タスク厨」って気色の悪い連中が多いな。

>>362
なんで泣いてんだよｗ

「嫌タスク厨」の書き込みを見てて思うんだが、

＞一体、何を問題にして、何を前提にしているんだ？

これにつきるな。

恥ずかしい連中だな。
プ！！
ワリィ、失笑しちまったぜ。

ポエマーは3D酔いの話をしたら眠くなりました

また、やねうらおに騙されたかわいそうな初心者が発狂したか

>>365
つーかあんたなんで初心者スレでは優しい人に変身してんだよ
キャラ変えすぎだろ女子高生的に考えて…

6年も前のMLのログを引っ張り出して何やってんだか

正直俺も嫌タスク厨はどうかと思う。

あれ、ID変わったかな？

＞やねうらお

＞一体、何を問題にして、何を前提にしているんだ？

>>370
日本語としては「じっぽん」が正しいが、レッドブックの「とおほん」（×とうほん）も間違いではない
ただ朝鮮人や一部の関西人が良く使う「じゅっぽん」は明らかに間違い
これを使っていると日本人である事を疑われるので気を付けるように

10円20銭

「嫌タスク厨」はロクに質問にも答えられないキチガイばっかだな。
常人の感性からすると気色悪くて目障りだからオンするなよ、なあ？

親切心から言ってやるが、
本人気利かせているつもりのチンケで鬱気味の幼稚表現も痛々しいぞ、自覚してるか？
まあ、それがお前らの正気状態か。
せいぜい頑張れや。
プ！！

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

【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

>>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シリーズで作られた

（終わり。寝る）

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

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

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

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

（ д ）ﾟ　ﾟ　ｽﾎﾟｰﾝ

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

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

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

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

・MITやばい

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

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

スレ違いじゃないの？

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

関係無いよね
スレと

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

まさにリアルDEFCONだな

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

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

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

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

スレ違いやめろ

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

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

>>396→>>396-397

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

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

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

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

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

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

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

大馬鹿はお前ら二人。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

アホか

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

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

Taskをモナドにしよう

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

×HSYNC毎に
○ライン毎に

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

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

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

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

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

あっそう。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

結論：

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

うおおおおお！

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

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

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

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

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

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

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

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

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

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

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

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

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

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

これだけ？

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

開発遅延中の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（・・・）

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

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

た

す

け

な

ん！？

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

>>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;

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

つまりタスクシステムは

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

×>>493
○>>494

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

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

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

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

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



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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

>>534
何が言いたいのか分からない。
管理クラスはupdate関数を呼ぶだけだし、呼ばれたほうは自分自身が何者かを知ってる。

何もないわけないだろう。ないならこんなに大騒ぎするはずないじゃん

かつての制限ありまくりのハードではっての前提ならなんかいいことあるんじゃないの？

>>534
は？
ごった煮リストから判別して特有の処理を呼び出す話をしてるんだよ
なんで共通のupdateの話をするの？

>>537ｰ538
あると思うならそれをいうべきだろ
ただ、あるんじゃないの？って認識の人が書き込む場面ではないだろ

>>539
必要な分はリストに入れる前にあらかじめメンバ変数として持っておくんだよ。
わざわざリストから取り出す必要はないし、型を改めて判別する必要もない。
リストから取り出すならdynamic_castだとも書いてある。
同じこと書かせないでくれ。分からない部分があるならそこをピンポイントで聞いてくれよ。

>>540
いやおれは>>497と同意見なだけだが

何をするためのものか整理してから話したら？ってこと

>>530
タスク厨を定義するにはタスクシステムを定義しなければならないのだが
>2にしても書籍にしてもゆらぎが大きく、絶対的な権威も不在、
且つ個々の理解もばらばらでコンセンサスがとれないのが現状。
>520は松浦大先生を権威として祭上げたいみたいだけど
その話題に触れているのは今のところ>521だけ。

>>530
いるいる。たーくさんいる。ここ5〜6年内はゲー専新卒の子だけじゃなくて
四大工学系新卒の子が説明会や集団面接で>>2を熱く語ったりする。臆面もなく。
他の子が目を白黒させてる。

沢山　：　oO（え、ナニそれ？何？それ知ってないとヤヴァイ？あとでググろっと）
少数　：　oO（プギャー）

など、様々な表情が観察できて面白い

まぁ最終段階で残る子はこんなもんこれっぽっちも知らなかったりするし
知ってても「だからナニ？」みたいな子ばっかだから
新人研修の段階で更生させる手間はゼロだしどうでもいいんだけどね

>>543
松浦御大の功績は認めるべきだよ。Cマガにおける特集記事とその後の連載記事
そして禿パブから出版された数々の書籍、これらによってタスクシステムという
呼称をその実装と共に伝道し、素人プログラマの間で爆発的に普及させた

それ以前にタスクシステムなんて単語を駆使する学生や子供は稀有だった。
X68界隈の草の根BBSみたいな閉じた狭いコミュニティでヲタ同士でコソコソ
やってただけ

松浦御大の教えに染まった子が増えたことで2DSTGを作る子も増えた。まぁ全てが悪いわけじゃない

>>544の前半
ニュースの映像でさえ本物かどうか疑わないといけない時代に
唐突にそんな逸話だけ出されてもねえ。
前にオカルトとかエセ科学とか言ってる人がいたからじゃないけど
検証可能性を担保できる話をしようよ。

>>541
わかんねぇ奴だな
たとえばクラスＡとＢがあったときクラスＢだけがもつmoveBメソッドを呼びたかったと
したらまずごった煮リストの取り出した要素がクラスＡかＢか判断する必要があんだろが
じゃねーとＢにしかないメソッドなんだから呼べないだろ

>>546
dynamic_cast の意味しらべるのオススメ

まあ、ゲーム開発だと RTTI はたいてい切ってるんだけどね

ちょっと訂正。

ゲーム開発 → コンソールでのゲーム開発

360, PS3 世代ならもういいかも。

タスクシステムなコードを昔見たとき

char data[256];

DataA *p = (Data A *)data;

こんな感じで領域確保してキャストして利用してたのは
C++から入った自分としてはへーと思ったな

頭悪い子のほうの撲殺天使の人暇だったんだな

>>539
＞ごった煮リストから判別して特有の処理を呼び出す話をしてるんだよ
＞なんで共通のupdateの話をするの？

>>546
＞したらまずごった煮リストの取り出した要素がクラスＡかＢか
＞判断する必要があんだろが
＞じゃねーとＢにしかないメソッドなんだから呼べないだろ

リストの個々のオブジェクトはupdateメソッドを保有している
で、そのupdateメソッドは自分が何者か知っているわけで
わざわざ型の判別をする必要はないだろ

オブジェクト間の相互作用の話をしているんだと思うよ

相手が自明ならキャストは普通は要らない
敵の中で〜なもの、といった風に条件付でスキャンしたいのなら
型の判別とキャストがいるだろう

代数データ型が使える言語ならもっと型安全にヴァリアントな型を
扱えるが、C++なら結局はキャストするしかない

で、「ごった煮リスト」とは言うが、実際には例えばTaskだのGameObjectだの
というインタフェースを継承したクラス群になるわけだろうから
型を判別する方法なんぞいくらでもある

言語組み込み機能なら、何度も言われているようにdynamic_cast
そうでなければ、例えば自分が誰かを示すメソッド等を、統一したインタフェース
として持たせればいいだけだ
なんも難しい話じゃないはずだが

>>546
こっちの話はすぐわかるからいける。多分>>551はリストのノード自体が多態性してる。
ゲームオブジェクトをupdateのみを持つ別のクラスで包むか、
ゲームオブジェクト自体がupdateをもち、オーバーライドしてupdate内で自分のメンバを呼んでいるんだろう。

ところで、タスクですべきことがゲームオブジェクトのupdate、positionの取得、など個々の場合
>>491みたいなEventTaskでやるべきことを判別する必要がある・・・で合ってる?

オブジェクトのグループ／階層がはっきりしているのなら
少なくともリストよりはツリーがいいように思う

全体も走査できるし
特定のグループに限定したいのなら、サブツリーを走査すればいい
フラットなリストでmap/filterを毎度やるよりは効率的だろう

多態とダウンキャストは、C++でOOやるなら宿命みたいなもんだから、
そこを突っ込んでみても仕方がない

型の判別が必要ってのはいいかい？
全く同じメソッドもってたって型を判別する必要あるな
自機、敵、自弾、敵弾の内、敵と敵弾だけに絞りたい場合なんかも型を判別する必要あるよな
こんときやらなきゃいけないのは一斉検索だろ？
んで処理をするもんとしないもんといちいち判別しながら処理しないといけないわけよ
何が言いたいかってーと
ごった煮である利点は少ないよねってことよ

ツリーも惜しいけどそれでもやはり意味がない

続く

>>555
「どうやって型を判別するんだよ」とか言ってるから
型なんか簡単に判別できるだろ、とだけ言っただけで
別にタスクシステムとやらを褒め称えてるわけじゃないんだけどね

ツリーも、少なくともフラットなリストよりはマシだろうってだけね

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

なんとなくすれちがいポイントがみえてきた

・入り口のメソッドだけあわせておけばあとはオブジェクトが自発的に処理すりゃいいだろ派

・オブジェクトの相互作用はまとめてかいたほうがいいだろJK。
　そうすると個別のオブジェクトの区別が必要だから1つに束ねると効率悪いだろ。

こんなかんじ？
まあ、両者ごもっとも。

俺なら今ならふつうに富豪的アプローチだな。
一連の処理を行う構造と、検索・相互作用用の構造は別の形でもったほうがいい。

・大枠は前者的思想でつくってメインループを回す。
　イベント処理＞状態変更＞画面更新
　とかそういう単位

・親に、自分以外のオブジェクトの検索をしやすいような辞書的構造を
　別途整備する。オブジェクトはこれを参照して自分の動作を決める

・複雑な処理は親の専用のロジックで辞書を直接総なめするような操作を
　作って、これ自体を処理オブジェクトとして一連の処理に投入するようにする

こんなかんじ？

>>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関数を作るか……）は好きにしてくれ。

以降のレスは呼んでる暇がないので、既にフォローされてたらごめん。

>>559
型判定の方法は論点じゃないから dynamic_cast の話は放置しておk

まともな人がいて助かる
型の判別方法は問題じゃ無い

続き

結局、型は判別しなきゃいけないんだよ
だったら別にまとめることなくね？
まとめた処理がしたかったらそんときだけ必要なもんだけ入れたポインタリストでも作ればいいんじゃないの？
わざわざごった煮にする意味がわかんないね
次の行動にターゲットが必要になった時点で共通仕様の縛りのせいでかなり悩まなきゃいけないじゃん
グローバル変数使ったり、生きてるか死んでるか不明のポインタをゲームオブジェクトが保持るとかいう
かなりアフォな構造になるじゃん

もうさ、タスクシステム勉強会を開いてそこで議論したほうがよくね？

ごった煮にしなければいけないなんて決まりはない。
リスト、ツリーに色々種類があるのと同じ。
使いやすいように各自工夫すればいい。

>>563
結局、タスクシステムって何？　どこまで「工夫」したら、タスクシステムじゃなくなるの？

単なる名称だからタスクシステムでもなんでもいいんだよね。
最近はフレームワークとか言ってる。

引数なくしてグローバル変数やシングルトンでやり取りされるのが一番困る
バグったら最後
誰もバグとれないくせに使い続けるんだもんなぁ・・・

上位階層の改修を前提にするのは賛成しかねる

判別方法は関係ない？
>>525,534,539,546
俺には、一貫して型の判別方法を聞かれているようにしか読めなかったんだが。
じゃあ、俺は一体何について聞かれていたんだ？

ポリモーフィズムのポの字も知らない馬鹿はスルーしろってことじゃねえの

>>525,534,539,546
特有の処理についてもっとkwsk

>>566
>引数なくしてグローバル変数やシングルトンでやり取りされるのが一番困る
何をやり取りされるのが困るかkwsk

>>568
うーん・・・たぶん。こういうことだろう。

>>561は、たとえば衝突判定とかするときに、結局型判定(というか属性判定)するじゃない。
たとえば自機と敵機が同じリスト構造内にいても、自機⇔敵機衝突判定するときに、
リスト構造内を検索、その際にゲームオブジェクトが自機なのか敵機なのか属性判定する事は避けられない。
といいたいんだと思う。

だから多態性とか継承とかとはまったく別の問題だよーってことじゃね。>>558見てわかった。


>・入り口のメソッドだけあわせておけばあとはオブジェクトが自発的に処理すりゃいいだろ派
これが俺や>>568が言ってたこと。

>・オブジェクトの相互作用はまとめてかいたほうがいいだろJK。
　そうすると個別のオブジェクトの区別が必要だから1つに束ねると効率悪いだろ。
これが>>561がいってたこと。

たぶん。

・敵リスト
・自機リスト
・背景リスト
みたく属性ごとにリストを分ければ、衝突判定等の記述がシンプルにかける。全部ごった煮にするとかけねーよってことか。

なんだか同じことの繰り返しで対話にならないっぽいので、
他の人から何もなければひとまずこれで引くわ。

>>555
＞自機、敵、自弾、敵弾の内、敵と敵弾だけに絞りたい場合なんかも型を判別する必要あるよな
最初から敵を管理するクラス、敵弾を管理するクラスを用意すればいい。
「タスク」レベルまで抽象化したものをわざわざ判別して取り出す必要はない。
使用頻度が低いとか、必要かどうか前もって分からないとかだったら、
後から取り出しても別に構わないとは思うけど。

>>561
＞まとめた処理がしたかったらそんときだけ必要なもんだけ入れたポインタリストでも作ればいいんじゃないの？
これはそのとおり。タスクリストは「毎フレーム（優先度順に）処理関数を呼ぶ」
「親子関係を持ち、親が死ぬと子も死ぬ」処理を行うためのもの。
（メモリ管理云々は、個人的にはタスク処理とは別の話だと思う）
積極的に他の目的のために使おうとするからおかしなことになる。

>>561の後半は何が言いたいのかまったく分からん。
「次の行動にターゲットが必要にな」るってのはどういうこと？

生きてるか死んでるか不明のポインタって、まだ必要なポインタが
解放されてるかもってこと？　それは構造関係なくただのバグじゃん。


ああ、念の為書いとくけど、別にタスクシステムを（他の方法より）
優れた方法だと言うつもりもないし、ましてや薦める意図はまったくないよ。
既に他の方法を確立しているならそれを使えばいいし、初心者なら
テクニックに走らず、ゲームの構造をそのままクラスにしたほうがいいと思う。
ただ、自分で制限つけたり、他の目的に使おうとしたりして、
「使いにくい」「利点がない」ってのはどうかと思っただけ。

>>571
>>525がそういう意味だとは思えないし、もしそうだったとしても、それについては
「それを必要とするクラスのメンバ変数として持てば、判別の必要はない」と何度も答えてる。
もちろん、「敵の種類」とかの判別は必要になるだろうけど、
それは「ごった煮リストからの判別」とはまったく別の話だよね。

つか、「個別のオブジェクトの区別が必要だから1つに束ねると効率悪い」はそもそも順番が逆で､
同じように扱いたいから１つに束ねたのに、個別のオブジェクトに戻そうとするから効率が悪くなる。
それに、オブジェクトが自発的に（見えるように）updateするのと、そのupdate関数内で
関連するオブジェクトを（個別のオブジェクトとして）利用するのは、別に背反することじゃない。

>>572-573
長ｗ
駄目だよ
レス自体誰も前提にもってない話が勝手に常識のように入ってるし
自分の妄想だけで話進めて俺と会話するつもりもない感じ
いいたいことまとめないとレスつけないよ

だいたい判別する必要あるじゃん
何がねぇんだよ
オブジェクト内に別オブジェクトの型なんかごちゃまぜにアクセスできたら
そもそもカプセル化も糞もねーじゃん
自機クラス内で敵クラスにも弾クラスにもアクセスできる時点でオブジェクト指向破綻してんじゃん
もう言ってることおかしい

>>575
コンポジットというものがあってな
もうしょうがなからぺにっぺにっでにっしんさせるね

OOスタイルで構文解析機を書けば「ごった煮」なASTになるわけだが……
DOMぐらい知らんのか？

まあ、dynamic_castすら知らないぐらいだから仕方がないね

ごめん俺DOMナメてたわ




リックドム。なんちて

dynamic_cast未サポートのコンパイラが普通にあることすら知らないぐらいだから話合わないのも仕方がないね

dynamic_castが使えないのなら、型タグに相当するものを実装すればいいだけだよ
Cのunionならいつもやることだろうに、アホか

え？
そんなコンパイラをお使いで？
相当のマゾでつね
D どんなもんだい
O オレは
M マゾっ気100%だぜ

>>580
union使ったら型システムに穴が空くジャン
できることなら使わずきれいに済ませたいジャン

>>581
それはさすがに釣る気みなぎりすぎｗｗｗ

また、全然関係無いレスばっかりつける
ちょっと前も型の判別方法なんて問題じゃないってのに
キャストキャスト連呼してる恥ずかしい奴がいたけどにたようなのしかいないのか？

>>583
いや、それは>>525が「型の判別方法わからん」とか言ってるから
何人かが教えてやってただけだろ……

>>582
Cなら仕方ないだろ
unionの類を使わずにLispインタプリタでも組んでみたらどうだ？

C++にしても、代数データ型はないのだし、ポリモーフィズムの手段が
継承なのだから、ダウンキャストはある程度宿命であり必要悪だ
無論、それを最低限に抑えることが望ましいがな

>>585
はぁ？なんのための必要悪なの？
そもそもベタ書きでゲーム作ったことあるのかすら怪しいね
だってゲーム作って複雑になるところとキャスト云々って全然関係無いもん

>>583
ごめんよ
以前dynamic_castが使えない環境でゲームプログラム書くことがあったから動的キャスト必須は移植性を考えるとありえないという頭があった。
あとunionは宗教上の理由で滅多に使えないので型タグ相当も小資源で作ることができない。これは俺のポリシー。
ライブラリ内なら使うかも。

そういう条件下だと性能の良し悪しとか概念の洗練度なんて議論とは全く別次元で、簡単に一意に解答が定まってしまう。
　「オブジェクト群を１つに束ねることは不可能」
って。
そういう立場の人もいるかもと頭の片隅にでも置いとくと怒りが安らぐかもしれない。

union使える宗教の人とかdynamic_cast使える環境が大前提の人にとっては有用な議論なんだろうなぁ、きっと。

>>584
それは>>523が特有のメソッドを追加しても問題ないっていうから
特有のメソッドを読んだら型判定が必要になって
ごった煮リストにしておくメリットねーぞって話のつもりだった

が、読み返してみるとたしかに型判定知らないアフォみたいだなｗスマンコｗ
でも問題はそこじゃないんだ

>>572
> これはそのとおり。タスクリストは「毎フレーム（優先度順に）処理関数を呼ぶ」
> 「親子関係を持ち、親が死ぬと子も死ぬ」処理を行うためのもの。

それって、単に子インスタンスをメンバ変数で持つだけで良いんじゃね？

class Enemy;
class Player;
class Scene {
　Player player_;
　std::list<Enemy> enemies_;
public:
　void exec() { PlayerExec(); EnemyExec(); HitCheck(); ... }
};

タスクって何？

>>587
なんだか俺がdynamic_cast云々の発端っぽいので一応言っておくけど。
dynamic_castは「型の判別方法」を聞かれたから答えただけで、
必要なものは元の型のままメンバ変数として持てば、
通常、dynamic_castが必要になる場面はないよ。

>>589
それでいいよ。
別にそういう書き方を否定してないよね。

>>590
>589 で十分だと言いながら、 >572 を読む限りあんたは何かの目的を持って
ごった煮リストにつなぐ（ことがある）んだろ？
しかもそれが初心者にはおすすめできない「テクニック」であると言うじゃないか。

それは何のためなのか、どんなメリットがあるのか、あるいはどんな問題が解決されるのか
ってのがこのスレ的には主題だと思うんだ。

まず、タスクシステムによって解決する問題をはっきりさせるほうが先じゃね？

>>592
>>535

裏山で出土した石器を明日の仕事でどうやって使うか話し合うスレはここですか？

>>594
なんて適切な表現だ

>>594
いいえ。そういう話し合いを望んでいる人間で、現状で生存確認が取れてるのは数人だけ。
筆頭は確定君。「確定」で検索しなさい。

村人達がとっくの昔に遺棄し朽ち果て忘れ去られたはずの山道、というか舗装もされてない獣道。
ある日ハーメルンの笛吹き男が現れこの獣道の入り口だけをお色直しして純真向くな都会の若者達を
招き入れるようになりました。

　「さぁおいで。夢の国へ続く道だよ。通行料代わりに私の本を買ってきなさいピーヒャララ♪」

その獣道は先に進めば進むほど細く険しくなる茨の道。落石や崩落で寸断され死人も出た危険な道。
今では村には国道や高速道路や鉄道が整備されトンネルで一直線に隣村や町に行けるようになり
その危険な獣道を使う村人はもういません。沢山の若者達が嬉しそうに入っていく様子を村人達は
とても不思議そうに眺めていました。「都会の若者が考えるこたわがんねなぁ」
ある村人は興味本位でその疑問を入山する若者に問いかけました。すると若者は快活に答えました

　「え、知らないんですか。可搬性と拡張性に優れた素晴らしい世界へ続く道ですよ。これ確定です」

村人は意味がよくわかりませんでしたが、戻ってきたら旅の感想を聞かせてくれると若者が約束
してくれたので楽しみに待つことにしました。しかし待てど待てどその純真無垢な若者が帰ってくる
ことはありませんでした

タスクシステムって名前じゃなけりゃ
こんなにまで議論の対象にならなかったと思うんだけどなぁ

名前を初めて聞いたときどんなすごいシステムなんだろうと思ったが、
詳細見てしょぼさ加減に思わず吹いたよｗｗｗ

タスクと聞くとOSをイメージしてしまうし、
システムとかたいそうな名前付けてる割には
パターンやイディオムレベルの構造だしな

>>597
そういうことなんだけど、それを理解できずに荒らす人がいるんだよね。
だからそういう人をこのスレに閉じ込めてるんでしょ。

タスク信者を荒らし認定すんなカス

タスク信者乙

タスク信者は
プログラム言語に型なんかないほうが扱いやすいって言ってるのと同じだよね
実際、タスクシステム使って組むと思いっきり型邪魔だしね

タスク信者はあいかわらずソースを出さないので相手にしない

タスクシステムに似た仰々しい名前を教えるね
「コントロールブレイク」
ミンナニハナイショダヨ

>>596
>今では村には国道や高速道路や鉄道が整備されトンネルで一直線に隣村や町に行けるようになり

詳しく

1ヵ月ぐらい住み着いてる抽象的な話で煙に巻く君だ。
放置推奨。

托鉢癖の乞食には酷く癇に障るものらしいよ

>>606
韓国語でおｋ

??? ???

型安全なタスクシステムってC++のtemplateとか使えばできるかな？
無理？

>>609
コード書いてみ

>>609
templateはあくまでコンパイル時の・静的なポリモーフィズムが実現できるだけでしょ

>>609
>>2じゃなくて（ごった煮にはしないで）素直に組む場合
型別で管理クラスを作るのにテンプレートは便利

レス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);
　　}
};

>>613
通りすがりだけど、そのlistが持っているCPlayer*とかは誰が解体するの？

普通のタスクシステムなら、タスクシステムが解体を保証するだろうし、
さもなくば、auto_ptrなりshared_ptrなりを使うのが普通だと思うのだが。

解体責任を明確にする上でもタスクシステムは有効なのだが、
そのことは理解してる？

あと、C++なんだから、structをtypedefするのやめようよ。
それとtemplateの部分、何がしたいのかわからない。

吹きそうにやるからタスクシステムって言うのやめてくれwww

>>613
ちょっとまて
それが何を目的としたどんな問題を解消するのか
それを宣言してから先へ進んでくれ

>>615
話が進まなくなる。
なにか名前がないと会話できないだろ。
フレームワークだけ先に浸透しちゃったから、それぞれが勝手に名前付けてるんだよ。
>>２の人たちは、できるだけ統一したいから、多数派っぽいタスクシステムって名前を使ってるだけじゃないかな。

>>613
ESPを使ったところ、処理単位の粒度を粗くしようとしているのかな。と読み取ってみた

>>614
まぁ>>613のコードがスマポ使ったほうがよさげというのは同意だけど
俺のESPによるとそれは枝葉末節の話のような気がする

ところでその枝葉末節について思うこと

＞普通のタスクシステムなら、タスクシステムが解体を保証するだろうし
＞（中略）解体責任を明確にする上でもタスクシステムは有効

�@キミのタスクシステムというのが何なのか知らんので
　⇒>>2みたいにひとつの循環リストに全オブジェクトをぶち込んでると仮定
�A解体というのが具体的に何（ゲーム上の生死なのかリソース開放なのか）か知らんので
　⇒リソース（メモリ、OSから発行されたデバイス等のインターフェース、etc）の開放と仮定
�B>>2の循環リストが何でソートされてんのか知らんので
　⇒差分処理の順序（>>2のプライオリティ？）でソートされてると仮定

以上の仮定のもとでレスを書くと、キミは
「全部入りの循環リストを舐めれば全リソースを開放できるから>>2は解体を保証してるのだ」と言ってるのね。
ところで>>2の循環リストは第一義にはゲームの処理の手続き、差分処理の順序を表わすものなんだよね？
単に全部入りのコンテナだからという理由でリソース開放用にこれを流用するの？

>>614
常々思うのは、何で>>2は（>>2を擁護する人は）ひとつの循環リストを特別にユーザーオブジェクトに侵入させ
ごった煮の全部入りとし、更にはこれにいろんな責任を与えようとするのかってこと。そこに合理的理由はあるのかな。
単なる貧乏性なんじゃないのかと思うんだよね

順序と集合が共通だから、ということで複数の責任・役目を与えるのはまぁいいよ
でも>>614みたいに第一義にはゲーム更新処理用のコンテナをリソース管理の責任も与えようとするなら
集合は共通してるけど順序は違うんだよね。ソートしなおすんだろうね

あと別件で、以前に>>2は親が死ねば子も死ぬという死の連鎖を表現できるという人がいたけど
これを直接に表現するのは>>2の侵入式の循環リストではなく、ユーザー側で用意する親子関係を表わすツリーだよね。
で、必要ならそのツリーをトラバースした順序をもとに>>2の侵入式循環リストの当該箇所をソートしなおすんでしょう？
>>2は親子の死の連鎖とかぶっちゃけ関係ないよね。ユーザー側に丸投げしてるでしょ

何で普通の（つまり外部収納の）コンテナを役割毎に持たないの？リソース管理用ならリソース管理用
更新手続き用なら更新手続き用、親子関係なら親子関係用、機能を明確に分離できずに無闇に
癒着させるってのは、硬直して首が回らなくなる危険を犯すってことだよ。経験に裏打ちされたものがない人に
こういう貧乏j根性主導のコンテナ共同利用はオススメできないよ

わけわかんなくなるから想像や仮定を前提にして話を進めようとするのはやめてくれ。
わからないことは素直に聞けよ。答えが返ってこなければそこまでの話だ。

> �@キミのタスクシステムというのが何なのか知らんので
> 　⇒>>2みたいにひとつの循環リストに全オブジェクトをぶち込んでると仮定
> �A解体というのが具体的に何（ゲーム上の生死なのかリソース開放なのか）か知らんので
> 　⇒リソース（メモリ、OSから発行されたデバイス等のインターフェース、etc）の開放と仮定
> �B>>2の循環リストが何でソートされてんのか知らんので
> 　⇒差分処理の順序（>>2のプライオリティ？）でソートされてると仮定

とはいえこれは妥当な仮定だわな
解体はゲーム上のオブジェクトの死ではなくリソース開放だろ
>>2のプライオリティの使い方は処理順だ
これも一致してる

ま、仮定するまでもなく的中だろう

なんで妥当なの？
オブジェクトごとのリスト、優先度なし、ソートなし。
これはタスクシステムと言ってはいけない？

>>622
普通は優先度ありはデフォっぽい気がするけどねぇ
じゃないと全てを入れるリスト構造がまともに動くとは思えないし。

全部まとめるから優先順位が必要になるんだよなぁ・・・

http://codezine.jp/article/detail/297
ここにあるサンプルを見る限りでは
オブジェクトごとのリストというよりタスクのリスト（似たようなものかな
優先度あり
優先度によるタスクのソートあり
だが

オブジェクト指向でのタスクシステムで異論を唱えている方は
同じことをやっているが手段が違うといったところですかな

>>622
で？なんなのその聳え立つ一本糞コレクションは。
それでナニすんのおめぇ？食うの？食えんのか？え、食うの？

もう今となってはさ、タスクシステムとか言ってる奴って
こういうカスばっかなんだな。認めざるを得ないわ

>>621
いやいや >613 が >2 を理解しているとは限らないだろ。
少なくとも >613 からはそれは読み取れん。
むしろ >613 が >2 を理解している信者であるという仮定は >613 のコードからすると大胆すぎる。

そもそもこれまでの流れを見る限り信者もアンチもこのスレの住人が >2 を理解してるとは思えん。
俺もよくわからん。書いてることバラバラじゃねえか。

http://nullpo.vip2ch.com/ga26086.jpg

待てなんだこの図は
どこにこんなんあるんだｗ

>>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;};

>>623
言葉が悪かった。
オブジェクトの種類ごとにリストを分けるだけで、単純なものなら優先度が不要になる。
シューティングの弾だったらほとんど生成順に描画で問題ないでしょ。

>>618
> ところで>>2の循環リストは第一義にはゲームの処理の手続き、差分処理の順序を表わすものなんだよね？
> 単に全部入りのコンテナだからという理由でリソース開放用にこれを流用するの？

解体責任が分散すると解体忘れにつながるからC/C++で書くなら
(auto_ptrやshared_ptrを使わずに愚直に書くなら)全部入りのコンテナか、
あるいは、その周辺が解体責任を担うように設計するのは普通だと思うんだが。

>>619 は一理あるので否定はしない。

ただ、(俺が作ってきた)タスクシステムは、タスクの生成/解体まで
タスクシステムがその権限/責任を持っていて、タスクデバッガのようなものを
attachさせて、実行時に走っているタスクをwatchしたり、実行時にbreakを
かけて特定のタスクを生成を指示したりすることが出来る。

まあ、これは「タスクシステム」ではなく、「タスクに関するフレームワーク」と
呼ぶべきかも知れない。ともかく、これが使い回しが利いてとても便利なんだ。

特定のタスクがイレギュラーな構造になっているとこのフレームワークの
恩恵を受けられない。それが嫌なんだな。

まあいいや。たぶんこのスレの趣旨とは違うんだろうから、おとなしくROMっとくよ。

>>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*>のようなものを持っていると、
親が死んだ子に対してアクセスしてしまう。これをどうやって防ぐの？

>>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)でまとめるも良し。そのままでも良し。

>>628
私の趣味の画像でございます
お気にさわるようでしたら削除いたします

>>631
ごめん。相手を見誤ってた。俺は>>618で
ID:8YYLBgEpの言うタスクシステム＝>>2と仮定してたんだけどこれ間違いだね。

ID:8YYLBgEpの言うタスクシステムはゲームオブジェクトのモニタでもあるんだね。
（というかモニタ機能がむしろメインだろうと思う）

＞解体責任が分散すると解体忘れにつながるからC/C++で書くなら
＞(auto_ptrやshared_ptrを使わずに愚直に書くなら)全部入りのコンテナか、
＞あるいは、その周辺が解体責任を担うように設計するのは普通だと思うんだが。

これは同意。上記の仮定間違いに伴うすれ違いだった。具体的には
>>2の場合、ユーザーは（ゲームオブジェクトのジョブを書く奴は）TCBにかなり自由に頻繁に触るので
TCBのパラメータが全く信用ならない⇒解体には別の、外部収納のコンテナが欲しい
（デバッグ用モニタとしては別のアドレス空間に欲しい）という趣旨で書いたんだ

＞ただ、(俺が作ってきた)タスクシステムは、（後略）

全くもって同意。異論を挟む余地がない

以下蛇足

モニタ機能の記述が完全に欠如したタスクシステム解説のWEBページや書籍があまりに多いので、俺は
「世間ではこういうものがタスクシステムと呼ばれるようになったのか。じゃあタスクシステムという言葉を
職場内で使うのも止めよう。」ということでタスクシステムという呼称を使うのやめちゃった

タスクシステム信者にお伺いしたいことがございますが
class A;
class B {
A *obj;
};
が理解できますか？

モニタ機能って、なんか、わざわざ発生させた問題に対策を用意して
対策を売り込むとか、マッチポンプじゃないの？

普通に組んで、普通にデバッガ使うのと何が違うの？

>モニタ機能の記述が完全に欠如したタスクシステム解説のWEBページや書籍があまりに多いので、俺は
>「世間ではこういうものがタスクシステムと呼ばれるようになったのか。じゃあタスクシステムという言葉を
>職場内で使うのも止めよう。」ということでタスクシステムという呼称を使うのやめちゃった

揚げ足を取るようで申し訳ないのですが
Observer パターン というものがございます
http://ja.wikipedia.org/wiki/Observer_%E3%83%91%E3%82%BF%E3%83%BC%E3%83%B3

>>635
了解しました。あなたとは同業者っぽいね。

>>636
コンポジションがどうかしたの？
まぁタスクシステム（>>2）信者じゃないから反応する理由はないんだけど
>>2とは全く異なる、自社製のマイクロカーネルがタスクシステムと呼ばれてたもんでね
まぁ、どうでもいい田舎モンのローカル用語だから実態が違うのは当然だし
世間様の前で「これがタスクシステムだ！」なんて絶叫したりしないから俺は心配ない。はず

>>640
いや、なに
一流と呼ばれている方が私のコンポジションだらけのソースを
わけわからんとおっしゃいまして
彼はタスクシステムを理解できていたようで
疑問に思っていた次第であります

>>638
GoFのデザパタに関する知識は後付け・付け焼刃のハンパなもんだけど
揚げ足をとられてる実感が全くないので詳しく頼むわ

>>642
>呼称を使うのやめちゃった
最後まで読んでおりませんでした
私の論理的ミスです
申し訳ございません

実際、>>619はタスクシステムで組んでるとぶち当たる問題を的確に表現してるな
これを問題と意識せずに華麗にスルーしてしまうとタスクシステムを使い続けるようになるんだろう
まずいものはまずいとちゃんと認識したほうがいい

>>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したり
　　...
}

>>645
> 1. Yes. コピペ上等の精神で乗り切る、はダメ？

・類似コードなのに再利用できない
・同じ処理内容のコードが複数の箇所に現われる

のは、プログラムの書き方がおかしいからだということを
もっと意識しておいたほうがいいと思うよ。

>　・deleteを一気に1フレームでやらずに残り時間に応じて分散させたい場合に
>　　ゲームオブジェクト内のステートだけではタイミングを判断できないかもしれない。

それは、まったく逆だと思う。deleteしているのが一カ所に集中していれば、1フレームでN回以上は
deleteしないという処理を書くのはたやすいけど、deleteしている部分が分散していたら
そんな処理を書くのはとても面倒。

> 親子タスクは無いけれど親子データとか親子オブジェクトは欲しい。
>　それは単なるオブジェクト間の通信に帰着可能だと思うので
> 下のupdate()群のように等価に置き換えできないでしょか。

そのコードのどこにオブジェクト間の通信のコードがあるのかわからない。
あと、その1フレーム分の処理、updateを書き忘れたり、新たに動かすものが増えるごとに
新たにその関数のなかにupdateを呼び出すコードを追加しなくてはならない。

これだといわゆる従来のタスクシステム(>>2)と比べても大幅に劣っている。

そういえば >>613 でゲームオブジェクトとからタスクを分離させた着想の元は
>>553 のレスの
>ゲームオブジェクトをupdateのみを持つ別のクラスで包む
だったかも。
それと「template使ったら何かがきれいに書けるかも！」という思い付きがなぜか混ざった。
昨晩は酔っ払っておりました。

>>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
はできないのでは？　運用でカバー？

>>648　は何が言いたいのかよくわかんないのでもう帰ることにするよ。最後まで相手できなくてごめんね。

2chを久々に見にきて、たまたま面白そうな話題だったからちょっと首つっこんでみただけなんだ。

しかし2chって面白いね。ID:1fr/EvSg みたいなベテランプログラマと、 ID:OfSsMU0e みたいな
ド素人(気を悪くしたらごめんね)とがひとつのスレで議論してたりするんだね。新鮮だった。

俺は大手ゲーム会社でかれこれ15年ぐらいプログラム書いてきてるんだけど、従来のタスクシステム( >>2 )は
出発点としては意味があると思うね。それをフレームワークとしてどう発展させていくかという問題はあるけどね。

>>649
整理して言えずごめんなさいね
ド素人には気は悪くしましたがタスクデバッガのようなものとか私作れないのでまぁ仕方ない。
何年も実業務に携わってる人にケチつける気は毛頭ないです。

生存タスクを列挙したりとか、生成・解放のログを取ったりとかは普通にやるよね。
それ以上のことは普通のデバッガで十分じゃない？

>>609
デザインパターンのオブザーバーとかをスマートポインタあたりでくるんで使うと
だいたい良い感じにそうなると思うよ。

C++の機能を使えばタスクシステムとやらを作っても危険性はまったくなくなるのだが
どうもC言語から離れたくない人が多いみたいだ。

>>652
>C++の機能を使えばタスクシステムとやらを作っても危険性はまったくなくなるのだが
危険性じゃなくて意味がないってほうが言いたいけどな

ほとんどROMってるだけだけど、たまには俺も口を出そう。

何でも同等に扱うごった煮的アプローチが批判されてばかりいるけど、
昔のゲームみたいに敵/味方とはっきり分かれているのは別として
最近の自由度が高いゲームだと元々システム的にあらゆるオブジェクトが
ほとんど対等な扱いだったりするから、そういう状況で使うのは有りだと思う。

PCのゲームだとデータ改竄で普段なら有りえない現象を見たりできるけど、
実装がごった煮っぽい現象はたまに見るよ。

>>654
はぁ？そりゃゲームの仕様の話だろ？
なにいってんだよ
お前、いままでで一番ピントがズレてんだよ
たまに口挟むなんてやらないほうがいいぞ
ここで煽りあって議論してる奴等もピントはずしたらどうなるか
一応わかってレスつけてるからレスを返せるんだぞ

えらそうw

>>655
でもゲームの仕様、つまり実装目標を無視して構造を考えるって、極めて無意味っぽくね？
手段と目的が完全に逆転してる希ガス

>>657
は？仕様がごった煮だからごった煮でいいって？
アフォでしょ？相手にもしたくない驚愕すべきレベルだな

ここでタスクシステムの議論してる人らってそのタスクシステムをなにに使おうとしてるの？
何が便利になるの？

>>653
どっちにしろ出来上がったものはタスクを処理するシステムになる。意味がないもくそも
タスクシステムって名称を貶めたいだけだろうアホめ。

>>659
それが重要だよね

デザインパターンの本を読めばどう便利なのか書いてある

>>662
デザインパターン自体なにも利点のないものが入ってるし疑わしい
そもそもそれがゲームに適用できるのかどうかって検証も必要になると余計ややこしい
やっぱりたとえ話じゃなんの説明にもならないんだよ
説明する内容が複雑でその構造を説明するときにたとえ話はいいかも知れないけどね
この場合デザインパターンの例は役に立たないと思う

デザインパターンの使い方が判らんのか？

正確にはデザインパターンのゲームプログラムへの適用が適切がどうかわからない
デザインパターンはゲームの本じゃないからね
使ってる奴が間違った適用をしてたら意味ないし

なんでこのスレの人は抽象的な話しばっかするんだろう

ゲームプログラムとプログラムが違うと思ってる時点でへんな先入観を持っている。

デザインパターンのオブザーバーとストラテジーはまんまタスクシステムだよ。

オブザーバーとストラテジー？
両方とも目的と適用可能性の説明がゲームオブジェクトとかけ離れていて全く理解不能
どこがわからないとかじゃなくて共通箇所が欠片もみあたらない
パターン間違ってない？

いろんなオブジェクトにメッセージなげて処理してもらって
状況に応じてそれぞれのオブジェクトの中身が変わるんだろ？

>>667
デザパタを理解してないヤシは出てくんな。

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

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

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

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

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

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

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

>>665
＞正確には

正確に言え。

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

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

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

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

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

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

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

ID:f259EVPA
ID:KNFisALs
ID:8MTRCkQM

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

いちいちageんなクズ共

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

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

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

んー、興味深いな。

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

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

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

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

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