タスクシステム総合スレ 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: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が比較的剥き出しになっているラッパーライブラリを使う場合）

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

>>70
> 簡単な古典TSには、TCB間の情報・イベント伝達や、親子関係を持たせる機能などが無い
> これらを実装しようとすると、気持ち悪いコードになる可能性が高い
今時のタスクシステムにしろUnreal EngineとかのActorにしろ、今時のゲームエンジン系で
イベント伝達や親子関係とかをサポートしてないものを探すほうが難しいな。
つまり実際に製品規模のゲームを作るうえでは必須な機能だ。

ゲームロジック部分は嫌でも土臭くなる部分が出てくるし、これはタスクとかActor
を使わなければ綺麗に書ける、というものでもない。

「いや、俺はそんなもの使わずに製品規模のゲーム作る方法知ってるよ」って天才がいるのなら
CEDECなりGDCなりで発表すればきっと世界中のゲームプログラマから賞賛受けるよ。

**名前は開発中のものです。** · 2010/01/01(金) 09:39:45

>>70
逐次実行がタスクシステムの売りっていわれても、そもそもプログラムは基本全部逐次実行だ。
ますますfor(;;){ task1(); task2(); task3(); }で問題ないな。

>>71
それらはゲームエンジンという制約からくるものだ。

ゲームのメインロジックは泥臭くなるというが、それはゲームエンジンを使おうとするから。
ゲームなんて、入力→状態更新→描画　を永遠と繰り返すだけなわけで、
普通に書けばそんなに泥臭くならない。
WindowsアプリがWindowsの仕様にあわせるために窓周りが泥臭くなるのと同じ理由で、
ゲームエンジンでゲーム作ると泥臭くなる。
増築の手法で一戸建て立てようとしているのだから当たり前。

**名前は開発中のものです。** · 2010/01/01(金) 09:50:21

>>72
>ゲームのメインロジックは泥臭くなるというが、それはゲームエンジンを使おうとするから。
>ゲームなんて、入力→状態更新→描画　を永遠と繰り返すだけなわけで、
>普通に書けばそんなに泥臭くならない。
UEエンジンやFarCryエンジン、タスクシステム使ってる時代遅れの開発者達に
「ゲームエンジンなんて使わずに普通に書け」と教えてあげなきゃ！
世界中のゲーム開発者が気づかなかったことを気づくなんて天才だね。
・・・紙一重にはかなわんｗｗ

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

今時ゲームなんて作ってる奴はもとより時代遅れなのかもしれないよ？

あーあと、親子関係とかは(何の親子関係かは知らんが)実装しても良いと思うよ。必要ならね。
それをタスクやactorに結びつけるのは糞の極みだが。

**名前は開発中のものです。** · 2010/01/01(金) 10:21:15

>>74
>今時ゲームなんて作ってる奴はもとより時代遅れなのかもしれないよ？
ゲーム製作技術なんて時代遅れの板では天才様のレベルには合わないようですよ？ｗｗｗ

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

ID:7lwJSlZL、そんなに怖がるなよｗ
ID:4JKBI3JGは少なからず理屈で出てるんだから、
お前が逃げると、見てるほうとしては物足りないぞ。
もっと頭を使わないと立派な大人になれないぞ。

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

>>2の構造ならポインタインクリ、デクリできるからじゃね？
あとなんかヒープ領域をリアルタイムでこまめに確保するのってなんかCっぽくないと思えるように最近なってきた。不思議。

77 · 2010/01/01(金) 11:01:41

安価忘れ。>>65へ

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

>>76
みえみえ・・・

**名前は開発中のものです。** · 2010/01/01(金) 15:18:56

イベントドリブンとgotoの違いがわかりません

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

>>76
>>71-75の流れ見ればID:4JKBI3JGの完敗にしか見えんが
ゲームエンジン否定して毎作エンジン自作しろってか？正気とは思えん。
ID:4JKBI3JGが勝ってるように見える人間の理屈を教えて欲しい。まじで。

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

なぜタスクシステムをゲームエンジンと読み替えるの？

**名前は開発中のものです。** · 2010/01/01(金) 16:36:10

>>82
>>72で本人が言ってるけど。

**名前は開発中のものです。** · 2010/01/02(土) 01:19:18

ゲームエンジン(タスクシステム含む)なんて糞ですよ。
ゲーム用ライブラリ、これで十分。
でも俺もゲーム用ライブラリ作って商売しろって言われたら、
マーケティングの都合上、そりゃゲームエンジン(フレームワークみたいな奴)
にするけどな。使い勝手とかじゃなく、身の保身のためにな。

ゲームのメインループは各モジュールに制御を分配する、いわば心臓みたいなもんで、
そんなもんを安々他人や他社に明け渡す気にはなれん。
裏を返せば、他人の心臓は握りたいってことだが。
そりゃあ、誰だって甘い汁すいてぇよなぁ。

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

あーだから、UEエンジンとかも、ライブラリ的に気軽に利用できる部分はどんどん使えばよいと思うよ。
ただ、actorとかマジで要らないよね。
なんていうか、トラップにすら思える。

**名前は開発中のものです。** · 2010/01/02(土) 01:41:11

>ゲームエンジン否定して毎作エンジン自作しろってか？正気とは思えん。

だから、なんでゲームエンジンが必要なんだ？
ゲームエンジンが無きゃゲームが作れないのか？
ゲームの種類は千差万別でやらせたいこともまちまちなのに、
汎用なゲームエンジン作ったってしょうがないだろ。てか出来ないだろ。
なんですぐそう統合したがるのかが分からん。
個々の機能ごとに、たとえば、
描画エンジンとか当たり判定エンジンとか、そう言う単位で用意すりゃいいだろ。

