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

**名前は開発中のものです。** · 2009/12/13(日) 18:11:06

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

part8 http://pc11.2ch.net/test/read.cgi/gamedev/1250678891/
part7 http://pc11.2ch.net/test/read.cgi/gamedev/1241670786/
part6 http://pc11.2ch.net/test/read.cgi/gamedev/1238725539/
part5 http://pc11.2ch.net/test/read.cgi/gamedev/1234977661/
part4 http://pc11.2ch.net/test/read.cgi/gamedev/1233459490/
part3 http://pc11.2ch.net/test/read.cgi/gamedev/1226199100/
part2 http://pc11.2ch.net/test/read.cgi/gamedev/1196711513/
part1 http://pc11.2ch.net/test/read.cgi/gamedev/1173708588/

・タスクと呼ばれる実装は、非常に多岐に渡ります
　古典タスクシステムについての話題は「>>2」と明示してください
　そうでない場合はカスタム版であることを明示してください

・人を憎んで言語を憎まず

**名前は開発中のものです。** · 2009/12/13(日) 18:12:02

古典タスクシステム（このスレでは「>>2」と呼ぶ）

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

タスクシステムのご先祖の「ジョブコン」は
http://game.2ch.net/gamedev/kako/1006/10061/1006184421.html の 810

**名前は開発中のものです。** · 2009/12/13(日) 18:12:48

http://ja.wikipedia.org/wiki/%E8%A3%B8%E3%81%AE%E7%8E%8B%E6%A7%98
あらすじ
新しいシステムが大好きなゲームプログラマの元に、二人組の詐欺師が
プロのゲーム開発者という触れ込みでやって来る。
彼らは何と、馬鹿や自分にふさわしくない仕事をしている者にはメリットが
理解できない不思議なシステムを紹介してくれるという。
プログラマは大喜びで紹介されたとおりに実装する。
他のプログラマにメリットを聞かれた時、自分がこれまで慣れ親しんだ
コードを正当化してくれるはずのメリットが説明できない。プログラマは
うろたえるが、そのシステムを自慢げに見せた後輩プログラマたちの手前、
本当の事は言えず、ありもしないメリットから目をそらさせるため
「馬鹿には理解できない」と言い続けるしかない。後輩は後輩で、自分には
メリットが理解できないもののそうとは言い出せず、空気を読んで目をそらす。
プログラマはメリットもないシステムに増築を重ねて開発終盤に臨む。
火消しプログラマも馬鹿と思われてはいけないと同じようにそのシステムを
使い続けるが、その中のまだ空気を読めていなかった新入りが、こう叫ぶ。
「このシステム邪魔だよ!」

**名前は開発中のものです。** · 2009/12/13(日) 18:14:08

バカ
せっかく落ちて静かだったのに建てるなよ
また老害どもがわいてくるだろ

**名前は開発中のものです。** · 2009/12/13(日) 23:35:21

結局TCBって何ですか？

**名前は開発中のものです。** · 2009/12/14(月) 12:03:07

タスクコントロールドバカ

**名前は開発中のものです。** · 2009/12/16(水) 11:04:06

Typical Confused Baka

**名前は開発中のものです。** · 2009/12/27(日) 11:07:32

タスクシステムなんて"僕の思ってるようには"使えないよ！
って坊やがまだわいてこないな

前スレで懲りたか？

**名前は開発中のものです。** · 2009/12/27(日) 11:11:55

>>8
タスクシステムのメリットを理解できてる？
自分の言葉で言い表せる？

**名前は開発中のものです。** · 2009/12/27(日) 11:41:36

>>9
詳しく説明されてる例がいくらでもあるのに
「自分の言葉」じゃなきゃダメな理由は何？

>>2 のリンク先読んで理解できないってのなら
「リンク先のここがわからないんで教えてください」
って素直に聞けばいいのに。

**名前は開発中のものです。** · 2009/12/27(日) 11:47:05

>>10
言い訳乙ｗ

**名前は開発中のものです。** · 2009/12/27(日) 12:12:27

「わからないところがわからない」って勉強のできない小学生みたいだな。
で、「僕のわからないところを見抜いて僕にわかるように説明しろ」と

すまんがエスパーじゃないので無理だｗｗｗ

坊やがゲーム専門学校の生徒でこっちが講師なら仕事だからやるけど
掲示板でゆとり相手にタダでそんな労力期待されてもねぇ

