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

タスクシステム総合ス ..

2:名前は開発中のものです。
07/12/04 04:54:13 bGSXJYb0
White Paper - Programming
URLﾘﾝｸ(homepage3.nifty.com)

タスクシステム
URLﾘﾝｸ(www5f.biglobe.ne.jp)

CodeZine：本格的なシューティングゲームを実現するタスクシステム（タスクシステム，シューティング，ゲーム）
URLﾘﾝｸ(codezine.jp)

いまどきのタスクシステムの実装
URLﾘﾝｸ(omoikane.my-sv.net)

ゲーム・ノ・シクミ第11回 C++によるタスクシステムの実現
今は無き C MAGAZINE 2006年1月号
URLﾘﾝｸ(www.cmagazine.jp)

3:名前は開発中のものです。
07/12/04 17:53:51 3YteMgDl
Logician Lord　…　【コンピュータゲームのからくり】
※ウェブアーカイブのキャッシュ
URLﾘﾝｸ(web.archive.org)

ウェブでタスクとかタスクシステムについてまとまった情報を提供したのは
このページが初めてだったのだが、残念なことに既に消滅してしまっている。
このページが登場する以前はgoogleで「タスク|タスクシステム」等で検索しても
ゲームプログラミング関連のページはひとつもひっかからなかった

当然ながら、Cマガにおいてド素人さんのタスクシステム紹介記事が載る前の話な

4:名前は開発中のものです。
07/12/04 18:00:24 3YteMgDl
4 ：名前は開発中のものです。：2007/03/13(火) 01:05:48 ID:lSPAnQVN
暇だったんで書いてみた。添削できる人がいたらよろしく。

タスク

プロセス・スレッド・ファイバなど実行パスの総称。
この用語はシステムによって異なるものを指すため、動作システムを明らかに
するか、「実行する何か」といった抽象的な意味でのみ使うことが推奨される。

古典タスク (別名: ファイバ/軽量スレッド/マイクロスレッド/ノンプリエンプティブスレッド)

→ファイバの項を参照

ただし、ゲームのプロセス管理システムとして実装されたものは、コンテキストスイッチの他に
優先順位や実行順序のソートなど各種管理機能を備えたものが通常である。

擬似タスク (別名: 関数ポインタリスト)

関数ポインタ・クラス・(関数ポインタを持った)構造体などをリストで繋いだもの。
古典タスクの機能のうち個々のタスクをリストで繋ぐ部分のみを継承したものと思われる。
データ構造にツリーや配列などの変種がある。一部のゲームプログラマのローカル用語。

注: Winedows3.1等の擬似マルチタスクとは関数のリターンが必要なところは同じであるが、
コンテキストスイッチが伴わないところが異なるため、同じものとは言い難い。

5:名前は開発中のものです。
07/12/04 18:01:49 3YteMgDl
5 ：名前は開発中のものです。：2007/03/13(火) 01:06:36 ID:lSPAnQVN
プロセス[Process]

→Wikipedia項目ﾘﾝｸ

注: 組み込み業界ではプロセスをタスクと呼ぶ慣習がある。
ゲーム業界は組み込みに近いシステムから同時代のPC並のものまで主流なシステムが
増えたため、異なる方面のエンジニアが交じり合い用語の混乱を招いていると思われる。

スレッド[Thread] (別名: ライトウェイトプロセス/プリエンプティブスレッド)

→Wikipedia項目ﾘﾝｸ

ファイバ[Fiber] (別名: 古典タスク/軽量スレッド/マイクロスレッド/ノンプリエンプティブスレッド)

軽量スレッドとも呼ばれる。並列的な記述が可能だが、スレッドで必要な
ロックが必要ない点がメリットである。コンテキストスイッチをOSではなく
アプリケーションが明示的に行うスレッド。WindowsではCreateFiber()で作成できる。

6:名前は開発中のものです。
07/12/04 22:58:33 IISCFTco
普通のゲームプログラムとアルゴリズムは変わらない。
ただASM臭い実装を好むという嗜好に過ぎない。

7:名前は開発中のものです。
07/12/05 01:23:10 KjVlOJvV
【タスクシステム狂信者のバイブル】
■松浦本
シューティングゲームアルゴリズムマニアックス
URLﾘﾝｸ(www.sbcr.jp)

アクションゲームアルゴリズムマニアックス
URLﾘﾝｸ(www.sbcr.jp)
シューティングゲームプログラミング
URLﾘﾝｸ(www.sbcr.jp)

　タスクシステム厨が信奉する松浦教祖の本

■やね本
Windowsプロフェッショナルゲームプログラミング１、２
URLﾘﾝｸ(www.shuwasystem.co.jp)
URLﾘﾝｸ(www.shuwasystem.co.jp)

　BM98の中の人の本。残念なことに絶版

■逆引き本
逆引きタスクシステム
URLﾘﾝｸ(www.shuwasystem.co.jp)

　タスクシステム厨の書いた本

8:名前は開発中のものです。
07/12/05 01:29:22 KjVlOJvV
【タスクシステム厨が読むべき不朽の名著】
■shi3z本
Direct3D プログラミングガイドブック
URLﾘﾝｸ(www.seshop.com)

　3Dエヴァンジェリストの本。嬉しいことに在庫あり

■山崎本
ゲームプログラマになる本
URLﾘﾝｸ(www.cqpub.co.jp)
めざせゲームプログラマ
URLﾘﾝｸ(www.cqpub.co.jp)
　
　日本におけるメガデモ第一人者の本。残念なことに絶版

9:名前は開発中のものです。
07/12/05 08:00:47 Lh4sjdD/
↑に古臭い本が紹介されてるけど、これ使えるの？

10:名前は開発中のものです。
07/12/05 11:36:59 Jvl1n8OM
>>9
わからん。が、期待は禁物。正直、目次からはそんな感じはしないなぁ。
大学とかで見たら、立ち読みして見れ。

