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

**名前は開発中のものです。** · 2009/05/07(木) 13:33:06

タスクシステムについての議論、相談、質問、雑談などのスレです

part6 http://pc11.2ch.net/test/read.cgi/gamedev/1238725539/
part5 http://pc11.2ch.net/test/read.cgi/gamedev/1234977661/
part4 http://pc11.2ch.net/test/read.cgi/gamedev/1233459490/
part3 http://pc11.2ch.net/test/read.cgi/gamedev/1226199100/
part2 http://pc11.2ch.net/test/read.cgi/gamedev/1196711513/
part1 http://pc11.2ch.net/test/read.cgi/gamedev/1173708588/

・タスクと呼ばれる実装は、非常に多岐に渡ります
　古典タスクシステムについての話題は「>>2」と明示してください
　そうでない場合はカスタム版であることを明示してください

・人を憎んで言語を憎まず

**名前は開発中のものです。** · 2009/08/08(土) 22:53:47

>>815
> どんなコメント（存在意義・使用目的の説明）をつけていますか？
”コンストラクタ”とか”デストラクタ”とかコメントつけないのと同じ意味でたぶんつけんけど。
あえてコメントをつけるなら”タスクシステム”

> 具体的に何と比較してどの点が簡単になるのでしょうか？
これは質問がおかしい。
タスクシステムを使う人に対して何かと比較して質問したいなら
質問側で具体的な「タスクじゃない何か」を比較対象として出すべき。
悪魔の証明じゃないんだから。

**名前は開発中のものです。** · 2009/08/08(土) 23:32:51

> どんなコメント（存在意義・使用目的の説明）をつけていますか？
そもそも存在「意義」・使用「目的」はソースのコメントで書くものじゃないだろ
引数とか戻り値とかの使用「方法」なら書くが・・・

**名前は開発中のものです。** · 2009/08/08(土) 23:38:26

>>816
ありがとうございます。

> タスクシステムを使う人に対して何かと比較して質問したいなら
> 質問側で具体的な「タスクじゃない何か」を比較対象として出すべき。

「何かと比較して質問したい」わけではありません。

何と比較して簡単になると言っているのか、という質問をしているので、
比較対象は回答として挙げられるものと思っています。

**名前は開発中のものです。** · 2009/08/08(土) 23:41:42

>>817
そうですか。コメントとして質問していては望む回答は得られないようですので、
少し質問を変えさせてもらいます。

「タスクシステム」の主要な部分となる class Task や TaskSystem などについて、
どんな存在意義・使用目的の説明をされていますか？

たとえばライブラリのドキュメントなどに記載されるような内容を想定しています。
よろしくおねがいします。

**名前は開発中のものです。** · 2009/08/08(土) 23:43:07

>>818

> 「何かと比較して質問したい」わけではありません。
> 何と比較して簡単になると言っているのか、という質問をしているので、

自分の質問を見返しておかしいとおもわないかな・・・？

**名前は開発中のものです。** · 2009/08/08(土) 23:49:50

>>819
> 「タスクシステム」の主要な部分となる class Task や TaskSystem などについて、
> どんな存在意義・使用目的の説明をされていますか？

>>2 のリンク先の方が詳しく図付きで説明してあるんでそっち見てくれ。
これを見て存在意義と使用目的が理解できんなら掲示板で説明しても理解できるとは思えん・・・

**名前は開発中のものです。** · 2009/08/08(土) 23:51:01

俺も質問していい？
PCでゲーム作る場合、ディスプレイのリフレッシュレートってまちまちでしょ。
(最近は液晶が普及したおかげで大概60Hｚだが)
でもゲームのロジックは60Hzとかで固定したいでしょ。
(数値解析の精度が変わったり壁抜けしたりするのが嫌だから)
それで、ディスプレイのリフレッシュレートとゲームロジックの周期のギャップを埋める仕組みが
必要だと思うんだけど、みんなはどうしてる？

http://spitfire.client.jp/program/fps.html

**名前は開発中のものです。** · 2009/08/08(土) 23:54:31

>>820
すいません。見返してみましたがおかしいと思うところはありませんでした。

**名前は開発中のものです。** · 2009/08/08(土) 23:55:07

>>822
ゲームによる。
ゲーム中の計算時間単位をリフレッシュレート側の更新速度にあわせる方法。
リフレッシュレートは無視して固定FPSでやる方法（ティアリングは無視）
ゲーム計算処理は固定FPS、表示だけリフレッシュレート依存。

とかとか・・・

**名前は開発中のものです。** · 2009/08/08(土) 23:59:03

>ゲーム計算処理は固定FPS、表示だけリフレッシュレート依存。

これ面倒なんだよね。

**名前は開発中のものです。** · 2009/08/09(日) 00:00:17

>>823
すいません。何か人工無能と会話してるみたいであなたと話が通じる気がしません・・・

**名前は開発中のものです。** · 2009/08/09(日) 00:17:45

>>821
ありがとうございます。

改めてひとつずつ見てみることにします。

**名前は開発中のものです。** · 2009/08/09(日) 00:20:01

