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

**名前は開発中のものです。** · 2009/02/19(木) 02:21:01

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

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」と明示してください
　そうでない場合はカスタム版タスクであることを明示してください

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

**ID:EEKBitmg** ◆HSP4mee/SU · 2009/03/14(土) 01:46:18

>>758
つーかお前、前>>510だろ。当たってる？当たってたらなんご褒美ちょうだい
チョー陰険だし、やたらどうでもいいことで噛み付いてくるし、顔真っ赤になると
言ってること滅茶苦茶になるから多分当たってるだろ。な。陰険アマチュア野郎。タスクシステム＝DB君。

俺が性格悪い？まぁアンタほどじゃないよ
>>730みたいな内容ゼロのハッタリゴミクズチンカスレスして悦に浸る中年には適わないね
俺が頭悪い？それ既出ジャン？>>355で既に認めてっからよく嫁カス。何今更言ってんだ

＞>>2では最初から並列動作なんか考えてないんだから

ま、この点でアンタとの争点ないのは分かってるから。せいぜい無視したら？
あんたさ、それが分かってるのに何でそこんとこで噛み付くの？俺が気に入らないだけだろ

**ID:EEKBitmg** ◆HSP4mee/SU · 2009/03/14(土) 02:33:21

>>766続き
連結リストのメモリ配置を整えましたー。速くなりましたーっていうけどさ
そんなことするならいっそのこと配列にしてダブルバッファリングしたほうがいい

**名前は開発中のものです。** · 2009/03/14(土) 02:33:35

処理の順番追うだけでもうやる気なくなるわー。擬似タスクとか死ねばいいのに。

**名前は開発中のものです。** · 2009/03/14(土) 02:44:33

構造が単純なのでゲーム毎の仕様にあったカスタマイズがしやすい、ってのもタスクのメリットの一つかなぁ
でもこの辺のメリットは”知る”ものじゃなくて”理解”するものだから、実際にゲーム作った経験の無い人には
分からないかもしれん。

なんかアンチタスクって独身スレにいる「結婚のメリット教えてくれ！」ってのと同じ感じ。
「絶対に幸せになる保証が無い限り結婚しない！」ってのがいたけど、あれととても似ている…

タスクはゲーム作るときに使うもので、ゲーム作らないならタスクにこだわる必要ないし
実際にタスク以外の方法でゲームつくってるならそれはそれでタスクなんて気にしなくてよい。
アンチはなんでタスクシステムに粘着してるんだろう？

**名前は開発中のものです。** · 2009/03/14(土) 03:17:55

>>770
プロ気取りがしたり顔で出鱈目いっちゃ駄目よん

**並列さん** ◆dPfetnROQg · 2009/03/14(土) 03:19:14

>>764
> 実際、仮想アドレス上でバランバランでもうろたえるほどの速度低下はない。

その部分に限って言えば、バランバランにメモリをアクセスするのと、
リニアにアクセスするのとでは数倍以上変わると思うけど。

全体に占める割合は…ゲームによるけど、何万パーティクルも表示するつもりなら致命的だと思うけど。

なんか同人規模のシューティングとかしか作ったことのない人が何か言っても説得力ないよ。

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

厨房のHSP大好き君は発言内容が粗削りだが目の付け所はまずまずだ
ゲームをよく作ってる感じがするのねん

**名前は開発中のものです。** · 2009/03/14(土) 06:17:22

>>773
なんでおまえはそんな偉そうなんだよｗ

このスレで一番あてにならないのは具体的なことは言わないくせに
妙に偉そうにしてるやつだとおも
擁護アンチ問わず

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

>>770
タスクシステムを使って書かれたプログラムを引き継ぐ羽目になって（バグが収束せずに
メインプログラマ交代）、散々苦労した。

**名前は開発中のものです。** · 2009/03/14(土) 16:42:18

>>767
＞つーかお前、前>>510だろ。当たってる？当たってたらなんご褒美ちょうだい

　ぶっぶー。チョー陰険だから前510だろってのは間違い！

初出は>>682で、以下ID:E0xOAlNR、ID:0j+yjPij、ID:GPL7IZe+、ID:QLymkmBo、
ID:kAszbGcI、ID:gk02bKgy、かな。抜けてるかもしんないけど多分こんだけ。

てか、あらためてスレを斜め読みしてみたら、ID:EEKBitmgさんて高専の人だったのね。
道理で、知識だけはあっても、考え方も物言いも子供っぽいわけだ・・・。
なんかもうすでにガキの喧嘩の捨て台詞みたいなレスになっちゃってるから、>>767に
いちいち突っ込むのはやめるけど・・・「俺が気に入らないだけだろ」みたいに、
下らない衝動を私に投影するのはやめてね。
上のリスト見れば分かると思うけど、おかしなことを書いてると思った人に対して
それはおかしいんじゃない？って書き込みしてるだけだよ。