**名前は開発中のものです。** · 2009/12/27(日) 14:41:21

> 「わからないところがわからない」って勉強のできない小学生みたいだな。
> で、「僕のわからないところを見抜いて僕にわかるように説明しろ」と

妄想に対してレスとかｗ

タスクシステムのメリットを理解できてる？
自分の言葉で言い表せる？

こんなカンタンなことから逃げるなよｗ

**名前は開発中のものです。** · 2009/12/27(日) 16:03:36

すまんがタスクシステム程度の何が理解できないのかわからん。
>>2 見りゃ想像つくだろ、ってのはレベル高すぎなのか？

出来ない子の気持ちがわからなくてすまんなぁ

って、まぁ想像はつくんだけどね。
足し算できない子供が「足し算勉強するメリットおしえろよ！」
って言う理屈はｗｗ

**名前は開発中のものです。** · 2009/12/27(日) 16:24:32

また逃げてるプｗ
タスクシステム程度のメリット説明が、
そんなに難しいこととは思わなかったよｗ
>>2読め？　結局お題目を朗読するしかないのか？ｗ

**名前は開発中のものです。** · 2009/12/27(日) 16:30:20

>>15
リンク先にメリット、デメリットが明記されてるけど
どのメリットがわからないんだい？

坊やがどのメリットが理解できないのか教えてくれないと
エスパー以外には答えられないよｗｗｗ

**名前は開発中のものです。** · 2009/12/27(日) 16:33:54

>>16
> どのメリットがわからないんだい？

ため息しかでねぇなｗ

タスクシステムのメリットを理解できてる？
自分の言葉で言い表せる？

お前にこれが問われているだけのことｗ

**名前は開発中のものです。** · 2009/12/27(日) 16:39:51

こっちは坊やの先生じゃないからさ
オーダーメードのレクチャーしてくれなんて甘えられても困るな。

丁寧に図解つきで馬鹿でもわかるように説明されてるページがあるのに
それすら理解できない見所の無い馬鹿に、掲示板で教え導いてくれる
親切心のある人がいると思ってるのかい？ゆとり君ｗｗｗ

**名前は開発中のものです。** · 2009/12/27(日) 16:40:42

おやおやｗ　結局逃げですかｗ

**名前は開発中のものです。** · 2009/12/27(日) 16:47:57

>>19
そのとおり
こっちは坊やのお母さんじゃないからさ、見捨てさせてもらうよ。

どうせ教えるならもっと見込みのある人に教えたい。
教えた時間が無駄になるのがわかってる適正の無い人間に教えるほど、
博愛精神にあふれてないんでね

**名前は開発中のものです。** · 2009/12/27(日) 16:48:47

タスクシステム程度のメリット説明が、
そんなに難しいこととは思わなかったよｗ
ダメだなあ君はｗ

**名前は開発中のものです。** · 2009/12/27(日) 17:20:18

冬休みになったのか？

**名前は開発中のものです。** · 2009/12/28(月) 00:44:13

メリット説明しろってのは2chでありふれたレトリック
ニートスレの「就職のメリット教えろ」とか
毒男スレの「結婚のメリット教えろ」とかと同じでいくらでも見つかる。

まともに議論したら「お前が無能なだけ」「お前に魅力がないだけ」って結論になって
プライド保てない負け犬が「何がメリットかわかりましぇーんｗｗ」
って逃げ回って相手に労力をかけさせて諦めるのを待つ見え見えの方法。

そんな展開のわかりきった手垢のついたレトリックに今時ひっかかる馬鹿はいないわな。

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

思う壷すぎてﾜﾛﾀ
老害とわ（ば）ものの罵り合いﾜﾛｽ

もっとやれ

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

>>3
> 「馬鹿には理解できない」と言い続けるしかない。

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

>>23
メリット説明しろってのは頭の弱いアンチ君たち唯一の武器だろうに。
かわいそうなアンチ君から唯一の武器を奪うなんてなんて大人気ない。

あとは単発IDで罵倒するぐらいしかアンチ君には手段が残されてないじゃなの。
弱いものイジメして楽しいか？もっと博愛しろｗ

**名前は開発中のものです。** · 2009/12/30(水) 04:08:55

メリット；動的に処理順を制御することができる。
ディメリット：大部分の処理は動的に処理順を制御する必要が無いので無駄。