11:名前は開発中のものです。
07/12/05 12:10:18 Isze4xKb
>>8
最後の二つはURLが逆？
めざせゲームプログラマは持ってます

12:名前は開発中のものです。
07/12/05 12:54:53 +KnvWAen
絶版なっているやつ
誰かスキャンしてpdfで公開してくれ

13:名前は開発中のものです。
07/12/05 22:59:09 Ng0dTUw2
>>8
＞ゲームプログラマになる本
＞URLﾘﾝｸ(www.cqpub.co.jp)

昔かって殆ど読んでないが持ってた、表紙見て思い出した
早速読んでみよう

14:名前は開発中のものです。
07/12/05 23:25:55 A6jH8VGj
タスクシステムが理解できなければ、職業ゲームプログラマになれないんでしょうか？

15:名前は開発中のものです。
07/12/05 23:28:17 VOAxOcjQ
YES.
使う使わないは別にして、この程度も理解できないような頭では、
プログラミングを職業にすることはあきらめた方がいい。

が、プログラマというのは所詮未来無きＩＴ土方であって、
理解できずにあきらめた方が出世できる、とも言える。

16:名前は開発中のものです。
07/12/05 23:50:00 Jvl1n8OM
>>15
それは・・・微妙に問題を摩り替えてる気もする。
プログラマでも、コーディング猿ならともかく
色々とやる人間はどこでも働き口見つけられるし、
そういういみで、より出世しやすいだろ。

問題は、プログラ"ム"しかできないプログラマがダメなだけ。
会話や交渉、人の扱い・金の計算などなど、ちょっとした事でも
それらができれば、単純なプログラマよりも幅広い選択と未来がある。
Sヨが精々な人も同様に、それほど未来がないしねｗ

17:名前は開発中のものです。
07/12/05 23:52:53 rqZWEfda
そんな御託は会社説明会で偉そうにぶっとけ。

18:名前は開発中のものです。
07/12/06 00:35:26 5WVY/F2x
ゲームにハマっている間に1000いってたので、500レス一気読み

441からのネタに対するひとつのソースがあったけど、今更だな。

>　【１．タスクシステム＝Logician Lordで紹介されているもののことだよ】
>　　　　　　　　　　　ギャラクシアンとその直系に見られる特徴的な実装こそタスクシステムであり
>　　　　　　　　　　　その要件を満たさない異形のコードは全て紛い物だ。タスクシステムとか名乗るな
>　　　　　　　　　　　
>　【２．タスクシステム＝リスト巡回UPDATE。ていうかforeachだよ。】
>　　　　　　　　　　　ギャラクシアンのそれとは全く別物の、異形のコードであろうとも
>　　　　　　　　　　　俺がタスクシステムって呼べばタスクシステムなんだいバーロー

最後のこれいいな。俺はまさに２だ。
ゲームでオブジェクトの動作に使われている巡回UPDATE＝タスクシステム

19:名前は開発中のものです。
07/12/06 00:41:53 2ewBanaL
>>16
そんなこといったってプログラム組めると知られたら
一生プログラム組まされるにきまってるだろ？
実はどこの現場でもプログラマいねーんだ
でもだからっつってプログラマの給料が高いわけじゃない

そんなたけーなら開発やめるor別のプログラマ探す。以上

ってだけ
最近、ゲーム以外の現場でもこんな感じ
めっちゃやる気ない。後継者不足で中小企業がつぶれたりしてるしね
っていうのは世界の労働力が大暴落してんだよね
中国とかインドとか発展してきてるしね（つまり○投げ）
んなもんで今後さらに苦しくなることが予想されるし
そんなの実力云々でどうのこうのできるはずもないのであきらめが肝心

まあ、日本の人件費で物作るのがそもそも割りにあってないっていうかそんなん
いまからプログラマになんてなろうと考えちゃ駄目だよ。これはマジで

20:名前は開発中のものです。
07/12/06 00:48:20 5WVY/F2x
あと>2の
>いまどきのタスクシステムの実装
>URLﾘﾝｸ(omoikane.my-sv.net)
>ゲーム・ノ・シクミ第11回 C++によるタスクシステムの実現
>今は無き C MAGAZINE 2006年1月号
>URLﾘﾝｸ(www.cmagazine.jp)
この２つはもう要らなかったんじゃね？

追加で

関連スレ
ゲームにおけるデータ構造・クラス設計・パターン
ｽﾚﾘﾝｸ(gamedev板)

C++ と今時のハードウェアでやる古典タスクシステムに替わるもの
URLﾘﾝｸ(www.issei.org)

21:名前は開発中のものです。
07/12/06 00:50:33 AhaNCitW
↑派遣って自分の身の回りしか見えてないのか。
そうなるとインドや中国云々も世間で言ってることの受け売りだろう。

アウトソーシングで倹約できる分野の仕事に付いたら終わりかもしれないが
できない分野のプログラマもいるんだよ。

22:名前は開発中のものです。
07/12/06 03:19:35 HdWZc6ta
ていうか解釈広くとっておかないとこのスレの意味がなくなるような
まあデータ構造スレへいけばいいだけのはなしなんだけどね

23:名前は開発中のものです。
07/12/06 06:11:52 UqqGAKZG
自分のこだわり

１、ゲームループはシーンごとに別にする
例えばRPGで移動シーンと戦闘シーンがある場合、
移動時は移動ループに入り、戦闘時は戦闘ループに入る。
お互いにまったく別の処理をするので、
お互いが見えない方がソースを簡潔に書ける。
データの受け渡しは、2つの元の関数(mainなど)から引数で渡す。

２、ゲームループにはウィンドウメッセージループ(GetMessage)を使う
タイトル画面など自動的な処理する必要がない時は
ループを回さないでCPU率を軽くする。
再描画やキー入力などに備えておくだけ。
アクションなどの場合はTimeBegin系を使う。

