タスクシステム

1 ：10/10/01 〜 最終レス ：11/11/23

タスクシステムで〜す。

2 ：

古典タスクシステム（このスレでは「>>2」と呼ぶ）
White Paper - Programming
http://homepage3.nifty.com/moha/programming.html
タスクシステム
http://www5f.biglobe.ne.jp/~kenmo/program/task/task.html
CodeZine：本格的なシューティングゲームを実現するタスクシステム（タスクシステム，シューティング，ゲーム）
http://codezine.jp/a/article.aspx?aid=297
Logician Lord　…　【コンピュータゲームのからくり】
※ウェブアーカイブのキャッシュ
http://web.archive.org/web/20041009222313/www.hh.iij4u.or.jp/~peto/Games/games_top.html
タスクシステムのご先祖の「ジョブコン」は
http://game.2ch.net/gamedev/kako/1006/10061/1006184421.html の 810

3 ：

http://ja.wikipedia.org/wiki/%E8%A3%B8%E3%81%AE%E7%8E%8B%E6%A7%98
あらすじ
新しいシステムが大好きなゲームプログラマの元に、二人組の詐欺師が
プロのゲーム開発者という触れ込みでやって来る。
彼らは何と、馬鹿や自分にふさわしくない仕事をしている者にはメリットが
理解できない不思議なシステムを紹介してくれるという。
プログラマは大喜びで紹介されたとおりに実装する。
他のプログラマにメリットを聞かれた時、自分がこれまで慣れ親しんだ
コードを正当化してくれるはずのメリットが説明できない。プログラマは
うろたえるが、そのシステムを自慢げに見せた後輩プログラマたちの手前、
本当の事は言えず、ありもしないメリットから目をそらさせるため
「馬鹿には理解できない」と言い続けるしかない。後輩は後輩で、自分には
メリットが理解できないもののそうとは言い出せず、空気を読んで目をそらす。
プログラマはメリットもないシステムに増築を重ねて開発終盤に臨む。
火消しプログラマも馬鹿と思われてはいけないと同じようにそのシステムを
使い続けるが、その中のまだ空気を読めていなかった新入りが、こう叫ぶ。
「このシステム邪魔だよ!」

4 ：

>>1が過去をなかったことにしたがってるので過去スレ一覧1でも張っておくか
タスクシステムについての議論、相談、質問、雑談などのスレです
part9 http://pc11.2ch.net/test/read.cgi/gamedev/1260695466/
part8 http://pc11.2ch.net/test/read.cgi/gamedev/1250678891/
part7 http://pc11.2ch.net/test/read.cgi/gamedev/1241670786/
part6 http://pc11.2ch.net/test/read.cgi/gamedev/1238725539/
part5 http://pc11.2ch.net/test/read.cgi/gamedev/1234977661/
part4 http://pc11.2ch.net/test/read.cgi/gamedev/1233459490/
part3 http://pc11.2ch.net/test/read.cgi/gamedev/1226199100/
part2 http://pc11.2ch.net/test/read.cgi/gamedev/1196711513/
part1 http://pc11.2ch.net/test/read.cgi/gamedev/1173708588/
・タスクと呼ばれる実装は、非常に多岐に渡ります
　古典タスクシステムについての話題は「>>2」と明示してください
　そうでない場合はカスタム版であることを明示してください
・人を憎んで言語を憎まず

5 ：

タスクシステム最高や！

6 ：

>2をチラ見しただけだが、主人公や敵やアイテムを同一の抽象クラスの継承で作って、
抽象クラスの配列で全部を管理する、ってのはタスクシステムとやらにあたるのか？
だとしたら俺は知らずに使ってたな。

7 ：

なんかロクな資料が無いな。>>2

8 ：

んじゃ、納得できるまともな資料ないのかよ

9 ：

タスクシステムを理解はできるが
特に新しくもない、びっくりすることもない、普通の汎用システムかなと思った
今のゲームでは０フレーム割り込みや、指定したタスクの削除、優先順位の変更とかが加わってるから　ここの資料は古い

10 ：

普通て

11 ：

