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

[表示 : 全て最新50 1-99 101- 201- 301- 2chのread.cgiへ]
Update time : 11/22 06:13 / Filesize : 128 KB / Number-of Response : 321
[このスレッドの書き込みを削除する]
[＋板最近立ったスレ＆熱いスレ一覧 : ＋板最近立ったスレ／記者別一覧] [類似スレッド一覧]


↑キャッシュ検索、類似スレ動作を修正しました、ご迷惑をお掛けしました

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

1 名前：名前は開発中のものです。 mailto:sage [2007/12/04(火) 04:51:53 ID:bGSXJYb0]: タスクシステムについての議論、相談、質問、雑談などのスレです

前スレ　pc11.2ch.net/test/read.cgi/gamedev/1173708588/
113 名前：名前は開発中のものです。 [2008/05/25(日) 01:06:31 ID:6V9YbMCv]: スレッド使えばこんな感じに書けるはずだが

主人公() {
while (true) {
if (A) ... ;
else if (B) ... ;
else if (C) ... ;
}
yield();
}

タスクシステムとやらを使ったときのありえない複雑さは凡人の俺には理解できない
簡単にできるものをわざわざ複雑に書く、天才だけの思考は全く理解できんな
114 名前：名前は開発中のものです。 mailto:sage [2008/05/25(日) 05:25:51 ID:dDrBARgy]: >>111が何を言いたいのかはよくわからんが、
タスクシステムも>>113も、複雑さは特に変わらないように思えるけど。

class 主人公 : public Task {
　void 実行() {
　　if (A) ... ;
　　else if (B) ... ;
　　else if (C) ... ;
　}
};

どの辺が、>>113に比べて「ありえない複雑さ」なんだ？
115 名前：名前は開発中のものです。 [2008/05/25(日) 05:35:43 ID:5unbeWfm]: サブクラスにいちいちIF仕込んでんのかよｗ
116 名前：名前は開発中のものです。 mailto:sage [2008/05/25(日) 08:15:02 ID:vQVRM4Hf]: >>110ですが、俺は>>112-113とは別人です一応
まあ使ってんだけどねタスク。仕事だし

>>111の言うような連携処理は、処理自体の複雑さの問題だと思うんだわ
俺が言ってんのはもっと低レベルな話でー

//10フレームかけて10ドット右へ
for (int i=0; i<10; ++i) {
move_right(1);
}

とやればいいとこが、

//10フレームかけて10ドット右へ
void task_handler() {
static int i = 0;
if (i >= 10) {
go_next_mode(); // 処理が終わったよ！
return;
}
move_right(1);
}

みたいになるのが長いと言うか分かりづらいと言うか、処理がこみいってくると混乱するなあと。
俺、なんか勘違いしてますかねー？
117 名前：名前は開発中のものです。 mailto:sage [2008/05/25(日) 08:40:06 ID:vQVRM4Hf]: ごめん、ちょっと直した。あとインデント入れた

//10フレームかけて10ドット右へ
for (int i=0; i<10; ++i) {
　　yield();
　　move_right(1);
}

//10フレームかけて10ドット右へ
void task_handler() {
　　static int i = 0;
　　if (i++ >= 10) {
　　　　go_next_mode(); // 処理が終わったよ！
　　　　return;
　　}
　　move_right(1);
}
118 名前：名前は開発中のものです。 mailto:sage [2008/05/25(日) 09:38:01 ID:xbxgumKd]: >>117
前者の方が不自然に感じる俺はどうすれば・・・
119 名前：名前は開発中のものです。 mailto:sage [2008/05/25(日) 10:39:48 ID:qUO2NAd9]: >>113
スレッドの生成/破棄がどれだけ高コストか分かっているのかね？

>>117
途中のフレームでやっぱり左に切り返す処理等を入れたら後者の方が
遥かにシンプルになる。
120 名前：名前は開発中のものです。 mailto:sage [2008/05/25(日) 10:52:41 ID:7UG2hamH]: >>112
いや、だから変わらんでしょ？って言いたかったわけよ
121 名前：名前は開発中のものです。 mailto:sage [2008/05/25(日) 10:57:13 ID:7UG2hamH]: あーだから、スレッドなんて作っても
根本の複雑さが問題なんであってタスクシステムなんて
してもここは変わらんよと
122 名前：名前は開発中のものです。 mailto:sage [2008/05/25(日) 11:08:35 ID:K3dp7DqQ]: 時間かけて行う処理、広くいうと、ある条件を満たすまで待って次に進むような逐次処理
を書こうとすると>>117の言うようなストレートに記述をしたくなるのは分かる

こういうのをコルーチン(co-routine)っていうんだっけ。

ただ>>119の後半にあるように条件判断をイテレーションごとに行う必要があるなら、
コルーチンであってもコルーチンっぽくは見えなくなってしまうかもしれない

（スレタイにあわせていうなら）
たとえば制御系タスクとワーカ系タスクっていうのがあって、
それぞれ記述しやすい方法が違ったりする？

制御系タスク　　　イテレーション（表示フレーム？）ごとに細かい条件判定を行い、大きな分岐がある
ワーカ系タスク　　↑に比べて単純なループ、条件判定は脱出するかどうか、程度

おれなら、
前者はメッセージディスパッチャっぽく書きたい。
後者はコルーチンっぽく書きたい。
なあ。
123 名前：名前は開発中のものです。 mailto:sage [2008/05/25(日) 11:56:53 ID:MyJQpRZH]: 結局何やっても複雑になるんだからどんな実装してもおｋ
Flashなんかも標準でタスクシステム（笑）のような仕組み持ってるんだけど、
やっぱ処理順序とかインタラクトとかみんな悩んでるお
124 名前：名前は開発中のものです。 mailto:sage [2008/05/25(日) 14:13:14 ID:7UG2hamH]: 作るもん間違ってんじゃねぇの？
>>117みたいな処理ってスクリプトやプログラムで解決しないで
フラッシュみたいなタイムライン（？）があるビジュアル的なもんがあったほうがいいんじゃねぇの？

んでキャラの状態遷移みたいなもんは遷移図と各ステータスの遷移条件表がないとどうしたってダメだろ？
こんな属性の違うもんをいっぺんに解決しようとする手段を探してること自体
問題の切り分けができていないんと違うか？

タスクシステムはあくまで全然別な独立処理をわかりやすく書くためだけのもんだろ
こいつは上記の２つの問題にはなんの解決策にもなっていねぇ
ゲームプログラムが複雑なのはオブジェクト同士の絡みだろ？
125 名前：名前は開発中のものです。 mailto:sage [2008/05/25(日) 14:17:00 ID:vQVRM4Hf]: >>119
あ、そうなのか？　あー、そうかも。