普通の人は、動的に処理順を制御する必要のある部分は個別にモジュール化する。
たとえば、Zソートは描画エンジンがやるだろうし、
当たり判定の優先順位なんかも、それ用のライブラリが面倒見る。
統合してタスクシステムとかやらない。

タスクシステムって、タスクを順番に実行していくものだろ。
でもそれって、命令を順に実行していくノイマン型コンピュータそのものだろ。
仕組みが重複してるw

**名前は開発中のものです。** · 2009/12/30(水) 09:00:30

そもそもメリットを聞くのはスタート地点じゃないんだよなー。
メリットってのは、代替手段やそれを使わなかった場合と比較することで、はじめて認識されることだし。

つまり、メリットは？と聞く前に、以下のいずれかを行っておく必要があるだろう。
・自分で実装した方法がある。実装構造の目的(実現したかったこと)と欠点も認識しておく。
・何もわからず右往左往してタスクシステムって何さ、と聞いているならばタスクシステムの目的(達成したいこと)をまず理解する。または聞く。

**名前は開発中のものです。** · 2009/12/30(水) 10:47:28

で、目的は？

**名前は開発中のものです。** · 2009/12/30(水) 10:59:46

>>2 のリンク先のメリット・デメリットについて

Ａ：理解できない。
＞どのメリットが理解できないのか明記すべき。

Ｂ：リンク先のメリット説明は間違っている。
＞間違っている箇所を説明すべき。

Ｃ：全て理解した。その上で他にもメリット無いか聞いている。
＞その旨明記すべき。

が建設的な対応だな。

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

>>27
ちゃんとリンク先読んだのか？
メリットはその一点だけじゃないぞ。
それに「普通の人は」って一つの脳内仮定で思考停止しちゃう人は
手段の優先は目的によって異なるってことを理解した方がいいぞ。

>>29
目的が理解できないレベルね。
リンク先の一例では「シューティングゲームを作る」かね。
君の目的は知らんけど。

**名前は開発中のものです。** · 2009/12/30(水) 11:34:53

また裸の王様か。
タスクシステムなしにシューティングをつくれるのになぜ導入するのかも言及しない。

**名前は開発中のものです。** · 2009/12/30(水) 11:36:11

レトリックに誰も突っ込まない優しさワロスｗ

**名前は開発中のものです。** · 2009/12/30(水) 11:38:32

>>32
>タスクシステムなしにシューティングをつくれるのになぜ導入するのかも言及しない。
メリット・デメリットがわざわざ明記してある意味すら理解できないレベルか・・・

**名前は開発中のものです。** · 2009/12/30(水) 11:39:32

修辞技法（しゅうじぎほう、または文彩（ぶんさい）、あや、英語・フランス語：Figure）とは、
スピーチおよび文章に豊かな表現を与えるための技法。
# 2 比喩
# 3 擬態法
# 4 擬人法
# 5 倒置法
# 6 反復法
# 7 同語反復
# 8 首尾同語（反照法）
# 9 体言止め
# 10 反語
# 11 呼びかけ
# 12 パラレリズム
# 13 押韻
# 14 語句の挿入
# 15 省略法
# 16 緩叙法
# 17 漸層法
# 18 対照法
# 19 敷衍（ふえん）
# 20 パロディ
# 21 畳語法・畳句法・畳音法
# 22 疑惑法
# 23 誇張法
# 24 列挙法・列叙法
# 25 折句
# 26 史的現在
# 27 撞着語法
# 28 頓降法/漸降法
# 29 黙説
# 30 冗語法
# 31 転用語法

**名前は開発中のものです。** · 2009/12/30(水) 11:39:58

で、何なの？

**名前は開発中のものです。** · 2009/12/30(水) 11:45:37

レトリック
(1)修辞学。美辞学。
(2)文章表現の技法・技巧。修辞。
「―にすぐれた文章」
(3)実質を伴わない表現上だけの言葉。表現の巧みな言葉。
「巧みな―にごまかされる」

(3)の詭弁の意味で問題なさげ。

自爆に突っ込まない優しさが無くてなｗｗ

**名前は開発中のものです。** · 2009/12/30(水) 11:56:09

>>37
ありがとう。マジでその意味は知らなかった。
レトリック　詭弁でぐぐるとザクザク出てくるし、
「それはレトリック＝詭弁と呼ばれ、禁じ手とされてきた。」などと一発目に目に付く。