>>9 ごった煮リスト使いが何を偉そうに(ﾌﾟ

12 ：

実行単位を抽象化したもの

13 ：

基本的概念は今でも通じる
しかし抽象化が人によって１００人１００通りあって、ののしりありの状態
これでは発展しない
まとめ役が必要ではないだろうか

14 ：

>>11
のように人格非難を行い、人権尊重を行わない環境では前向きな議論ができない
似たようなものに、ジョブやタスクなどあるが、これらを参考に１００％ではないが、納得できる抽象的にコード化できる人物が必要ではないか
そして、オープンソースにすることによって、より多くの人に使ってもらえて、さらなるフィードバックが行われ、より改善されていくのではないだろうか
今までは、タスクを一定の決まった業務名で決めきっていたが、今は抽象化というあいまいな言葉で表現するので、なかなか理解されにくい
おそらく C,アセンブラ時代のシステムと思われるが、メモリが大量に使えるようになった今ではもっと応用できるようになるのではないだろうか

15 ：

＼　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　／
　 ￣￣￣￣￣￣￣￣￣￣￣∨￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
　　　　　　　　　　　　　　　 　＿＿＿_
　　　　　　　　　　　　　　　／　　 　 　＼
　 /＼＿＿_／＼　　　..／ ⌒　　　⌒　 ＼
／　／　　 　ヽ ::: ＼ ／ 　（●）　（●） 　　＼
|　（●）,　、（●）、　||　 　　（__人__）　　　　　|　
|　　,,ノ(、_, )ヽ、,, 　 |＼　　 ｀ ⌒´ 　　　　_／　
|　　　,;‐＝‐ヽ 　 .:::::| 　|　　　　　　　　　　 ＼
＼　　｀ニニ´　 .:::／ 　.|　|　　　　　　　　 | 　|
／｀ー‐--‐‐―´´＼―┴┴―――――┴┴――――
　 　　　　 .ｎ:n　　　 ｎｎ　　 　
　 　 　　nf|｜| 　　　| | |^!n 　 ＿|＼∧∧∧ＭＭＭＭ∧∧∧／|＿
　 　 　　ｆ|.| | ∩　　∩|..| |.| 　 ＞　　　　　　　　　　　　　　　　　　＜
　 　 　　|: ::　 ! }　　{！ ::: :| ＜　　　　　NO THANK YOU　　　　 ＜
　 　　　 ヽ　　,イ 　　ヽ　:イ　 .＞　　　　　　　　　　　　　　　　　　＜
　　　　　　　　　　　　　　　　　￣|／∨∨∨ＷＷＷＷ∨∨∨＼|￣

16 ：

>>14
「ジョブ」や「タスク」は std::fucntion (boost::function) に、
それを集めたコンテナは std::list や std::map に抽象化および汎用化
されているだろ。しかもオープンソースで。仕様も明確に文書化されて
おり、関連情報も Web 上に関連情報もたくさんある。結果、もっと応用
できるようになっている。
これでもまだ何か問題ある？

17 ：

歴史は繰り返すｗ

18 ：

>>16
それをつかったタスクシステムを早く見せてみろ。
能書きはいいから早くやれ。

19 ：

>>18
それが人にものを頼む態度か？

20 ：

>>18 typedef std::function Task; typedef std::multimap<int, Task> TaskSystem;

21 ：

>>20仮想関数よりおせえぞ、このカスが。

22 ：

>>21
http://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 ：

レスが遅いっていう意味じゃないのか

24 ：

うおーおちるｗｗｗ

25 ：

落ちていいんじゃない

26 ：

保守

27 ：

燃料投下age
http://d.hatena.ne.jp/alwei/20110117/1295290033

28 ：

いってみたらすでに論破されてた

29 ：

名前からして不明瞭。
そこに嫌な匂いを見出せるのは、
ある程度苦労したプログラマ。

30 ：

これが島国さんやnyaxtさんの書いた記事だったりすると反応違うんだろうなｗ

31 ：

ゲーＰＧはネームバリュー（ハッタリ）に弱い人間少ない気がする
むしろ、俺がそいつを粉砕してやるぜ的な

32 ：

PCエロゲ界の貴公子の近代的〜が唯一の参考文献としてあげられてるのは
「私の話は眉に唾をたっぷり塗りたくってから読んでください」というシグナルだろ
メモリアロケーションとタスクコントロールの都合をゴチャ混ぜにしてる時点で
ウェブ上に幾度となく流布されてきたアマチュア発の怪文書の仲間入り

33 ：

いいかげんCEDECで白黒はっきりすべき
なぁなぁで適当なセッションばっかやってるんじゃねーよ

34 ：

このぐらいのトラップはあったほうがいい

35 ：

理解はできるが　それほどはしゃぐほどのしろものじゃぁないと思う　＞　タスクシステム

36 ：

いやそれじゃまったくわかってない

37 ：

アセンブラレベルで組んでたら当然このようなシステムになると思う　＞　タスクシステム

38 ：

なので、今の１G単位のファイル扱い時代には、>>3 にあるとおり邪魔すぎる
しかも >>2 のリンク先のとおりに組んでたら１００％環境に依存したものができるね
構造化設計がきちんとできれば、別に困らない

39 ：

ちょっとしたところを書かせても、
ちょっと見通しよく書いてくれる人と、
ちょっと見通し悪く書いてしまう人が居るね。

40 ：

元々はアセンブラレベルで簡単なコルーチンを実現するシステムだった（ジョブコン）。
いつのまにやら、C言語で実装されコルーチンではなくなって、コールバック管理システムになり、
いろいろごてごてと御利益の能書きが追加された。

41 ：

まだ根絶はされていないようだ。
http://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 ：

>>41
いっぱいいるね

43 ：

これはひどい

44 ：

ツイッターは宮崎県の東国原元知事でもやってる

45 ：

タスクシステム、っていう名前からして臭いわな。
便利なフリした機能の癒着やごった煮を連想させる。

46 ：

ツイッターやってる一般人ってキモイよな

47 ：

ツイッターやってる一般人がというか、たいした情報でもないのに情報発信源気取りでしゃべってるのがキモいんだと思う。
あまつさえ斜め上の内容だからなおさら。

48 ：

タスクシステムとまったく関係のないやりとりをする　こいつらがキモイ

49 ：

>>48
そう？

50 ：

もはや根絶の時期がメインの話題になるぐらいのものでしかない。

51 ：

てか、まだ使ってる人居るのかネェ。
だいたい、プログラム自体が処理を実行順に並べたもの「そのもの」なんだから、
自前で処理リスト持って、毎フレーム逐次実行する意味が分からないよな。
まるでバーチャルマシンじゃん。
void do_tasks(){ task1(); task2(); task3(); /*←タスクリスト*/ }
↑こんなん作っておいて、毎フレーム呼びだしゃ良いだけだもんなぁ。

52 ：

バカはつかわなくていいよ

53 ：

みんなでプログラムしようぜ　とみんながやる気になる
みんなでいろいろな意見が出され、いろいろ議論される
とても活発、いろんなスレがたてられる
実際につかわれはじめ、みんな期待する
実用化されたものが発売、みんなキター状態
これを見たマスコミが　これはすごいともてはやす
マスコミの情報を見て、やじうまがあらわれる
タスクシステムのすごさを報道
バカには理解できない　そのうえ、数は多い
こんなもの何の役に立つんだ　根絶してしまえ　←　いまここ

54 ：

>>3

55 ：

つまりバカほど・・・おっと　もはやまともな奴は静かにしてるな

56 ：

釣りはもっと上手くやれよ

57 ：

タスクシステムは
抽象的には
発生する大量のオブジェクトを
動的に一元管理・実行できるってのがすべてだと思うんだけど
逆にこれ以外の方法で大量のオブジェクトを扱える設計は
何が考えられますか？
コード中のあちらこちらでメモリ領域確保してたら
わけわからなくなりませんか

58 ：

>>57
全部「タスク」の名の下にごちゃまぜになってるほうがわけわからなくなりませんか？
「〜のコンテナ」を必要なだけ必要なところに置けば十分で、さらにそのほうがコンテナの
スコープが狭まり、個別に名前付けが行われるぶんコードは読みやすいはずです。
コンテナが分かれていれば、特定のオブジェクト郡にだけ適用できる最適化を局所的に
行うこともできるようになります。（ここは挿入削除が頻繁だから list で、ここでは
要素数がずっといっしょだから vector で、などなど）
逆にコンテナがまとまっていた場合、そもそもそういった最適化が不可能になってしまうか、
できたとしても全体に影響が波及してしまうことになり、危険度が上がってしまうでしょう。
> コード中のあちらこちらでメモリ領域確保してたらわけわからなくなりませんか
逆に、なぜ「わけわからなく」なってしまうのかを追究してみたいところです。

59 ：

>>58
過疎っぽいからレスつかないかと思った。ありがとう
>「〜のコンテナ」を必要なだけ必要なところに置けば十分で
というのがまさしく、気になるところで、例えば
擬似コードですが
class enemy ｛
Tama tama[];//唯一の参照保持コンテナ

弾発射（）｛
　//３つ発射しちゃうぞー
　tama.add(new Tama());
　tama.add(new Tama());
　tama.add(new Tama());
｝
}
というような実装を単純にしてしまうと
enemyが弾が消える前に破壊されて
deleteされるような事態になったら
おかしなことになりかねませんよね
当然、こんな場当たり的な領域確保できないわけで、
弾のコンテナのスコープはどこがいいのか、
どう管理するんだ、というような話になると。
つづく