>>122
なる。制御系とワーク系って分けると、なんか分かりやすい。
多分俺がストレスを感じるのは、ちょっとした演出、タイトル画面のデモ、プレイ前の説明画面、
そういう目立たないけど手早くたくさん作らないとならない動きをつけるために、
ゲーム時のキャラクター制御と同じくらいがっちり組まされることなんだな。
実際、ゲーム中の制御は最初からがっちり組みにいくんでストレス感じないし、
俺の場合はイベントドリブンで考えた方が組みやすいから確かに>>119の言う通りかも知れない。

しかし・・・だまされないぞ！
イベントドリブンがしたければ別にスレッドでもできるわけで（Windowsで言うPeekMessageね）、
スレッドのコストの問題は（色々と解決方法が考えられるはずなので）ここでは無視して考えてほしいんだけど、
処理によってはタスクと同じ機構をスレッド上に構築することがあったとしても、
それが可能なことは悪いことじゃないと思わない？
それはＣ＋＋がベターＣとして使えるように、スレッドがベタータスクとして使えることだとは思わない？
126 名前：名前は開発中のものです。 mailto:sage [2008/05/25(日) 15:41:32 ID:0NNJH3W1]: >>122
コルーチンとかファイバーとか言うね。
少し違うけど継続(continuation)の方が知られてるかな。
スレッドは同時に走ることを期待するからこの点は違う。

そういやゲーム方面でLuaが人気あるらしいけど
コルーチンも使ってるのかな。
127 名前：名前は開発中のものです。 mailto:sage [2008/05/25(日) 15:43:46 ID:dDrBARgy]: 我々に必要なスレッドは２つ。
メインスレッド、データ読み込みスレッド、BGM再生スレッド、この３つだ。
スクリプトでタイトル画面実装してコルーチン使う、とかならともかく、
キャラの制御なんかと同じレベルにスレッドぽこぽこ作るのは嫌だなぁ。

つか、どう実装するにしても、
ボタンによる演出スキップとか、時間経過によるデモへの移行とか、
タイトル画面程度のものでも状態遷移は考えなきゃならないと思うけど。
まあ、キャラなんかとは、複雑さは全然違うけどさ。
128 名前：名前は開発中のものです。 mailto:sage [2008/05/25(日) 15:55:46 ID:7UG2hamH]: 何度も言うけどスレッドは状態遷移の複雑さの問題を解決しないよ
129 名前：名前は開発中のものです。 mailto:sage [2008/05/25(日) 16:03:27 ID:zNY0acjC]: マトリクスでも書いて整理しろよ
130 名前：名前は開発中のものです。 mailto:sage [2008/05/25(日) 16:43:17 ID:vQVRM4Hf]: 全レスしたいけどウザがられるしとりあえず

>>128
んとですね、夢を語ってるように見えたかも知れないけどもｗ
スレッドがゲームの状態遷移の複雑さを解決すると考えているのではなく、
タイマードリブンないわゆるタスク処理というものは、
本来ローカル変数やプログラムカウンタという言語上の機能を
プログラマが自分で状態として（ワーク変数などで）管理しなくてはならないのが
負担だと思いませんかと言いたいのです
131 名前：名前は開発中のものです。 mailto:sage [2008/05/25(日) 17:01:19 ID:vQVRM4Hf]: あ、俺が想定してるスレッドは擬似スレッドです。コルーチン等
ＯＳが用意するプロセス／タスク／スレッドは想定してないです
132 名前：名前は開発中のものです。 mailto:sage [2008/05/25(日) 17:02:07 ID:7UG2hamH]: >>130
もとのレスと比べて全然いってることが違うような希ガス
133 名前：名前は開発中のものです。 [2008/05/25(日) 17:02:23 ID:6V9YbMCv]: おれも>>130と同じ事が聞きたい
話を広げて逃げないでください>天才タスカーの皆さん
134 名前：名前は開発中のものです。 mailto:sage [2008/05/25(日) 17:15:50 ID:7UG2hamH]: >>133
んあ？
考えてることがさっぱりわからん
ゲームプログラムで複雑なのは各オブジェクトの状態遷移であって
タスクシステム云々は問題じゃねぇから気に入った方法で好きにしろってのが
みんなの総意だろ（おそらく）

ここまででなんか違うこと言ってるならなんか言ってみ？
135 名前：名前は開発中のものです。 [2008/05/25(日) 17:22:31 ID:6V9YbMCv]: >>134
130に対する答えにはなってないな
質問の意味が理解できないのならできるだけわかりやすく解説するが、必要か?
136 名前：名前は開発中のものです。 mailto:sage [2008/05/25(日) 17:23:16 ID:A+/TQh+q]: >あ、俺が想定してるスレッドは擬似スレッドです。コルーチン等
最初から「マイクロスレッド」と言えば無用な混乱を避けられるぞ
137 名前：名前は開発中のものです。 mailto:sage [2008/05/25(日) 17:23:43 ID:vQVRM4Hf]: >>134
ですよねー

すんません、でかけてきます
138 名前：名前は開発中のものです。 mailto:sage [2008/05/25(日) 18:00:32 ID:xbxgumKd]: ゲームプログラムからそれを取ったら後は何が残るんだ？
139 名前：名前は開発中のものです。 mailto:sage [2008/05/25(日) 18:10:01 ID:dDrBARgy]: >>113 の if の羅列は状態ごとの処理の振り分けじゃなかったのか。
140 名前：名前は開発中のものです。 [2008/05/25(日) 18:24:49 ID:6V9YbMCv]: >>139
状態ごとの処理の振り分けが何を指すのかわからないけど
マイクロスレッドと状態遷移のトレードオフとして

例えば信号の状態が「赤、青、黄」の三つだとして

普通に状態遷移を書く場合(Stateパターンではなく)
state; // をメンバ変数か、グローバルで
if (state == 赤) ... ;
else if (state == 青) ... ;
else if (state == 黄) ... ;

それよりも、スレッドを用いて
while (true)
{
赤(); sleep(?);
黄(); sleep(?);
青(); sleep(?);
}
の方が直感的で読みやすいでしょという意味で書いたつもり。
141 名前：名前は開発中のものです。 mailto:sage [2008/05/25(日) 18:38:09 ID:A+/TQh+q]: 青→黄→赤と遷移するんだろう？
さっそくバグを仕込んでいるじゃないか
142 名前：名前は開発中のものです。 [2008/05/25(日) 18:52:00 ID:6V9YbMCv]: GOFパターンで言うと
タスクシステムとやらがStateのCommandをListに突っ込んだものなら
Stateのメリットは拡張性にあって可読性にはないから
可読性を優先するならマイクロスレッドの形を取るべきだ
と言いたいわけだ。

ところが天才タスカーはタスクシステムを使えば簡単になるよとしか言わない
可読性が低下するというデメリットにも触れない、又は理解していない
そう見える
143 名前：名前は開発中のものです。 mailto:sage [2008/05/25(日) 19:34:28 ID:dDrBARgy]: >>140
？　ごめん。>>113 をどう読んでも、そうは解釈できんわ。
……まあ、>>140として、
それだと、他から状態を変えたりしにくいし、
仕様変更への対応も大変じゃないか？
仕様が確定していて絶対変わらないというのならいいけど。