**名前は開発中のものです。** · 2009/12/30(水) 12:01:47

タスクシステムとやらで不要なシステムを強要してバグを大量生産するプロジェクトが
よく見られますがどう思いますか

**名前は開発中のものです。** · 2009/12/30(水) 12:06:48

>>39
ホントはね、「触らぬ神に祟り無し」これだけで十分。
相手をして遊ぶのは仕事から離れた、２ちゃんとかだけにしときたいよね。
私怨をもたれたらめんどいから。

**名前は開発中のものです。** · 2009/12/30(水) 12:21:26

>>39
プロジェクトのメインプログラマーが、タスクシステムのデメリットを超える
メリットがある、と判断したて採用したんだろうなぁ、と。

不要に見えるならもっと良い方法を提示してあげたらいいんじゃない？できるんなら。

一本メインで任せられるほど会社から実績と信頼もらってる優秀なプログラマなんだから
もっと良い方法提示されたら喜んで受け入れてくれるよ・・・

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

おれがメインやるときは使わないが
火の車のプロジェクトにヘルプで入るとってパターンばかり
おれは使うなとはいうけど責任ないプロジェクトにまで影響力ないな

**名前は開発中のものです。** · 2009/12/30(水) 13:24:09

個人的な経験の範囲ではプロジェクトに火がつくかどうかとタスクシステムの有無に因果関係はほとんど無かったけどな。
火がつく理由は非常識な納期とか仕様の甘さとか進捗管理のまずさとか、もっと外側の原因がほとんど。

まぁタスクシステムは良くも悪くも「Ｃの精神」と「ゲームプログラマ固有のケチさ」が色濃くでてる
システムではあるんだけど。

新人がタスクシステム使って「何でこんな簡単な処理を、ここまで複雑で危険な処理にできるんだろう」
というのも見たことあるし。

スーファミ時代から現役の４０歳超え超ロートルプログラマがＤＳ用にタスクシステムで作ったゲーム
コードでは、美しい数学の証明でも見てるみたいに理解しやすくシンプルで、高速高効率なコードに
仕上がってるのみ見たこともある。

結局、誰がどんなプラットフォームでどんな仕様のゲームを作るのか、という目的にてらしてメリットデメリット
比較して使えるところではうまく使えばいいんじゃね？という当たり前の結論。

**名前は開発中のものです。** · 2009/12/30(水) 19:13:10

ヒットに責任もつやつが主導権持つのは当たり前。
そういう点ではここのプログラマーが下に見られるのは当たり前。
決してプログラマーはヒットに貢献出来ないといってるわけではない。

**名前は開発中のものです。** · 2009/12/30(水) 21:37:14

というか、普通にかけばいいじゃん。

tasks.push_back( task1 );
tasks.push_back( task2 );
tasks.push_back( task3 );
for(;;){ for( size_t i=0; i<tasks.size(); ++i){ tasks[i](); } }

よりも、

for(;;){
task1();
task2();
task3();
}

の方が自然だろ。
プログラム自体が処理のリストなのに、何故わざわざ処理のリストを自前で用意するんだ？
バーチャルマシンでも作る気か？

**名前は開発中のものです。** · 2009/12/30(水) 21:44:27

タスクシステムを(アカデミックな方向に)発展させていくと、

gotoタスク：　引数で指定した番号のタスクにジャンプする。
ifタスク：　タスクの評価が非0の時、引数で指定した番号のタスクにジャンプする。

とかになるぞ。変だろ。

**名前は開発中のものです。** · 2009/12/30(水) 21:55:31

C言語には、プログラムを上から順番に実行していくというタスクシステム的な仕組み以外にも、
if文があったり関数に引数が指定できたり、型があったりと、
目いっぱい便利な仕組みが用意されているのに、
なんでわざわざバーチャルマシンもどきのタスクシステムを自分で実装しようとするんだ？
そんなことするから、C言語に元から用意されていた、
構造化制御とか型とか関数の引数などの便利な機能が使えなくなるんだろ。

**名前は開発中のものです。** · 2009/12/30(水) 22:22:56

技術的に低すぎる馬鹿みたいな例をあえて出して
釣ろうって手段かね。
釣りだとしてもいまいち・・・

**名前は開発中のものです。** · 2009/12/30(水) 23:03:38