24:名前は開発中のものです。
07/12/06 08:20:05 AhaNCitW
俺から見たら嫌な作りだね。
ゲームのメイン部分では、メッセージループでどんなAPIを使うかなど思考の埒外にしたいね。
Direct3Dのデバイスのリセットやメッセージループがあちこちに散らばるなんて
デバッグで面倒が増えるだけだ。

25:名前は開発中のものです。
07/12/06 08:22:16 2ewBanaL
>>21
その場合、開発をやめてしまったり潰れてしまう会社が多い
人材倒産っていうんだとさ

26:名前は開発中のものです。
07/12/06 09:05:59 aorsrR2s
>>23
ないわ

27:名前は開発中のものです。
07/12/08 01:44:04 CYfUYGS1
>>24
始めはシーンごとにコールバック関数を作っていたが、
グローバル変数やstatic変数を使いたくないので、
メッセージループ(の中にコードを書く)を複数作るようになった。

DirectXは使っていないのでよく分からないが、
デバッグは現在のシーンのコールバックかメッセージループ
を調べるだけなので分かりやすい気もする。

28:名前は開発中のものです。
07/12/08 05:37:29 l8AiqE/q
これが同人ソフトだとしたら
タイトル画面が魅力的になるようにキャラを動かしたりアニメさせましょうと提案されても
「CPU使用率が上がるから駄目」「そういう構造になってないから駄目」と拒否するのか
だっさｗｗｗｗ

29:名前は開発中のものです。
07/12/08 05:40:49 cj/l/sA4
>>23
まぁ、mine sweeper 作るならアリかなぁ。

30:名前は開発中のものです。
07/12/08 07:28:22 CYfUYGS1
>>28
一般的に派手な動きは少ないシーンという意味で使った。
だからコンフィグシーンなどでもいい。

それとキャラをアニメさせたとしても、
OSに処理を返すとかをしっかりやれば重くならないと思う。
自分のレベルは昔の横シューティングぐらいで、
ホームページのフラッシュアニメレベルだとそうなりそう。

>>29
逆にロープレとか
シーンの種類の多いゲームの方が向いている気がする。

31:名前は開発中のものです。
07/12/08 13:14:00 /PKo7xok
// たすくしすてむ

foreach(ball b in balls)
{
　　b.update();
　　b.paint();
}

32:名前は開発中のものです。
07/12/08 15:37:53 dpKOt0nT
>>30
シーンの切り替えでクロスフェード等を使う場合はどうするの？
かならずフェードアウト／イン(もしくは一瞬)？

ドラクエみたいに、フィールドの上で戦闘やショップの処理、
ステータス表示なんかを行いたい場合とかもどうするのか気になる。

33:名前は開発中のものです。
07/12/09 05:57:18 fYOmZnNF
>>32
クロスフェードというのは音楽のなんかみたいだがよくわからない。

ドラクエはショップを例にすると、
店の処理をポップアップ子ウィンドウを出して行う。
ドラクエの黒塗りのウィンドウがホントのウィンドウになる感じ。

店に入る時に、所持金、商品、所持アイテムなどのデータは受け取るが、
店には関係ない、主人公がどこにいるか、NPCがどこにいるかなどは、
まったく関係ない(コードに触れない)状態になっている。
もちろんデータは取って置いてあって、
店ループを抜けフィールドループに戻ると触れるようになる。

親ウィンドウメッセージが来たなら、店シーンに入る時に
保存しておいたメモリビットマップを使っての再描画、
閉じる(プログラム終了)、デフォ処理のみ行う。

子ウィンドウメッセージが来たなら、
キー、マウスによるカーソルの移動、決定、キャンセル、
WM_TIMERによるカーソルの点滅、
再描画、閉じる(店シーンの終了)、デフォ処理などを行う。

シーン切替えの説明にはなっていない気がするが、大本の違いは
if(g_scene == SceneField) **
else if(g_scene == SceneShop) **
のチェックを、よくあるやり方の場合、1ループ毎に行っていると思うが、
シーンを切り替える場合は、一度チェックしたら
**の所で別のゲームループまたはコールバックに入ってしまうので、
そのシーンから抜けるまでシーンのチェックは行わない。

34:名前は開発中のものです。
07/12/09 06:57:29 fYOmZnNF
お店のシーン(ゲームループ、コールバック)にも複数あって、
買う売る出るの選択、買う物の選択、売る物の選択、
誰が買うかの選択、「○○を買った」と表示し、
キー入力があるまで待つシーンなどがある。

お店だけでもシーンがたくさんあり、
シーンごとに分けるとコードが膨大になり、たしかにめんどくさい。

ただ、買う売る出るの選択、買う物の選択、誰が買うかの選択などは
文字列を選択するという共通の処理なので、個別にシーンを作るのでなく、
ひとつの文字列選択シーンを作り、使いまわしている。
そのシーンでは、どの位置の文字列を選択したかのみをチェックし、
そのシーンを抜けた後で、お金が足りているかなどのチェックをする。

「○○を買った」と待つのも、「扉を開けた」、「○○を手に入れた」
などと同じキー入力があるまで待つという共通の処理なので、
ひとつの待つシーンを作り、使いまわしている。

35:名前は開発中のものです。
07/12/09 07:20:28 nQCm/lvH
誰もが普通に使うような技法や、誰もわざわざやろうとしない技法に特別な名前を付けて、
俺様天才！俺様スゲーーーー！！！

というのがタスクシステムの本質だとすれば、きっとスレ違いではないのだろうな。

36:名前は開発中のものです。
07/12/09 09:00:37 fYOmZnNF
>>35
確かに自分のやり方以外のやり方はあまり知らないので、
他のやり方と比べた客観的な説明にはなっていないのかも。
出直してきます。

37:名前は開発中のものです。
07/12/09 19:28:44 Lzb0B9+Z
>>33
クロスフェードってのは、元の場面をフェードアウトしつつ、新しい場面をフェードインすること。
ゲームの場合だと、元のシーンを後ろで動かしつつ、新しいシーンの描画のアルファ値を
上げていって切り替える感じかな。
計算や描画の重さもあるから、「前のシーンを動かしつつ」ってのは難しいかもしれんが。

