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

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

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

古典タスクシステム（このスレでは「>>2」と呼ぶ）

White Paper - Programming
http://homepage3.nifty.com/moha/programming.html

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

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

Logician Lord　…　【コンピュータゲームのからくり】
※ウェブアーカイブのキャッシュ
http://web.archive.org/web/20041009222313/www.hh.iij4u.or.jp/~peto/Games/games_top.html

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

前>>1000

全力で却下する

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

高専のHSPerのクルクルパーが吠えてると聞いて

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

HSPerが寝たころを見計らって。前スレの問いに一応答えておくか。
またネタにマジレスとか言われるかもしれないが。

>あとさ、シーングラフの中から、条件にあったオブジェクトを高速に列挙する
>それをお前はDBだとかあんた言ってるんだろ？
>そんな機能、シーングラフを扱うライブラリなら大抵入ってるじゃん
>or用意に組み込めるようなトラバーサのインターフェースを提供してるじゃん

いや、可読性の問題だから。HSPが嫌われる原因も主に可読性だしな。

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

ProcessだったりActorだったりObjectだったりTaskだったりJobだったり。

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

結局、前スレの奴、なんでDBにしたのかさっぱりわからないな(笑)

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

エスパーじゃないから判らないのは当然だ。
しかしその理由を推測できないのは、>7のプログラマとしてのセンスが足りないと言わざるを得ない。

目の前のコードを解析してその設計思想を推測するのは、プログラム上達への近道。

ワカランワカランと何時までもほざいているのは、ただのバカ。

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

普通に分かるように話せよ。
前スレでMPIが出てきたときは吹いた。
苦し紛れにアレコレ言い逃れしようとすんな。

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

>>8
>>518のプログラムは分かるだろ。普通に巨大なクソだった。
で、なんでそんなに巨大なクソをありがたく拝んでいるのかが分からんと言ってるんだが。
メリットはなんだといろんな奴が何度も聞いてるのに、出てくる答えは全部HOW。

これはプログラム見たって分からないし、
クソの思想設計を推測したってプログラムは上達しない。
自動並列化にしたって>>510のコードには何もない。
だから話がかみ合わないんだろ。疑問が生まれるんだろ。

つーかさ、マジでこんなの推測できるわけないだろ。
「参照構造」とかトンデモ思想が飛び出して唖然としたわ。
こんなナナメ上理解できるかよ。

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

>>10
>>518じゃなくて前スレの>>510な。

開発規模が個人と複数とではまるで話が違ってくるんで、
個人向けなら個人向けと最初から言って欲しい。
前スレ>>510の「オブジェクトがどこからでも参照できるのがメリット」
とかいうのは複数人開発では全く使えないな。

なんでもできるようにするのがエンジニアリングだと思うなよ。

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

>>5
専用のインターフェースを使ったほうが可読性上がるだろ普通。
あと、目的が分からないまま言語だけ叩いてもしょうがないと思うが。

どんなゲームをHSPで作ろうとしているのか。
そのゲームを作るのにHSPに過不足があるのか。

この辺見えてないまま単にHSPだけ叩くのは不可能だろ。
目的によって最適な手段は違うから、目的が分からないままでは手段の不当性は訴えられない。
タスカーは目的無視で一般的銀の弾丸を漠然と論じたがる傾向があるから難しいかもしれんが、
それじゃ議論にならないから目的をハッキリさせるのは重要だと理解してくれよな。

ちなみに、タスクシステムは目的０というか、>>510に至っては掲げている目的が見当違いだったり、
実は実装されていなかったりだからナニコレ？と言ってるわけだ。

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

みんなHSPに反応しすぎだよ。HSP使いのことはほっといてタスクの話しようぜ。
このままだと、このスレッドはHSPスレです。タスクの議論は他でお願いします。
とかそのうち出てきそうじゃん。

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

タスク信者どもこのスレで完全に息の根をとめてやるぜ
具体的にはもうタスクシステムでゲームなんて作れんようにしてやる

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

別に使い続けてもいいんだよ
洗脳するなってだけ

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

>>14
発想が小学生だな

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

小学生に失礼

**名前は開発中のものです。** · 2009/02/20(金) 00:46:37

給料泥棒のHSPがアンチタスカーのふりをして暴れてると聞いて

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

ドンタスクったらドンタスク

**ID:EEKBitmg** · 2009/02/20(金) 05:38:32

>>5
＞いや、可読性の問題だから

何言ってんのお前。頭蓋の中が空っぽだから適当ぶっこいてHSP叩いて逃げてるだろ
HSPの問題じゃねーのよ。わかる？フロントエンドに何の言語使ってようが
てめぇが言ってるタスクシステム＝DBとかいう珍説はチンプンカンプンなんだよ

**ID:EEKBitmg** · 2009/02/20(金) 05:41:55

>>13
本当だよな。俺はHSP使いってだけなのに
底辺ワナビー・ダメ中年に限ってHSP使ってるって部分に脊髄反射してやたらネチネチと絡んでくる
おまけにポインタが使えないだとか、見当違いのこと言ってくる（前>>821-）。馬鹿かと
固定長メモリプール使ってれば>>2のポインタの使い方なんて配列の添え字（番号）でも記述できる
ハンドル使ってるなら、ID+配列の添え字　あるいは　ID+プールタイプ+配列の添え字　とか

あと前>>510のソースの背後にある思想は>>2と違うと書いたが、どうやら外れだったらしい
書いた本人（>>510）の思想はタスク信者そのものだった。何がしたいのかサッパリ見えないし無知だ
ageうんこ詩人の当初の予想は的中していたようだ。心からお詫びする

ゲームプログラムの中の処理単位を扱う何らかのシステムだというタスクシステム
>>2ではゲームオブジェクトがタスクらしい。
それが今度はDBです。とか。何言ってるんだ？

タスク信者って窮すると話をかっ飛ばしてウヤムヤにしようとするよな

**名前は開発中のものです。** · 2009/02/20(金) 07:08:32

まあ、>>510の最終目標の1つは、シーングラフを構築する上でタスクを使って並列処理を行うって意味なんでしょ。
タスク単位で他タスクの保有するオブジェクトの参照や依存関係を明確にして、
並列処理できる分については、自動でスレッドにタスクを投げ込んでやろうとしてるのかな。

参照構造はその第1歩って事なんだと思う。DBって言葉使うと紛らわしいよね。一般的なDBMとは単語の意味合いがちょっと違うかな。
タスクからのオブジェクトの所有/解放と他オブジェクト参照の可否を組込む辺りから先ずは始めるのがいいと思う。
でも、並列タスクが相互干渉する状態での同期処理となると頭抱えちゃうかな。
最後にこのようなタスクが残るとクリティカルパスに影響するだろうから、
同期/非同期なのかは、個別に指示する必要がありそうな感ではある。全部動的にするのは難しいね。

タスクの粒度を細かくすると、参照構造がばらけて、並列化しやすくなるだろうけど、タスクプールが肥大になってかえってオーバヘッド生みそうだし、、
逆に粒度を荒くすると、並列化が困難になりそうだよね。その辺のバランス調整も難しそうだ。

他にもアイディアとしては、前フレームでの1タスクの実行時間を保持しておき、
それを次フレームでのタスク予想時間として利用して、効率的に分配するとかかな。

俺はタスクは使わない派だが、>>510は応援するよ。ネタとしては楽しいと思う。
始めソースを見ても目的が意味不明だったが、言ってることは分かった。
>>2とは、目標としているところは全然違うっしょ。
あと、参照構造についての意見はまたそのうちまとめて書くよ。

**名前は開発中のものです。** · 2009/02/20(金) 07:27:31

そんなわけねーじゃん
だってどっからでも参照できるのがメリットとかウンコ臭かったじゃんよ

**名前は開発中のものです。** · 2009/02/20(金) 07:55:22

手段のせいで目的を制限するようなことはしたくないなぁ。