タスクシステム自体がバカみたいな例そのものだとおもうが。
既存のものを使わずに自作して周囲からの恩恵を受けられなくなるという。
そういう趣味性を否定するわけではないが。

**名前は開発中のものです。** · 2009/12/30(水) 23:17:16

タスクシステムって、基本は動的関数呼び出しがキモで、それって、
OSに対するアプリとか、
ブラウザに対するプラグインとか、
ウィンドウマネージャに対するウィンドウとか、
そういった、後から拡張を要する場合に利用される手法なんだよ。
単一アプリのゲームの開発に持ち出すのはナンセンス。
増築の手法で一戸建てを立てるようなものだね。
ディアゴスティーニじゃないんだから。

**名前は開発中のものです。** · 2009/12/30(水) 23:46:59

>>47
ネタにマジレスだが
関数ポインタもＣ言語に元から用意された便利な機能だろ？
タスクシステムの実装っていかにもＣ言語的（というかthe spirit of C）なんだが。良くも悪くも。
古典的タスクシステムなんて古きよきUNIX時代のC言語のコードを見てる気分になる。
これこそCのプログラムって感じ。
「プログラマを信頼する」というＣの精神と同じ思想で
信頼されたプログラマ、つまりタスク仕様上の「落とし穴」を正しく理解したプログラマであれば
その穴に陥らずにプログラムを書けるはずである、といういかにもな精神。

ネタじゃないなら、HSPとか使う方が君には合ってる気がする。

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

>>51
関数ポインタ⊂タスクシステム

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

>>47に>>51と返す奴の理解力が心配だなｗ

**名前は開発中のものです。** · 2009/12/31(木) 13:56:13

ネタにマジレスしてくれる優しい人なんでしょｗｗ
引数君のレベルが低すぎて話が噛み合ってないが

**名前は開発中のものです。** · 2009/12/31(木) 14:48:06

>>45
> というか、普通にかけばいいじゃん。
それはお前にとっての普通だろｗ

一般のＣプログラマにとっては関数ポインタ使った方法もＣ言語の
言語仕様で想定された"普通"の方法の一つなんだけど。

お前にとっては「そんなの使ったら僕理解できない！型とか関数の引数などの
便利な機能が"僕には"使えなくなる（涙）」ってだけｗ

その程度で「ＯＳでも作るのか？バーチャルマシンでも作るのか？」って涙目ｗ

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

>>55
頭の弱いものいじめ、カコワルイｗｗ

**名前は開発中のものです。** · 2009/12/31(木) 18:52:03

抽象化はメリットがなければじゃまなだけ。
メリットが明確じゃないから使わないんだろ。
メリット感じてるやつだけが使えばいいんだよ。

**名前は開発中のものです。** · 2009/12/31(木) 19:06:43

「タスクシステムでゲームを作る」って言うよりは、
「有限状態機械を組み合わせてゲームを作りたいけど、
　使用する言語にコルーチンのような機構が無いから、
　同じような物を自前で実装するためにタスクシステムを使用する」
っていうのがタスクシステムを使う本来の動機だと思う

**名前は開発中のものです。** · 2009/12/31(木) 19:28:41

正直最初に実装した人は少なくともそんな小難しく考えてないだろう。
・俺がメモリを管理する！がしたい
・状態(データ)と処理(動作)を一まとめに出来たら直感的
・それらの一まとめを個別に自由に追加・削除したい。

以上の要求にC言語で応えようとすると、リスト構造を純粋に作るか、
>>2で示すような(リスト+配列)/2のような構造がぱっと思いつくのでは?

**名前は開発中のものです。** · 2009/12/31(木) 19:38:27

>>57
つ >>43
それもう結論出てるから。

今はメリット・デメリットの比較までたどりつけない子がイジメられてるだけｗｗ

**名前は開発中のものです。** · 2009/12/31(木) 19:48:27

でも誰も語れない不思議

**名前は開発中のものです。** · 2009/12/31(木) 19:53:57

FSMとコルーチンってなんか特別な関係があるの？
コルーチンって状態遷移に対してメリット思いつかないんだが

**名前は開発中のものです。** · 2009/12/31(木) 20:43:02

>>61
でも誰も"僕の理解できることを"語れない不思議

>>62
コルーチンをサポートする言語のVMをFSMとして見るなら、コルーチンの単位を一つの状態として見れるかもね。
そもそも用語の次元が違う話だけど。

