10/10/01 19:54:53 ZGMtyIlk
タスクシステムで～す。
2:名前は開発中のものです。
10/10/01 23:32:23 smcLQQMe
古典タスクシステム（このスレでは「>>2」と呼ぶ）
White Paper - Programming
URLﾘﾝｸ(homepage3.nifty.com)
タスクシステム
URLﾘﾝｸ(www5f.biglobe.ne.jp)
CodeZine：本格的なシューティングゲームを実現するタスクシステム（タスクシステム，シューティング，ゲーム）
URLﾘﾝｸ(codezine.jp)
Logician Lord … 【コンピュータゲームのからくり】
※ウェブアーカイブのキャッシュ
URLﾘﾝｸ(web.archive.org)
タスクシステムのご先祖の「ジョブコン」は
URLﾘﾝｸ(game.2ch.net) の 810
3:名前は開発中のものです。
10/10/01 23:34:03 smcLQQMe
URLﾘﾝｸ(ja.wikipedia.org)
あらすじ
新しいシステムが大好きなゲームプログラマの元に、二人組の詐欺師が
プロのゲーム開発者という触れ込みでやって来る。
彼らは何と、馬鹿や自分にふさわしくない仕事をしている者にはメリットが
理解できない不思議なシステムを紹介してくれるという。
プログラマは大喜びで紹介されたとおりに実装する。
他のプログラマにメリットを聞かれた時、自分がこれまで慣れ親しんだ
コードを正当化してくれるはずのメリットが説明できない。プログラマは
うろたえるが、そのシステムを自慢げに見せた後輩プログラマたちの手前、
本当の事は言えず、ありもしないメリットから目をそらさせるため
「馬鹿には理解できない」と言い続けるしかない。後輩は後輩で、自分には
メリットが理解できないもののそうとは言い出せず、空気を読んで目をそらす。
プログラマはメリットもないシステムに増築を重ねて開発終盤に臨む。
火消しプログラマも馬鹿と思われてはいけないと同じようにそのシステムを
使い続けるが、その中のまだ空気を読めていなかった新入りが、こう叫ぶ。
「このシステム邪魔だよ!」
4:名前は開発中のものです。
10/10/02 14:57:04 3G+xsfMG
>>1が過去をなかったことにしたがってるので過去スレ一覧1でも張っておくか
タスクシステムについての議論、相談、質問、雑談などのスレです
part9 ｽﾚﾘﾝｸ(gamedev板)
part8 ｽﾚﾘﾝｸ(gamedev板)
part7 ｽﾚﾘﾝｸ(gamedev板)
part6 ｽﾚﾘﾝｸ(gamedev板)
part5 ｽﾚﾘﾝｸ(gamedev板)
part4 ｽﾚﾘﾝｸ(gamedev板)
part3 ｽﾚﾘﾝｸ(gamedev板)
part2 ｽﾚﾘﾝｸ(gamedev板)
part1 ｽﾚﾘﾝｸ(gamedev板)
・タスクと呼ばれる実装は、非常に多岐に渡ります
古典タスクシステムについての話題は「>>2」と明示してください
そうでない場合はカスタム版であることを明示してください
・人を憎んで言語を憎まず
5:名前は開発中のものです。
10/10/02 16:46:55 ivfidkIQ
タスクシステム最高や！
6:名前は開発中のものです。
10/10/04 04:42:00 wZ2Od63Y
>2をチラ見しただけだが、主人公や敵やアイテムを同一の抽象クラスの継承で作って、
抽象クラスの配列で全部を管理する、ってのはタスクシステムとやらにあたるのか？
だとしたら俺は知らずに使ってたな。
7:名前は開発中のものです。
10/10/05 07:48:11 sdbMWIqN
なんかロクな資料が無いな。>>2
8:名前は開発中のものです。
10/10/05 18:54:00 421zFKXd
んじゃ、納得できるまともな資料ないのかよ
9:名前は開発中のものです。
10/10/07 18:50:46 5CN7mPsf
タスクシステムを理解はできるが
特に新しくもない、びっくりすることもない、普通の汎用システムかなと思った
今のゲームでは０フレーム割り込みや、指定したタスクの削除、優先順位の変更とかが加わってるから ここの資料は古い
10:名前は開発中のものです。
10/10/07 23:44:44 vlNFvdd4
普通て
11:名前は開発中のものです。
10/10/08 03:32:57 dA38FdUI
>>9 ごった煮リスト使いが何を偉そうに(ﾌﾟ
12:名前は開発中のものです。
10/10/08 22:17:51 ublp+ohs
実行単位を抽象化したもの
13:名前は開発中のものです。
10/10/08 22:33:17 H111P/KO
基本的概念は今でも通じる
しかし抽象化が人によって１００人１００通りあって、ののしりありの状態
これでは発展しない
まとめ役が必要ではないだろうか
14:名前は開発中のものです。
10/10/08 22:42:10 H111P/KO
>>11
のように人格非難を行い、人権尊重を行わない環境では前向きな議論ができない
似たようなものに、ジョブやタスクなどあるが、これらを参考に１００％ではないが、納得できる抽象的にコード化できる人物が必要ではないか
そして、オープンソースにすることによって、より多くの人に使ってもらえて、さらなるフィードバックが行われ、より改善されていくのではないだろうか
今までは、タスクを一定の決まった業務名で決めきっていたが、今は抽象化というあいまいな言葉で表現するので、なかなか理解されにくい
おそらく C,アセンブラ時代のシステムと思われるが、メモリが大量に使えるようになった今ではもっと応用できるようになるのではないだろうか
15:名前は開発中のものです。
10/10/10 02:33:13 BGhnH7my
＼ ／
￣￣￣￣￣￣￣￣￣￣￣∨￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
＿＿＿_
／ ＼
/＼＿＿_／＼ ..／ ⌒ ⌒ ＼
／ ／ ヽ ::: ＼ ／ （●） （●） ＼
| （●）, 、（●）、 || （__人__） |
| ,,ノ(、_, )ヽ、,, |＼ ｀ ⌒´ _／
| ,;‐＝‐ヽ .:::::| | ＼
＼ ｀ニニ´ .:::／ .| | | |
／｀ー‐--‐‐―´´＼―┴┴―――┴┴――
.ｎ:n ｎｎ
nf|｜| | | |^!n ＿|＼∧∧∧ＭＭＭＭ∧∧∧／|＿
ｆ|.| | ∩ ∩|..| |.| ＞ ＜
|: :: ! } {！ ::: :| ＜ NO THANK YOU ＜
ヽ ,イ ヽ :イ .＞ ＜
￣|／∨∨∨ＷＷＷＷ∨∨∨＼|￣
16:名前は開発中のものです。
10/10/10 18:20:56 uUzLGcmj
>>14
「ジョブ」や「タスク」は std::fucntion (boost::function) に、
それを集めたコンテナは std::list や std::map に抽象化および汎用化
されているだろ。しかもオープンソースで。仕様も明確に文書化されて
おり、関連情報も Web 上に関連情報もたくさんある。結果、もっと応用
できるようになっている。
これでもまだ何か問題ある？
17:名前は開発中のものです。
10/10/11 02:24:38 wa/o1WvE
歴史は繰り返すｗ
18:名前は開発中のものです。
10/10/13 18:15:32 2KiuekrF
>>16
それをつかったタスクシステムを早く見せてみろ。
能書きはいいから早くやれ。
19:名前は開発中のものです。
10/10/13 21:28:01 CCduEWNw
>>18
それが人にものを頼む態度か？
20:名前は開発中のものです。
10/10/14 01:16:15 ll+gWl86
>>18 typedef std::function Task; typedef std::multimap<int, Task> TaskSystem;
21:名前は開発中のものです。
10/10/14 15:23:01 k3ms7C9R
>>20仮想関数よりおせえぞ、このカスが。
22:名前は開発中のものです。
10/10/15 01:16:59 DzwiEmkJ
>>21
URLﾘﾝｸ(www.boost.org)
> Invocation efficiency
> With a properly inlining compiler, an invocation of a function object requires
> one call through a function pointer. ...
有意な差がでるとは思わんのだけど、どんな計測して言ってるの？
23:名前は開発中のものです。
10/10/15 03:34:52 wNB49Iff
レスが遅いっていう意味じゃないのか
24:名前は開発中のものです。
10/12/13 19:19:30 SwUzzdNV
うおーおちるｗｗｗ
25:名前は開発中のものです。
10/12/13 20:04:26 L8WMZWjV
落ちていいんじゃない
26:名前は開発中のものです。
10/12/26 13:53:29 Yn0HjZGE
保守
27:名前は開発中のものです。
11/01/19 04:08:40 N8paXvut
燃料投下age
URLﾘﾝｸ(d.hatena.ne.jp)
28:名前は開発中のものです。
11/01/19 08:55:53 85Pl9gjp
いってみたらすでに論破されてた
29:名前は開発中のものです。
11/01/19 10:13:05 e0eMWBCA
名前からして不明瞭。
そこに嫌な匂いを見出せるのは、
ある程度苦労したプログラマ。
30:名前は開発中のものです。
11/01/19 14:09:28 E8wjYx2w
これが島国さんやnyaxtさんの書いた記事だったりすると反応違うんだろうなｗ
31:名前は開発中のものです。
11/01/19 14:23:28 85Pl9gjp
ゲーＰＧはネームバリュー（ハッタリ）に弱い人間少ない気がする
むしろ、俺がそいつを粉砕してやるぜ的な
32:名前は開発中のものです。
11/01/19 14:30:26 KQY63ukG
PCエロゲ界の貴公子の近代的～が唯一の参考文献としてあげられてるのは
「私の話は眉に唾をたっぷり塗りたくってから読んでください」というシグナルだろ
メモリアロケーションとタスクコントロールの都合をゴチャ混ぜにしてる時点で
ウェブ上に幾度となく流布されてきたアマチュア発の怪文書の仲間入り
33:名前は開発中のものです。
11/01/19 23:21:57 vxFFDIc1
いいかげんCEDECで白黒はっきりすべき
なぁなぁで適当なセッションばっかやってるんじゃねーよ
34:名前は開発中のものです。
11/01/20 09:09:02 3uJfSIst
このぐらいのトラップはあったほうがいい
35:名前は開発中のものです。
11/01/21 16:04:26 Fjw2Tp9y
理解はできるが それほどはしゃぐほどのしろものじゃぁないと思う ＞ タスクシステム
36:名前は開発中のものです。
11/01/22 03:03:53 4JOlz5Oe
いやそれじゃまったくわかってない
37:名前は開発中のものです。
11/01/22 07:25:59 QooqzLRE
アセンブラレベルで組んでたら当然このようなシステムになると思う ＞ タスクシステム
38:名前は開発中のものです。
11/01/22 07:38:28 QooqzLRE
なので、今の１G単位のファイル扱い時代には、>>3 にあるとおり邪魔すぎる
しかも >>2 のリンク先のとおりに組んでたら１００％環境に依存したものができるね
構造化設計がきちんとできれば、別に困らない
39:名前は開発中のものです。
11/01/26 20:44:21 4Ps2t9ZU
ちょっとしたところを書かせても、
ちょっと見通しよく書いてくれる人と、
ちょっと見通し悪く書いてしまう人が居るね。
40:名前は開発中のものです。
11/02/02 17:54:54 WROn6kOq
元々はアセンブラレベルで簡単なコルーチンを実現するシステムだった（ジョブコン）。
いつのまにやら、C言語で実装されコルーチンではなくなって、コールバック管理システムになり、
いろいろごてごてと御利益の能書きが追加された。
41:名前は開発中のものです。
11/02/09 21:51:05 +dlXNCDm
まだ根絶はされていないようだ。
URLﾘﾝｸ(twitter.com)
42:名前は開発中のものです。
11/02/09 22:15:38 xtMvpX8d
>>41
いっぱいいるね
43:名前は開発中のものです。
11/02/10 08:36:28 dY2cgLTQ
これはひどい
44:名前は開発中のものです。
11/02/10 09:29:39 rhn2H02Q
ツイッターは宮崎県の東国原元知事でもやってる
45:名前は開発中のものです。
11/02/10 11:13:00 6Rcuugl9
タスクシステム、っていう名前からして臭いわな。
便利なフリした機能の癒着やごった煮を連想させる。
46:名前は開発中のものです。
11/02/11 01:43:47 TZypN/D2
ツイッターやってる一般人ってキモイよな
47:名前は開発中のものです。
11/02/14 09:22:19 7vUEnASs
ツイッターやってる一般人がというか、たいした情報でもないのに情報発信源気取りでしゃべってるのがキモいんだと思う。
あまつさえ斜め上の内容だからなおさら。
48:名前は開発中のものです。
11/02/14 16:24:13 wzlRlBXo
タスクシステムとまったく関係のないやりとりをする こいつらがキモイ
49:名前は開発中のものです。
11/02/15 23:36:25 smoeNTMJ
>>48
そう？
50:名前は開発中のものです。
11/02/16 11:05:15 wRI9y0Na
もはや根絶の時期がメインの話題になるぐらいのものでしかない。
51:名前は開発中のものです。
11/02/17 01:57:08 xb/j0cZ1
てか、まだ使ってる人居るのかネェ。
だいたい、プログラム自体が処理を実行順に並べたもの「そのもの」なんだから、
自前で処理リスト持って、毎フレーム逐次実行する意味が分からないよな。
まるでバーチャルマシンじゃん。
void do_tasks(){ task1(); task2(); task3(); /*←タスクリスト*/ }
↑こんなん作っておいて、毎フレーム呼びだしゃ良いだけだもんなぁ。
52:名前は開発中のものです。
11/02/17 07:28:17 mmuGB28x
バカはつかわなくていいよ
53:名前は開発中のものです。
11/02/17 07:32:48 mmuGB28x
みんなでプログラムしようぜ とみんながやる気になる
みんなでいろいろな意見が出され、いろいろ議論される
とても活発、いろんなスレがたてられる
実際につかわれはじめ、みんな期待する
実用化されたものが発売、みんなキター状態
これを見たマスコミが これはすごいともてはやす
マスコミの情報を見て、やじうまがあらわれる
タスクシステムのすごさを報道
バカには理解できない そのうえ、数は多い
こんなもの何の役に立つんだ 根絶してしまえ ← いまここ
54:名前は開発中のものです。
11/02/17 09:42:43 wffMBw0x
>>3
55:名前は開発中のものです。
11/02/17 12:32:10 mmuGB28x
つまりバカほど・・・おっと もはやまともな奴は静かにしてるな
56:名前は開発中のものです。
11/02/18 00:05:05 Rx3rFAqD
釣りはもっと上手くやれよ
57:名前は開発中のものです。
11/03/02 11:06:20.50 VVBDgu3W
タスクシステムは
抽象的には
発生する大量のオブジェクトを
動的に一元管理・実行できるってのがすべてだと思うんだけど
逆にこれ以外の方法で大量のオブジェクトを扱える設計は
何が考えられますか？
コード中のあちらこちらでメモリ領域確保してたら
わけわからなくなりませんか
58:名前は開発中のものです。
11/03/02 11:46:07.55 IG+0eofe
>>57
全部「タスク」の名の下にごちゃまぜになってるほうがわけわからなくなりませんか？
「～のコンテナ」を必要なだけ必要なところに置けば十分で、さらにそのほうがコンテナの
スコープが狭まり、個別に名前付けが行われるぶんコードは読みやすいはずです。
コンテナが分かれていれば、特定のオブジェクト郡にだけ適用できる最適化を局所的に
行うこともできるようになります。（ここは挿入削除が頻繁だから list で、ここでは
要素数がずっといっしょだから vector で、などなど）
逆にコンテナがまとまっていた場合、そもそもそういった最適化が不可能になってしまうか、
できたとしても全体に影響が波及してしまうことになり、危険度が上がってしまうでしょう。
> コード中のあちらこちらでメモリ領域確保してたらわけわからなくなりませんか
逆に、なぜ「わけわからなく」なってしまうのかを追究してみたいところです。
59:名前は開発中のものです。
11/03/02 16:31:08.79 VVBDgu3W
>>58
過疎っぽいからレスつかないかと思った。ありがとう
>「～のコンテナ」を必要なだけ必要なところに置けば十分で
というのがまさしく、気になるところで、例えば
擬似コードですが
class enemy ｛
Tama tama[];//唯一の参照保持コンテナ
弾発射（）｛
//３つ発射しちゃうぞー
tama.add(new Tama());
tama.add(new Tama());
tama.add(new Tama());
｝
}
というような実装を単純にしてしまうと
enemyが弾が消える前に破壊されて
deleteされるような事態になったら
おかしなことになりかねませんよね
当然、こんな場当たり的な領域確保できないわけで、
弾のコンテナのスコープはどこがいいのか、
どう管理するんだ、というような話になると。
つづく
60:名前は開発中のものです。
11/03/02 16:34:46.21 VVBDgu3W
つづき
>コンテナが分かれていれば、
>特定のオブジェクト郡にだけ適用できる最適化を局所的に
>行うこともできるようになります。
というのが、結局のところ
URLﾘﾝｸ(d.hatena.ne.jp)
のタスクシステムの解説記事の中の
■その他の問題 で、
>タスクの数が異常に増えたりする際は複数のタスクリストやコンテナに分けた方が
>管理面でも速度面でも良くなったりします．
というふうにタスクシステムの範疇から出てないのかな、と。
長くなって申し訳ない。
61:名前は開発中のものです。
11/03/03 01:26:17.44 JE+9DEkn
>>59
> 当然、こんな場当たり的な領域確保できないわけで、
「当然」ではないでしょう。「弾が消える前にenemyが破壊される」という
仕様が出てきたから不都合が発生したという話にしか見えません。
それがたとえば「弾」ではなく enemy と共に破壊される「角」とかそういう
オブジェクトであれば何も問題はなかったのです。
> 弾のコンテナのスコープはどこがいいのか、
> どう管理するんだ、というような話になると。
そういう話になるでしょうけども、だからといって「タスク」も「システム」も
カスりもしません。
典型的には「弾のコンテナはもうひとつ外に持っとくか」という話になるだけ
ではないでしょうか？
62:名前は開発中のものです。
11/03/03 01:27:01.28 JE+9DEkn
>>60
>>タスクの数が異常に増えたりする際は複数のタスクリストやコンテナに分けた方が
>>管理面でも速度面でも良くなったりします．
>
> というふうにタスクシステムの範疇から出てないのかな、と。
「オブジェクトをコンテナに入れたら、それはもうタスクシステムだ」という
ことでしょうか？
それを完全に否定する材料は持ち合わせていませんが、それが言えたからと
いって何になるのか、何がうれしいのか、わかりません。
63:名前は開発中のものです。
11/03/03 04:50:40.85 o4mDyDkO
>>61
どうしてもレスが長くなってしまう。。
>「当然」ではないでしょう。「弾が消える前にenemyが破壊される」という
>仕様が出てきたから不都合が発生したという話にしか見えません。
いやいや、さすがにそれはちょっと…
シューティング以外でも魔法でも矢でもエフェクトでもダメージ表示でも。
> 典型的には「弾のコンテナはもうひとつ外に持っとくか」という話になるだけ ではないでしょうか？
それって、enemyのコンテナの隣に弾のコンテナってイメージでいいんですかね。
80種類の敵がいたら80個コンテナ作って自機との命中判定のために80個の
参照作って、なんてのは考えにくいから「敵コンテナ」に統合しますよね。
>「オブジェクトをコンテナに入れたら、それはもうタスクシステムだ」という
>ことでしょうか？
結局、
いわゆるタスクシステムとの違いが
「敵と弾を分離してるだけ」とか、
「シーンクラスとかキー入力処理クラスまで
同じコンテナのタスクとして扱うのは
気持ち悪いから、別処理にする」程度の話なら
タスクシステムのような方言の多い設計技法の実装としては
よく見かける気がするんですよね。
つづく
64:名前は開発中のものです。
11/03/03 04:51:19.58 o4mDyDkO
つづき
それを指して「これはタスクシステムではない！」ってのは
正直に言うと得るところがないです。
むしろ知りたいのは
その範疇には収まらない設計はあるのだろうか、
あったら知っておきたいなと思って、
>>57の
>逆にこれ以外の方法で大量のオブジェクトを扱える設計は
>何が考えられますか？
と聞いたわけです。
知らない以上、うまく言えないんですが
コンテナが不要なデザインパターンみたいなものとか
存在するのかなと思って。
うれしいとかうれしくないとか別にないです。
65:名前は開発中のものです。
11/03/03 06:16:04.21 JE+9DEkn
>>63-64
> いやいや、さすがにそれはちょっと…
何でしょう？書いてもらわないとわかりませんよ。
> 80種類の敵がいたら80個コンテナ作って自機との命中判定のために80個の
> 参照作って、なんてのは考えにくいから「敵コンテナ」に統合しますよね。
どちらにもメリット・デメリットがあるでしょうから、そうするかもしれませんし、しないかもしれません。
ただし、少なくとも僕が「タスクシステム」と聞いてイメージするようなグローバルなリストに統合することは
無いでしょう。
>>「オブジェクトをコンテナに入れたら、それはもうタスクシステムだ」という
>>ことでしょうか？
...
> タスクシステムのような方言の多い設計技法の実装としては
> よく見かける気がするんですよね。
つまり、答えは yes ということですかね？そういうことなら「タスクシステム」などという不明瞭な
言葉は使わず、はじめから「コンテナ」と言って欲しいところです。
> それを指して「これはタスクシステムではない！」ってのは
> 正直に言うと得るところがないです。
何かを指して「これはタスクシステムではない！」などとは言ってません。
ただ、仕様に沿ってコンテナを用意しただけのコードを指して「これもタスクシステムですね？」などと
言われれば「知らんがな。何なの？」となります。
> コンテナが不要なデザインパターンみたいなものとか
そんなものを探すことに意味があるとは思いません。
66:名前は開発中のものです。
11/03/03 07:33:16.78 o4mDyDkO
>>65
うーん、そういう結論かｗ
なんにせよ、つきあってもらってありがとね
67:名前は開発中のものです。
11/03/03 10:42:52.29 S1R4ZHdy
>>59-60を読んでレスしようとしたことを、
俺がしようとしたよりまとめた形で>>61-62にレスされてて驚いたｗ
68:名前は開発中のものです。
11/03/04 18:49:09.34 W65V8c4v
過去ログみてたら、良いこと書いてあったので貼っとく
タスクシステムは嫌いだけど、ここにタスクシステムのメリットが示されてると思うわ
タスクシステム総合スレ part5
URLﾘﾝｸ(2chnull.info)
874,880的な理由でタスクシステムを採用するのはありだと思う
ゲーム開発に最初から完成された仕様を求めるのは難しいからな
ただ、仕様が完成されている（面白さが実証されている）ゲームに対して
タスクシステムを採用しようという意見には賛成できないがね
69:名前は開発中のものです。
11/03/04 23:18:07.18 Hcaww+pW
>>68
その場合は「タスクシステムを採用する(ｷﾘｯ」などとは言わずに、
「わりと何でも入るごった煮リストを予備で用意しとくよ。
設計に悩んで対応が間に合わなくなりそうだったら、とりあえず
ここに入れて済ませても良いよ。
でもなるべくデバッグ始まるまでには片付けるように考えてね。」と
正直に言って欲しい。さらに言えばそのごった煮リストにアクセスする
インターフェースのコメントに書いておいて欲しい。
70:名前は開発中のものです。
11/03/05 12:11:49.38 3H1ntObt
内容自体は別にいいとも悪いとも思わないんだけど
所詮設計手法であるにもかかわらず
タスクやらシステムやらたいそうな名前付けてるのに問題があるよな
71:名前は開発中のものです。
11/03/12 03:57:26.31 /4EBtN3h
そもそも、さっき出てきた、敵やら弾やらは、ゲームオブジェクトであって、タスクではないだろ。
なのにタスクシステムとかいうから・・・もうそっからしていかれてる。
72:名前は開発中のものです。
11/03/18 19:52:37.70 j/XYUi0c
ノンプリエンプティブなタスクです。
73:名前は開発中のものです。
11/03/19 22:04:55.48 waQ7BrWH
SPUのようにメモリが共有できないプロセッサで有効な手法ってありますか？？
74:名前は開発中のものです。
11/03/19 23:11:19.21 4X1JhQIF
>>73
問題も挙げずに手法もクソもあるか。
何が問題なの？それはこのスレに関係あるの？
75:名前は開発中のものです。
11/03/20 00:21:21.49 0de+XUQH
お前が頭悪い
メモリが共有されてないのが問題だろ
タスクシステムは並列化でも関係あるし
76:名前は開発中のものです。
11/03/22 00:26:05.99 XIrlBxPX
>>73
無い
77:名前は開発中のものです。
11/03/22 08:02:01.84 sfNYTUX7
>>75
共有されてないメモリを何らかの「手法」で共有しちゃおうって話だったの？
そりゃ無理だｗ
78:名前は開発中のものです。
11/03/22 23:26:57.49 IORdeWKB
あほか
79:名前は開発中のものです。
11/05/06 23:29:54.19 tdzmLgDZ
まーC++で一番簡単なのは、
template< typename _t > &obj_list(){ static std::list< _t * > inst; return inst; }
とかやって、テンプレートにシングルトンの型リスト作ってもらって、
obj.itr = obj_list< obj_t >().push_back( &obj );
って感じで型リストに登録して、
for( std::list< obj_t *>::iterator itr=obj_list< obj_t >().begin(); itr!=obj_list< obj_t >().end(); ++itr )
{ /*処理*/ }
って感じで型ごとにforeach回してやりたい処理して、
obj_list< obj_t >().erase( obj.itr );
って感じで登録削除する、やり方かなぁ。
処理の優先順位って、実際には型にくっついてる場合が多いし、型ごとのリストで十分なことが多い。
for文が煩雑に思えるのなら、マクロ使えばいいし、
attachやdetachも、テンプレート関数使えば、型推論が効くし、
コールバックにならないから、引数固定になることもないし、
型ごとにリスト持つからダウンキャストも発生しないし、
制御フローは書いた順そのものだから、可読性も高い。
手っ取り早くゲームを作りたいホビープログラマには打って付けだと思う。
80:名前は開発中のものです。
11/05/06 23:57:22.49 4boNOk2w
>>79
タスクシステム関係なくね？スレ違いじゃね？過疎ってるからいいけど。
あとシングルトンは死ね。
81:名前は開発中のものです。
11/05/07 02:25:37.71 FaGHlUhW
燃料投下age
URLﾘﾝｸ(dixq.net)
82:名前は開発中のものです。
11/05/07 13:19:43.23 HQP20IoI
アマチュア発のオカルト怪文書だね
83:名前は開発中のものです。
11/05/07 16:42:34.61 YeA8xK1G
>>79
並列処理はどうやって対応する？
84:名前は開発中のものです。
11/05/07 18:59:52.07 9I/zjC76
>>83
foreachの並列化なんて超簡単じゃん。
85:名前は開発中のものです。
11/05/16 16:22:40.47 6KFTtmqy
みんな、オンラインゲームを支える技術つまて本読んだ？
タスクシステムが紹介されてるな。
実際のオンラインゲームでも使われてるんだな。
86:名前は開発中のものです。
11/05/17 08:45:55.89 rFUq1Hs1
具体的に何が？ｗ
87:名前は開発中のものです。
11/05/18 18:02:54.11 xlWxC1Wx
とりあえず買ってきたけど何頁だよ
88: [―{}@{}@{}-] 名前は開発中のものです。
11/06/09 07:44:43.82 F833/hsX
タスクシステムってlistにオブジェクト突っ込んでイテレータでぐるぐる回しながら処理を実行させるだけのことだろ
89:名前は開発中のものです。
11/06/09 08:44:11.64 /RZWOxKd
だから ｽﾚﾘﾝｸ(prog板) でやれ
90:名前は開発中のものです。
11/09/03 21:11:50.72 rKhpPrRf
タスクシステムか・・・なつかしいな
ゲームオブジェをどんな構造でまわすか、って悩むのはゲームプログラマなら
みんな通ったことのある壁の一つだよね。
最近は情報があふれてるからこの辺までは定石のお勉強で到達できるけど
ここから先が自分で考えられる人か教わらないとできない人か、の登竜門な感じ。
ゲームプログラマ向きじゃないのはここで詰まったまま脱落するんだよね。
まぁここを超えてももっと高い壁がまだまだ続くんだけどね・・・
91:名前は開発中のものです。
11/09/04 19:01:47.88 F8LegbLJ
で「タスクシステム」を極めることが目的じゃない、と気付き、
使い回しの効く便利ルーチンをいくつか作るに止めるか、
なぜか目的を忘れてハマるか、という分岐があるんだけどね。
92:名前は開発中のものです。
11/09/05 04:56:06.83 qHGk9if0
ゲームの仕様、開発言語、対象マシンのリソースと制限、納期とメンバーのスキル、etc...
タスクシステムの扱う範囲はゲームのコアアーキテクチャに関係してくる
最適解がコンテキスト依存な問題の典型。
これらコンテキストは作ろうとしているゲームによって千差万別だからネットで一般解を聞いても
ケースバイケースという一般論しか返ってこない。
さらに「タスクシステム」ってゲーム業界で慣習的に呼ばれてるだけで
実装はゲームによって全然別物。
ってことで結局サンプルソースとかで実装されてるタスクシステムと言われる
ものを参考にでもして作る予定のゲームにあわせて自分で考えて実装しろや、となる。
93:名前は開発中のものです。
11/09/05 23:02:25.18 7BkdaPO7
そんで、あれ、もしかして、これ要らなくね？となる。
型ごとにリスト用意して、任意にforeach回すだけ。
94:名前は開発中のものです。
11/09/06 01:05:01.29 4mf44gCT
>>93
レベル（ステージ）毎に必要な型のforeachを実行する関数を用意するわけか。
レベルデザイン時の柔軟性が失われないか？
もしくは全ステージで同じ型出すと、ステージ色が失われないか？
95:名前は開発中のものです。
11/09/06 06:56:47.84 +MWn67Ig
コールバックさせるupdate関数の引数が固定になる方が柔軟性が損なわれる。
96:名前は開発中のものです。
11/09/06 09:34:01.98 vhjBYDIv
そうだよな
必要な情報ってオブジェクトごと違うのにそこをわざわざ統一しちゃうのは
逆に必要な情報が関数みてわからなくなっちゃう
ホーミングミサイルで更新にターゲットが必要ならそれが必要な情報とわかるように
むしろ引数で明示するべき
その情報がなければこの関数は実行できないよと
これがプログラムの基本なんだよ
97:名前は開発中のものです。
11/09/06 19:39:44.89 8sfW2Qro
書泉でゲームプログラムフェアってのやってたから「何とかでつくるシューティング」とか
何冊か立ち読みしたら6冊中4冊でタスクシステムの説明とそれ使ったゲームがのってた。
PHPのやつとAVGの二冊はタスクシステムじゃなかった。
>>92
の言うようにC++とかJavaとかObject-Cとかで実装は別々だったけど、作るゲームにあってるなら
タスクシステム使って。
ポインタや参照使えない言語使う、とかタスクシステムが合わないゲーム作るならほかの方法で実装すれば
いいんじゃないかな。
98:名前は開発中のものです。
11/09/06 19:57:34.88 4mf44gCT
>>95
書籍で紹介されているタスクシステムでは、個体情報を含むメモリブロックへの参照をメンバに含む
構造体ポインタを引数経由で渡して、個体情報特有の構造体にキャストしている。
むしろ何でもありで、情報のやり取りの柔軟性が損なわれることはない。
>>96
呼ぶ側は呼ぶことしか行わない方が、分かりやすい。
また例で言うとターゲットが存在しない場合の条件分岐を、呼ぶ側にしわ寄せ実装する必要が出てくる。
生存および消滅の過程や、何をターゲットにするかは、対象リストへの広域なインターフェースを用意して、
個体タスク内で自律的に行わせる。
基本と言い切るのは勇み足じゃないか？
99:名前は開発中のものです。
11/09/06 22:03:20.33 vhjBYDIv
>>98
バッカ
全然関係ない
ちゃんと引数で渡すようにすれば何が何をやるべきかちゃんと見えてくる
なんにも見えないのは年がら年中そうやってオブジェクト同士の関連を面倒だからって
端折ってるからなにも分析できないなにも進歩しない
100:名前は開発中のものです。
11/09/06 22:58:45.25 8sfW2Qro
書籍にソースコードを全て載せるぐらい小さいゲームや、iphoneとかandroidのミニゲームみたいに
ゲームの状態推移がほとんどなくてゲームオブジェも簡単に全て把握できる、みたいなシンプルなゲームなら
タスクシステムのような単純な仕組みで実装する、って判断も十分合理的かと。
どんなアルゴリズムにしろアーキテクチャにしろ、適した用途と適さない用途はあるわけで。
>>99 がどんなハードでどんな仕様のゲームを想定してるのかは本人しかわからないけど
想定しているゲームの仕様には適さないと思うならタスクシステムじゃなくもっとそのゲームに適した仕組みで
実装するのが現実的だと思うけど。
101:名前は開発中のものです。
11/09/06 23:14:39.10 +MWn67Ig
型ごとにリストを用意して、
必要に応じてforeach回す方法の方がタスクシステムよりシンプルだよ？
引数も関数名も自由に決めれるし、
書いた順に実行されるから、
タスクシステムにありがちな、実行順のソートとかワケワカラン処理も要らないし。
タスクシステムってタスクを順番に逐次実行するんでしょ？
でもプログラムって放っておいても逐次実行だよ？
void do_tasks(){ task1(); task2(); }
って書いとけば、それそのものがタスクのリストだよ？
わざわざ動的にタスクのリストを用意して逐次実行する意味ってあるの？
それじゃまるでインタプリタやVMだよ。それも碌な制御構造もない貧弱で直線番長な。
102:名前は開発中のものです。
11/09/06 23:20:56.58 +MWn67Ig
折角C言語やC++にはif文やらなんやらの立派な制御構造があるのに、
タスクシステムだと、タスクを前から順番に実行することしか出来ないから、
言語の持つ折角のメリットを殺しちゃうことになるんだよ？
update関数の引数が固定になっちゃって、これも言語の機能を殺すことになるよ？
動的にタスクのリストを用意するから、
ソースコードを読んだだけではタスクの実行順が分からないってのもマイナスだね。
わざわざそんな茨の道を行く必要は無いんじゃないの？
103:名前は開発中のものです。
11/09/06 23:55:38.12 8sfW2Qro
＞タスクシステムにありがちな、実行順のソートとかワケワカラン処理も要らないし。
上であげてるゲームでは実行順のソートとかワケワカラン処理は必要ないケースだし
＞update関数の引数が固定になっちゃって、これも言語の機能を殺すことになるよ？
単純なゲームだから引数にコンテキスト渡すだけで解決。
＞ソースコードを読んだだけではタスクの実行順が分からないってのもマイナスだね。
ソース2～3個で完結してるようなゲームだし、普通のプログラマなら十分把握できるでしょ・・・
あと、タスクだと敵出現のシーケンスは、データ読んでその種類のタスク生成してくっつけるタスクの原理を
うまく使ったシンプル実装。
これを逐次駆動でタスクよりシンプルに実装できるのかな？
タスクの方法より短くシンプルなコードでSTGの弾、エフェクト、敵AI切り替え、ボス、敵のシーケンス化、等々を
実装できるのならその方法でもいいかもしれないけど・・・
書籍のサンプルでは上記全てタスク実装で1個のソースにして綺麗にまとまってたから、逐次ベタ書きで
これよりシンプルに短くこの仕様全て実装するのは難しいと思うけど。
STGのサンプルの大多数タスクシステムを採用してるのはそれなりに合理的な理由があると思うよ。
104:名前は開発中のものです。
11/09/07 00:11:57.19 2Lv+in6p
実行順のソートが必要ないなら、なおさら動的にタスクリストを持つ必要ないじゃん。
ソースコードにベタでtask1(); task2(); task3()って書いてけよ。
なんども言うけど、ベタで書いたほうが、タスクシステムよりよっぽどシンプルなんだ。
型ごとにリスト用意して、必要に応じてupdateってのは、
名前すら付いていないほど、普通に考えりゃそうなるだろうってやり方。
だから、単純さを武器にタスクシステムを薦めるのは可笑しい。
タスクシステムは、最終ビルド後、製品出荷後で、
後からプログラムを拡張したいときなんかに使われるような、それなりに高度なやり方。
プラグインやMODやドライバなんかで使われる手法。
その必要も無いのに使うものではないんよ。乱用なんよ。コールバックの乱用。
105:名前は開発中のものです。
11/09/07 00:20:37.44 2Lv+in6p
list<弾*>弾リスト; list<エフェクト*>エフェクトリスト; list<敵*>敵リスト、list<ボス*>ボスリスト;
foreach( 弾リスト ) { update( 弾 ); }
foreach( エフェクトリスト ) { update( エフェクト ); }
foreach( 敵リスト ) { 敵->AI(); }
foreach( ボスリスト ) { ボス->シーケンス(); }
な？簡単だろ？
型情報も殺さないし、引数も自由だ。
106:名前は開発中のものです。
11/09/07 00:27:04.18 2Lv+in6p
複数処理を型に跨って順不同に呼ぶことだって出来るぜ？
foreach( 敵リスト ) { 前処理( 敵 ); }
foreach( 弾リスト ) { 前処理( 弾 ); }
foreach( 敵リスト ) { 敵->AI(); }
foreach( 弾リスト ) { update( 弾 ); }
foreach( 敵リスト ) { 後処理( 敵 ); }
タスクシステムだと言語本来が持つ制御構造を殺しちゃってるから、
こう言うことが難しい。
107:名前は開発中のものです。
11/09/07 00:31:43.66 2Lv+in6p
敵->AI();とか書いちゃったけど、実際には
敵->AI( 敵 ); だな。ごめんごめん。
ついでに。
foreachを多重ループにすれば、相互作用の記述も簡単。
タスクシステムですると破綻しかねん処理だ。
foreach( 敵リスト ) //二重ループ
foreach( 弾リスト )
{
当たり判定とか相互作用的なもの( 弾, 敵 )
}
108:名前は開発中のものです。
11/09/07 00:59:04.96 2Oz0OCTe
逐次実行の書き方って...本気でこのコードでゲームを最後まで書くっていってるの...？
まぁこー書かないとコード追えないって言ってるから、しょうがないのかもしれないけど...
タスクシステムで実装されたSTGゲームは書籍なりネットなりでいろいろコードみれるけど
この方式で最後まで完成したちゃんとしたSTGのコードって今まで一つも見たことないな。
論より証拠で、どんなものになるかぜひ完成したものを見せてほしいな。
109:名前は開発中のものです。
11/09/07 01:02:00.30 2Lv+in6p
一応書いておくと、話題に挙がった、タスク = ゲームオブジェクト なタスクシステムのほかに、
タスク = 純粋な処理 なタスクシステムもある。
一見良さそうだけど、種類の違うタスクを同じコンテナに混ぜ込んじゃうから本質的には何も変わらない。
コンテキストが必要なタスクの場合、
タスクのコンテキスト構造体を作って型ごとにリストで管理。
foreach( タスク1のリスト ){ タスク1の処理( タスク1 ); }
foreach( タスク2のリスト ){ タスク2の処理( タスク2 ); }
コンテキスト不要なタスクの場合、タスク=関数。
foreach( 敵リスト ){ タスク1( 敵 ); }
foreach( 敵リスト ){ タスク2( 敵 ); }
こうした方が良い。
110:名前は開発中のものです。
11/09/07 01:06:48.32 njRzaK7Q
>>108
なんでゲームやSTGに限ろうとするの？
ほとんどのアプリが、型ごとにリスト持ってて、必要に応じて更新ってスタイルだよ？
111:名前は開発中のものです。
11/09/07 01:14:01.19 8h9D8UMl
>>109
前スレより随分と解りやすくなった
112:名前は開発中のものです。
11/09/07 01:17:49.74 AZsoDlPL
4mf44gCTだけど、みんなのエネルギーもらってるみたいで楽しいよ。
>>99
繊細なんだな。俺は煽るつもりはなかったんだ。
>>101
＞必要に応じてforeach回す方法の方がタスクシステムよりシンプルだよ？
いずれにせよ個体の種類と量が増えると、人間の頭ではワケワカメになると思うんだが。
解決策としては、むしろ以下の方針で、ソースの透明性確保の努力をするべきじゃないか？
１）呼ぶ側の構造をできるだけシンプルにする。
２）個体の状態の両端末、すわなち生存・消滅に関わるメカニズムを統一して単純化にする。
３）個体同士の相互作用のメカニズムを統一して単純化する。
上の方針を守っている限り、柔軟性のあるいわゆる「タスクシステム」の方が有利だと思うんだが。
113:名前は開発中のものです。
11/09/07 01:18:43.81 AZsoDlPL
>>106
＞タスクシステムだと、タスクを前から順番に実行することしか出来ないから、
＞言語の持つ折角のメリットを殺しちゃうことになるんだよ？
＞update関数の引数が固定になっちゃって、これも言語の機能を殺すことになるよ？
言語の「メリット」「機能」というのが曖昧だな。
本質ではないかもしれんが、>>106をみると敵クラスについて、前処理、AI、後処理と分けていて、非常に複雑な印象を受ける。
このように分ける必然性がわからない。
むしろハードコーディングにより、このように分けてしまうと柔軟なレベルデザインの妨げになるような予感がする。
あと誤解しているが、書籍などで紹介されている「タスクシステム」は、タスク登録時に優先順位（Priority）により各個体の実行順序を制御できる。
だから実質的に、同種の個体で実行順序をグループ化することも可能だ。つまりこれまでID:+MWn67Ig / 2Lv+in6pが提起している「制御構造」の問題は解決されている。
114:名前は開発中のものです。
11/09/07 01:31:29.34 2Oz0OCTe
>>110
なぜタスクシステムを使うべきでないケースでタスクを使うことを考えるんだろう...
>>100 の前提のとおり、タスクシステムにしろどんな仕組みにしろそれを使うケースは
それが合理的なケースだけ、というのは当然でしょう。
なにか否定している理由は合理的な考えから出たものとは違うみたいなので
これ以上続けても意味のある結論は出なさそうですね...
115:名前は開発中のものです。
11/09/07 01:35:34.18 njRzaK7Q
これはもう石頭でどうしようもない。物事を勘違いしたまま突き進んじゃってる。
>いずれにせよ個体の種類と量が増えると、人間の頭ではワケワカメになると思うんだが。
ワケワカにならないように、違った型のオブジェクトを同じリストに突っ込まないようにするわけで。
ワケワカでOKってことはないでしょ？
>敵クラスについて、前処理、AI、後処理と分けていて、非常に複雑な印象を受ける。
>このように分ける必然性がわからない。
敵クラスの前処理とAI処理の間に、他クラスの別処理が入ってるのが味噌。
一回ずつオブジェクトをupdateでなめなめして、それで全ての処理が終わるとは限らないだろ？
>タスク登録時に優先順位（Priority）
それは、違った型のオブジェクトを同一のリストに入れるから必要になる仕組みであって、
苦肉の策であることを分かって言ってるのか？
そしてそんな貧弱な制御構造で、言語本来の制御構造と対等に立てるとでも？
116:名前は開発中のものです。
11/09/07 01:46:07.51 njRzaK7Q
>１）呼ぶ側の構造をできるだけシンプルにする。
物事は上流で解決した方が良い。
>２）個体の状態の両端末、すわなち生存・消滅に関わるメカニズムを統一して単純化にする。
言ってる意味が良く分からんが、あえてエスパーすると、メモリアロケートの話ならアロケーターの仕事。
>３）個体同士の相互作用のメカニズムを統一して単純化する。
上流(メインループ部)を直接改造できる状況下においては、
相互作用は上流でするべき。
>>114
逆にタスクシステムを使うべきケースって何？
ああいったコールバックシステムは、
上流部が固定されている場合だけだと思うんだけど。
ゲームはメインループ部を自由に触れるよね？
リリース前なんだから。
117:名前は開発中のものです。
11/09/07 01:46:51.37 AZsoDlPL
>>115
おい、煽るなよｗ
＞ワケワカ
>>116のような記述がズラーーーーーーと並んだら、ワケワカメになるとは思わないか？
俺はそうなる事態を予見して、解決策を提案したんだが。
＞敵クラスの前処理とAI処理の間に、他クラスの別処理が入ってるのが味噌。
率直に言うと、複雑な相互作用メカニズムになっているという気がするな。
＞そしてそんな貧弱な制御構造で、言語本来の制御構造と対等に立てるとでも？
例で示されている要件は、タスクシステムでもクリアされているんじゃないか。
もっと「言語本来の制御構造」のメリットが出ている例を挙げてもらいたいな。
所詮は場末の小競り合いだ。
落ち着いて逝こうぜ。
118:名前は開発中のものです。
11/09/07 02:02:46.60 njRzaK7Q
>>117
>>116のような記述がズラーーーーーーと並んだら、ワケワカメになるとは思わないか？
そこにズラーーーと書いてあることが、格ゲームオブジェクトのupdate関数に移るだけだから同じこと。
むしろ、分散されて余計わけが分からなくなる。
>率直に言うと、複雑な相互作用メカニズムになっているという気がするな。
あえて例で上げたまでだからね。
だけど、一回のupdateで全ての更新が終了するとは限らないだろ？
>例で示されている要件は、タスクシステムでもクリアされているんじゃないか。
二回のupdateが必要な場合はどうするの？
a->update1(); → 何かの処理 → a->update2();
C言語本来の制御構造なら、やりたいことをやりたい順で書けば済む。
タスクシステムだと、タスクシステムの仕様に制限される。
119:名前は開発中のものです。
11/09/07 02:10:21.64 AZsoDlPL
>>116
＞物事は上流で解決した方が良い。
上流のフローは、単純でなければいけない。
その解決策は、先に書いた通り。
＞>２）個体の状態の両端末、すわなち生存・消滅に関わるメカニズムを統一して単純化にする。
＞言ってる意味が良く分からん
生存＝個体がタスクリストに登録されている状態
消滅＝個体がタスクリストに登録されていない状態
＞相互作用は上流でするべき。
詳しく。
レベルデザインの足かせとならないか？
＞逆にタスクシステムを使うべきケースって何？
確実に言えるのは、メモリリソースが希少な場合だろう。
＞ゲームはメインループ部を自由に触れるよね？
そんなに簡単にいじれるかな？
どんな触り方を言ってるのん？
120:名前は開発中のものです。
11/09/07 02:21:42.40 AZsoDlPL
>>118
＞一回のupdateで全ての更新が終了するとは限らないだろ？
これ具体例教えてもらえないか？
ところで（書籍ででている）タスクシステムでも、（この議論の流れでは反則になるかも知れんが）
ちょっといじれば各個体にupdateを2つ持たせることは可能だぜ。
優先順位を2つ持たせることも可能だ。
メインループで登録リストを2回なめることになるが。
121:名前は開発中のものです。
11/09/07 05:53:24.18 P+KLPKHG
ひさしぶりにタスクシステムな人が来たみたいだな。
まずは >>2-4 あたりを読んで、それでもまだ何か言いたいんなら、まぁがんばって。
122:名前は開発中のものです。
11/09/07 08:11:32.13 BWfYxSne
>>105
俺はお前を支持する
こっちのほうが１０００倍楽
タスクシステムの起こすバグはハンパじゃない
123:名前は開発中のものです。
11/09/07 08:21:53.19 BWfYxSne
>>105に書いてある内容は本来書き並べないといけない処理なんだよ
必要に応じてわかりやすい単位で関数に分けることは必須だけど
これをタスクシステムにしたら実行しないとこの順番がわからないとか
開発がホント酷いことになる
派遣で色々と会社まわったけど
タスクシステムを使わないところはバグの数が１０分の１ぐらいだかんね
タスクシステム使ってるようなところはバグ数がプロジェクトで３万（万？はぁ？）とか
明らかに数字がおかしい
124:名前は開発中のものです。
11/09/07 12:09:48.38 Cw/CE0Hp
もともとはアセンブラ時代のテクニックだろうよ
CPUやメモリ資源もない時代。
１．ゲームオブジェクトを統一的に扱う。
２．アラインメントを考慮したメモリにやさしい固定長のオブジェクト
３．固定長のオブジェクトを柔軟に扱うためのプロセスアドレスの保持
今の時代は
１は継承で可能。２は資源的にちっとやそっとの無駄は気にしない。
３は今で言うところのメンバ関数とか関数ポインタ。
125:名前は開発中のものです。
11/09/07 12:39:30.24 njRzaK7Q
今の時代なら、
>１．ゲームオブジェクトを統一的に扱う。
はテンプレートでしょ。
126:名前は開発中のものです。
11/09/07 17:13:02.56 V+dkRM26
ジョブコンの説明を確認すればわかるが、非常に単純化されたコルーチンのようなものの
メカニズム、というのが元の姿。
127:名前は開発中のものです。
11/09/07 20:57:18.96 njRzaK7Q
違った種類のジョブを単一リストで管理する理由はないね。
上流の呼び出し部分が出来合いのもので、
改変が許されないのなら別だが。
128:名前は開発中のものです。
11/09/08 01:34:35.91 lvpyEMH1
タスクシステム大佐：
「私のフレームワークはデリケートにチューニングされている」
129:名前は開発中のものです。
11/09/08 01:44:22.92 IMtv8g35
違った種類のモンを一端混ぜておいて、
場合によっちゃあ後から分別するんだから間違ってる。
別に扱いたいのなら、別に持っておけば十分だし簡潔。
130:名前は開発中のものです。
11/09/10 09:54:25.43 10z5xUck
>>92 で言ってることが全てなんだろうな
メンバーのスキルが「型固定で全てのフローをコードに直書きしないとソースが読めない」
みたいなレベルの場合はタスクシステムとか関数ポインタ使うとバグだらけで完成しないだろうし。
その場合はタスクシステムは使わないのが正解だろう。
Unreal Engine等の近頃のメジャーなゲームフレームワークの場合はタスクやアクターを使っていて
「敵やアイテムを型固定にしてコードに直書き」なんて作りはありえないけど
プロじゃなくて同人とかなら無理してスキルに合わない方法を背伸びして使わずに
自分のスキルで使える範囲の言語のフロー構造だけで作る、という結論は間違っていない。
131:名前は開発中のものです。
11/09/10 23:52:59.57 h48cNNb3
タスクシステム = 上級者用 ？？？
これはこれは。
132:名前は開発中のものです。
11/09/11 00:03:27.99 Y7Irx4Sl
タスクシステムが上級者用なんて、まさかwww
タスクシステムなんてゲームプログラマなら使えて当然の基礎中の基礎。
ただそんな単純な仕組みでも、つかうと手に負えなくなってバグが直せない、
みたいな超初心者なら、もっと単純な方法で作るのが正解だ。
hello worldの次のステップのプログラマならifとswitchだけ、ぐらいで
つくるのが適切。
133:名前は開発中のものです。
11/09/11 00:07:30.68 AdyJz/xc
俺はタスクシステムに逃げちゃう設計者は根性がないと思うけどね
この構造がダメなのはみんなうすうすわかってんだよ
134:名前は開発中のものです。
11/09/11 00:41:24.97 P9u9NThf
>>132
> タスクシステムなんてゲームプログラマなら使えて当然の基礎中の基礎。
ということにしたいのですね。 >>3
135:名前は開発中のものです。
11/09/11 00:47:43.20 Y7Irx4Sl
>>97 のようにタスクシステムを使って最後まで完成されたゲームは
沢山あるから書籍にしろネットにしろタスクシステムのサンプルには困らん。
完成してゲームという最終成果が出ている以上、そのゲームで必要な機能は
満たしているわけだし。
根拠が「根性」で出せるサンプルが foreach～だけ、みたいなのよりかは
採用するにしろしないにしろ、タスクシステムの例の方が参考価値がある。
ゲームを完成させたこともない人の言う「みんながうすうす」って言葉には
正直言ってこれを覆すだけの説得力が無い
136:名前は開発中のものです。
11/09/11 00:53:21.53 P9u9NThf
>>135
「タスクシステム」と言って具体的に何のことを指してるのかよくわからないから、
ネットのほうの「タスクシステムのサンプル」をいくつか URL で示してもらえませんか？
137:名前は開発中のものです。
11/09/11 00:57:39.18 Y7Irx4Sl
>>136
>>92 を見ればその答えがわかると思うね。
その上で疑問に思うことがまだあるなら個別にコンテキストを明示
して聞かないと無意味。
138:名前は開発中のものです。
11/09/11 01:03:39.39 P9u9NThf
>>137
つまり「タスクシステム」と言って指しているものは具体的にはわからんし状況によって変わりうる、
ということでしょうか。そんなもの役に立ちませんし「基礎中の基礎」だなんて具体的な技術である
かのように言えるわけないですね。なんかおかしいですね。
139:名前は開発中のものです。
11/09/11 01:14:44.40 Y7Irx4Sl
現実的に多くのゲームで「タスクシステム」と命名されてる構造が使われてるわけだ。
それを「共通じゃないから無意味」と結論するのは勝手だけどその行為もまったく無意味。
参考になるかどうか、現状のコンテキストから判断して適切に参考にして
作るゲームに役立てることの方がはるかに有意義。
140:名前は開発中のものです。
11/09/11 01:40:32.06 +CByEq1T
>>138
書籍などで紹介されているもは、タスクシステムの一般化された形態であり、
あとはアーキテクトが、場合に応じて、一般化形態から出発して特殊化するんじゃないかな。
一つのキャラを完成させるために上流も下流もいじる必要があるとなったら、
それこそ到達点が低くなる。
力を注ぐ必要のある要素は、キャラの基本的な出現消失の管理以外に一杯ある。
出来るだけ、いじらなきゃいかんソースの場所減らそうって目的で、
メインループ内を抽象化したのがタスクシステムじゃないか。
一方、上流のタスクシステムのアーキテクチャを改修すれば、当然、下流側への影響は絶大なわけで、
>>133は、ヘッポコアーキテクトが、途中で無責任改修やっちゃった事例なんじゃないか？
そんな奴はフレームワークに何使っても、むしろ何をやってもｗ上手くいかないんじゃないかと想像が膨らむ。
141:名前は開発中のものです。
11/09/11 01:42:27.37 P9u9NThf
>>139
そういって自作コンテナや自作アロケータや無茶なキャストを下手に参考にされる人が
後を絶たなくて困るんですが、あなたのいう「タスクシステム」がそういうクソの山とは違うと
いうのなら >>136
142:141
11/09/11 01:44:12.94 P9u9NThf
「後を絶たなくて」は言いすぎですね。今ではだいぶ稀になってますね。
143:名前は開発中のものです。
11/09/11 01:48:03.10 Y7Irx4Sl
>>141
＞そういって自作コンテナや自作アロケータや無茶なキャストを下手に参考にされる人が
書籍や何かでいくらでも簡単に手に入るサンプルをみても全てクソだと思うなら
君がゲームの仕様に適したもっと適切な構造で実装すればいいだけだ。
「僕にはアーキテクトを決める権限は無いけどタスクシステムと命名されたクソしすてむ
で作らされたおかげでバグだらけ（涙）」って愚痴ならご愁傷様としか言えんが。
144:名前は開発中のものです。
11/09/11 01:53:19.19 b4z41GvT
タスクシステムを一般的に語るなら、要はCなどの構造化言語がgotoを封じたもんだから、それに代わる状態遷移方法が必要なわけ。
そこでメインループというものを一般化し、キー入力イベント、敵の動き、当たり判定などの処理のセットを入れ替えることで状態遷移を可能とした。
でもgotoと同じく各状態への遷移が自由なためにスパゲッティになりやすい。
145:名前は開発中のものです。
11/09/11 04:26:51.67 ZZ/mHUa2
タスクシステマーのレベルが下がってきてるな。
そもそも、
update(){ task1(); task2(); }と処理を静的に書き並べていくことと、
実行時にタスクのリストを動的に生成して、逐次実行することに、
構造的な差はあまり無い。
ただ、後者は言語の持ってる型や制御構造といった機能を殺す。
アセンブラ時代に考えられたものだから、高級言語との相性は考えられてない。
146:名前は開発中のものです。
11/09/11 13:02:01.02 YqmjwGNN
>>144 ご大層なもん作らんでも、ごく普通のステートマシンの実装法でいいだろ
147:名前は開発中のものです。
11/09/11 13:28:29.62 b4z41GvT
>>146
ごく普通のステートマシンってなんだよ。
ifやswitchをメインに構成された状態遷移ならともかく、
関数やクラスのポインタを扱うstateパターンとか、ごく普通のステートマシンのことを
タスクシステムと呼んでタスカーたちは崇め、奉ってるんだと思ったんだけど違うの？
148:名前は開発中のものです。
11/09/11 13:32:34.15 ZZ/mHUa2
全然違うね。
ステートマシンであることと、ごった煮リストであることは、なんら関係が無い。
149:名前は開発中のものです。
11/09/11 15:36:06.08 Y7Irx4Sl
>>144-148
つ >>135
タスクシステムでそのゲームに必要な仕様を全て満たして完成されたゲームが
現実に多数存在する以上、せめてタスクシステムで作られたのと同じゲームを
別の実装で全て移植してみてそのコードの優劣を比較、ぐらいやらないと
根拠がお花畑すぎてちょっとなぁ・・・
童貞がリア充に女の口説き方を説教してるみたいで見ていて痛々しすぎる。
童貞のリアリティの無い妄想レベルのupdate()～みたいな程度の低いサンプル出されても
経験のある人間からしたら「ああ、この人一度もゲーム最後まで完成させた経験が無いんだなぁ」
ってバレちゃうだけ。
150:名前は開発中のものです。
11/09/11 16:27:01.31 YqmjwGNN
PHP信者が必死で主張する「PHPをdisるべきではない理由」にそっくりだなw
151:名前は開発中のものです。
11/09/11 20:10:56.36 b4z41GvT
ごった煮システムを別の視点から見ればそれはステートマシンそのものであり、
一つのシーンを形作るタスクのセットを入れ替えることで状態を表現する。
152:名前は開発中のものです。
11/09/11 20:21:21.31 ZZ/mHUa2
副作用を許すような、普通のプログラム、普通のプロセス、普通のゲーム、は、
それ自体がステートマシンそのものだろ。ごった煮リストであるかどうかは関係ない。
ごった煮リストってのは、型関係なく、単一リストに何でもかんでも入れてる状態。
たとえ型や種類ごとに綺麗に整理整頓して分けてリストに入れていたとしても、
ステートマシンはステートマシンだわな。
153:名前は開発中のものです。
11/09/11 20:33:46.30 ZZ/mHUa2
>>149
タスクシステムは全てのタスクを単一リストで管理するけど、
それを複数リストに分けろと言っているだけなんだから、
これが可能であることは、プログラマなら誰でも分かるわな。
タスクシステムで書かれてないゲームも多いぞ。
とくに海外製のゲームなんかはベタで書かれていることが多い。
気になるんだったら、探してみたら？
というか、何かリストで管理しようとしたとき、
型ごとにコレクトしていくのって、割と普通じゃないか？
型によっては木構造とかで管理したいかもしれないし。
画一的に全てを同じタスクリストで管理ってのはどうかと。
154:名前は開発中のものです。
11/09/11 20:57:08.72 b4z41GvT
タスクシステムはゲームに特化した状態管理の枠組みや方針、レイヤー、仮想環境ともいえるものを提供する。
155:名前は開発中のものです。
11/09/11 21:35:33.06 Y7Irx4Sl
>>153
＞タスクシステムで書かれてないゲームも多いぞ。
わざわざ海外のゲームなんて探さなくても大昔のベーマガ時代から
ベタで書きなんて珍しくもないよ・・・
数当てゲームとかね。
しかし、>>92 >>97 あたりに書いてあることをほんとに何一つ理解できてないんだねぇ
コンテキスト依存で実装考えるって当然のことを理解できる知能があればそんな
見当違いなこと言い出さないはずだけど。
まぁ、それをその当然のことを前提にしちゃうとどう見ても勝ち目が無いから
馬鹿のふりして話題そらして逃げてるんだろうけど。
ちなみ海外と言えばUnreal EngineやCryEngineのactorはタスクのごった煮とやらと
本質的に同じ。型固定でifとswitchだけ、なんて牧歌的な作りは影も形も無いけど、
それについてはどんな逃げ方をするのかな？また話題そらし？
156:名前は開発中のものです。
11/09/11 21:40:28.61 YqmjwGNN
偉そうなタームを並べちゃってw
現代言われている「ゲームエンジン」が、もはやタスクシステムとはぜんぜん違う
ものであることには目をつぶって「あれもこれもシステムだもん」とかw
157:名前は開発中のものです。
11/09/11 22:13:11.16 Y7Irx4Sl
結局その逃げ方しかできんのか。つまらんな。
taskもactorも逐次実行じゃないよ？ほら？どうした？ｗｗｗ
タスクシステムとはぜんぜん違う？どのタスクシステムとは違うのかな？
AndroidやiPhone用のプログラム本にのってる近年のタスクシステムと近年の
ゲームエンジンに本質的な違いがあるならその違いを言ってごらんよ。
158:名前は開発中のものです。
11/09/11 22:54:47.89 Ynk6BT3o
その前にタスクシステムは普通の書き方のなんの問題を解決してるのか聞いてみたい
単に面倒なだけだと思うんだけどｗ
159:名前は開発中のものです。
11/09/11 23:14:25.45 Y7Irx4Sl
形勢不利だから話題そらしで逃げるつもりみたいだけど残念。
>>157
の答えを早くくれないかな。
actorが逐次実行なのはいいのかな？ゲームフレームワークも全否定？
タスクとゲームエンジンの本質的な違い、「ぜんぜん違う」と断言できるなら当然答えられるよね？
160:名前は開発中のものです。
11/09/11 23:15:43.66 QoX0R0+Y
皆が話してる「タスクシステム」って何なの？
161:名前は開発中のものです。
11/09/11 23:17:28.01 YqmjwGNN
それは本質ではない、という逃げは万能だもんな。
はいはい、あんたの勝ちですよw
162:名前は開発中のものです。
11/09/11 23:21:28.73 Y7Irx4Sl
＞あんたの勝ちですよw
典型的だなｗｗｗ
「もう来ねえよ!ウワァァン」が足りないぞ？
163:名前は開発中のものです。
11/09/11 23:47:35.30 Ynk6BT3o
>>160
ごった煮リストにインスタンスをすべてぶち込むシステム
なんだけど
明らかに取り出すときにそのぶち込んだものがなんであるか判定する必要があってやたらと面倒なんだ
しかもバグる
実行順序も制御きかねぇし
164:名前は開発中のものです。
11/09/11 23:50:22.61 ZZ/mHUa2
俺に言わせりゃ、actorなんか使うのはアホだけど、
それでも、フレームワークが社外製で、
メインループを触ることが出来ないっつーんなら、仕方ない。
ちょうどOSのウィンドウやドライバがそうなっているようにな。
新しいアプリやドライバ書く度にカーネル触って再コンパイルってわけにはいかないからな。
どうしてもコールバック前提の非同期処理になる。
だから、メインループ部に改変不可なフレームワークを導入するのはお勧めできないな。
メインループはゲームに合わせて自分で書いたほうがよい。
描画エンジンやサウンドエンジンや物理エンジンは外部ライブラリに任せてしまえば良いけどね。
165:名前は開発中のものです。
11/09/11 23:50:44.67 YqmjwGNN
典型的な勝利宣言バカだろ、おまえが
166:名前は開発中のものです。
11/09/11 23:55:56.92 Ynk6BT3o
>>164
え？お前んとこって全部追加部分はdllかなにかで書いてるわけ？ゲームなのに？
そうでないならタスクシステムはいらないっていってる？
なんか特殊じゃね？
167:名前は開発中のものです。
11/09/11 23:57:25.94 Y7Irx4Sl
>>165
＞はいはい、あんたの勝ちですよw
なんてみっともない白旗自分から上げといて
もう一度参上できるとはすごい勇気だね。
普通ならとても恥ずかしくて出てこれないよｗｗｗ
で？答えは出た？ｗｗｗ
168:名前は開発中のものです。
11/09/12 00:04:11.07 1pUHEh9P
>>163
実行順の制御は出来る場合が多い。
ただ、普通にtask1();task2();って並べて書いてくのと何も変わらないし、
ソースコード見ただけじゃ、何がどの順で動くのか分からないし、
if文やfor文といった高度な制御構造を持てない直線番長だし、
高級言語では当たり前の機能の型も死ぬし、
実行効率もベタで書いたコードより速い訳ではないし。
>>158も言っている様に、ここまでの話の流れで、
だれも之と言ったタスクシステムのメリットを挙げてない。(し、実際無い)
そのくせ、高級言語の持つ「型」と「制御構造」という2大機能を殺すわけだから、
まったく使う理由が無い。
169:名前は開発中のものです。
11/09/12 00:06:20.63 k+/jcxg5
> だれも之と言ったタスクシステムのメリットを挙げてない。(し、実際無い)
> そのくせ、高級言語の持つ「型」と「制御構造」という2大機能を殺すわけだから、
> まったく使う理由が無い。
それなのに >>167 のように完全に勝ったつもりでいるんだぜ？
キチガイここに極まれりだな。
170:名前は開発中のものです。
11/09/12 00:10:36.54 0e8x3TnW
>>135-161
で見事なまでに完全論破してるね・・・
型云々とか逐次実行とか言ってるのは >>157 に答えられない以上
惨敗確定だｗｗｗ
171:名前は開発中のものです。
11/09/12 00:17:43.46 k+/jcxg5
どこが？
172:名前は開発中のものです。
11/09/12 00:53:29.75 C74P2jTs
>>155,157
Unreal Engine の Actor ってのはこれでいいんかな？
URLﾘﾝｸ(udn.epicgames.com)
URLﾘﾝｸ(udn.epicgames.com)
クラスの必要性がちゃんとドキュメント化されてていいね。いつ使うべきか、使わないで
いいのはどんな場合か、ちゃんとわかるだろう。
少なくとも、必要性やメリットを問いただすだけで荒れるような「タスクシステム」とは
まったく格の違うものに見える。
173:名前は開発中のものです。
11/09/12 00:56:51.96 C74P2jTs
>>157
> AndroidやiPhone用のプログラム本にのってる近年のタスクシステムと近年の
さらっと流しかけたけど、これマジか？どの本にそんなの載ってるの？
174:名前は開発中のものです。
11/09/12 01:26:30.29 1pUHEh9P
>>172
俺的にはタスクシステムと同じかなー。
個人的にはこう言う仕組みってあまりメリット感じなんだよね。
それでも規格とドキュメントがしっかりしている分、ずいぶんマシだけど。
175:名前は開発中のものです。
11/09/12 08:40:01.46 k+/jcxg5
URLﾘﾝｸ(tatsu-zine.com)
なんか、どんなもんでもタスクシステムだと言っちゃえばタスクシステムだ、
みたいなこと言ってるなw
176:名前は開発中のものです。
11/09/12 08:40:33.34 c30nkSHj
意味不明なんだよ
だってごった煮にしたから各update側には余計なもんが流れてくるから仕分けしないといけないし
一旦まとめる意味がまったくない
論破とか言われてもこの事実が覆る情報なんて一つも出てないじゃん
だからオナニーなんだろ？(笑)
正直に僕のオナニーを見てって言えよ
177:名前は開発中のものです。
11/09/12 09:40:05.43 r2WqQWWe
アセンブラ時代にフレームワークとして、
自前でちょっとこーいう枠組みを用意しちゃうよ、ってんなら理解できる。
だってそこには、型も、クラスも、リストも無いんだから。
178:名前は開発中のものです。
11/09/12 17:07:09.89 Q2UPSfzC
ポインタ覚えたてのころにやると、何か得体のしれない黒魔術みたいでカッコいいじゃん
よく分からん…けど動いたスゲーって感じで
>>2のTCBは子供騙しでありロマンだよ
179:名前は開発中のものです。
11/09/12 21:27:03.15 0e8x3TnW
タスクシステムとUnreal Engine の actorの違いはドキュメントの有無。
ドキュメントがあるぶんactorの方がはるかにマシだが両方ごった煮には変わりないのでどちらもメリットは理解できない、と。
で、taskにしろactorにしろメリットがわからない、といってる人の目から見るとそれが何で動いてるのかわからない
何か得体のしれない黒魔術のように見えている、と。
で、ifとswitchだけ使って全て逐次実行でベタ書きしないとバグだらけになって作れないと主張している、と。
まとめるとこんな感じになるな。
180:名前は開発中のものです。
11/09/12 21:43:17.91 JVPxlqK+
Unreal Engineはレンダリング、コリジョン探索の両方を扱う枠組みを与えてくれるんだろ？
しかも、それぞれにしっかりした実装があるってんならメリットはまさにそれのことだろう？
自力でレンダリングや衝突を頑張っても、わりと汚くなって性能なんてお粗慢なんだから。
181:名前は開発中のものです。
11/09/12 22:19:19.23 0e8x3TnW
レンダリングやコリジョン探索を扱う枠組はUnreal Engineの一部ではあるが
アーキテクト上actorとは別階層の話だ。
レンダリングやコリジョン探索の実装があるならメリットは理解できる、というなら
同じようにタスクシステム上にレンダリングとコリジョン検索を扱うフレームワーク実装があれば
そのフレームワークのメリットを理解できる、ということになるが、それでいいのかね？
182:名前は開発中のものです。
11/09/12 22:33:43.32 JVPxlqK+
ん？
> そのフレームワークのメリットを理解できる、ということになるが、それでいいのかね？
いいのかね？ と言われても…。タスクシステムだろうと、Unreal Engineだろうと、
それ以外のなんかであろうと、一定の評価を得たライブラリの実装があれば、
それは評価できるし、使えるんならメリットだろう？ それだけのことを言ったつもりだが。
ちなみにこのスレで発言したのは>>180が初めてだよ。
183:名前は開発中のものです。
11/09/12 22:40:22.91 0e8x3TnW
ほう、これが初めての書き込みね。そーいうことなら大変失礼。
ま、普通の人間はメリットについて当然そう考えるわな。
＞普通にtask1();task2();って並べて書いてくのと何も変わらないし、
＞ソースコード見ただけじゃ、何がどの順で動くのか分からないし、
とかでtaskもactorも全てメリットが無い、みたいな考えをするアレと一緒にされたら
誰でも不快だよな。大変失礼、謝るよ。
184:名前は開発中のものです。
11/09/12 23:02:21.91 1pUHEh9P
といいつつ、メリットは書き込まれない。一度も。
185:名前は開発中のものです。
11/09/12 23:10:27.89 1pUHEh9P
例えば、レンダリングエンジンやコリジョンエンジンが搭載されているタスクシステムがあったとして
とても便利だったとする。
でも、それらからタスクシステムを無くすともっと便利、
もしくは、有っても、あえてタスクシステム部は使わない方がもっと便利、
なわけだから、やっぱりタスクシステムは要らないって話になる。
そもそも、タスクシステムに描画エンジンやコリジョンエンジンをくっ付ける必要はないしな。
タスクシステム、描画エンジン、コリジョンエンジン、サウンドエンジンが
それぞれ選択的に利用できるようになってた方が、必要に応じて選べて便利だ。
そんで、タスクシステムだけ使わないのなw。
アンリアルエンジンのActorも使わなければ良いだけの話。
186:名前は開発中のものです。
11/09/13 00:00:04.61 7WlpQLAU
真性のアレのお出ましか。
＞メリットは書き込まれない。一度も。
今までのログや >>2 のリンク先からいくらでも長所、メリットが
明記されてる箇所が見つかるのに”一度も”とか断言しちゃうような
特殊学校級の真性君に根気よく説明するサリバン先生みたいな
聖人じゃないんだ、ゴメンネ。
＞アンリアルエンジンのActorも使わなければ良いだけの話。
世界でミリオンタイトルをいくつも出してるゲームエンジンを
使ってる優秀な人たちは君とは何故か違う考えみたいだけど、
君にとっては自分の頭で理解できないものを使わない、ってのは
正解だとは思うよ。
187:名前は開発中のものです。
11/09/13 00:04:51.24 pCx3Pnsp
ソースロンダリングはいいって。
さっさとメリット挙げたら？
188:名前は開発中のものです。
11/09/13 01:08:57.32 D6ApEC6F
>>186
> 今までのログや >>2 のリンク先からいくらでも長所、メリットが
> 明記されてる箇所が見つかるのに”一度も”とか断言しちゃうような
それらの長所・メリットは、仮想関数をはじめ標準コンテナや関数オブジェクトなど、
より汎用的で粒度の高い現代的な手法の選択的な組み合わせで置き換えられるから、
今さらタスクシステムなんて作る必要はないよね。
ここで出せ出せといわれているのは、こういう他の手段での置き換えが利かない
タスクシステム独特の長所だろう。
すでに出てるんなら URL 貼るだけでもいいんだから、出してもらえないだろうか？
189:名前は開発中のものです。
11/09/13 08:59:03.57 aC0nIGEU
タスクシステムのメリットはあがらない絶対だ
190:名前は開発中のものです。
11/09/13 13:11:55.54 3fH2rWBj
真性のアレ、はどう見てもおまえなんだが。
現代的なゲームエンジンのことなら「ゲームエンジン」と呼べばいい。
過去いくつも、全くそれに及びもつかない実例がある「タスクシステム」なんて呼称で、
現代的なゲームエンジンまで含ませよう、だなんていう発想をするおまえが、
どう見ても真性のアレ。基地外タスクシステム信者。
191:名前は開発中のものです。
11/09/13 20:43:23.42 7WlpQLAU
>>188
＞それらの長所・メリットは、仮想関数をはじめ標準コンテナや関数オブジェクトなど、
へぇ、「それらの長所・メリット」ってことは君は少なくともメリットがあがってるのを知覚できるぐらいの知能はあるんだね。
＞ここで出せ出せといわれているのは、こういう他の手段での置き換えが利かない
でも「他の手段がある＝メリットが無い」の論理的な間違いを認知できるだけの知能は無いみたいだね。
>>190
＞現代的なゲームエンジンまで含ませよう、だなんていう発想をするおまえが、
ほぅ、つまり
＞アンリアルエンジンのActorも使わなければ良いだけの話。
みたいな真性ちゃんと一緒にするな、と言ってる訳ね。www
192:名前は開発中のものです。
11/09/13 22:55:00.28 pCx3Pnsp
そしてやっぱりタスクシステムのメリットは挙がらない。
193:名前は開発中のものです。
11/09/13 23:09:28.54 CoLgixDm
＞タスクシステムのメリット
一言でいえば抽象化。
まあ実際に抽象化によだれ垂らして魅力を感じる人種なんてごくわずかだよな。
194:名前は開発中のものです。
11/09/13 23:48:36.64 pCx3Pnsp
タスク=処理なんか抽象化して、一体何をしようって言うの？
何か目的があるなら、その目的のエンジンでも作って外部に追いやったら良いだけでは？
例えば描画エンジンやサウンドエンジンや物理エンジンみたいに。
195:名前は開発中のものです。
11/09/13 23:52:17.37 D6ApEC6F
>>191
> でも「他の手段がある＝メリットが無い」の論理的な間違い
そこに突っかかってたの？
たぶんそういう意味でメリットを出せと言ってた人はいないと思うよ、ということを説明
したつもりだったんだけど。
で、結局「タスクシステム独特の長所」を挙げないということはつまり、「いくらでも」と
言ってたタスクシステムの長所、メリットっていうのはすべて他の（より汎用的でｒｙ）手法で
置き換えられるものである、と解釈していいのかな？
196:名前は開発中のものです。
11/09/14 00:14:23.96 RbzrsAkF
何も不思議じゃない。
//俺らのメリット算出方
foreach( A_list )
foreach( B_list )
{
compare( A, B );
}
//彼らのメリット算出方
foreach( task_list )
{
task->merit();
}
思考回路が元々違うんだよ。彼らは他とのかかわりにメリットを見出さない。スタンドアロンこそ至高。
197:名前は開発中のものです。
11/09/14 00:40:49.57 9+DNuNz5
>>195
＞で、結局「タスクシステム独特の長所」を挙げないということはつまり、「いくらでも」と
＞言ってたタスクシステムの長所、メリットっていうのはすべて他の（より汎用的でｒｙ）手法で
「タスクシステム独特の長所」と「タスクシステムの長所」が都合よく混同されてるのはわざとかな？
それとも馬鹿だから矛盾に気づかないから？どっちかな。
まぁ「他の手段がある≠メリットが無い」と当たり前の前提の前では
そうごまかすしか無いんだろうねぇ・・・
198:名前は開発中のものです。
11/09/14 00:53:35.60 2wea9XYb
だめだｗ会話にならねぇ
199:名前は開発中のものです。
11/09/14 01:24:27.88 9+DNuNz5
色々なジャンル、仕様、言語、ハード制限上でtaskなりactorなりのメリットを利用した
アーキテクチャで動く完成されたゲームが多数存在するわけだ。
で、これらの明示されたメリットが間違いであることを証明するためにはそれら全てのケースを、
他の手段の実装で元と同じ仕様を完全に満たせること、さらに実装コスト、CPU消費リソース、メモリ消費量、
生産性、その他諸々がtaskやactorを使うより良い値になることを証明する必要がある。
どれか一つでもそれが出来ないとそのケースではメリットが「ある」ってことになるからね。
「独自じゃない」「他の手段が存在する」ってのはそもそもメリットの有無とは無関係。
ってことで、あげられたメリットの間違いの証明よりしく。
とりあえず>>2や>>97にタスクのメリットの明記や説明とそれで完成されたゲームがあるからその辺から。
あとactorのメリットも否定してるみたいだから最新のミリオンタイトルでの証明もねwww
でないと「メリットが無いなんて言った僕が間違ってました、許してください（泣）」
って謝るか、また「誰も（僕に理解できる）メリットをあげられない」って真性知恵遅れの
ふりをするしかなくなるから。www
200:名前は開発中のものです。
11/09/14 01:41:11.63 lRejrv89
また逃げたか。
201:名前は開発中のものです。
11/09/14 01:53:00.58 2wea9XYb
「明示されたメリット」とか「あげられたメリット」とか、もうね。
おまえわざとやってるだろ。
202:名前は開発中のものです。
11/09/14 01:58:29.51 lRejrv89
俺恐竜飼ってるんだ！！
マジだよ！
見せてやらないけどマジだよ！
どんな恐竜か言えないけどマジだよ！
203:名前は開発中のものです。
11/09/14 05:57:36.37 tmisYety
今日もタスクシステムのメリットはあがらない絶対だ
204:名前は開発中のものです。
11/09/14 08:08:42.84 eS9b7eHQ
なんか「ぼくのかんがえたさいきょうの」が、この基地外の脳内では、
タスクシステムという言葉の前に付いてるんだな、多分。
えーと、アクタモデルって非同期なんですが、タスクシステムで
非同期呼び出しを抽象化してる文献ってあります？
あるなら示してね。示せなければおまえの言ってることは脳内だと決定だから。
205:名前は開発中のものです。
11/09/14 08:36:33.75 vVsGUZmh
>>204
関係のない話だ
示せたところでタスクシステムのメリットの話とはほど遠い
206:名前は開発中のものです。
11/09/14 19:46:38.28 TEFbFSuQ
カプコンのMTフレームワークってタスクシステムで実装してるんじゃないの？
個々のタスクを象徴化することで、マルチスレッド化の際に、処理に関係無くタスクをスレッドに割り触れるのと、個々のスレッドの負荷に応じて、タスクの再割り当ても容易に実現できるじゃないかな？
207:名前は開発中のものです。
11/09/14 19:54:50.57 TEFbFSuQ
あと、タスクって単位にすることで、個々のタスクの処理時間を現道に管理することが出来るから、プロファイラーで、チューニングする場合も、負荷原因の分析が容易に実現できるじゃないか
208:名前は開発中のものです。
11/09/14 19:57:15.45 TEFbFSuQ
↑現道→厳密
209:名前は開発中のものです。
11/09/14 20:20:11.79 JZWV1Mta
＞まあ実際に抽象化によだれ垂らして魅力を感じる人種なんてごくわずかだよな。
これを繰り返すのは悲しいぜ。
「あれはダメ」「これはダメ」なんてNG発言テンプレ繰り返していると、
浅はかな奴だなと思われてしまうぞ。
自分のやりやすいやり方でやればいいと思うよ。
210:名前は開発中のものです。
11/09/14 23:09:01.96 tmisYety
>>206
上のほうのあったま悪ぃ奴等が考えたライブラリ使うほうの身になってみろってのｗ
的代物と予想
デビルメイクライとか人気有り気なゲームにも使われてるんだろうか？
211:名前は開発中のものです。
11/09/15 05:46:32.18 X4eTv7zl
>>199
taskだろうがactorだろうが適切に使われた場合のメリットを否定することは誰にもできない
あんたの勝ち
個人的にはタスクシステムというバズワードにあまり良い印象は無いけど
さすがにUnreal Engineまで否定したり単発IDでメリット絶対にあがらないとか連呼する馬鹿と同類にはなりたくない
212:名前は開発中のものです。
11/09/15 06:05:29.80 HTGL8JrA
ダメなもんふんだんに使っててもそれを上回るもんがあれば使うんじゃね？
だからといってダメな箇所はやっぱりダメだろ
213:名前は開発中のものです。
11/09/15 09:04:52.49 dPXBkiSf
>>206 「タスク」ってのは一般的な用語だから、それを使うゲームエンジンもあるだろう。
しかし、タスクという用語が使われているからと言ってタスクシステムと言うな、と。
タスクシステムという用語は >>2 のように過去にさんざ俺様システムを指して使われてるから。
214:名前は開発中のものです。
11/09/15 09:59:54.22 jPQ/7J/c
Unreal Engineはコンセプトじゃなくて、クオリティが買われてるんじゃね？
しっかり動いて、表現力もあるからじゃね？
で、タスクシステムならではの価値って何？
ハッキリしたメリットってやっぱり無いのか？
215:名前は開発中のものです。
11/09/15 14:10:29.91 /z22kFyX
>>213
タスクスケジューラーとか？
216:名前は開発中のものです。
11/09/15 22:31:31.45 0dcbvfmp
無限遠方の0地点との比較なら、どんなものでも存在しているだけで+になるから
かならず存在しているものには全てなんらかのメリットはあるんだけど、
そんな遊びに興味は無い。
他の何かと比較してこそ有用なメリットが浮かび上がる。
その意味でのタスクシステムのメリットは未だに挙がってない。
217:名前は開発中のものです。
11/09/15 23:11:04.64 wQycavaM
タスクシステムのメリットとやらを知ってる奴が、
こうだよ、これだよ、と示してくれたら十分だと思うんだが…。
それを言うことすら困難で大変でめんどくさくてしょうがないほどの、
ビミョーな言いにくい、不明瞭なメリットしかないのか？
218:名前は開発中のものです。
11/09/15 23:21:26.57 YYYHmhqU
いままでの挑戦者は全員「日本語でおｋ」って感じの奴等ばっかりだなｗ
219:名前は開発中のものです。
11/09/16 22:58:30.16 v4UaqC9+
>>216
＞無限遠方の0地点との比較なら、どんなものでも存在しているだけで+になるから
”僕の脳内だけにあるすごい逐次処理”は完全な0。ってことは認めちゃったのね。
＞かならず存在しているものには全てなんらかのメリットはあるんだけど、
と
＞他の何かと比較してこそ有用なメリットが浮かび上がる。
って自分で言っていて矛盾してることに気づかないなかしら。
お仲間のタスク懐疑派にすら呆れて見捨てられるだけのことはある。救いの無いお馬鹿さんだね。
220:名前は開発中のものです。
11/09/16 23:20:29.84 H6Mhy7O+
無限遠方の0地点は宇宙すら存在していないような、何も無い世界。
それに比べれば、タスクシステムにだってメリットは有る。
だけど、お前は、「"僕の脳内だけにあるすごい逐次処理”は完全な0」というが、
実際には、0ではないし、タスクシステムよりもメリットがある。
タスクシステムはアセンブリ時代に作られたもの。
俺の言う、「型や用途ごとにリストを分けて、制御構文で制御を記述」は、
アセンブリ時代より後に生まれた高級言語の機能を利用した方法だから、
前者より洗練されてる。より無限遠方の0地点より遠い。
もし、そこをお前が言うように0地点の基準とするならば、
タスクシステムはマイナスになってしまう。まさにメリットなし。
後半は、
メリット≠有用なメリット
いつもの意図的な読み飛ばし乙
221:名前は開発中のものです。
11/09/16 23:27:30.91 v4UaqC9+
＞実際には、0ではないし、タスクシステムよりもメリットがある。
それは今のところ何の証明もされてない坊やの脳内だけに存在する妄想だね。
>>199
＞他の手段の実装で元と同じ仕様を完全に満たせること、さらに実装コスト、CPU消費リソース、メモリ消費量、
＞生産性、その他諸々がtaskやactorを使うより良い値になることを証明する必要がある。
続きは妄想じゃ無いと証明できてからだね。
222:名前は開発中のものです。
11/09/16 23:35:19.68 v4UaqC9+
>>220
＞メリット≠有用なメリット
こんなおもろいもの見落としたわ。思わず吹き出しちゃったよｗｗｗｗ
何このギャグｗｗｗ
メリットと有用なメリットの違い、ぜひ詳しく解説してほしいなｗｗｗ
223:名前は開発中のものです。
11/09/16 23:50:51.32 AnOXip5X
あー、やめろやめろ
結局、タスクシステムのメリットとかでてこないなら話続けなくていいから
次の挑戦者さんどうぞ↓
224:名前は開発中のものです。
11/09/16 23:58:48.64 v4UaqC9+
>>211 が呆れて見捨てるのもわかるよ
＞さすがにUnreal Engineまで否定したり単発IDでメリット絶対にあがらないとか連呼する馬鹿と同類にはなりたくない
負けが確定すると単発IDでメリット出せってワンパターンに逃げまわる負け犬。
たしかにこんな真性馬鹿と同類にされるなんて屈辱だよなｗｗｗ
225:名前は開発中のものです。
11/09/17 00:17:54.81 MCs54x4G
挑戦者 ＝ タスクシステムの理解に挑戦している童貞（笑）↑
226:名前は開発中のものです。
11/09/17 00:22:21.73 MCs54x4G
>>225は>>223向けな。
余りにもしょーもない方向に行っていたから、
まさか相手にする人が出てくるとは思わんかった。
227:名前は開発中のものです。
11/09/17 00:26:06.83 4i4N0qwB
>>221
悪魔の照明をさせたいのだろうが、その手には乗らんよ。
お前はメリットも述べず、ディメリットを否定することもせず、
ひたすらあおって相手が「メリットが無い」と書き込むのを待っていただけだろ。
お前は自らが「メリットが無い」と言う言葉をひたすら繰り返すことで、相手に刷り込ませて、
発言させるのを待っていただけなんだな。今読み返して分かった。
>>222
無意味な比較に基づいてはじき出されたメリットに有用性は無いだろ。
何も無いよりはマシだ、とかね。本当に何も無いのならそうだが、
実際には高級言語を使えるのが当たり前なわけで。
それの機能を無いものとして、メリットを説いたところで通用しないだろ。
228:名前は開発中のものです。
11/09/17 00:32:16.47 4i4N0qwB
俺は初め、
「タスクシステムを使わずにベタで書いたほうがよい」って書いていただけなのに、
相手か繰り返し、「メリットが無い」って言葉を繰り返すものだから、
勝手に立場が出来上がって、そのまま「メリットが無い」って発言しちゃったんだよな。
仕組まれたな。
単に、タスクシステムでかくより、
高級言語で型ごとにリスト持って制御構文で制御する方が良い、
と言っておけばよかったのか。そうすれば悪魔の照明も必要ないな。
メリットって言葉は例の彼が一番使ってる訳で、初めはそんな話誰もしてなかったんだよな。
229:名前は開発中のものです。
11/09/17 00:37:40.47 4i4N0qwB
要は、相手にはディメリットがあって、こっちにはこういうメリットがあります、と言えば良いわけか。
つーか、まぁ普通そう考える罠。
そこを捻じ曲げてくる彼の手法には正直感服した。
二重否定を使って、言葉を刷り込むのな。こういうのはディベートとかで習うんかねぇ。
230:名前は開発中のものです。
11/09/17 01:05:12.23 qHdhBdvV
>>228
＞「タスクシステムを使わずにベタで書いたほうがよい」って書いていただけなのに、
結局同じことを言ってるねぇ・・・
それは今のところ君の脳内だけの仮定で何も証明されてないから。
>>199
の証明よろしく。これは君の妄想でなければ実在するはずの二つの実装の有益性の比較だ。
現実に実行可能だし悪魔の証明とは構造が違うねぇ。
しかもこのスレには珍しく有益だ！ｗｗｗ
＞メリットって言葉は例の彼が一番使ってる訳で、初めはそんな話誰もしてなかったんだよな。
おやおや、「彼」ねぇ・・・・
ではその「メリット君」とやらはこのスレ公認の真性お馬鹿さんということにしておきますかｗｗｗ
231:名前は開発中のものです。
11/09/17 01:17:23.83 qHdhBdvV
悪魔の証明といえば
こっちは君が言った言葉の矛盾を追求していただけですがねぇ
その結果悪魔の証明になったのは君の最初の前提が間違ってるからなんだけどね
「タスクシステムを使わずにベタで書いたほうがよい」
この一文で君は自分から悪魔の証明にはまっているんだよねぇ・・・
この文のどこが間違ってるかわかるかな？
ヒントはこの文の「よい」が「好みだ」なら特に間違いにはならないということだ。
「よい」とするならこの文にはあるものが欠けている。
232:名前は開発中のものです。
11/09/17 01:28:11.15 36JW9Dyb
で、メリットって何？
233:名前は開発中のものです。
11/09/17 02:10:11.81 4i4N0qwB
>>230
>>199の証明をする必要は無いよ。
だって初めから高級言語の型と制御構造の機能を 殺す/殺さない について言及している訳だから。
>>101-102を読めば分かるけど、誰もCPUリソースやメモリリソースの話はしてない。
如何にシンプルに記述するか、初めから記述性を問題にしている。
それへの反論で、お前が突然勝手に変なこと言い出したんだから、
自らが>>199に基づいてタスクシステムのメリットを証明したら？
234:名前は開発中のものです。
11/09/17 02:40:26.56 36JW9Dyb
メリットが「有る」と主張する者がそれを示すべきである。
235:名前は開発中のものです。
11/09/17 03:06:29.62 qHdhBdvV
>>233
つまり君の言う「タスクシステムを使わずにベタで書いたほうが”よい”」ってのは
メモリ使用量もCPU効率も生産性も悪いけど「シンプルに記述することができる」
ってだけの話なのね。シンプルに記述ってのも怪しいもんだが、まぁ
君の言う「よい」がそういう意味限定なら君の頭の中だけでは成立するかもねぇ・・・
普通のプログラマはそんな意味で「よい」とか使わんなぁ
236:名前は開発中のものです。
11/09/17 03:18:33.09 VCr/0evz
>>235
「タスクシステム」がメモリ使用量やCPU効率や生産性を改善してくれると言いたげだな。
それなら「タスクシステム」を使わない場合のコードと使う場合のコードを挙げてそれを
示してくれよ。
237:名前は開発中のものです。
11/09/17 03:23:41.38 MCs54x4G
手段のアドバンテージというのは絶対的なものではない。
目的・条件・状況に応じて、ある手段にアドバンテージが発生したり消滅したりする。
そしてもちろんアドバンテージは使用する人間のスキルや特性にも依存する。
「タスクシステムを使うメリットが無い」
→「ﾎﾞｸﾁﾝは、タスクシステムのアドバンテージを活かせる問題を経験したことが無い」
→「タスクシステムのアドバンテージを活かせるだけの十分なスキル・特性がﾎﾞｸﾁﾝにはない」
ｗｗｗ
「メリットを示せ」
→「ﾎﾞｸﾁﾝのスキル・特性・問題意識が劣っていることを証明しろ（ｶﾞｸﾌﾞﾙ」
ｗｗｗ
「記述性を問題に」
→「ﾎﾞｸﾁﾝにわかる記述で解決できる問題しか、問題と認めません」
ｗｗｗ
ﾜﾗカスなや。相変わらず不毛だな。手を動かせ。
「悪魔の証明」とか使っててカッコいいとか思ってんのかね。
相変わらず引き籠り臭がひどいな。
何が問題かは自分で決めろよ。
誰かが言っていたが、何が問題なのか人に聞いているようじゃダメだな。
238:名前は開発中のものです。
11/09/17 03:27:27.96 4i4N0qwB
>>234
実際そうなんだよね。無いことの証明の義務は無いからね。
でもそんなこといっちゃかわいそうでしょ。
相手さんは、有ることの証明すら出来ないか、
もしくは有っても小さすぎて言えない立場なんだから。
>>235
>メモリ使用量もCPU効率も生産性も悪いけど「シンプルに記述することができる」
「ベタ書きがメモリ使用量もCPU効率も生産性も悪い」は、俺は言って無い。
初耳だし、お前の意見だからお前が保証しろよ。俺は知らん。
239:名前は開発中のものです。
11/09/17 03:33:00.58 4i4N0qwB
おい、ID:MCs54x4G よ。
俺の相手ばっかしてないで、ID:MCs54x4G の相手してやれよ。
真性の相手するの好きなんだろ？
240:名前は開発中のものです。
11/09/17 03:37:26.82 qHdhBdvV
>>236
効率が良くなるか聞いたら「誰もCPUリソースやメモリリソースの話はしてない。」
って否定したから良くはならんのだろう、と思っただけだがぁ？
別にこちらはタスクシステムが何かよりも優れてるなんて一言も言ってない。
タスクシステムよりベタ書きが「よい」って言い張るやつがいたから
普通のプログラマとして効率なり何なりが良くなるというなら証明はあるのかね？
と聞いただけだ。
あと「シンプルに記述できる」と言い張るなら結局>>199と同じように
シンプルに記述できることを示して見せないとねぇ・・・
まぁ普通に考えれば何の前提条件もつけずに「よい」とか「わるい」とか
断言しちゃうプログラマは思い込みの激しいお馬鹿さんとして遊ばれる運命なんだがｗｗｗ
241:名前は開発中のものです。
11/09/17 07:22:40.75 lH2L/Zqh
今日もタスクシステムのメリットはあがらない！絶対だ！
242:名前は開発中のものです。
11/09/17 09:06:14.97 XgHTKRTi
だれかタスクシステムでなんかつくってうぷしろよ
インベーダゲームとか
それをたたき台にはなししようぜ
243:名前は開発中のものです。
11/09/17 09:30:31.14 lH2L/Zqh
前に星がキラキラするサンプルを
タスクシステムと普通の書き方で比べたことがあったんだけど
タスク側はこの書き方は違うだのあーだこーだごちゃごちゃいうだけで何も進展しないで終わったよ
244:名前は開発中のものです。
11/09/17 11:25:57.16 gc0AoBNe
>>237
は今後独自フィルターを通して現実を見る事を宣言したようですｗ
245:名前は開発中のものです。
11/09/17 11:49:37.92 qHdhBdvV
>>243
うわぁ・・・まじかよ
ゲーム一本どころか星がキラキラするサンプル程度のものすら
タスクシステム使ったら実装できないって底辺ゲー専生徒以下のレベルの子だったのね・・・
前からタスク使うとバグだらけで作れない、とか何か得体のしれない黒魔術とか、
言ってることに違和感があったんだけどそーいうことか。
で、ifとswitchだけ使ってプログラム作れと粘着してたのね。
やっと納得できたがレベルが低すぎてまじで呆れた。
まぁ匿名掲示板だからどんなレベルの人が書き込んでもいいんだけどさ、
君のレベルならまず本屋のゲームプログラムコーナーにでも行って
適当にタスクシステム使ったサンプルのってる本を一冊、最初から最後まで
通してちゃんと勉強するのがいいと思うよ。こんなスレで粘着してる暇があるなら・・・
246:名前は開発中のものです。
11/09/17 13:40:44.52 lH2L/Zqh
>>245
いや、ちゃんとレスを読めばわかると思うんけど
俺はアンチタスク派
247:名前は開発中のものです。
11/09/17 14:02:12.11 MCs54x4G
今日もアンチは殻に閉じ込められたままで成長することはない！絶対だ！
248:名前は開発中のものです。
11/09/17 15:30:12.89 lH2L/Zqh
>>247
それはむしろタスク派だろ
タスク以外の組み方した上でやってるのかと・・・
249:名前は開発中のものです。
11/09/17 18:09:03.48 PmKmkwjo
一体>>243をどう解釈したら>>245みたいなレスが出てくるんだろう。怖い。
250:名前は開発中のものです。
11/09/17 18:24:53.23 wfiREtyq
久しぶりに覗いてわろた。ざーっと読み通したんだが
この挑戦者くんは前スレのハード君だね
相変わらず成長がほとんどないので驚いている
まぁ元気そうで何よりだよ
251:名前は開発中のものです。
11/09/18 01:32:51.46 4A2Y3GhZ
しかしアンチはなんでタスクシステムに粘着するんだろうな。
「タスクシステムのこの有用性は、こういうやり方で代替できる」って代替案を示すわけでもない。
そもそも有用性が無いと思い込んでいるんだったら、そもそもスレに来なきゃいいのに。
そうすればわざわざスキル・センス・経験の無さを露呈することもないだろうに。
どんな得があるんだろうな。
まあ見ていて笑えるからどうでもいいけど。
252:名前は開発中のものです。
11/09/18 02:24:56.62 op9sc0Bj
いつまでたってもメリットを示せないのも笑えるよｗ
示せないけどあるんだよ！ ってのはｗ
253:名前は開発中のものです。
11/09/18 02:51:11.99 VtDDRqaE
組み込みでタスク使ってるけど便利じゃん
ゲームのタスクは不便なの？
254:名前は開発中のものです。
11/09/18 03:01:48.51 VYP6b49t
>>251
> 「タスクシステムのこの有用性は、こういうやり方で代替できる」って代替案を示すわけでもない。
少なくとも >>188 で一度は示されてるように見えるんだが
255:名前は開発中のものです。
11/09/18 06:18:40.68 N+1J8kOQ
>>251
＞そうすればわざわざスキル・センス・経験の無さを露呈することもないだろうに。
彼はスキル・センス・経験を得るのに十分な知性と学習能力を持ってないんだろうｗｗｗ
>>253
ゲームでもそれ以外でも適切につかえば当然便利だと思うよ。
ifとswitchだけで作らないとプログラム完成しないって低脳ちゃんに
「僕が使いこなせないのはタスクが複雑なせいだ！」って恨みかって粘着されちゃっただけ。
>>254
あれ？>>188って
>>188 >>191 >>195 >>197 >>199 >>230 >>240
と来て君が論破された流れじゃんｗｗｗ
>>188 を出すなら >>240 に答えないとね。
256:名前は開発中のものです。
11/09/18 07:02:12.90 9dJPZyb/
>>188とか意味わかんないな
俺は具体的な代替案っていったら>>105だと思う
もっともスタンダードな方法であってなぜこれでダメなのか？
タスクシステムでなくてはならないのか？ってのはみんなに考えてほしいと思うな
257:名前は開発中のものです。
11/09/18 07:11:48.35 N+1J8kOQ
＞タスクシステムでなくてはならないのか？ってのはみんなに考えてほしいと思うな
タスクシステムでないとならない、なんて誰一人言ってないけど、誰と戦ってるの？
アンチは「タスクシステムを使わずにベタで書いたほうがよい」って断言してるけどwww
A「XはYよりよい」
B「へぇ、で、その根拠は？」
A「え...（汗）、お、お前がYのメリットを出せよ！」
B「お前頭大丈夫？」
今こんな感じ。
258:名前は開発中のものです。
11/09/18 07:17:18.77 9dJPZyb/
>>257
いいんだよこのスレのテーマはタスクシステムなんだから
259:名前は開発中のものです。
11/09/18 07:21:03.66 ZnWLqSes
>>256
>>105書いた者だけど、レスありがと。
本来もっとも普通のかき方のはずなのに、ここではなぜかアウェーなんだよね。
例ではシンプルに型ごとに突っ込んでるが、
さらに細分化して用途ごとに分けても良いし、
OOPならインターフェースごとにコレクトしても良いし、
速度命の部分は配列でやってもよいし、
ツリーにしても良いし、foreachを並列化しても良いし、と、
コンテキストに合わせて自由にデータ構造とアルゴリズムを記述できる。。
制御にしたって、二重ループを当たり前に書けるから、相互作用だって簡単だし、
型が死んでなく、オーバーロードが効くから、
テンプレートでダックタイピングしても良いし。