シーン管理の方法は大体理解した。
ゲームのロジックの中にWindows独自のルールが平然と出てくるのは気になるが、
その辺割り切って作るならいいんじゃないかな。

38:名前は開発中のものです。
07/12/09 20:16:34 QBlb02fM
いまのマシンってワンシーンで限界まで性能ださないからロードさえ気をつければ
クロスフェード（２シーン分）ぐらいなら普通にいけると思うよ
PS２とかじゃ苦しいけど

39:名前は開発中のものです。
07/12/09 20:24:41 RxPCFRcK
>>38
> PS２とかじゃ苦しいけど
あれは性能より VRAM が…

40:名前は開発中のものです。
07/12/09 20:25:58 RxPCFRcK
>>34
アニメーションはどうするの？　ドラクエだと敵が動いたり、攻撃時にエフェクトが
出るような場合。

41:名前は開発中のものです。
07/12/09 20:38:58 QBlb02fM
複数のシーンを絡ませて管理する機能が必要なんだから
シーン同士を管理するシーンマネージャーを作ればいいだけの話じゃねぇの？
シーン間を飛び越えてマップやキャラのデータが存在し続けるんなら
キャラやマップはシーンに属さないっていうかシーンが抱えるべき情報ではない
つまりシーンの前処理後処理でロードアンロードされないわけだな
じゃ、誰がするのかというとさっき用意したシーンマネージャーが管理するわけだ
シーン間を接続する役目もシーン間が絡む以上シーンマネージャの仕事だろう
シーンクラスの役目は今の情報・状態から自分の表示・実行に必要なデータをシーンマネージャに
返す機能だけになるんじゃね？
それをうけてシーンマネージャは複数のシーンを総合的にみて現在必要なデータを搾り出すと
シーンマネージャに当たるもんは結構でかくなるぜ
これをシーンごとに頑張って管理しようとするとデスマーチ確定

42:名前は開発中のものです。
07/12/09 23:12:03 rwPHbHKr
>>23
> １、ゲームループはシーンごとに別にする
つまりタスクシステムだね
タスクを入れ替えることで違うシーンに対して別のループを提供できる
もしタスクシステムを使わなければシーンの数だけほぼ同じソースを別個に書かなければならない
1箇所ソースを変更するだけでそれらのシーンすべてのループを書き換えることになりメンテナンス性が著しく落ちる

> 例えばRPGで移動シーンと戦闘シーンがある場合、
> 移動時は移動ループに入り、戦闘時は戦闘ループに入る。
戦闘タスクと移動タスクを入れ替えるってことだね

> お互いにまったく別の処理をするので、
> お互いが見えない方がソースを簡潔に書ける。
そう、タスクシステムではタスク単位で完結するから独立性が高い記述が可能になる

> ２、ゲームループにはウィンドウメッセージループ(GetMessage)を使う
CPU使用率を稼げるし、仮に必要になっても多少のループならタイマーで十分だよね

> タイトル画面など自動的な処理する必要がない時は
> ループを回さないでCPU率を軽くする。
タスクシステムを使えばシーンごとにまったく違う処理が書けるから
シーンごとに違うメインループを書くことも可能なんだよね
仮にオープニングでアニメーションやデモを追加したい場合
タスクを入れ替えることで対応可能

43:名前は開発中のものです。
07/12/09 23:19:22 rwPHbHKr
>>24
タスクシステムを使えばそれらは一箇所に記述するだけでいい
重複した記述を最小限にできるタスクシステムはデバッグにも役立つ

>>27
限りなく正解に近い
タスクシステムとはコールバック進化系の一種だ
コールバックされる関数を制御する仕組みが追加されたものがタスクシステムなのだ

44:名前は開発中のものです。
07/12/10 00:12:04 kVa9UCh4
何が「限りなく正解に近い」だ、このおっぱい占い野郎
「コールバック進化系」とか無駄にESP値を要求する造語を散りばめんな

コールバック＝何かをきっかけに呼び出される
それだけだ。これの進化系ってどういうことだ。具体的に何に対して何が進化したんだ

45:名前は開発中のものです。
07/12/10 00:17:12 FgTvF4nS
また面白い燃料が投下されたようですね

46:名前は開発中のものです。
07/12/10 01:07:39 AFViqWGu
> > １、ゲームループはシーンごとに別にする
> つまりタスクシステムだね

この時点で釣りとしか思えない。

47:名前は開発中のものです。
07/12/10 08:12:39 oZKWD7tz
店なんか床に商品並べて店番一人置いておけばループ分けなど不要

48:名前は開発中のものです。
07/12/10 11:26:27 4KeM6Lnp
シーンって何よ？
言葉の定義なくして話進められても？？だぜ

49:名前は開発中のものです。
07/12/10 13:37:22 NNHyQgcJ
また定義厨か
さすがにそれはないな

50:名前は開発中のものです。
07/12/10 16:08:36 FhEMVCWa
>>48
さてはDirect3D使ったこと無いな？

51:名前は開発中のものです。
07/12/10 17:15:59 TRJA29h8
>>48
見た感じ
・タイトル画面
・戦闘画面
・マップ移動画面
みたいなのをシーンと書いてあるだけ。

>>50
なぜ突然Direct3D・・・
(IDirect3DDeviceN::BeginScene？)

52:名前は開発中のものです。
07/12/10 18:15:58 kVa9UCh4
定義厨の俺でも
さすがに>>48はないな

53:名前は開発中のものです。
07/12/10 19:32:53 ynLW352R
ゲームをまともに作れないことが明らかな>>48の発言に、一同、シーンとなった。

54:名前は開発中のものです。
07/12/10 19:44:32 sWUDY/qD
プログラム開発現場の駄洒落は99%、発言者が死ねばいいのにという感想になる。
しかもバグの取れない苛立ちまでも一手に引き受けてな。

55:名前は開発中のものです。
07/12/11 00:04:17 T0+r8UQD
>>53
誰がシーンとなることを言えと

