トップページ⇒gamedev
1001コメント599KB

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

■ このスレッドは過去ログ倉庫に格納されています
0001名前は開発中のものです。2008/11/09(日) 11:51:40ID:+pjnJyQQ
タスクシステムについての議論、相談、質問、雑談などのスレです

part2 http://pc11.2ch.net/test/read.cgi/gamedev/1196711513/
part1 http://pc11.2ch.net/test/read.cgi/gamedev/1173708588/
0167名前は開発中のものです。2008/12/03(水) 02:14:33ID:Smp60beT
>164は>165を指してるんだよね。
http://pc11.2ch.net/test/read.cgi/gamedev/1036512390/860-862
0168名前は開発中のものです。2008/12/03(水) 03:28:15ID:uVk3FrZq
そのスレ読んだ
LGPLを含むEXEがLGPLに感染してるなんてライセンス文読めば一目瞭然のことを
何とか超解釈で否定しようとしてる子が定期的に出没していて
その理屈は違くね？という人達が理詰めで外堀から確実に徐々に埋め立ててる
そんな感じ？

物事をひん曲げて解釈したがる人を諭すには
駄目押し気味でもああいうのも有効かなとはおもた
0169名前は開発中のものです。2008/12/03(水) 11:42:42ID:YzqEx1FO
>>167
あのスレのレスは三行でまとめて欲しい

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

ところで、感染しないライセンスなんて無いよ。例えパブリックドメインであっても。
結合したら二次著作物なんだから。
0170名前は開発中のものです。2008/12/03(水) 12:08:41ID:1jatayxx
>>169
二次利用に縛りをかけないライセンスは存在する。

ていうか、パブリックドメインとは、だれのものでもない存在だから、
二次著作物とかそういう縛りもない、はず。
0171名前は開発中のものです。2008/12/03(水) 12:59:17ID:YzqEx1FO
>>170
うーん、有名どころで二次利用に縛りをかけないライセンスを見たことないけどな。
少なくとも「本ライセンス文書を同封しろ」と書いてある。

パブリックドメインに関しては著作権者が権利放棄してるから、利用に縛りはないだろうけど。
0172名前は開発中のものです。2008/12/03(水) 13:23:37ID:6uS+aRN8
>>169-170
おまえらあっちのスレでやれ。
>>168
むしろ逆効果にしか見えないのだが、
前スレで釣り宣言してたからそれで狙い通りなのだろう。
0173名前は開発中のものです。2008/12/03(水) 13:25:50ID:ls+0FiDV
三次利用以降に縛りをかけない事、という縛りをかけてるものはあるな
0174名前は開発中のものです。2008/12/04(木) 00:21:20ID:J8DrEDup
数年前のとある同人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;
}
0175名前は開発中のものです。2008/12/04(木) 00:28:18ID:J8DrEDup
_tmainじゃなくて_tWinMainだったかな。よくおぼえてないや
各シーンはいわゆるベタベタの配列厨コード。元HSパーだから仕方ないね
でもメモリもGPUリソースもジャブジャブ使いまくったおかげで
見た目はバリバリのイケイケになったよ。動作も軽快だったよ。自惚れだね
0176名前は開発中のものです。2008/12/04(木) 02:00:33ID:yi3zavJ4
>>174
たのむ
なにが言いたいのか最後に書いてくれ

俺が気になるのは、メインループが本当に必要なのかどうかだな
タスクシステムも、それ以外のＣ＋＋コードでも、なんでメインループ作るん？いらなくね？
普通に書けばいいじゃん（普通ってなによ）
0177名前は開発中のものです。2008/12/04(木) 02:16:23ID:vVwN1TZ0
stage1->Run()はstage1が終わるまで返ってこないんだろ。
いずれにせよゲームなんて毎フレームの同じ処理の繰り替えしなんだから
どこぞかにループは存在するのが当たり前だと思うが。
0178名前は開発中のものです。2008/12/04(木) 02:16:58ID:iyneYGG1
>>176が言う普通ってどんなコードなんだろうね
0179名前は開発中のものです。2008/12/04(木) 03:27:17ID:yi3zavJ4
あーすまん
メインループはどんなプログラムにもあんね