>>142
「簡単になる」とは誰も言ってないよ。
そもそも「すべての場合でタスクシステムを使え」とも言ってない。
（実装方法そのものが本質ではないから）状態遷移の複雑さに応じて、
自分のやりやすい方法でやれと、みんな言ってると思うんだが。
何か変な思い込みが議論を阻害してる気がするな。
144 名前：名前は開発中のものです。 mailto:sage [2008/05/25(日) 19:57:43 ID:7UG2hamH]: >>140
上はstateによって処理を決定するけど下はなんだ？
stateを途中で変えられないような気がすんだけど
なんか比べるもん間違ってね？
145 名前：名前は開発中のものです。 [2008/05/25(日) 22:16:46 ID:6V9YbMCv]: 142に書いてる
>Stateのメリットは拡張性にあって可読性にはないから
>可読性を優先するならマイクロスレッドの形を取るべきだ
マイクロスレッドの方が可読性が高いかどうかは主観によるものだが
これを否定するのなら、そっちに話を持っていく

可変性や拡張性が低いってのも142に書いてるけど
そもそもスレッドを与えるクラスが小さいものであるなら、変更は脅威ではない
逆に、タスクシステムとやらが変更に強いとも断定はできない
あれは新しいクラスを作る拡張に強いのであって、置き換える形の変更には強いが
修正する変更はスレッドを用いたものと同じようなものだ
146 名前：名前は開発中のものです。 mailto:sage [2008/05/25(日) 22:45:40 ID:dDrBARgy]: たとえば、>>140 の信号に「夜間は点滅する」「殴られたら停止する」という仕様が追加された場合、

前者の、普通に状態遷移を書く場合だと、
void 夜になる() { if (state != 停止) state = 点滅; }
void 朝になる() { if (state == 点滅) state = 赤; }
void 殴る() { state = 停止; }
みたいなメソッドを追加して、
if (state == 赤) ... ;
else if (state == 青) ... ;
else if (state == 黄) ... ;
else if (state == 点滅) ... ;
else if (state == 停止) ... ;
と分岐を追加していけばいいよね。

後者のスレッドを用いる場合だとどう修正するの？
結局、似たような感じになっていく気がするんだけど。
147 名前：名前は開発中のものです。 mailto:sage [2008/05/25(日) 23:08:03 ID:jMUik1Ya]: >>125
>イベントドリブンがしたければ別にスレッドでもできるわけで

スレッドとタスクシステム（笑）では想定されている粒度が違う
極端な話、相互作用ありのパーティクルにスレッドなんて使わない
たとえばコンテキストスイッチなんて御大層なサービス要らないでしょ
148 名前：名前は開発中のものです。 mailto:sage [2008/05/25(日) 23:16:28 ID:jMUik1Ya]: >>131
えー。それは疑似タスク（笑）同様に疑似スレッド（笑）でしょ
単語の使い方が変杉。最初からスレッドでなく俺定義の
スレッド（笑）の話ってことを断ってその定義も説明しといてよ
149 名前：名前は開発中のものです。 mailto:sage [2008/05/25(日) 23:21:39 ID:7UG2hamH]: >>148
まあ、それはわかってるからいちいちこだわんなよ
わかってないのお前ぐらいだってｗ
150 名前：名前は開発中のものです。 mailto:sage [2008/05/25(日) 23:25:47 ID:jMUik1Ya]: 携帯端末でテケトーに流し読みレスしてっから
会話の全体像は見えてないよ！俺は！
151 名前：名前は開発中のものです。 [2008/05/25(日) 23:27:07 ID:6V9YbMCv]: >>146
がんがん追加してください
追加するほどスレッドを使った方がいいじゃないかと思えてきます
Stateを用いると文の上下の意味的なつながりがなくなるため
規模が大きくなるほどコードが分散して理解するのが困難になります

while (true)
{
if (通常)
{
赤(); sleep(?);
青(); sleep(?);
黄(); sleep(?);
}
else // 真夜中
{
点滅(); sleep(?);
}
}

void 緊急停止()
{
スレッドに対して停止命令();
}
152 名前：名前は開発中のものです。 mailto:sage [2008/05/25(日) 23:27:28 ID:4NW3nz0D]: てかくだんね
153 名前：名前は開発中のものです。 mailto:sage [2008/05/25(日) 23:29:42 ID:jMUik1Ya]: そもそもタスク（笑）とマイクロスレッドの明白な相違点て何よ
例えばコンテキストスイッチ付いてるとタスク（笑）じゃないっていうなら
おまいらのいうタスク（笑）ってどういうタスク（笑）なの
Logician Lordのタスクか？
154 名前：名前は開発中のものです。 mailto:sage [2008/05/25(日) 23:59:22 ID:vQVRM4Hf]: 俺の考えなしな書き込みのせいで、
タスクとコルーチンが対立項として扱われてる感じで、なんかゴメン
今までの流れから自分がどっちに行きたいのか整理してみると、こんな感じ

・タスク（あるいはオブジェクト指向による代替タスク）は有用だ。それはもちろん
・ただし、イベントドリブン主体であることには欠点もある。>>130のような負担ね
・コルーチンを併用すればそれを補えるかも知れない

例えばもし次のような実装が手元にあって、簡単にイベントドリブンとコルーチンを
使い分けられるなら、早く仕事がこなせる方をケースバイケースで選びたいよね

class Task {
public:
　　//サブクラスでonFrameTimer()をインプリメントすると毎フレームコールバック処理が行えます
　　virtual void onFrameTimer() {}

　　//サブクラスでcoroMain()をインプリメントすると関数がコルーチンとして起動されます
　　//yield()でメインルーチンへ処理が戻り、次フレームで再開（resume）、を繰り返します
　　virtual void coroMain() {}
}

実際にこんなC++実装が手元にあれば、みんな使う？

>>151氏あたりは既に使ってそうだけど、俺は使わない、もしくは迷うと思う。
実行コンテキスト切り替えコードは大抵アセンブリで速いけど移植性がないし、
他人に引き継ぎしずらいし（普及してないから）、ノウハウが無ければケアレスミスで簡単にスタックあふれるし。
だけどオールドスタイルのタスクもとてもストレスがたまるんだ