**名前は開発中のものです。** · 2009/03/14(土) 18:34:28

ごちゃごちゃいいわけはいいからタスクシステムのメリットぐらい説明しろよ

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

メリットはリンスインシャンプーがあることだろ常考・・・

**名前は開発中のものです。** · 2009/03/14(土) 19:07:02

>>777
>763

**名前は開発中のものです。** · 2009/03/14(土) 20:18:24

>>775
”タスクシステム”を”C言語”とか”ポインタ”に置き換えても成立するな。
バグが収束せずにメインプログラマ交代って時点で既に…

**名前は開発中のものです。** · 2009/03/14(土) 21:24:01

CG板だと、タスクシステムを Shade とか sai に置き換えても違和感無いんだぜ？

**名前は開発中のものです。** · 2009/03/14(土) 22:13:43

>バグが収束せず
ただ単にコーディングレベルの問題ではないか？ｗ

**名前は開発中のものです。** · 2009/03/15(日) 00:16:39

>>779
は？何もかいてないけど？
馬鹿がわかりもしないでレスつけないでくれない？

**510** · 2009/03/15(日) 02:45:36

タスクシステムが並列化に向く向かないで盛り上がっているようだが。
書いてみればすぐ分かること。

タスクシステム並列化版
http://kansai2channeler.hp.infoseek.co.jp/cgi-bin/joyful/img/8978.zip

各スレッドでタスク群の添え字をInterlockedIncrementしつつループまわすだけ。

なお、並列化に関係ない部分は手抜き実装。

**510** · 2009/03/15(日) 02:57:48

処理順序だとかプライオリティーだとか色々議論しているが、
並列化に処理順序の話を持ち込むのはナンセンスだと考えるが。
並列化しないからといって、処理順序がどうでも良いというわけではない。

**名前は開発中のものです。** · 2009/03/15(日) 06:19:12

これ並列動作しねぇって
VTuneでも使って一度みてみろマジで

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

おいおいお口チャックマンだぜ？

**510** · 2009/03/15(日) 09:15:14

いや、並列で動くことは動くんだが、他のところがバグってるね。

**名前は開発中のものです。** · 2009/03/15(日) 11:45:56

完璧に余談ですが

#include <boost/lambda/lambda.hpp>
#include <boost/lambda/bind.hpp>
#include <cassert>
#include <vector>
#include <pstade/oven/parallel_for_each.hpp>
#include <pstade/oven/forall.hpp>
struct test_task{
int m_counter;
test_task() : m_counter(0) {}
};
int main(int argc, char *argv[]){
namespace ov = pstade::oven;
namespace ll = boost::lambda;
const size_t N = 10000;
const size_t THREADS_SIZE = 4;
std::vector<test_task> v(N);
ov::parallel_for_each(THREADS_SIZE, v, ll::bind(&test_task::m_counter, ll::_1) += 1);
assert( ov::forall(v, ll::bind(&test_task::m_counter, ll::_1) == 1) );
ov::parallel_for_each(THREADS_SIZE, v, ll::bind(&test_task::m_counter, ll::_1) += 2);
assert( ov::forall(v, ll::bind(&test_task::m_counter, ll::_1) == 3) );
return 0;
}
>>784のmainの動作を真似するだけなら、boostやovenを使ってこう書けたりする。
んで、並行動作するオブジェクト間の依存を上手く消してTBB等のparallel algorithmで一発というのが、
一番簡単な並行プログラミングだろうなと思った。
boost threadはただのマルチスレッドだけどTBBのだと強烈な並列化もしてくれるみたいだしね。
しかし、こういうのは参照透明性の保証が容易な関数型言語の十八番のように思うわ。

**名前は開発中のものです。** · 2009/03/16(月) 00:25:10

そもそも、なんでタスクとやらを並列化したがるかな。

ゲームに限らんが、並列化しやすい部分としにくい部分がある。描画周りとかパーティクルなどの
エフェクト系、モーション計算とかを並列化したほうが、依存関係が複雑で仕様変更が多発する
プレイヤーやら何やらを並列化するよりよほど現実的だと思うんだが。

**名前は開発中のものです。** · 2009/03/16(月) 00:41:01

並列化は別で話してほしい。
優先順位とグローバル変数（シングルトン含めて）問題の冴えたやりかたを検討しようぜ

**ID:EEKBitmg** ◆HSP4mee/SU · 2009/03/16(月) 02:18:40

>>784
ちょっとちょっとちょっとー。ハッタリ自動並列メタボDBオヤジは本当に大丈夫なの？

　　『ボクが作ったこのコードにもタスクシステムって名前付けたからこれもタスクシステムですし
　　　ついでに言うとこれDBですし自動並列処理もできますしお前らはボクのコードが並列化に
　　　向いてないって言いたいんだろうけどそれは全くの誤りだしどうしてそれが分からないの？』

