タスクシステム総合スレ 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/
2 名前：名前は開発中のものです。 mailto:sage [2007/12/04(火) 04:54:13 ID:bGSXJYb0]: White Paper - Programming
homepage3.nifty.com/moha/programming.html

タスクシステム
www5f.biglobe.ne.jp/~kenmo/program/task/task.html

CodeZine：本格的なシューティングゲームを実現するタスクシステム（タスクシステム，シューティング，ゲーム）
codezine.jp/a/article.aspx?aid=297

いまどきのタスクシステムの実装
omoikane.my-sv.net/gcss/tasksystem/index.php

ゲーム・ノ・シクミ第11回 C++によるタスクシステムの実現
今は無き C MAGAZINE 2006年1月号
www.cmagazine.jp/contents/200601.html
3 名前：名前は開発中のものです。 mailto:sage [2007/12/04(火) 17:53:51 ID:3YteMgDl]: Logician Lord　…　【コンピュータゲームのからくり】
※ウェブアーカイブのキャッシュ
web.archive.org/web/20041009222313/www.hh.iij4u.or.jp/~peto/Games/games_top.html

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

当然ながら、Cマガにおいてド素人さんのタスクシステム紹介記事が載る前の話な
4 名前：名前は開発中のものです。 mailto:sage [2007/12/04(火) 18:00:24 ID:3YteMgDl]: 4 ：名前は開発中のものです。：2007/03/13(火) 01:05:48 ID:lSPAnQVN
暇だったんで書いてみた。添削できる人がいたらよろしく。

タスク

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

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

→ファイバの項を参照

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

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

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

注: Winedows3.1等の擬似マルチタスクとは関数のリターンが必要なところは同じであるが、
コンテキストスイッチが伴わないところが異なるため、同じものとは言い難い。
5 名前：名前は開発中のものです。 mailto:sage [2007/12/04(火) 18:01:49 ID:3YteMgDl]: 5 ：名前は開発中のものです。：2007/03/13(火) 01:06:36 ID:lSPAnQVN
プロセス[Process]

→ja.wikipedia.org/wiki/%E3%83%97%E3%83%AD%E3%82%BB%E3%82%B9

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

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

→ja.wikipedia.org/wiki/%E3%82%B9%E3%83%AC%E3%83%83%E3%83%89_%28%E3%82%B3%E3%83%B3%E3%83%94%E3%83%A5%E3%83%BC%E3%82%BF%E3%83%97%E3%83%AD%E3%82%B0%E3%83%A9%E3%83%9F%E3%83%B3%E3%82%B0%29

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

軽量スレッドとも呼ばれる。並列的な記述が可能だが、スレッドで必要な
ロックが必要ない点がメリットである。コンテキストスイッチをOSではなく
アプリケーションが明示的に行うスレッド。WindowsではCreateFiber()で作成できる。
6 名前：名前は開発中のものです。 mailto:sage [2007/12/04(火) 22:58:33 ID:IISCFTco]: 普通のゲームプログラムとアルゴリズムは変わらない。
ただASM臭い実装を好むという嗜好に過ぎない。
7 名前：名前は開発中のものです。 mailto:sage [2007/12/05(水) 01:23:10 ID:KjVlOJvV]: 【タスクシステム狂信者のバイブル】
■松浦本
シューティングゲームアルゴリズムマニアックス
www.sbcr.jp/books/products/detail.asp?sku=4797327316

アクションゲームアルゴリズムマニアックス
www.sbcr.jp/books/products/detail.asp?sku=4797338954
シューティングゲームプログラミング
www.sbcr.jp/books/products/detail.asp?sku=4797337214

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

■やね本
Windowsプロフェッショナルゲームプログラミング１、２
www.shuwasystem.co.jp/cgi-bin/detail.cgi?isbn=4-7980-0314-X
www.shuwasystem.co.jp/cgi-bin/detail.cgi?isbn=4-7980-0603-3

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

■逆引き本
逆引きタスクシステム
www.shuwasystem.co.jp/cgi-bin/detail.cgi?isbn=4-7980-1169-X

　タスクシステム厨の書いた本
8 名前：名前は開発中のものです。 mailto:sage [2007/12/05(水) 01:29:22 ID:KjVlOJvV]: 【タスクシステム厨が読むべき不朽の名著】
■shi3z本
Direct3D プログラミングガイドブック
www.seshop.com/detail.asp?pid=159

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

■山崎本
ゲームプログラマになる本
www.cqpub.co.jp/hanbai/books/35/35751.htm
めざせゲームプログラマ
www.cqpub.co.jp/hanbai/books/35/35641.htm
　
　日本におけるメガデモ第一人者の本。残念なことに絶版
9 名前：名前は開発中のものです。 mailto:sage [2007/12/05(水) 08:00:47 ID:Lh4sjdD/]: ↑に古臭い本が紹介されてるけど、これ使えるの？
10 名前：名前は開発中のものです。 mailto:sage [2007/12/05(水) 11:36:59 ID:Jvl1n8OM]: >>9
わからん。が、期待は禁物。正直、目次からはそんな感じはしないなぁ。
大学とかで見たら、立ち読みして見れ。
11 名前：名前は開発中のものです。 mailto:sage [2007/12/05(水) 12:10:18 ID:Isze4xKb]: >>8
最後の二つはURLが逆？
めざせゲームプログラマは持ってます
12 名前：名前は開発中のものです。 mailto:sage [2007/12/05(水) 12:54:53 ID:+KnvWAen]: 絶版なっているやつ
誰かスキャンしてpdfで公開してくれ
13 名前：名前は開発中のものです。 [2007/12/05(水) 22:59:09 ID:Ng0dTUw2]: >>8
＞ゲームプログラマになる本
＞www.cqpub.co.jp/hanbai/books/35/35751.htm

昔かって殆ど読んでないが持ってた、表紙見て思い出した
早速読んでみよう
14 名前：名前は開発中のものです。 mailto:sage [2007/12/05(水) 23:25:55 ID:A6jH8VGj]: タスクシステムが理解できなければ、職業ゲームプログラマになれないんでしょうか？
15 名前：名前は開発中のものです。 mailto:sage [2007/12/05(水) 23:28:17 ID:VOAxOcjQ]: YES.
使う使わないは別にして、この程度も理解できないような頭では、
プログラミングを職業にすることはあきらめた方がいい。

が、プログラマというのは所詮未来無きＩＴ土方であって、
理解できずにあきらめた方が出世できる、とも言える。
16 名前：名前は開発中のものです。 mailto:sage [2007/12/05(水) 23:50:00 ID:Jvl1n8OM]: >>15
それは・・・微妙に問題を摩り替えてる気もする。
プログラマでも、コーディング猿ならともかく
色々とやる人間はどこでも働き口見つけられるし、
そういういみで、より出世しやすいだろ。

問題は、プログラ"ム"しかできないプログラマがダメなだけ。
会話や交渉、人の扱い・金の計算などなど、ちょっとした事でも
それらができれば、単純なプログラマよりも幅広い選択と未来がある。
Sヨが精々な人も同様に、それほど未来がないしねｗ
17 名前：名前は開発中のものです。 mailto:sage [2007/12/05(水) 23:52:53 ID:rqZWEfda]: そんな御託は会社説明会で偉そうにぶっとけ。
18 名前：名前は開発中のものです。 mailto:sage [2007/12/06(木) 00:35:26 ID:5WVY/F2x]: ゲームにハマっている間に1000いってたので、500レス一気読み

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

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

最後のこれいいな。俺はまさに２だ。
ゲームでオブジェクトの動作に使われている巡回UPDATE＝タスクシステム
19 名前：名前は開発中のものです。 mailto:sage [2007/12/06(木) 00:41:53 ID:2ewBanaL]: >>16
そんなこといったってプログラム組めると知られたら
一生プログラム組まされるにきまってるだろ？
実はどこの現場でもプログラマいねーんだ
でもだからっつってプログラマの給料が高いわけじゃない

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

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