60 ：

つづき
>コンテナが分かれていれば、
>特定のオブジェクト郡にだけ適用できる最適化を局所的に
>行うこともできるようになります。
というのが、結局のところ
http://d.hatena.ne.jp/alwei/20110117/1295290033
のタスクシステムの解説記事の中の
■その他の問題　で、
>タスクの数が異常に増えたりする際は複数のタスクリストやコンテナに分けた方が
>管理面でも速度面でも良くなったりします．
というふうにタスクシステムの範疇から出てないのかな、と。
長くなって申し訳ない。

61 ：

>>59
> 当然、こんな場当たり的な領域確保できないわけで、
「当然」ではないでしょう。「弾が消える前にenemyが破壊される」という
仕様が出てきたから不都合が発生したという話にしか見えません。
それがたとえば「弾」ではなく enemy と共に破壊される「角」とかそういう
オブジェクトであれば何も問題はなかったのです。
> 弾のコンテナのスコープはどこがいいのか、
> どう管理するんだ、というような話になると。
そういう話になるでしょうけども、だからといって「タスク」も「システム」も
カスりもしません。
典型的には「弾のコンテナはもうひとつ外に持っとくか」という話になるだけ
ではないでしょうか？

62 ：

>>60
>>タスクの数が異常に増えたりする際は複数のタスクリストやコンテナに分けた方が
>>管理面でも速度面でも良くなったりします．
>
> というふうにタスクシステムの範疇から出てないのかな、と。
「オブジェクトをコンテナに入れたら、それはもうタスクシステムだ」という
ことでしょうか？
それを完全に否定する材料は持ち合わせていませんが、それが言えたからと
いって何になるのか、何がうれしいのか、わかりません。