56:名前は開発中のものです。
07/12/11 00:53:40 ECQVp0Tr
さっきからチーンチーンチーンチーンってお前等は変態か？

57:名前は開発中のものです。
07/12/11 08:56:37 xDs0NYc0
ユビキタスとかWeb2.0とかあんな感じの電波を感じるな

58:名前は開発中のものです。
07/12/15 22:33:07 dW/LIK6y
>>44
説明しよう！

＞コールバック＝何かをきっかけに呼び出される
まさにその通りだ！！
コールバック関数とは関数ポインタを呼び出し側に登録しておき
適宜呼び出される方式だ
この方式はタスクシステムにも採用されている

タスクヘッダには初期値としてタスクエンド（Cでは大抵NULLだろう）を示すポインタが入っている
図1.タスクヘッダ → タスクエンド

ここにタスクを登録していくことで呼び出される関数が増えていく

図2.タスクヘッド → タスク1 → タスク2 → タスクエンド

こうして生成されたタスクリストのタスクはタスクループで順番に呼び出されていく

図3.タスクループ
　　　　　↓
　　　タスクヘッド → タスク1 → タスク2 → タスクエンド

以上のような構造からタスクシステムはコールバック関数であるといえる

コールバック関数に比べてタスクシステムを特徴づけているのは次の3点だ

　　1.呼び出し側と呼び出され側が1対多である
　　2.呼び出し側は機能を持たない
　　3.呼び出され側がさらに呼び出され側を登録することができる

以上の特徴により、動的に機能を拡張し、相互に連携することが可能になったのである

59:名前は開発中のものです。
07/12/16 00:14:11 tU3FXTu1
>>58
> 以上の特徴により、動的に機能を拡張し、相互に連携することが可能になったのである
単にインスタンスの数が可変なだけで、連携については何も触れてないじゃん。

60:名前は開発中のものです。
07/12/16 01:22:25 Uds4tbII
先頭をheadにするなら末尾はtailにしてくれ
末尾をendにするなら先頭はbeginかstartにしてくれ
俺が言いたいのはそれだけ

61:名前は開発中のものです。
07/12/16 01:27:07 tU3FXTu1
>>58
どうでも良いけど
> タスクヘッダには初期値としてタスクエンド（Cでは大抵NULLだろう）を示すポインタが入っている
番兵1つ置いた方が、余計な場合分けが減って嬉しくない？　
BSDで使われてる TAILQ でも、ヘッドは

#define TAILQ_HEAD(name, type) \
struct name { \
struct type *tqh_first; /* first element */ \
struct type **tqh_last; /* addr of last next element */ \
}

っつー定義だよな。

あと C++ だと昔は std::list<> 好きだったが、最近は std::vector で、フレームの最後に
まとめて std::remove_if と std::vector<>::erase 組み合わせて済ませる方向に。

62:名前は開発中のものです。
07/12/16 01:50:58 eEobSst5
>>58
タスクシステムが誕生する70年代末期よりも遥か前の
古典的なコンピュータのプログラムで既に同じようなことをやってるだろ。
例えば、割り込み信号にフックするとき、つまり割り込み処理ルーチン
（常駐プログラム・サービス）を割り込みベクタテーブルに追加するとき
既存のルーチンがあればそれと数珠繋ぎにするだろ

63:名前は開発中のものです。
07/12/16 02:16:17 eEobSst5
単純で乱暴なやり方をするなら、割り込みベクタテーブルに
既存ルーチンの代わりに自分のアドレスを上書きして
先に自分の処理を呼び出させ、自分の処理が終わったら
既存ルーチンへジャンプさせる。つまり割り込み処理に割り込む。

もう少し紳士的なやり方なら（同じ割り込み信号にフックする）
割り込み処理ルーチン同士で協定を作り
割り込み処理ルーチンのリストを管理するルーチンを用意する。

こうした仕組みは>>58の言う

　　1.呼び出し側と呼び出され側が1対多である
　　2.呼び出し側は機能を持たない
　　3.呼び出され側がさらに呼び出され側を登録することができる

を全て満たしている。

　呼び出し側＝ハードウェア
　呼び出され側＝割り込み処理ルーチン

ハードウェアは割り込み信号に応じて割り込みベクタテーブルの
当該アドレスに登録されてる割り込み処理ルーチンを呼び出す。
そしてリストに登録された順に次々呼び出される。
割り込み処理ルーチンは処理完了時のリターン命令を
他のルーチンへのジャンプ命令に書き換えることで
子ルーチンの追加が可能

64:名前は開発中のものです。
07/12/16 02:18:07 eEobSst5
紳士的なやり方なら
呼び出し側＝割り込み処理ルーチンのリスト管理プログラム、か

65:名前は開発中のものです。
07/12/17 15:54:34 d05xYvvB
意見は出したくないが文句はつけたい
そんな嫌タスク厨の巣窟だというのがわかる流れでしたね
文句つけてる暇があったら、58がかすむくらいの有益情報でも書き込めっての

66:名前は開発中のものです。
07/12/17 16:25:30 fh4AIKkl
またブーメラン芸か