http://homepage3.nifty.com/moha/prog_realtime.html
> さて、話は前後しますが「処理」の部分を状態によって切り替える手法についてです。
> 最も単純な方法はおそらく、状態に番号をつけてif文やswitch～case文で切り替える方法でしょう。
...
> そこで、タスクという手法が登場します。

このページで「タスク」の存在意義を示しているのはこの部分のようです。

しかし、これは仮想関数によって解決される問題だと思います。
むしろ仮想関数のほうが言語のサポートによって型安全に書きやすい分、
適切だと思います。

これだけのことのために以下のような注意事項に悩まされてしまうのでは、
まったく割に合わないと思います。
http://homepage3.nifty.com/moha/prog_attention.html

**名前は開発中のものです。** · 2009/08/09(日) 00:23:59

http://www5f.biglobe.ne.jp/~kenmo/program/task/task.html
> タスクシステムを採用すると、以下のメリットが得られます。
>
> * CPUの負荷を減らすことができる
> * メモリの使用量を節約することができる
> * ゲームを開発するのに適したシステムで開発できる
>
> デメリットとしては、
> 現代的なプログラムに比べると、分かりにくい部分があります。
>
> ジャンプ処理や、関数ポインタを使用するので、
> 泥臭いコードになりがちです。

メリット・デメリットがちゃんとまとめられていて助かりますね。

CPU 負荷については、関数ポインタによる分岐が多発する分、最近の CPU では
逆に不利になることが考えられます。

メモリの使用量については、独立したメモリプールの仕組みを使えば、
挙げられているタスクシステムのデメリットは回避しながら望む結果が得られます。

「ゲームを開発するのに適したシステム」については、残念ながら何のことか
わかりませんでした。（誰か解説してもらえますか？）

最後のやつがわからないままではありますが、総じてデメリットのほうが
大きいように思います。

**名前は開発中のものです。** · 2009/08/09(日) 00:25:49

>>828
ここに出てる問題で
仮想関数を使って解決できるのはワークオーバーだけ、ということを理解できたら
だいぶタスクが理解できてる、と言える。

先走って半端な理解のまま結論出さずに、ちゃんと理解してから結論だしな。

**名前は開発中のものです。** · 2009/08/09(日) 00:27:32

仮想関数もタスクシステムも同類で、まともなやつは使わないんだよなこれが。

**名前は開発中のものです。** · 2009/08/09(日) 00:29:23

> * CPUの負荷を減らすことができる
> * メモリの使用量を節約することができる
> * ゲームを開発するのに適したシステムで開発できる

マジでこれどうやって検証したんだろうか？

**名前は開発中のものです。** · 2009/08/09(日) 00:36:03

>>829
> CPU 負荷については、関数ポインタによる分岐が多発する分、最近の CPU では
> 逆に不利になることが考えられます。
関数ポインタによる分岐と通常関数による分岐、仮想関数による分岐
CPU上でどんな動作をしているのかイメージできてるのかな・・・？

> メモリの使用量については、独立したメモリプールの仕組みを使えば、
> 挙げられているタスクシステムのデメリットは回避しながら望む結果が得られます。
メモリプールを使ってタスクと同じことができるタスクのデメリットが無いシステム
ってやつを君が作ることが出来れば、誰もタスクシステムなんて使わなくなると思うよ。

タスクシステムなんて使ってゲーム作ってる現役ゲームプログラマの馬鹿どもに作ってみせてやりなよ。
君の素晴らしいシステムをｗｗ

**名前は開発中のものです。** · 2009/08/09(日) 00:41:10

>タスクシステムなんて使ってゲーム作ってる現役ゲームプログラマの馬鹿ども
いないから。

**名前は開発中のものです。** · 2009/08/09(日) 00:43:03

>>834
仮想関数もタスクシステムも都市伝説、君か。
久しぶりにアンチらしいアンチが出没したな。

**名前は開発中のものです。** · 2009/08/09(日) 00:47:59

http://codezine.jp/article/detail/297?p=1
> 　タスクシステムとは、これら複数のタスクを管理する仕組みであり、現在でも
> プロの現場で用いられています。長所は次の通りです。
>
> * ジャンルを問わず様々なゲームに適用できる
> * 並列処理をうまい具合に実現できる
> * ゲームの流れを自然な形で表現できる
> * 大規模なゲームも開発できる
> * タスクごとに独立しているため、複数人で開発できる
>
> 　一方の短所は、タスクシステムの歴史が古いことに起因する、高すぎる自由度です。
> さまざまな実装方法があり、またオブジェクト指向が一般的ではなかった時代の
> 手法なためか、スパゲティプログラムや、データの隠蔽化が不十分なプログラムと
> なっている例も見かけます。

いちおう長所・短所をまとめて書いてくれてはいますが、どれもあまり
具体的ではなく、はっきりしません。

しょうがないので２ページ目まで見られる記事本文を読みすすめて見ました。

**名前は開発中のものです。** · 2009/08/09(日) 00:49:09

http://codezine.jp/article/detail/297?p=1
> このようにタスクの削除にメモリ領域の解放を伴わないことによって自滅も
> 可能となり、プログラムの見通しが良くなる、という利点があります。