なんかさ、１フレームごとに回るループを作るやり方と
作らないやり方（あちこちでupdateする）について
急に気になって言ってみたんだが
やっぱどっちでもいい気がしてきたからいいや
0180名前は開発中のものです。2008/12/04(木) 04:04:02ID:BYcsjOha
スレッド作るにしろなんにしろ
どこかでスケジューラが回ってるがな
0181名前は開発中のものです。2008/12/04(木) 10:56:55ID:vVwN1TZ0
>>179
> 作らないやり方（あちこちでupdateする）について
> 急に気になって言ってみたんだが

それは使ってるフレームワークが裏でループ回してupdate()呼んでるんだろ。
あるいは割り込み駆動の可能性もあるが。
0182名前は開発中のものです。2008/12/04(木) 22:22:51ID:wPvA+LuT
>>175
＞見た目はバリバリのイケイケ
気になるな。
0183名前は開発中のものです。2008/12/05(金) 00:50:08ID:Vt/x/8eI
>>176
>たのむ
>なにが言いたいのか最後に書いてくれ

地域担当の教団勧誘員に>>174を見せると彼の顔はみるみる青ざめ、ついには目を背けてしまいました。
ただごとでない様子を感じ取った私は恐る恐るその訳を尋ねました。すると彼はおずおずと耳元で囁くのです。
「それはいけない。凶兆が見えます。そのようなものを作っていては遠からず仏罰が下るでしょう。南無妙法蓮華」
>>174は彼らの"先生"の教義に反する、知性体として恥ずべきお猿さんコードなのだそうです。私は狼狽してみました。
幼少の砌よりﾂｸﾗｰにしてHSPerである私の深層に眠る劣等感の残滓の存在をESPで見抜いたのか、彼は目を細め
「安心なさい。今からでも間に合う。私共のように三宝( 　*　 )に帰依なさい。そうすれば必ず道は開けますよ」
と仏様のような微笑みを湛えながらビール券とこの案内状をくれたのです
0184名前は開発中のものです。2008/12/05(金) 00:51:18ID:Vt/x/8eI
>>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のﾌﾟﾗｲｵﾘﾃｲのみ。｜
｜ 　 この崇高なる輪廻転生の法を冒涜し踏み躙る邪教徒共はママの愛情が足りなかったに違いない。 .|
｜　　敬虔なる信徒諸君は彼らの妄言に惑わされることなく修行に励みたまえ。そして最終解脱者となっ.｜
～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～

ビール券に弱い僕は誘われるままホイホイとこのスレにやって来たんだね
0185名前は開発中のものです。2008/12/05(金) 03:20:55ID:JyB7wu71
そろそろタスクシステム総合スレじゃなくて
ゲームシステム総合スレに名前変えね？
>>2を使ってる人は皆無なわけだし
0186名前は開発中のものです。2008/12/05(金) 04:47:21ID:U4VbVISL
いや、ここ隔離スレだから…
0187名前は開発中のものです。2008/12/05(金) 05:37:33ID:lg/+bi94
>>185
あー、ゲームシステム総合とか間抜けたスレタイいちいち考えなくていいから
既存スレちゃんとあるんで。こっちでは撲殺天使の人もあっちでは普通だから

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

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

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

は？お前が憤死しても代わりは幾らでも湧いてくるから心配しなくていいって
0188名前は開発中のものです。2008/12/05(金) 09:54:30ID:bKzmksBZ
やね本はプレミア付く程のレア物
0189名前は開発中のものです。2008/12/06(土) 00:08:37ID:AlgIGpgY
>>166
何がいいたいかわからん。動的インスタンスリスト巡回アップデートwの具体的なメリットデメリットを指摘すればいいんじゃないか？
ttp://www.issei.org/
そのひらしょ氏の本を手伝ったらしいPGさんのブログ。タスクシステムらしきソースがある。
問い詰めた知人てこのひとかな？
例えば>>174をタスクシステムで書いたとして、単純に比較すればそりゃ
>直感的でない、変に抽象化されてデバグしにくい、実行順がコードの形で書かれておらずメンテしにくい
コードだと思うんだよ。んで、それでも使いたいメリットあるのか？て話だよな。

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