**名前は開発中のものです。** · 2010/01/04(月) 19:31:30

タスクシステムの利点は、ゲームプログラミングの学習の段階で
ゲーム中のオブジェクトを抽象化する練習が出来ることだと思う
ゲーム中のイベントやキャラクター、エフェクトを
どのようにオブジェクトに分割して実装するか、とか考える練習になると思う

まあ、同等の事が出来るなら、特に今ではタスクシステムである必要はないけど

**名前は開発中のものです。** · 2010/01/04(月) 19:44:33

今のゲームプログラマって抽象化ができないんだよね

**名前は開発中のものです。** · 2010/01/05(火) 03:55:23

しかし、抽象化に限界を感じるのも事実かも。特に汎化。
車輪の再発明はするなとか、再利用性とか・・・。

**名前は開発中のものです。** · 2010/01/05(火) 10:58:16

10年以上タスクを使ってたおれが、いま非タスクでゲームを実装してるよー！
正直どっちでもいいよとおもった。

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

たしかにどちらでも動作するので
プレイする側からしたらどうでもいい話
しかし、抽象化のできないマと話をするのは嫌

**名前は開発中のものです。** · 2010/01/05(火) 14:17:47

タスクシステムはともかくゲームエンジンまで不要と言い出したのか。
昔のタスクスレでＯＯＰ不要とかクラス不要と言ってた人と同一人物っぽいな。

**名前は開発中のものです。** · 2010/01/05(火) 15:46:08

タスクシステムもオブジェクト指向も、抽象化して複雑さを管理するための
メタファーでしかないんだけどな。

自分ひとりで作れるぐらい単純なレベルなら抽象化もしない方が見通しいいかもしれない。
プログラマ２～３人ぐらいの小さなプロジェクトでも無くても作ることはできるだろう。

次世代機の開発者数百人ってレベルで「普通に作れ」って何も基底システム用意しないのはさすがにありえんけど。

**名前は開発中のものです。** · 2010/01/06(水) 03:10:22

タスクシステムが制御構造のいったい何を抽象化するというのだろう。
俺からしたら、いわゆるif文とかで普通に制御する構造化制御のよりも、
抽象度が落ちているようにしか思えないのだが。
ノイマン型コンピュータの逐次実行性を抽象化するもの→VM　ってこと？

**名前は開発中のものです。** · 2010/01/06(水) 11:26:48

ifで制御とか、超具象的じゃね？

**名前は開発中のものです。** · 2010/01/06(水) 14:23:59

TCBは構造体やクラスだからデータの抽象化。TCBのリストはデータの抽象化
TCBリストのイテレーションはループ処理の抽象化
各TCBから呼び出される関数はサブルーチンの抽象化
つまり、タスクシステムはデータのリストから各サブルーチンを実行するループ処理の抽象化

これだけだと、VMの命令リストと同じように見えるけど、
最大の違いは、VMの命令リストは配列なのに対して、
タスクシステムのTCBリストは連結リストである点

TCBは連結リストで管理されているから、連結リストのメリットとデメリットを受ける
オブジェクトが頻繁に追加・削除されるゲームでは連結リストのメリットが生かされる

逆に言えば、連結リストの恩恵を受けられないようなゲームでは、
>>45の言うようにタスクシステムを使う必要がない

**名前は開発中のものです。** · 2010/01/06(水) 16:42:37

思ったとおりに動く
この快感を知らない理論派プログラマは去っていい

**名前は開発中のものです。** · 2010/01/06(水) 21:39:48

>>97
プログラマの思ったとおりに動かないプログラムって何だ？
ＡＩが知性持って反乱でも起こすのか？

**名前は開発中のものです。** · 2010/01/07(木) 01:20:32

>>96
俺が言いたいのはそう言うことじゃなくてさ。
タスクシステムも抽象化は抽象化なんだけど、
勝手手前な抽象化だから、C言語そのもののもつ抽象化と相性が悪く、
逆に退化してんじゃねーかって。

たとえば、タスクのプロシージャに引数が自由に指定できなかったり、
ダウンキャストが発生したり、
タスクの実行順をタスクの追加順やプライオリティーで指定しなければならなかったり。

タスクシステムも抽象化には変わりないんだけど、
C言語に元からある抽象化機能をスポイルしてしまうから、
トータルでは退化している部分の方が多いような。

タスクのプロシージャに自由に引数を指定でき、
書いた順に実行され、ダウンキャストの発生しない
タスクシステム誰か作れや。

**名前は開発中のものです。** · 2010/01/07(木) 01:27:41

タスクシステムって数々の苦行を強いるくせに、
皆が認めるメリットって、「実行順序を動的に制御できる」だけだろ。
なんか割に合わない。

**名前は開発中のものです。** · 2010/01/07(木) 01:38:41

>>99
>C言語に元からある抽象化機能をスポイルしてしまうから、
C言語に元からある抽象化ってまさかifとかswitchのことを言ってるの？

>>100
皆って誰よ。
リンク先には５～６個メリットが上がってるじゃん。

**名前は開発中のものです。** · 2010/01/07(木) 02:10:42

>>101
>C言語に元からある抽象化ってまさかifとかswitchのことを言ってるの？

型とか関数の引数とか構造化制御とか。
ちゃんと>>99で書いてるじゃん。勘弁してよ。

>リンク先には５～６個メリットが上がってるじゃん。

これのことですか？
「ゲームを開発するのに適したシステムで開発できる」
勘弁してくださいよ。

**名前は開発中のものです。** · 2010/01/07(木) 02:48:24

君、ノイマンがどうのとか前スレから言ってた奴だろ