delete this できることが最初にあげた「ゲームの流れを自然な形で表現できる」
などの根拠になっているようですが、ここでタスクシステムとして紹介されて
いるような仕組みが無くとも delete this は可能です。

http://codezine.jp/article/detail/297?p=2
operator new/delete の独自定義も行っているのですが、本来メモリ割り当てと
解放しか行わないはずのこれらの処理の中でコンストラクタ・デストラクタ
相当の動作をしており、 C++ のオブジェクトモデルから外れてしまっています。

なにやら「デフラグ」という見慣れない機能があったのですが、実装を見ると
memmove() しています。これでは派生クラスのメンバには POD しか持てません。

どうも、この筆者は C++ に対する理解が不十分なようです。

おそらく std::list<Task> とでもすれば済みそうな仕組みを、標準ライブラリを
知らなかったがために一生懸命組み上げてしまった、その中で、自分が最近学んだ
珍しい機能を使ってみた、というものぐらいにしか見えません。

**名前は開発中のものです。** · 2009/08/09(日) 01:11:47

面白い理解のしかたをするねぇ

その理解で言えば
A)タスクシステム使ったゲームは都市伝説で存在しない
B)タスクシステム使ったゲームを作るゲームプログラマは君よりレベルが低い馬鹿
C)タスクシステムの使いどころを理解できない君が馬鹿

のAかBになりそうだけど・・・
正解はどれだと思う？ｗｗ

**名前は開発中のものです。** · 2009/08/09(日) 01:22:20

ID:4TaFdjmkの言うことは正論のようで正論でない。
本にはわからないだろうが。

**名前は開発中のものです。** · 2009/08/09(日) 01:23:30

本人にはわからないだろうが。

**名前は開発中のものです。** · 2009/08/09(日) 01:31:04

http://web.archive.org/web/20041012011316/www.hh.iij4u.or.jp/~peto/Games/task_02.html
> タスクとは、いったい何なのでしょう？辞書や用語辞典を引いても、何の手助けにもなりません。
> タスクを一言で説明すると、
>
> ・実行アドレスを含む汎用ワークの連結リスト
>
> となるでしょうか。

仮想関数、標準コンテナの組み合わせで実現するのがよさそうです。

> 冒頭でも述べたように、タスクとは非常に原始的な処理です。
> 非常に少ない（数キロ～数十キロバイトの）ワークエリアと、
> 至って非力な（数メガヘルツの）CPUパワーを有効活用する為のテクニック、
> それがタスク処理なのです。

そういうことなのでしょう。

関数を切り替えることで状態を切り替えるという手法は今でも適切に応用できる
場面があると思います。しかし、それを実現するためにシステムとして提供する
ところはありません。

**名前は開発中のものです。** · 2009/08/09(日) 01:42:54

>仮想関数、標準コンテナの組み合わせで実現するのがよさそうです。
何で実現してもタスクシステムはタスクシステムだろうに。

**名前は開発中のものです。** · 2009/08/09(日) 01:52:03

ひととおり読んで、これらのような「タスクシステム」の存在意義や使用目的はすべて
過去のものであると思いました。いずれも古い記事だということからも、そのように
考えられます。

このような仕組みを現在でも新規で採用するようなことがあるとすれば、これらの
記事に挙げられているようなメリットを自分の対象環境で検証していないとか、
デメリットを無視しているだとか、あるいは C++ による標準的な手法を知らないだとか、
何かしら見落としがあるのではないかと思います。

一連の書き込みについて、「そこは間違っている」だとかいうことがあれば、
具体的にどこが間違っていて、正しくはこうである、というような指摘をもらえると
助かります。

**名前は開発中のものです。** · 2009/08/09(日) 01:56:32

>あるいは C++ による標準的な手法
↑詳しく

**名前は開発中のものです。** · 2009/08/09(日) 02:03:19

一番肝要そうなところをはしょるね

**名前は開発中のものです。** · 2009/08/09(日) 02:06:41

>>843
「残念ながら何のことかわかりませんでした。（誰か解説してもらえますか？）」
自分で言ってるように、これが君のタスクに対する理解ってことでいいんでない？

理解できなかったのに結論だけ出るのはおかしいってことも分からないのかも知れないけど
タスクは使えないって結論ありきで、欠点以外は耳に入らないみたいだから誰にも君に解説
できる人は居ない。

**名前は開発中のものです。** · 2009/08/09(日) 02:08:50

>>844
>> あるいは C++ による標準的な手法
> ↑詳しく

switch による分岐が嫌だという時には仮想関数（ State パターンなど）を使う。
リンクリストなどの動的コンテナは標準ライブラリなどを使う。
メモリ管理のカスタマイズはコンテナのアロケータを差し替えたり
operator new/delete を独自定義するなどして行う。

一連の記事を読んでて思い当たったのはこんなところです。

**名前は開発中のものです。** · 2009/08/09(日) 02:18:19

>>837
そのcodezineの記事は批判が多いことと
仮想関数やstd::listを使ったものも
タスクシステムとみなす一派もいるらしいことを
付け加えとく。