67:名前は開発中のものです。
07/12/17 16:43:25 fh4AIKkl
=210.130.51.98 ヘ(　`Д)ﾉ

68:名前は開発中のものです。
07/12/17 21:14:21 PVpDrrvq
コールバック進化系（笑）スィーツ（笑）

69:名前は開発中のものです。
07/12/17 21:26:04 FK63IV8y
確かにプログラム用語の大半はスイーツ（笑）テイストを感じさせる回りくどい言い回しだな

70:名前は開発中のものです。
07/12/17 23:00:26 ZuWNJ+Fe
つまりタスクシステムは何なわけ？
わたしわかりまぁせん

71:名前は開発中のものです。
07/12/17 23:12:00 DxnpSp/c
foreach

72:名前は開発中のものです。
07/12/17 23:52:08 lVhxy2mV
ここはwhile(1);つかfor(;;);かな。最適化されてればどっちも同じだろうが。

73:名前は開発中のものです。
07/12/18 20:23:42 RgUcH/0L
1フレーム毎に（大抵）全てのオブジェクトのupdateメソッドがコールバックされるシステム

と考えていいんじゃね？

74:名前は開発中のものです。
07/12/18 23:42:42 LovnfmvP
-----------------------------------------------------------
987 ：名前は開発中のものです。：2007/12/03(月) 23:02:28 ID:hqsjjSWF
　スレのログ見ると、定期的に「タスクシステム＝デザインパターン」とか絶叫してる人がいるみたいだが
　この人たちの言うタスクシステムってどのタスクシステムの話なんだろうね？

　【１．タスクシステム＝Logician Lordで紹介されているもののことだよ】
　　　ギャラクシアンとその直系に見られる特徴的な実装こそタスクシステムであり
　　　その要件を満たさない異形のコードは全て紛い物だ。タスクシステムとか名乗るな
　　　　　　　　　　　
　【２．タスクシステム＝リスト巡回UPDATE。ていうかforeachだよ。】
　　　ギャラクシアンのそれとは全く別物の、異形のコードであろうとも
　　　俺がタスクシステムって呼べばタスクシステムなんだいバーロー
-----------------------------------------------------------

観察してると、どうもタスク厨って呼ばれてる子は後者が多いような気がしてきた。
何も知らない頭白紙の状態で松浦教祖に洗礼を受けたこの恐るべき子供たちは
タスクシステムというフレーズにとても執着してるようだが、厨房神経を刺激する
何かがあるのか？

とにかく何が何でもこのタスクシステムという古のローカル用語を俺様理論で
再定義・再構築してやろう、という無駄な努力がヒシヒシと伝わってくるんだが
ある意味で（マムコ信者に言わせれば）由緒正しいｗローカル用語をわざわざ
掘り起こしてきて流用するのは止めてくれって思う

「朕思うに」「新概念」「新解釈」「オナニー」「再構築」は好きなだけやっていいから
なんか別の名前にしろよ。「リスト巡回UPDATE」でも「僕のforeach」でも
「エターナルフォースブリザードシステム」でも何でもいいからさ

75:名前は開発中のものです。
07/12/18 23:44:17 m+PO2WK4
私はもうタスクという言葉自体を使ってない

76:名前は開発中のものです。
07/12/19 08:00:04 hUc1dbeP
ゲイは身をタスク。

77:名前は開発中のものです。
07/12/19 15:24:26 Ir64JLrB
○○システムって言い方自体、かなり厨2魂を揺さぶるフレーズだよ

78:名前は開発中のものです。
07/12/19 15:25:28 F/n53iWq
じゃあタスクパターンで

79:名前は開発中のものです。
07/12/19 20:46:55 UEhDeB5F
＞タスクパターン

「ストラテジーパターン？あー、AoEとか大戦略ってパターンだよね」
とか真顔で言ってのけるウィザード級ハッカーの心の琴線に触れる

80:名前は開発中のものです。
07/12/19 20:47:44 hUc1dbeP
じゃあ、「タスクモンスターとのアルティメットコラボレーション」で。

81:名前は開発中のものです。
07/12/20 07:20:27 c5xOqVc7
>>74
タスクシスステム改め
ギャラクシアンロジックかLogician Load Systemでおｋ

82:名前は開発中のものです。
07/12/20 20:44:20 tLt8cR7R
エロスロジック

83:名前は開発中のものです。
07/12/21 00:29:57 rVMYRhvV
オナニーシステムで通じると思うんだ
リスト巡回オナニーも分かりやすい
オナニーforeachは微妙
オナニーパターンはオナテク板で使用済み

84:名前は開発中のものです。
07/12/21 00:38:40 Jo2a6K/I
じゃ、タスクシステム関連は、PinkBBSに移動しようか。

85:名前は開発中のものです。
07/12/21 01:45:05 sZQMdwXf
僕の肛門もリスト巡回されそうです

86:名前は開発中のものです。
07/12/31 11:54:08 K8WL7pln
どうすればギャラクシアンのソースを見られますか？

87:名前は開発中のものです。
07/12/31 15:03:05 73X1rpDN
逆アセンブルすればそれがほぼソース

88:名前は開発中のものです。
07/12/31 18:29:38 K8WL7pln
>>87
ファミコン版でいいですか？

89:名前は開発中のものです。
08/01/07 06:40:49 5ateSYSb
タスクシステムこそ
ゲーム業界にのみ伝わる現代の魔術
連綿と口伝によってのみ受け継がれ
変化し、進化と退化を繰り返す
その亜流は数知れず、もはやその全てを語れるものはいない

90:名前は開発中のものです。
08/01/07 14:38:53 GyFmGIbt
都市伝説テンプレート

91:名前は開発中のものです。
08/01/14 14:54:45 qTpR8IwF
つまりはスケジューリングでおk？

92:名前は開発中のものです。
08/01/14 15:24:10 qReoD61a
少なくともスケジューリングは含まれるだろうな

93:名前は開発中のものです。
08/03/13 22:58:00 Bu/r75Um
保守

94:名前は開発中のものです。
08/04/03 17:01:08 0WE0DNgq
ゲームプログラミングで分厚い目の本選んだら
著者流タスクシステムの解説が大半で(´･ω･`) ｼｮﾎﾞｰﾝ。

95:名前は開発中のものです。
08/04/03 18:08:34 HifUC8Yv
>>94
>>7

96:名前は開発中のものです。
08/04/03 18:34:18 0WE0DNgq
逆引きタスクシステム
これだorz

97:名前は開発中のものです。
08/04/03 18:37:31 0WE0DNgq
ちょっと違ったな。
買ったのは「逆引きゲームプログラミング」って書いてあるから姉妹本かな。
表紙に堂々とタスクシステムなんて書いてあったらさすがにスルーするしねw