こういうことなの？頭の中がお花畑なの？公序良俗に反するポピーの花が自生してるの？
お前がひりだしたウンコがどう陳列され得るかなんていう前衛美術の話なんて誰もしてないから
安心していいよ

それとオッサン、あんたは何で配列にぶち込んだ1万個の鼻糞みたいなちっさな処理を一個一個
処理する度にsleepしたりクリティカルセクションかまして次に処理する要素番号をゲットすんの？
スレッドの数で配列を等分して粗粒度並列化でもしときなさいよ
sleepなんか噛ましたらインストラクションレベルの自動最適化の妨げになっちゃうじゃないの

あんたのコード使うくらいなら直列番長の>>2のほうがまだ速いよ

**ID:EEKBitmg** ◆HSP4mee/SU · 2009/03/16(月) 02:40:43

あとさ、同一フレーム内で終わらせないといけない処理なのに
イベント（シグナル）で同期とったりするのは何の冗談なの？
ベンチ取った？アホ？

もしかしてワーカースレッドが目覚める前にメインスレッドが全部処理
しちゃったりしてない？あとさ、最初のTASK1(hage)が終わって
次のTASK1(hoge)が始まる頃には何ms経過してるの？

なんかもう自動並列とか以前に足元がグラグラのヘボヘボな気がする
おやすみ

**ID:EEKBitmg** ◆HSP4mee/SU · 2009/03/16(月) 02:44:52

あと、TASK1(hogehoge)の度にスレッド作るのはサンプルだから？
ウソだろ？サンプルだからってこれはないと思う。聳え立つウンコだ

**ID:EEKBitmg** ◆HSP4mee/SU · 2009/03/16(月) 08:13:22

>>794
よく見たらtasksystemはグローバル変数だからスレッドは使い回してるから
そびえ立つウンコてのは言い過ぎか

**名前は開発中のものです。** · 2009/03/16(月) 13:07:05

おっさん言う奴は自分は若いと思ってる20代後半から30代前半の独身男性だな

**名前は開発中のものです。** · 2009/03/16(月) 21:21:55

タスクシステムってあれだろ
雑魚とドラム缶を合わせて4つまでしか画面に表示しないように制限するシステム

**名前は開発中のものです。** · 2009/03/16(月) 22:00:19

大体お前の頭の中身と同じだな。

**ID:EEKBitmg** ◆HSP4mee/SU · 2009/03/16(月) 22:53:40

>>796
俺そんなに大人びて見えるか？もしかして俺褒められてる？
このマス掻き童貞夜更かししてないでエロゲでシコって糞して寝てろ、とか
罵倒されるんじゃないかとﾋﾞｸﾋﾞｸしてたんだけど杞憂だったのかな

**名前は開発中のものです。** · 2009/03/17(火) 00:41:33

「新装版　大規模C++ソフトウェアデザイン」って本を昨日から読み始めたんだけど、
１章を読んだだけでタスクシステムのだめな点が指摘されているような気がした。

「継承」対「階層化」では階層化の勝ちで、
理由は階層化の方がはるかに一般的＝依存性が少ないからって話みたい。
タスクシステム（なんちゃってC++版）のタスクは継承使ってるよね。

タスクの次にどこに進めばいいか分からないとか、
抽象的な話に飽きた、デザパタとか眉唾ーって人は
これ読むとおもしろいかもよ。おれはおもしろい。当たり前のことが書いてある。

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

包含と継承のことだな。

まあ多態性を使わない場面ならすべて包含でいける。
包含だと結合が緩やかだから見通しが良いって話だなそれは。

何段も深くなければよいんじゃないかね？

**名前は開発中のものです。** · 2009/03/17(火) 07:25:27

なんでもかんでも機能を突っ込もうとするからだ。

delegateのリストでも使っとけ。

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

タスクシステムいいじゃん。
範囲指定で自殺してくれるの最高。

**名前は開発中のものです。** · 2009/03/17(火) 13:49:55

>>803
その範囲は何を意味してるの？
何かの値なんだろうけど。

**名前は開発中のものです。** · 2009/03/17(火) 14:04:47

親殺せば子も死ぬってことじゃね？

**名前は開発中のものです。** · 2009/03/17(火) 17:56:34

タスクシステム関係無いじゃん

**名前は開発中のものです。** · 2009/03/17(火) 21:56:42

>>802
タスクシステムのExecやRunやProcなんかは
まさにそういう用途の窓口じゃないのかね？

**名前は開発中のものです。** · 2009/03/18(水) 00:44:43

>>807
その窓口を誰が用意するかという話。
本人なのか、本人と取り引きする別の人なのか。