まあ、日本の人件費で物作るのがそもそも割りにあってないっていうかそんなん
いまからプログラマになんてなろうと考えちゃ駄目だよ。これはマジで
20 名前：名前は開発中のものです。 mailto:sage [2007/12/06(木) 00:48:20 ID:5WVY/F2x]: あと>2の
>いまどきのタスクシステムの実装
>omoikane.my-sv.net/gcss/tasksystem/index.php
>ゲーム・ノ・シクミ第11回 C++によるタスクシステムの実現
>今は無き C MAGAZINE 2006年1月号
>www.cmagazine.jp/contents/200601.html
この２つはもう要らなかったんじゃね？

追加で

関連スレ
ゲームにおけるデータ構造・クラス設計・パターン
pc11.2ch.net/test/read.cgi/gamedev/1155209226/

C++ と今時のハードウェアでやる古典タスクシステムに替わるもの
ttp://www.issei.org/blog/archives/000225.html
21 名前：名前は開発中のものです。 mailto:sage [2007/12/06(木) 00:50:33 ID:AhaNCitW]: ↑派遣って自分の身の回りしか見えてないのか。
そうなるとインドや中国云々も世間で言ってることの受け売りだろう。

アウトソーシングで倹約できる分野の仕事に付いたら終わりかもしれないが
できない分野のプログラマもいるんだよ。
22 名前：名前は開発中のものです。 mailto:sage [2007/12/06(木) 03:19:35 ID:HdWZc6ta]: ていうか解釈広くとっておかないとこのスレの意味がなくなるような
まあデータ構造スレへいけばいいだけのはなしなんだけどね
23 名前：名前は開発中のものです。 mailto:sage [2007/12/06(木) 06:11:52 ID:UqqGAKZG]: 自分のこだわり

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

２、ゲームループにはウィンドウメッセージループ(GetMessage)を使う
タイトル画面など自動的な処理する必要がない時は
ループを回さないでCPU率を軽くする。
再描画やキー入力などに備えておくだけ。
アクションなどの場合はTimeBegin系を使う。
24 名前：名前は開発中のものです。 mailto:sage [2007/12/06(木) 08:20:05 ID:AhaNCitW]: 俺から見たら嫌な作りだね。
ゲームのメイン部分では、メッセージループでどんなAPIを使うかなど思考の埒外にしたいね。
Direct3Dのデバイスのリセットやメッセージループがあちこちに散らばるなんて
デバッグで面倒が増えるだけだ。
25 名前：名前は開発中のものです。 mailto:sage [2007/12/06(木) 08:22:16 ID:2ewBanaL]: >>21
その場合、開発をやめてしまったり潰れてしまう会社が多い
人材倒産っていうんだとさ
26 名前：名前は開発中のものです。 mailto:sage [2007/12/06(木) 09:05:59 ID:aorsrR2s]: >>23
ないわ
27 名前：名前は開発中のものです。 mailto:sage [2007/12/08(土) 01:44:04 ID:CYfUYGS1]: >>24
始めはシーンごとにコールバック関数を作っていたが、
グローバル変数やstatic変数を使いたくないので、
メッセージループ(の中にコードを書く)を複数作るようになった。

DirectXは使っていないのでよく分からないが、
デバッグは現在のシーンのコールバックかメッセージループ
を調べるだけなので分かりやすい気もする。
28 名前：名前は開発中のものです。 mailto:sage [2007/12/08(土) 05:37:29 ID:l8AiqE/q]: これが同人ソフトだとしたら
タイトル画面が魅力的になるようにキャラを動かしたりアニメさせましょうと提案されても
「CPU使用率が上がるから駄目」「そういう構造になってないから駄目」と拒否するのか
だっさｗｗｗｗ
29 名前：名前は開発中のものです。 mailto:sage [2007/12/08(土) 05:40:49 ID:cj/l/sA4]: >>23
まぁ、mine sweeper 作るならアリかなぁ。
30 名前：名前は開発中のものです。 mailto:sage [2007/12/08(土) 07:28:22 ID:CYfUYGS1]: >>28
一般的に派手な動きは少ないシーンという意味で使った。
だからコンフィグシーンなどでもいい。

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

>>29
逆にロープレとか
シーンの種類の多いゲームの方が向いている気がする。
31 名前：名前は開発中のものです。 mailto:sage [2007/12/08(土) 13:14:00 ID:/PKo7xok]: // たすくしすてむ

foreach(ball b in balls)
{
　　b.update();
　　b.paint();
}
32 名前：名前は開発中のものです。 mailto:sage [2007/12/08(土) 15:37:53 ID:dpKOt0nT]: >>30
シーンの切り替えでクロスフェード等を使う場合はどうするの？
かならずフェードアウト／イン(もしくは一瞬)？

ドラクエみたいに、フィールドの上で戦闘やショップの処理、
ステータス表示なんかを行いたい場合とかもどうするのか気になる。
33 名前：名前は開発中のものです。 mailto:sage [2007/12/09(日) 05:57:18 ID:fYOmZnNF]: >>32
クロスフェードというのは音楽のなんかみたいだがよくわからない。

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

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

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

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

シーン切替えの説明にはなっていない気がするが、大本の違いは
if(g_scene == SceneField) **
else if(g_scene == SceneShop) **
のチェックを、よくあるやり方の場合、1ループ毎に行っていると思うが、
シーンを切り替える場合は、一度チェックしたら
**の所で別のゲームループまたはコールバックに入ってしまうので、
そのシーンから抜けるまでシーンのチェックは行わない。
34 名前：名前は開発中のものです。 mailto:sage [2007/12/09(日) 06:57:29 ID:fYOmZnNF]: お店のシーン(ゲームループ、コールバック)にも複数あって、
買う売る出るの選択、買う物の選択、売る物の選択、
誰が買うかの選択、「○○を買った」と表示し、
キー入力があるまで待つシーンなどがある。

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

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

「○○を買った」と待つのも、「扉を開けた」、「○○を手に入れた」
などと同じキー入力があるまで待つという共通の処理なので、
ひとつの待つシーンを作り、使いまわしている。
35 名前：名前は開発中のものです。 mailto:sage [2007/12/09(日) 07:20:28 ID:nQCm/lvH]: 誰もが普通に使うような技法や、誰もわざわざやろうとしない技法に特別な名前を付けて、
俺様天才！俺様スゲーーーー！！！

というのがタスクシステムの本質だとすれば、きっとスレ違いではないのだろうな。
36 名前：名前は開発中のものです。 mailto:sage [2007/12/09(日) 09:00:37 ID:fYOmZnNF]: >>35
確かに自分のやり方以外のやり方はあまり知らないので、
他のやり方と比べた客観的な説明にはなっていないのかも。
出直してきます。
37 名前：名前は開発中のものです。 mailto:sage [2007/12/09(日) 19:28:44 ID:Lzb0B9+Z]: >>33
クロスフェードってのは、元の場面をフェードアウトしつつ、新しい場面をフェードインすること。
ゲームの場合だと、元のシーンを後ろで動かしつつ、新しいシーンの描画のアルファ値を
上げていって切り替える感じかな。
計算や描画の重さもあるから、「前のシーンを動かしつつ」ってのは難しいかもしれんが。