スレ毎に話題がループしてる気がするんだが
このスレの過去ログ倉庫どっかに無いかな。

**名前は開発中のものです。** · 2009/08/09(日) 02:44:31

>仮想関数やstd::listを使ったものも
>タスクシステムとみなす一派もいるらしいことを

俺のことだな。
だってアーキテクチャ的には同じものだからな。
樹海に行くのに徒歩で行くか車で行くか程度の差でしかない。
どちらにしろ糞は糞ってこった。糞に到達するのが早いか遅いかの議論に興味はないね。

というわけだ>>847

俺の中では ID:4TaFdjmk もタスク一派かな。
なんでかって？そりゃ思考のアーキテクチャがタスカーと同程度だからだ。
だってお前の言ってる事って、要は、STL使ったり仮想関数使った方が、
codezineの記事の方法よりも、もっと早くタスクシステムを作れますよ、って事だろ。
否定的な立場をとりつつも、結局タスクシステムを作るのを手助けしちゃってるじゃないか。
本当はどうしたかったんだ？
タスクシステムの構築を加速させるのがお前の目的だったのか？
でも案外それがお前の本質なのかもな。
こんなスレ覗くぐらいだし、本当はお前もタスクシステムが好きなんじゃないか？
タスクシステマーはお前と同程度の人間だから、みんな暖かいぜ？
朱に交われば赤くなるってやつだな。

**名前は開発中のものです。** · 2009/08/09(日) 03:38:37

俺は下のどっちかで動いるアプリはタスク一派とみなす
（A)毎フレーム処理
（B)コルーチン処理

**名前は開発中のものです。** · 2009/08/09(日) 04:09:03

std::listで実装する場合って親クラスのポインタを入れるの？
なんかもったいないような

**名前は開発中のものです。** · 2009/08/09(日) 08:53:19

最近のゆとりプログラマ
stlは使えるけど、自分でlist実装できません。ってのが出没して侮れん・・・

昔はlistなんて誰でも同じような実装何度も繰り返して、さすがに無駄だろってstlが生まれたんだが
stl以降のゆとりプログラマにとってはlistは何かすごく高尚なアルゴリズムで自分で実装なんて考えられないらしい。
だからstlに存在しないデータ構造はC++では使えないと思ってる新人プログラマがいたりする。

車輪の再発明は無駄だが、便利になりすぎると使う人間が劣化するのはどこでも一緒なのかね。

**名前は開発中のものです。** · 2009/08/09(日) 09:09:15

シリコンウエハー一枚も満足に作れないような奴が
パソコンで動くソフトウェアを作ろうなんて
ちゃんちゃらおかしいということですね。わかります。

**名前は開発中のものです。** · 2009/08/09(日) 11:01:23

引数の重要性がわかってない人間の使う糞道具
グローバル変数使ってやりとりするのが好きなんだろ？
でもそれってわかってくると恥かしいぜｗ

**646** · 2009/08/09(日) 11:22:11

>>807
>>>646 にいたっては自問自答で質問にすらなってない

まぁそりゃそうだわなー。俺は>>628とお話してたわけだからねぇ
君にとっちゃ関係ないお話なんだからいきなり>>646を引っ張ってきて
質問に答えてって言われても困るだろうねぇ

>>808
君は>>646に返答してくれた>>650かな。もしそうなら
答えにくい話に付き合ってくれてありがとうねぇ
でも答えにくいのは俺が自問自答したからじゃないんだよ
他人に考えを伺う際にこちらの考え（or解釈）も添えただけだからねぇ
俺の考え（or解釈）との一致不一致が答えにくさに作用するはずないよねぇ
考え（or解釈）が一致するから答えにくい　　→　嫌われちゃったかねぇ
考え（or解釈）が一致しないから答えにくい　→　気にすんな。違って当たり前だ

ローカル用語だからねぇ

**名前は開発中のものです。** · 2009/08/09(日) 11:27:50

>>854
また君か。懲りないねどうも

**名前は開発中のものです。** · 2009/08/09(日) 11:49:06

なんでこんなもん使うかってグローバル変数での受け渡し方法しか知らないからだろ？
普通のプログラムもまともに組めないままＰＧ気取ってる糞がこんなもんに騙される

**名前は開発中のものです。** · 2009/08/09(日) 12:10:00

>>852
HashMapは自分で作れる自信ないわ俺

**名前は開発中のものです。** · 2009/08/09(日) 15:32:56

>>858
おいおい、せめてB+-treeとかにしてくれよ。
http://pfp7.cc.yamaguchi-u.ac.jp/~ichikawa/lecture/yamanashi-u/01/resume/node10.html

>>854
真性現る。

**名前は開発中のものです。** · 2009/08/09(日) 15:33:21

なんでそんなこと言うかってグローバル変数と引数しか受け渡し方法を知らないからだろ？

**名前は開発中のものです。** · 2009/08/09(日) 16:04:19

>>860
それ以外の方法はどうせグローバル変数と似たような問題が発生するので知っていても無意味だよ
引数で渡すか、グローバル変数で渡すか
クラスで強引にまとめてメンバやスタティック変数に別関数の引数から渡して
目的の処理の関数は引数を通さないってのは結局グローバル変数と同じ問題が発生してしまうので考慮に値しない