あと、メインループ周りを作ってしまえば、そこをいじらなくても別のゲームが作れるのは
なれれば安心感があるな。
ただ、万人にお勧めできるかつと、それはちょっと難しいかもとは思う。
0190名前は開発中のものです。2008/12/06(土) 00:15:03ID:+2mVCqZ1
>>189
>ためしにプロトタイプを作ってて、「ここで一発エフェクトが欲しいな」と思ったところで、new してリストにつなぐだけで動くってのはちょっと感心した。
これホントは動かないのが普通なんだよ
裏でグローバル変数でつながってるからnewするだけで動くように見えるだけ
可能でしょ？そういうの？
本来あるべき手続きを見た目見えなくするもんだから
後で「え？そんなところと関係あるの？」っていう部分がボロボロ出てくる

結果これ以上ないデスマになる
0191名前は開発中のものです。2008/12/06(土) 00:28:23ID:AlgIGpgY
>>190
レス早すぎるだろw
>後で「え？そんなところと関係あるの？」っていう部分がボロボロ出てくる

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

＞裏でグローバル変数でつながってるから
これ、このスレでよく批判の対象になってるけど、俺が見た範囲では
それぞれ listはprivateにしたり一応保護する工夫をしているように見えるけど
「オブジェクト同士が相互参照できるならグローバルと同じで無意味」ってこと？
0192名前は開発中のものです。2008/12/06(土) 03:37:13ID:+2mVCqZ1
>>191
タスクシステム云々ってよりグローバル変数の駄目な理由そのものじゃん
0193issei2008/12/06(土) 07:28:54ID:wah4ZAkA
>>189
> タスクシステムらしきソースがある。
どこに？

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

http://www.issei.org/blog/archives/000225.html
0194名前は開発中のものです。2008/12/06(土) 11:22:47ID:r2noZKmJ
>>193
名前欄入れてらっしゃるけど、ご本人様で？

そのエントリによると、新人研修でタスクシステムのようなものを教えてる
ところは実在するわけですかね。
0195名前は開発中のものです。2008/12/06(土) 12:02:44ID:+2mVCqZ1
散々タスクシステムを崇拝してきた人間も
ひらしょーさんの「なにそれ？」で完全に散ったなｗ
0196名前は開発中のものです。2008/12/06(土) 12:40:25ID:r2noZKmJ
入門を脱したばかりの奴が入門記事を書く悪循環に、
ちょうどタスクシステムがはまっていた感はあったな。
CodeZineとか。
0197issei2008/12/06(土) 19:18:28ID:wah4ZAkA
>>193
私は新人研修に関わってないので、どういう文脈で紹介されたのかは不明です。
研修中の息抜きで、単なる昔話してたのかも。
01981892008/12/06(土) 22:51:20ID:AlgIGpgY
>>193 ありゃ？そのページをみて書いたんだけどw
釈迦に説法だと思うけど、一応、

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

というような定義がこのスレでは何度か上がってて、オブジェクトの種類ごとに
リストを分けるべき、てな議論もあるんで、>>193のサンプルや、ほかに公開している
ものはその範疇かな、と思った。
　定義自体あいまいなところがあるので、タスクシステムと呼ばれたくない、
ということであれば申し訳ない。
0199名前は開発中のものです。2008/12/06(土) 23:09:38ID:vtDZydvR
毎フレームstd::listに繋がったメンバ関数を呼ぶだけのものに
システムとか名前つけること自体が厨臭くてダメだろ。
0200名前は開発中のものです。2008/12/06(土) 23:25:08ID:Z3cf8eY8
GUIアプリのデザインパターンとしてなんらかの名前があると思うんだけどなぁ
0201名前は開発中のものです。2008/12/06(土) 23:49:37ID:gO9ddo5C
>>199
命名自体は思考の道具として必須だよ。
りんごを「りんご」と呼べないならそれをどう頭の中で扱うのか？