シーン管理の方法は大体理解した。
ゲームのロジックの中にWindows独自のルールが平然と出てくるのは気になるが、
その辺割り切って作るならいいんじゃないかな。
38 名前：名前は開発中のものです。 mailto:sage [2007/12/09(日) 20:16:34 ID:QBlb02fM]: いまのマシンってワンシーンで限界まで性能ださないからロードさえ気をつければ
クロスフェード（２シーン分）ぐらいなら普通にいけると思うよ
PS２とかじゃ苦しいけど
39 名前：名前は開発中のものです。 mailto:sage [2007/12/09(日) 20:24:41 ID:RxPCFRcK]: >>38
> PS２とかじゃ苦しいけど
あれは性能より VRAM が…
40 名前：名前は開発中のものです。 mailto:sage [2007/12/09(日) 20:25:58 ID:RxPCFRcK]: >>34
アニメーションはどうするの？　ドラクエだと敵が動いたり、攻撃時にエフェクトが
出るような場合。
41 名前：名前は開発中のものです。 mailto:sage [2007/12/09(日) 20:38:58 ID:QBlb02fM]: 複数のシーンを絡ませて管理する機能が必要なんだから
シーン同士を管理するシーンマネージャーを作ればいいだけの話じゃねぇの？
シーン間を飛び越えてマップやキャラのデータが存在し続けるんなら
キャラやマップはシーンに属さないっていうかシーンが抱えるべき情報ではない
つまりシーンの前処理後処理でロードアンロードされないわけだな
じゃ、誰がするのかというとさっき用意したシーンマネージャーが管理するわけだ
シーン間を接続する役目もシーン間が絡む以上シーンマネージャの仕事だろう
シーンクラスの役目は今の情報・状態から自分の表示・実行に必要なデータをシーンマネージャに
返す機能だけになるんじゃね？
それをうけてシーンマネージャは複数のシーンを総合的にみて現在必要なデータを搾り出すと
シーンマネージャに当たるもんは結構でかくなるぜ
これをシーンごとに頑張って管理しようとするとデスマーチ確定
42 名前：名前は開発中のものです。 mailto:sage [2007/12/09(日) 23:12:03 ID:rwPHbHKr]: >>23
> １、ゲームループはシーンごとに別にする
つまりタスクシステムだね
タスクを入れ替えることで違うシーンに対して別のループを提供できる
もしタスクシステムを使わなければシーンの数だけほぼ同じソースを別個に書かなければならない
1箇所ソースを変更するだけでそれらのシーンすべてのループを書き換えることになりメンテナンス性が著しく落ちる

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

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

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

> タイトル画面など自動的な処理する必要がない時は
> ループを回さないでCPU率を軽くする。
タスクシステムを使えばシーンごとにまったく違う処理が書けるから
シーンごとに違うメインループを書くことも可能なんだよね
仮にオープニングでアニメーションやデモを追加したい場合
タスクを入れ替えることで対応可能
43 名前：名前は開発中のものです。 mailto:sage [2007/12/09(日) 23:19:22 ID:rwPHbHKr]: >>24
タスクシステムを使えばそれらは一箇所に記述するだけでいい
重複した記述を最小限にできるタスクシステムはデバッグにも役立つ

>>27
限りなく正解に近い
タスクシステムとはコールバック進化系の一種だ
コールバックされる関数を制御する仕組みが追加されたものがタスクシステムなのだ
44 名前：名前は開発中のものです。 mailto:sage [2007/12/10(月) 00:12:04 ID:kVa9UCh4]: 何が「限りなく正解に近い」だ、このおっぱい占い野郎
「コールバック進化系」とか無駄にESP値を要求する造語を散りばめんな

コールバック＝何かをきっかけに呼び出される
それだけだ。これの進化系ってどういうことだ。具体的に何に対して何が進化したんだ
45 名前：名前は開発中のものです。 mailto:sage [2007/12/10(月) 00:17:12 ID:FgTvF4nS]: また面白い燃料が投下されたようですね
46 名前：名前は開発中のものです。 mailto:sage [2007/12/10(月) 01:07:39 ID:AFViqWGu]: > > １、ゲームループはシーンごとに別にする
> つまりタスクシステムだね

この時点で釣りとしか思えない。
47 名前：名前は開発中のものです。 mailto:sage [2007/12/10(月) 08:12:39 ID:oZKWD7tz]: 店なんか床に商品並べて店番一人置いておけばループ分けなど不要
48 名前：名前は開発中のものです。 mailto:sage [2007/12/10(月) 11:26:27 ID:4KeM6Lnp]: シーンって何よ？
言葉の定義なくして話進められても？？だぜ
49 名前：名前は開発中のものです。 mailto:sage [2007/12/10(月) 13:37:22 ID:NNHyQgcJ]: また定義厨か
さすがにそれはないな
50 名前：名前は開発中のものです。 mailto:sage [2007/12/10(月) 16:08:36 ID:FhEMVCWa]: >>48
さてはDirect3D使ったこと無いな？
51 名前：名前は開発中のものです。 mailto:sage [2007/12/10(月) 17:15:59 ID:TRJA29h8]: >>48
見た感じ
・タイトル画面
・戦闘画面
・マップ移動画面
みたいなのをシーンと書いてあるだけ。

>>50
なぜ突然Direct3D・・・
(IDirect3DDeviceN::BeginScene？)
52 名前：名前は開発中のものです。 mailto:sage [2007/12/10(月) 18:15:58 ID:kVa9UCh4]: 定義厨の俺でも
さすがに>>48はないな
53 名前：名前は開発中のものです。 mailto:sage [2007/12/10(月) 19:32:53 ID:ynLW352R]: ゲームをまともに作れないことが明らかな>>48の発言に、一同、シーンとなった。
54 名前：名前は開発中のものです。 mailto:sage [2007/12/10(月) 19:44:32 ID:sWUDY/qD]: プログラム開発現場の駄洒落は99%、発言者が死ねばいいのにという感想になる。
しかもバグの取れない苛立ちまでも一手に引き受けてな。
55 名前：名前は開発中のものです。 mailto:sage [2007/12/11(火) 00:04:17 ID:T0+r8UQD]: >>53
誰がシーンとなることを言えと
56 名前：名前は開発中のものです。 mailto:sage [2007/12/11(火) 00:53:40 ID:ECQVp0Tr]: さっきからチーンチーンチーンチーンってお前等は変態か？
57 名前：名前は開発中のものです。 mailto:sage [2007/12/11(火) 08:56:37 ID:xDs0NYc0]: ユビキタスとかWeb2.0とかあんな感じの電波を感じるな
58 名前：名前は開発中のものです。 mailto:sage [2007/12/15(土) 22:33:07 ID:dW/LIK6y]: >>44
説明しよう！

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

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

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

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

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

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

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

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

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