98:名前は開発中のものです。
08/04/06 18:50:02 cIcTAloV
Javaはポインタが使えないからイテレータ使うしかないのかな？

99:名前は開発中のものです。
08/04/06 21:07:19 RBp65Y5g
>>98
Java がポインタを使えないのは確かだが、たぶん >>98 はそれ以前の
勘違いをしている。

100:名前は開発中のものです。
08/04/06 21:09:30 ptmozDNb
ねぇぼく、すれたいよめゆ？

101:名前は開発中のものです。
08/04/06 21:24:10 hAyEqcH5
>>98にタスク厨の素質を感じた
お前たち、大事に育てなさい

102:名前は開発中のものです。
08/04/07 04:08:41 qDynBUHm
■星屑きらら杯
URLﾘﾝｸ(kirara111.sakura.ne.jp)
主催：１１１
超絶神星屑きららを迎えての史上最強コンテスト。
優勝賞金はwebマネー３万円ぶん。
今までの常識は通用しない、コードネームは・・・アンタッチャブル。

103:名前は開発中のものです。
08/04/07 16:38:25 V2Suu5FZ
ほえ

104:名前は開発中のものです。
08/04/20 10:58:52 tFc51Cra
boost::circular_bufferってタスクシステム向きだと思う

105:名前は開発中のものです。
08/04/21 20:44:13 RVUuTgSY
どこらへんが向いてると思うの？
バッファからあふれた分は上書きされるわけだが・・・

106:名前は開発中のものです。
08/05/05 11:03:20 RRXW9Hmv
結局タスクシステムって良いプログラム？？それとも悪いプログラム？？

107:名前は開発中のものです。
08/05/05 16:01:08 h5LjEvcu
普通のプログラム

このボケを期待してたんだろうけど若い人はこのネタ知らないよ。
欽どんと欽どこのどっちだったかな。

108:名前は開発中のものです。
08/05/05 16:01:33 /b4BEf3P
適材適所
なんでもタスクシステムで済まそうとすると苦労する

109:名前は開発中のものです。
08/05/05 18:20:31 mspxDfm7
この絵は良い絵ですか？悪い絵ですか？

110:名前は開発中のものです。
08/05/23 05:11:37 urjZe250
もーやだ
普通に逐次処理で書いて並列的な仕事はスレッドっぽい何かでやりたい
ゴリゴリとタスクとやらで状態マシン書いていけるお前らはすげーよ
俺は頭悪いから無理。forループ相当のことやるだけでも混乱する

111:名前は開発中のものです。
08/05/24 21:14:24 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:名前は開発中のものです。
08/05/25 00:58:28 6V9YbMCv
>>111
タスクシステムとやらを使っても
全部処理しなければならないというのは一緒なんだろ
ならどっちでもいいじゃないか、状態遷移の話をしているのか?

113:名前は開発中のものです。
08/05/25 01:06:31 6V9YbMCv
スレッド使えばこんな感じに書けるはずだが

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

タスクシステムとやらを使ったときのありえない複雑さは凡人の俺には理解できない
簡単にできるものをわざわざ複雑に書く、天才だけの思考は全く理解できんな

114:名前は開発中のものです。
08/05/25 05:25:51 dDrBARgy
>>111が何を言いたいのかはよくわからんが、
タスクシステムも>>113も、複雑さは特に変わらないように思えるけど。

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

どの辺が、>>113に比べて「ありえない複雑さ」なんだ？

115:名前は開発中のものです。
08/05/25 05:35:43 5unbeWfm
サブクラスにいちいちIF仕込んでんのかよｗ

116:名前は開発中のものです。
08/05/25 08:15:02 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:名前は開発中のものです。
08/05/25 08:40:06 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:名前は開発中のものです。
08/05/25 09:38:01 xbxgumKd
>>117
前者の方が不自然に感じる俺はどうすれば・・・

119:名前は開発中のものです。
08/05/25 10:39:48 qUO2NAd9
>>113
スレッドの生成/破棄がどれだけ高コストか分かっているのかね？

>>117
途中のフレームでやっぱり左に切り返す処理等を入れたら後者の方が
遥かにシンプルになる。

120:名前は開発中のものです。
08/05/25 10:52:41 7UG2hamH
>>112
いや、だから変わらんでしょ？って言いたかったわけよ

121:名前は開発中のものです。
08/05/25 10:57:13 7UG2hamH
あーだから、スレッドなんて作っても
根本の複雑さが問題なんであってタスクシステムなんて
してもここは変わらんよと

122:名前は開発中のものです。
08/05/25 11:08:35 K3dp7DqQ
時間かけて行う処理、広くいうと、ある条件を満たすまで待って次に進むような逐次処理
を書こうとすると>>117の言うようなストレートに記述をしたくなるのは分かる

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

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

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

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

おれなら、
前者はメッセージディスパッチャっぽく書きたい。
後者はコルーチンっぽく書きたい。
なあ。

123:名前は開発中のものです。
08/05/25 11:56:53 MyJQpRZH
結局何やっても複雑になるんだからどんな実装してもおｋ
Flashなんかも標準でタスクシステム（笑）のような仕組み持ってるんだけど、
やっぱ処理順序とかインタラクトとかみんな悩んでるお

124:名前は開発中のものです。
08/05/25 14:13:14 7UG2hamH
作るもん間違ってんじゃねぇの？
>>117みたいな処理ってスクリプトやプログラムで解決しないで
フラッシュみたいなタイムライン（？）があるビジュアル的なもんがあったほうがいいんじゃねぇの？

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

タスクシステムはあくまで全然別な独立処理をわかりやすく書くためだけのもんだろ
こいつは上記の２つの問題にはなんの解決策にもなっていねぇ
ゲームプログラムが複雑なのはオブジェクト同士の絡みだろ？

125:名前は開発中のものです。
08/05/25 14:17:00 vQVRM4Hf
>>119
あ、そうなのか？　あー、そうかも。

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