ただ、付ける名前の好き嫌いと妥当性はあるだろう。
自分の子供に「悪魔」と名づけたら批判される。
まあその程度なんだが。
0202名前は開発中のものです。2008/12/07(日) 01:28:33ID:DJqT4ev1
大袈裟過ぎるのは確かなんだが
いまさらどうにもなんないよなぁ
0203名前は開発中のものです。2008/12/07(日) 02:16:59ID:ubrMdVl3
>>202
タスクもシステムもOSを意識してしまう用語だからな。
言葉の意味的には >>92 のいう　ジョブコン（トローラ）の方がより厳密かなあ。
0204名前は開発中のものです。2008/12/07(日) 02:54:06ID:0juovOZI
名前なんかどうでもいいじゃん、あほらしい
0205名前は開発中のものです。2008/12/07(日) 03:37:41ID:mATZsXLl
しかし、タスクシステムを崇拝してる奴等は
自分が学ぶ技術に名前や名称がほしかったんだろうな
理由はきっとそっちのほうがたしからしく見えるからかな？

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

ひらしょーさんと同じことを説明してくれてる人はたくさんいたけど
名称の魔力があったから信者はまったく聞き入れなかったよね
0206名前は開発中のものです。2008/12/07(日) 11:05:38ID:DJqT4ev1
>>205
信者決め付け脳はウザい。
0207名前は開発中のものです。2008/12/07(日) 13:20:37ID:kyRfBfLD
内なる敵と戦っているんだよ。
0208名前は開発中のものです。2008/12/07(日) 14:00:36ID:So4hgvTQ
http://game.watch.impress.co.jp/docs/20070131/3dlp.htm
システムはどうかしらないけど、ゲーム業界でタスクは一般的になってると思うよ。
俺が書いたコードをソフトメーカーの人に見せたら、汎用タスクだねって言ってた。
0209名前は開発中のものです。2008/12/07(日) 14:40:22ID:DJqT4ev1
>>208
まぁその記事の「タスク」は、MTフレームワークの用語としての「タスク」だと
思うが。
0210名前は開発中のものです。2008/12/07(日) 16:34:44ID:So4hgvTQ
>>209
このスレで言ってるタスクシステムとなにが違うの？

「タスク」はプレーヤー、敵、カメラ(視点)、ライティングなどの同時多発的に発生する
ゲームを進行させる処理そのもののことを指す。
各タスクには、プレーヤータスクの更新処理、描画処理。
敵タスクの更新処理、描画処理といった形で「更新処理」、「描画処理」が存在する。
0211名前は開発中のものです。2008/12/07(日) 17:02:09ID:mATZsXLl
>>210
まあ、似たようなもんだろ
0212名前は開発中のものです。2008/12/07(日) 17:12:29ID:mATZsXLl
ただ、あんまりうまくいってねぇ気がするね
だってそんなもん作ったわりにそれほど見応えのあるソフト連投してねぇし
0213名前は開発中のものです。2008/12/07(日) 20:03:21ID:4pqMat4a
ジョブコンがアンチパターンである理由

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

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

※２は、言い換えると「様々なコードの断片や描画物を、必要に応じて追加・削除できるオブジェクトとして
　同じ抽象レベルで扱える」というメリット的な言い方も出来るかも知れん
0214名前は開発中のものです。2008/12/07(日) 20:56:55ID:hSkKXTzZ
タスクシステム否定派　＝　人の意見に盲従するヘタレ

ということはわかった。
0215名前は開発中のものです。2008/12/07(日) 23:20:58ID:YTdxZCAS
＞１．グローバル変数（または静的クラス変数）を多用しがち
変数の参照範囲は必要なだけ広く、そして最小範囲
タスクシステムだからこれが出来ないという理由はない
少なくともリストや配列を使った非タスクシステム比べて
変数の参照範囲を広くとる必要などない

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

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

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

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