63 ：

>>61
どうしてもレスが長くなってしまう。。
>「当然」ではないでしょう。「弾が消える前にenemyが破壊される」という
>仕様が出てきたから不都合が発生したという話にしか見えません。
いやいや、さすがにそれはちょっと…
シューティング以外でも魔法でも矢でもエフェクトでもダメージ表示でも。
> 典型的には「弾のコンテナはもうひとつ外に持っとくか」という話になるだけ ではないでしょうか？
それって、enemyのコンテナの隣に弾のコンテナってイメージでいいんですかね。
80種類の敵がいたら80個コンテナ作って自機との命中判定のために80個の
参照作って、なんてのは考えにくいから「敵コンテナ」に統合しますよね。
>「オブジェクトをコンテナに入れたら、それはもうタスクシステムだ」という
>ことでしょうか？
結局、
いわゆるタスクシステムとの違いが
「敵と弾を分離してるだけ」とか、
「シーンクラスとかキー入力処理クラスまで
同じコンテナのタスクとして扱うのは
気持ち悪いから、別処理にする」程度の話なら
タスクシステムのような方言の多い設計技法の実装としては
よく見かける気がするんですよね。
つづく

64 ：

つづき
それを指して「これはタスクシステムではない！」ってのは
正直に言うと得るところがないです。
むしろ知りたいのは
その範疇には収まらない設計はあるのだろうか、
あったら知っておきたいなと思って、
>>57の
>逆にこれ以外の方法で大量のオブジェクトを扱える設計は
>何が考えられますか？
と聞いたわけです。
知らない以上、うまく言えないんですが
コンテナが不要なデザインパターンみたいなものとか
存在するのかなと思って。
うれしいとかうれしくないとか別にないです。

65 ：