どっちがいいかはよくわからん。
もっと条件を絞れば考えやすくはなるが、俺の思考が正しいとは限らん。

**ID:EEKBitmg** ◆HSP4mee/SU · 2009/03/20(金) 00:38:03

（・∀・）ﾍﾗﾍﾗ
クソガキの俺がそろそろ総括しちゃおっかなーっと
結局21世紀にもなってタスクシステムだタスクシステムだなんて叫んでるおじちゃん達って
相当に不勉強なロートルちゃんが混じってるんだよねー。不勉強なまま頭がコチコチに
固まっちゃったガンコなお年寄りに限って声がデカイもんだから迷惑してる人もいるだろうね

　・タスクバカは、たかが実行待ちキューに得意げにお名前を付けてることにいつまでも気付かない
　・タスクバカは、タスクシステムが何なのか一般化して説明するだけの知能がない。だから、ハハン、
　　想像力の問題だね、とかハハン、自分で考えな、みたいに居丈高に振舞って誤魔化すしかない。
　・タスクバカは、>>2で使われてる用語のTASKやらTCBやらが実はOSやらMONITORから拝借されて
　　きた用語であることを知らない。知らないフリをし続ける。指摘されても『アーアー聞こえない聞こえない』
　　の知能障害で逃げまくる。で、『>>2はOSとは設計も目的も意味も違うから混同するのはおかしい』
　　だとか、『OSとの比較は無意味』、だとか臆面も無く言ってのける。もはや介護が必要な知的水準だ

　・タスクバカは、>>2がOSやMONITORの仕組みを劣化猿真似しただけの代物であることを
　　どうしても認めたくない。プライドの高い彼らにとって>>2とは、タスクシステムとは

　　　　ボクらのギョーカイが編み出したプライスレスでオンリーワンなミラクルテクノロジー

　　でなければならないらしいのだろう。タスクシステム誇らしいですねホルホルホル

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

老害プログラマーに現在進行形でムカついてんならともかく
ただの学生なのにここまで熱心に煽れるエネルギーってなんなんだろうｗ

**名前は開発中のものです。** · 2009/03/20(金) 00:55:34

ここ以外では話聞いてもらえないんじゃねぇの
人によって場合によって色々前提違うのに、自分の世界の話ばかりだし
リアルならお近付きになりたくないタイプ
ウザすぎる

**名前は開発中のものです。** · 2009/03/20(金) 01:11:51

>>809
おっさんのタスクバカだが>>2がOSやMONITORの仕組みを
劣化猿真似しただけの代物と思ってるぜ。良い意味で。

学問的には屑だがシンプルでちゃんと動くぜというか
微妙なたとえかもしれないが大学に対する高専みたいな。

**名前は開発中のものです。** · 2009/03/20(金) 01:37:27

タスクシステムは1実行単位で必ず1回実行したい処理などを、
実装する窓口を作るのが本来の仕事だと思います。

タスク間メッセージのやり取りなどで汎用化とか考えがちだけど、
結局は時間的コストがばかにならないのでたいてい失敗に終わる。

メッセージのやり取りなら上位の管理役オブジェクトに
取得するメソッドを経由するほうが効率的だと思います。

で、タスクシステムが何を作るのに有用かと言うと、
上で書いたとおり1実行単位で必ず1回実行したい処理です。

たとえばGameの進行を管理するためのGameMaster、
入力機器などのステータスのアップデート、ゲーム内ステータスの表示(UI)、
プレイヤーが操作するキPC、NPCなどのAIなどが一般的。

当たり判定などはこれらを実行しつつあたり判定用の
データベース（ハッユや4分木）に登録する。

一通りシステムタスクやキャラクタタスクの実行が終わった後、
当たり判定を行いゲーム内物理に応じた反応を計算。

このあとジオメトリ計算やレンダリングが行われるわけです。

**名前は開発中のものです。** · 2009/03/20(金) 01:40:55

実装してみれば分かると思いますが、ゲームシステムにおいて
1実行単位で必ず1回実行したい処理ってのは割りとあります。

いろんな所で使うためおもわず「システム」といいたくなるのでしょう。

ツリー構造や処理依存関係を考慮したタスクの
生存管理を行うとよりシステムらしくなるでしょうね。

まあ、すべてタスクで行うの愚かでしょう、
しかしタスクを全く使わないのも非効率ですね。

パーティクルなどはタスクで実装すると、
非効率なのでべつの処理系を僕は作っています。

弾幕ゲーム程度の弾数ですとタスクで処理しちゃいますけどね。

**510** · 2009/03/20(金) 18:07:47

>>792
普通に仕事してるので、一週間に一回程度しかスレを確認できないから亀レスすまん。

>配列にぶち込んだ1万個の鼻糞みたいなちっさな処理を一個一個
>処理する度にsleepしたりクリティカルセクションかまして次に処理する要素番号をゲットすんの？

