- 1 名前：名前は開発中のものです。 [2010/10/01(金) 19:54:53 ID:ZGMtyIlk]
- タスクシステムで〜す。
- 18 名前：名前は開発中のものです。 mailto:sage [2010/10/13(水) 18:15:32 ID:2KiuekrF]
- >>16
それをつかったタスクシステムを早く見せてみろ。
能書きはいいから早くやれ。
- 19 名前：名前は開発中のものです。 mailto:sage [2010/10/13(水) 21:28:01 ID:CCduEWNw]
- >>18
それが人にものを頼む態度か？
- 20 名前：名前は開発中のものです。 mailto:sage [2010/10/14(木) 01:16:15 ID:ll+gWl86]
- >>18 typedef std::function Task; typedef std::multimap<int, Task> TaskSystem;
- 21 名前：名前は開発中のものです。 mailto:sage [2010/10/14(木) 15:23:01 ID:k3ms7C9R]
- >>20仮想関数よりおせえぞ、このカスが。
- 22 名前：名前は開発中のものです。 mailto:sage [2010/10/15(金) 01:16:59 ID:DzwiEmkJ]
- >>21
www.boost.org/doc/libs/1_44_0/doc/html/function/misc.html#id1285131
> Invocation efficiency
> With a properly inlining compiler, an invocation of a function object requires
> one call through a function pointer. ...
有意な差がでるとは思わんのだけど、どんな計測して言ってるの？
- 23 名前：名前は開発中のものです。 mailto:sage [2010/10/15(金) 03:34:52 ID:wNB49Iff]
- レスが遅いっていう意味じゃないのか
- 24 名前：名前は開発中のものです。 mailto:sage [2010/12/13(月) 19:19:30 ID:SwUzzdNV]
- うおーおちるｗｗｗ
- 25 名前：名前は開発中のものです。 mailto:sage [2010/12/13(月) 20:04:26 ID:L8WMZWjV]
- 落ちていいんじゃない
- 26 名前：名前は開発中のものです。 mailto:sage [2010/12/26(日) 13:53:29 ID:Yn0HjZGE]
- 保守
- 27 名前：名前は開発中のものです。 [2011/01/19(水) 04:08:40 ID:N8paXvut]
- 燃料投下age
d.hatena.ne.jp/alwei/20110117/1295290033
- 28 名前：名前は開発中のものです。 mailto:sage [2011/01/19(水) 08:55:53 ID:85Pl9gjp]
- いってみたらすでに論破されてた
- 29 名前：名前は開発中のものです。 mailto:sage [2011/01/19(水) 10:13:05 ID:e0eMWBCA]
- 名前からして不明瞭。
そこに嫌な匂いを見出せるのは、
ある程度苦労したプログラマ。
- 30 名前：名前は開発中のものです。 mailto:sage [2011/01/19(水) 14:09:28 ID:E8wjYx2w]
- これが島国さんやnyaxtさんの書いた記事だったりすると反応違うんだろうなｗ
- 31 名前：名前は開発中のものです。 mailto:sage [2011/01/19(水) 14:23:28 ID:85Pl9gjp]
- ゲーＰＧはネームバリュー（ハッタリ）に弱い人間少ない気がする
むしろ、俺がそいつを粉砕してやるぜ的な
- 32 名前：名前は開発中のものです。 mailto:sage [2011/01/19(水) 14:30:26 ID:KQY63ukG]
- PCエロゲ界の貴公子の近代的〜が唯一の参考文献としてあげられてるのは
「私の話は眉に唾をたっぷり塗りたくってから読んでください」というシグナルだろ
メモリアロケーションとタスクコントロールの都合をゴチャ混ぜにしてる時点で
ウェブ上に幾度となく流布されてきたアマチュア発の怪文書の仲間入り
- 33 名前：名前は開発中のものです。 mailto:sage [2011/01/19(水) 23:21:57 ID:vxFFDIc1]
- いいかげんCEDECで白黒はっきりすべき
なぁなぁで適当なセッションばっかやってるんじゃねーよ
- 34 名前：名前は開発中のものです。 mailto:sage [2011/01/20(木) 09:09:02 ID:3uJfSIst]
- このぐらいのトラップはあったほうがいい
- 35 名前：名前は開発中のものです。 mailto:sage [2011/01/21(金) 16:04:26 ID:Fjw2Tp9y]
- 理解はできるが それほどはしゃぐほどのしろものじゃぁないと思う ＞ タスクシステム
- 36 名前：名前は開発中のものです。 mailto:sage [2011/01/22(土) 03:03:53 ID:4JOlz5Oe]
- いやそれじゃまったくわかってない
- 37 名前：名前は開発中のものです。 mailto:sage [2011/01/22(土) 07:25:59 ID:QooqzLRE]
- アセンブラレベルで組んでたら当然このようなシステムになると思う ＞ タスクシステム
- 38 名前：名前は開発中のものです。 mailto:sage [2011/01/22(土) 07:38:28 ID:QooqzLRE]
- なので、今の１G単位のファイル扱い時代には、>>3 にあるとおり邪魔すぎる
しかも >>2 のリンク先のとおりに組んでたら１００％環境に依存したものができるね
構造化設計がきちんとできれば、別に困らない
- 39 名前：名前は開発中のものです。 mailto:sage [2011/01/26(水) 20:44:21 ID:4Ps2t9ZU]
- ちょっとしたところを書かせても、
ちょっと見通しよく書いてくれる人と、
ちょっと見通し悪く書いてしまう人が居るね。
- 40 名前：名前は開発中のものです。 mailto:sage [2011/02/02(水) 17:54:54 ID:WROn6kOq]
- 元々はアセンブラレベルで簡単なコルーチンを実現するシステムだった（ジョブコン）。
いつのまにやら、C言語で実装されコルーチンではなくなって、コールバック管理システムになり、
いろいろごてごてと御利益の能書きが追加された。
- 41 名前：名前は開発中のものです。 mailto:sage [2011/02/09(水) 21:51:05 ID:+dlXNCDm]
- まだ根絶はされていないようだ。
twitter.com/search?q=%E3%82%BF%E3%82%B9%E3%82%AF%E3%82%B7%E3%82%B9%E3%83%86%E3%83%A0
- 42 名前：名前は開発中のものです。 mailto:sage [2011/02/09(水) 22:15:38 ID:xtMvpX8d]
- >>41
いっぱいいるね
- 43 名前：名前は開発中のものです。 mailto:sage [2011/02/10(木) 08:36:28 ID:dY2cgLTQ]
- これはひどい
- 44 名前：名前は開発中のものです。 mailto:sage [2011/02/10(木) 09:29:39 ID:rhn2H02Q]
- ツイッターは宮崎県の東国原元知事でもやってる
- 45 名前：名前は開発中のものです。 mailto:sage [2011/02/10(木) 11:13:00 ID:6Rcuugl9]
- タスクシステム、っていう名前からして臭いわな。
便利なフリした機能の癒着やごった煮を連想させる。
- 46 名前：名前は開発中のものです。 mailto:sage [2011/02/11(金) 01:43:47 ID:TZypN/D2]
- ツイッターやってる一般人ってキモイよな
- 47 名前：名前は開発中のものです。 mailto:sage [2011/02/14(月) 09:22:19 ID:7vUEnASs]
- ツイッターやってる一般人がというか、たいした情報でもないのに情報発信源気取りでしゃべってるのがキモいんだと思う。
あまつさえ斜め上の内容だからなおさら。
- 48 名前：名前は開発中のものです。 mailto:sage [2011/02/14(月) 16:24:13 ID:wzlRlBXo]
- タスクシステムとまったく関係のないやりとりをする こいつらがキモイ
- 49 名前：名前は開発中のものです。 mailto:sage [2011/02/15(火) 23:36:25 ID:smoeNTMJ]
- >>48
そう？
- 50 名前：名前は開発中のものです。 mailto:sage [2011/02/16(水) 11:05:15 ID:wRI9y0Na]
- もはや根絶の時期がメインの話題になるぐらいのものでしかない。
- 51 名前：名前は開発中のものです。 mailto:sage [2011/02/17(木) 01:57:08 ID:xb/j0cZ1]
- てか、まだ使ってる人居るのかネェ。
だいたい、プログラム自体が処理を実行順に並べたもの「そのもの」なんだから、
自前で処理リスト持って、毎フレーム逐次実行する意味が分からないよな。
まるでバーチャルマシンじゃん。
void do_tasks(){ task1(); task2(); task3(); /*←タスクリスト*/ }
↑こんなん作っておいて、毎フレーム呼びだしゃ良いだけだもんなぁ。
- 52 名前：名前は開発中のものです。 mailto:sage [2011/02/17(木) 07:28:17 ID:mmuGB28x]
- バカはつかわなくていいよ
- 53 名前：名前は開発中のものです。 mailto:sage [2011/02/17(木) 07:32:48 ID:mmuGB28x]
- みんなでプログラムしようぜ とみんながやる気になる
みんなでいろいろな意見が出され、いろいろ議論される
とても活発、いろんなスレがたてられる
実際につかわれはじめ、みんな期待する
実用化されたものが発売、みんなキター状態
これを見たマスコミが これはすごいともてはやす
マスコミの情報を見て、やじうまがあらわれる
タスクシステムのすごさを報道
バカには理解できない そのうえ、数は多い
こんなもの何の役に立つんだ 根絶してしまえ ← いまここ
- 54 名前：名前は開発中のものです。 mailto:sage [2011/02/17(木) 09:42:43 ID:wffMBw0x]
- >>3
- 55 名前：名前は開発中のものです。 mailto:sage [2011/02/17(木) 12:32:10 ID:mmuGB28x]
- つまりバカほど・・・おっと もはやまともな奴は静かにしてるな
- 56 名前：名前は開発中のものです。 mailto:sage [2011/02/18(金) 00:05:05 ID:Rx3rFAqD]
- 釣りはもっと上手くやれよ
- 57 名前：名前は開発中のものです。 mailto:sage [2011/03/02(水) 11:06:20.50 ID:VVBDgu3W]
- タスクシステムは
抽象的には
発生する大量のオブジェクトを
動的に一元管理・実行できるってのがすべてだと思うんだけど
逆にこれ以外の方法で大量のオブジェクトを扱える設計は
何が考えられますか？
コード中のあちらこちらでメモリ領域確保してたら
わけわからなくなりませんか
- 58 名前：名前は開発中のものです。 mailto:sage [2011/03/02(水) 11:46:07.55 ID:IG+0eofe]
- >>57
全部「タスク」の名の下にごちゃまぜになってるほうがわけわからなくなりませんか？
「〜のコンテナ」を必要なだけ必要なところに置けば十分で、さらにそのほうがコンテナの
スコープが狭まり、個別に名前付けが行われるぶんコードは読みやすいはずです。
コンテナが分かれていれば、特定のオブジェクト郡にだけ適用できる最適化を局所的に
行うこともできるようになります。（ここは挿入削除が頻繁だから list で、ここでは
要素数がずっといっしょだから vector で、などなど）
逆にコンテナがまとまっていた場合、そもそもそういった最適化が不可能になってしまうか、
できたとしても全体に影響が波及してしまうことになり、危険度が上がってしまうでしょう。
> コード中のあちらこちらでメモリ領域確保してたらわけわからなくなりませんか
逆に、なぜ「わけわからなく」なってしまうのかを追究してみたいところです。
- 59 名前：名前は開発中のものです。 mailto:sage [2011/03/02(水) 16:31:08.79 ID:VVBDgu3W]
- >>58
過疎っぽいからレスつかないかと思った。ありがとう
>「〜のコンテナ」を必要なだけ必要なところに置けば十分で
というのがまさしく、気になるところで、例えば
擬似コードですが
class enemy ｛
Tama tama[];//唯一の参照保持コンテナ
弾発射（）｛
//３つ発射しちゃうぞー
tama.add(new Tama());
tama.add(new Tama());
tama.add(new Tama());
｝
}
というような実装を単純にしてしまうと
enemyが弾が消える前に破壊されて
deleteされるような事態になったら
おかしなことになりかねませんよね
当然、こんな場当たり的な領域確保できないわけで、
弾のコンテナのスコープはどこがいいのか、
どう管理するんだ、というような話になると。
つづく
- 60 名前：名前は開発中のものです。 [2011/03/02(水) 16:34:46.21 ID:VVBDgu3W]
- つづき
>コンテナが分かれていれば、
>特定のオブジェクト郡にだけ適用できる最適化を局所的に
>行うこともできるようになります。
というのが、結局のところ
d.hatena.ne.jp/alwei/20110117/1295290033
のタスクシステムの解説記事の中の
■その他の問題 で、
>タスクの数が異常に増えたりする際は複数のタスクリストやコンテナに分けた方が
>管理面でも速度面でも良くなったりします．
というふうにタスクシステムの範疇から出てないのかな、と。
長くなって申し訳ない。
- 61 名前：名前は開発中のものです。 mailto:sage [2011/03/03(木) 01:26:17.44 ID:JE+9DEkn]
- >>59
> 当然、こんな場当たり的な領域確保できないわけで、
「当然」ではないでしょう。「弾が消える前にenemyが破壊される」という
仕様が出てきたから不都合が発生したという話にしか見えません。
それがたとえば「弾」ではなく enemy と共に破壊される「角」とかそういう
オブジェクトであれば何も問題はなかったのです。
> 弾のコンテナのスコープはどこがいいのか、
> どう管理するんだ、というような話になると。
そういう話になるでしょうけども、だからといって「タスク」も「システム」も
カスりもしません。
典型的には「弾のコンテナはもうひとつ外に持っとくか」という話になるだけ
ではないでしょうか？
- 62 名前：名前は開発中のものです。 mailto:sage [2011/03/03(木) 01:27:01.28 ID:JE+9DEkn]
- >>60
>>タスクの数が異常に増えたりする際は複数のタスクリストやコンテナに分けた方が
>>管理面でも速度面でも良くなったりします．
>
> というふうにタスクシステムの範疇から出てないのかな、と。
「オブジェクトをコンテナに入れたら、それはもうタスクシステムだ」という
ことでしょうか？
それを完全に否定する材料は持ち合わせていませんが、それが言えたからと
いって何になるのか、何がうれしいのか、わかりません。
- 63 名前：名前は開発中のものです。 mailto:sage [2011/03/03(木) 04:50:40.85 ID:o4mDyDkO]
- >>61
どうしてもレスが長くなってしまう。。
>「当然」ではないでしょう。「弾が消える前にenemyが破壊される」という
>仕様が出てきたから不都合が発生したという話にしか見えません。
いやいや、さすがにそれはちょっと…
シューティング以外でも魔法でも矢でもエフェクトでもダメージ表示でも。
> 典型的には「弾のコンテナはもうひとつ外に持っとくか」という話になるだけ ではないでしょうか？
それって、enemyのコンテナの隣に弾のコンテナってイメージでいいんですかね。
80種類の敵がいたら80個コンテナ作って自機との命中判定のために80個の
参照作って、なんてのは考えにくいから「敵コンテナ」に統合しますよね。
>「オブジェクトをコンテナに入れたら、それはもうタスクシステムだ」という
>ことでしょうか？
結局、
いわゆるタスクシステムとの違いが
「敵と弾を分離してるだけ」とか、
「シーンクラスとかキー入力処理クラスまで
同じコンテナのタスクとして扱うのは
気持ち悪いから、別処理にする」程度の話なら
タスクシステムのような方言の多い設計技法の実装としては
よく見かける気がするんですよね。
つづく
- 64 名前：名前は開発中のものです。 mailto:sage [2011/03/03(木) 04:51:19.58 ID:o4mDyDkO]
- つづき
それを指して「これはタスクシステムではない！」ってのは
正直に言うと得るところがないです。
むしろ知りたいのは
その範疇には収まらない設計はあるのだろうか、
あったら知っておきたいなと思って、
>>57の
>逆にこれ以外の方法で大量のオブジェクトを扱える設計は
>何が考えられますか？
と聞いたわけです。
知らない以上、うまく言えないんですが
コンテナが不要なデザインパターンみたいなものとか
存在するのかなと思って。
うれしいとかうれしくないとか別にないです。
- 65 名前：名前は開発中のものです。 mailto:sage [2011/03/03(木) 06:16:04.21 ID:JE+9DEkn]
- >>63-64
> いやいや、さすがにそれはちょっと…
何でしょう？書いてもらわないとわかりませんよ。
> 80種類の敵がいたら80個コンテナ作って自機との命中判定のために80個の
> 参照作って、なんてのは考えにくいから「敵コンテナ」に統合しますよね。
どちらにもメリット・デメリットがあるでしょうから、そうするかもしれませんし、しないかもしれません。
ただし、少なくとも僕が「タスクシステム」と聞いてイメージするようなグローバルなリストに統合することは
無いでしょう。
>>「オブジェクトをコンテナに入れたら、それはもうタスクシステムだ」という
>>ことでしょうか？
...
> タスクシステムのような方言の多い設計技法の実装としては
> よく見かける気がするんですよね。
つまり、答えは yes ということですかね？そういうことなら「タスクシステム」などという不明瞭な
言葉は使わず、はじめから「コンテナ」と言って欲しいところです。
> それを指して「これはタスクシステムではない！」ってのは
> 正直に言うと得るところがないです。
何かを指して「これはタスクシステムではない！」などとは言ってません。
ただ、仕様に沿ってコンテナを用意しただけのコードを指して「これもタスクシステムですね？」などと
言われれば「知らんがな。何なの？」となります。
> コンテナが不要なデザインパターンみたいなものとか
そんなものを探すことに意味があるとは思いません。
- 66 名前：名前は開発中のものです。 mailto:sage [2011/03/03(木) 07:33:16.78 ID:o4mDyDkO]
- >>65
うーん、そういう結論かｗ
なんにせよ、つきあってもらってありがとね
- 67 名前：名前は開発中のものです。 mailto:sage [2011/03/03(木) 10:42:52.29 ID:S1R4ZHdy]
- >>59-60を読んでレスしようとしたことを、
俺がしようとしたよりまとめた形で>>61-62にレスされてて驚いたｗ
- 68 名前：名前は開発中のものです。 mailto:sage [2011/03/04(金) 18:49:09.34 ID:W65V8c4v]
- 過去ログみてたら、良いこと書いてあったので貼っとく
タスクシステムは嫌いだけど、ここにタスクシステムのメリットが示されてると思うわ
タスクシステム総合スレ part5
2chnull.info/r/gamedev/1234977661/874-880
874,880的な理由でタスクシステムを採用するのはありだと思う
ゲーム開発に最初から完成された仕様を求めるのは難しいからな
ただ、仕様が完成されている（面白さが実証されている）ゲームに対して
タスクシステムを採用しようという意見には賛成できないがね
- 69 名前：名前は開発中のものです。 mailto:sage [2011/03/04(金) 23:18:07.18 ID:Hcaww+pW]
- >>68
その場合は「タスクシステムを採用する(ｷﾘｯ」などとは言わずに、
「わりと何でも入るごった煮リストを予備で用意しとくよ。
設計に悩んで対応が間に合わなくなりそうだったら、とりあえず
ここに入れて済ませても良いよ。
でもなるべくデバッグ始まるまでには片付けるように考えてね。」と
正直に言って欲しい。さらに言えばそのごった煮リストにアクセスする
インターフェースのコメントに書いておいて欲しい。
- 70 名前：名前は開発中のものです。 [2011/03/05(土) 12:11:49.38 ID:3H1ntObt]
- 内容自体は別にいいとも悪いとも思わないんだけど
所詮設計手法であるにもかかわらず
タスクやらシステムやらたいそうな名前付けてるのに問題があるよな
- 71 名前：名前は開発中のものです。 mailto:sage [2011/03/12(土) 03:57:26.31 ID:/4EBtN3h]
- そもそも、さっき出てきた、敵やら弾やらは、ゲームオブジェクトであって、タスクではないだろ。
なのにタスクシステムとかいうから・・・もうそっからしていかれてる。
- 72 名前：名前は開発中のものです。 mailto:sage [2011/03/18(金) 19:52:37.70 ID:j/XYUi0c]
- ノンプリエンプティブなタスクです。
- 73 名前：名前は開発中のものです。 mailto:sage [2011/03/19(土) 22:04:55.48 ID:waQ7BrWH]
- SPUのようにメモリが共有できないプロセッサで有効な手法ってありますか？？
- 74 名前：名前は開発中のものです。 mailto:sage [2011/03/19(土) 23:11:19.21 ID:4X1JhQIF]
- >>73
問題も挙げずに手法もクソもあるか。
何が問題なの？それはこのスレに関係あるの？
- 75 名前：名前は開発中のものです。 mailto:sage [2011/03/20(日) 00:21:21.49 ID:0de+XUQH]
- お前が頭悪い
メモリが共有されてないのが問題だろ
タスクシステムは並列化でも関係あるし
- 76 名前：名前は開発中のものです。 mailto:sage [2011/03/22(火) 00:26:05.99 ID:XIrlBxPX]
- >>73
無い
- 77 名前：名前は開発中のものです。 mailto:sage [2011/03/22(火) 08:02:01.84 ID:sfNYTUX7]
- >>75
共有されてないメモリを何らかの「手法」で共有しちゃおうって話だったの？
そりゃ無理だｗ
- 78 名前：名前は開発中のものです。 mailto:sage [2011/03/22(火) 23:26:57.49 ID:IORdeWKB]
- あほか
- 79 名前：名前は開発中のものです。 mailto:sage [2011/05/06(金) 23:29:54.19 ID: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 名前：名前は開発中のものです。 mailto:sage [2011/05/06(金) 23:57:22.49 ID:4boNOk2w]
- >>79
タスクシステム関係なくね？スレ違いじゃね？過疎ってるからいいけど。
あとシングルトンは死ね。
- 81 名前：名前は開発中のものです。 [2011/05/07(土) 02:25:37.71 ID:FaGHlUhW]
- 燃料投下age
dixq.net/forum/viewtopic.php?f=3&t=8414
- 82 名前：名前は開発中のものです。 mailto:sage [2011/05/07(土) 13:19:43.23 ID:HQP20IoI]
- アマチュア発のオカルト怪文書だね
- 83 名前：名前は開発中のものです。 mailto:sage [2011/05/07(土) 16:42:34.61 ID:YeA8xK1G]
- >>79
並列処理はどうやって対応する？
- 84 名前：名前は開発中のものです。 mailto:sage [2011/05/07(土) 18:59:52.07 ID:9I/zjC76]
- >>83
foreachの並列化なんて超簡単じゃん。
- 85 名前：名前は開発中のものです。 mailto:sage [2011/05/16(月) 16:22:40.47 ID:6KFTtmqy]
- みんな、オンラインゲームを支える技術つまて本読んだ？
タスクシステムが紹介されてるな。
実際のオンラインゲームでも使われてるんだな。
- 86 名前：名前は開発中のものです。 mailto:sage [2011/05/17(火) 08:45:55.89 ID:rFUq1Hs1]
- 具体的に何が？ｗ
- 87 名前：名前は開発中のものです。 mailto:sage [2011/05/18(水) 18:02:54.11 ID:xlWxC1Wx]
- とりあえず買ってきたけど何頁だよ
- 88 名前： [―{}@{}@{}-] 名前は開発中のものです。 mailto:sage [2011/06/09(木) 07:44:43.82 ID:F833/hsX]
- タスクシステムってlistにオブジェクト突っ込んでイテレータでぐるぐる回しながら処理を実行させるだけのことだろ
- 89 名前：名前は開発中のものです。 mailto:sage [2011/06/09(木) 08:44:11.64 ID:/RZWOxKd]
- だから hibari.2ch.net/test/read.cgi/prog/1290878067/ でやれ
- 90 名前：名前は開発中のものです。 [2011/09/03(土) 21:11:50.72 ID:rKhpPrRf]
- タスクシステムか・・・なつかしいな
ゲームオブジェをどんな構造でまわすか、って悩むのはゲームプログラマなら
みんな通ったことのある壁の一つだよね。
最近は情報があふれてるからこの辺までは定石のお勉強で到達できるけど
ここから先が自分で考えられる人か教わらないとできない人か、の登竜門な感じ。
ゲームプログラマ向きじゃないのはここで詰まったまま脱落するんだよね。
まぁここを超えてももっと高い壁がまだまだ続くんだけどね・・・
- 91 名前：名前は開発中のものです。 mailto:sage [2011/09/04(日) 19:01:47.88 ID:F8LegbLJ]
- で「タスクシステム」を極めることが目的じゃない、と気付き、
使い回しの効く便利ルーチンをいくつか作るに止めるか、
なぜか目的を忘れてハマるか、という分岐があるんだけどね。
- 92 名前：名前は開発中のものです。 [2011/09/05(月) 04:56:06.83 ID:qHGk9if0]
- ゲームの仕様、開発言語、対象マシンのリソースと制限、納期とメンバーのスキル、etc...
タスクシステムの扱う範囲はゲームのコアアーキテクチャに関係してくる
最適解がコンテキスト依存な問題の典型。
これらコンテキストは作ろうとしているゲームによって千差万別だからネットで一般解を聞いても
ケースバイケースという一般論しか返ってこない。
さらに「タスクシステム」ってゲーム業界で慣習的に呼ばれてるだけで
実装はゲームによって全然別物。
ってことで結局サンプルソースとかで実装されてるタスクシステムと言われる
ものを参考にでもして作る予定のゲームにあわせて自分で考えて実装しろや、となる。
- 93 名前：名前は開発中のものです。 mailto:sage [2011/09/05(月) 23:02:25.18 ID:7BkdaPO7]
- そんで、あれ、もしかして、これ要らなくね？となる。
型ごとにリスト用意して、任意にforeach回すだけ。
- 94 名前：名前は開発中のものです。 mailto:sage [2011/09/06(火) 01:05:01.29 ID:4mf44gCT]
- >>93
レベル（ステージ）毎に必要な型のforeachを実行する関数を用意するわけか。
レベルデザイン時の柔軟性が失われないか？
もしくは全ステージで同じ型出すと、ステージ色が失われないか？
- 95 名前：名前は開発中のものです。 mailto:sage [2011/09/06(火) 06:56:47.84 ID:+MWn67Ig]
- コールバックさせるupdate関数の引数が固定になる方が柔軟性が損なわれる。
- 96 名前：名前は開発中のものです。 mailto:sage [2011/09/06(火) 09:34:01.98 ID:vhjBYDIv]
- そうだよな
必要な情報ってオブジェクトごと違うのにそこをわざわざ統一しちゃうのは
逆に必要な情報が関数みてわからなくなっちゃう
ホーミングミサイルで更新にターゲットが必要ならそれが必要な情報とわかるように
むしろ引数で明示するべき
その情報がなければこの関数は実行できないよと
これがプログラムの基本なんだよ
- 97 名前：名前は開発中のものです。 mailto:sage [2011/09/06(火) 19:39:44.89 ID:8sfW2Qro]
- 書泉でゲームプログラムフェアってのやってたから「何とかでつくるシューティング」とか
何冊か立ち読みしたら6冊中4冊でタスクシステムの説明とそれ使ったゲームがのってた。
PHPのやつとAVGの二冊はタスクシステムじゃなかった。
>>92
の言うようにC++とかJavaとかObject-Cとかで実装は別々だったけど、作るゲームにあってるなら
タスクシステム使って。
ポインタや参照使えない言語使う、とかタスクシステムが合わないゲーム作るならほかの方法で実装すれば
いいんじゃないかな。
- 98 名前：名前は開発中のものです。 mailto:sage [2011/09/06(火) 19:57:34.88 ID:4mf44gCT]
- >>95
書籍で紹介されているタスクシステムでは、個体情報を含むメモリブロックへの参照をメンバに含む
構造体ポインタを引数経由で渡して、個体情報特有の構造体にキャストしている。
むしろ何でもありで、情報のやり取りの柔軟性が損なわれることはない。
>>96
呼ぶ側は呼ぶことしか行わない方が、分かりやすい。
また例で言うとターゲットが存在しない場合の条件分岐を、呼ぶ側にしわ寄せ実装する必要が出てくる。
生存および消滅の過程や、何をターゲットにするかは、対象リストへの広域なインターフェースを用意して、
個体タスク内で自律的に行わせる。
基本と言い切るのは勇み足じゃないか？
- 99 名前：名前は開発中のものです。 mailto:sage [2011/09/06(火) 22:03:20.33 ID:vhjBYDIv]
- >>98
バッカ
全然関係ない
ちゃんと引数で渡すようにすれば何が何をやるべきかちゃんと見えてくる
なんにも見えないのは年がら年中そうやってオブジェクト同士の関連を面倒だからって
端折ってるからなにも分析できないなにも進歩しない
- 100 名前：名前は開発中のものです。 mailto:sage [2011/09/06(火) 22:58:45.25 ID:8sfW2Qro]
- 書籍にソースコードを全て載せるぐらい小さいゲームや、iphoneとかandroidのミニゲームみたいに
ゲームの状態推移がほとんどなくてゲームオブジェも簡単に全て把握できる、みたいなシンプルなゲームなら
タスクシステムのような単純な仕組みで実装する、って判断も十分合理的かと。
どんなアルゴリズムにしろアーキテクチャにしろ、適した用途と適さない用途はあるわけで。
>>99 がどんなハードでどんな仕様のゲームを想定してるのかは本人しかわからないけど
想定しているゲームの仕様には適さないと思うならタスクシステムじゃなくもっとそのゲームに適した仕組みで
実装するのが現実的だと思うけど。
- 101 名前：名前は開発中のものです。 mailto:sage [2011/09/06(火) 23:14:39.10 ID:+MWn67Ig]
- 型ごとにリストを用意して、
必要に応じてforeach回す方法の方がタスクシステムよりシンプルだよ？
引数も関数名も自由に決めれるし、
書いた順に実行されるから、
タスクシステムにありがちな、実行順のソートとかワケワカラン処理も要らないし。
タスクシステムってタスクを順番に逐次実行するんでしょ？
でもプログラムって放っておいても逐次実行だよ？
void do_tasks(){ task1(); task2(); }
って書いとけば、それそのものがタスクのリストだよ？
わざわざ動的にタスクのリストを用意して逐次実行する意味ってあるの？
それじゃまるでインタプリタやVMだよ。それも碌な制御構造もない貧弱で直線番長な。
- 102 名前：名前は開発中のものです。 mailto:sage [2011/09/06(火) 23:20:56.58 ID:+MWn67Ig]
- 折角C言語やC++にはif文やらなんやらの立派な制御構造があるのに、
タスクシステムだと、タスクを前から順番に実行することしか出来ないから、
言語の持つ折角のメリットを殺しちゃうことになるんだよ？
update関数の引数が固定になっちゃって、これも言語の機能を殺すことになるよ？
動的にタスクのリストを用意するから、
ソースコードを読んだだけではタスクの実行順が分からないってのもマイナスだね。
わざわざそんな茨の道を行く必要は無いんじゃないの？
- 103 名前：名前は開発中のものです。 mailto:sage [2011/09/06(火) 23:55:38.12 ID:8sfW2Qro]
- ＞タスクシステムにありがちな、実行順のソートとかワケワカラン処理も要らないし。
上であげてるゲームでは実行順のソートとかワケワカラン処理は必要ないケースだし
＞update関数の引数が固定になっちゃって、これも言語の機能を殺すことになるよ？
単純なゲームだから引数にコンテキスト渡すだけで解決。
＞ソースコードを読んだだけではタスクの実行順が分からないってのもマイナスだね。
ソース2〜3個で完結してるようなゲームだし、普通のプログラマなら十分把握できるでしょ・・・
あと、タスクだと敵出現のシーケンスは、データ読んでその種類のタスク生成してくっつけるタスクの原理を
うまく使ったシンプル実装。
これを逐次駆動でタスクよりシンプルに実装できるのかな？
タスクの方法より短くシンプルなコードでSTGの弾、エフェクト、敵AI切り替え、ボス、敵のシーケンス化、等々を
実装できるのならその方法でもいいかもしれないけど・・・
書籍のサンプルでは上記全てタスク実装で1個のソースにして綺麗にまとまってたから、逐次ベタ書きで
これよりシンプルに短くこの仕様全て実装するのは難しいと思うけど。
STGのサンプルの大多数タスクシステムを採用してるのはそれなりに合理的な理由があると思うよ。
- 104 名前：名前は開発中のものです。 mailto:sage [2011/09/07(水) 00:11:57.19 ID:2Lv+in6p]
- 実行順のソートが必要ないなら、なおさら動的にタスクリストを持つ必要ないじゃん。
ソースコードにベタでtask1(); task2(); task3()って書いてけよ。
なんども言うけど、ベタで書いたほうが、タスクシステムよりよっぽどシンプルなんだ。
型ごとにリスト用意して、必要に応じてupdateってのは、
名前すら付いていないほど、普通に考えりゃそうなるだろうってやり方。
だから、単純さを武器にタスクシステムを薦めるのは可笑しい。
タスクシステムは、最終ビルド後、製品出荷後で、
後からプログラムを拡張したいときなんかに使われるような、それなりに高度なやり方。
プラグインやMODやドライバなんかで使われる手法。
その必要も無いのに使うものではないんよ。乱用なんよ。コールバックの乱用。
- 105 名前：名前は開発中のものです。 mailto:sage [2011/09/07(水) 00:20:37.44 ID:2Lv+in6p]
- list<弾*>弾リスト; list<エフェクト*>エフェクトリスト; list<敵*>敵リスト、list<ボス*>ボスリスト;
foreach( 弾リスト ) { update( 弾 ); }
foreach( エフェクトリスト ) { update( エフェクト ); }
foreach( 敵リスト ) { 敵->AI(); }
foreach( ボスリスト ) { ボス->シーケンス(); }
な？簡単だろ？
型情報も殺さないし、引数も自由だ。
- 106 名前：名前は開発中のものです。 mailto:sage [2011/09/07(水) 00:27:04.18 ID:2Lv+in6p]
- 複数処理を型に跨って順不同に呼ぶことだって出来るぜ？
foreach( 敵リスト ) { 前処理( 敵 ); }
foreach( 弾リスト ) { 前処理( 弾 ); }
foreach( 敵リスト ) { 敵->AI(); }
foreach( 弾リスト ) { update( 弾 ); }
foreach( 敵リスト ) { 後処理( 敵 ); }
タスクシステムだと言語本来が持つ制御構造を殺しちゃってるから、
こう言うことが難しい。
- 107 名前：名前は開発中のものです。 mailto:sage [2011/09/07(水) 00:31:43.66 ID:2Lv+in6p]
- 敵->AI();とか書いちゃったけど、実際には
敵->AI( 敵 ); だな。ごめんごめん。
ついでに。
foreachを多重ループにすれば、相互作用の記述も簡単。
タスクシステムですると破綻しかねん処理だ。
foreach( 敵リスト ) //二重ループ
foreach( 弾リスト )
{
当たり判定とか相互作用的なもの( 弾, 敵 )
}
- 108 名前：名前は開発中のものです。 mailto:sage [2011/09/07(水) 00:59:04.96 ID:2Oz0OCTe]
- 逐次実行の書き方って...本気でこのコードでゲームを最後まで書くっていってるの...？
まぁこー書かないとコード追えないって言ってるから、しょうがないのかもしれないけど...
タスクシステムで実装されたSTGゲームは書籍なりネットなりでいろいろコードみれるけど
この方式で最後まで完成したちゃんとしたSTGのコードって今まで一つも見たことないな。
論より証拠で、どんなものになるかぜひ完成したものを見せてほしいな。
- 109 名前：名前は開発中のものです。 mailto:sage [2011/09/07(水) 01:02:00.30 ID:2Lv+in6p]
- 一応書いておくと、話題に挙がった、タスク = ゲームオブジェクト なタスクシステムのほかに、
タスク = 純粋な処理 なタスクシステムもある。
一見良さそうだけど、種類の違うタスクを同じコンテナに混ぜ込んじゃうから本質的には何も変わらない。
コンテキストが必要なタスクの場合、
タスクのコンテキスト構造体を作って型ごとにリストで管理。
foreach( タスク1のリスト ){ タスク1の処理( タスク1 ); }
foreach( タスク2のリスト ){ タスク2の処理( タスク2 ); }
コンテキスト不要なタスクの場合、タスク=関数。
foreach( 敵リスト ){ タスク1( 敵 ); }
foreach( 敵リスト ){ タスク2( 敵 ); }
こうした方が良い。
- 110 名前：名前は開発中のものです。 mailto:sage [2011/09/07(水) 01:06:48.32 ID:njRzaK7Q]
- >>108
なんでゲームやSTGに限ろうとするの？
ほとんどのアプリが、型ごとにリスト持ってて、必要に応じて更新ってスタイルだよ？
- 111 名前：名前は開発中のものです。 mailto:sage [2011/09/07(水) 01:14:01.19 ID:8h9D8UMl]
- >>109
前スレより随分と解りやすくなった
- 112 名前：名前は開発中のものです。 mailto:sage [2011/09/07(水) 01:17:49.74 ID:AZsoDlPL]
- 4mf44gCTだけど、みんなのエネルギーもらってるみたいで楽しいよ。
>>99
繊細なんだな。俺は煽るつもりはなかったんだ。
>>101
＞必要に応じてforeach回す方法の方がタスクシステムよりシンプルだよ？
いずれにせよ個体の種類と量が増えると、人間の頭ではワケワカメになると思うんだが。
解決策としては、むしろ以下の方針で、ソースの透明性確保の努力をするべきじゃないか？
１）呼ぶ側の構造をできるだけシンプルにする。
２）個体の状態の両端末、すわなち生存・消滅に関わるメカニズムを統一して単純化にする。
３）個体同士の相互作用のメカニズムを統一して単純化する。
上の方針を守っている限り、柔軟性のあるいわゆる「タスクシステム」の方が有利だと思うんだが。
- 113 名前：名前は開発中のものです。 mailto:sage [2011/09/07(水) 01:18:43.81 ID:AZsoDlPL]
- >>106
＞タスクシステムだと、タスクを前から順番に実行することしか出来ないから、
＞言語の持つ折角のメリットを殺しちゃうことになるんだよ？
＞update関数の引数が固定になっちゃって、これも言語の機能を殺すことになるよ？
言語の「メリット」「機能」というのが曖昧だな。
本質ではないかもしれんが、>>106をみると敵クラスについて、前処理、AI、後処理と分けていて、非常に複雑な印象を受ける。
このように分ける必然性がわからない。
むしろハードコーディングにより、このように分けてしまうと柔軟なレベルデザインの妨げになるような予感がする。
あと誤解しているが、書籍などで紹介されている「タスクシステム」は、タスク登録時に優先順位（Priority）により各個体の実行順序を制御できる。
だから実質的に、同種の個体で実行順序をグループ化することも可能だ。つまりこれまでID:+MWn67Ig / 2Lv+in6pが提起している「制御構造」の問題は解決されている。
- 114 名前：名前は開発中のものです。 mailto:sage [2011/09/07(水) 01:31:29.34 ID:2Oz0OCTe]
- >>110
なぜタスクシステムを使うべきでないケースでタスクを使うことを考えるんだろう...
>>100 の前提のとおり、タスクシステムにしろどんな仕組みにしろそれを使うケースは
それが合理的なケースだけ、というのは当然でしょう。
なにか否定している理由は合理的な考えから出たものとは違うみたいなので
これ以上続けても意味のある結論は出なさそうですね...
- 115 名前：名前は開発中のものです。 mailto:sage [2011/09/07(水) 01:35:34.18 ID:njRzaK7Q]
- これはもう石頭でどうしようもない。物事を勘違いしたまま突き進んじゃってる。
>いずれにせよ個体の種類と量が増えると、人間の頭ではワケワカメになると思うんだが。
ワケワカにならないように、違った型のオブジェクトを同じリストに突っ込まないようにするわけで。
ワケワカでOKってことはないでしょ？
>敵クラスについて、前処理、AI、後処理と分けていて、非常に複雑な印象を受ける。
>このように分ける必然性がわからない。
敵クラスの前処理とAI処理の間に、他クラスの別処理が入ってるのが味噌。
一回ずつオブジェクトをupdateでなめなめして、それで全ての処理が終わるとは限らないだろ？
>タスク登録時に優先順位（Priority）
それは、違った型のオブジェクトを同一のリストに入れるから必要になる仕組みであって、
苦肉の策であることを分かって言ってるのか？
そしてそんな貧弱な制御構造で、言語本来の制御構造と対等に立てるとでも？
- 116 名前：名前は開発中のものです。 mailto:sage [2011/09/07(水) 01:46:07.51 ID:njRzaK7Q]
- >１）呼ぶ側の構造をできるだけシンプルにする。
物事は上流で解決した方が良い。
>２）個体の状態の両端末、すわなち生存・消滅に関わるメカニズムを統一して単純化にする。
言ってる意味が良く分からんが、あえてエスパーすると、メモリアロケートの話ならアロケーターの仕事。
>３）個体同士の相互作用のメカニズムを統一して単純化する。
上流(メインループ部)を直接改造できる状況下においては、
相互作用は上流でするべき。
>>114
逆にタスクシステムを使うべきケースって何？
ああいったコールバックシステムは、
上流部が固定されている場合だけだと思うんだけど。
ゲームはメインループ部を自由に触れるよね？
リリース前なんだから。
- 117 名前：名前は開発中のものです。 mailto:sage [2011/09/07(水) 01:46:51.37 ID:AZsoDlPL]
- >>115
おい、煽るなよｗ
＞ワケワカ
>>116のような記述がズラーーーーーーと並んだら、ワケワカメになるとは思わないか？
俺はそうなる事態を予見して、解決策を提案したんだが。
＞敵クラスの前処理とAI処理の間に、他クラスの別処理が入ってるのが味噌。
率直に言うと、複雑な相互作用メカニズムになっているという気がするな。
＞そしてそんな貧弱な制御構造で、言語本来の制御構造と対等に立てるとでも？
例で示されている要件は、タスクシステムでもクリアされているんじゃないか。
もっと「言語本来の制御構造」のメリットが出ている例を挙げてもらいたいな。
所詮は場末の小競り合いだ。
落ち着いて逝こうぜ。
- 118 名前：名前は開発中のものです。 mailto:sage [2011/09/07(水) 02:02:46.60 ID:njRzaK7Q]
- >>117
>>116のような記述がズラーーーーーーと並んだら、ワケワカメになるとは思わないか？
そこにズラーーーと書いてあることが、格ゲームオブジェクトのupdate関数に移るだけだから同じこと。
むしろ、分散されて余計わけが分からなくなる。
>率直に言うと、複雑な相互作用メカニズムになっているという気がするな。
あえて例で上げたまでだからね。
だけど、一回のupdateで全ての更新が終了するとは限らないだろ？
>例で示されている要件は、タスクシステムでもクリアされているんじゃないか。
二回のupdateが必要な場合はどうするの？
a->update1(); → 何かの処理 → a->update2();
C言語本来の制御構造なら、やりたいことをやりたい順で書けば済む。
タスクシステムだと、タスクシステムの仕様に制限される。
|
 |