ちなみにここで問題っていうのは更新するものが呼び出し元から見えなくなってしまう状態な

**名前は開発中のものです。** · 2009/08/09(日) 18:18:04

プログラム中に予め一つしかないことがわかっている物はグローバル変数で問題ない。
例：C言語の標準入出力

**名前は開発中のものです。** · 2009/08/09(日) 18:24:35

143 名前：名前は開発中のものです。[sage] 投稿日：2009/06/05(金) 23:54:01 ID:2tFnphs7
もしも、引数君がwin32apiを設計したら。

GetMessage( &dosv, &x86, &win32, &process, &thread, &queue, &msg, NULL, 0, 0 );

めんどくせーし、可読性も落ちる。バグの元だな。

**名前は開発中のものです。** · 2009/08/09(日) 18:40:25

>>862
ダメだろ
あるプロジェクトのソースをあるプロジェクトで使いたいときに
影響範囲がわからなくてまるで木の根っこみたいにプロジェクトにソースがひっついてしまって
カプセル化の意味がまったくなくなってしまう
グローバル変数なんか使ってしまったら必要なデータがなにかわからないだろ
これを引数でいれておけば引数をみるだけで簡単に必要なものが絞れるってわけよ

また、これは別にプロジェクトから移動させるときだけじゃなくて
構造を組み替えなければならないときにも迂闊に分離できない
つまり、仕様変更に弱いプログラムになってしまうんだよ

**名前は開発中のものです。** · 2009/08/09(日) 18:49:44

似たような構造で失敗してるもんに

DirectXのSetRenderState関数があるな
これさセットしたもんが何にどう影響するのかわからないんだよな
だから固定シェーダとか使うなよボケってみんなからフルボッコにされる

**名前は開発中のものです。** · 2009/08/09(日) 19:58:51

>木の根っこみたいにプロジェクトにソースがひっついてしまって
引数で渡しても引っ付くことには変わりないだろ。
だってそれはそのアプリの仕様なんだから。

>プロジェクトにソースがひっついてしまって
>カプセル化の意味がまったくなくなってしまう
カプセル化(データ隠蔽)の意味をわかっていない。モジュールの結合度が高まることとカプセル化は関係ない。

>グローバル変数なんか使ってしまったら必要なデータがなにかわからないだろ
わからなくていいからグローバル変数なんだ。
サブシステムというものはそういうものだ。

>また、これは別にプロジェクトから移動させるときだけじゃなくて
>構造を組み替えなければならないときにも迂闊に分離できない
これに限って言えば、グローバル変数使ってるほうが構造の組み換えには強い。
引数の引き回しを考えなくて良いからな。
グローバル変数は柔軟すぎて何でも出来ちゃうからこそ問題なんだろうに。

>DirectXのSetRenderState関数があるな
>これさセットしたもんが何にどう影響するのかわからないんだよな
セットした後、使い終わったら元に戻さないからそういうことになるんだろ。
ちなみにID3DXEffectはエフェクト内での設定を処理後に自動で元に戻してくれる。
自動で元に戻してくれるってだけで、SetRenderStateと仕組みは同じ。

**名前は開発中のものです。** · 2009/08/09(日) 20:12:00

だいたい、俺らはWin32が内部で持ってる変数なんて知らないし、知る必要もない。
Cの標準ライブラリが内部で持ってる変数ですら知らない。
標準出力の正体なんか知らなくてもprintfは使える。
printpolygon(座標)でポリゴンが描画されたとしてもなんら困らない。
既に我々はグローバル変数的なサブシステムの上で
プログラムを書いているし、走らせているということ。

**名前は開発中のものです。** · 2009/08/09(日) 21:00:30

>>867
それはカプセル化であって、グローバル変数とは違うだろｗ
Win32が内部でもってる変数を外から書き換えたらどうなるか想像つくだろ
それがグローバル変数ってことだろうがｗ

**名前は開発中のものです。** · 2009/08/09(日) 22:02:36

>>868
Win32が”内部で”持ってる変数はグローバルじゃないだろ
コンテキストなりで内部状態を持ってるわけだ。

引数で全コンテキスト状態を渡さなくてもコンテキスト変更の入り口と出口さえ押さえられれば
安全に運用できる・・・ってのは引数君には理解できないレベルの話か。

**名前は開発中のものです。** · 2009/08/09(日) 22:44:53

だから要するに、Win32サブシステム自体が一塊のグローバル変数の如く機能しているという。
だからプログラムのどこからでもWin32APIを呼び出せる。

**名前は開発中のものです。** · 2009/08/10(月) 00:21:45

そうなんだよね
だからWin32apiも呼べるからってどこでも読んじゃダメだ
せめて使う必要のある場所とない場所を区別するために
windows.hを呼ぶソースと呼ばないソースをわけるぐらいはしないと
馬鹿は全部まとめた総合ヘッダーとか作っちゃうけど本当はそんなことやっちゃダメだ