じゃあどうしたい、どうしたらいい、って話を、俺と同じように
現状のタスクに（意識的、または無意識的に）ストレス感じてる人に聞いてみたかったんだ
155 名前：名前は開発中のものです。 mailto:sage [2008/05/26(月) 00:21:41 ID:UvsW7CAY]: タスク（笑）といえばイベントドリブンなのか？
一定のタイムスライスでコンテキストスイッチするものはもはやタスク（笑）ではないのか？
156 名前：名前は開発中のものです。 mailto:sage [2008/05/26(月) 00:39:42 ID:J4tqU4Kx]: >>151
＞がんがん追加してください
じゃあ、もう少し追加してみる。
「殴られたら停止する」を、「殴られたら青→黄→赤の遷移を強制的にひとつ進める」に修正。
「点滅状態からの復帰時、点滅状態に遷移する直前の状態に戻す」を追加。
class 信号 {
　enum State { 赤, 青, 黄, 点滅 };
　State state, oldState;
　void 実行() {
　　switch (state) {
　　　case 赤: 赤処理(); break;
　　　case 青: 青処理(); break;
　　　case 黄: 黄処理(); break;
　　　case 点滅: 点滅処理(); break;
　　}
　}
　void 殴る() {
　　if (state == 赤) state = 青;
　　else if (state == 青) state = 黄;
　　else if (state == 黄) state = 赤;
　}
　void 夜になる() { oldState = state; state = 点滅; }
　void 朝になる() { state = oldState; }
};
＞Stateを用いると文の上下の意味的なつながりがなくなるため
＞規模が大きくなるほどコードが分散して理解するのが困難になります
ところで、この部分が何を言ってるのか良く分からないんだけど、もう少し説明してくれない？
関数が長くなるから読みにくくなるってことじゃないよね？

>>154
前にも書いたけど、そういうのは同じレベルで実装しないで、
コルーチンを使いたい部分をスクリプトで実装するのが良いと思う。
157 名前：名前は開発中のものです。 mailto:sage [2008/05/26(月) 00:56:08 ID:FFo0It8G]: あんたらいちいち相手を挑発しなきゃ議論できねーのかｗ
158 名前：名前は開発中のものです。 [2008/05/26(月) 01:19:18 ID:lNPZHMUK]: >>156
ひどいやつだなw
Pythonのジェネレータ関数風味で

色 foo() {
　while (true) {
　　yield 赤;
　　if (夜) {
　　　yield 点滅;
　　　yield 赤;
　　}
　　yield 青;
　　if (夜) {
　　　yield 点滅;
　　　yield 青;
　　}
　　yield 黄;
　　if (夜) {
　　　yield 点滅;
　　　yield 黄;
　　}
}
}
void 殴る() { foo(); }

処理の前後に何が処理されているのかというのは
スレッドなら前後の文を見ればすむ。
stateで管理するとstateの変化を追って確認しなければならないから
前後の流れを読むのが難しい。
gotoのスパゲッティコードのデメリットと同じようなもの。
分けてすぎたせいで、逆に可読性が失われている。
159 名前：名前は開発中のものです。 mailto:sage [2008/05/26(月) 01:25:20 ID:onffbclF]: coroutine的なことやってるのはスクリプト上だから移植うんぬんの悩みはないな
かといってオールマイティなのかといえばそーでもなく
時間経過に連続的に対応するような流れのもんは、要するにsleepをする必要のないものは
逆にcoroutineしないほうがきれい

>>156のように二通り選べるようにするのは理想的なのかもしれないが
大体ある特定の現象群を表現する分にはどっちか片方で十分だったりする
160 名前：名前は開発中のものです。 [2008/05/26(月) 01:37:09 ID:lNPZHMUK]: >>159
>時間経過に連続的に対応するような流れのもんは、要するにsleepをする必要のないものは
>逆にcoroutineしないほうがきれい
無理やりタスクシステムとやらのメリットを作ろうとしても無駄
タスクシステムとやら、つまりStateのメリットは拡張性にある
そのため可読性をかなり犠牲にしている
普通に書けばcoroutineの方が可読性が高い場合が多い、俺の主観では
161 名前：名前は開発中のものです。 mailto:sage [2008/05/26(月) 02:05:33 ID:02TzkeDh]: >>154
少し前の俺を見ているようだ。

>>116,130はコルーチンを使えば時系列に沿った行動の記述が簡単になる、という主張でいいんだよな？
それを踏まえるが、時系列に沿った記述をするコルーチン内では
外的要因による状態遷移を行おうとすると複雑になる、というのは気づいているかな。

yield() する前に毎回状態をチェックしてもいいんだが、チェックする内容によっては
スタックが溢れかねないし。

タスクで状態を監視＆管理しながら、コルーチンなりスクリプトなりで記述された行動を呼び出して、
両方の良いとこ取りをするのがいいと思うな。外的要因による行動の差し替えはタスクから行う、と。
俺はそうしてるよ。
162 名前：名前は開発中のものです。 mailto:sage [2008/05/26(月) 02:29:45 ID:J4tqU4Kx]: >>158
夜間に殴りつづけたときの動作がおかしくない？

＞stateで管理するとstateの変化を追って確認しなければならないから
＞前後の流れを読むのが難しい。
そういう面は確かにある。けど、通常の流れはstateを順番に
見ていけばいいので、それほど複雑にはならないと思うし、
特殊な処理を通常の流れとは分けて書けるメリットがある。
>>158みたいなやり方だと、一部分を見たときに前後の流れは直線的に理解できるけど、
通常の流れ(この場合だと夜=falseの場合)が読みにくくならないか？
163 名前：名前は開発中のものです。 [2008/05/26(月) 02:33:43 ID:lNPZHMUK]: タスクシステムとやらを使うメリットを誰も言えない
でも、タスクシステム信者としては黙ってられない

目を覚ませ
高いレベルでCommand利用を前提としたロジックを実装すると
他の有益なパターンが使いづらくなる
わざわざ、自分で制限をかけてプログラムを書いて
なんの修行をしているんだってのw
164 名前：名前は開発中のものです。 [2008/05/26(月) 02:51:26 ID:lNPZHMUK]: >>162
君こそ通常時の遷移が抜けてるぜw

状態遷移図書いたらわかるけど、このケースだと状態が
赤、黄、青、赤点滅、黄点滅、青点滅の六つ必要になってる
俺は状態遷移そのものが複雑なだけと見てるから
その割には単純になったと思ってる

どっちを選択しても複雑なんだから
StateをCommandとしてListに突っ込んでさらに複雑にするのは
バカげていると思わないかい?
165 名前：名前は開発中のものです。 mailto:sage [2008/05/26(月) 03:18:22 ID:j2qTftQO]: どーでもいいじゃん
166 名前：名前は開発中のものです。 mailto:sage [2008/05/26(月) 03:53:53 ID:J4tqU4Kx]: あー、ごめん。「点滅」は色とは関係ないつもりだった。実際は黄色か赤だろうけど。
つまり、State は４つで、夜間は殴ってもなにも起きなくていい。
つか、自分で仕様変更して自分でソース書いてるんだから、
「状態の数が違う」みたいな豪快なバグは入れないよ。
でも、状態が６つだとしても、>>158 はおかしいだろ。
夜間に殴りつづけると、点滅→赤→青→点滅……と変わっていくんじゃないの？