>>63-64
> いやいや、さすがにそれはちょっと…
何でしょう？書いてもらわないとわかりませんよ。
> 80種類の敵がいたら80個コンテナ作って自機との命中判定のために80個の
> 参照作って、なんてのは考えにくいから「敵コンテナ」に統合しますよね。
どちらにもメリット・デメリットがあるでしょうから、そうするかもしれませんし、しないかもしれません。
ただし、少なくとも僕が「タスクシステム」と聞いてイメージするようなグローバルなリストに統合することは
無いでしょう。
>>「オブジェクトをコンテナに入れたら、それはもうタスクシステムだ」という
>>ことでしょうか？
...
> タスクシステムのような方言の多い設計技法の実装としては
> よく見かける気がするんですよね。
つまり、答えは yes ということですかね？そういうことなら「タスクシステム」などという不明瞭な
言葉は使わず、はじめから「コンテナ」と言って欲しいところです。
> それを指して「これはタスクシステムではない！」ってのは
> 正直に言うと得るところがないです。
何かを指して「これはタスクシステムではない！」などとは言ってません。
ただ、仕様に沿ってコンテナを用意しただけのコードを指して「これもタスクシステムですね？」などと
言われれば「知らんがな。何なの？」となります。
> コンテナが不要なデザインパターンみたいなものとか
そんなものを探すことに意味があるとは思いません。

66 ：

>>65
うーん、そういう結論かｗ
なんにせよ、つきあってもらってありがとね

67 ：

>>59-60を読んでレスしようとしたことを、
俺がしようとしたよりまとめた形で>>61-62にレスされてて驚いたｗ

68 ：

過去ログみてたら、良いこと書いてあったので貼っとく
タスクシステムは嫌いだけど、ここにタスクシステムのメリットが示されてると思うわ
タスクシステム総合スレ part5
http://2chnull.info/r/gamedev/1234977661/874-880
874,880的な理由でタスクシステムを採用するのはありだと思う
ゲーム開発に最初から完成された仕様を求めるのは難しいからな
ただ、仕様が完成されている（面白さが実証されている）ゲームに対して
タスクシステムを採用しようという意見には賛成できないがね

69 ：

