- 1 名前：名前は開発中のものです。 mailto:sage [2007/12/04(火) 04:51:53 ID:bGSXJYb0]
- タスクシステムについての議論、相談、質問、雑談などのスレです
前スレ pc11.2ch.net/test/read.cgi/gamedev/1173708588/
- 70 名前：名前は開発中のものです。 mailto:sage [2007/12/17(月) 23:00:26 ID:ZuWNJ+Fe]
- つまりタスクシステムは何なわけ？
わたしわかりまぁせん
- 71 名前：名前は開発中のものです。 mailto:sage [2007/12/17(月) 23:12:00 ID:DxnpSp/c]
- foreach
- 72 名前：名前は開発中のものです。 mailto:sage [2007/12/17(月) 23:52:08 ID:lVhxy2mV]
- ここはwhile(1);つかfor(;;);かな。最適化されてればどっちも同じだろうが。
- 73 名前：名前は開発中のものです。 mailto:sage [2007/12/18(火) 20:23:42 ID:RgUcH/0L]
- 1フレーム毎に（大抵）全てのオブジェクトのupdateメソッドがコールバックされるシステム
と考えていいんじゃね？
- 74 名前：名前は開発中のものです。 mailto:sage [2007/12/18(火) 23:42:42 ID:LovnfmvP]
- -----------------------------------------------------------
987 ：名前は開発中のものです。：2007/12/03(月) 23:02:28 ID:hqsjjSWF
スレのログ見ると、定期的に「タスクシステム＝デザインパターン」とか絶叫してる人がいるみたいだが
この人たちの言うタスクシステムってどのタスクシステムの話なんだろうね？
【１．タスクシステム＝Logician Lordで紹介されているもののことだよ】
ギャラクシアンとその直系に見られる特徴的な実装こそタスクシステムであり
その要件を満たさない異形のコードは全て紛い物だ。タスクシステムとか名乗るな
【２．タスクシステム＝リスト巡回UPDATE。ていうかforeachだよ。】
ギャラクシアンのそれとは全く別物の、異形のコードであろうとも
俺がタスクシステムって呼べばタスクシステムなんだいバーロー
-----------------------------------------------------------
観察してると、どうもタスク厨って呼ばれてる子は後者が多いような気がしてきた。
何も知らない頭白紙の状態で松浦教祖に洗礼を受けたこの恐るべき子供たちは
タスクシステムというフレーズにとても執着してるようだが、厨房神経を刺激する
何かがあるのか？
とにかく何が何でもこのタスクシステムという古のローカル用語を俺様理論で
再定義・再構築してやろう、という無駄な努力がヒシヒシと伝わってくるんだが
ある意味で（マムコ信者に言わせれば）由緒正しいｗローカル用語をわざわざ
掘り起こしてきて流用するのは止めてくれって思う
「朕思うに」「新概念」「新解釈」「オナニー」「再構築」は好きなだけやっていいから
なんか別の名前にしろよ。「リスト巡回UPDATE」でも「僕のforeach」でも
「エターナルフォースブリザードシステム」でも何でもいいからさ
- 75 名前：名前は開発中のものです。 mailto:sage [2007/12/18(火) 23:44:17 ID:m+PO2WK4]
- 私はもうタスクという言葉自体を使ってない
- 76 名前：名前は開発中のものです。 mailto:sage [2007/12/19(水) 08:00:04 ID:hUc1dbeP]
- ゲイは身をタスク。
- 77 名前：名前は開発中のものです。 mailto:sage [2007/12/19(水) 15:24:26 ID:Ir64JLrB]
- ○○システムって言い方自体、かなり厨2魂を揺さぶるフレーズだよ
- 78 名前：名前は開発中のものです。 mailto:sage [2007/12/19(水) 15:25:28 ID:F/n53iWq]
- じゃあタスクパターンで
- 79 名前：名前は開発中のものです。 mailto:sage [2007/12/19(水) 20:46:55 ID:UEhDeB5F]
- ＞タスクパターン
「ストラテジーパターン？あー、AoEとか大戦略ってパターンだよね」
とか真顔で言ってのけるウィザード級ハッカーの心の琴線に触れる
- 80 名前：名前は開発中のものです。 mailto:sage [2007/12/19(水) 20:47:44 ID:hUc1dbeP]
- じゃあ、「タスクモンスターとのアルティメットコラボレーション」で。
- 81 名前：名前は開発中のものです。 mailto:sage [2007/12/20(木) 07:20:27 ID:c5xOqVc7]
- >>74
タスクシスステム改め
ギャラクシアンロジックかLogician Load Systemでおｋ
- 82 名前：名前は開発中のものです。 mailto:sage [2007/12/20(木) 20:44:20 ID:tLt8cR7R]
- エロスロジック
- 83 名前：名前は開発中のものです。 mailto:sage [2007/12/21(金) 00:29:57 ID:rVMYRhvV]
- オナニーシステムで通じると思うんだ
リスト巡回オナニーも分かりやすい
オナニーforeachは微妙
オナニーパターンはオナテク板で使用済み
- 84 名前：名前は開発中のものです。 mailto:sage [2007/12/21(金) 00:38:40 ID:Jo2a6K/I]
- じゃ、タスクシステム関連は、PinkBBSに移動しようか。
- 85 名前：名前は開発中のものです。 mailto:sage [2007/12/21(金) 01:45:05 ID:sZQMdwXf]
- 僕の肛門もリスト巡回されそうです
- 86 名前：名前は開発中のものです。 mailto:sage [2007/12/31(月) 11:54:08 ID:K8WL7pln]
- どうすればギャラクシアンのソースを見られますか？
- 87 名前：名前は開発中のものです。 mailto:sage [2007/12/31(月) 15:03:05 ID:73X1rpDN]
- 逆アセンブルすればそれがほぼソース
- 88 名前：名前は開発中のものです。 mailto:sage [2007/12/31(月) 18:29:38 ID:K8WL7pln]
- >>87
ファミコン版でいいですか？
- 89 名前：名前は開発中のものです。 mailto:sage [2008/01/07(月) 06:40:49 ID:5ateSYSb]
- タスクシステムこそ
ゲーム業界にのみ伝わる現代の魔術
連綿と口伝によってのみ受け継がれ
変化し、進化と退化を繰り返す
その亜流は数知れず、もはやその全てを語れるものはいない
- 90 名前：名前は開発中のものです。 mailto:sage [2008/01/07(月) 14:38:53 ID:GyFmGIbt]
- 都市伝説テンプレート
- 91 名前：名前は開発中のものです。 [2008/01/14(月) 14:54:45 ID:qTpR8IwF]
- つまりはスケジューリングでおk？
- 92 名前：名前は開発中のものです。 mailto:sage [2008/01/14(月) 15:24:10 ID:qReoD61a]
- 少なくともスケジューリングは含まれるだろうな
- 93 名前：名前は開発中のものです。 mailto:sage [2008/03/13(木) 22:58:00 ID:Bu/r75Um]
- 保守
- 94 名前：名前は開発中のものです。 [2008/04/03(木) 17:01:08 ID:0WE0DNgq]
- ゲームプログラミングで分厚い目の本選んだら
著者流タスクシステムの解説が大半で(´･ω･`) ｼｮﾎﾞｰﾝ。
- 95 名前：名前は開発中のものです。 mailto:sage [2008/04/03(木) 18:08:34 ID:HifUC8Yv]
- >>94
>>7
- 96 名前：名前は開発中のものです。 mailto:sage [2008/04/03(木) 18:34:18 ID:0WE0DNgq]
- 逆引きタスクシステム
これだorz
- 97 名前：名前は開発中のものです。 mailto:sage [2008/04/03(木) 18:37:31 ID:0WE0DNgq]
- ちょっと違ったな。
買ったのは「逆引きゲームプログラミング」って書いてあるから姉妹本かな。
表紙に堂々とタスクシステムなんて書いてあったらさすがにスルーするしねw
- 98 名前：名前は開発中のものです。 [2008/04/06(日) 18:50:02 ID:cIcTAloV]
- Javaはポインタが使えないからイテレータ使うしかないのかな？
- 99 名前：名前は開発中のものです。 mailto:sage [2008/04/06(日) 21:07:19 ID:RBp65Y5g]
- >>98
Java がポインタを使えないのは確かだが、たぶん >>98 はそれ以前の
勘違いをしている。
- 100 名前：名前は開発中のものです。 mailto:sage [2008/04/06(日) 21:09:30 ID:ptmozDNb]
- ねぇぼく、すれたいよめゆ？
- 101 名前：名前は開発中のものです。 mailto:sage [2008/04/06(日) 21:24:10 ID:hAyEqcH5]
- >>98にタスク厨の素質を感じた
お前たち、大事に育てなさい
- 102 名前：名前は開発中のものです。 mailto:sage [2008/04/07(月) 04:08:41 ID:qDynBUHm]
- ■星屑きらら杯
ttp://kirara111.sakura.ne.jp/
主催：１１１
超絶神星屑きららを迎えての史上最強コンテスト。
優勝賞金はwebマネー３万円ぶん。
今までの常識は通用しない、コードネームは・・・アンタッチャブル。
- 103 名前：名前は開発中のものです。 mailto:sage [2008/04/07(月) 16:38:25 ID:V2Suu5FZ]
- ほえ
- 104 名前：名前は開発中のものです。 mailto:sage [2008/04/20(日) 10:58:52 ID:tFc51Cra]
- boost::circular_bufferってタスクシステム向きだと思う
- 105 名前：名前は開発中のものです。 mailto:sage [2008/04/21(月) 20:44:13 ID:RVUuTgSY]
- どこらへんが向いてると思うの？
バッファからあふれた分は上書きされるわけだが・・・
- 106 名前：名前は開発中のものです。 [2008/05/05(月) 11:03:20 ID:RRXW9Hmv]
- 結局タスクシステムって良いプログラム？？それとも悪いプログラム？？
- 107 名前：名前は開発中のものです。 mailto:sage [2008/05/05(月) 16:01:08 ID:h5LjEvcu]
- 普通のプログラム
このボケを期待してたんだろうけど若い人はこのネタ知らないよ。
欽どんと欽どこのどっちだったかな。
- 108 名前：名前は開発中のものです。 mailto:sage [2008/05/05(月) 16:01:33 ID:/b4BEf3P]
- 適材適所
なんでもタスクシステムで済まそうとすると苦労する
- 109 名前：名前は開発中のものです。 mailto:sage [2008/05/05(月) 18:20:31 ID:mspxDfm7]
- この絵は良い絵ですか？悪い絵ですか？
- 110 名前：名前は開発中のものです。 mailto:sage [2008/05/23(金) 05:11:37 ID:urjZe250]
- もーやだ
普通に逐次処理で書いて並列的な仕事はスレッドっぽい何かでやりたい
ゴリゴリとタスクとやらで状態マシン書いていけるお前らはすげーよ
俺は頭悪いから無理。forループ相当のことやるだけでも混乱する
- 111 名前：名前は開発中のものです。 mailto:sage [2008/05/24(土) 21:14:24 ID:MJp3dmaD]
- >>110
普通に考えてスレッド同士の関連の処理考えるだけで頭痛いじゃん
分けたからどうだってのよ？
結局
主人公：スレッドNo１
敵A：スレッドNo2
障害物A：スレッドNo３
ってなったら、例えスレッドに分けたとしても
関連時にスレッドNo１ｘスレッドNo２ｘスレッドNo3のステータス分の
対応表ができることはかわらんがな
言ってることわかる？
つまり、スレッドごとにステータスが３つ（仮に状態○、△、□とする）あったら
敵A○ 敵A△ 敵A□
主人公○ STA STB STC
主人公△ STC STC STA
主人公□ X X X
敵A○ 敵A△ 敵A□
障害物○ STA STB STC
障害物△ STC STC STA
障害物□ X X X
主人公ｘ障害物省略
STA ステータスA
STB ステータスB
X なにもおきない
とか必要になるってわかるだろ？
- 112 名前：名前は開発中のものです。 [2008/05/25(日) 00:58:28 ID:6V9YbMCv]
- >>111
タスクシステムとやらを使っても
全部処理しなければならないというのは一緒なんだろ
ならどっちでもいいじゃないか、状態遷移の話をしているのか?
- 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; }
|
 |