しかし・・・だまされないぞ！
イベントドリブンがしたければ別にスレッドでもできるわけで（Windowsで言うPeekMessageね）、
スレッドのコストの問題は（色々と解決方法が考えられるはずなので）ここでは無視して考えてほしいんだけど、
処理によってはタスクと同じ機構をスレッド上に構築することがあったとしても、
それが可能なことは悪いことじゃないと思わない？
それはＣ＋＋がベターＣとして使えるように、スレッドがベタータスクとして使えることだとは思わない？

126:名前は開発中のものです。
08/05/25 15:41:32 0NNJH3W1
>>122
コルーチンとかファイバーとか言うね。
少し違うけど継続(continuation)の方が知られてるかな。
スレッドは同時に走ることを期待するからこの点は違う。

そういやゲーム方面でLuaが人気あるらしいけど
コルーチンも使ってるのかな。

127:名前は開発中のものです。
08/05/25 15:43:46 dDrBARgy
我々に必要なスレッドは２つ。
メインスレッド、データ読み込みスレッド、BGM再生スレッド、この３つだ。
スクリプトでタイトル画面実装してコルーチン使う、とかならともかく、
キャラの制御なんかと同じレベルにスレッドぽこぽこ作るのは嫌だなぁ。

つか、どう実装するにしても、
ボタンによる演出スキップとか、時間経過によるデモへの移行とか、
タイトル画面程度のものでも状態遷移は考えなきゃならないと思うけど。
まあ、キャラなんかとは、複雑さは全然違うけどさ。

128:名前は開発中のものです。
08/05/25 15:55:46 7UG2hamH
何度も言うけどスレッドは状態遷移の複雑さの問題を解決しないよ

129:名前は開発中のものです。
08/05/25 16:03:27 zNY0acjC
マトリクスでも書いて整理しろよ

130:名前は開発中のものです。
08/05/25 16:43:17 vQVRM4Hf
全レスしたいけどウザがられるしとりあえず

>>128
んとですね、夢を語ってるように見えたかも知れないけどもｗ
スレッドがゲームの状態遷移の複雑さを解決すると考えているのではなく、
タイマードリブンないわゆるタスク処理というものは、
本来ローカル変数やプログラムカウンタという言語上の機能を
プログラマが自分で状態として（ワーク変数などで）管理しなくてはならないのが
負担だと思いませんかと言いたいのです

131:名前は開発中のものです。
08/05/25 17:01:19 vQVRM4Hf
あ、俺が想定してるスレッドは擬似スレッドです。コルーチン等
ＯＳが用意するプロセス／タスク／スレッドは想定してないです

132:名前は開発中のものです。
08/05/25 17:02:07 7UG2hamH
>>130
もとのレスと比べて全然いってることが違うような希ガス

133:名前は開発中のものです。
08/05/25 17:02:23 6V9YbMCv
おれも>>130と同じ事が聞きたい
話を広げて逃げないでください>天才タスカーの皆さん

134:名前は開発中のものです。
08/05/25 17:15:50 7UG2hamH
>>133
んあ？
考えてることがさっぱりわからん
ゲームプログラムで複雑なのは各オブジェクトの状態遷移であって
タスクシステム云々は問題じゃねぇから気に入った方法で好きにしろってのが
みんなの総意だろ（おそらく）

ここまででなんか違うこと言ってるならなんか言ってみ？

135:名前は開発中のものです。
08/05/25 17:22:31 6V9YbMCv
>>134
130に対する答えにはなってないな
質問の意味が理解できないのならできるだけわかりやすく解説するが、必要か?

136:名前は開発中のものです。
08/05/25 17:23:16 A+/TQh+q
>あ、俺が想定してるスレッドは擬似スレッドです。コルーチン等
最初から「マイクロスレッド」と言えば無用な混乱を避けられるぞ

137:名前は開発中のものです。
08/05/25 17:23:43 vQVRM4Hf
>>134
ですよねー

すんません、でかけてきます

138:名前は開発中のものです。
08/05/25 18:00:32 xbxgumKd
ゲームプログラムからそれを取ったら後は何が残るんだ？

139:名前は開発中のものです。
08/05/25 18:10:01 dDrBARgy
>>113 の if の羅列は状態ごとの処理の振り分けじゃなかったのか。

140:名前は開発中のものです。
08/05/25 18:24:49 6V9YbMCv
>>139
状態ごとの処理の振り分けが何を指すのかわからないけど
マイクロスレッドと状態遷移のトレードオフとして

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

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

それよりも、スレッドを用いて
while (true)
{
赤(); sleep(?);
黄(); sleep(?);
青(); sleep(?);
}
の方が直感的で読みやすいでしょという意味で書いたつもり。

141:名前は開発中のものです。
08/05/25 18:38:09 A+/TQh+q
青→黄→赤と遷移するんだろう？
さっそくバグを仕込んでいるじゃないか

142:名前は開発中のものです。
08/05/25 18:52:00 6V9YbMCv
GOFパターンで言うと
タスクシステムとやらがStateのCommandをListに突っ込んだものなら
Stateのメリットは拡張性にあって可読性にはないから
可読性を優先するならマイクロスレッドの形を取るべきだ
と言いたいわけだ。

ところが天才タスカーはタスクシステムを使えば簡単になるよとしか言わない
可読性が低下するというデメリットにも触れない、又は理解していない
そう見える

143:名前は開発中のものです。
08/05/25 19:34:28 dDrBARgy
>>140
？　ごめん。>>113 をどう読んでも、そうは解釈できんわ。
……まあ、>>140として、
それだと、他から状態を変えたりしにくいし、
仕様変更への対応も大変じゃないか？
仕様が確定していて絶対変わらないというのならいいけど。

>>142
「簡単になる」とは誰も言ってないよ。
そもそも「すべての場合でタスクシステムを使え」とも言ってない。
（実装方法そのものが本質ではないから）状態遷移の複雑さに応じて、
自分のやりやすい方法でやれと、みんな言ってると思うんだが。
何か変な思い込みが議論を阻害してる気がするな。

次ページ