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

**名前は開発中のものです。** · 2008/11/09(日) 11:51:40

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

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

**名前は開発中のものです。** · 2008/11/26(水) 00:23:32

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

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

**名前は開発中のものです。** · 2008/11/26(水) 01:14:00

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

**名前は開発中のものです。** · 2008/11/26(水) 02:19:03

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

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

**名前は開発中のものです。** · 2008/11/26(水) 02:34:19

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

**名前は開発中のものです。** · 2008/11/26(水) 08:30:23

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

**130** · 2008/11/26(水) 23:22:37

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

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

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

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

**130** · 2008/11/26(水) 23:23:39

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

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

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

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

**130** · 2008/11/26(水) 23:28:25

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

**名前は開発中のものです。** · 2008/11/26(水) 23:53:44

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

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

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

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

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

だよな

（続く）

**名前は開発中のものです。** · 2008/11/26(水) 23:55:50

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

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

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

**名前は開発中のものです。** · 2008/11/27(木) 00:37:08

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

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

**名前は開発中のものです。** · 2008/11/27(木) 00:57:00

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

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

**名前は開発中のものです。** · 2008/11/27(木) 05:33:57

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

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

**名前は開発中のものです。** · 2008/11/27(木) 06:07:57

プライオリティについては>>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リストに入れりゃいいんだよ。
別に配列でもいいが。

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

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

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

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

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

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

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

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

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

**名前は開発中のものです。** · 2008/12/01(月) 19:17:54

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

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

大手ならどこでも通じる

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

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

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

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

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

**名前は開発中のものです。** · 2008/12/02(火) 01:05:14

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

**名前は開発中のものです。** · 2008/12/02(火) 08:48:36

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

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

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

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

**名前は開発中のものです。** · 2008/12/02(火) 19:37:52

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

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

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

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

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

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

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

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

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

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

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

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

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

**名前は開発中のものです。** · 2008/12/03(水) 02:14:33

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

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

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

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

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

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

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

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

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

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

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

**名前は開発中のものです。** · 2008/12/03(水) 12:59:17

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

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

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

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

**名前は開発中のものです。** · 2008/12/03(水) 13:25:50

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

**名前は開発中のものです。** · 2008/12/04(木) 00:21:20

数年前のとある同人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;
}

**名前は開発中のものです。** · 2008/12/04(木) 00:28:18

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

**名前は開発中のものです。** · 2008/12/04(木) 02:00:33

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

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

**名前は開発中のものです。** · 2008/12/04(木) 02:16:23

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

**名前は開発中のものです。** · 2008/12/04(木) 02:16:58

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

**名前は開発中のものです。** · 2008/12/04(木) 03:27:17

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

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

**名前は開発中のものです。** · 2008/12/04(木) 04:04:02

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

**名前は開発中のものです。** · 2008/12/04(木) 10:56:55

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

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

**名前は開発中のものです。** · 2008/12/04(木) 22:22:51

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

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

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

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

**名前は開発中のものです。** · 2008/12/05(金) 00:51:18

>>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のﾌﾟﾗｲｵﾘﾃｲのみ。｜
｜　この崇高なる輪廻転生の法を冒涜し踏み躙る邪教徒共はママの愛情が足りなかったに違いない。 .|
｜　　敬虔なる信徒諸君は彼らの妄言に惑わされることなく修行に励みたまえ。そして最終解脱者となっ.｜
～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～

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

**名前は開発中のものです。** · 2008/12/05(金) 03:20:55

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

**名前は開発中のものです。** · 2008/12/05(金) 04:47:21

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

**名前は開発中のものです。** · 2008/12/05(金) 05:37:33

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

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

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

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

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

**名前は開発中のものです。** · 2008/12/05(金) 09:54:30

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

**名前は開発中のものです。** · 2008/12/06(土) 00:08:37

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

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

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

**名前は開発中のものです。** · 2008/12/06(土) 00:15:03

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

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

**名前は開発中のものです。** · 2008/12/06(土) 00:28:23

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

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

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

**名前は開発中のものです。** · 2008/12/06(土) 03:37:13

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

**issei** · 2008/12/06(土) 07:28:54

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

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

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

**名前は開発中のものです。** · 2008/12/06(土) 11:22:47

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

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

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

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

**名前は開発中のものです。** · 2008/12/06(土) 12:40:25

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

**issei** · 2008/12/06(土) 19:18:28

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

**189** · 2008/12/06(土) 22:51:20

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

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

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

**名前は開発中のものです。** · 2008/12/06(土) 23:09:38

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

**名前は開発中のものです。** · 2008/12/06(土) 23:25:08

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

**名前は開発中のものです。** · 2008/12/06(土) 23:49:37

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

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

**名前は開発中のものです。** · 2008/12/07(日) 01:28:33

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

**名前は開発中のものです。** · 2008/12/07(日) 02:16:59

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

**名前は開発中のものです。** · 2008/12/07(日) 02:54:06

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

**名前は開発中のものです。** · 2008/12/07(日) 03:37:41

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

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

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

**名前は開発中のものです。** · 2008/12/07(日) 11:05:38

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

**名前は開発中のものです。** · 2008/12/07(日) 13:20:37

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

**名前は開発中のものです。** · 2008/12/07(日) 14:00:36

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

**名前は開発中のものです。** · 2008/12/07(日) 14:40:22

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

**名前は開発中のものです。** · 2008/12/07(日) 16:34:44

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

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

**名前は開発中のものです。** · 2008/12/07(日) 17:02:09

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

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

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

**名前は開発中のものです。** · 2008/12/07(日) 20:03:21

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

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

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

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

**名前は開発中のものです。** · 2008/12/07(日) 20:56:55

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

ということはわかった。

**名前は開発中のものです。** · 2008/12/07(日) 23:20:58

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

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

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

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

**名前は開発中のものです。** · 2008/12/07(日) 23:21:29

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

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

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

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

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

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

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

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

**名前は開発中のものです。** · 2008/12/08(月) 00:11:25

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

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

>>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。多少回りくどいが、メッセージのパスがシンプルになってコード
見れば一目瞭然になるので、バグは減るし追加処理を入れやすい。

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

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

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

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

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

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

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

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

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

**名前は開発中のものです。** · 2008/12/08(月) 12:56:45

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

**名前は開発中のものです。** · 2008/12/08(月) 13:24:53

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

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

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

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

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

**223** · 2008/12/08(月) 14:05:31

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

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

**名前は開発中のものです。** · 2008/12/08(月) 19:17:09

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

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

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

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

**名前は開発中のものです。** · 2008/12/09(火) 21:57:26

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

違いがわかりません

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

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

**名前は開発中のものです。** · 2008/12/09(火) 23:57:46

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

**名前は開発中のものです。** · 2008/12/10(水) 00:41:20

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

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

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

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

**名前は開発中のものです。** · 2008/12/10(水) 01:56:38

230を好意的に解釈すると

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

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

**名前は開発中のものです。** · 2008/12/11(木) 00:44:32

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

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

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

**名前は開発中のものです。** · 2008/12/11(木) 01:28:26

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

**名前は開発中のものです。** · 2008/12/11(木) 10:19:51

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

**名前は開発中のものです。** · 2008/12/11(木) 22:05:22

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

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

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

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

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

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

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

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

**名前は開発中のものです。** · 2008/12/12(金) 01:51:42

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

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

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

**名前は開発中のものです。** · 2008/12/12(金) 01:52:20

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

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

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