時には泥臭いことをやってでも解決しなきゃいけないことはあるんだ。
動けばいいんだよ。

HSPクンだって引数クンだってアンチタスク厨だって、作ったものが仕様どおりに動けばいいんだ。

仕様ってのは「どこからでも参照できる」でその手段が「DBのようなものを採用」だっただけ。
じゃ、なんで「どこからでも参照できる」なのかといえば、それは>510が決めたからとしか言いようが無い。
別に他人のタメにプログラム組んでるわけじゃないのだから。

**名前は開発中のものです。** · 2009/02/20(金) 08:36:41

設計のせの字もわかってないから引数否定して
グローバルインスタンスホルダーなんて作ってしまうわけですね

まず、なんでグローバル変数や関数が駄目なのか？とかそっから理解してないよね

**名前は開発中のものです。** · 2009/02/20(金) 09:27:17

>>24
>別に他人のタメにプログラム組んでるわけじゃないのだから。

自分のためのライブラリならそう明示すりゃいい。
目的・用途が不明瞭なまま手段だけ出して「これどうよ」と言われれば、
それは一般向けのものとして応えるしかないだろ。

**名前は開発中のものです。** · 2009/02/20(金) 10:18:16

HSPクンは、

「俺はHSP使いってだけなのに
底辺ワナビー・ダメ中年に限ってHSP使ってるって部分に脊髄反射してやたらネチネチと絡んでくる」

とHSPを使ってることを叩かれると激しく怒る。

しかしHSPクン自身も、タスク使いってだけのやつにネチネチと絡んでいる。

これを同属嫌悪という。

**名前は開発中のものです。** · 2009/02/20(金) 10:44:19

>>27
で？

**名前は開発中のものです。** · 2009/02/20(金) 13:23:17

HSP使いの基地外が暴れてると聞いて

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

>>22
前スレ510はアンチの立場から>2の考え方を参考にしつつ
明らかに違うものをタスクと再定義してみるネタじゃね。
(読み違えてなければ)従来のタスクで特徴的だとされる
ごった煮リストじゃなくて型毎にリスト持ってるし。
OpenMPやMap-Reduceの影響の方が強いように感じた。

**名前は開発中のものです。** · 2009/02/20(金) 18:33:19

でもＤＢがどうのこうの言ってたじゃん
馬鹿のすることに無理やり意味なんて探すことないよ

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

どうせ匿名掲示板なんだから有利な状態で仕切り直し直せよ
それでも潰すけどね

**名前は開発中のものです。** · 2009/02/20(金) 18:51:36

それと新ワード連発して煙にまく手法は相手にされなきゃそれまでな上に
逆に具体性を求められるとタスクシステムに関係してないとどうしても弱くなるし
その上タスクシステムとの関連まで説明させられるしで正直手としては弱い気がすんだよね

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

>25
引数クンは、前スレでContext&の受け渡しも否定していたヤツだぞ。

　引数を通して渡すのは必要なものだけ、それ以外を渡したらダメ。
　グローバルは当然使っちゃダメ。グローバルに順ずるものも使っちゃダメ。

という極端すぎる人のことだが、ID:SutyetVrはもしかして引数クン本人なのか？

**名前は開発中のものです。** · 2009/02/20(金) 22:38:42

引数君は給料泥棒のド素人プログラマなんだから、いい加減トリップつけて、
みんなからNG指定してもらったほうがこのスレのためだと思うが。

基地外みたいなアンチタスカーは引数君か前のスレ主なんだろうな。

**名前は開発中のものです。** · 2009/02/20(金) 22:53:18

ID:YgfxUXIw
ここまで煽りのみか。
お前がトリップつけろよ。
煽りしかできない奴は邪魔。

**名前は開発中のものです。** · 2009/02/20(金) 22:54:50

DBって何?
ドラゴンボールの略かえ?
タスクシステムってwikiにすら載ってないから謎が多いよね
オブジェクト指向データベースですらwikiに載ってるというのに
タスクシステムごときをシーングラフと同列に並べるなよ
全角英数使うなよ
DSLぐらい理解しろよ
飯食ったか
風呂入ったか
歯ー磨けよ

**名前は開発中のものです。** · 2009/02/21(土) 04:05:46

そのwikiってのは、もしかしてWikipediaのことか？

**名前は開発中のものです。** · 2009/02/21(土) 09:45:44

個人で作る規模のゲームなら、変に凝らなくてもタスクシステム程度でちょうどいいんでないかな。
タスクも必要ないテトリスとかオセロぐらい単純なゲームならwhile/switch/caseだけでもいいし。

仕事で作るゲームならその現場のルールや伝統の方法でやりゃいい。

結局アンチタスクって
ポインタも構造体も無いHSPでタスク使いたくても使えないから
すっぱい葡萄になってるレアケースでしょ。

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

「変に凝ってる」のがタスクシステムだと気付け。

**名前は開発中のものです。** · 2009/02/21(土) 10:22:39

いい加減ド素人タスカーの「お前ら技術力ないだろ、○○を勉強しろ」的なレスは飽きた。

**名前は開発中のものです。** · 2009/02/21(土) 10:27:28

>>40
あの糞単純なタスクシステムのどこが凝って見えるのかを知りたい。

**名前は開発中のものです。** · 2009/02/21(土) 10:32:12

どのタスクシステムについて言ってるんだ？
>>2か？

>>2なら現代でやる意味がないという意味で変に凝っている。
その他のカスタムタスクを指しているなら、目的が迷走している点で変に凝っている。

**名前は開発中のものです。** · 2009/02/21(土) 10:35:42

#define ONE 1
#define PLUS +

int x = ONE PLUS ONE;

こんな馬鹿げたことをやってるのがタスクシステム。
単純なこと変なやり方でやって喜んでるだけだろ。

**名前は開発中のものです。** · 2009/02/21(土) 10:40:06

>>44
よくわからんが

君の頭の中では
タスクシステム＝マクロ
なのか？

もしかしてタスクシステムを理解してない？

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

……。

「単純なこと変なやり方でやって喜んでる」という例えを示しただけなんだけど。

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

タスクシステム自体はすごく単純な作りだけど
あれでも理解できない人がいるということか

まぁ関数ポインタとか、C言語初心者には「変なやり方」で難しいかもしれんが。

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

まあ、「理解してない？」みたいな突っかかり方が十八番だからしゃあないか。
つーか、理解するとかしないとか、どんだけ低レベルなの。

>>47
>>41

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

>>48
それはつまり
みんな君が理解してないことを突っ込んでたけど
君は勉強しても理解できないからアンチになった、ということになるが…

**名前は開発中のものです。** · 2009/02/21(土) 11:00:45

とりあえず、タスクシステムのメリットを説明してみ？
誰もまともにできてないんだが。

お前がどう理解しているのかちゃんと示してくれ。

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

メリット説明できずに黙るだろうな。
これまでの奴は全部そうだった。

ID:P36r7rTDの健闘を祈る。

**名前は開発中のものです。** · 2009/02/21(土) 11:04:27

ギャラガとか今なら個人で作る規模のアクションゲームなら
複数オブジェの並列動作を単純に記述できていいね、ぐらいのものじゃない？

そんな難しく考えるほどのもの？

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

forループで済む話をわざわざ変なやり方で面倒にしている理由を話せと言っている。
単純というが、普通に書いたらどう複雑で、それをどう単純にしたのか示してみろ。
タスクシステムのほうが複雑だから「単純に記述」という部分が嘘になってるんだよ。

**名前は開発中のものです。** · 2009/02/21(土) 11:18:09

ギャラガを例にとると
自分・敵の弾、敵の死亡、敵の生成、などのオブジェが可変のケースだと
オブジェの増減をリスト管理してとか、結局タスクシステムと同じような仕組み作る必要があるんでない？

さらに、敵が編隊組んで移動、とかボーナスシーンとか、隊長機がやられたら編隊解散、とか
タスクなら関数切り替えで単純に状態推移を記述可能だけど
switch/caseで状態をオブジェ単位で記録して切り分け、となると
タスクシステムのほうがシンプルに記述できるだろ。