Sleepを入れているのは、明示的にスレッドの切り替えを発生させ、並列動作をテストするため。
だから、本来は入らない。
それから、クリティカルセクションは使ってない。

**並列さん** ◆dPfetnROQg · 2009/03/20(金) 20:09:54

>>815
いまさらかも知れないが
名前の「510」は、「前スレ510」とか「タスクシステム改良君」とかにしたほうがいいような気がした。

ところで、>>792だが、俺もちょっと的外れな気がする。
ID:EEKBitmg は、サンプルプログラムを読み解く力に乏しいのか、ケチの付け方が毎度しょーもない。

**名前は開発中のものです。** · 2009/03/20(金) 20:40:49

嫌タスク厨にレスする度に、魂がよごれていく気がするんだよな、ハハン

**名前は開発中のものです。** · 2009/03/20(金) 23:37:12

>816
> ケチの付け方が毎度しょーもない。

仕方ないよ。知識も経験も乏しいセンセイに教わってる学生サンなんだから。

**ID:EEKBitmg** ◆HSP4mee/SU · 2009/03/21(土) 00:37:19

>>815
クリティカルセクションじゃなくてインターロックだった。なんか書き間違えた

>>816
うぜぇよハゲ
ちいさな処理をひとつこなしたら排他制御かけて次に処理する要素を決定、とか
こんなチマチマとロックをかけるくらいなら

thread1 execute task[0～10000/4-1]
thread2 execute task[10000/4～10000*2/4-1]
thread3 execute task[10000*2/4～10000*3/4-1]
thread4 execute task[10000*3/4～10000-1]

のほうがはえーんだけど

**名前は開発中のものです。** · 2009/03/21(土) 00:47:27

当然だけど、すべてがタスクシステムのリストに繋がってると思ってないよね。
大量のパーティクルとかは、1つのタスクに配列を持たせて管理するでしょ。

**ID:EEKBitmg** ◆HSP4mee/SU · 2009/03/21(土) 01:01:55

>>820
てめぇ、質問するときは言葉を選べよボンクラ
俺にタスクシステムの実装を聞いてどうすんだよ

＞お前らタスクバカはさ、いい加減『ナニを作るのか』具体的に書けよ
＞何でもツクール目指すから『ナニを作るのか』書けません、だとか
＞ミラクルドリーマーみたいな事をほざくなよ

何度も何度もいってんだろ。バカが
毎度毎度てめぇのに都合に合わせて俺様実装を引っ張り出して
『当然だけど』、とかほざくなっつってんだよ

**ID:EEKBitmg** ◆HSP4mee/SU · 2009/03/21(土) 01:08:12

というのは不毛なので
>>820
>>2のタスク一個一個でパーティクル一粒一粒を作るようなことをせず
配列でやるというのはとても清々しい実装だと思うね。タスカーっつっても色々だね
ところでそれはタスクシステム派としては多数派の意見なの？
全てをタスクにしないと気がすまない人がいたような気がするんだけど

**名前は開発中のものです。** · 2009/03/21(土) 02:41:56

相手によって発言内容変えてくるクズだろ？
まともに相手にしてんなよ

**名前は開発中のものです。** · 2009/03/21(土) 10:47:01

>ところでそれはタスクシステム派としては多数派の意見なの？
>全てをタスクにしないと気がすまない人がいたような気がするんだけど
お前の頭の中に仮想敵作って必死にどっかの誰かと戦ってますね

**名前は開発中のものです。** · 2009/03/21(土) 10:52:49

でもすべてごった煮にしてないとせっかくまとめたのにアクセスできないオブジェクトができるよね？
タスクシステムなんて使ってるアフォからしてみたらそれはすごく面倒なことなんじゃないの？
引数作ってもってくるみたいなことしてるとも思えないし

**名前は開発中のものです。** · 2009/03/21(土) 12:14:38

>>821
＞毎度毎度てめぇのに都合に合わせて俺様実装を引っ張り出して
＞『当然だけど』、とかほざくなっつってんだよ

てめぇの都合に合わせて俺様実装するのが当たり前だろうが
そういうのが当然だっつってんだよ

お前本当に高専か? 老害連中より頭固いじゃねぇか
教科書読むしか能の無いサルは社会に出てくんなよ迷惑だから

**名前は開発中のものです。** · 2009/03/21(土) 13:37:52

>>822
他の人がどうしてるか知らないけど、普通に考えて、
数千、数万のリストを作る人はいないと思う。

>>825
1つのタスクの中に、複数のオブジェクトのデータがあるだけだよ。
アクセスは引数使ってもできるし、引数なしでもできる。

**名前は開発中のものです。** · 2009/03/21(土) 16:58:12