**名前は開発中のものです。** · 2009/08/10(月) 00:30:39

ID:xyBM8L8Y は言葉遊びが好きだねぇ

>>810
既に指摘されてるようだが
「具体的」と「主観的」は排他的な関係ではないねぇ

>>812
＞主観的でいいなら
＞>>674
＞でこのスレは終わってないか？

うんにゃ。君が>>674の見解に100%の見解の一致があるというなら
それは君と>>674との間の一致にすぎないんだねぇ
権威不在のローカル用語、タスクシステム。これの共通理解は朧げだねぇ

例えばアンチを装う歪んだ性癖のあるファイルシステム君 ID:6uucu48D。
この珍獣は自前のチンカスタスクシステムの常識をこのように述べた（>>765）

　『タスクシステム自体もタスク間でのコミュニケーションが苦手という問題を抱えてるが』

実に愉快な「ボクのチンカスシステム固有の事情」を赤裸々に語ってくれたわけだが
君はどう思うね？おそらく見解は異なるだろう

例えばDCAJの調査報告がタスクシステムについて言及したわけだが
玉虫色の内容にならざるを得なかったのは示唆に富んでるよねぇ

あのパートを担当した方はジャンケンで負けたんだろうかねぇ
とんだババを引いて大変だったねぇ

**名前は開発中のものです。** · 2009/08/10(月) 00:54:11

>>871
＞馬鹿は全部まとめた総合ヘッダーとか作っちゃうけど本当はそんなことやっちゃダメだ

また引数君（総合ヘッダー君）の告解の時間が始まったのか
ここは君の懺悔室かね

**名前は開発中のものです。** · 2009/08/10(月) 01:11:23

>>816
>> 具体的に何と比較してどの点が簡単になるのでしょうか？
>これは質問がおかしい。

特におかしいとは思えないねぇ。簡単というのは所詮は相対的な表現だからねぇ
何らかの比較対象・基準値があって、それよりも簡単or複雑（困難）という表現を
使うものだからねぇ。そうだろう？

>タスクシステムを使う人に対して何かと比較して質問したいなら
>質問側で具体的な「タスクじゃない何か」を比較対象として出すべき。
>悪魔の証明じゃないんだから。

不存在の証明を要求してるわけじゃないから悪魔の証明は関係ないと思うねぇ

**名前は開発中のものです。** · 2009/08/10(月) 08:53:44

>>872
> それは君と>>674との間の一致にすぎないんだねぇ
それが「主観的」ってもんでしょ。
主観的な回答求められてるのに客観的じゃないからダメってのはねぇ・・・？

**名前は開発中のものです。** · 2009/08/10(月) 12:49:17

またそうやって逃げるのか卑怯者

**名前は開発中のものです。** · 2009/08/10(月) 15:11:50

>>875
詭弁論者きもい

**名前は開発中のものです。** · 2009/08/11(火) 00:22:33

詭弁なのか図星なのか・・・

**名前は開発中のものです。** · 2009/08/11(火) 01:10:42

明らかに詭弁だろ
これで技術者だと思ってる糞をマジで叩きだしたい

**名前は開発中のものです。** · 2009/08/11(火) 01:19:59

>>803-821 あたりもひどかったが、同じ人なのかな。

**名前は開発中のものです。** · 2009/08/11(火) 01:29:35

なんでタスク信者はいつまでたってもメリットとその説明ができないの？ｗ

**名前は開発中のものです。** · 2009/08/11(火) 01:46:54

なんでタスクアンチはいつまでたっても論破できないの？ｗ

タスク使ったプログラムなんて、どうやっても俺専用クソースになるのがわかってるから
「ここはこう組んだほうがいい」と代案ひとつ出せば勝ちなのに。
圧倒的兵力差でも勝てない米軍見てるみたいでイライラする。

**名前は開発中のものです。** · 2009/08/11(火) 01:59:01

>>882
> 「ここはこう組んだほうがいい」と代案ひとつ出せば勝ちなのに。

「ここは」といって代案を出すには、まず「タスクシステム」を使ったコードが無いと
できないと思うんだけど、どっかにまとまった量のサンプルが落ちてないかな？

これまでの例で言うと、典型的と思われる問題のわかりやすいコードを
アンチタスクシステムな人が作って置き換えの例を出しても、
「それは前提にしてるそのコードのレベルが低いだけ」って言う流れになってた。

**名前は開発中のものです。** · 2009/08/11(火) 03:09:31

それが詭弁のカラクリだしな

**名前は開発中のものです。** · 2009/08/11(火) 06:16:45

>510 名前: 名前は開発中のものです。 Mail: sage 投稿日: 2009/02/14(土) 08:31:15 ID: V87nWtWS
>http://kansai2channeler.hp.infoseek.co.jp/cgi-bin/joyful/img/8878.zip
>ちょっと変わったタスクシステム出来たよ。
>なにが違うの？
>・タスクはデータ構造ではなく制御構造。
>・タスクはオブジェクトではない。
>・タスクはデータを持たない。
>・タスクはオブジェクト間での相互作用を記述する。
>・タスクは関数やメソッドの中に定義する。
>ちゃんとデバッグしてないから多分バグある。
>サンプルプログラムは星の間に働く万有引力のやつ。
これをサンプルにすればいいんじゃね？

