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

1 名前：名前は開発中のものです。 mailto:sage [2007/12/04(火) 04:51:53 ID:bGSXJYb0] タスクシステムについての議論、相談、質問、雑談などのスレです 前スレ　pc11.2ch.net/test/read.cgi/gamedev/1173708588/ 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で語ってるだけの人間。 �A3Dが苦手。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] 毎度必ず、連続投稿の最後にポエムつけてくるよなｗ 214 名前：名前は開発中のものです。 mailto:sage [2008/06/01(日) 17:47:28 ID:uh0F8OUP] 最終解脱者の私はHSPこそ絶対にして至高だと確信する タマネギ狂信者だが、それでも構わないかね？ 215 名前：名前は開発中のものです。 mailto:sage [2008/06/01(日) 17:49:26 ID:Vobw4BHh] 好きにしろ 日本国憲法で宗教の自由は認められている 216 名前：名前は開発中のものです。 mailto:sage [2008/06/01(日) 17:59:55 ID:K8JTnWL1] >>214 HSPとタスクシステムは直接関係ないからＯＫ 217 名前：名前は開発中のものです。 mailto:sage [2008/06/01(日) 19:12:10 ID://w8HXJr] なにこの流れｗ 「タスクシステム信者」なんて都市伝説ですよ >>212 >単純明快で使いやすい代替システムをまとめた講座サイトを作ってくれないかな 他人任せなのはどうかと思うが、「単純明快で使いやすい代替システム」については同意です ここがその提案の場で良いのでは？ 218 名前：名前は開発中のものです。 mailto:sage [2008/06/01(日) 19:14:10 ID:rH1ss0D0] >>208 だからさー 擬似タスク使う意味がないっての なんのために擬似タスク使うの？ 何が楽になる？ 具体的に書いてよ ぶっちゃけ、なんにも役に立ってないでしょ？ 219 名前：名前は開発中のものです。 mailto:sage [2008/06/01(日) 19:27:29 ID://w8HXJr] >>218はＣ＋＋禁止プロジェクトでゲーム作る時もタスク使わないの？ 俺はＣ縛りの場合はタスクは便利だと思うし、 それはつまり、実装（関数ポインタを使うか仮想関数を使うか、構造体を使うかクラスを使うか）は どうあれ、設計的には一理あるものだと思うんだけども 220 名前：名前は開発中のものです。 mailto:sage [2008/06/01(日) 19:47:12 ID:nqxXsx94] >>213 私が以前ここでカキコんだのは昨年クリスマス前あたりだから たぶん人違いだ 「恐るべき子供たち」で検索してヒットすればきっとそれ 221 名前：名前は開発中のものです。 mailto:sage [2008/06/01(日) 19:51:40 ID:nqxXsx94] あとSTGスレで富豪理論を展開してつまみ出されてるくらいだな ID違うのは今帰宅中の電車の中だからだ。すまんの。じゃあの 222 名前：名前は開発中のものです。 mailto:sage [2008/06/01(日) 19:58:03 ID:A9oINGs6] >>218 何度も書いてるだろ。「特に変わらない」って。所詮ただの手段なんだし。 少なくとも、他の手段に比べて特に複雑になったり、「影響が広範囲に及」んだりって ことはないよ。「タスクごとに記述を分ける」のがタスクシステムなんだから。 あと、俺が使ったのは、「会社で使ってたから」だよ。 言語がC++だから、いわゆる「古典的タスクシステム」とは違うかもしれんが。 いい加減、話を逸らすのはやめて、 タスクシステムだと使えない「有益なパターン」ってのを教えてよ。 なぜ、わざわざ議論を長引かせようとするんだ？ 223 名前：名前は開発中のものです。 mailto:sage [2008/06/01(日) 20:11:10 ID://w8HXJr] >>222 なんか>>218には「タスクを使う人間」に対する強い憎しみを感じるよね・・・ まー会社かなんかで色々あったんだろうけど 「影響が広範囲」ってのは十分にカプセル化されてなかったりが原因だと思うけど、本質的な問題とは思えないなあ 結局運用の問題であって、同じナイフでも使う人間によって役にも立てば凶器にもなる、みたいな 224 名前：名前は開発中のものです。 mailto:sage [2008/06/01(日) 20:17:47 ID://w8HXJr] あ、もちろん安全鋏でまかなえることは安全鋏を使う方がいいと思う なんでもできるナイフを全員が持つ時代でないのは確か 225 名前：199 mailto:sage [2008/06/01(日) 20:59:26 ID:I+z4oIpe] >>202 >変更と追加はまったく違う >CommandやStateのメリットですらない ごめん主語つけてくれんと意味分かんない。 >>207 俺も分からんから教えてほしいんだけど。 具体例を示してもらわんと議論し難いしね。 あと218で聞き返す前に自分への問いに答えるべきじゃないの？ >>209-211 Zソートと近いね。リンクリスト構造になっているタスクを使うのは適切でしょ？ また、深度バッファとか210の文を見ると、3D表示での話をしたいのかなと思ったんだけど、 Zバッファ可能な3D描画デバイスではZ値そのものを表示順位として使えるから、 この表示部にわざわざタスクシステムを使う必要は無いけどね。 ただ半透明だとか、内部処理の実行順の制御にはタスクシステムは使えると思う。 3Dだとシーングラフ的な構造に近くなるのかも知れんけど。 あとさ、「要素内のプライオリティ変数」とかいうのを勝手に幻想して毛嫌いしてるのそっちじゃない？ 226 名前：名前は開発中のものです。 mailto:sage [2008/06/01(日) 21:17:24 ID:uTWu7ixX] 別に自分の作りたいように作ればいいじゃない 227 名前：名前は開発中のものです。 mailto:sage [2008/06/01(日) 21:30:53 ID:rH1ss0D0] >>222 なんだよ じゃ、バグ増やして遊んでるだけかよ 仕事しろよｗ >>225 あんまり、突っ込みたくないけど お前のは他の誰とも違うと思うよｗ なんかズレてる 228 名前：名前は開発中のものです。 mailto:sage [2008/06/01(日) 21:46:12 ID:DrvtIKA9] 議論するのも無駄に思えてきた ゲーム脳と同じで 論文もなしに根拠のない本を書いて金稼いで 公演開いて金稼いで 信じている連中は考えることを放棄している それでいいかもな 結晶に話しかけるときれいになるよ 宇宙人と会ったことあるよ マイナスイオンはすごいよ ゲルマニウムパワーだよ 229 名前：名前は開発中のものです。 mailto:sage [2008/06/01(日) 21:52:09 ID:DrvtIKA9] >>225 おまえが3Dを全く理解していなくて 知ってる言葉を並べているだけということはわかった 230 名前：名前は開発中のものです。 mailto:sage [2008/06/01(日) 21:55:10 ID:rH1ss0D0] >>228 でも、世の中の９３％ぐらいはそんなもんだぞ 論文なんて正しい間違ってるのジャッジなんて まったく同じ研究をもう一度誰かがやってジャッジするか 頭でシミュでもして擬似的に想像するぐれーしかないんだから まあ、言ったもん勝ちって面はあるだろうな 231 名前：名前は開発中のものです。 mailto:sage [2008/06/01(日) 21:59:45 ID:DrvtIKA9] >>230 有害だとわかっているのにうまく説明できない 批判しようとしても悪魔の証明を求められる しかもシステムの知識が浅い人ばかりなので、まわりくどく説明しなければならない このもどかしさ、この理不尽さ でも死滅させないと、信者が増殖してますますおかしなことになる 俺にはもうどうすることもできない …… …… …… たまにはタスクシステムもいいよね 232 名前：名前は開発中のものです。 mailto:sage [2008/06/01(日) 22:03:01 ID:rH1ss0D0] >>231 無理でしょ？ どっちが正しいかなんて判断できんの？ 233 名前：名前は開発中のものです。 mailto:sage [2008/06/01(日) 22:24:32 ID:DrvtIKA9] >>232 無理 宇宙人がいるかどうか問われても いるともいないとも言えない、調べる術がないから それに宇宙人がいないことを証明しろと言われても無理 だからといって宇宙人は存在するんだといわれても それは肯定するわけにはいかない 宇宙人の存在を肯定している人が宇宙人を連れてくるべきだと思う タスクシステムについても同じ タスクシステムを使うメリットがなんであるのかはっきり言うべきだろう それがないのに、タスクシステムのメリットがないことの証明を 俺に求めてくるのはフェアじゃない タスクシステム信者は卑怯者だ 234 名前：名前は開発中のものです。 mailto:sage [2008/06/01(日) 22:30:29 ID:2ljWYPOW] スレが進んでいるから何かと思ったら… 何ヶ月か毎に似たようなこと繰り返すよね、このスレ。 それにしてもID紅い奴多すぎだろう。 235 名前：名前は開発中のものです。 mailto:sage [2008/06/01(日) 22:32:09 ID://w8HXJr] rH1ss0D0とDrvtIKA9は同一人物かと思ってたわ 二人ともなんか言ってることが子供っぽいよ タスクが有害な理由はいくらでも思いつくし、有益な理由もいくつか思いつく 多分、あと１０年もすると中心的な世代が入れ替わり、 欧米的な設計手法ばかりになってタスクは嫌でも消えていくと思う だから、そんな風に汚い言葉で煽ったり非難する必要なんかない あなた方が理想論者で世の中を自分の思っている方に変えたいと考えてるのは分かったけど 俺にとっては目の前にタスクを使う先輩方がいるっていう現実が問題であるわけで、 彼らが引退するまで増大し続ける要求に対して古き良きタスクで頑張り続けることは到底不可能だから、 前に進むためには、そうやってただ気持ちよく批判して否定してても仕方ないんよ どうやって彼らを懐柔して、いかにも「タスクいいっすよねー、使ってますよー」という顔をしながら 実際には本来のタスクとは根本を異にする欧米流の設計手法にすりかえていき、 安全で品質の良いコーディングをしていくかってことが大事なんよ

---

---

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

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