パーティクルの一粒一粒が他のタスクに何らかの影響を与えて相互に作用する必要がないなら全部まとめて１タスク内で処理するよな
処理の単位がタスクなだけであって、すべての要素がタスクな訳じゃないだろ

**名前は開発中のものです。** · 2009/03/21(土) 17:09:54

>>827
でもわざわざ引数なんて使いたくないんでしょ？

**名前は開発中のものです。** · 2009/03/21(土) 21:25:16

引数ってなんの話だっけ
俺的にはメソッドに常に self を渡すのは当然

**名前は開発中のものです。** · 2009/03/22(日) 05:18:44

>>829
何かアンチタスクは思い込みの激しいタイプみたいだな…

**名前は開発中のものです。** · 2009/03/22(日) 05:30:54

>>831
引数使う人間がごった煮をメリットだと思うかね・・・馬鹿かね君は

**名前は開発中のものです。** · 2009/03/22(日) 05:32:36

ごった煮ってこのスレでよく見かける言葉だけど、
どんな状態なんだろうか

**名前は開発中のものです。** · 2009/03/22(日) 05:37:34

引数つかわない、ごった煮…
やはり何かに取り付かれてるな

見えない何かと戦うのは疲れないかい？

**名前は開発中のものです。** · 2009/03/22(日) 10:27:25

インターフェースを使った抽象化をごった煮とはこれいかにｗ

**名前は開発中のものです。** · 2009/03/22(日) 11:10:41

>>833
それは>>2を読んでないな
とりあえずこのスレのタスクシステムは>>2なんだから会話に参加するなら
まず>>2を読むべき

**名前は開発中のものです。** · 2009/03/22(日) 13:18:05

面倒だからググったらやねうらおの記事で使われてる言葉だったのか

**名前は開発中のものです。** · 2009/03/22(日) 13:21:33

日付と過去ログを合わせればここで使ってたほうが早いぞ
奴は議論の過渡期にわざわざ見当違いな記事書いて意味不明なフェードアウトしただけ

**名前は開発中のものです。** · 2009/03/22(日) 13:34:52

タスクシステムなんて記憶をたどると15年位前から使われてる。

**名前は開発中のものです。** · 2009/03/22(日) 13:41:41

>>836
タスクシステムは>>2にあるものがすべてって考えはどうかしてる。
ゲームに合わせて実装は変えるのが普通。
教えられた通りのことしかできないプログラマはゴミ。

**名前は開発中のものです。** · 2009/03/22(日) 13:49:52