最初は状態変数で分岐させてるけど、後半はタスクシステムじゃねーか
0217名前は開発中のものです。2008/12/08(月) 00:01:48ID:62ubqb8M
>順序制御機構があるならコードは見やすいだろう

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


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

ひらしょーは正直どうでもいいｗ
0218名前は開発中のものです。2008/12/08(月) 00:11:25ID:nrC30ZCa
>>215
>変数の参照範囲は必要なだけ広く、そして最小範囲
>タスクシステムだからこれが出来ないという理由はない
>少なくともリストや配列を使った非タスクシステム比べて
>変数の参照範囲を広くとる必要などない
それってソースコード読む人にどうやって伝えるの？
0219名前は開発中のものです。2008/12/08(月) 08:47:20ID:3OfRiy2M
>>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。多少回りくどいが、メッセージのパスがシンプルになってコード
見れば一目瞭然になるので、バグは減るし追加処理を入れやすい。

単一型リストにしちゃうと引数型も当然単一になるから、引数で情報を渡すのが
不可能になって、結局グローバルな領域に情報を記録することになる。そうなると
いつ誰が読み書きするかわからないので、予期しないタイミングで予期しない処理を
されて泣くわけだ。
0220名前は開発中のものです。2008/12/08(月) 08:52:11ID:3OfRiy2M
ゲームの場合は、プログラムの基本構造が「一定時間ごとに外から関数を呼ばれる
小さなオブジェクトの塊」になる。

このオブジェクトを単一リストに入れることで型システムや変数スコープの利点を捨るか、
あるいは複数のリストに入れることで仕様変更時のソースコードの変更範囲が大きくなる
のを諦めるかというのがトレードオフなんだろうね。
0221名前は開発中のものです。2008/12/08(月) 12:05:50ID:aJ+u6Y4C
なんかいきなりジョブコン叩きをはじめた奴がいるが。

ジョブコンの利点は、コルーチンが実現できることだ、ってのは把握してる？
0222名前は開発中のものです。2008/12/08(月) 12:28:19ID:rbhhFL67
叩いているようには見えないし
そもそもコルーチンじゃないし
信者を装うにも無理がある
0223名前は開発中のものです。2008/12/08(月) 12:56:45ID:+P2RkRte
>>220
仕様変更が起こってもソースの変更範囲を小さくできるなんてメリットだとは思わないな。
それができるということは仕様とソースが乖離していること、乖離していくことを示している。
0224名前は開発中のものです。2008/12/08(月) 13:24:53ID:HU7PRYqb
>>223
確かに仕様変更の中身に強く依存することなので
一般論としてしまうには無理があるな。
設計によって対応しやすい変更としにくい変更があるだろうから
それらを具体的に考えてみるのもいい。
0225名前は開発中のものです。2008/12/08(月) 13:40:00ID:96cnGhTJ
>>223
> 仕様変更が起こってもソースの変更範囲を小さくできるなんてメリットだとは思わないな。
> それができるということは仕様とソースが乖離していること、乖離していくことを示している。

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

小さな仕様変更でソースのあちこちを変更しなければならないという状態のほうが、
仕様と乖離したソースだということになるはずだが？
02262232008/12/08(月) 14:05:31ID:+P2RkRte
>>225
ごめんよ。もちろん１つの仕様変更であちこち変更するのを基準に「小さく」って話を
してるわけじゃないんだ。

ある処理が依存する情報について変更があっても、グローバル変数を使っていれば
関数の引数には変更が現れなかったりする、そういう変更の小ささがメリットだとは思わない
って話。
0227名前は開発中のものです。2008/12/08(月) 19:17:09ID:nrC30ZCa
>>226
同意
特にグローバル変数まで使って変更を強引に縮小することにメリットは全く無い
0228名前は開発中のものです。2008/12/08(月) 21:47:43ID:3OfRiy2M
グローバル変数を使っていれば、明示的に引数などで渡す必要がない
struct 使っていれば、わざわざ setter, getter を使う必要がない