以上の特徴により、動的に機能を拡張し、相互に連携することが可能になったのである
59 名前：名前は開発中のものです。 mailto:sage [2007/12/16(日) 00:14:11 ID:tU3FXTu1]: >>58
> 以上の特徴により、動的に機能を拡張し、相互に連携することが可能になったのである
単にインスタンスの数が可変なだけで、連携については何も触れてないじゃん。
60 名前：名前は開発中のものです。 mailto:sage [2007/12/16(日) 01:22:25 ID:Uds4tbII]: 先頭をheadにするなら末尾はtailにしてくれ
末尾をendにするなら先頭はbeginかstartにしてくれ
俺が言いたいのはそれだけ
61 名前：名前は開発中のものです。 mailto:sage [2007/12/16(日) 01:27:07 ID: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 名前：名前は開発中のものです。 mailto:sage [2007/12/16(日) 01:50:58 ID:eEobSst5]: >>58
タスクシステムが誕生する70年代末期よりも遥か前の
古典的なコンピュータのプログラムで既に同じようなことをやってるだろ。
例えば、割り込み信号にフックするとき、つまり割り込み処理ルーチン
（常駐プログラム・サービス）を割り込みベクタテーブルに追加するとき
既存のルーチンがあればそれと数珠繋ぎにするだろ
63 名前：名前は開発中のものです。 mailto:sage [2007/12/16(日) 02:16:17 ID:eEobSst5]: 単純で乱暴なやり方をするなら、割り込みベクタテーブルに
既存ルーチンの代わりに自分のアドレスを上書きして
先に自分の処理を呼び出させ、自分の処理が終わったら
既存ルーチンへジャンプさせる。つまり割り込み処理に割り込む。

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

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

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

を全て満たしている。

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

ハードウェアは割り込み信号に応じて割り込みベクタテーブルの
当該アドレスに登録されてる割り込み処理ルーチンを呼び出す。
そしてリストに登録された順に次々呼び出される。
割り込み処理ルーチンは処理完了時のリターン命令を
他のルーチンへのジャンプ命令に書き換えることで
子ルーチンの追加が可能
64 名前：名前は開発中のものです。 mailto:sage [2007/12/16(日) 02:18:07 ID:eEobSst5]: 紳士的なやり方なら
呼び出し側＝割り込み処理ルーチンのリスト管理プログラム、か
65 名前：名前は開発中のものです。 mailto:sage [2007/12/17(月) 15:54:34 ID:d05xYvvB]: 意見は出したくないが文句はつけたい
そんな嫌タスク厨の巣窟だというのがわかる流れでしたね
文句つけてる暇があったら、58がかすむくらいの有益情報でも書き込めっての
66 名前：名前は開発中のものです。 mailto:sage [2007/12/17(月) 16:25:30 ID:fh4AIKkl]: またブーメラン芸か
67 名前：名前は開発中のものです。 [2007/12/17(月) 16:43:25 ID:fh4AIKkl]: =210.130.51.98 ヘ(　`Д)ﾉ
68 名前：名前は開発中のものです。 mailto:sage [2007/12/17(月) 21:14:21 ID:PVpDrrvq]: コールバック進化系（笑）スィーツ（笑）
69 名前：名前は開発中のものです。 mailto:sage [2007/12/17(月) 21:26:04 ID:FK63IV8y]: 確かにプログラム用語の大半はスイーツ（笑）テイストを感じさせる回りくどい言い回しだな
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; }
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]: 毎度必ず、連続投稿の最後にポエムつけてくるよなｗ
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は同一人物かと思ってたわ
二人ともなんか言ってることが子供っぽいよ

タスクが有害な理由はいくらでも思いつくし、有益な理由もいくつか思いつく
多分、あと１０年もすると中心的な世代が入れ替わり、
欧米的な設計手法ばかりになってタスクは嫌でも消えていくと思う
だから、そんな風に汚い言葉で煽ったり非難する必要なんかない

あなた方が理想論者で世の中を自分の思っている方に変えたいと考えてるのは分かったけど
俺にとっては目の前にタスクを使う先輩方がいるっていう現実が問題であるわけで、
彼らが引退するまで増大し続ける要求に対して古き良きタスクで頑張り続けることは到底不可能だから、
前に進むためには、そうやってただ気持ちよく批判して否定してても仕方ないんよ
どうやって彼らを懐柔して、いかにも「タスクいいっすよねー、使ってますよー」という顔をしながら
実際には本来のタスクとは根本を異にする欧米流の設計手法にすりかえていき、
安全で品質の良いコーディングをしていくかってことが大事なんよ
236 名前：名前は開発中のものです。 mailto:sage [2008/06/01(日) 22:45:00 ID:sbTmSAWc]: >>235
C++禁止とか、先輩には技術的批判ができない空気とか、かわいそうな環境に居るんだね。
そういう環境を変えようとは思わないの？
237 名前：名前は開発中のものです。 mailto:sage [2008/06/01(日) 22:57:04 ID:DrvtIKA9]: タスクという言葉には意味があるのに
タスクシステムという偉そうな名前にして
略してタスクって言ってる、これ自体がおかしい

意味を勝手に再定義して、人を混乱させて何か楽しいのか
消防署の方から来ましたって言って人を騙しているのと同じだろ

そんな奴に子供っぽいとは言われたくないな
カルトを批判することが子供っぽいのなら、いくらでも子供っぽくなってやる
238 名前：名前は開発中のものです。 mailto:sage [2008/06/01(日) 23:15:28 ID:A9oINGs6]: ただ「ダメだ」と言い続けるだけでは「批判」にならんよ。

>>227
で？　「有益なパターン」とやらは、まだ挙げられないの？
もう調べなおす時間は十分あったと思うけど？

>>233
「メリットのないことの証明」なんてする必要ないでしょ。
代替手段のメリットか、タスクシステムのデメリットを説明すればいいだけ。
その「デメリット」をはっきりさせるために質問してるんだけどなぁ。
君でもいいので>>206に答えてよ。
239 名前：名前は開発中のものです。 mailto:sage [2008/06/01(日) 23:26:32 ID:DrvtIKA9]: >>238
もうどうでもいい
散々書いてるのに無視されまくって同じことを何度も書くのもバカらしい
知識を持たない奴と議論しても何も生まれない
タスクの正しい意味もわかってないような奴と対話する必要もない
240 名前：名前は開発中のものです。 mailto:sage [2008/06/01(日) 23:37:44 ID:DrvtIKA9]: 半端に容認してやがるカスのせいで
信者が新しく増え続ける弊害
延命する手助けをして自分の首絞めてろ
241 名前：名前は開発中のものです。 mailto:sage [2008/06/01(日) 23:39:12 ID:6rc2ui2D]: 捨て台詞入りました
242 名前：名前は開発中のものです。 mailto:sage [2008/06/01(日) 23:43:59 ID://w8HXJr]: >>236
正論ですねｗ
そういう環境を変えるのが一番だと思うし、そういう風にも動いています

ただ、単に今までのやり方をやめさせて新しいものを受け入れさせるっていうのは
傲慢だとも思うんですよねー
のちのち、自分の後輩が、例えば「boost使いたいんですけど」って言ってきた時に
多分自分も「んー、boostは、コンパイル環境に依存するからなあ・・・」とか
「shared_ptrとかbind程度ならいいけど、あまり複雑すぎるのは使わないで」とか
もっともらしい言い訳しながら抵抗すると思うんですよね
それは慣れたやり方を捨てるのが嫌で、知らないものを受け入れるのが怖いから
誰だってそうだと思う。そんな簡単に既存のやり方を否定なんかできないと思う

>>239
タスクの正しい意味がわかってなくてすいませんでしたー
243 名前：名前は開発中のものです。 mailto:sage [2008/06/01(日) 23:50:57 ID:rH1ss0D0]: >>238
お前の議論の仕組みがわからない
俺等にデメリットを出させてそれでどうしようっていうの？
まず、これを答えてくれ
質問内容は「デメリットを出してそれでどうしたいのか？」

なにやらどうしてもあげてほしいみたいだから書いておくけど
こんな感じ↓
・仕組み自体が意味ないし、
・グローバル変数必須になるし
・デバッグのしにくさ、
・インスタンスの把握のしにくさ、
・各オブジェクトの管理のし難さ、
・無駄なプライオリティの管理の必要

追記しておくと、はっきりいってこんなみんなわかってるようなことを
あえて聞くあたりもう議論に勝つためにわざと知らないふりをして
知っていることを相手にいちいち答えさせることでうんざりさせる効果を狙ってるとしか思えないけどね
244 名前：名前は開発中のものです。 mailto:sage [2008/06/01(日) 23:52:10 ID:Q8YpYrfT]: よくわからないのでソースで示してください
245 名前：名前は開発中のものです。 mailto:sage [2008/06/01(日) 23:52:38 ID:rH1ss0D0]: >>244
邪魔　消えろ
246 名前：名前は開発中のものです。 mailto:sage [2008/06/01(日) 23:59:28 ID:zLG7F7W1]: 243を見てさっきからニヤニヤしてる
247 名前：名前は開発中のものです。 mailto:sage [2008/06/02(月) 00:04:43 ID:TfZZ1SZH]: 俺もニヤニヤしてる。
248 名前：名前は開発中のものです。 mailto:sage [2008/06/02(月) 00:33:36 ID:cwut3Cbv]: タスクシステムを理解できなかったからって醜態をさらすなよ、見苦しい。
249 名前：名前は開発中のものです。 mailto:sage [2008/06/02(月) 00:43:16 ID:CLd7aMjs]: >>238はデメリットをあげてもらってどうしたいのか答えられるのかね？
250 名前：名前は開発中のものです。 mailto:sage [2008/06/02(月) 00:43:51 ID:Y5ac98mm]: >>248
おいおい、本物のタスクシステム信者？
251 名前：名前は開発中のものです。 mailto:sage [2008/06/02(月) 00:52:30 ID:cwut3Cbv]: いんや rH1ss0D0 みててタスクシステム大好きなんだなって思って書いてみただけ。
252 名前：名前は開発中のものです。 mailto:sage [2008/06/02(月) 00:57:40 ID:tWKX9lA+]: >>225
本当に往生際の悪い人だなぁ

＞Zソートと近いね。

「近い」ではなく「そのもの」だろう

＞3Dだとシーングラフ的な構造に近くなるのかも知れんけど

「的」ではなく「そのもの」だろう
タスクシステムの原義(※)に照らせばシーングラフ的思想などない。
強引に解釈して「シーングラフの片鱗が見出せます！」とか
歴史修正主義者みたいな苦しい抵抗は試みるなよ。
シーングラフ的ならそれはもはやタスクシステムと呼べない。
そう認めたほうがきっと気持ちいい

＞「要素内のプライオリティ変数」とかいうのを勝手に幻想して

タスクシステムの原義(※)に照らせばそのような実装になっている。

（※）現在、公の議論の場で出典として使えるまともな一次情報がない。
ギャラクシアンのプログラマがダンマリを決め込んでいるから当然だ。
ギャラクシアンのバイナリイメージをリバースエンジニアリングした
結果は胸のうちに仕舞い込むしかない。公にした違法なのだから
出典として使えない。よって合法的に入手可能な限りなく一次情報に
近い情報を持ち出して、これを原義とするしかなく、俺の知る限りじゃ
Logician Lordのウェブアーカイブがかなりまともだった
253 名前：名前は開発中のものです。 mailto:sage [2008/06/02(月) 01:02:35 ID:tWKX9lA+]: タスクシステムという単語はローカル用語に過ぎない。密教みたいなものだ。
経典が公に明かされてないのを良いことに、玉入れ民族根性丸出しで勝手に捏造修正
拡大解釈再定義増改築魔改造して原型留めない異形のコードを尻からひり出して
それを現代的タスクシステムなどと称し社内で発表会やって悦に浸るのはまぁいい。
それをこのような場に乗り込んで臆面も無くやるからカオスになるのだ。具体的定義や
実装もロクに語らず、オラが村の娘っこが一番めんこい正統派だぁ、いんやオメんとこのは
淫売ドブスだぁオラんとこのがめんこいしウンコもしない清純派だぁ、みたいなアカデミックで
高属性な水掛け論になる。

さゆりすとに言わせればみんな出来悪い紛い物だ
254 名前：名前は開発中のものです。 mailto:sage [2008/06/02(月) 01:19:16 ID:ZvhvBDDi]: >>243
デメリットがはっきり示されていれば、
君らの言う「タスクシステム信者」も減るかもしれないだろ？
使うにしても、デメリットを理解して使うほうがいい。
つか、君は議論とは「相手を言い負かす」ものと思ってるようだけど、
俺は別にどっち派でもないから、勝ち負けはどうでもいいんだよね。

で、挙げてもらったデメリットだけど、巷のタスクシステムの説明を何も考えずに
鵜呑みにして、なんでもかんでもタスクにしようとすれば、確かにそうなり得ると思う。
ただ、グローバル変数は必須にはならないし、
「オブジェクトの管理のし難さ」は元々ゲームプログラミングが内包する問題で、
タスクシステムによって増すものではないと思うけど。
それがタスクシステムそのもののデメリットだと言うなら、
タスクシステム自体が「どのように」影響してそうなるのか説明してくれないと。

んで、タスクシステムだと使えない「有益なパターン」は？
君が言い出したことなんだから、最低限これだけは答えてほしいなぁ。
これだけちゃんと答えてくれれば、議論は君の勝ちでいいよ。

……つか、ここまで書いて思ったが、君に「デメリットを出せ」とは言ってなくないか？
俺は>>233(231)が言うような「悪魔の証明」は必要ない（メリットが「ない」ことの
証明は必要なく、デメリットが「ある」ことを示せば良い）と言ってるだけで、
君にはずっと「有益なパターン」とやらについてしか聞いてない。
それが使えないこと＝タスクシステムのデメリットなんだろ？
255 名前：名前は開発中のものです。 mailto:sage [2008/06/02(月) 01:35:21 ID:CLd7aMjs]: >>254
>デメリットがはっきり示されていれば、
>君らの言う「タスクシステム信者」も減るかもしれないだろ？
ならまずはじめにそれを説明するべきじゃない？
明らかに順序が違うと思わない？
それとまだメリットを説明できてないわけだけど
メリットがないのにデメリットの検証をするの？おかしくない？

>んで、タスクシステムだと使えない「有益なパターン」は？
は？しゃべってる日本語がまったく意味不明なんですけど？
現状、デメリットがでてしまっている部分を解消できたら有益なパターンといえないですかね？
まあ、しっかり例としてあげなきゃ気がすまないっていうならあげちゃいますけど

プライオリティなんて定義しないで直接ソースにならべりゃいいんですよ
現状、数字打って管理するしかないっすよね？
if(){
　if(){
の形で実行の条件が書けないからタスクシステムで正しく動作させようとすると
動的にプライオリティを振りなおす必要がでてくることも多いでしょうよ
当たり判定の実行順序なんかでかなり複雑になるはずです

これをやらないことが有益なパターンですよ
256 名前：名前は開発中のものです。 mailto:sage [2008/06/02(月) 01:37:15 ID:CLd7aMjs]: >>254
>これだけちゃんと答えてくれれば、議論は君の勝ちでいいよ。
じゃ、答えたよ
俺の勝ちだね
敗北宣言だけはしていってほしいなぁ
「私はタスクシステムのメリットを説明できませんでした」
ってちゃんと言ってってよ
257 名前：名前は開発中のものです。 mailto:sage [2008/06/02(月) 01:45:21 ID:VZyqS9Dw]: なんと醜い争いだろうか
258 名前：名前は開発中のものです。 mailto:sage [2008/06/02(月) 01:50:28 ID:2Kuej5cO]: ＞んで、タスクシステムだと使えない「有益なパターン」は？
そういう攻め方はもうやめなよ
見苦しい
259 名前：名前は開発中のものです。 mailto:sage [2008/06/02(月) 01:56:22 ID:Y5ac98mm]: こんな言い争い、誰の得にもならねえｗ

タスクシステムに「有益なパターン」を追加することは可能だし、実際に各自やっていることだが
そうやってデメリットを減らしていくと最終的には今風のモダン設計になる
「原義のタスクシステム」などというものは、すでにどこの現場にも存在しない
「タスクシステム」という名前だけが残って内実は形骸化しているから、いいとか悪いとか言うことが無意味
二人ともこれで満足か
260 名前：名前は開発中のものです。 mailto:sage [2008/06/02(月) 02:02:05 ID:MtYGqYka]: 曖昧なスタンスの奴が議論に混ざると話がおかしくなるんだな。
中立だと言うくせにアンチだけにやけに食いついてる。
見ていて気持ち悪いから、黙るかタスクシステム肯定しているのかはっきりしないだろうか。
タスクシステムってのは前から疑問に思ってたけど、
こんな流れじゃタスクシステムについての理解は深まらないんだが。
261 名前：名前は開発中のものです。 mailto:sage [2008/06/02(月) 02:04:38 ID:CLd7aMjs]: いいんだよ
タスクシステム（擬似タスク）はもう滅んだ
262 名前：名前は開発中のものです。 mailto:sage [2008/06/02(月) 02:50:03 ID:ZvhvBDDi]: >>255
たぶん別人だろうけど、一応説明しとく。>>195 >>206 を読んでくれ。
タスクシステムの影響が広範囲に及ぶために、他の様々な有益なパターン適用の枷になる
というのなら、
タスクシステムを使わないことによって使える、様々な有益なパターンがある
ってことだろ？　それはどんなパターンなのかってのを、俺はずっと聞いてるんだけど。
>>195 と >>207 が別人というならスマンが、
少なくとも >>207 はその「有益なパターン」とやらを知ってるわけだろ？

>>259
その言い分はまったくもって正論だと思うが、向こうは
「タスクシステムに「有益なパターン」を追加することは可能」というのを否定してるんだよ。

>>260
スマンね。別に中立と言うわけじゃない。前から言ってる通り、俺の立場は「どっちでもいい」
なので、「タスクシステム」VS「非タスクシステム」であれば、中立の立場を取るが、
「タスクシステム肯定」VS「タスクシステム否定」なら、アンチの言い分をはっきりさせたい。
IDで調べてもらえば分かると思うけど、俺は「タスクシステムだと使えない、有益なパターン」
が知りたいだけなんだよ。それさえ教えてもらえば黙るよ。
263 名前：名前は開発中のものです。 mailto:sage [2008/06/02(月) 04:20:41 ID:2Kuej5cO]: >>262
相手には答えない自由があることを認めよう
＞それさえ教えてもらえば黙るよ。
ならもう「使えない有益なパターンは無い」でいいじゃん終了
言質とってからなんか議論を展開するのかと思ったら黙っちゃうのかよ
がっかりだよ
264 名前：名前は開発中のものです。 mailto:sage [2008/06/02(月) 05:11:15 ID:NbU9ArOr]: だからソースコードをだせと
265 名前：名前は開発中のものです。 mailto:sage [2008/06/02(月) 07:06:29 ID:CLd7aMjs]: >>262
>タスクシステムを使わないことによって使える、様々な有益なパターンがある
現状タスクシステムのデメリットが払拭できるんだからタスクシステムを使わないことが
有益なパターンででいいんじゃねぇの？
ダメな理由を言ってよ

っていうかこれが正しい正しくないはおいておいて
有益なパターンとしてあげたんだからさっさと敗北宣言しろよ

なにもあげたパターンがお前の意にそうものかどうかのジャッジまで
お前は求めてなかったぞ
あげた時点でお前の負けだ
266 名前：名前は開発中のものです。 mailto:sage [2008/06/02(月) 11:18:09 ID:FVmHkf2I]: >>252
スレ違いだけど重要な事だと思うので指摘。

リバースエンジニアリングは違法ではない。
否定も肯定もされていないグレーゾーンにある。
ダンプしたコードをコピーすれば著作権侵害になるが
参考にすることは明確に権利の侵害とはいえない。

それではみなさん愚論の続きをどうぞ↓
267 名前：名前は開発中のものです。 mailto:sage [2008/06/02(月) 13:17:51 ID:ZvhvBDDi]: >>263
本当に、タスクシステムだと使えない有益なパターンがあるのであれば、
「タスクシステムを使うべきではない」あるいは
「使えるパターンに制限があることを考慮して使うべき」で終了。
そうでなければ、そもそも議論の前提が成り立たないのでやっぱり終了。
他のことならともかく、この点についてはこれ以上展開する必要はないよね。

>>265
あれ？　同一人物だったのか。

＞なにもあげたパターンがお前の意にそうものかどうかのジャッジまで
パターンが意に添う必要はないけど、「タスクシステムを使わない」じゃ
そもそも「パターン」になってないじゃん。
パターンというからには一定の「型」が必要だろ。
タスクシステム以外の方法はすべて同じパターンなのか？

まあ、それがパターンであると言い張るのならしょうがない。
確かに、「タスクシステム」を使えば、
「タスクシステムを使わないパターン」は使えないよなぁ。
俺の負けだよ。おめでとう！
268 名前：名前は開発中のものです。 mailto:sage [2008/06/02(月) 18:05:37 ID:nsmxUAKf]: おめでとう
269 名前：名前は開発中のものです。 mailto:sage [2008/06/02(月) 18:31:33 ID:tWKX9lA+]: >>266
＞リバースエンジニアリングは違法ではない。
＞否定も肯定もされていないグレーゾーンにある。

よく嫁。リバースエンジニアリングが違法だとは言っていない。
リバースエンジニアリングした結果取得された技術情報を
公に発表することは権利侵害であり、これはグレーではなく
完全に黒、違法だと言っている

だから、
ギャラクシアンのバイナリイメージをリバースエンジニアリングした
【結果】は胸のうちに仕舞い込むしかない。【公にしたら違法】なのだから
出典として使えない。と言っている
270 名前：名前は開発中のものです。 mailto:sage [2008/06/02(月) 19:20:27 ID:RkeN99NI]: >>269
何権が侵害されるの？
アイディアやアルゴリズムを含む「仕様」に発生する
権利は現在の法体系には存在しないぞ。

それが特許になってるとまた別だけどね。
271 名前：名前は開発中のものです。 mailto:sage [2008/06/02(月) 19:50:17 ID:CLd7aMjs]: >>267
じゃあ、タスクシステムがまったく使えないって完全に認めたってことだよねｗ
そもそもね

俺はデメリットをたくさんあげたけど
君は１つもメリットをあげられなかったんだ

勝負とかそういうんじゃなくてね
君の言うことにはまったく説得力がないのさ（笑）
272 名前：名前は開発中のものです。 mailto:sage [2008/06/02(月) 20:18:50 ID:rQLP4r4x]: 要所で使い分けろよ
喧嘩すんなよ
273 名前：名前は開発中のものです。 mailto:sage [2008/06/02(月) 20:31:21 ID:r55Dmo9D]: いや、ここ隔離スレだしｗ
知ったかと学生が喧嘩するのを
時折いじりつつ基本的には高みから見物する場所だ
>>243には笑わせてもらったよ
274 名前：名前は開発中のものです。 mailto:sage [2008/06/02(月) 20:37:46 ID:nsmxUAKf]: タスクシステムこそ
ゲーム業界にのみ伝わる現代の魔術
連綿と口伝によってのみ受け継がれ
変化し、進化と退化を繰り返す
その亜流は数知れず、もはやその全てを語れるものはいない
275 名前：名前は開発中のものです。 mailto:sage [2008/06/02(月) 20:40:28 ID:tWKX9lA+]: >>270
そのとおり。アルゴリズムやアイディアに著作権はない

リバースエンジニアリングした結果取得された技術情報を公に発表する
と書いたのは、具体的には当該箇所のZ80マシン語コードの断片を例示しての解説。
自分でディスアセンブルしたコードなら独自の著作物と主張できるんじゃないの、とか
断片を例示しての解説は引用に過ぎないから問題ないんじゃないの、とか
そこまでは詳しく知らないので黒じゃないかもだが
276 名前：名前は開発中のものです。 mailto:sage [2008/06/02(月) 22:32:05 ID:78e1tECU]: >>269
それは大変失礼した。ひとつ言い訳をさせてもらうと>252は
「公にした違法」だからリバースエンジニアリングした事実を
公表することが本人にとってまずいと解釈した。
タスクもそうだが、人によって想定しているものが往々にして
異なるから、話をする時は見解の違いがどこに由来するものか
慎重に見極める必要があるな。全くの誤解であることも少なくない。

>>275
> 自分でディスアセンブルしたコードなら独自の著作物と主張できるんじゃないの、とか
> 断片を例示しての解説は引用に過ぎないから問題ないんじゃないの、とか

前者はありえないな。後者も解説にオリジナルのコード断片が
どうしても必要とは考えにくいから怪しいな。擬似コードでもいいだろ。
277 名前：名前は開発中のものです。 mailto:sage [2008/06/02(月) 22:36:24 ID:tWKX9lA+]: >>276
＞公にした違法

悪かった。それ素でtypoってた
278 名前：名前は開発中のものです。 mailto:sage [2008/06/03(火) 00:35:43 ID:9OwbDmWK]: これは古のオーパーツ、密教、タスクシステムを己の意のままに再定義・再構築・
拡大解釈しようと試みる修正主義者共の不毛で果てしない内ゲバ、宗教戦争だ。
我こそ現代的タスクシステム（御神体）を手にする神の代弁者。おまいら皆異端！
といった具合に定期的に出没しては四散してゆく田舎侍たちには2通りいる

①カルト教団ナンチャッテタスクシステム学会学会員
松浦先生（師匠）の書物を経典とし、それに記述された言葉を神の恵みと有難がる。
彼らは若く純粋で無知ゆえに洗脳されやすい。低学歴ゆえにアカデミックな権威を
忌避するので、そこに漬け込まれて得体の知れないカルトにハマる。
ゆえに密教総本山と縁もゆかりも無いレトロ趣味者の先生（師匠）が語る出典不明の
現代的タスクシステム論を妄信することができる

②自称プロ
出自を明かせないチキンにも関わらず誰一人として出典を挙げられない。
手持ちのエモノといえば、村のジジ・ババ世代が街道の旅人から伝え聞いた
神器タスクシステムに関する風の噂をもとに復元し村独自のハイセンスで
新解釈・再定義・再構築・アレンジ・増改築・魔改造して出来上がった何だか
よくわからない塊だ。

教条主義や権威主義やアカデミズムは時と場合によっては害悪となるものだが
ことこれこの「タスクシステム」なる経典不在の胡散臭いローカル用語に関しては
「教条や権威の不在」を理由に小突き回して迫害してイジメてシメたほうが良い。
ローカル用語であることを忘れ、何食わぬ顔で公の場にひょうひょうと出没
することがないよう、タスクシステムには自己批判と総括が必要だ
279 名前：名前は開発中のものです。 mailto:sage [2008/06/03(火) 00:55:20 ID:VvhS3kOQ]: これ才能の無駄遣いってやつじゃね。
280 名前：名前は開発中のものです。 mailto:sage [2008/06/03(火) 01:11:43 ID:5RWrmeor]: タスクシステム（笑）を銀の弾丸か何かみたいに思ってる人多いよね。
たぶんそれなりの規模のまともなゲーム１本仕上げたことないんだろうけど。
281 名前：名前は開発中のものです。 mailto:sage [2008/06/03(火) 03:15:13 ID:MeXq4ZrZ]: お前らいちいち相手を煽らねーと議論ができねーのかｗ
282 名前：名前は開発中のものです。 mailto:sage [2008/06/03(火) 03:30:49 ID:vDXWXCn8]: 同一抽象度のリスト内での位置取りを決める必要があるなら
必ず優先度みたいな値が必要になるだろう
でも、そういう場面では同一の抽象度で扱うのがそもそも適当じゃない
そういったリストの構成はリストの要素が各々決めるべきものではない
継承を使える言語なんかでアイデアを真似てしまったタスクシステムの
根本的な問題はここだと思う
283 名前：名前は開発中のものです。 mailto:sage [2008/06/03(火) 13:18:46 ID:SxIgnH8O]: >>275
著作権はないけど特許はあるよ
284 名前：名前は開発中のものです。 mailto:sage [2008/06/03(火) 16:41:39 ID:Uafcojed]: タスクシステムに特許はないよ
285 名前：名前は開発中のものです。 mailto:sage [2008/06/03(火) 23:34:19 ID:knR5aZLW]: おそらく特許って言ってみたかっただけなんだな
286 名前：名前は開発中のものです。 mailto:sage [2008/06/04(水) 00:00:16 ID:i3SoJRXc]: じゃあパテント
287 名前：名前は開発中のものです。 mailto:sage [2008/06/04(水) 00:54:44 ID:bwfPDWKd]: タスクを使うと多人数で開発する場合に
コントローラー（各オブジェクト処理を呼び出す）部分を
新たなタイプのオブジェクトが増えるたびに書き換えなくていいという
メリットがあるけど

タスクを使わずに素直に書く場合どうなるのだろう？
FactoryMethod? 使うのかな？
288 名前：名前は開発中のものです。 mailto:sage [2008/06/04(水) 05:38:36 ID:efviw52E]: >>287
タスクとかコントローラー部分の具体的な内容がわからないけど、
具体的なオブジェクトが増えても呼び出し元を書き換えたくないってことなら
普通に仮想関数と、必要ならコンテナを使えば済むんじゃない？
289 名前：名前は開発中のものです。 mailto:sage [2008/06/04(水) 06:57:08 ID:qWTsFTty]: この流れなら言ってもいいよな？

タスク
ダメ
ゼッタイ！

タスク依存症から抜け出す方法について議論しようぜ
290 名前：名前は開発中のものです。 mailto:sage [2008/06/04(水) 08:25:19 ID:7qi7u0vz]: その様子だとカルト教団ナンチャッテタスクシステム学会から足を洗うのは
なかなかに多難のようだな

余りの風当たりの強さと叩かれっぷりに熱狂的信徒がパニクってるようだが
叩かれてるのはあくまでもその呼称であって、その動作原理ではない。
熱烈な信徒らがカルト教団にお布施して入手した池ｄ、じゃなくて松○先生の
著書（聖書）に記述された教義の内容自体は至って平凡で凡庸で有り触れた
もので、別にあれこれ叩かれるようなものではない

それをタスクシステム（笑）などと呼ぶから小突かれたりイジメられるんだよ
291 名前：名前は開発中のものです。 mailto:sage [2008/06/04(水) 08:40:59 ID:qWTsFTty]: ？？？　>>290の言ってることはよくわからん
松○先生とやらは知らんし呼称はどうでもいいのだが・・・
みんな動作原理っつーか設計の古さを問題にしてるんだと思うぞ
292 名前：名前は開発中のものです。 mailto:sage [2008/06/04(水) 08:50:34 ID:7qi7u0vz]: みんなとは誰のことだ？設計が古いとはどれのことだ？
ギャラクシアンのZ80コードの古さを問題視するのか？
293 名前：名前は開発中のものです。 mailto:sage [2008/06/04(水) 09:15:13 ID:UiW3eWaI]: タスクを使おうと主張する奴らって低学歴低賃金ワープア臭がするよな
294 名前：名前は開発中のものです。 mailto:sage [2008/06/04(水) 11:36:50 ID:3Jrj0qeW]: 別にそんなことないけど？
295 名前：名前は開発中のものです。 mailto:sage [2008/06/04(水) 16:18:00 ID:MMARvLzl]: こんな過疎技術スレで不似合いな精神論とか人格批判をやりたいと申したか
ニュージェネレーションの到来を予感させるのう
296 名前：名前は開発中のものです。 mailto:sage [2008/06/04(水) 16:37:21 ID:JPzcOSZw]: 糞スレだけど、過疎ってないと思う。
297 名前：名前は開発中のものです。 mailto:sage [2008/06/04(水) 19:08:43 ID:dA0XQ2Ce]: ケンカ始めるとあっというまに流れるな
298 名前：名前は開発中のものです。 mailto:sage [2008/06/05(木) 00:19:17 ID:BfpoJj45]: いつもはGoFだの蟹飯本だのストールマンのソースだのGDC論文だのの権威を傘に
用語の正しさを巡ってあーだこーだ言ってる偏屈野郎が、タスクシステムの話になった途端に
それまでの頑なな教条主義や権威主義をかなぐり捨てて、まともな出典もない一介の
ローカル用語を必死になって擁護するのだから面白くてしょうがない
299 名前：名前は開発中のものです。 mailto:sage [2008/06/05(木) 03:16:13 ID:jWfxbouu]: ところで・・・

>GoFだの蟹飯本だのストールマンのソースだのGDC論文だのの権威を傘に
これ↑ってプログラムを組む上でほとんど役に立たないよな（笑）

知識として知ってるのはいいけど
今、目の前にある問題を解決してくれる類のものではないことは確かだよな

色んな奴がいていいと思うけど
所詮、作ったのは人間って部分を忘れて
「ちょっと知られた論文＝絶対に正しい＝出典を示せば説明不要」って
前提で話を始めるのはよろしくない
正直、分野が分野だけに未熟だと思うぜ
論文って反論するのにものすごい時間を使うから誰も相手にしてないだけで
出版社なんかが盛り上げたらそれでOkみたいなもんあるし

正直、便利以外に「効果、可読性、品質、実用性」あたりの面から検証すれば
ボッコボコに叩かれるもんってたくさんあると思うけど現場で働いてるプログラマーにそんなことする暇ないわけで
こんな本や論文書いてる奴がどんな奴かっていうというまでもなく
本職のプログラマじゃないわけでダメなもんもそのまま広がってしまっているって面あるぜ
300 名前：名前は開発中のものです。 mailto:sage [2008/06/05(木) 08:50:34 ID:OUccFB/T]: もっと人格批判やろうぜ
301 名前：名前は開発中のものです。 mailto:sage [2008/06/05(木) 15:48:09 ID:z9orY+fP]: GOFの1/4ぐらいは、知っててほしい
302 名前：名前は開発中のものです。 mailto:sage [2008/06/05(木) 15:49:05 ID:z9orY+fP]: >現場で働いてるプログラマーにそんなことする暇ないわけで
そういう人が３５歳定年説
303 名前：名前は開発中のものです。 mailto:sage [2008/06/05(木) 16:43:00 ID:fUsn6oNK]: ごｆは古いから読む気しない
OO関係は計算機科学と違ってナマモノだし
改訂版というかyetanother的なものがあればいいんだけど
304 名前：名前は開発中のものです。 mailto:sage [2008/06/06(金) 13:09:49 ID:L0mhQQ6Z]: singletonぐらいはわかってやれ
305 名前：名前は開発中のものです。 mailto:sage [2008/06/07(土) 00:04:29 ID:Oo0P7gwB]: singleton をグローバル変数の隠れ蓑みたいに使ってる人と
「タスクシステム」を使ってる人に、何とはうまく言えないけども
共通点を感じる。なんだろう？
306 名前：名前は開発中のものです。 mailto:sage [2008/06/07(土) 15:10:10 ID:pJb1OYfH]: データベースに格納してもグローバル変数ですよ
307 名前：名前は開発中のものです。 mailto:sage [2008/06/07(土) 16:36:21 ID:k73DxxZ1]: >>305
型や引数を捨てちまうから結果的にそんな感じで組むしかないだろう
別に使わなくても強引にキャストしてタイプみてクラスの型判別して
switch caseで処理分けてなんてやってる手間みると
遊んでないで真面目に仕事しろよってマジで思う
308 名前：名前は開発中のものです。 [2008/06/08(日) 00:00:30 ID:HvoeC0NO]: GOFパターンの利点と欠点を理解して考えて使ってる奴と
利点と欠点を理解せず考えなしに、使い方だけは知っているGOFを使ってる奴の違い

タスクシステム信者は後者
他人の権威や威光を振りかざして他人に自分をよく見せかけたい奴や
理解してないけど使ったら自分の理解を超えた何かが得られるに違いないと
考えることを放棄している奴

理解できてないからメリットを説明できないので、揚げ足取りだけ
中立だと宣言して安全な場所から攻撃する
部分的にタスクシステムも使うべきだと譲歩して話をそらす
309 名前：名前は開発中のものです。 [2008/06/08(日) 00:57:24 ID:reXzLmVa]: パターンてのは「誰かが考案した画期的な設計」じゃなくて
「普通に作ってたら誰でもこうなる」の最大公約にすぎない。
最大公約にすぎないので、各々のシステムに合致するとは限らないし
不満点も出るだろう。パターンは改造する事が前提になってるんだから当然だ。

とGOF本に書いてあった。

タスクシステムもある種のゲームプログラムのパターン
310 名前：名前は開発中のものです。 mailto:sage [2008/06/08(日) 03:50:08 ID:C6EIFH9z]: タスクシステム厨は後退戦を始めると必ず「タスクシステムはパターン！」とか絶叫する。
リスト巡回UPDATE、僕のforeach、オナニーパターン等の強烈な説得力と妥当性の前では
全くの無駄な抵抗と言える
311 名前：名前は開発中のものです。 mailto:sage [2008/06/08(日) 03:57:53 ID:gLC0FzQF]: なんでタスクシステムスレで吠えるんだろう
アンチってやつか
ベクトルが違うだけで、信者と変わんねえな
312 名前：名前は開発中のものです。 mailto:sage [2008/06/08(日) 05:42:55 ID:19xi0Pci]: ここのトピックはタスクシステムじゃなくて
タスクシステム厨がいかなるものかポエムを投稿する場所
らしいよ最近は

たしかに「ここは○○パターンを使いました。エッヘン」ってやつとか
どうタスクシステムを導入するかみたいな議論があったりとかするけど
まぁ初心者なんだし生暖かく見守るしかないだろ
少なくともこき下ろして楽しいほどの権威も威光もないぞ

もしかして自戒をこめて過去の自分を攻撃してるのかな？
313 名前：名前は開発中のものです。 mailto:sage [2008/06/08(日) 06:07:00 ID:7MPd/8c6]: >>309
が後者な
本に書いてあったからって言って、考えようとしない
メリットもデメリットも理解できてない
マイナスイオンも科学だと言ってる連中と同じレベル
本当のことの中に嘘を混ぜて正当化しようとしている
314 名前：名前は開発中のものです。 mailto:sage [2008/06/08(日) 06:39:27 ID:7MPd/8c6]: 議論にすらならない、不毛だ
タスクシステムという言葉を肯定的に使う奴は、例外なく設計のセンスがない
これだけが唯一の事実だ
315 名前：名前は開発中のものです。 mailto:sage [2008/06/08(日) 06:41:40 ID:C4yVvUkh]: >>190 で紹介されている Protothreads、マクロ展開された後のコード見て気絶...
ついでに、ウェブページ右の news のリンク先がまた面白かったり。
316 名前：名前は開発中のものです。 mailto:sage [2008/06/08(日) 08:55:38 ID:uXx0W8YJ]: >>314
おお、久々にわかる奴みた

>タスクシステムという言葉を肯定的に使う奴は、例外なく設計のセンスがない
これ同意
まず、その辺にあるタスクシステムのサンプルみて
拒絶反応がないところがプログラマとしてのスキルが低いよな

強引で意味不明な型キャスト、引数消滅、グローバル変数使いまくり、
誰かに説明してもらわなわからん基本構造、一覧でも作成しないとわからない処理順序と
ちょっと見ただけで俺は吐気がするんだが・・・
317 名前：名前は開発中のものです。 mailto:sage [2008/06/08(日) 16:05:28 ID:03Qtljvd]: j自演乙ｗ
318 名前：名前は開発中のものです。 mailto:sage [2008/06/08(日) 22:25:17 ID:SDe8+kDd]: >>315
PT_BEGIN が switch(xxx) { とかに展開されるよな。

アイデアは面白いけど、ローカル変数は保持されないわけだし、制御の流れが変わるし、
まったく別の言語として扱うしかなさそうだ。
319 名前：名前は開発中のものです。 mailto:sage [2008/06/10(火) 15:11:17 ID:uFRpudfY]: frgm.jp/ （フリーソフトで面白いゲームまとめサイト）（新）
やっと復活しました。好きなゲームに投票できます。

海外フリゲ（？）特集
frgrgnd.blog99.fc2.com/　自由遊戯黙示録フリーゲーム
www.gametunnel.com/ 　game tunnel
www.tigsource.com/ 　TIGSource
320 名前：名前は開発中のものです。 mailto:sage [2008/06/13(金) 10:11:18 ID:FGpNXRkP]: どういう判定基準で自動投稿してんだ
この糞スクリプトはｗ

[ 新着レスの取得/表示 (agate) ] / [ 携帯版 ]

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