- 1 名前：名前は開発中のものです。 [2010/10/01(金) 19:54:53 ID:ZGMtyIlk]
- タスクシステムで〜す。
- 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言語本来の制御構造なら、やりたいことをやりたい順で書けば済む。
タスクシステムだと、タスクシステムの仕様に制限される。
- 119 名前：名前は開発中のものです。 mailto:sage [2011/09/07(水) 02:10:21.64 ID:AZsoDlPL]
- >>116
＞物事は上流で解決した方が良い。
上流のフローは、単純でなければいけない。
その解決策は、先に書いた通り。
＞>２）個体の状態の両端末、すわなち生存・消滅に関わるメカニズムを統一して単純化にする。
＞言ってる意味が良く分からん
生存＝個体がタスクリストに登録されている状態
消滅＝個体がタスクリストに登録されていない状態
＞相互作用は上流でするべき。
詳しく。
レベルデザインの足かせとならないか？
＞逆にタスクシステムを使うべきケースって何？
確実に言えるのは、メモリリソースが希少な場合だろう。
＞ゲームはメインループ部を自由に触れるよね？
そんなに簡単にいじれるかな？
どんな触り方を言ってるのん？
- 120 名前：名前は開発中のものです。 mailto:sage [2011/09/07(水) 02:21:42.40 ID:AZsoDlPL]
- >>118
＞一回のupdateで全ての更新が終了するとは限らないだろ？
これ具体例教えてもらえないか？
ところで（書籍ででている）タスクシステムでも、（この議論の流れでは反則になるかも知れんが）
ちょっといじれば各個体にupdateを2つ持たせることは可能だぜ。
優先順位を2つ持たせることも可能だ。
メインループで登録リストを2回なめることになるが。
- 121 名前：名前は開発中のものです。 mailto:sage [2011/09/07(水) 05:53:24.18 ID:P+KLPKHG]
- ひさしぶりにタスクシステムな人が来たみたいだな。
まずは >>2-4 あたりを読んで、それでもまだ何か言いたいんなら、まぁがんばって。
- 122 名前：名前は開発中のものです。 mailto:sage [2011/09/07(水) 08:11:32.13 ID:BWfYxSne]
- >>105
俺はお前を支持する
こっちのほうが１０００倍楽
タスクシステムの起こすバグはハンパじゃない
- 123 名前：名前は開発中のものです。 mailto:sage [2011/09/07(水) 08:21:53.19 ID:BWfYxSne]
- >>105に書いてある内容は本来書き並べないといけない処理なんだよ
必要に応じてわかりやすい単位で関数に分けることは必須だけど
これをタスクシステムにしたら実行しないとこの順番がわからないとか
開発がホント酷いことになる
派遣で色々と会社まわったけど
タスクシステムを使わないところはバグの数が１０分の１ぐらいだかんね
タスクシステム使ってるようなところはバグ数がプロジェクトで３万（万？はぁ？）とか
明らかに数字がおかしい
- 124 名前：名前は開発中のものです。 mailto:sage [2011/09/07(水) 12:09:48.38 ID:Cw/CE0Hp]
- もともとはアセンブラ時代のテクニックだろうよ
CPUやメモリ資源もない時代。
１．ゲームオブジェクトを統一的に扱う。
２．アラインメントを考慮したメモリにやさしい固定長のオブジェクト
３．固定長のオブジェクトを柔軟に扱うためのプロセスアドレスの保持
今の時代は
１は継承で可能。２は資源的にちっとやそっとの無駄は気にしない。
３は今で言うところのメンバ関数とか関数ポインタ。
- 125 名前：名前は開発中のものです。 mailto:sage [2011/09/07(水) 12:39:30.24 ID:njRzaK7Q]
- 今の時代なら、
>１．ゲームオブジェクトを統一的に扱う。
はテンプレートでしょ。
- 126 名前：名前は開発中のものです。 mailto:sage [2011/09/07(水) 17:13:02.56 ID:V+dkRM26]
- ジョブコンの説明を確認すればわかるが、非常に単純化されたコルーチンのようなものの
メカニズム、というのが元の姿。
- 127 名前：名前は開発中のものです。 mailto:sage [2011/09/07(水) 20:57:18.96 ID:njRzaK7Q]
- 違った種類のジョブを単一リストで管理する理由はないね。
上流の呼び出し部分が出来合いのもので、
改変が許されないのなら別だが。
- 128 名前：名前は開発中のものです。 mailto:sage [2011/09/08(木) 01:34:35.91 ID:lvpyEMH1]
- タスクシステム大佐：
「私のフレームワークはデリケートにチューニングされている」
- 129 名前：名前は開発中のものです。 mailto:sage [2011/09/08(木) 01:44:22.92 ID:IMtv8g35]
- 違った種類のモンを一端混ぜておいて、
場合によっちゃあ後から分別するんだから間違ってる。
別に扱いたいのなら、別に持っておけば十分だし簡潔。
- 130 名前：名前は開発中のものです。 mailto:sage [2011/09/10(土) 09:54:25.43 ID:10z5xUck]
- >>92 で言ってることが全てなんだろうな
メンバーのスキルが「型固定で全てのフローをコードに直書きしないとソースが読めない」
みたいなレベルの場合はタスクシステムとか関数ポインタ使うとバグだらけで完成しないだろうし。
その場合はタスクシステムは使わないのが正解だろう。
Unreal Engine等の近頃のメジャーなゲームフレームワークの場合はタスクやアクターを使っていて
「敵やアイテムを型固定にしてコードに直書き」なんて作りはありえないけど
プロじゃなくて同人とかなら無理してスキルに合わない方法を背伸びして使わずに
自分のスキルで使える範囲の言語のフロー構造だけで作る、という結論は間違っていない。
- 131 名前：名前は開発中のものです。 mailto:sage [2011/09/10(土) 23:52:59.57 ID:h48cNNb3]
- タスクシステム = 上級者用 ？？？
これはこれは。
- 132 名前：名前は開発中のものです。 [2011/09/11(日) 00:03:27.99 ID:Y7Irx4Sl]
- タスクシステムが上級者用なんて、まさかwww
タスクシステムなんてゲームプログラマなら使えて当然の基礎中の基礎。
ただそんな単純な仕組みでも、つかうと手に負えなくなってバグが直せない、
みたいな超初心者なら、もっと単純な方法で作るのが正解だ。
hello worldの次のステップのプログラマならifとswitchだけ、ぐらいで
つくるのが適切。
- 133 名前：名前は開発中のものです。 mailto:sage [2011/09/11(日) 00:07:30.68 ID:AdyJz/xc]
- 俺はタスクシステムに逃げちゃう設計者は根性がないと思うけどね
この構造がダメなのはみんなうすうすわかってんだよ
- 134 名前：名前は開発中のものです。 mailto:sage [2011/09/11(日) 00:41:24.97 ID:P9u9NThf]
- >>132
> タスクシステムなんてゲームプログラマなら使えて当然の基礎中の基礎。
ということにしたいのですね。 >>3
- 135 名前：名前は開発中のものです。 mailto:sage [2011/09/11(日) 00:47:43.20 ID:Y7Irx4Sl]
- >>97 のようにタスクシステムを使って最後まで完成されたゲームは
沢山あるから書籍にしろネットにしろタスクシステムのサンプルには困らん。
完成してゲームという最終成果が出ている以上、そのゲームで必要な機能は
満たしているわけだし。
根拠が「根性」で出せるサンプルが foreach〜だけ、みたいなのよりかは
採用するにしろしないにしろ、タスクシステムの例の方が参考価値がある。
ゲームを完成させたこともない人の言う「みんながうすうす」って言葉には
正直言ってこれを覆すだけの説得力が無い
- 136 名前：名前は開発中のものです。 mailto:sage [2011/09/11(日) 00:53:21.53 ID:P9u9NThf]
- >>135
「タスクシステム」と言って具体的に何のことを指してるのかよくわからないから、
ネットのほうの「タスクシステムのサンプル」をいくつか URL で示してもらえませんか？
- 137 名前：名前は開発中のものです。 mailto:sage [2011/09/11(日) 00:57:39.18 ID:Y7Irx4Sl]
- >>136
>>92 を見ればその答えがわかると思うね。
その上で疑問に思うことがまだあるなら個別にコンテキストを明示
して聞かないと無意味。
- 138 名前：名前は開発中のものです。 mailto:sage [2011/09/11(日) 01:03:39.39 ID:P9u9NThf]
- >>137
つまり「タスクシステム」と言って指しているものは具体的にはわからんし状況によって変わりうる、
ということでしょうか。そんなもの役に立ちませんし「基礎中の基礎」だなんて具体的な技術である
かのように言えるわけないですね。なんかおかしいですね。
- 139 名前：名前は開発中のものです。 mailto:sage [2011/09/11(日) 01:14:44.40 ID:Y7Irx4Sl]
- 現実的に多くのゲームで「タスクシステム」と命名されてる構造が使われてるわけだ。
それを「共通じゃないから無意味」と結論するのは勝手だけどその行為もまったく無意味。
参考になるかどうか、現状のコンテキストから判断して適切に参考にして
作るゲームに役立てることの方がはるかに有意義。
- 140 名前：名前は開発中のものです。 mailto:sage [2011/09/11(日) 01:40:32.06 ID:+CByEq1T]
- >>138
書籍などで紹介されているもは、タスクシステムの一般化された形態であり、
あとはアーキテクトが、場合に応じて、一般化形態から出発して特殊化するんじゃないかな。
一つのキャラを完成させるために上流も下流もいじる必要があるとなったら、
それこそ到達点が低くなる。
力を注ぐ必要のある要素は、キャラの基本的な出現消失の管理以外に一杯ある。
出来るだけ、いじらなきゃいかんソースの場所減らそうって目的で、
メインループ内を抽象化したのがタスクシステムじゃないか。
一方、上流のタスクシステムのアーキテクチャを改修すれば、当然、下流側への影響は絶大なわけで、
>>133は、ヘッポコアーキテクトが、途中で無責任改修やっちゃった事例なんじゃないか？
そんな奴はフレームワークに何使っても、むしろ何をやってもｗ上手くいかないんじゃないかと想像が膨らむ。
- 141 名前：名前は開発中のものです。 mailto:sage [2011/09/11(日) 01:42:27.37 ID:P9u9NThf]
- >>139
そういって自作コンテナや自作アロケータや無茶なキャストを下手に参考にされる人が
後を絶たなくて困るんですが、あなたのいう「タスクシステム」がそういうクソの山とは違うと
いうのなら >>136
- 142 名前：141 mailto:sage [2011/09/11(日) 01:44:12.94 ID:P9u9NThf]
- 「後を絶たなくて」は言いすぎですね。今ではだいぶ稀になってますね。
- 143 名前：名前は開発中のものです。 mailto:sage [2011/09/11(日) 01:48:03.10 ID:Y7Irx4Sl]
- >>141
＞そういって自作コンテナや自作アロケータや無茶なキャストを下手に参考にされる人が
書籍や何かでいくらでも簡単に手に入るサンプルをみても全てクソだと思うなら
君がゲームの仕様に適したもっと適切な構造で実装すればいいだけだ。
「僕にはアーキテクトを決める権限は無いけどタスクシステムと命名されたクソしすてむ
で作らされたおかげでバグだらけ（涙）」って愚痴ならご愁傷様としか言えんが。
- 144 名前：名前は開発中のものです。 mailto:sage [2011/09/11(日) 01:53:19.19 ID:b4z41GvT]
- タスクシステムを一般的に語るなら、要はCなどの構造化言語がgotoを封じたもんだから、それに代わる状態遷移方法が必要なわけ。
そこでメインループというものを一般化し、キー入力イベント、敵の動き、当たり判定などの処理のセットを入れ替えることで状態遷移を可能とした。
でもgotoと同じく各状態への遷移が自由なためにスパゲッティになりやすい。
- 145 名前：名前は開発中のものです。 mailto:sage [2011/09/11(日) 04:26:51.67 ID:ZZ/mHUa2]
- タスクシステマーのレベルが下がってきてるな。
そもそも、
update(){ task1(); task2(); }と処理を静的に書き並べていくことと、
実行時にタスクのリストを動的に生成して、逐次実行することに、
構造的な差はあまり無い。
ただ、後者は言語の持ってる型や制御構造といった機能を殺す。
アセンブラ時代に考えられたものだから、高級言語との相性は考えられてない。
- 146 名前：名前は開発中のものです。 mailto:sage [2011/09/11(日) 13:02:01.02 ID:YqmjwGNN]
- >>144 ご大層なもん作らんでも、ごく普通のステートマシンの実装法でいいだろ
|
 |