……それが通じるのは、アドレス空間 64KB の世界までだよな。
0229名前は開発中のものです。2008/12/09(火) 21:57:26ID:Cm1hssKy
タスクシステム
ストラテジーパターン
FSM

違いがわかりません
0230名前は開発中のものです。2008/12/09(火) 23:12:27ID:kSxszrcc
タスクシステムはC言語より前に生まれたのでは
0231名前は開発中のものです。2008/12/09(火) 23:57:46ID:4ucfkUBf
>>230
キミはＣ言語の誕生をいつと思ってるのカネ？
0232名前は開発中のものです。2008/12/10(水) 00:41:20ID:zML+BZeA
UNIX用に作られたくらいだった気がするので３０年前くらい？

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

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

ゲーム上でのタスクは後になるのか。タスクの元になるものが更にあるかは知らないｗ
0233名前は開発中のものです。2008/12/10(水) 01:56:38ID:vj+7d+7Z
230を好意的に解釈すると

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

C言語使うようになったのなんて90年代になってからだね。
0234名前は開発中のものです。2008/12/11(木) 00:44:32ID:RMSlUpht
>>208
汎用。これはとても便利な言葉だ
これは何にでも使えるね、というポジティブな意味に使えるし
これは何にもできないね、というネガティブな意味にも使える
どちらに重みが置かれるかはケースバイケースだが
仮に後者の重み係数が大きくても角が立たないという魅力的な言葉だ

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

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

0235名前は開発中のものです。2008/12/11(木) 01:28:26ID:U09K2ObF
いちいち駆け引きしなきゃ話もできんようなやつとは
仕事したくないなあ
0236名前は開発中のものです。2008/12/11(木) 10:19:51ID:tNsh0a9k
90年代？自分の記憶がソースかよ
0237名前は開発中のものです。2008/12/11(木) 22:05:22ID:IWquCMNP
>システムはどうかしらないけど、ゲーム業界でタスクは一般的になってると思うよ。

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

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


という談話を聞いてきたHSPerでした
0238名前は開発中のものです。2008/12/11(木) 22:17:27ID:IWquCMNP
>>237訂正
>ユーザーに直接タスクを記述させて

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

ジョブエントリの連結リストを走査して順次処理するだけの単純な仕掛けだから
スケジューリングがなってないしデッドラインに処理が完了するようマネージメントすることもできない
全てマニュアル操作。ユーザーに責任を押し付けてる。劣化ジョブコンとも
0239名前は開発中のものです。2008/12/12(金) 01:51:42ID:EK0D+T+v
半年程うだうだやってようやくタスクシステム卒業できた気がする俺からのヒント。
これでこのスレからも卒業だ！

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

　上のレイヤではvoid enter_frame(void)、void display(void)のようなタイミング通知の意味しかない関数
　（C++ならメソッド）を用意しておいて、イベントハンドラからはそれを呼ぶだけに留める。
　データの受け渡しはあくまでも上主導で。
　下主導で上へとアクションかけるのは処理実行タイミング通知（関数呼び出し）だけ。
　入力データは下のレイヤでバッファリングしておいて上のレイヤが下に参照しに行く。相互参照を避けるため。
　タイミング通知の関数のタスクシステムとの違いは、それらの関数がプログラム中にただ一つずつしか存在しないこと。
　関数呼び出しされた側では、その関数内で１フレーム分の処理を手続き型言語丸出しで書いてＯＫ。
　例えばif文、switch文も関数呼び出しも他のインスタンスのメソッド呼び出しも自由自在だし、がんがん引数渡し可能。
　ゲームオブジェクト種別ごとに別の配列用意したりとかも普通にできるようになる。
　ウィンドウプログラムに入る前のC入門書のノリで普通にプログラム書ける。
（続く）
0240名前は開発中のものです。2008/12/12(金) 01:52:20ID:EK0D+T+v
（続き）
2.ゲームプロジェクトとは別にライブラリプロジェクト作る。Visual C++ 2008 Express Editionでもライブラリ用のプロジェクト簡単に作れる。
　１つのプロジェクトで既にきれいに分けれていると思っててもプロジェクト分けると切れてなかったことに気づく。結構重要。
　ライブラリ化はよくある普通の部品化レベルでよい。
　フレームワーク作りはまだ止めとけ。部品化だけで十分役立つ。というかタスクシステム卒業したら部品化できる範囲が急激に広がるのでそれだけで十分手一杯になれる。


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