**名前は開発中のものです。** · 2009/08/11(火) 08:53:56

>>883
> 「タスクシステム」を使ったコードが無いと
つまりアンチはタスクシステムを使ったコードがわからない、というレベルか
タスクの悪いところがわかるからアンチ、とか以前の問題じゃん・・・

**名前は開発中のものです。** · 2009/08/11(火) 08:57:11

そもそも掲示板でコードを出して説明、なんてめんどくさすぎてやらんだろ。
後輩指導とかなら仕事だし、後々自分が楽になるから面倒でもやるけど
今までのスレ読んでも理解できません。自分で考えることもできません。
って明らかにプログラマとして見所の無い赤の他人にそこまで手間かけるほど
暇で親切な人間なんていないよ・・・

**名前は開発中のものです。** · 2009/08/11(火) 17:28:23

まーた1行だけ抜き出して関係ないレッテル張ってるよこのひと

**名前は開発中のものです。** · 2009/08/11(火) 19:04:11

全然関係無いことを言い出すのやめてほしいよね

**名前は開発中のものです。** · 2009/08/12(水) 11:24:27

preemptive schedular = タスクシステム

**646** · 2009/08/12(水) 23:30:28

preemptive scheduler？それnon-preemptiveの間違いじゃないかねぇ

>>2の「システム」は侵入式連結リストを定周期でナメてるだけだからねぇ
同期的・協調的に実行待ちの要素を順次実行をしているだけなんだねぇ
プリエンプションに必要な実行コンテキストの保存には一切関与しないし
プリエンプティブなスケジューリングなど一切していない

**名前は開発中のものです。** · 2009/08/13(木) 00:46:20

変なのが沸いて困るな

**名前は開発中のものです。** · 2009/08/13(木) 00:50:55

「タスクシステム」の機能としてよく挙げられる以下のような手法は、それぞれ
単体で有用な場面があることに異論のある人はいないと思う。

　・連結リスト構造
　・関数ポインタ（または仮想関数、またはその両方）
　・メモリプール（あるいはオブジェクトプールなど）
　・ツリー構造
　・型や名前などのキーによるオブジェクトへの間接アクセス（および列挙）

「タスクシステム」というと、これらの手法（他にもあるかも）を複数
組み合わせたもので、システムと呼ぶくらいにプログラム全体のベースとして
存在しているもの、ということになると思うんだけど、この解釈から外れる
ような「タスクシステム」を使ってるという人はいますか？

**名前は開発中のものです。** · 2009/08/13(木) 00:56:31

そもそも素のタスクシステム自体使ってる人がいない

**名前は開発中のものです。** · 2009/08/13(木) 01:00:33

>>887
あらら
その切り方だとこのスレの教えて君アンチは全滅だｗ
もう少し生暖かく導いてくれよｗｗｗ

**名前は開発中のものです。** · 2009/08/13(木) 01:36:18

>>893
タスクシステムなんてゲームの仕様の数だけ実装があるような
経験知の塊みたいなものを、「これがタスクシステム」「これはタスクシステムじゃない」
なんて線引きしても無駄じゃないかな。

まぁ、それがデザインパターンとか、形式知になった物しか使えないタイプの人間には
我慢ならない所なんだろうけど。

**名前は開発中のものです。** · 2009/08/13(木) 02:04:49

(　´д)ﾋｿ(´д｀)ﾋｿ(д｀ )

**名前は開発中のものです。** · 2009/08/13(木) 10:53:51

俺の言ったとおりだな。タスクシステマーは井の中の蛙で、他人の意見を聞こうとしない、
というより、理解できない池沼。
タスクシステムで作ったゲームは、自分勝手なタスク達がおのおのそれらしく振舞うことで成り立つ。
池沼のあつまり。
タスクシステマーにとっての天国。理想の社会像。

**名前は開発中のものです。** · 2009/08/13(木) 12:19:13

天才プログラマー要製ギプス
http://www.sun-inet.or.jp/~yaneurao/intensive/ggg/log1.html

>私が考える一番エレガントな方法とは、少なくともキャラクターは自立性が有ることです。例えば、
>　　　　new CMissile;
>とすればミサイルが生成され、あとはメインのプログラムからは、ミサイルについて意識しなくても済むような設計が理想です。

自立性があるのは結構だが、
最終的にはゲームとして成り立てるためにシステマティックに振舞ってもらわないと困るわけで。

一旦、個を確立させといて、あとから集団として意味づけするのは、
どう考えても2度手間だよな。

**名前は開発中のものです。** · 2009/08/13(木) 12:43:47

そもそも、キャラクタの自立性を確立するのはとても大変なこと。
やねうらおも自分で言ってる。

>たとえば、ホーミング弾にはＳＥが存在するとしましょう。
>前回、話したようにホーミング弾を担うクラスは自立性のあるクラスです。
>ホーミング弾が生成された瞬間にＳＥは鳴らないといけませんから、
>ホーミング弾のコンストラクタは、soundを読み込み、再生しようとします。
>すると、以下のような問題が浮上します。
>１．生成された瞬間にサウンドをファイルから読み込んでいたのではリアルタイム性が損なわれる