**名前は開発中のものです。** · 2009/12/31(木) 21:44:09

それでも語らない不思議

**名前は開発中のものです。** · 2010/01/01(金) 00:33:49

>>59
その動機ならalloc系をラッピングしたほうが自然では？

**名前は開発中のものです。** · 2010/01/01(金) 03:30:24

>>55
>一般のＣプログラマにとっては関数ポインタ使った方法もＣ言語の
>言語仕様で想定された"普通"の方法の一つなんだけど。

関数ポインタ？使えば良いんじゃね？
タスクシステムが糞といってるだけで、関数ポインタが悪いとは言ってないんだが。

タスクシステムのまずい点は、言語レベルで初めから持っているはずの、
「プログラムは上から順番に実行される」を自前で実装しちゃってる点。
考えてもみろよ。結婚式のプログラムだろうが運動会のプログラムだろうが、
プログラムと名のつくものは大概順番に実行されていくものだろ。
コンピュータだって機械語レベルでそうなってるし、C言語以下の低級言語ですら、それぐらいの機能は持ってる。
それを何で今更自前で用意する必要がある？
そんなの独自にやろうとするから、C言語既存の、
「引数受け渡し」や「型」や「構造化制御」との親和性が低くなる。

なんでも言語標準の機能を使えとは言わないが、
あまりにも基本的な部分を覆すのはどうかと。

**名前は開発中のものです。** · 2010/01/01(金) 03:49:11

もちろん、実行順序を動的に制御したい場合もあるだろうけど、
そういう汚い部分は、個々のモジュール内に閉じ込めて、表に撒き散らさないようにした方が賢いと思うが。
Zソートを例に挙げると、それは描画エンジン内でこっそり行えばよい話で、
タスクシステムみたいに変に統合しちゃって、猫も杓子もそれつかえってのは無茶。

**名前は開発中のものです。** · 2010/01/01(金) 04:12:13

>>62
>FSMとコルーチンってなんか特別な関係があるの？
>コルーチンって状態遷移に対してメリット思いつかないんだが

これも良く引っかかる罠なんだが、
コルーチンはスタックフレームの状態が保存できるから
スタックフレーム上のプログラムカウンタを状態とみなすことで状態変数をなくすことが出来る。
しかしそれは状態が独立している場合のみに有効で、
状態と状態が連携をとる場合は、状態変数は消せない。

例）
if( stateA && stateB ){}
else if( !stateA && stateB ){}
else if( stateA && !stateB ){}
else{}

FSMの中身が上記のようになる場合は、コルーチンを使っても状態変数は消せない。
つまり、あんま意味無い。

状態変数の数だけコルーチンは必要なんだけど、状態と状態が連携をとる場合、
各コルーチン同士で状態のやり取りをする必要が出てきて、結局状態変数を復活せざるを得ないってこと。

**名前は開発中のものです。** · 2010/01/01(金) 04:27:38

では、状態が独立している場合にはコルーチンが有効かというと、実はそうでもない。
なんでかっていうと、状態が独立しているのなら、初めからプログラムはそんなに複雑にはならないから、
ベタで書いても大したこと無いから。

同期の粒度が大きければコルーチンは便利かもしれないけど、
一フレーム毎に同期を取るゲームでは無用かな。

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

古典タスクシステムの

メリット：

多数のFSMを逐次実行するための一手段になる

簡単な古典TS（>>2の「最も基本的なTCBの構造」だけで済むTS）ならコードはシンプル

MVCのMとCが分離されているため、タスクシステム（C）を実装すれば、
後は動的に実行される関数（M）の実装に専念できる

デメリット：

逐次実行するFSMの数が少ないならわざわざ使う必要が無い

各TCBのワーク領域割当に苦労する
ワーク領域を動的確保にする場合はガベージコレクトの問題が出る

簡単な古典TSには、TCB間の情報・イベント伝達や、親子関係を持たせる機能などが無い
これらを実装しようとすると、気持ち悪いコードになる可能性が高い
（TCBの逐次実行がウリなのに実行順序を無視したり、グローバル変数にアクセスしたり）
設計・実装にプログラマの良し悪しが出る

TCBから呼ぶ関数内でMVCのMとVを分離せず書くと、今時のプログラミングでは混乱しやすい
（特に、直接API（DirectX等）や、APIが比較的剥き出しになっているラッパーライブラリを使う場合）