#プログラム構造の文献はCで完結するような原始的な領域の本が分かりやすくていいよ。組み込みとかの。SESSAME WGのとか。
0241名前は開発中のものです。2008/12/12(金) 02:04:21ID:NGRnTHCb
おまえらやっぱり1度Java経験しといたほうがいいと思った
0242名前は開発中のものです。2008/12/12(金) 05:20:00ID:J9pDnhIw
>>239-240
タスクシステム大好きっ子を締め上げたりしてる俺だが流石にお前は可哀相に思う

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

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

これこそサイコー！って言ってるだけ。>>2のmain関数だって同じように書けるし。アホかお前。氏ね
抑制したつもりだったけどやっぱり無理でした
0243名前は開発中のものです。2008/12/12(金) 07:57:45ID:uOw1miUt
タスクシステムって単なるオブジェクト指向プログラミングなんじゃねーの？
時代に乗り遅れた奴らが悶絶してるスレにしか見えないｗ
0244名前は開発中のものです。2008/12/12(金) 08:56:23ID:6q9RSuqq
>>243
オブジェクト指向のキモは、クラスの洗い出しと、クラス間の関連を見極めること。
何でもかんでもグローバル変数に書いて共有するのはダメだろ。
0245名前は開発中のものです。2008/12/12(金) 13:54:57ID:6fpFqUQy
タスクシステムとグローバル変数には何の関連性もないし
タスクシステムがオブジェクト指向であるというのもそのとおり。

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

デザパタより昔からあった手法だし、C++よりは古い。
0246名前は開発中のものです。2008/12/12(金) 22:29:53ID:vHZmpFnT
クラスもなければプロトタイプでもない、CLOS のような多態のメカニズムもない。
どこがどうオブジェクト指向なんですかね。
0247名前は開発中のものです。2008/12/12(金) 22:35:04ID:EK0D+T+v
>>243
１口にオブジェクト指向といってもメッセージングとオブジェクト主体の動的なものと、
構造体主体の静的なものとかがある。前者はスクリプト言語とか。C/C++は主に後者。

参考： http://d.hatena.ne.jp/sumim/20040525/p1
0248名前は開発中のものです。2008/12/13(土) 00:25:41ID:m0qW0f8x
このスレの異常に不憫な嫌タスク厨を見てて
いつも思うことがあるんだが・・・




「神は自らタスクるものをタスク」
0249名前は開発中のものです。2008/12/13(土) 00:26:53ID:de3lQl9T
>>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フレーム待ってるやり方。
0250名前は開発中のものです。2008/12/13(土) 01:06:41ID:1u8g2R1V
>>249
それってホーミングミサイルがターゲッティングした相手とか
キャラと移動床、移動床と固定壁の相互判定の処理とかって
どこ飛んでいっちゃってんの？

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

上記のことをそのシステム使って解決しようとすると
もう関数の引数でやりとりできないからグローバル変数使って回避するしかないっしょ？
0251名前は開発中のものです。2008/12/13(土) 01:16:46ID:gfZ50szk
>WM_LBUTTONDOWNとかWM_MOVINGとかWM_DESTROYみたいなイベントも扱う。
>それら入出力関係・アプリ生存期間の制御関係のものと、ゲーム処理をいっしょくたに
>扱える標準的インタフェースなんて作るなというのが主旨

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

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

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