通常時の遷移はわざわざ書く必要もないだろうし、改行が多すぎて拒否されたんで省いたけど、
その部分だけ書くと、こんな感じかな。
class 信号 {
　static const int 赤時間;
　static const int 黄時間;
　static const int 青時間;
　int timer;
　void SetState(State state) { this->state = state; timer = 0; }
　void 赤処理() { if (++timer >= 赤時間) SetState(青); }
　void 黄処理() { if (++timer >= 黄時間) SetState(赤); }
　void 青処理() { if (++timer >= 青時間) SetState(黄); }
};

＞StateをCommandとしてListに突っ込んで
というのが分からんのだが、List に突っ込むのは
タスク (この場合は信号オブジェクト) であって、State じゃないだろ。
状態ごとの処理は各タスク内で完結してるんだから、さらに複雑にはならんよ。
167 名前：名前は開発中のものです。 [2008/05/26(月) 05:18:08 ID:lNPZHMUK]: >>166
俺の書き方が悪かった、二択だ
ひとつめ
赤、青、黄、赤の裏の点滅、青の裏の点滅、黄の裏の点滅
ふたつめ
赤、青、黄、点滅
このどちらかが状態のリストになる
コードは前者であると仮定してシンプルに書いた、点滅は書き損じ
それとも、状態遷移の状態も作るというのなら、俺はパス
168 名前：名前は開発中のものです。 [2008/05/26(月) 05:33:57 ID:lNPZHMUK]: 赤、青、黄、赤の裏の点滅、青の裏の点滅、黄の裏の点滅
ならば
遷移が発生するイベントは時間経過(通常)と殴ると時間経過(例外)

赤、青、黄、点滅
ならば
遷移が発生するイベントは時間経過(通常)と殴ると時間経過(例外)
さらに、時間経過(例外)から入力された三つの値、赤から、青から、黄からのイベント
時間経過(例外時)に入力が発生する
169 名前：名前は開発中のものです。 mailto:sage [2008/05/26(月) 12:34:03 ID:J4tqU4Kx]: よくわからん。「状態遷移の状態」を作るってどういう意味？
あと、普通に色が変わる場合の「時間」は誰がどこで設定するの？
他のオブジェクトから信号の色を知りたい場合にどうするのかも気になる。
結局、>>158 のスクリプトとは別のところで信号の状態を管理することになるんじゃないの？
170 名前：名前は開発中のものです。 [2008/05/26(月) 15:51:02 ID:lNPZHMUK]: 状態のネストというらしい、俺はその辺は詳しくない
最初に適当に書いた俺が悪かった

enum { RED, BLUE, YELLOW } color;
void timeout()
{
　if (color == RED) color = BLUE;
　else if (color == BLUE) color = YELLOW;
　else if (color == YELLOW) color = RED;
}

enum { RED, BLUE, YELLOW } color;
void coroutine()
{
　while (true)
　{
　　color = RED;
　　yield;
　　color = BLUE;
　　yield;
　　color = YELLOW;
　　yield;
　}
}
void timeout() { yield; }
171 名前：名前は開発中のものです。 [2008/05/26(月) 16:04:14 ID:lNPZHMUK]: INIT状態で点滅、resetでINITに遷移
殴るはtimeoutと同じ意味だから必要ないよな

enum { RED, BLUE, YELLOW, INIT } color;
void timeout()
{
　if (color == INIT) color = RED;
　else if (color == RED) color = BLUE;
　else if (color == BLUE) color = YELLOW;
　else if (color == YELLOW) color = RED;
}
void reset() { color = INIT; }

enum { RED, BLUE, YELLOW, INIT } color;
void coroutine()
{
　color = INIT;
　yield;
　while (true)
　{
　　color = RED;
　　yield;
　　color = BLUE;
　　yield;
　　color = YELLOW;
　　yield;
　}
}
void timeout() { yield; }
void reset() { コルーチンリスタート(); }
172 名前：名前は開発中のものです。 mailto:sage [2008/05/26(月) 20:50:15 ID:pgU86LI0]: あれ、こんなスレあったんだ。

何年かゲームプログラム(非プロ)やってるけど、
この周りはどうしても複雑になるよね。以下この辺の処理の個人的感想。
・(いわゆる)タスクシステム
　関数ポインタでジャンプやらStateパターン、Strategyパターンなど。
はまってた頃は多用したのだが、今ではシーンの遷移にしか使わない・・・
敵やら弾とかの状態遷移はif文分岐で困らん。
いわゆるUpdateやRenderの中でif文分岐の方が読みやすいよ。。。

・コルーチン、ファイバ、マイクロスレッド
エフェクトやら敵の動きのような処理を外だししたときに
スクリプト内で使うのみ。
組み込まれていない言語(C++とか)では使わない。

・スレッド
メイン、BGM再生、データ読み込み以外は不要。
デバッグ用のログ出力ウィンドウとか作成したときは別スレッドにする。
1キャラクタ1スレッドとかやった人いるのだろうか？
スレッドでつくると、スレッド生成時にそのスレッドのための
スタック領域(デフォルトだと1スレッドにつき、512kBだか1MBだっけ？)が必要ですよね。
もちろんサイズ変更はできるけど、少なくしてスタックオーバーフローで落ちる
限界を見極めるとか面倒すぎる気がする。
173 名前：名前は開発中のものです。 mailto:sage [2008/05/26(月) 21:45:04 ID:QJtuJBIN]: >・コルーチン、ファイバ、マイクロスレッド
>エフェクトやら敵の動きのような処理を外だししたときに
>スクリプト内で使うのみ。

なるほど、そういう使い分けなのね

>組み込まれていない言語(C++とか)では使わない。

継続やコルーチン的なことがやりにくいから？
可能ならやる？
174 名前：名前は開発中のものです。 mailto:sage [2008/05/27(火) 00:01:22 ID:cvXssXEI]: >継続やコルーチン的なことがやりにくいから？
>可能ならやる？
可能ならやるというか
その言語の通常の仕組みで記述できる範囲なら使います。
ただC++で書く場合なら、このスレでいうタスク(敵とか弾とか)のようなのは
外部ファイルに出します。

あと組み込みでない言語を細工してコルーチンを実装するのと
元々実装してある言語では、できることの範囲に差があるように思えます。
例えばコルーチンはコルーチン自体を入れ子にできると
便利ですよね。説明しづらいですが
エフェクト作成関数
{
　coroutine エフェクトメイン
　{
　　coroutine エフェクト座標操作{...}
　　coroutine エフェクト描画元画像位置操作{...}

　　エフェクト座標操作コルーチン起動
　　エフェクト描画元画像位置操作コルーチン起動
　}
　エフェクトメインコルーチン起動
}
のような感じで、関数やコルーチンの内側に次々と子の関数やコルーチンを生成できるようなの。
C++には内部関数すらないのでこういったのは難しいです。
(関数内に構造体を宣言して内部関数みたいなのはつくれますが
外部のローカル変数にはアクセスできない)
175 名前：名前は開発中のものです。 mailto:sage [2008/05/27(火) 00:38:38 ID:5lsjU+J+]: コルーチン的なことはスクリプトでやると言う人がちらほらいるね。
何を使ってるんだろう。
Lua？　Squirrel？　それとも独自実装スクリプトなのかな