というか、実行巡回リストのみしか存在しない、それ以外のコレクションが存在しないとか考えてて、
なんでもかんでもごった煮リスト(wに頼らないとやっていけないとか考えてるお子様が未だに存在する
というのがちょっとした脅威。

**名前は開発中のものです。** · 2009/03/22(日) 13:51:32

アンチ君はプログラマではなくてただの学生みたいだから
そこまで想像できないんだろう。

**名前は開発中のものです。** · 2009/03/22(日) 14:18:45

>>840
だったらまずは>>2のメリットデメリットを説明した上で
自分の改良版の>>2との相違点を説明するべき

それがこのスレに参加する条件だろ

**名前は開発中のものです。** · 2009/03/22(日) 14:44:30

別に相違点だけでいいんじゃね？

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

>843
人に教えてもらったところで、それを理解できなければ意味が無いだろwww

**名前は開発中のものです。** · 2009/03/22(日) 14:51:40

タスクってゲーム毎に手を入れて使うのが普通だし、プラットフォームとかジャンルとか前提条件によって使い方も異なるから
具体的な前提条件が無いとメリットデメリットの説明は抽象的なものにしかならんだろうなぁ…

まぁ、抽象的なものでも経験のあるゲームプログラマならだいたい暗黙知で分かるんだけど
タスクの仕組みを聞いただけではその辺がまったく想像すらつかないってレベルなら、
理解できるだけのプログラム能力や経験が不足してるか、そもそもプログラマとしての適正がないんでないかな。かわいそうだけど。

**名前は開発中のものです。** · 2009/03/22(日) 16:32:43

>>846
一番ＰＧとして適正のない人間ってちゃんと比較検討ができない人間だと思うぜ
数字出してちゃんとメリットとデメリットを掲示できない、
ちゃんと検討もしたことないのに勘でいいものだと信じる
あたりを見回して楽に手の届くところにあるもんをテキトーにつまんで
勉強した気になってるような奴は詐欺師に騙されてしまう

ソフトウェア工学はクズが多すぎたよ
海外の人間からいってウンコみたいな奴等ばっかりだし
グローバル変数・関数が平気で使ってあるもんが褒め称えられてる異常事態
ちゃんと自分で判断できる人間が周囲にいるかどうかも正直微妙だしね
環境によっては糞を受け付けられてしまってもしょうがない

**名前は開発中のものです。** · 2009/03/22(日) 16:42:26

PGには独善的な連中も多いようだな
他人にキャンキャン噛み付いてるのを見てると結構面白い

**名前は開発中のものです。** · 2009/03/22(日) 16:45:24

>>846
抽象的な説明に、ひとつの具体例でもついてれば十分だよ。
デザインパターンの説明なんて、みんなそんなもんだ。

抽象的な説明にしかならないからって、説明しない理由にはならないよね。

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

俺自身は、タスクシステムが良いとか悪いとか言うつもりは無いんだが・・・
このスレ見てると、いつもアンチ側がタスカー側に対して、
説明しろだの具体例を挙げろだのと一方的に要求してるよな。
アンチ側は、自分の方からタスクシステムより良い具体的な実装例を挙げて、
これこれこうだからタスクシステムは駄目なんだ、っていう比較をしようとは思わないのか？
なんか見てて不思議なんだが。

**名前は開発中のものです。** · 2009/03/22(日) 17:13:17

>>850
すべて個別に実行用のメソッドをもったオブジェクトを、
用途に合わせたコンテナに突っ込んでまわすとかいってた希ガス。

**名前は開発中のものです。** · 2009/03/22(日) 17:31:36

メリットやデメリットは何かと比較したときに初めて出てくるもので
比較対象の無い文脈でメリットやデメリットを問うのは論理的におかしい。
>846ば偉そうにしてる割にそんなこともわからんのか。

>>849
デザインパターンの説明は目的と構造だけだろ。
例えばVisitorパターンのメリット、デメリットは?と問われて答えられる?

**名前は開発中のものです。** · 2009/03/22(日) 18:26:41

そうか比較対象が明らかじゃないのか。すまんかった。

じゃぁとりあえず個人的な興味で、話の流れに合ってるかどうかは知らないけど、
↓の比較で前者の方針にメリットがあるのかどうか、教えてもらえるとうれしい。

- 「タスクシステム」的方針
まず、毎フレーム実行される処理のコンテナ（リストなど）が在ることが前提。
毎フレーム実行される処理はまず「タスク」と考え、上記のコンテナに登録する。
大量のパーティクルなど、不都合が現れた場合は「タスク」としない。

- そうでない方針（個人的にはこっちが「ふつう」）
とりあえず必要な処理は関数呼び出しで並べる。
動的な寿命や複数インスタンスの一括処理などが必要になったら
リストなどのコンテナを必要な場所に用意して使う。

ここで「アンチタスク」として書き込みしている人は、たぶん前者の方針が
我慢できないんだと思うんだ。

**名前は開発中のものです。** · 2009/03/22(日) 18:46:43

>>853
それってどっちにしても毎フレーム実行コンテナは使ってんだな。
つまり
・常に毎フレーム実行コンテナ
・必要になったときに毎フレーム実行コンテナ
この２派がここまで醜い争いしてんの？ｗ

**名前は開発中のものです。** · 2009/03/22(日) 19:20:29

>>854
個人的にはそういうことだと思って見てる。たぶんシューティングゲームや
アクションゲームを作れば結果として同じような構造が（必要に迫られて）現れるだろう
と思う。

タスクシステムが「どんなゲームでも基本になる」とか「（メリットが）暗黙知」とか言う人は、
きっとシューティングゲームやアクションゲームなどを作った割合が多いんだろうな、とか。

ただ、後者であればコンテナは複数種使うのがあたりまえだし、ましてグローバルでは
ありえない。

これに対して前者では単一のコンテナ（これが「タスクシステム」と呼ばれたり）だったり、
それがさらにグローバルになったりしやすい。

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

おまいら全員毎フレーム実行コンテナを使わないことにすれば
論争は解決するんじゃね

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

>>853
>動的な寿命や複数インスタンスの一括処理などが必要になったら
同じような構造がプログラム中に複数表れる場合は
共通化できる部分を抽象化して共通のシステムにできないか、と考えるのが普通だと思うが

アンチは必要な箇所全てにコピペなりで同じような実装を個別に持つのがいい、という理屈か？

まぁ共通化できそうな箇所が２箇所ぐらいならいいけど、アクション系ゲームとかではかなり出てくるだろうし
そーなると共通化したほうがマシでない？

**名前は開発中のものです。** · 2009/03/22(日) 22:49:10

確か継承も否定してたぞ＞アンチタスク厨

**名前は開発中のものです。** · 2009/03/22(日) 23:14:54

>>857
同じ構造のコードを共通化することに異論は無いよ。

共通化できるはずということ（なのかどうか知らないけど）で最初から根っこにひとつ
「タスクシステム」が存在してるのが >853 でいう「タスクシステム」的方針。

共通化できる部分を見つけてから実装を括りだすのが >853 でいう「ふつう」の方針。

前者だと何か構造的な変更を考えたときに、根っこをいじることになって影響が
広がりやすいというデメリットが考えられる。別の言い方をすると、たくさんの
プログラムから共用されているということは変更が難しくなる、という至極当然の話。
これに対して、大きなメリットは思い当たらない。

**名前は開発中のものです。** · 2009/03/22(日) 23:22:45

>859
> 前者だと何か構造的な変更を考えたときに、根っこをいじることになって影響が
> 広がりやすいというデメリットが考えられる。

いわゆる『タスクシステム』も含めて、それらはただの実行巡回コレクションなのだから、それ以上の
機能を持たせようとするのが間違い。なんでもかんでも一つの構造に押し込めるのがおかしい。

実装をくくりだす後者の場合でも、当然共用されているところに変更が入ったらその機能の調停に
手間がかかるのは同じだ。

機能を絞り込めないなら、前者でも後者でも変更が難しくなるのは変わらないよ。

**名前は開発中のものです。** · 2009/03/22(日) 23:24:30

局所的な要求に対して個別のコンテナを置く（作る）のが難しかった（面倒だった）
C++ 初期以前の時代なら、すべての要求に対する単一のコンテナをあらかじめ
持っておくという方法に大きなメリットが感じられたのかもしれないけど、今となっては
基本的なコンテナは標準テンプレートから即座に作れてしまうわけで、大きな違いには
ならない。

C++ 標準コンテナの利用という点にメリット・デメリットの感じ方の分岐点があるのだと
考えれば、 C++ 標準コンテナのゲームプログラマ内での普及率とあわせて、
タスクシステムの恩恵を感じる人が多いことも納得できる。

**名前は開発中のものです。** · 2009/03/22(日) 23:24:32

>>859
>共通化できるはずということ（なのかどうか知らないけど）で最初から根っこにひとつ
>「タスクシステム」が存在してるのが >853 でいう「タスクシステム」的方針。
タスクシステムの定義に根っこ一つなんてあったかな？

前々スレあたりに出てた
メイン遷移状態・メニュー階層・ゲームオブジェ・エフェクト…
って粒度単位で分かれてる階層タスクシステムってのもあるみたいだけど。

>共通化できる部分を見つけてから実装を括りだすのが >853 でいう「ふつう」の方針。
そこで括りだされた共通実装って一般にタスクシステムと言われるものでは？

**名前は開発中のものです。** · 2009/03/22(日) 23:27:38

>>859
>たくさんのプログラムから共用されている

継承が浅ければたいした問題じゃないよ。

その理論からいったら.NETが提供する「Object」なんて、
すべてのオブジェクトから継承されるので論外って話になるんじゃないかね？

**名前は開発中のものです。** · 2009/03/22(日) 23:34:22

>>860
> いわゆる『タスクシステム』も含めて、それらはただの実行巡回コレクションなのだから、それ以上の
> 機能を持たせようとするのが間違い。なんでもかんでも一つの構造に押し込めるのがおかしい。

そういう立場で言うと、「タスクシステム」と呼ぶほどの構造はどこにも現れないはず。
つまり「タスクシステム」が存在していること自体が、なにか不適切な機能の押し込みの
存在を示している（或いは感じさせる）ということになる。

> 実装をくくりだす後者の場合でも、当然共用されているところに変更が入ったらその機能の調停に
> 手間がかかるのは同じだ。

後者の方針では、共用されていることで変更が面倒になるようなら共用しないという選択が
簡単にできる。だって元々共用することが前提じゃなかったんだから、元に戻すだけの話。
括りだした実装を、結局ひとつの場面でしか使わないことになったとしても何も問題は無い。

**名前は開発中のものです。** · 2009/03/22(日) 23:41:47

>>862
根っこにひとつという定義は無いと思う。逆に、根っこにひとつとか、共用が前提とかいう
方針でなければ「タスクシステム」と名前がついていても、あまり否定するポイントは無いよ。

名前を改めることを強くお勧めする程度。

**名前は開発中のものです。** · 2009/03/22(日) 23:42:38

>864
オマエの頭の中には、機能の階層構造が『タスク』と『タスクを継承した何か』しか無いのか？

そもそも『タスクシステム』なんて仰々しい名称が付いてるが、あんなのはただのイディオムでしか
ないぞ。教条的に従うものでもなんでもない。

> そういう立場で言うと、「タスクシステム」と呼ぶほどの構造はどこにも現れないはず。

『タスクシステムとよほどのもの』は無いかもしれないが、そういう『構造』は確かに存在するし、
>859の後者の方針だって、例えば敵なら敵でまとめてコレクションを作って実行巡回する
んだろ？　それは敵という機能をベースにした「タスク」のコレクション以外の何だというんだ？