数々の困難を乗り越えて、やっとこさっとこキャラクタの自立性を確立したところで、
結局はゲームとしてシステマティックに振舞わせるために、
個々の自立キャラクタに集団としての意味づけをしなければならない。

もうやってること意味わからないってレベルじゃねーぞ。

**名前は開発中のものです。** · 2009/08/13(木) 12:51:52

だから自立性のあるキャラクタ云々がそもそもの間違い。
発想の一番最初から既に間違っている。
なので、どこまで行ってもうまく行かない。
何にもならない。無駄。

>私が考える一番エレガントな方法とは、「少なくとも」キャラクターは自立性が有ることです
↑キャラクタの自立性が発想の根本な人の例。
↑キャラクタには少なくとも自立性がなきゃ話にならないらしいです。
↑かわいそうな人です。

**名前は開発中のものです。** · 2009/08/13(木) 13:01:58

>841
概念と実装を混同してるよ。

**名前は開発中のものです。** · 2009/08/13(木) 13:32:36

だからプログラムうｐしろよ

**名前は開発中のものです。** · 2009/08/13(木) 17:07:38

>>901
> だから自立性のあるキャラクタ云々がそもそもの間違い。

違うね。それはゲームによるよ。そういう設計をしたほうがエレガントになることは十分ありうる。

**名前は開発中のものです。** · 2009/08/13(木) 19:37:31

>>904
あったま悪ぃｗ

**名前は開発中のものです。** · 2009/08/14(金) 01:11:32

>>898
アンチが何か意見言ったか？
メリット教えろってのは意見じゃなくて質問だろ。

あぁ、アンチの意見って引数以外認めないとか仮想関数はダメとか、あれのことかｗ
そりゃ誰も意見なんて聞かんわなｗｗw

**名前は開発中のものです。** · 2009/08/14(金) 01:21:18

>>905
お前、クルクルパーすぎるだろ

**名前は開発中のものです。** · 2009/08/14(金) 02:40:35

>>906
早くメリット言えよ
聞いてやっからよ

**名前は開発中のものです。** · 2009/08/14(金) 06:57:44

C#4.0でタスクシステムがサポートされる。
C# taskでくぐってみろ。

**名前は開発中のものです。** · 2009/08/14(金) 11:51:38

http://www.google.co.jp/search?q=System.Threading.Tasks
これか。

http://www.danielmoth.com/Blog/2008/12/introducing-new-task-type.html
処理単位ごとに全部 System.Threading.Thread 作ってたらメモリ消費や OS による
スケジューリングのオーバーヘッドが問題になる。
↓
System.Threading.ThreadPool で解決。でもそれだけじゃ終了待ちとかキャンセルとか
自分で実装する必要があって、いまひとつ使いにくい。
↓
新しいラッパー System.Threading.Tasks を作って解決。

メリットとか役割とか明確ですばらしいね。
それにひきかえゲーム屋のタスクシステムときたら、メリットひとつ挙げられやしない。

**名前は開発中のものです。** · 2009/08/14(金) 12:16:29

2chでその論法使うと詭弁扱いなんだよな。
問題の設定が恣意的で結果ありきだろと。

**名前は開発中のものです。** · 2009/08/14(金) 14:03:58

めっちゃ久しぶりにこのスレ来たんだけど、HSP厨はどこいったの？まだ元気？

**名前は開発中のものです。** · 2009/08/15(土) 09:49:08

>>908 >>910
メリットって初めから
>>2 のリンク先に書いてあるけど。
それじゃ理解できないから解説して欲しいのかな？

それは「メリット説明できない」じゃなくて
「説明されても頭悪いから理解できません」
ってことだろ。
まぁ >>887 だけどなｗｗ

**名前は開発中のものです。** · 2009/08/15(土) 10:36:40

理解できない＝自分が馬鹿
プライドが邪魔してこれが認められないから、アンチは粘着するんだろうな。
タスクシステムを否定しないと自分が馬鹿ってことを認めざるをえないから。

理解できる人なら、タスクシステムのメリット・デメリットを比較して
「このケースなら使うかも」とか「俺は別の方法でやるから使わんな」とか、使う使わないは別にして
粘着アンチにはなりえない。

**名前は開発中のものです。** · 2009/08/15(土) 14:45:15

ところが真実は、
　(タスクシステムが無駄だってことが)理解できない＝自分が馬鹿
　プライドが邪魔してこれが認められない
なんだよな。
そもそも、プライドという言葉が出てくる時点で既におかしい。
プライド云々はタスクシステムに依存している信派の理論であって、
もとより、タスクシステムに依存心の無いアンチには関係のない話。
そんなことすら分からない。
このように、タスクシステマーの精神構造のおかしさは随所ににじみ出る。

**名前は開発中のものです。** · 2009/08/15(土) 15:55:10

>>915
えっ？お前、タスクシステムのメリットわかんないの？馬鹿じゃねーのｗｗｗ