まぁ関数ポインタ理解できない人が見たら難しいソースになるかもしらんが。

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

>>54
なにいってるのかまったくわからない

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

まぁ理解できないなら使わないでいいと思うぞ。
趣味のプログラマがどんな方法でプログラムしようとも
誰も文句いわんだろ。

**名前は開発中のものです。** · 2009/02/21(土) 11:30:15

状態遷移を関数ポインタで表現するのは良いと思うし、
それはタスクシステムに限ったことじゃないよな。

>>1を読んで、どのタスクシステムについて語ってるのかハッキリさせてほしいんだが。

タスクシステムだとオブジェクト間の関連が処理順依存になって面倒になると思うが。
そこはどうすんの？
１フレームの誤差だから許容すんの？

**名前は開発中のものです。** · 2009/02/21(土) 11:38:27

>>57
>>1を読んで、どのタスクシステムについて語ってるのかハッキリさせてほしいんだが。
ゲームの種類にあわせればいいんでない？
ほんとに単純なゲームなら>>2でもいいけど、ゲームによって問題が出たり
普通にC++使える環境ならクラスで作り直したり改良もあり.。基本的な考え方は変わらんでしょ。

>>タスクシステムだとオブジェクト間の関連が処理順依存になって面倒になると思うが。
オブジェクト間の処理順が問題になるケースなら
いわゆる「プライオリティつき」タスクを使うか、シグナルのような仕組みを付け加えればよいのでは？

そもそもあんまりタスク使って複雑になるようなゲームならタスクじゃない管理方法使うべきだし。

**名前は開発中のものです。** · 2009/02/21(土) 11:55:53

>>58
>基本的な考え方は変わらんでしょ。
TCB有る無しで違うと思うが。
タスクを１個のリストで管理するかどうかも重要だ。
ごった煮リストでむりくり制御しようとしている様を指して変だと言ってるんで。

>いわゆる「プライオリティつき」タスクを使うか、シグナルのような仕組みを付け加えればよいのでは？
ここまでやると「単純」の域を超えているだろ。
すでにコードの見通しが悪くなってる。
「タスクシステム」のプライオリティーはベーシックの行番号やGOTOに見えるわ。

>そもそもあんまりタスク使って複雑になるようなゲームならタスクじゃない管理方法使うべきだし。
そうだな。

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

「箸なんて原始的です。だから誰かメリット教えてくれないと箸の使い方覚えません」
って言ってる子供と同じだな。
「魚食うときとか便利だろ？」と言っても
「スープ飲めないじゃん、肉切れないじゃん」と言い返される。
スープ飲むときゃスプーン使えばいい。肉きりたきゃナイフとフォーク。箸で食いやすいものは箸で食えば良い。それだけのこと。
でも箸ぐらい使えないと馬鹿にされるぞ、と。

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

単純-複雑、変-変じゃない、とか審美的主観の話をしたら
好みの違う人とは話が合わないのは当然。
技術的に欠陥や優位があるというのならコードや
測定結果の数字を使って具体的に定量的に主張しろよ。

**名前は開発中のものです。** · 2009/02/21(土) 12:20:35

>>60
で、「箸で食いやすいもの」は結局なんなの？
タスクシステム使って良かったと思える場面てどこ？
やっぱりメリット言えないの？

タスクシステムが原始的だなんて言ってないだろ。
タスクシステムよりもずっと原始的なやり方のほうが遥かにマシだと言ってるんだが。

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

>>60
ちがうな
箸で食えばいいのにトンカチで食べようとしてる人がいるから
なんで？って聞いてるんだ

**名前は開発中のものです。** · 2009/02/21(土) 12:22:39

いや、トンカチですらないな
トンカチは役に立つもんなｗ

タスクシステムはなんだろ？
なんにも役に立たないやｗ

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

定量的な主張なら前スレ>>510と>>641でやったな。
>>510にはメリットが無いのにコード量は>>641の倍だった。

コード量の差と>>510が使っていたかなりの量のマクロを指して複雑だと言っている。
>>2はその時点ですでにタスク信者が見放していたからまだだけど、比較する必要あるか？

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

>53
だからcontinuationの問題だろ？

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

>>66
だから継続もタスクシステム抜きで実現できるだろ？

**名前は開発中のものです。** · 2009/02/21(土) 12:27:28

>57
全てのn+1は、必ずnを参照すべし

とキミは主張しているのか？

**名前は開発中のものです。** · 2009/02/21(土) 12:27:39

そのうえ全部まるごと食えばいいじゃんとか言う奴もいるから話にならんな

**名前は開発中のものです。** · 2009/02/21(土) 12:28:57

>67
dispatch部分をいちいち個別に書くのかよw

**名前は開発中のものです。** · 2009/02/21(土) 12:29:20

>>68
何言ってるのかサッパリ分からん。

**名前は開発中のものです。** · 2009/02/21(土) 12:34:33

>71
> タスクシステムだとオブジェクト間の関連が処理順依存になって面倒になると思うが。
> そこはどうすんの？
> １フレームの誤差だから許容すんの？

タスクシステムだろうと、個別ループだろうと、処理依存するだろ？
1フレームの誤差はどちらでも出るぞ。

だから、『状態n+1に更新する場合は、全ての状態nを保存してから処理すべし』、と言いたいのか？

と尋ねたんだが、理解できなかったか？

**名前は開発中のものです。** · 2009/02/21(土) 12:46:40

逆に言えば、

　　priorityを上げ下げすることで処理順依存をある程度解消できるタスクシステムとやらの方が
　　個別ループよりも柔軟性が高く優秀である

とID:3HETWV4tは言っているわけだが、今まで言ってきてることと矛盾してるだろ？
ホントに気づいてないのか？

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

>>65
> >>510にはメリットが無いのにコード量は>>641の倍だった。

タスクシステムの部分を除けば641のほうがはるかにコード量は多かったよ。

それだけでもタスクシステムというシステムを導入するメリットがあると言えると思うが。

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

>>72
>タスクシステムだろうと、個別ループだろうと、処理依存するだろ？
ああ、そりゃそうだな。

>>73
プライオリティーで表現すれば処理順を動的に変更できるし柔軟性も高まるが、そんな需要あるか？

　・自機の弾に当たっている敵A
　・自機に重なっている敵A

この場合どちらを先に処理するか、全部消滅させるかみたいなルールは動的に決めるものではないよな。
これをわざわざプライオリティーで表現してソートしたりするのが面倒なんだが。
さらにこの辺のプライオリティーがハードコーディングならやっぱり無駄にしか見えん。

でもってこれをタスクシステムで頑張ると「面倒→誤差許容しないとやってられない」、
というシナリオを描いて>>57の発言となった。

シグナルだのプライオリティーだの言っても所詮ルールが静的ならべた書きのほうが楽だろ。

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

>>74

■TaskDemo
main.cpp 4684
Tasksystem.cpp 337
Tasksystem.h 4625

■NormalDemo
main.cpp 5087
Star.cpp 514
main.h 118
Star.h 235

(5087 + 514 + 118 + 235) - 4684 = 1270

その差５０行程度だが、どこが遥かになんだ。

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

なんで静的であるという前提なんだ？
そういうゲームしか作ったこと無いとか？

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

>>77
この手のルールが動的に変わる場合ってどんなのがあるの？
ギャラガは違うよな。

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

素手で食いたいなら素手で食ってもいいんだが…
何を使えばいいかは料理しだい。世界中の料理を箸で食べろとは主張してないし、
ナイフもフォークもどんな道具も、万能な道具なんてないよ。

でも箸使えないからって箸を否定するのはみっともないよね、ということだね。

箸を使えないのが能力不足のせいか、HSPのせいかは知らんが。

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

>78
つまり、作ったことも無ければ想像したことも無いということか。
ダメジャンw

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