0252名前は開発中のものです。2008/12/13(土) 01:38:03ID:1u8g2R1V
>>250はレス先間違えたｗ
0253名前は開発中のものです。2008/12/13(土) 02:16:57ID:gfZ50szk
>タスクシステム＝イベントハンドラ崩れorイベントハンドラの俺ゲーム最適化後というイメージを持ってる。

>>2にはイベントという概念はないしイベントディスパッチャもないよ
イベント駆動システムの体を成してないよ
>>2はジョブの連結リストを走査して全ての要素（ジョブ）をディスパッチしてる
つまり単純な順次処理しかしてくれないよ
イベントがあるとすれば、それはユーザー自身がジョブの中で記述しなければならないよ
>>2は何にもしてくれないよ
0254名前は開発中のものです。2008/12/13(土) 09:18:22ID:HlSyOfLl
イベントというかメッセージだったかな
HSPerは頭よくないから使い分けがよくわかんないの

ケータイだからID違うのはしかたないね
0255名前は開発中のものです。2008/12/13(土) 15:00:33ID:qrT1CCoR
>>242
不憫なやつだな、お前
なんかわかった気になっちゃってんだろうけど

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

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

あ、でもタスクしか使えない老害はそろそろ消えてくださいｗ
もうバブルは終わったんだよ。過去にしがみつくなｗｗｗ
0256名前は開発中のものです。2008/12/13(土) 15:49:54ID:nTnjQTuE
モナドを使ったステートレスなタスクを考えてください
0257名前は開発中のものです。2008/12/13(土) 16:20:05ID:Q1lPMEoI
CPSでおｋ
0258名前は開発中のものです。2008/12/13(土) 21:30:40ID:rCULSb4p
久しぶりにのぞいたら例の本でふきあがってるのな
まだ続いてる？
いわゆるタスクシステム的な抽象度の高いオブジェクトがシステム最上層で一本だけのリストに
なってる系の設計の問題だと思う点はタスクの描画順序を変えようとしてプライオリティを変えると
その抽象度の高いクラスを継承するクラス全部リコンパイルするハメになるとこ
そして最近は複数バッファを使う技術を実装する途上で描画順序を変えなくてはならなくなることが多い
同一のリソースに複数回描画を要請することもある
0259名前は開発中のものです。2008/12/13(土) 23:19:03ID:ngcrwCO9
本当のタスクシステムはリストではなくリングバッファ
リスト使うやつはまがい物
0260名前は開発中のものです。2008/12/14(日) 02:07:26ID:JyTBiW8D
>>255
で、なんで急に「ジョブコン」の話を始めてるのかな？
俺は>>2の話をしたがお前はそれを「ジョブコン」の話だと思ってるのかな？
もしかしてお前、>>2＝「ジョブコン」だとでもいいたいのかな？まさかね

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

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

　今では誰もが使っているというか、既に時代遅れなのですが、当
時はプログラマに読者層がある雑誌などで、プログラムを解析して
紹介したりしてました。
0262名前は開発中のものです。2008/12/14(日) 06:36:31ID:lnd0cLcc
描画順序を内包するから問題になるのであってそれは外にだせばいいだけだな
それでも複雑・特殊化した描画のシーケンスに対する柔軟性のなさは相変わらずだけど
0263名前は開発中のものです。2008/12/14(日) 08:13:40ID:zCveThyG
業務用アプリでさえタスクシステムなのにお前らいつまでこんなネタを繰り広げてるんだよ
0264名前は開発中のものです。2008/12/14(日) 10:46:26ID:hPd7IYfR
×タスクシステム
○イベント駆動
0265名前は開発中のものです。2008/12/14(日) 13:38:40ID:zax2tb8N
タスクシステム　＝　リアルタイム・ゲームにおける並列動作処理の基本アイデア

基本アイデアを否定するって、初心者掲示板においてどんだけ罰あたりなんだよ。
0266名前は開発中のものです。2008/12/14(日) 13:55:05ID:J0IK5eg8
>>265
ゲームの基本アイデアは、

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

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