>>173
>継続やコルーチン的なことがやりにくいから？
>可能ならやる？

C言語上のコルーチンは環境に左右されやすすぎない？

たとえば、ゲームプログラマが多分いま一番関わることが多いだろうDSで
C言語上のコルーチンを実装したとしても、
DSでは通常スタック領域をDTCMという高速メモリに割り当てているにも関わらず、
コルーチン呼び出し中はスタック領域をメインメモリ上に持っていくことになってしまい、
ローカル変数アクセスや関数呼び出しはガクンと遅くなると考えられる。

※以上のDSの話は以下の記載を根拠にした
ttp://meraman.dip.jp/index.php?NDS_Chap11
176 名前：名前は開発中のものです。 mailto:sage [2008/05/27(火) 08:13:36 ID:tDqFmLHm]: >>175
俺は独自実装スクリプト。lua だと、ちょっとスクリプタが辛そうだったんで。
177 名前：名前は開発中のものです。 mailto:sage [2008/05/28(水) 20:41:16 ID:2pIaJOU5]: >>172
ちょっとまって
横文字書いて満足しちゃってそうだから突っ込むけど
そのどれも>>111にあるみたいな
オブジェクト同士が絡むときの処理の何かを解決するの？

意味ねぇっていってんじゃん
わざわざそんな複雑にしていったい何がやりたいのか意味不明

ちょっとオナニー入ってない？

っていうのはね
なんか聞きなれない言葉多いじゃない？
そういうの複数人で開発するときやこういう掲示板で情報を共有しようってときに
すごく邪魔なのよホント
178 名前：名前は開発中のものです。 mailto:sage [2008/05/28(水) 20:47:29 ID:DREncIEi]: >>177
turemasuka
179 名前：名前は開発中のものです。 mailto:sage [2008/05/28(水) 20:50:08 ID:2pIaJOU5]: >>178
アフォ？
そんな部分どう組んだって完成すんだよ
問題はオブジェクト同士がかかわったときの管理をいかにうまく管理するかだ
そこに技術使わないで一体どこに技術を使うというのか？
逆にそれ以外好きにしろよｗ
180 名前：名前は開発中のものです。 mailto:sage [2008/05/28(水) 20:54:51 ID:DREncIEi]: タスクシステムのスレでそんなこといわれてもな。
181 名前：名前は開発中のものです。 mailto:sage [2008/05/28(水) 21:18:38 ID:DREncIEi]: >問題はオブジェクト同士がかかわったときの管理をいかにうまく管理するかだ
>そこに技術使わないで一体どこに技術を使うというのか？
ここについて話したい素直にそう書けばいいことでは。
182 名前：名前は開発中のものです。 mailto:sage [2008/05/28(水) 22:37:27 ID:UT4Zgemv]: これがいわゆるツンデレってやつかい？
183 名前：名前は開発中のものです。 mailto:sage [2008/05/28(水) 23:55:23 ID:shc+nb/z]: >>177
いったいどれが聞きなれない言葉？
ゲームプログラム特有の言葉は
＞タスクシステム、いわゆるUpdateやRender、エフェクト、1キャラクタ、シーンの遷移、敵やら弾
くらいで、他はプログラムかじってたら知っていそうな用語ばかりだと思う。
と思ったが、かじってる言語によるわな。
スレッドのスタック領域ってなんですか？　ってなってもおかしくないし、問題があるわけでもない。

>問題はオブジェクト同士がかかわったときの管理をいかにうまく管理
ここは同意。整然とかけない。
184 名前：名前は開発中のものです。 mailto:sage [2008/05/28(水) 23:57:06 ID:Uls7k781]: >>177が言ってる横文字って、デザインパターンのことじゃね？

デザインパターンは、プログラマ同士の簡潔な意思疎通に
役立つというのが利点のひとつだと思うけど、
デザインパターン自体が分かってもらえない場合は逆に混乱をまねく。
ゲーム業界にはデザパタは明らかに普及してないから、
>>117のような多分古株のプログラマから反発があるのは仕方ないかと・・・。

まあ、俺は>>172の味方だけどなｗ
185 名前：名前は開発中のものです。 mailto:sage [2008/05/29(木) 00:35:39 ID:b9433K2i]: タスクの勉強するにあたってのお薦めの書籍はありませんか？
186 名前：名前は開発中のものです。 mailto:sage [2008/05/29(木) 00:53:27 ID:XHqPrNQg]: 「勉強」するほどのものなのだろうかといつも思うんですが……。
普通に思ったままC++で組んでみれば？
187 名前：名前は開発中のものです。 mailto:sage [2008/05/29(木) 00:59:34 ID:syTZfubz]: >>185
古典的なタスクを勉強したいのですか？
なんのために？？？

C++が使えない場合や、メモリ管理がシビアな場合、
技術レベルが一定しない複数人数でコーディングする場合などは、
管理構造体のリストor配列で手軽に管理できる（つまり、作りが単純な）タスクは
確かに役に立つけれど・・・。
Windowsでプログラムするならもっと色んな良いやり方があると思う。

タスクを解説した本って見たことないんだよなー。
ネットの情報の方がまとまってるんじゃないかな。
仕事で必要ってのなら、現場でソースを見て覚えるのが一番かと（そもそも、会社によって作りが全然違うし）。
188 名前：名前は開発中のものです。 mailto:sage [2008/05/29(木) 01:49:18 ID:DnMQ76l7]: ゲームのためのタスクシステム：C MAGAZINE 2004年12月号特別記事
ttp://cgi32.plala.or.jp/higpen/sIssue/tasksystem.shtml

書籍というとこれぐらいか。
今でもCマガのバックナンバー買えるのかどうか知らんが
わざわざ買うようなもんでもないと思う。
189 名前：名前は開発中のものです。 mailto:sage [2008/05/29(木) 01:52:42 ID:cLzPDmvQ]: つ>>7-8
190 名前：名前は開発中のものです。 mailto:sage [2008/05/31(土) 21:32:30 ID:O6vPsevd]: 流れで記述するための擬似コルーチン（？）マクロ
ちゃんと時間があるならスクリプトを組み込むなりすべきと思うが
そういうことができない場合もある

#define BEGIN　　　　　int pg_cnt__ = 0
#define END　　　　　　 ++work->pg_cnt
#define DO　　　　　　　if (pg_cnt__++ == work->pg_cnt)
#define LABEL(x)　　　pg_cnt = x
#define GOTO(x)　　　 do { work->pg_cnt = x-1; return; } while (0)

