- 1 名前：名前は開発中のものです。 mailto:sage [2009/02/19(木) 02:21:01 ID:k4ODtuXP]
- タスクシステムについての議論、相談、質問、雑談などのスレです
part4 pc11.2ch.net/test/read.cgi/gamedev/1233459490/
part3 pc11.2ch.net/test/read.cgi/gamedev/1226199100/
part2 pc11.2ch.net/test/read.cgi/gamedev/1196711513/
part1 pc11.2ch.net/test/read.cgi/gamedev/1173708588/
・タスクと呼ばれる実装は、非常に多岐に渡ります
古典タスクシステムについての話題は「>>2」と明示してください
そうでない場合はカスタム版タスクであることを明示してください
・人を憎んで言語を憎まず
- 72 名前：名前は開発中のものです。 mailto:sage [2009/02/21(土) 12:34:33 ID:Kwr5xaMF]
- >71
> タスクシステムだとオブジェクト間の関連が処理順依存になって面倒になると思うが。
> そこはどうすんの？
> １フレームの誤差だから許容すんの？
タスクシステムだろうと、個別ループだろうと、処理依存するだろ？
1フレームの誤差はどちらでも出るぞ。
だから、『状態n+1に更新する場合は、全ての状態nを保存してから処理すべし』、と言いたいのか？
と尋ねたんだが、理解できなかったか？
- 73 名前：名前は開発中のものです。 mailto:sage [2009/02/21(土) 12:46:40 ID:Kwr5xaMF]
- 逆に言えば、
priorityを上げ下げすることで処理順依存をある程度解消できるタスクシステムとやらの方が
個別ループよりも柔軟性が高く優秀である
とID:3HETWV4tは言っているわけだが、今まで言ってきてることと矛盾してるだろ？
ホントに気づいてないのか？
- 74 名前：名前は開発中のものです。 mailto:sage [2009/02/21(土) 13:56:49 ID:07PQbtcV]
- >>65
> >>510にはメリットが無いのにコード量は>>641の倍だった。
タスクシステムの部分を除けば641のほうがはるかにコード量は多かったよ。
それだけでもタスクシステムというシステムを導入するメリットがあると言えると思うが。
- 75 名前：名前は開発中のものです。 mailto:sage [2009/02/21(土) 14:20:08 ID:3HETWV4t]
- >>72
>タスクシステムだろうと、個別ループだろうと、処理依存するだろ？
ああ、そりゃそうだな。
>>73
プライオリティーで表現すれば処理順を動的に変更できるし柔軟性も高まるが、そんな需要あるか？
・自機の弾に当たっている敵A
・自機に重なっている敵A
この場合どちらを先に処理するか、全部消滅させるかみたいなルールは動的に決めるものではないよな。
これをわざわざプライオリティーで表現してソートしたりするのが面倒なんだが。
さらにこの辺のプライオリティーがハードコーディングならやっぱり無駄にしか見えん。
でもってこれをタスクシステムで頑張ると「面倒→誤差許容しないとやってられない」、
というシナリオを描いて>>57の発言となった。
シグナルだのプライオリティーだの言っても所詮ルールが静的ならべた書きのほうが楽だろ。
- 76 名前：名前は開発中のものです。 mailto:sage [2009/02/21(土) 14:29:25 ID:3HETWV4t]
- >>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
その差５０行程度だが、どこが遥かになんだ。
- 77 名前：名前は開発中のものです。 mailto:sage [2009/02/21(土) 14:30:42 ID:Te+n/W8K]
- なんで静的であるという前提なんだ？
そういうゲームしか作ったこと無いとか？
- 78 名前：名前は開発中のものです。 mailto:sage [2009/02/21(土) 14:34:49 ID:3HETWV4t]
- >>77
この手のルールが動的に変わる場合ってどんなのがあるの？
ギャラガは違うよな。
- 79 名前：名前は開発中のものです。 mailto:sage [2009/02/21(土) 14:40:53 ID:P36r7rTD]
- 素手で食いたいなら素手で食ってもいいんだが…
何を使えばいいかは料理しだい。世界中の料理を箸で食べろとは主張してないし、
ナイフもフォークもどんな道具も、万能な道具なんてないよ。
でも箸使えないからって箸を否定するのはみっともないよね、ということだね。
箸を使えないのが能力不足のせいか、HSPのせいかは知らんが。
- 80 名前：名前は開発中のものです。 mailto:sage [2009/02/21(土) 14:48:03 ID:Te+n/W8K]
- >78
つまり、作ったことも無ければ想像したことも無いということか。
ダメジャンw
- 81 名前：名前は開発中のものです。 mailto:sage [2009/02/21(土) 14:50:59 ID:3HETWV4t]
- 万能な道具はないが、明らかに場違いな道具はあるって話。
俺はもともと目的に合った手段を選べという立場だ。
タスクシステムが手段として他のやり方よりもまともに機能する場面て何？と聞いているんだが。
その問いに対してズバリこれと言ってくれればそれで話は終わるんだがな。
>でも箸使えないからって箸を否定するのはみっともないよね
俺はオマル使えないし、オマル使ってるやつは否定したくなるな。
オマル使ってるやつはみっともないし、オマルを勧める奴は言語道断だ。
- 82 名前：名前は開発中のものです。 mailto:sage [2009/02/21(土) 14:53:10 ID:3HETWV4t]
- まあ、オマルならな、渋滞にはまった時の非常手段として役立つかもしれない。
洩らすよりはマシだからな。
こういう「こんな時なら使える」って意見が欲しいんだよ。
- 83 名前：名前は開発中のものです。 mailto:sage [2009/02/21(土) 14:54:55 ID:P36r7rTD]
- タスクシステムを使った実例は
ナムコの古典的アーケード以外にも
昔からのゲームメーカーのゲームを入れれば星の数ほど使われてる
それに対して何もゲーム作ったことも無い人間が「メリット理解できません」
といっても「そうだろうね」としか言えんわな。
今の最新ゲームの規模で古典的タスクみたいな単純な仕組みが使われることはもう無いけど、
個人製作レベルならまだその程度で十分じゃないのかな。
個人製作レベルで数億円かかるフレームワークとかエンジンとかの話してても夢物語だし…
- 84 名前：名前は開発中のものです。 mailto:sage [2009/02/21(土) 14:57:44 ID:3HETWV4t]
- >>83
現代で使うメリットが無いと言ってるんだよ。
リソースきつきつだった時代に使うことまで否定してないだろ。
- 85 名前：名前は開発中のものです。 mailto:sage [2009/02/21(土) 15:03:45 ID:P36r7rTD]
- >>84
関数ポインタ理解できる程度のプログラマなら
小規模なゲームで状態推移を簡単に管理できる実装の一例、程度でしょ
プログラマに実装の選択肢があるのは一般にメリットだと思うがね。
逆に君は「あらゆる状態でタスクより優れた方法がある」ということを
説明できるのかね？
- 86 名前：名前は開発中のものです。 mailto:sage [2009/02/21(土) 15:06:25 ID:Te+n/W8K]
- >81
> 俺はオマル使えないし、オマル使ってるやつは否定したくなるな。
> オマル使ってるやつはみっともないし、オマルを勧める奴は言語道断だ。
オマエは要介護認定の人たちをバカにしているのか？
- 87 名前：名前は開発中のものです。 [2009/02/21(土) 15:08:18 ID:hYClRP74]
- なんでお前らは結論の出てる議題で必死になってるんだ？
- 88 名前：名前は開発中のものです。 mailto:sage [2009/02/21(土) 15:18:06 ID:3HETWV4t]
- >>85
>>84
- 89 名前：名前は開発中のものです。 mailto:sage [2009/02/21(土) 15:19:06 ID:3HETWV4t]
- >>86
>>36
- 90 名前：名前は開発中のものです。 mailto:sage [2009/02/21(土) 15:21:43 ID:P36r7rTD]
- そーいえば
非相対マルチコアの某最新コンシューマ機で
少ないサブコアのローカルメモリ内だけでメインCPU側から独立して
タスク管理するために、ほぼタスクシステムな仕組みでジョブ管理されてる実装を見たな。
これ、最新ゲームだったけど。
リソースがいくらでもある、って前提で富豪的考え方しか出来ん最近のゆとりプログラマには
結局最新技術も使いこなせないんだろうなぁ…
- 91 名前：名前は開発中のものです。 mailto:sage [2009/02/21(土) 15:25:48 ID:bQf1hP7d]
- タスクシステムは個々のタスクがグローバルなもの（例えばスクリーンデバイス）にばらばらにアクセスする。
ばらばらにアクセス＝グローバルなものの整理ができていない。
グローバルなものの整理ができていないと１万行を超えるプログラムを動作させるのは難しい。
www.kojima-cci.or.jp/fuji/mybooks/cdiag/cdiag.2.4.html
だから代わりに引数を使おう
www.kojima-cci.or.jp/fuji/mybooks/cdiag/cdiag.2.5.html
という話で終わるでしょ。
たとえ個人製作レベルでも１万行なんて普通に超えるよ。
もしタスクシステム使う人が
「1万行越えたらそのコードはいったん捨てて、タスクシステム使わずに１から設計し直すよ」
という認識を持っているならアリかもしれないが、
例えば
「1万行越え確実だけどタスクシステム使って設計するよ。
もちろん1万行超えたらそのコードはいったん捨てて、またタスクシステム使って１から設計し直おすよ」
と言う話ならナシ。
- 92 名前：名前は開発中のものです。 mailto:sage [2009/02/21(土) 15:31:55 ID:3HETWV4t]
- >>90
>>84
まあ、これは無駄に「現代」とくくったのがイカンかったね。
リソース使える場面でもタスクシステム使うといいよという例があったら頼むわ。
- 93 名前：名前は開発中のものです。 mailto:sage [2009/02/21(土) 15:33:38 ID:Dmt7DoEE]
- みんな熱いな。タスクについての認識や結論はもう出てると思う。
「使いたいやつが使えばいいと思う」
ただそれだけだ。
タスクのメリット話せと言われても、おそらく使ってる人も表現し辛い箇所なんだよね。
フレーム間を跨ぐ処理を書く上で多用するわけで、その辺はゲームによってまちまちだ。
じゃあ逆にタスク代替案も示せと言われても、
switchに戻すだとかで、これといって画一的な処理は示されないのが現状。
銀の弾丸は存在しない。それだけだよね。
- 94 名前：名前は開発中のものです。 mailto:sage [2009/02/21(土) 15:33:51 ID:IeOQ7r77]
- haskellとかでタスクシステムを実装するとしたらどんな感じになるか
ただしunsafeほげほげとかIORef禁止で
- 95 名前：名前は開発中のものです。 mailto:sage [2009/02/21(土) 15:45:18 ID:7rFrs1eT]
- >>91
そのURLに書いてあるのって、アクセスの話じゃなくて宣言を整理するって話じゃないの？
- 96 名前：名前は開発中のものです。 mailto:sage [2009/02/21(土) 15:46:27 ID:P36r7rTD]
- >>92
CPUリソースとメモリリソースを考慮に入れないなら
それこそどんなアルゴリズムでもいいんでない？遅かろうが無駄だろうが好きなの使えば。
作業効率とか考えるならプログラムも不要でツクールやMODでいいんじゃね？という感じ。
本職のプログラマなら、どんなチープな環境でも軽量・低コストで動作できる
アルゴリズムを知ってるのは十分メリットだと思うけど。
組み込みにしろ、携帯機にしろ、リソースの厳しい環境でやれって言われるのは
良くあることだから。
ま、個人製作ならそんなことどーでもいいんで、
そーなると実装方法を強制されない個人製作で何でアンチタスクになるのかが謎だが。
嫌いなら使わなきゃいいだけなのに。何でアンチ？
- 97 名前：名前は開発中のものです。 mailto:sage [2009/02/21(土) 15:47:46 ID:4jF5VqD/]
- >>91
なつかしいな「Ｃプログラミング診断室」
でもグロバール変数一覧は俺はオススメできないけどな
そもそも作るなといいたいｗ＞グローバル変数・関数
- 98 名前：名前は開発中のものです。 [2009/02/21(土) 15:48:18 ID:Vn5x9Xxe]
- Haskellはスレッドが数バイトしか使わないほど
軽いから結構かわりそう
- 99 名前：名前は開発中のものです。 mailto:sage [2009/02/21(土) 16:01:57 ID:3HETWV4t]
- >>96
いきなり極端になったな。
作業効率考えるなら〜の部分が唐突に投げやりなんだが、まあしゃあないか。
>>39
>>40
この流れをよく見てみよう。
結局、変に凝ってるのはどっちだよ。
アンチっていうか、こういう意味不明なこと言う奴に、
「リソースある場面でタスクシステム導入する奴は変に凝ってる」
と言いたいわけだ。
リソース無い場面で使うことに関して異論がないのはもう何べんも言ってるのでこれ以上繰り返さないようにな。
ちなみに>>39で想定している場面てリソースないような状況じゃないよな。
- 100 名前：名前は開発中のものです。 mailto:sage [2009/02/21(土) 16:04:15 ID:bQf1hP7d]
- >>95
そうです。今見返すと話つながってないっすね。混乱させてごめん。
１つ目のURL書いた理由は、グローバルなもの（マクロも変数も）を無秩序に使ってると
10000行あたりで破綻するという話を紹介したかったからです。
２つ目のURLはOKだよね？
- 101 名前：名前は開発中のものです。 mailto:sage [2009/02/21(土) 16:04:28 ID:Kwr5xaMF]
- >99
引数クンなのか、ごった煮リスト嫌いクンなのか、どっちなの？
それとも、それ以外？
複雑なものは理解できないクン？
- 102 名前：名前は開発中のものです。 mailto:sage [2009/02/21(土) 16:05:45 ID:a9F+sDW/]
- >>92
リソースが余ってるならC++を使う必要性自体がないのでは・・・ｗ
俺は>>84は、現代のプログラマでも「タスクも知っていた方が良い」ことを示すいい事例だと思った
リソース使える場面でC#やRubyよりC++使うといいよという例があれば前言は取り消す
- 103 名前：名前は開発中のものです。 mailto:sage [2009/02/21(土) 16:08:02 ID:07PQbtcV]
- >>76
> (5087 + 514 + 118 + 235) - 4684 = 1270
> その差５０行程度だが、どこが遥かになんだ。
タスクシステム使わないほうは、27%もソース増えてるじゃん。
開発時間はソースの量にだいたいは比例するから、
8時間の作業で済むところが、10時間強もかかる計算になるじゃん。
俺ならそんなの御免だね。
だから、俺は使えるところでは使ったほうがいいという結論だな。
使えないと思うところでは使わない。それだけのことじゃん。
- 104 名前：名前は開発中のものです。 mailto:sage [2009/02/21(土) 16:13:33 ID:4jF5VqD/]
- >>103
処理が減ったわけでもないのに
そこがそんなにうれしいとこなのか？
- 105 名前：名前は開発中のものです。 mailto:sage [2009/02/21(土) 16:16:13 ID:07PQbtcV]
- >>104
人間がバグを仕込んでしまう確率は、だいたいコードの分量に比例して増えるからね。
可読性を保っているなら、コードは少ないほうが望ましい。27%も違えば大きな違いだろう。
- 106 名前：名前は開発中のものです。 mailto:sage [2009/02/21(土) 16:18:18 ID:7rFrs1eT]
- >>100
１つ目が繋がってないのに２つ目を持ってこられても困るというか
個人的な感想を言えば、たったの１万行で破綻するとはとても思えない
- 107 名前：名前は開発中のものです。 mailto:sage [2009/02/21(土) 16:19:40 ID:4zHPU/si]
- とりあえず俺は実装についてはどうでもよくて、タスクシステムという名前へのアンチ
要はゲーム中で動く「モノ」のことでしょ？なんでわざわざタスクとか呼ぶん？
例えば「実例で学ぶゲームAIプログラミング」の２章が
もろにいわゆるタスクシステムやタスク間通信の近代的なC++実装だと思うんだが
タスクなんてひとっことも言わないし、こうやって作るんだとか誇りもしないのね。たいしたことじゃないから。
これがいまどきのありふれた感覚じゃねーの？
だいたい根本的に、「モノ」を管理するために低レベルなOSのアナロジーを使うこと自体が間違ってると思う。
そういうの実装を歪めると思わん？
「ゲームオブジェクト」「エンティティ」「アクター」なんでもいいけど、「タスク」だけはない。
具象的なネーミングとしても抽象的なネーミングとしても。
非ゲームプログラマがTaskという名前のクラスを見て、何なのかすぐ理解できるのかってことですよ。
お前らがやりたいのは、OSの稚拙な真似事じゃなくて、「モノ」を動かすことでしょ？
あーでもロスプラみたいにマルチコアに振り分けるならOS的要素強いかもね。わかんね。
結局、典型的な「自転車置場の議論」（0xcc.net/blog/archives/000135.html）なんだよなこれ。
松浦本読んだ程度のドシロウトでも参加できるという。
そういうのを避けるためにも俺はタスクシステムという言葉は使わない。
使ってるやつ見かけたら陰からこっそり指さして笑う。
- 108 名前：名前は開発中のものです。 mailto:sage [2009/02/21(土) 16:21:47 ID:3HETWV4t]
- 行数でインパクトがないからってパーセント換算するのはヤメようぜ。
- 109 名前：名前は開発中のものです。 mailto:sage [2009/02/21(土) 16:25:03 ID:3HETWV4t]
- タスクというとITRON思い出すから嫌なんだよな。
ITRONのタスクはすげーよ。なのに、タスクシステムのタスクは全然すごくねーよ。
このギャップにイラッとするのはある。
- 110 名前：名前は開発中のものです。 mailto:sage [2009/02/21(土) 16:25:40 ID:4jF5VqD/]
- >>105
それは本質をまったくみてないなぁ
１行ごとに中身のない改行を入れて「;」を打つだけでも行数だけは増えるじゃない
しかも今回のプログラムだって工夫すれば改行崩れの処理省きでcontinue文は消せてしまうので
それをソースコードの行数の増加と考えるのは上げ足取りをしてるようにしか見えない
むしろ、マクロでfor文を見えなくした>>510のがわかりにくくて気持ち悪い
このマクロっぽいのの意味を初見でみた人が知るには付属のタスクシステムテンプレートを
全部読んで理解するしかないでしょ？
これは嫌だなぁ
仮にマニュアルもなにもなかったとしたらかなり読める人限定されそう
- 111 名前：名前は開発中のものです。 mailto:sage [2009/02/21(土) 16:26:24 ID:07PQbtcV]
- >>108
このまま規模が大きくなっても、このパーセンテージは揺らがない。
タスクシステムを使わないほうのプログラムでは、どうしても27%ほどだけソースが大きくなる。
だから行数なんかには意味がない。このパーセンテージのほうがはるかに重要だ。
お前は、どうしてそれをごまかそうとするのか俺にはわからない。
- 112 名前：名前は開発中のものです。 mailto:sage [2009/02/21(土) 16:31:02 ID:07PQbtcV]
- >>110
> それは本質をまったくみてないなぁ
そんなことはない。大雑把にはソースの分量で判定できる。
どちらのプログラムも平均的なプログラマが書いたと仮定して、
タスクシステムを使わないほうは27%もソース分量が増えたのには違いない。
> むしろ、マクロでfor文を見えなくした>>510のがわかりにくくて気持ち悪い
あの程度のソースがわかりにくいとは思わないが、マニュアルがないと
正しく使えない人がいるというのには同意。
ただ、本人が開発するなら話は別だろう。
- 113 名前：名前は開発中のものです。 mailto:sage [2009/02/21(土) 16:33:03 ID:4jF5VqD/]
- >>111
酷いな
ループのカッコとnull判定のことでしかないのに
ここまでくると病気としかいいようがない
- 114 名前：名前は開発中のものです。 mailto:sage [2009/02/21(土) 16:35:43 ID:4jF5VqD/]
- まあ、でも差分がループのカッコとnull判定だけなんだから
それがタスクシステムの本来の役目ということがはっきりしたともいえるね
正直、差分がそこしか見えなかったんだからそれでいいんだよな？
タスクシステム＝ループのカッコとnull判定をはじけます
でおｋ？
- 115 名前：名前は開発中のものです。 mailto:sage [2009/02/21(土) 16:38:17 ID:07PQbtcV]
- >>113
あんたはプログラミング経験が浅くてわかってないんだろうが、ループも、二重ループにするとき、
i,jの添え字を間違えたり、null判定を忘れたり、continueを書き忘れたりするのが人間ってものなの。
そういう定型化している部分を共通部分として書き出して、どこか別のところに追いやったほうが
バグは減るわけ。それは別にタスクシステムでなくてもいいのだが。
forがforeachになっただけでずいぶんバグが減る。
foreachの終了のときのハンドラを定義する構文があればさらに安全性は高まる。
そうやって抽象化と共通部分の括りだしを繰り返して書いていくのがプログラムだろう。
- 116 名前：名前は開発中のものです。 mailto:sage [2009/02/21(土) 16:40:14 ID:3HETWV4t]
- >>111
>このまま規模が大きくなっても、このパーセンテージは揺らがない。
どこがそんなにラクになるのかなと見直したが、２重のforループがTASK2と書けるんだね。
ここでだいぶ文字数稼いでるみたいだ。
んで、それがそんなにうれしいことなのかと言われるとNOな訳で。
- 117 名前：名前は開発中のものです。 mailto:sage [2009/02/21(土) 16:40:41 ID:4jF5VqD/]
- >>115
だから
タスクシステム＝ループのカッコとnull判定をなくした最新鋭のシステムです
でいいんだろ？
- 118 名前：名前は開発中のものです。 mailto:sage [2009/02/21(土) 16:41:07 ID:07PQbtcV]
- >>114
> 正直、差分がそこしか見えなかったんだからそれでいいんだよな？
全然違うね。
510のように抽象化することで、自動並列化のようなことが可能になってくる。
まあ、510のソースを自動並列化するのは正直無理だが、もう少し抽象化して、
各タスクの役割を明確に記述できれば自動並列化できる。
- 119 名前：名前は開発中のものです。 mailto:sage [2009/02/21(土) 16:41:26 ID:P36r7rTD]
- >>107
「ウォークマン」みたいなものじゃない？
最初に有名になって、それ以降類似したものの総称として
便利だから名前だけ使ってるって。
>非ゲームプログラマがTaskという名前のクラスを見て、何なのかすぐ理解できるのかってことですよ。
タスクシステムを使うのはゲームプログラマでしょ。普通は。
いちいち現場で「これはオブジェクトを管理するシステムで更新と描画で登録関数が呼ばれて…」
とか説明するより「タスクシステム的なもの」の一言でゲームプログラマならだいたいって通じるし。
ま、デザインパターンみたいにちゃんと定義と命名されればいいんだろうけど
ゲーム業界固有の物だしねぇ
- 120 名前：名前は開発中のものです。 mailto:sage [2009/02/21(土) 16:41:35 ID:07PQbtcV]
- >>116-117
>>118
- 121 名前：名前は開発中のものです。 mailto:sage [2009/02/21(土) 16:45:39 ID:4jF5VqD/]
- >>118
それは>>510からはいえないな
実際、>>510と>>641の間で自動化云々って話はないわけだし
自動化を証明したければ比較のソースを書いてからだな
それまではいっちゃいけねぇだろ
俺も否定しないし
少なくとも>>510と>>641の間では自動化は見えなかった
今回はこれが結論
- 122 名前：名前は開発中のものです。 mailto:sage [2009/02/21(土) 16:52:23 ID:3HETWV4t]
- まあ、２重のforループで文字数稼いでいるということは、
forループの中身が増えれば増えるほどその稼ぎは薄まる訳だ。
規模が巨大になればなるほどパーセント減るようにしか見えないぞ。
その辺どうなのよ。
- 123 名前：名前は開発中のものです。 mailto:sage [2009/02/21(土) 16:55:30 ID:07PQbtcV]
- >>121
510と641を並列化するソースを書き比べればすぐにわかるよ。
そんな本格的なものでなくていいから。
2重ループでi×jのループ回してるところ、あれをi×j / N のループに
分けて実行して、すべてのスレッドの終了をセマフォで待つだけでいいよ。
- 124 名前：名前は開発中のものです。 mailto:sage [2009/02/21(土) 16:56:43 ID:07PQbtcV]
- >>122
> forループの中身が増えれば増えるほどその稼ぎは薄まる訳だ。
> 規模が巨大になればなるほどパーセント減るようにしか見えないぞ。
それはもちろん正しい。そのへんはゲームの性質によるだろう。
- 125 名前：名前は開発中のものです。 mailto:sage [2009/02/21(土) 17:14:52 ID:3HETWV4t]
- >>124
>>111
- 126 名前：名前は開発中のものです。 mailto:sage [2009/02/21(土) 17:27:14 ID:iOCBxjYv]
- タスクシステムとやらのメリット
コードが一割減
タスクシステムのデメリット
可読性が低くなる
この調子でお願いします
メリットわかってるんだったらごまかさずに書けよ
そんな出し惜しみばかりするから無駄に荒れる
- 127 名前：名前は開発中のものです。 mailto:sage [2009/02/21(土) 17:35:18 ID:07PQbtcV]
- >>126
コード削減、一割減はちょっと違うと思うな。
今回の例ではタスクシステムを使わないと27%増。
俺の感覚では、だいたいこの数字はどんなゲームでもそんなに変わらなくて
平均すれば20%前後だと思うな。これが10%程度ってことはないな。
並列化とかもっと大がかりな仕組みがタスクシステム側に用意されていれば
この差はもっと広がるしな。まあ、それをタスクシステムと呼んでいいのかは知らんが。
- 128 名前：名前は開発中のものです。 mailto:sage [2009/02/21(土) 17:46:01 ID:iOCBxjYv]
- じゃあ二割減でもいいや
開発速度向上はない、可読性が低いものほど開発に時間がかかるから
タスクシステムとやらのデメリットとして
開発に時間がかかるというのも追加できる
この調子ならメリットデメリットを列挙できそうだな
選択肢になりうるかどうかはそれを見れば判断できるだろう
化けの皮を一枚ずつはいでいくのは楽しいの
- 129 名前：名前は開発中のものです。 mailto:sage [2009/02/21(土) 17:52:15 ID:07PQbtcV]
- >>128
> 開発速度向上はない、可読性が低いものほど開発に時間がかかるから
ソース全部理解しなくても、510のタスクシステムは使えるだろ。
TASK2(クラス名A,クラス名B)
{
クラス名A1.XXX = YYY;
クラス名B2.ZZZ = WWW;
}
こう使うだけじゃん。説明に1分も要さないと思うが？
- 130 名前：名前は開発中のものです。 mailto:sage [2009/02/21(土) 17:52:47 ID:Kwr5xaMF]
- >128
> 開発速度向上はない、可読性が低いものほど開発に時間がかかるから
> タスクシステムとやらのデメリットとして
まずタスクシステムのどこが可読性低いのかを示してもらわないと。
FSMになってるところ？ 関数ポインタの部分？ ごった煮リスト？
- 131 名前：名前は開発中のものです。 mailto:sage [2009/02/21(土) 18:15:26 ID:D/oVP314]
- >>130
自分のタスク内で完結しない処理に関しては、全部グローバル変数経由
ゲーム中のあるシーンを想定した場合、そこで何のタスクがどういう順番で走るかが、
コードの一箇所を見てもわからない。
- 132 名前：名前は開発中のものです。 mailto:sage [2009/02/21(土) 18:15:57 ID:4jF5VqD/]
- >>129
でも読みにくいなぁ、おいｗ
それが何を表してるのかさっぱりわからないぜｗ
ループ隠しただけなのになｗ
- 133 名前：名前は開発中のものです。 mailto:sage [2009/02/21(土) 18:24:15 ID:hYClRP74]
- >>131
>自分のタスク内で完結しない処理に関しては、全部グローバル変数経由
そんな処理するのはタスクじゃないだろ。
- 134 名前：名前は開発中のものです。 mailto:sage [2009/02/21(土) 18:26:52 ID:D/oVP314]
- >>118
> もう少し抽象化して、各タスクの役割を明確に記述できれば自動並列化できる。
そんな簡単じゃないよ。
並列処理は計算機科学の分野では長らく研究されていて、いろいろ知見が積み重なってるんだが、
少なくとも 510 からは、自動並列化につながる筋道がまったく見えない。
夢が大きいのはいいんだが、まったく現実性が無いのもどうかと思うぞ。
- 135 名前：名前は開発中のものです。 mailto:sage [2009/02/21(土) 18:32:19 ID:a9F+sDW/]
- タスク擁護派から言わせてもらうが、>>129 は読みづらいよ
初めて読む STL や Loki や boost と同じくらいにね。俺なら使わん
結局、あるライブラリを使うメリットは普及してるかどうかだ
strcpy や strncpy を使うメリットはなんだ？
みんなあの仕様はおかしいと感じているのに？ タスクもそれと同じこと。
そして、普及さえしていなければメリットはないと考えて必死で叩くお前らは正しい
- 136 名前：名前は開発中のものです。 mailto:sage [2009/02/21(土) 18:40:14 ID:07PQbtcV]
- >>134
> 並列処理は計算機科学の分野では長らく研究されていて、いろいろ知見が積み重なってるんだが、
> 少なくとも 510 からは、自動並列化につながる筋道がまったく見えない。
「自動」の意味を誤解しているようだが、
自動車は、自動的に目的地まで運んでくれる乗り物ではないのと同様、
人間が何もしなくてもいいという意味ではない。
俺が「自動」並列化と言っているのは>>123の意味。
例えば、TASK2をP_TASKと人間が書き換えればあとは自動的に並列化してくれるように改造するのは容易。
なんでこれが出来ないと思うのか、俺はお前らの技術力を疑いたくなる。本当にお前らプログラマなのか？
- 137 名前：名前は開発中のものです。 mailto:sage [2009/02/21(土) 19:05:26 ID:D/oVP314]
- >>136
> なんでこれが出来ないと思うのか
その程度で済むなら OpenMP がやってる
- 138 名前：名前は開発中のものです。 mailto:sage [2009/02/21(土) 19:18:40 ID:4jF5VqD/]
- >>136
なんにも自動化しないだろｗ
- 139 名前：名前は開発中のものです。 mailto:sage [2009/02/21(土) 19:35:06 ID:07PQbtcV]
- >>137-138
お前らが何もわかってないただの自称プログラムだというのは十分わかった。
123すら出来ないとはな。
- 140 名前：名前は開発中のものです。 mailto:sage [2009/02/21(土) 19:51:24 ID:07PQbtcV]
- >>138
お前本当に日本人か？どう見ても中国人だろ。
前スレ、前前スレから日本語が極端に不自由な奴が二名いるみたいだが、お前はそいつだろ。
プログラム以前に日本語教室行ってこいよ。
- 141 名前：名前は開発中のものです。 mailto:sage [2009/02/21(土) 19:59:47 ID:4jF5VqD/]
- もはや進む方向が頭おかしいじゃん
ループなんかはずして喜ぶプログラマいないってｗ
むしろ、ループ処理してるならfor文を見えるところにおいておいてほしいだろ
誰がこんな構造にして喜ぶのか？
ちょっとは考えろよ
- 142 名前：名前は開発中のものです。 mailto:sage [2009/02/21(土) 20:09:26 ID:D/oVP314]
- >>139
依存関係も副作用も無いコードなら、そら簡単に並列処理できるさ。数値計算だと
割と多いが、ゲームでそれはほとんどないだろ。
- 143 名前：名前は開発中のものです。 mailto:sage [2009/02/21(土) 20:43:23 ID:HdiuLFdj]
- 日本語がおかしかったら中国人ってなんできめつけんの？
インド人かもしれんし韓国人かもしれんだろ
- 144 名前：名前は開発中のものです。 mailto:sage [2009/02/21(土) 20:43:36 ID:iOCBxjYv]
- 可読性に関してはDSLの圧勝なので
それに比べてタスクシステムは可読性がないと言えるのは間違いないよ
専門家でも読むのが難しい本と、幼稚園児が読める絵本とでは
同じ文字数だとしても
絵本の方が圧倒的に速く読めるでしょう、当たり前だけどな
使えるから使えると言ってるけど
使ったら他の選択肢がなくなるから、使えるからと言って考えなしに使うなと
昔の偉い人とエロイ人もゆってた
つまり、エロエロよー
- 145 名前：名前は開発中のものです。 mailto:sage [2009/02/21(土) 20:47:01 ID:Dmt7DoEE]
- >>142
横槍ですまんが、あくまでゲームで並列処理は難しいと決め付けるのは良くない。
ゲームは依存化が明確にしやすく、
割と並列化しやすいとMTフレームワークの中の人が言っております。
game.watch.impress.co.jp/docs/20070131/3dlp.htm
>石田氏は「タスクという観点から見ると、依存関係は最小化でき、
>むしろゲームプログラムは並列化しやすいともいえるんです」と、
>これまでのゲーム開発の常識とは正反対の意見を主張する。
これには自分も驚いたが、
MTフレームワークの製作者が実践してそう思ったのなら説得力があると思わないか？
まぁ、予想(予測)と理論と実践はそれぞれ違うって事だ。
- 146 名前：名前は開発中のものです。 mailto:sage [2009/02/21(土) 20:56:31 ID:D/oVP314]
- >>145
予想というか、仕事で実際にゲーム書いてた経験談なんだが。モーションとかレンダリング
まわりのジョブはわりと分割しやすいんだけど、いわゆるゲームロジックに絡む部分は、
かなり難しい。
排他制御は特にバグが入りやすい部分だし、仕様変更多発が想定されるゲームロジック
部分を並列処理するのはリスキー。
- 147 名前：名前は開発中のものです。 mailto:sage [2009/02/21(土) 21:03:43 ID:Dmt7DoEE]
- 完全に頭ごなしに否定するのではなく、
そのリスキーな部分をいかにして、
安全で仕様変更に強い設計で書くのかを議論していってもいと思うわけよ。
仕事でロジック部分の並列化やられたら、うへぇってなるが、
趣味だったら面白いネタだとおもわないかい？
- 148 名前：名前は開発中のものです。 mailto:sage [2009/02/21(土) 21:13:55 ID:Dmt7DoEE]
- まぁ俺はタスク使わない派だけれども、
もしタスク派が生き残りをかけるのなら、マルチコア時代の恩恵を
受けられるような並列処理の記述性ただ1点だけ突き詰めるのが良いとおもうぜ。
- 149 名前：名前は開発中のものです。 mailto:sage [2009/02/21(土) 21:15:06 ID:iOCBxjYv]
- 前スレでは、誰かがプロも使っているタスクシステムと言ってたな
他人の権威にすがって偉そうにする奴も世の中にはたくさんいる
そういう奴は最後には命乞いをして延命を図る
延命を図るのだよっっっ
くやしいのぅ、くやしいのぅwww
- 150 名前：名前は開発中のものです。 [2009/02/21(土) 21:37:12 ID:H2kw4iDd]
- ID:Dmt7DoEE
前スレの>>510は名乗るのをやめても
タスク信者の特徴は消せないのだから
名乗るといい
名無しでの火消し＆誘導は無駄
- 151 名前：名前は開発中のものです。 mailto:sage [2009/02/21(土) 21:43:42 ID:Dmt7DoEE]
- いや。俺は以前>>22を書いた者で、すまんが510とは別人だ。
実際にタスクについては主に見通しの問題で否定的で、参照構造についても目的が無ければ無意味な足枷でしかないと考えている。
ただ、並列化については興味があるわけ。マルチスレッドで速度を稼げるのならそういう技術も覚えたいと思っている。
そんな中、自動並列化についてタスクにはその可能性がなきにしもあらずと考えている。
まぁ自分は実装するのはゴメンだがね。
- 152 名前：名前は開発中のものです。 mailto:sage [2009/02/21(土) 21:49:55 ID:07PQbtcV]
- >>142
> 依存関係も副作用も無いコードなら、そら簡単に並列処理できるさ。数値計算だと
> 割と多いが、ゲームでそれはほとんどないだろ。
あんた、本当に大きなゲームのプログラム書いたことがなさそうだな。
並列化して処理時間を稼ぎたい部分って、同期のためのコストとかもあるから
実際はかなり粒度の大きな、単純な計算が繰り返される処理なんだよ。
ゲームのうち、衝突判定とかは特にそういう計算ばっかりだ。
まあ、>>145でもすでに指摘されているが。
このスレは本当に商用で大きな規模のゲームを作ったことがあるのかと
疑いたくなるような奴ばかりで俺はただただ呆れるばかりだ。
- 153 名前：名前は開発中のものです。 mailto:sage [2009/02/21(土) 21:50:34 ID:D/oVP314]
- >>151
> そんな中、自動並列化についてタスクにはその可能性がなきにしもあらずと考えている。
そもそも、CPU 食ってるのはゲームロジックより、ヒット判定やモーション処理だったり
しないか？ 将棋とかの AI は別だけどさ。
そこは仕様が比較的安定しているから、作りこむだけのコストがかけられる。自動並列化
なんていわずとも、従来のロックベースの方法で OK。
- 154 名前：名前は開発中のものです。 mailto:sage [2009/02/21(土) 21:55:00 ID:3HETWV4t]
- 一般的な自動並列化と俺定義の自動並列化で話が通じ合ってないな、お前ら。
- 155 名前：名前は開発中のものです。 mailto:sage [2009/02/21(土) 21:59:19 ID:D/oVP314]
- >>152
衝突判定は、単に「ぶつかってる・いない」を判定するだけなら簡単なんだが、衝突の
解決が絡むと並列化が割と難しい。
衝突解決には、たとえば「壁は動かない」「プレイヤーが壁に当たったら押し戻される」
「プレイヤーと NPC があたったら NPC 優先」とかルールを決めて、それに応じて
優先順位つけて解決していくのが一般的だと思うが、問題は解決するときに相互
作用が発生することなんだよな。
シーケンシャルに処理するなら、割と手抜きアルゴリズムでもそれっぽく見えるんだが、
並列処理するとなったら、とたんに複雑さが増す。前に一度やってみてメゲた。
- 156 名前：名前は開発中のものです。 mailto:sage [2009/02/21(土) 22:02:28 ID:Dmt7DoEE]
- >>153
コンシューマならCPUの数と使用用途が特定されてるもんだが、現実的に考えて決めうちでが妥当だと思う。
PCのような特定されないマルチCPUの環境を考えると、自動で並列化するのは面白いんじゃないんかねぇ……。
自動並列化といっても、正直こればっかりは実装してみないと、
どのようにスレッド分配され、パフォーマンスが上がるのか下がるのかは、議論できんところだね。
- 157 名前：名前は開発中のものです。 mailto:sage [2009/02/21(土) 22:08:58 ID:3HETWV4t]
- お前らｗ
>>136で自動並列化の俺定義出してるんだから、ここはそれに合わせてやれよ。
>>136はライブラリ提供者が、ライブラリ利用者に分からないようこっそり裏で並列化（手作業）しやすいよ。
と、言ってるんじゃないの？ 違うか？
ちなみにID:D/oVP314とその他は一般的な意味で話してるような気がする。
ググって出てくるような一般的な意味ね。
- 158 名前：名前は開発中のものです。 mailto:sage [2009/02/21(土) 22:14:35 ID:D/oVP314]
- >>157
っつか、それはデータの依存性自動検出とかできないと無理なわけで。ハードルが
超高い。
- 159 名前：名前は開発中のものです。 mailto:sage [2009/02/21(土) 22:16:13 ID:3HETWV4t]
- ループの抽象化が人為的ミスを防ぐとか、>>123の意味で処理を挿げ替え易いというのは分かる。
出来るだけ先入観を抜きにして、もう一度>>510を読んでみた。
やっぱり、TASKマクロのもどかしさが引っかかるんだよな。
iとjどっちも0からブン回してるけど、星衝突ループはj=i+1からで充分。
オーダーが変わってくるんだけど、その辺手が出せないじゃん。
そんな場合、TASK2Bマクロでも作るのかな？
ライブラリに任せでこういう不備があると面倒だ。
しかもこれに対処するとアドバンテージ消えそうだな。
WindowだのApplicationだのをタスク化してるのも意味不明だな。
継承したものがまるまる無駄になってるのが大雑把すぎ。
TASK2に突っ込みたいがためにやってるだけなら、やっぱり無駄過ぎだよな。
先行投資と言っても、その投資が回収されるまでは過度の抽象化にすぎないわけだ。
んで、>>641バグっるかもって作者言ってたけど、ホントにバグっててワロタ。
・万有引力はj=0から回さないとダメ。
・星衝突で自分同士の場合のcontinueが抜けてる。
あとはOK。
- 160 名前：名前は開発中のものです。 mailto:sage [2009/02/21(土) 22:22:05 ID:Dmt7DoEE]
- >>158
その超高いハードルを、どうしたら解決できるだろうかを議論しようじゃないか。
たとえば>>510はデータ集約について提案し、
参照構造の是非について議論しようとしていたようだよね。
オブジェクトの所有/解放を(ライブラリ内で見えないように)行うことで、
並列化の足掛かりを見出そうとしたようだよ。第1歩というか、パフォーマンス的には第-1歩だけど。
- 161 名前：名前は開発中のものです。 mailto:sage [2009/02/21(土) 22:25:18 ID:3HETWV4t]
- まあ、>>123みたいな部分で泥臭い作業が発生したとしても、
俺は>>510より>>641のほうが良いね。
「シンボル'Star2'は定義されてません」とかVCに言われてイラつくこともないし。
無駄や不透明な部分があると精神衛生上良くない。
- 162 名前：名前は開発中のものです。 mailto:sage [2009/02/21(土) 22:26:57 ID:D/oVP314]
- >>160
> その超高いハードルを、どうしたら解決できるだろうかを議論しようじゃないか。
本気でやるなら、サーベイ論文読むところからスタート。かなり研究されてる分野だから、
ゼロから何かやるとか時間の無駄なので。
- 163 名前：名前は開発中のものです。 mailto:sage [2009/02/21(土) 22:31:42 ID:4jF5VqD/]
- >>162
そんなくだらいこと研究して金もらってる奴がいることに驚きだぜｗ
- 164 名前：名前は開発中のものです。 mailto:sage [2009/02/21(土) 22:36:21 ID:07PQbtcV]
- >>161
> 「シンボル'Star2'は定義されてません」とかVCに言われてイラつくこともないし。
インテリセンスでるのにそんなミスやるはずがないじゃん。あんた使ってるのVC98？
- 165 名前：名前は開発中のものです。 mailto:sage [2009/02/21(土) 22:39:35 ID:D/oVP314]
- >>163
並列処理のアルゴリズム・データ構造まわりは昔から研究ネタとしてはよくあるんだが、
単一プロセッサの性能向上が頭打ちになるのが現実的になってきた頃から、Intel, IBM を
はじめとした企業が金と人突っ込んでる。
公開されていて実際に開発に使えるレベルになっている成果というと、たとえば Intel
Threading Building Block とかさ。
- 166 名前：名前は開発中のものです。 mailto:sage [2009/02/21(土) 22:40:53 ID:3HETWV4t]
- いや、自動並列化は普通に研究対象としてアリだろ。
これから必要になってくる分野だぞ。
タスクシステムにしてもな、
ゲームの根幹的な制御部に使うのはかえって面倒そうなのでやっぱり嫌だ。
単純で、相互作用がなくて、あったとしても誤差許容できて、計算結果はゲーム性に影響しない。
ベストエフォートで充分なところなら使えそうだとは思った。
大量の火花エフェクトとか、そういう余力でやればいいような部分。
- 167 名前：名前は開発中のものです。 mailto:sage [2009/02/21(土) 22:42:18 ID:3HETWV4t]
- >>164
右クリック→定義へ移動
- 168 名前：名前は開発中のものです。 mailto:sage [2009/02/21(土) 22:45:19 ID:Dmt7DoEE]
- >>162
すまん。俺も本気でやるつもりは無いんだ。
正直、並列化には憧れているが、鬼門だと思ってる。それが手動であっても自動であってもさ。
ゲームではない自分の専門分野でIntelC++とMPIで稼ぐ実装をした事があるが、
冗長になった割にパフォーマンスが出なくて萎えた経験がある。
もしゲーム特化で、安全で保守の掛からないデータ構造を有するタスク自動並列化のライブラリが出来たのなら、
金貰ってもいいレベルだと思う。個人が趣味でやる分野じゃないねぇ。
- 169 名前：名前は開発中のものです。 mailto:sage [2009/02/21(土) 22:54:04 ID:4jF5VqD/]
- 結局、自動化ってあんまり意味ないよね
プログラムって最低限設定しなきゃいけない内容は絶対に自動にならねぇし
結局は上にスルーパスして設定を任せるだけになる
スクリプト組んでも苦労する人間が変わるだけで絶対的な作業量は無くならない
むしろ、トータルでは増えてしまう場面のが多いかもね
そりゃプログラマの仕事があんまり高度で・・・っていうならわかるけど
できたスクリプト言語がＣ言語とあまり変わらんようなのってどうよ？
ってのと同じでタスクシステムも結局処理をスルーパスしてるだけで
自動化してるように見えるだけでしょ？
- 170 名前：名前は開発中のものです。 mailto:sage [2009/02/21(土) 23:00:58 ID:Dmt7DoEE]
- >>169
ん？複数スレッドにタスク単位で処理を投げてパフォーマンスを稼ぐ「自動並列化」の話だよ？
- 171 名前：名前は開発中のものです。 mailto:sage [2009/02/21(土) 23:02:21 ID:D/oVP314]
- >>169
データ構造と処理内容を限定することで、並列処理を定型化して簡単に使えるように
するってのは、話としては分かる。
ただ、それを目指すならタスクとやらは starting point としては全然ダメなのが萎える。
- 172 名前：名前は開発中のものです。 mailto:sage [2009/02/21(土) 23:02:42 ID:07PQbtcV]
- >>169
ID:4jF5VqD/はド素人か。本当にゲーム作ったことあんのか？
お前、一人だけレベルが低すぎる。もう引っ込め。
|
 |