万能な道具はないが、明らかに場違いな道具はあるって話。
俺はもともと目的に合った手段を選べという立場だ。
タスクシステムが手段として他のやり方よりもまともに機能する場面て何？と聞いているんだが。
その問いに対してズバリこれと言ってくれればそれで話は終わるんだがな。

>でも箸使えないからって箸を否定するのはみっともないよね

俺はオマル使えないし、オマル使ってるやつは否定したくなるな。
オマル使ってるやつはみっともないし、オマルを勧める奴は言語道断だ。

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

まあ、オマルならな、渋滞にはまった時の非常手段として役立つかもしれない。
洩らすよりはマシだからな。
こういう「こんな時なら使える」って意見が欲しいんだよ。

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

タスクシステムを使った実例は
ナムコの古典的アーケード以外にも
昔からのゲームメーカーのゲームを入れれば星の数ほど使われてる

それに対して何もゲーム作ったことも無い人間が「メリット理解できません」
といっても「そうだろうね」としか言えんわな。

今の最新ゲームの規模で古典的タスクみたいな単純な仕組みが使われることはもう無いけど、
個人製作レベルならまだその程度で十分じゃないのかな。

個人製作レベルで数億円かかるフレームワークとかエンジンとかの話してても夢物語だし…

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

>>83
現代で使うメリットが無いと言ってるんだよ。
リソースきつきつだった時代に使うことまで否定してないだろ。

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

>>84
関数ポインタ理解できる程度のプログラマなら
小規模なゲームで状態推移を簡単に管理できる実装の一例、程度でしょ

プログラマに実装の選択肢があるのは一般にメリットだと思うがね。
逆に君は「あらゆる状態でタスクより優れた方法がある」ということを
説明できるのかね？

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

>81
> 俺はオマル使えないし、オマル使ってるやつは否定したくなるな。
> オマル使ってるやつはみっともないし、オマルを勧める奴は言語道断だ。

オマエは要介護認定の人たちをバカにしているのか？

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

なんでお前らは結論の出てる議題で必死になってるんだ？

**名前は開発中のものです。** · 2009/02/21(土) 15:18:06

>>85
>>84

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

>>86
>>36

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

そーいえば
非相対マルチコアの某最新コンシューマ機で
少ないサブコアのローカルメモリ内だけでメインCPU側から独立して
タスク管理するために、ほぼタスクシステムな仕組みでジョブ管理されてる実装を見たな。

これ、最新ゲームだったけど。
リソースがいくらでもある、って前提で富豪的考え方しか出来ん最近のゆとりプログラマには
結局最新技術も使いこなせないんだろうなぁ…

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

タスクシステムは個々のタスクがグローバルなもの（例えばスクリーンデバイス）にばらばらにアクセスする。
ばらばらにアクセス＝グローバルなものの整理ができていない。

グローバルなものの整理ができていないと１万行を超えるプログラムを動作させるのは難しい。
http://www.kojima-cci.or.jp/fuji/mybooks/cdiag/cdiag.2.4.html

だから代わりに引数を使おう
http://www.kojima-cci.or.jp/fuji/mybooks/cdiag/cdiag.2.5.html

という話で終わるでしょ。
たとえ個人製作レベルでも１万行なんて普通に超えるよ。

もしタスクシステム使う人が
　「1万行越えたらそのコードはいったん捨てて、タスクシステム使わずに１から設計し直すよ」
という認識を持っているならアリかもしれないが、
例えば
　「1万行越え確実だけどタスクシステム使って設計するよ。
　　もちろん1万行超えたらそのコードはいったん捨てて、またタスクシステム使って１から設計し直おすよ」
と言う話ならナシ。

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

>>90
>>84

まあ、これは無駄に「現代」とくくったのがイカンかったね。
リソース使える場面でもタスクシステム使うといいよという例があったら頼むわ。

**名前は開発中のものです。** · 2009/02/21(土) 15:33:38

みんな熱いな。タスクについての認識や結論はもう出てると思う。
「使いたいやつが使えばいいと思う」
ただそれだけだ。
タスクのメリット話せと言われても、おそらく使ってる人も表現し辛い箇所なんだよね。
フレーム間を跨ぐ処理を書く上で多用するわけで、その辺はゲームによってまちまちだ。
じゃあ逆にタスク代替案も示せと言われても、
switchに戻すだとかで、これといって画一的な処理は示されないのが現状。

銀の弾丸は存在しない。それだけだよね。

**名前は開発中のものです。** · 2009/02/21(土) 15:33:51

haskellとかでタスクシステムを実装するとしたらどんな感じになるか
ただしunsafeほげほげとかIORef禁止で

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

>>91
そのURLに書いてあるのって、アクセスの話じゃなくて宣言を整理するって話じゃないの？

**名前は開発中のものです。** · 2009/02/21(土) 15:46:27

>>92
CPUリソースとメモリリソースを考慮に入れないなら
それこそどんなアルゴリズムでもいいんでない？遅かろうが無駄だろうが好きなの使えば。
作業効率とか考えるならプログラムも不要でツクールやMODでいいんじゃね？という感じ。

本職のプログラマなら、どんなチープな環境でも軽量・低コストで動作できる
アルゴリズムを知ってるのは十分メリットだと思うけど。
組み込みにしろ、携帯機にしろ、リソースの厳しい環境でやれって言われるのは
良くあることだから。

ま、個人製作ならそんなことどーでもいいんで、
そーなると実装方法を強制されない個人製作で何でアンチタスクになるのかが謎だが。
嫌いなら使わなきゃいいだけなのに。何でアンチ？

**名前は開発中のものです。** · 2009/02/21(土) 15:47:46

>>91
なつかしいな「Ｃプログラミング診断室」
でもグロバール変数一覧は俺はオススメできないけどな
そもそも作るなといいたいｗ＞グローバル変数・関数

**名前は開発中のものです。** · 2009/02/21(土) 15:48:18

Haskellはスレッドが数バイトしか使わないほど
軽いから結構かわりそう

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

>>96
いきなり極端になったな。
作業効率考えるなら～の部分が唐突に投げやりなんだが、まあしゃあないか。

>>39
>>40
この流れをよく見てみよう。
結局、変に凝ってるのはどっちだよ。
アンチっていうか、こういう意味不明なこと言う奴に、
「リソースある場面でタスクシステム導入する奴は変に凝ってる」
と言いたいわけだ。

リソース無い場面で使うことに関して異論がないのはもう何べんも言ってるのでこれ以上繰り返さないようにな。
ちなみに>>39で想定している場面てリソースないような状況じゃないよな。

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

>>95
そうです。今見返すと話つながってないっすね。混乱させてごめん。
１つ目のURL書いた理由は、グローバルなもの（マクロも変数も）を無秩序に使ってると
10000行あたりで破綻するという話を紹介したかったからです。

２つ目のURLはOKだよね？

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

>99
引数クンなのか、ごった煮リスト嫌いクンなのか、どっちなの？
それとも、それ以外？

複雑なものは理解できないクン？

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

>>92
リソースが余ってるならC++を使う必要性自体がないのでは・・・ｗ
俺は>>84は、現代のプログラマでも「タスクも知っていた方が良い」ことを示すいい事例だと思った

リソース使える場面でC#やRubyよりC++使うといいよという例があれば前言は取り消す

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

>>76
> (5087 + 514 + 118 + 235) - 4684 = 1270
> その差５０行程度だが、どこが遥かになんだ。

タスクシステム使わないほうは、27%もソース増えてるじゃん。

開発時間はソースの量にだいたいは比例するから、
8時間の作業で済むところが、10時間強もかかる計算になるじゃん。

俺ならそんなの御免だね。
だから、俺は使えるところでは使ったほうがいいという結論だな。

使えないと思うところでは使わない。それだけのことじゃん。

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

>>103
処理が減ったわけでもないのに
そこがそんなにうれしいとこなのか？

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

>>104
人間がバグを仕込んでしまう確率は、だいたいコードの分量に比例して増えるからね。

可読性を保っているなら、コードは少ないほうが望ましい。27%も違えば大きな違いだろう。

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

>>100
１つ目が繋がってないのに２つ目を持ってこられても困るというか
個人的な感想を言えば、たったの１万行で破綻するとはとても思えない

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

とりあえず俺は実装についてはどうでもよくて、タスクシステムという名前へのアンチ
要はゲーム中で動く「モノ」のことでしょ？なんでわざわざタスクとか呼ぶん？

例えば「実例で学ぶゲームAIプログラミング」の２章が
もろにいわゆるタスクシステムやタスク間通信の近代的なC++実装だと思うんだが
タスクなんてひとっことも言わないし、こうやって作るんだとか誇りもしないのね。たいしたことじゃないから。
これがいまどきのありふれた感覚じゃねーの？

だいたい根本的に、「モノ」を管理するために低レベルなOSのアナロジーを使うこと自体が間違ってると思う。
そういうの実装を歪めると思わん？
「ゲームオブジェクト」「エンティティ」「アクター」なんでもいいけど、「タスク」だけはない。
具象的なネーミングとしても抽象的なネーミングとしても。
非ゲームプログラマがTaskという名前のクラスを見て、何なのかすぐ理解できるのかってことですよ。

お前らがやりたいのは、OSの稚拙な真似事じゃなくて、「モノ」を動かすことでしょ？

あーでもロスプラみたいにマルチコアに振り分けるならOS的要素強いかもね。わかんね。
結局、典型的な「自転車置場の議論」（http://0xcc.net/blog/archives/000135.html）なんだよなこれ。
松浦本読んだ程度のドシロウトでも参加できるという。

そういうのを避けるためにも俺はタスクシステムという言葉は使わない。
使ってるやつ見かけたら陰からこっそり指さして笑う。

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

行数でインパクトがないからってパーセント換算するのはヤメようぜ。

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

タスクというとITRON思い出すから嫌なんだよな。
ITRONのタスクはすげーよ。なのに、タスクシステムのタスクは全然すごくねーよ。
このギャップにイラッとするのはある。

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

>>105
それは本質をまったくみてないなぁ
１行ごとに中身のない改行を入れて「;」を打つだけでも行数だけは増えるじゃない
しかも今回のプログラムだって工夫すれば改行崩れの処理省きでcontinue文は消せてしまうので
それをソースコードの行数の増加と考えるのは上げ足取りをしてるようにしか見えない

むしろ、マクロでfor文を見えなくした>>510のがわかりにくくて気持ち悪い
このマクロっぽいのの意味を初見でみた人が知るには付属のタスクシステムテンプレートを
全部読んで理解するしかないでしょ？
これは嫌だなぁ
仮にマニュアルもなにもなかったとしたらかなり読める人限定されそう

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

>>108
このまま規模が大きくなっても、このパーセンテージは揺らがない。
タスクシステムを使わないほうのプログラムでは、どうしても27%ほどだけソースが大きくなる。

だから行数なんかには意味がない。このパーセンテージのほうがはるかに重要だ。

お前は、どうしてそれをごまかそうとするのか俺にはわからない。

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

>>110
> それは本質をまったくみてないなぁ

そんなことはない。大雑把にはソースの分量で判定できる。

どちらのプログラムも平均的なプログラマが書いたと仮定して、
タスクシステムを使わないほうは27%もソース分量が増えたのには違いない。

> むしろ、マクロでfor文を見えなくした>>510のがわかりにくくて気持ち悪い

あの程度のソースがわかりにくいとは思わないが、マニュアルがないと
正しく使えない人がいるというのには同意。

ただ、本人が開発するなら話は別だろう。

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

>>111
酷いな
ループのカッコとnull判定のことでしかないのに
ここまでくると病気としかいいようがない

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

まあ、でも差分がループのカッコとnull判定だけなんだから
それがタスクシステムの本来の役目ということがはっきりしたともいえるね
正直、差分がそこしか見えなかったんだからそれでいいんだよな？

タスクシステム＝ループのカッコとnull判定をはじけます

でおｋ？

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

>>113
あんたはプログラミング経験が浅くてわかってないんだろうが、ループも、二重ループにするとき、
i,jの添え字を間違えたり、null判定を忘れたり、continueを書き忘れたりするのが人間ってものなの。

そういう定型化している部分を共通部分として書き出して、どこか別のところに追いやったほうが
バグは減るわけ。それは別にタスクシステムでなくてもいいのだが。

forがforeachになっただけでずいぶんバグが減る。
foreachの終了のときのハンドラを定義する構文があればさらに安全性は高まる。

そうやって抽象化と共通部分の括りだしを繰り返して書いていくのがプログラムだろう。

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

>>111
>このまま規模が大きくなっても、このパーセンテージは揺らがない。
どこがそんなにラクになるのかなと見直したが、２重のforループがTASK2と書けるんだね。
ここでだいぶ文字数稼いでるみたいだ。
んで、それがそんなにうれしいことなのかと言われるとNOな訳で。

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

>>115
だから

タスクシステム＝ループのカッコとnull判定をなくした最新鋭のシステムです

でいいんだろ？

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

>>114
> 正直、差分がそこしか見えなかったんだからそれでいいんだよな？

全然違うね。

510のように抽象化することで、自動並列化のようなことが可能になってくる。

まあ、510のソースを自動並列化するのは正直無理だが、もう少し抽象化して、
各タスクの役割を明確に記述できれば自動並列化できる。

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

>>107
「ウォークマン」みたいなものじゃない？
最初に有名になって、それ以降類似したものの総称として
便利だから名前だけ使ってるって。

>非ゲームプログラマがTaskという名前のクラスを見て、何なのかすぐ理解できるのかってことですよ。
タスクシステムを使うのはゲームプログラマでしょ。普通は。

いちいち現場で「これはオブジェクトを管理するシステムで更新と描画で登録関数が呼ばれて…」
とか説明するより「タスクシステム的なもの」の一言でゲームプログラマならだいたいって通じるし。

ま、デザインパターンみたいにちゃんと定義と命名されればいいんだろうけど
ゲーム業界固有の物だしねぇ

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

>>116-117
>>118

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

>>118
それは>>510からはいえないな
実際、>>510と>>641の間で自動化云々って話はないわけだし
自動化を証明したければ比較のソースを書いてからだな
それまではいっちゃいけねぇだろ
俺も否定しないし
少なくとも>>510と>>641の間では自動化は見えなかった
今回はこれが結論

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

まあ、２重のforループで文字数稼いでいるということは、
forループの中身が増えれば増えるほどその稼ぎは薄まる訳だ。
規模が巨大になればなるほどパーセント減るようにしか見えないぞ。
その辺どうなのよ。

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

>>121
510と641を並列化するソースを書き比べればすぐにわかるよ。
そんな本格的なものでなくていいから。

2重ループでi×jのループ回してるところ、あれをi×j / N のループに
分けて実行して、すべてのスレッドの終了をセマフォで待つだけでいいよ。

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

>>122
> forループの中身が増えれば増えるほどその稼ぎは薄まる訳だ。
> 規模が巨大になればなるほどパーセント減るようにしか見えないぞ。

それはもちろん正しい。そのへんはゲームの性質によるだろう。

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

>>124
>>111

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

タスクシステムとやらのメリット
コードが一割減

タスクシステムのデメリット
可読性が低くなる

この調子でお願いします
メリットわかってるんだったらごまかさずに書けよ
そんな出し惜しみばかりするから無駄に荒れる

**名前は開発中のものです。** · 2009/02/21(土) 17:35:18

>>126
コード削減、一割減はちょっと違うと思うな。
今回の例ではタスクシステムを使わないと27%増。

俺の感覚では、だいたいこの数字はどんなゲームでもそんなに変わらなくて
平均すれば20%前後だと思うな。これが10%程度ってことはないな。

並列化とかもっと大がかりな仕組みがタスクシステム側に用意されていれば
この差はもっと広がるしな。まあ、それをタスクシステムと呼んでいいのかは知らんが。

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

じゃあ二割減でもいいや

開発速度向上はない、可読性が低いものほど開発に時間がかかるから
タスクシステムとやらのデメリットとして
開発に時間がかかるというのも追加できる

この調子ならメリットデメリットを列挙できそうだな
選択肢になりうるかどうかはそれを見れば判断できるだろう
化けの皮を一枚ずつはいでいくのは楽しいの

**名前は開発中のものです。** · 2009/02/21(土) 17:52:15

>>128
> 開発速度向上はない、可読性が低いものほど開発に時間がかかるから

ソース全部理解しなくても、510のタスクシステムは使えるだろ。

TASK2(クラス名A,クラス名B)
{
クラス名A1.XXX = YYY;
クラス名B2.ZZZ = WWW;
}

こう使うだけじゃん。説明に1分も要さないと思うが？

**名前は開発中のものです。** · 2009/02/21(土) 17:52:47

>128
> 開発速度向上はない、可読性が低いものほど開発に時間がかかるから
> タスクシステムとやらのデメリットとして

まずタスクシステムのどこが可読性低いのかを示してもらわないと。

FSMになってるところ？　関数ポインタの部分？　ごった煮リスト？

**名前は開発中のものです。** · 2009/02/21(土) 18:15:26

>>130
自分のタスク内で完結しない処理に関しては、全部グローバル変数経由

ゲーム中のあるシーンを想定した場合、そこで何のタスクがどういう順番で走るかが、
コードの一箇所を見てもわからない。

**名前は開発中のものです。** · 2009/02/21(土) 18:15:57

>>129
でも読みにくいなぁ、おいｗ
それが何を表してるのかさっぱりわからないぜｗ
ループ隠しただけなのになｗ

**名前は開発中のものです。** · 2009/02/21(土) 18:24:15

>>131
>自分のタスク内で完結しない処理に関しては、全部グローバル変数経由
そんな処理するのはタスクじゃないだろ。

**名前は開発中のものです。** · 2009/02/21(土) 18:26:52

>>118
> もう少し抽象化して、各タスクの役割を明確に記述できれば自動並列化できる。
そんな簡単じゃないよ。

並列処理は計算機科学の分野では長らく研究されていて、いろいろ知見が積み重なってるんだが、
少なくとも 510 からは、自動並列化につながる筋道がまったく見えない。

夢が大きいのはいいんだが、まったく現実性が無いのもどうかと思うぞ。

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

タスク擁護派から言わせてもらうが、>>129 は読みづらいよ
初めて読む STL や Loki や boost と同じくらいにね。俺なら使わん

結局、あるライブラリを使うメリットは普及してるかどうかだ
strcpy や strncpy を使うメリットはなんだ？
みんなあの仕様はおかしいと感じているのに？　タスクもそれと同じこと。

そして、普及さえしていなければメリットはないと考えて必死で叩くお前らは正しい

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

>>134
> 並列処理は計算機科学の分野では長らく研究されていて、いろいろ知見が積み重なってるんだが、
> 少なくとも 510 からは、自動並列化につながる筋道がまったく見えない。

「自動」の意味を誤解しているようだが、
自動車は、自動的に目的地まで運んでくれる乗り物ではないのと同様、
人間が何もしなくてもいいという意味ではない。

俺が「自動」並列化と言っているのは>>123の意味。
例えば、TASK2をP_TASKと人間が書き換えればあとは自動的に並列化してくれるように改造するのは容易。

なんでこれが出来ないと思うのか、俺はお前らの技術力を疑いたくなる。本当にお前らプログラマなのか？

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

>>136
> なんでこれが出来ないと思うのか
その程度で済むなら OpenMP がやってる

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

>>136
なんにも自動化しないだろｗ

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

>>137-138
お前らが何もわかってないただの自称プログラムだというのは十分わかった。

123すら出来ないとはな。

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

>>138
お前本当に日本人か？どう見ても中国人だろ。

前スレ、前前スレから日本語が極端に不自由な奴が二名いるみたいだが、お前はそいつだろ。

プログラム以前に日本語教室行ってこいよ。

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

もはや進む方向が頭おかしいじゃん
ループなんかはずして喜ぶプログラマいないってｗ
むしろ、ループ処理してるならfor文を見えるところにおいておいてほしいだろ
誰がこんな構造にして喜ぶのか？
ちょっとは考えろよ

**名前は開発中のものです。** · 2009/02/21(土) 20:09:26

>>139
依存関係も副作用も無いコードなら、そら簡単に並列処理できるさ。数値計算だと
割と多いが、ゲームでそれはほとんどないだろ。

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

日本語がおかしかったら中国人ってなんできめつけんの？
インド人かもしれんし韓国人かもしれんだろ

**名前は開発中のものです。** · 2009/02/21(土) 20:43:36

可読性に関してはDSLの圧勝なので
それに比べてタスクシステムは可読性がないと言えるのは間違いないよ
専門家でも読むのが難しい本と、幼稚園児が読める絵本とでは
同じ文字数だとしても
絵本の方が圧倒的に速く読めるでしょう、当たり前だけどな

使えるから使えると言ってるけど
使ったら他の選択肢がなくなるから、使えるからと言って考えなしに使うなと
昔の偉い人とエロイ人もゆってた

つまり、エロエロよー

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

>>142
横槍ですまんが、あくまでゲームで並列処理は難しいと決め付けるのは良くない。
ゲームは依存化が明確にしやすく、
割と並列化しやすいとMTフレームワークの中の人が言っております。
http://game.watch.impress.co.jp/docs/20070131/3dlp.htm
>石田氏は「タスクという観点から見ると、依存関係は最小化でき、
>むしろゲームプログラムは並列化しやすいともいえるんです」と、
>これまでのゲーム開発の常識とは正反対の意見を主張する。

これには自分も驚いたが、
MTフレームワークの製作者が実践してそう思ったのなら説得力があると思わないか？
まぁ、予想(予測)と理論と実践はそれぞれ違うって事だ。

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

>>145
予想というか、仕事で実際にゲーム書いてた経験談なんだが。モーションとかレンダリング
まわりのジョブはわりと分割しやすいんだけど、いわゆるゲームロジックに絡む部分は、
かなり難しい。

排他制御は特にバグが入りやすい部分だし、仕様変更多発が想定されるゲームロジック
部分を並列処理するのはリスキー。

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

完全に頭ごなしに否定するのではなく、
そのリスキーな部分をいかにして、
安全で仕様変更に強い設計で書くのかを議論していってもいと思うわけよ。

仕事でロジック部分の並列化やられたら、うへぇってなるが、
趣味だったら面白いネタだとおもわないかい？

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

まぁ俺はタスク使わない派だけれども、
もしタスク派が生き残りをかけるのなら、マルチコア時代の恩恵を
受けられるような並列処理の記述性ただ1点だけ突き詰めるのが良いとおもうぜ。

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

前スレでは、誰かがプロも使っているタスクシステムと言ってたな
他人の権威にすがって偉そうにする奴も世の中にはたくさんいる
そういう奴は最後には命乞いをして延命を図る
延命を図るのだよっっっ
くやしいのぅ、くやしいのぅwww

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

ID:Dmt7DoEE
前スレの>>510は名乗るのをやめても
タスク信者の特徴は消せないのだから
名乗るといい

名無しでの火消し＆誘導は無駄

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

いや。俺は以前>>22を書いた者で、すまんが510とは別人だ。
実際にタスクについては主に見通しの問題で否定的で、参照構造についても目的が無ければ無意味な足枷でしかないと考えている。
ただ、並列化については興味があるわけ。マルチスレッドで速度を稼げるのならそういう技術も覚えたいと思っている。
そんな中、自動並列化についてタスクにはその可能性がなきにしもあらずと考えている。
まぁ自分は実装するのはゴメンだがね。

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

>>142
> 依存関係も副作用も無いコードなら、そら簡単に並列処理できるさ。数値計算だと
> 割と多いが、ゲームでそれはほとんどないだろ。

あんた、本当に大きなゲームのプログラム書いたことがなさそうだな。

並列化して処理時間を稼ぎたい部分って、同期のためのコストとかもあるから
実際はかなり粒度の大きな、単純な計算が繰り返される処理なんだよ。
ゲームのうち、衝突判定とかは特にそういう計算ばっかりだ。

まあ、>>145でもすでに指摘されているが。

このスレは本当に商用で大きな規模のゲームを作ったことがあるのかと
疑いたくなるような奴ばかりで俺はただただ呆れるばかりだ。

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

>>151
> そんな中、自動並列化についてタスクにはその可能性がなきにしもあらずと考えている。
そもそも、CPU 食ってるのはゲームロジックより、ヒット判定やモーション処理だったり
しないか？　将棋とかの AI は別だけどさ。

そこは仕様が比較的安定しているから、作りこむだけのコストがかけられる。自動並列化
なんていわずとも、従来のロックベースの方法で OK。

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

一般的な自動並列化と俺定義の自動並列化で話が通じ合ってないな、お前ら。

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

>>152
衝突判定は、単に「ぶつかってる・いない」を判定するだけなら簡単なんだが、衝突の
解決が絡むと並列化が割と難しい。

衝突解決には、たとえば「壁は動かない」「プレイヤーが壁に当たったら押し戻される」
「プレイヤーと NPC があたったら NPC 優先」とかルールを決めて、それに応じて
優先順位つけて解決していくのが一般的だと思うが、問題は解決するときに相互
作用が発生することなんだよな。

シーケンシャルに処理するなら、割と手抜きアルゴリズムでもそれっぽく見えるんだが、
並列処理するとなったら、とたんに複雑さが増す。前に一度やってみてメゲた。

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

>>153
コンシューマならCPUの数と使用用途が特定されてるもんだが、現実的に考えて決めうちでが妥当だと思う。
PCのような特定されないマルチCPUの環境を考えると、自動で並列化するのは面白いんじゃないんかねぇ……。
自動並列化といっても、正直こればっかりは実装してみないと、
どのようにスレッド分配され、パフォーマンスが上がるのか下がるのかは、議論できんところだね。

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

お前らｗ

>>136で自動並列化の俺定義出してるんだから、ここはそれに合わせてやれよ。
>>136はライブラリ提供者が、ライブラリ利用者に分からないようこっそり裏で並列化（手作業）しやすいよ。
と、言ってるんじゃないの？　違うか？

ちなみにID:D/oVP314とその他は一般的な意味で話してるような気がする。
ググって出てくるような一般的な意味ね。

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

>>157
っつか、それはデータの依存性自動検出とかできないと無理なわけで。ハードルが
超高い。

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

ループの抽象化が人為的ミスを防ぐとか、>>123の意味で処理を挿げ替え易いというのは分かる。

出来るだけ先入観を抜きにして、もう一度>>510を読んでみた。
やっぱり、TASKマクロのもどかしさが引っかかるんだよな。
iとjどっちも0からブン回してるけど、星衝突ループはj=i+1からで充分。
オーダーが変わってくるんだけど、その辺手が出せないじゃん。
そんな場合、TASK2Bマクロでも作るのかな？
ライブラリに任せでこういう不備があると面倒だ。
しかもこれに対処するとアドバンテージ消えそうだな。

WindowだのApplicationだのをタスク化してるのも意味不明だな。
継承したものがまるまる無駄になってるのが大雑把すぎ。
TASK2に突っ込みたいがためにやってるだけなら、やっぱり無駄過ぎだよな。
先行投資と言っても、その投資が回収されるまでは過度の抽象化にすぎないわけだ。

んで、>>641バグっるかもって作者言ってたけど、ホントにバグっててワロタ。
・万有引力はj=0から回さないとダメ。
・星衝突で自分同士の場合のcontinueが抜けてる。
あとはOK。

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

>>158
その超高いハードルを、どうしたら解決できるだろうかを議論しようじゃないか。
たとえば>>510はデータ集約について提案し、
参照構造の是非について議論しようとしていたようだよね。
オブジェクトの所有/解放を(ライブラリ内で見えないように)行うことで、
並列化の足掛かりを見出そうとしたようだよ。第1歩というか、パフォーマンス的には第-1歩だけど。

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

まあ、>>123みたいな部分で泥臭い作業が発生したとしても、
俺は>>510より>>641のほうが良いね。
「シンボル'Star2'は定義されてません」とかVCに言われてイラつくこともないし。
無駄や不透明な部分があると精神衛生上良くない。

**名前は開発中のものです。** · 2009/02/21(土) 22:26:57

>>160
> その超高いハードルを、どうしたら解決できるだろうかを議論しようじゃないか。
本気でやるなら、サーベイ論文読むところからスタート。かなり研究されてる分野だから、
ゼロから何かやるとか時間の無駄なので。

**名前は開発中のものです。** · 2009/02/21(土) 22:31:42

>>162
そんなくだらいこと研究して金もらってる奴がいることに驚きだぜｗ

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

>>161
> 「シンボル'Star2'は定義されてません」とかVCに言われてイラつくこともないし。

インテリセンスでるのにそんなミスやるはずがないじゃん。あんた使ってるのVC98？

**名前は開発中のものです。** · 2009/02/21(土) 22:39:35

>>163
並列処理のアルゴリズム・データ構造まわりは昔から研究ネタとしてはよくあるんだが、
単一プロセッサの性能向上が頭打ちになるのが現実的になってきた頃から、Intel, IBM を
はじめとした企業が金と人突っ込んでる。

公開されていて実際に開発に使えるレベルになっている成果というと、たとえば Intel
Threading Building Block とかさ。

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

いや、自動並列化は普通に研究対象としてアリだろ。
これから必要になってくる分野だぞ。

タスクシステムにしてもな、
ゲームの根幹的な制御部に使うのはかえって面倒そうなのでやっぱり嫌だ。
単純で、相互作用がなくて、あったとしても誤差許容できて、計算結果はゲーム性に影響しない。
ベストエフォートで充分なところなら使えそうだとは思った。
大量の火花エフェクトとか、そういう余力でやればいいような部分。

**名前は開発中のものです。** · 2009/02/21(土) 22:42:18

>>164
右クリック→定義へ移動

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

>>162
すまん。俺も本気でやるつもりは無いんだ。
正直、並列化には憧れているが、鬼門だと思ってる。それが手動であっても自動であってもさ。
ゲームではない自分の専門分野でIntelC++とMPIで稼ぐ実装をした事があるが、
冗長になった割にパフォーマンスが出なくて萎えた経験がある。

もしゲーム特化で、安全で保守の掛からないデータ構造を有するタスク自動並列化のライブラリが出来たのなら、
金貰ってもいいレベルだと思う。個人が趣味でやる分野じゃないねぇ。

**名前は開発中のものです。** · 2009/02/21(土) 22:54:04

結局、自動化ってあんまり意味ないよね
プログラムって最低限設定しなきゃいけない内容は絶対に自動にならねぇし
結局は上にスルーパスして設定を任せるだけになる

スクリプト組んでも苦労する人間が変わるだけで絶対的な作業量は無くならない
むしろ、トータルでは増えてしまう場面のが多いかもね
そりゃプログラマの仕事があんまり高度で・・・っていうならわかるけど
できたスクリプト言語がＣ言語とあまり変わらんようなのってどうよ？

ってのと同じでタスクシステムも結局処理をスルーパスしてるだけで
自動化してるように見えるだけでしょ？

**名前は開発中のものです。** · 2009/02/21(土) 23:00:58

>>169
ん？複数スレッドにタスク単位で処理を投げてパフォーマンスを稼ぐ「自動並列化」の話だよ？

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

>>169
データ構造と処理内容を限定することで、並列処理を定型化して簡単に使えるように
するってのは、話としては分かる。

ただ、それを目指すならタスクとやらは starting point としては全然ダメなのが萎える。

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

>>169
ID:4jF5VqD/はド素人か。本当にゲーム作ったことあんのか？

お前、一人だけレベルが低すぎる。もう引っ込め。

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

とりあえず、煽るのはヤメにしようぜ。面倒だ。

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

同じく煽るのはやめましょう。
識者との有意義な話。(できれば建設的な話)にもっていきたい。

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

松浦健一郎の本って内容濃いね

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

>>170
え？そんな話してんの？ｗ
絶対無理だと思うよ
ゲームで一番重い処理はオブジェクト同士の関連だって
少なくともデータ自体は分離されてなきゃ並列に動けないと思うぜ
ごった煮にした時点でそんなの無理じゃね？

**名前は開発中のものです。** · 2009/02/22(日) 05:31:48

ゲームロジックで一番重たいのは当り判定だ。
そんなものしらないのかよ。糞が。

**名前は開発中のものです。** · 2009/02/22(日) 05:51:25

今、oyaとkoクラスがあって、それぞれupdateメソッドを持っている。
koクラスのupdateメソッドはoyaクラスのupdateメソッド内で呼ばれる。
koクラスのupdateメソッド内の処理は、ある特定の情報(ここではinfoとする)を必要としている。
infoをどのようにしてkoクラスのupdateメソッド内の処理に参照させればよいか。
1．グローバル変数
2．引数
3．シングルトンパターン

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

複数生成されちゃ困るような情報ならシングルトンになるんじゃないの？
oyaクラスで生成する情報であれば引数で渡すのが楽だろうし

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

>>159
>・星衝突で自分同士の場合のcontinueが抜けてる。
j=i+1から回してるから自分同士ありえないな。
万有引力をj=0から回すだけで良い。

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

>>177
ゲーム内容も明示せずに
>ゲームロジックで一番重たいのは当り判定だ。
ってゲーム一般として断言できちゃうあたりがステキ

物理演算バリバリの3Dコリジョンチェックと
2Dシューティングのボックス判定の繰り返しは違うし
AIの計算時間、モデルのアニメ計算etc...の時間もゲームによって違うのにね。

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

>>177
ジャンルによる。将棋だと AI の方が重い。

**名前は開発中のものです。** · 2009/02/23(月) 07:26:36

タスク信者どもやっと死んだか？

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

プログラムが一行も書けないアンチタスカーのポエマーが死んだんじゃね？

**名前は開発中のものです。** · 2009/02/23(月) 09:35:14

タスク信者は死なんよ。
なぜならアンチタスカーこそが最大のタスク信者だから。
俺もアンチタスカーだが、皆がタスクシステムの利点に気づかないように、
あえてアンチを演じている。
気づかれると日本経済が破綻するからな。

**名前は開発中のものです。** · 2009/02/23(月) 12:39:27

日本経済脆過ぎだろ

**名前は開発中のものです。** · 2009/02/23(月) 16:16:29

皆それが分からずに回りをぐるぐる回ってるだけ。
アメリカではオブジェクト指向での陽動作戦が主流。
一部日本でもその余波の影響を受けてる。2重3重に騙されて踊らされてる状態。
何かおかしいと気がついたインテリたちはLisp使ってる。
しかしそこどまり。ロジックでは根源にたどり着かない。
防空壕の中に居ては何も出来ない現実。

**名前は開発中のものです。** · 2009/02/23(月) 16:58:53

日本語でお願いします。

**名前は開発中のものです。** · 2009/02/23(月) 17:15:51

信者もアンチもどっちもゲ製住民らしくてとっても面白いので
もうちょっと続けてください

**名前は開発中のものです。** · 2009/02/23(月) 17:19:36

スタックという構造がそもそもの誤り。諸悪の根源。
理想な構造＝都合の悪いものを外部に追いやってるだけ。局所的幸せ。
このままいくと、プログラムは幸せになるが、プログラマは不幸になる。
国は幸せだが国民が不幸な北朝鮮と同じ。

**名前は開発中のものです。** · 2009/02/23(月) 17:31:30

ちょっと考えれば分かること。
スタックがあるので関数はいつでも呼び出せる。
でも、引数はいつでも用意できるわけではない。
スタックは一見理想的な構造に見えるが、実は都合の悪いことを外部に追いやっただけ。
みんな困ってる。でも気がついていない。

**名前は開発中のものです。** · 2009/02/23(月) 17:57:19

タスクシステムは流れが読みづらくなりすぎだ
オブジェクト指向的スパゲッティコードのようなもの
GOTOを使ったスパゲッティコードの方がまし

Lisperが書いた本でlisp最高最高書いてあったからよく読んでみたら
DSLのようなメタをその言葉を知らないまま絶賛していた
Lisperってのはすごいんだかすごくないんだかよくわからない人達だった

実装の要点である問題領域をいかに簡単に書くかということこそが
最重要であるのに、そのアプローチを真っ向から阻むタスクシステムを
俺は許せない、許せんのだよ
タスクシステム死すべき死すべき

**名前は開発中のものです。** · 2009/02/23(月) 18:06:49

問題領域が簡単に書けたとしても、それ以外の部分が複雑になるだけ。
「簡単に書いてやろう」その発想がすでに誤り。
タスカーもアンチタスカーも同じ場所をぐるぐる回ってるだけ。

**名前は開発中のものです。** · 2009/02/23(月) 18:22:16

もうこれはプログラム技術知識というか哲学だな。
>>107の書いてた自転車置き場の議論だっけ？良く納得した。
早々に退散させてもらうぜ。

**名前は開発中のものです。** · 2009/02/23(月) 18:42:04

>>193
タスク信者はひとくくりにしていい
だがタスク信者でないものはひとくくりには出来ない
それはログを見れば分かる。それぞれ批判の切り口が違う

読まないから分からない。こういう一見さんに限って
俯瞰視点を気取って分かったような口を利き
稚拙な総括で締めくくろうとする

タスク信者以上に邪魔な存在だ

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

>>194
結論なんてとっくにでてるよ。
余暇にやることが無いからとりあえずアンチと信者に分かれて鬼ごっこしてるだけ。

**名前は開発中のものです。** · 2009/02/23(月) 18:47:56

>>194
哲学？そんな高尚なものではない
どうでもいい役割に、どうでもよくない重要な役割を無理に与え昇格させようと試み
どうでもいい実装を、どうでもよくないウルテクであるかのように喧伝する

これはハッタリ詐欺だ。昔を知らないアマチュアを騙くらかそうと躍起になる石器人の産物だ

**名前は開発中のものです。** · 2009/02/23(月) 18:59:34

>>195
残念ながら私は前スレの510だ。
一見さんどころか、プログラムすら投じている常連だ。
むしろ、私が居ないとこのスレは回らない。もはやネタが無いからな。

>読まないから分からない。こういう一見さんに限って
>俯瞰視点を気取って分かったような口を利き
>稚拙な総括で締めくくろうとする

自分にレスして楽しいの？

さ～今宵も盛り上がってまいりました！！

**名前は開発中のものです。** · 2009/02/23(月) 19:04:16

やれやれ、わからない奴もいるんだな
複雑だが重要な箇所や、試行錯誤が必要な箇所
何度も書き換える必要のある箇所をDSLで記述を簡潔にする
それ以外は多少複雑になってもかまわない
一度しか書かない複雑な箇所と、何度も書き直す簡単な箇所のみで
システム全体が組まれていれば
トータルでの開発コストが最小になる
逆に複雑な箇所を何度も書き直したら莫大なコストになるってことぐらい
少し考えればバカでもわかるはずだ

**名前は開発中のものです。** · 2009/02/23(月) 19:11:49

>何度も書き換える必要のある箇所をDSLで記述を簡潔にする
DSLだと何で簡単になるの？
仮に何らかの理由で簡単になるとして、理由が分かってるのならDSLでなくても良くない？
なんでわざわざ言語作るの？