void task_handler(TASK_WORK* work)
{
　　BEGIN;
　　DO printf("１フレーム目\n");
　　DO {
　　　　printf("２フレーム目");
　　　　GOTO( 100 );
　　}
LABEL( 100 );
　　DO printf("３，５，７，９…フレーム目\n");
　　DO {
　　　　printf("４、６，８，１０…フレーム目\n");
　　　　GOTO( 100 );
　　}
　　END;
}

他にこういうのもある>www.sics.se/~adam/pt/index.html
なんにしろコルーチン不要論は理解できないです
191 名前：名前は開発中のものです。 mailto:sage [2008/05/31(土) 21:57:25 ID:+aan3boX]: >>190
何がいいたいのかわからない
オブジェクトとオブジェクトが関わるところ以外は好きに組めばいいじゃん

俺等が知りたいのはオブジェクトAがステータス１の状態で
オブジェクトBがステータス２の状態のときに
この２つの物体が接触したときのそれぞれのステータスの変化
やそのときに生じるイベントの管理の方法なわけよ

ここさえ綺麗に管理できるってんなら他は何しててもいいよ

以上

何書いてあるか正直読んでないけど
これを解決できるものなの？>>190の内容は・・・

だいたいね、君が管理していい気になってるところなんて
管理できなかったゲームはないのよ
既存部分をちょっと自分流に書き換えていい気になってんでしょ？邪魔邪魔（笑）
192 名前：名前は開発中のものです。 mailto:sage [2008/05/31(土) 22:06:22 ID:O6vPsevd]: うーん、気を悪くしてほしくないんだけど
>>191のテーマだって管理できなかったゲームはないと思うんだが・・・

つかね、>>191のテーマは別の議題として議論する価値はあると思うし
ちゃんと議題としてまとめてもらえれば、俺も参加させてもらうよ

俺は最近のゲーム業界ではむしろ演出面での要求の負担が大きくなってるから
演出をいかに効率的に実装するかを（特にタスクとの併用において）考えたいって言ってるんだ
193 名前：名前は開発中のものです。 mailto:sage [2008/05/31(土) 22:32:22 ID:4GhMIZDi]: 190=110だとするなら最初の話から外れてきているように見える。

191の話題はタスクシステムの範疇を超えて設計全般に及びそうだから
↓のスレの方がふさわしいと思う。

ゲームにおけるデータ構造・クラス設計・パターン2
pc11.2ch.net/test/read.cgi/gamedev/1211544659/
194 名前：名前は開発中のものです。 mailto:sage [2008/05/31(土) 22:44:52 ID:+aan3boX]: タスクってなんのためにタスクにするのか最早意味不明なんだよな
なんでもタスクにすると今度は当たり判定の優先順序の管理のが面倒になって意味がねぇ
ここはプライオリティなんて変数作って番号で管理なんかするより
ソースに直接記述したほうがわかりやすくていい
そもそも状況によって処理順序が変わることがあるんだろうか？

って考えるとタスクも意味がねぇよな
195 名前：名前は開発中のものです。 mailto:sage [2008/05/31(土) 22:52:05 ID:twk4PUSn]: 外れるように話を広げたのはタスクシステム信者だろ
タスクシステムのメリットを言える奴は誰もいない
拡張性がいいとほざく奴がいるけど、代わりに複雑性を内包する必要が出る
さらに、影響が広範囲に及ぶため、他の様々な有益なパターン適用の枷となる
しかも、これを使えば万能みたいな説が流れているせいで初心者が勘違いして使って
無駄に複雑なコードを書いて自滅する
使う理由は「あんなすごいひとが使っているから」というカルト的理由によるもの
完全に時代遅れのアンチパターンだ
こんなクソパターンは今世紀に入る前に消滅させるべきだった
196 名前：名前は開発中のものです。 mailto:sage [2008/05/31(土) 23:23:00 ID:D6/N/mJk]: おまえ今世紀に入る前に消滅させるべきだったって言ってみたかっただけやろ
197 名前：名前は開発中のものです。 mailto:sage [2008/05/31(土) 23:34:14 ID:O6vPsevd]: >>193
外れてきてますね・・・。最初はただの愚痴だったｗ
まあでもせっかく人が集まってるみたいだし、なんかタスク絡みのいろいろを情報交換したいな

>>194-195
アンチパターンかー。過激だが、そうかもなあ

俺は、タスクは（名前の通り）継続的な処理を示すんだと解釈してるんだが
それを、それ以外の状態を持った何かに拡張させようとするから混乱するんじゃまいか
たとえばタスクとスプライトは、俺は別の扱いにすべきだと思う
198 名前：名前は開発中のものです。 mailto:sage [2008/05/31(土) 23:43:37 ID:O6vPsevd]: MVC設計でいうと、スプライトが車だとすれば
タスク=Contoroller
スプライト=View
車の車種やスピード管理クラス=Model
かな
199 名前：名前は開発中のものです。 mailto:sage [2008/05/31(土) 23:51:05 ID:rHVvUvBq]: >>195
タスクシステムって、制御構造を動的かつ柔軟に変更出来るところがメリットでしょ。
コード片を一つのオブジェクトとして使えるというのはアンチパターンなんかじゃなく、
柔軟なプログラミングを行ううえでの重要なパターンに違いないと思うけどな。

>>194
表示順位なんかはころころ変わるでしょ。斜め上方からの視点な2Dゲームとか。
また例えば、BがAというオブジェクトの相対位置に固定されるように
動的に処理の切り替えを行いたいとして、Aが毎フレーム自由に移動している場合、
Bは必ずAの移動処理の後に位置を決定しなければならない。
でないと1フレーム分位置がずれてしまうから。(そういうゲームあるよね・・)
これは１タスクを表すオブジェクトに、事前に完了しているべきタスクへの参照情報を保持させれば
スマートに実装出来ると思う。(デッドロック的な状況に陥る可能性がふと頭を過ったのは内緒･･)
もしこれがハードコーディングでB->Aという処理順序で固定されてしまっていたら
フラグなどを使った面倒くさい制御なんかが増えて可読性が良くないと思うんだよね。
200 名前：名前は開発中のものです。 mailto:sage [2008/06/01(日) 00:09:34 ID:26Sl1TFL]: 要するに汎用性を追及したい病、ハードコーディング気持ち悪い病でしょ。プログラマのかかる罠。
ゲームのオブジェクト管理の場合、中途半端に成功しそうに見えるのがまた手に負えないところだ。
201 名前：名前は開発中のものです。 mailto:sage [2008/06/01(日) 00:53:17 ID:DrvtIKA9]: そうそう、どの方向に拡張したいかを考えずに
どの方向にも拡張したいと考えるからおかしくなる