>>68
その場合は「タスクシステムを採用する(ｷﾘｯ」などとは言わずに、
「わりと何でも入るごった煮リストを予備で用意しとくよ。
　設計に悩んで対応が間に合わなくなりそうだったら、とりあえず
　ここに入れて済ませても良いよ。
　でもなるべくデバッグ始まるまでには片付けるように考えてね。」と
正直に言って欲しい。さらに言えばそのごった煮リストにアクセスする
インターフェースのコメントに書いておいて欲しい。

70 ：

内容自体は別にいいとも悪いとも思わないんだけど
所詮設計手法であるにもかかわらず
タスクやらシステムやらたいそうな名前付けてるのに問題があるよな

71 ：

そもそも、さっき出てきた、敵やら弾やらは、ゲームオブジェクトであって、タスクではないだろ。
なのにタスクシステムとかいうから・・・もうそっからしていかれてる。

72 ：

ノンプリエンプティブなタスクです。

73 ：

SPUのようにメモリが共有できないプロセッサで有効な手法ってありますか？？

74 ：

>>73
問題も挙げずに手法もクソもあるか。
何が問題なの？それはこのスレに関係あるの？

75 ：

お前が頭悪い
メモリが共有されてないのが問題だろ
タスクシステムは並列化でも関係あるし

76 ：

>>73
無い

77 ：

>>75
共有されてないメモリを何らかの「手法」で共有しちゃおうって話だったの？
そりゃ無理だｗ

78 ：

あほか

79 ：

まー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 ：

>>79
タスクシステム関係なくね？スレ違いじゃね？過疎ってるからいいけど。
あとシングルトンは。

81 ：

燃料投下age
http://dixq.net/forum/viewtopic.php?f=3&t=8414

82 ：

アマチュア発のオカルト怪文書だね

83 ：

>>79
並列処理はどうやって対応する？

84 ：

>>83
foreachの並列化なんて超簡単じゃん。

85 ：

みんな、オンラインゲームを支える技術つまて本読んだ？
タスクシステムが紹介されてるな。
実際のオンラインゲームでも使われてるんだな。

86 ：

具体的に何が？ｗ

87 ：

とりあえず買ってきたけど何頁だよ

88 ：

タスクシステムってlistにオブジェクト突っ込んでイテレータでぐるぐる回しながら処理を実行させるだけのことだろ

89 ：

だから http://hibari.2ch.net/test/read.cgi/prog/1290878067/ でやれ

90 ：

タスクシステムか・・・なつかしいな
ゲームオブジェをどんな構造でまわすか、って悩むのはゲームプログラマなら
みんな通ったことのある壁の一つだよね。
最近は情報があふれてるからこの辺までは定石のお勉強で到達できるけど
ここから先が自分で考えられる人か教わらないとできない人か、の登竜門な感じ。
ゲームプログラマ向きじゃないのはここで詰まったまま脱落するんだよね。
まぁここを超えてももっと高い壁がまだまだ続くんだけどね・・・

91 ：

で「タスクシステム」を極めることが目的じゃない、と気付き、
使い回しの効く便利ルーチンをいくつか作るに止めるか、
なぜか目的を忘れてハマるか、という分岐があるんだけどね。

92 ：

ゲームの仕様、開発言語、対象マシンのリソースと制限、納期とメンバーのスキル、etc...
タスクシステムの扱う範囲はゲームのコアアーキテクチャに関係してくる
最適解がコンテキスト依存な問題の典型。
これらコンテキストは作ろうとしているゲームによって千差万別だからネットで一般解を聞いても
ケースバイケースという一般論しか返ってこない。
さらに「タスクシステム」ってゲーム業界で慣習的に呼ばれてるだけで
実装はゲームによって全然別物。
ってことで結局サンプルソースとかで実装されてるタスクシステムと言われる
ものを参考にでもして作る予定のゲームにあわせて自分で考えて実装しろや、となる。

93 ：

そんで、あれ、もしかして、これ要らなくね？となる。
型ごとにリスト用意して、任意にforeach回すだけ。

94 ：

>>93
レベル（ステージ）毎に必要な型のforeachを実行する関数を用意するわけか。
レベルデザイン時の柔軟性が失われないか？
もしくは全ステージで同じ型出すと、ステージ色が失われないか？

95 ：

コールバックさせるupdate関数の引数が固定になる方が柔軟性が損なわれる。

96 ：

そうだよな
必要な情報ってオブジェクトごと違うのにそこをわざわざ統一しちゃうのは
逆に必要な情報が関数みてわからなくなっちゃう
ホーミングミサイルで更新にターゲットが必要ならそれが必要な情報とわかるように
むしろ引数で明示するべき
その情報がなければこの関数は実行できないよと
これがプログラムの基本なんだよ

97 ：

書泉でゲームプログラムフェアってのやってたから「何とかでつくるシューティング」とか
何冊か立ち読みしたら6冊中4冊でタスクシステムの説明とそれ使ったゲームがのってた。
PHPのやつとAVGの二冊はタスクシステムじゃなかった。
>>92
の言うようにC++とかJavaとかObject-Cとかで実装は別々だったけど、作るゲームにあってるなら
タスクシステム使って。
ポインタや参照使えない言語使う、とかタスクシステムが合わないゲーム作るならほかの方法で実装すれば
いいんじゃないかな。

98 ：

>>95
書籍で紹介されているタスクシステムでは、個体情報を含むメモリブロックへの参照をメンバに含む
構造体ポインタを引数経由で渡して、個体情報特有の構造体にキャストしている。
むしろ何でもありで、情報のやり取りの柔軟性が損なわれることはない。
>>96
呼ぶ側は呼ぶことしか行わない方が、分かりやすい。
また例で言うとターゲットが存在しない場合の条件分岐を、呼ぶ側にしわ寄せ実装する必要が出てくる。
生存および消滅の過程や、何をターゲットにするかは、対象リストへの広域なインターフェースを用意して、
個体タスク内で自律的に行わせる。
基本と言い切るのは勇み足じゃないか？

99 ：

>>98
バッカ
全然関係ない
ちゃんと引数で渡すようにすれば何が何をやるべきかちゃんと見えてくる
なんにも見えないのは年がら年中そうやってオブジェクト同士の関連を面倒だからって
端折ってるからなにも分析できないなにも進歩しない

100read 1read

1read 100read

TOP カテ一覧 スレ一覧 2ch元 削除依頼 ▲