それと、ノベルゲーみたいなものでは割とうまくいきそうな
PAC(プチPAC)を、他のゲームでもうまくいくだろうと考えるのはおかしい
PACはエージェント同士の関係が複雑にならないものや
単純なルールのゲームでしか使い物にならない
202 名前：名前は開発中のものです。 [2008/06/01(日) 01:02:29 ID:DrvtIKA9]: >>199
おまえが何もわかっていないということはよくわかった
変更と追加はまったく違う
CommandやStateのメリットですらない

有益なんだったら、外国に布教してきなよ
鼻水流して感謝されるぜw
203 名前：名前は開発中のものです。 mailto:sage [2008/06/01(日) 01:44:46 ID://w8HXJr]: 一応補足しとく
>>201の言うPACとは（Presentation, Abstract, Controller）の略で、MVCに近い手法らしい

んで、PACは俺は知らないんだけど、大体MVCのようなものとして聞くけど、
PACが単純なルールにしか適用できないと考えるのはなぜ？

俺はむしろ、単純なルールならMVCやらPACみたく、わざわざ構造を分離させない
>>199の言うような、複雑で動的なルールに対応するために
そういう設計手法があるんじゃないのか？
204 名前：名前は開発中のものです。 mailto:sage [2008/06/01(日) 01:46:29 ID:37mn39Y5]: 厨房だらけの掲示板でさえ
Singletonとか言い出す奴にはグローバル変数で十分じゃいと返され
MVCとか言い出す奴にはおまえV複数つくる気あるんかいと返される
そんな海外
合理的だ
205 名前：名前は開発中のものです。 mailto:sage [2008/06/01(日) 01:55:03 ID://w8HXJr]: >>201
あ、ごめん。PACはツリー構造なんだな。MVCとはだいぶ違うっぽい
PACの何を批判してるのか俺は理解してないようなので>>203はスルーしてくれ
206 名前：名前は開発中のものです。 mailto:sage [2008/06/01(日) 08:00:05 ID:A9oINGs6]: >>195
＞拡張性がいいとほざく奴がいるけど、代わりに複雑性を内包する必要が出る
＞さらに、影響が広範囲に及ぶため、他の様々な有益なパターン適用の枷となる
「複雑性を内包」とはどういうことか？
なぜ「影響が広範囲に及ぶ」のか？
どのようなパターン適用の枷となるのか？

この辺をちゃんと説明してよ。
それこそ「初心者が勘違いして使って無駄に複雑なコードを書い」た結果なんじゃないの？
207 名前：名前は開発中のものです。 mailto:sage [2008/06/01(日) 09:03:00 ID:rH1ss0D0]: >>206
そんなのわかんないのお前だけだよ
もうね、そういう議論に勝つための質問はもうおなかいっぱいなんだ
208 名前：名前は開発中のものです。 mailto:sage [2008/06/01(日) 16:10:22 ID:A9oINGs6]: いや、勝ち負けじゃなくてさ。
純粋に、「タスクシステムだと適用できない、有益なパターン」てのを知りたいんだけど。
その「有益なパターン」が本当に「タスクシステムのせい」で使えないのだとすれば、
曖昧にしておく意味はないと思うんだけど。それこそ、君の「勝利」のためにも。

つか、「自分に質問／反論する奴はすべてタスクシステム信者」と思ってるみたいだけど、
俺はタスクシステム、非タスクシステムどちらも経験していて、
複雑さに関しては「どっちでも特に変わらない」と思ってるんだよね。
とすると、「タスクシステムだと適用できない、有益なパターン」が鍵を握ってそうじゃん。
209 名前：名前は開発中のものです。 mailto:sage [2008/06/01(日) 16:25:17 ID:uh0F8OUP]: >>199
＞表示順位なんかはころころ変わるでしょ。斜め上方からの視点な2Dゲームとか。

それ要するに深度値（Z）ソートだよね。で、半透明なしは深度バッファ任せとか。そういう話でしょ。
たすくしすてむ？プライオリティ？なになにー？みたいな。そんな単語が出る幕あるか？

＞また例えば、BがAというオブジェクトの相対位置に固定されるように
＞動的に処理の切り替えを行いたいとして、Aが毎フレーム自由に移動している場合、
＞Bは必ずAの移動処理の後に位置を決定しなければならない。
＞でないと1フレーム分位置がずれてしまうから。(そういうゲームあるよね・・)

それ要するに親子関係でしょ。ペアレントするとか骨を入れるとか。そういう話でしょ。
モノ同士の依存関係を表すために、なんで線形リスト（？）の要素内にプライオリティ
という変数があってー、みたいな話になるのかわかんね
210 名前：名前は開発中のものです。 mailto:sage [2008/06/01(日) 16:29:37 ID:uh0F8OUP]: あとこれ偏見かもしらんけど、端から2D前提で話をする人には2通りいる気がする

①2D3Dを一般化して同じ土俵で語れる。話の便宜上（簡易化のため）2Dで語ってるだけの人間。
②3Dが苦手。2D全盛時代の貧弱ハード＆開発環境下に苦し紛れに生み出された貧乏テクを
　その生まれた背景や導出過程を理解することなく天下り的に教わり、盲信し、呪縛されてる。

で、タスクシステム狂信者って圧倒的に後者が多いでしょ。老いも若きも。
この手合いは、表示上の縛り（2D、クォータービュー疑似3D）が発想の縛りにすら
なってしまっていて、とにかく何でもかんでも一個の線形リストにぶち込んで
とにかく巡回巡回巡回、僕のforeach！リスト巡回UPDATE最高！以外に脳がない
211 名前：名前は開発中のものです。 mailto:sage [2008/06/01(日) 17:29:17 ID:uh0F8OUP]: 松浦尊師のナンチャッテタスクシステム教団に入信し洗礼を施され
タスクシステムこそ絶対にして至高、時空を超越した普遍の真理と
信じて疑わないこの恐るべき子供達は、経典に記述された線形リストと
その要素内にあるプライオリティという変数に固執し、それをもって
深度による前後関係や物体同士の親子関係を表現させようと試みる。
その様はもはやカルト。不合理の極みだが、彼らは経典に従わねば
仏罰が下ると盲信しているので家族による奪還は難しい。

彼らは粗末なバラック小屋に無理やり機能拡張を試み増改築魔改造
を繰り返しついには九龍城みたいなよくわからないものを築き上げ
その偉容にホルホルするのだが、いざ使ってみればただのグロテスクな
汚物だと気付き、世を穿かなんで配列厨になることだろう
212 名前：名前は開発中のものです。 mailto:sage [2008/06/01(日) 17:40:18 ID:PJD7oyGT]: 君のおかげでタスク教から目が覚めたよ
だから単純明快で使いやすい代替システムをまとめた講座サイトを作ってくれないかな
213 名前：名前は開発中のものです。 mailto:sage [2008/06/01(日) 17:44:22 ID:zLG7F7W1]: 毎度必ず、連続投稿の最後にポエムつけてくるよなｗ

[ 続きを読む ] / [ 携帯版 ]

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef