タスクシステム総合スレ part9

**名前は開発中のものです。** · 2009/12/13(日) 18:11:06

タスクシステムについての議論、相談、質問、雑談などのスレです

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」と明示してください
　そうでない場合はカスタム版であることを明示してください

・人を憎んで言語を憎まず

**名前は開発中のものです。** · 2010/02/01(月) 02:33:20

>>408
概念的にグローバルであればよくて、弾や地形がそれぞれ一意の
お母さんポインタを持ってるってことで、実装の話ではないですよ。
弾や地形のお母さんにもお母さんがいたって不思議じゃないし。

**名前は開発中のものです。** · 2010/02/01(月) 02:34:28

あ、説明が足りないかも。ま、いっか

**名前は開発中のものです。** · 2010/02/01(月) 02:35:45

グローバルな存在 ≠ グローバル名前空間

つーことなんでねーの。たぶん

国境を越えて存在するもの。長命インスタンス。
例えばハードウェアリソースの制御・分配を行う低層の色々。
ブート→電源断の間、ずっと生き続ける実行待ちキュー。

**名前は開発中のものです。** · 2010/02/01(月) 02:40:14

かぶったな。
長命インスタンス　→　相対的に長命な存在

**名前は開発中のものです。** · 2010/02/01(月) 06:35:15

>>409
はぁ？逃げるなよ
自分で決めた言葉もう一度定義しなおしたいなら
せめて前にした定義をどう変更するのか明確にしろよ
勝手に会話の中で都合いいように変化させてんじゃねーよ
しかも違うし
違うだろ？

>弾や地形のお母さんにもお母さんがいたって不思議じゃないし。
なんだよ
グローバルなんだろ？
グローバルのグローバルってなんだよ
全然わけわかんねんだよ！
お前技術者やめろよ

**名前は開発中のものです。** · 2010/02/01(月) 07:09:25

仮に彼のいうことを汲んでやったとしても
弾クラスや地形クラスでグローバル的にアクセスできるもんなんてないじゃんｗ
いつまで自分の世界で話してるんだって思うｗ

**名前は開発中のものです。** · 2010/02/01(月) 10:19:55

>>375のコードってどうなの？
メタプログラミングとやらに馴染みがないので、
ものすごく、いや、有り得ないほどにウザく感じるんだが。
率直な感想を聞きたいね。
みんな、あんなのを保守していきたいと思う？

**名前は開発中のものです。** · 2010/02/01(月) 10:36:30

>>415
なにこれ。コード読めません。。。。。何をしてるんでしょうか

**名前は開発中のものです。** · 2010/02/01(月) 15:07:54

とりあえず本人による解説待ち

**ハードの人** · 2010/02/01(月) 22:41:56

>>415
てか、こんなことしてるからオナニーとか言われるんだろ。
技術屋ってのは、お山に登っても駄目なんだよ。山を崩すから金になるんだ。
登るべき山と崩すべき山を見定めなきゃ

**名前は開発中のものです。** · 2010/02/01(月) 23:14:31

他のタスクの検索するためのDBってどうやって実現すればいい？
multisetに識別子とタスクのポインタを格納すればいいかな。

**名前は開発中のものです。** · 2010/02/01(月) 23:43:47

エンジニアとして破綻してる中年がガキに説教垂れてんぞｗ
ハード君は素人オジサンだから子供相手にも余裕が無いよね

**名前は開発中のものです。** · 2010/02/01(月) 23:45:37

>>419
もし、ダウンキャストを嫌うのなら、型ごとにリスト持つしかないよ。

**名前は開発中のものです。** · 2010/02/01(月) 23:53:00

>>421
あーそうか。

**名前は開発中のものです。** · 2010/02/01(月) 23:54:05

俺まだ若造なんだが。どうでもいいや。
つーか、年寄りは良いよなー。
日本経済の先行きが不安すぎて死ねる。40年持ってくれるだろうか。
あーー高度経済成長期を体験してぇ。

**名前は開発中のものです。** · 2010/02/02(火) 00:05:31

前スレから何度も書かれてることだが
「1タスク＝ 1オブジェクト」だの「タスク＝オブジェクト」といったような
固定観念に縛られた自称タスクシステムは単なるオブジェクトのコントローラだよ

別の言い方をすれば「1タスク＝ 1オブジェクト」「タスク＝オブジェクト」限定で
構わないならばタスク（処理単位）という汎化された概念にスポットライトは当たりようが無いし
意識する必要も無い。ただ単にオブジェクトをタスク言いたいだけちゃうんかとというのが
例えばCodezineのそれ

タスクはあくまでも処理単位、処理ステップ。別に上記の（ゲーム）オブジェクトとは
限らないし型があるとも限らない。何らかの理由でそこにある処理の一塊・切り身であり
機械的に演算器に割り当て流し込む存在でしかない

**名前は開発中のものです。** · 2010/02/02(火) 00:08:19

>>424
むずかしくよくわからない。
別に議論したくない

**名前は開発中のものです。** · 2010/02/02(火) 00:13:16

>>424
>>2のLogicianLordとCodezineの差異

**名前は開発中のものです。** · 2010/02/02(火) 00:18:45

弾幕ものとかって、弾をグループで管理したりとかする？

**名前は開発中のものです。** · 2010/02/02(火) 00:29:42

>>427
case1) an entity is treated by a task
case2) an entity is treated by multiple tasks
case3) a task treats multiple entities

case3 は普通にある

**名前は開発中のものです。** · 2010/02/02(火) 00:38:39

すまん処理じゃなくて管理か

例
・敵を倒したらその敵の撒いた弾も消滅するケース
・多段式誘導弾、MIRV弾頭、散弾、同時消滅あり

皆親子

**名前は開発中のものです。** · 2010/02/02(火) 00:42:56

あとハード君はタスクシステム云々以前に
さっさとゲーム作れるようになりなさい

**名前は開発中のものです。** · 2010/02/02(火) 00:43:21

親子関係はいらないと思ってきた。自弾だったら自機知ってるし。

**名前は開発中のものです。** · 2010/02/02(火) 00:53:37

反対に自機は自弾のことを知っているべきか

**名前は開発中のものです。** · 2010/02/02(火) 01:24:32

>>431
それも親子だろ。子→親の片方向の接続情報というだけの話。
親の認知がないと法的には親子とは認められない（怒）とか
そういう眠たいお話になるなら退散するが

**名前は開発中のものです。** · 2010/02/02(火) 01:29:58

>>433
いや、タスクシステム自体には必要ないという意味で。。。

**ハ(ry** · 2010/02/02(火) 01:34:02

自機も自弾もデータだろ。
データに知ってるも糞もあるかよ。
データはデータ。そこに転がってるだけの単なるメモリブロック以上の解釈は必要ないだろ。
データに命を吹き込むのが制御構造、つまりプログラムなわけで、
プログラム中の自機と自弾を制御している箇所にそれぞれの在り処が分かればそれでよい。

自弾に自機のポインタを突っ込むことはあるだろうが、
それはそれらを処理するプログラム(関数)から、どの弾がどの機体のものか判別できるように、
便宜上突っ込んだってだけで、単に「そう実装した」っていう以上の意味は無い。手抜き実装。
別に別途、機体と弾の紐付けを管理するテーブルを用意したとしても、それはそれでかまわないわけで。
プログラムが自弾と自機のことを知ることが出来ればなんでも良い。

つまり、自機と自弾を知っているべき者はプログラムで、
自弾も自機も各々を知っている必要は無い。

**名前は開発中のものです。** · 2010/02/02(火) 01:37:00

俺の場合自弾は自機から離れた瞬間自機とは赤の他人としてたわ

**名前は開発中のものです。** · 2010/02/02(火) 13:36:47

自称ハード屋って相当に頭がコチコチのオッサンだよね
恥ずかしいから出てくるなよ

**名前は開発中のものです。** · 2010/02/02(火) 13:54:24

ここってメモリ管理とか処理の流れの受け渡しとかオーバーヘッドの話をするところじゃないの？
と思ってたけどただの基地外隔離スレだったのか。

**名前は開発中のものです。** · 2010/02/02(火) 14:13:33

メモリ管理？タスクコントローラが内包するのか？
関係なくね？

**名前は開発中のものです。** · 2010/02/02(火) 14:22:46

別々にしときゃあいいもの一緒にしてしまうのはいつでも糞仕様。
曖昧な名前しか付かない単位でやりくりするのはいつでも糞仕様。

**名前は開発中のものです。** · 2010/02/02(火) 15:20:03

>>435を何度も読み返してみたがやはりこの人は本当にヤバイな
さすがOOPを否定する超人だけあって凡人には理解できない

**名前は開発中のものです。** · 2010/02/02(火) 16:26:13

誤爆してんじゃねえよｗｗｗ

**名前は開発中のものです。** · 2010/02/02(火) 18:55:31

ハード屋さんって上のほうでオブジェクト指向を否定してた
凄腕のアンチさんでしょ。どう見ても彼は引数君クラスだね

**名前は開発中のものです。** · 2010/02/02(火) 19:29:20

>>436
＞俺の場合自弾は自機から離れた瞬間自機とは赤の他人としてたわ

え？赤の他人って具体的にどういう状態なのそれ？
いくらなんでも弾の出自・所属を知る手段がないなんて話じゃないよね？

**名前は開発中のものです。** · 2010/02/02(火) 20:04:09

なんかスレの血色が良くなってきたなｗ

>>442
　　　　　＿＿＿＿
　　　／∵∴∵∴＼
　　 /∵∴∵∴∵∴＼
　　/∵∴∴,（・）（・）∴|
　　|∵∵／　　 ○　＼|
　　|∵ /　　三　|　三　|　　／￣￣￣￣￣
　　|∵ |　　　＿_|＿_ 　|　＜　うるせー馬鹿！
　　＼|　　　＼＿/　／　　＼＿＿＿＿＿
　　　＼＿＿＿_／　

**名前は開発中のものです。** · 2010/02/02(火) 20:05:13

自機が弾吐き出す時自弾リストに追加して自機とは親子関係もないってこと
自弾リストが出自・所属の代わりになるのかな

**名前は開発中のものです。** · 2010/02/02(火) 20:24:48

だよな
そのリストの全要素は出自・所属がコード上で決定してるから
各要素が出自・所属情報を持つ必要が無いというだけの話で
コード上では親子として扱われてる

**名前は開発中のものです。** · 2010/02/02(火) 20:52:49

は？なんで？

**名前は開発中のものです。** · 2010/02/02(火) 21:15:54

ん？あー、すまん。>>447の「だよな」は>>446の2行目にかかってんだわ

>>447続き
だから親子関係も糞もないという話にはならねーだろっつーこと。
例えばツリー状コンテナ（内部収納でも外部収納でも可）内の配置で
（動的な）親子関係を表現されてなくとも、コード上で記述された
（静的な）親子関係というものがそこにはあるでしょと

**名前は開発中のものです。** · 2010/02/02(火) 22:47:32

>>429
ありがとう。
でも、グループで管理されてる弾は、ひとつひとつは単発の弾として扱いたいので
普通の弾クラスを継承して、グループ管理者への参照を持つ弾とするのかな。
いいのかなこういうの。

ていうか、弾ごときにクラスとか作ったりするのって普通？
何が普通かももうわからんくなってきた

**名前は開発中のものです。** · 2010/02/02(火) 23:21:35

>>449
は？なにをいっているのか本当にわからない

**名前は開発中のものです。** · 2010/02/02(火) 23:30:21

まーたゴキブリアンチがわかんないわかんないって喚いてんのか
付ける薬ねーな

**名前は開発中のものです。** · 2010/02/02(火) 23:33:54

わりー。>>450のことじゃないから気にしないでくれ

>>450
それでいいんじゃね？

**名前は開発中のものです。** · 2010/02/02(火) 23:35:18

はぁ？どうせ初心者が意味不明なコード組んでるんだろ？
弾の発射にどうやったら自機と弾とで親子関係なんてできんだよ
マジで意味不明ｗ

ためしに聞いてみるけど
自機からシーンの弾発射クラスに弾発射のリクエストもらうような実装だと
親子関係ってできるの？これだとできない？
それともこの実装でもできることなの？

**名前は開発中のものです。** · 2010/02/02(火) 23:43:27

>>454
＞出自・所属

とやらが表現されてるって>>446は言ってんだろ？
出自・所属とやらが表現されてて親子関係も糞ねーってどんな状況だよ
論理的におかしいだろ。おかしくねーってんなら説明してみ？

**名前は開発中のものです。** · 2010/02/02(火) 23:57:10

>>455
コードの親子関係はあるってどういう意味なん？

**名前は開発中のものです。** · 2010/02/02(火) 23:58:53

出自・所属　→　どこ中

**名前は開発中のものです。** · 2010/02/03(水) 00:01:09

データ構造内で親子関係が表現されてるか
ロジックの中で親子関係が表現されてるか
というだけのような

**名前は開発中のものです。** · 2010/02/03(水) 00:03:10

>>458
いや親子関係なんてまったくねーの
まったくねーのにあるとか言い出してる人がいるから
なんで？って聞いてるのがいまの俺の状況
なんでもインスタンスのことじゃなくてコード（？）のことらしい

**名前は開発中のものです。** · 2010/02/03(水) 00:07:25

> いや親子関係なんてまったくねーの

ID:rRkqKnAN

この人誰？ID:zzoDV2n3と同一人物なの？怖い

**ハ(ry** · 2010/02/03(水) 00:08:58

だからお前ら親子親子って、いったい何の親子だよ。
生存期間の親子か？座標系の親子か？何かの設定値の親子か？更新順序の親子関係か？
なんなんだよ。
第一いろんな親子関係が発生しうるのに、一緒くたにタスクシステムで管理する理屈はねぇんだよ。
理由がねぇ。初めからスレ違い。
それとも何か？親子関係基底クラスでも作って、多重継承するおつもりですか？
そもそもからして、タスクシステムは制御構造を管理するためのものだから、
データ構造まで足伸ばすと破綻するんだ。
もとより関係ないものを必要も無いのにくっ付けんなよなー。可搬性ってしらないのかよ。

**名前は開発中のものです。** · 2010/02/03(水) 00:14:03

バカはすっこんでろ

**名前は開発中のものです。** · 2010/02/03(水) 00:15:41

なんかもめてるようだが、
ゲームの仕様上に親子関係があるなら、そりゃプログラム的には親子関係はあるわな。
それともあれか？プレイヤーに「この弾を撃ったあいつに報復してやるぜ」って
勝手に親子関係を見出してもらう類の話をしているのか？
そう言うのは因縁って言うんだ。

**名前は開発中のものです。** · 2010/02/03(水) 00:23:42

話に乗っかるけど、因縁の管理ってどうやってやるんだろうね。
ホーミング弾とかって基本的に自機なり敵なりの座標を把握してるわけだけど
因縁変数として敵機のポインタを持っちゃうと、処理上まずいよね？
こういうときはどうするのがふつくしいんだろうか

**名前は開発中のものです。** · 2010/02/03(水) 00:24:51

俺は自機と自弾の間には親子関係ないってつもりで言ったんだがな
俺の言う親子関係とは例えば敵の吐き出す弾はその吐き出し元の敵を壊せば皆消滅する
この場合敵を親、その弾を子と見て、更新関数呼び出す場合は親の更新関数中で子群の更新関数を呼び出せばいいんじゃないかな
それとは違い自機と自弾はそういう関係がないから並列に処理すればいいと思うのだが

**名前は開発中のものです。** · 2010/02/03(水) 00:37:02

>>464
それは俺の言ってる因縁とは意味が違うんだが・・・
ホーミング弾の場合はターゲットを追いかけるって仕様がはっきりしてる。
当然プログラム中にもそう言うコードが含まれてる。
俺の言ってる因縁は、コード上どこにもそんな関係は示してないのに、
プレイヤーが勝手に関係あると思い込んで因縁つけるという。
たとえば、「コンテニューどっかでカウントしてて密かに成績に響いてるんじゃねぇだろうな」とか。
そう言う風に匂わす作りは大切だと思うけど。

>>465
生存期間の親子関係以外は親子関係とは言わないと？
初めから、「親子関係は要らない」とは言わず、「生存期間に依存は要らない」
と書けばよかったものを。

**名前は開発中のものです。** · 2010/02/03(水) 00:37:05

>>465
弾が敵性オブジェクトと衝突しそれを破壊したら
誰の得点を加算するのかどうやって知るんだい？

母機が誰なのかを知る術が必ずあるはずだろう
データ構造なりロジック中でハードコードされてるなり

**名前は開発中のものです。** · 2010/02/03(水) 00:39:39

お、ハード君、今日は冴えてるじゃないか
何か悪いものでも食ったか？

**名前は開発中のものです。** · 2010/02/03(水) 00:42:58

その自機なり自弾なり敵なり敵弾なりを操ってる大元のクラスが知ればいいんじゃねーの

**名前は開発中のものです。** · 2010/02/03(水) 00:45:50

>>467
残念ながら、それを親子関係と呼ぶかどうかは、ID:gGt1YOQG　が決めるとこ。
ID:gGt1YOQG　の仕様書では、生存期間の依存のみを親子関係と表記するらしいから、
これはもう仕方が無い。
一般的には親子関係というと木構造を指すことが多いのだが、
本人が「親子関係ではなく、ただの木構造です」と言いはりゃそれまでだわな。

**名前は開発中のものです。** · 2010/02/03(水) 00:46:01

>>447が１人で馬鹿なだけだろ

**名前は開発中のものです。** · 2010/02/03(水) 01:13:22

>>469
「自」機と「自」弾リストがある。コンテナ（の要素）の所属があるということ。
それが要素の所属であり、その大元のクラスとやらのメンバ関数の中の
ロジック中でそういうものとして取り扱われてるんでしょ？
所属があるということは何らかのヒエラルキーがありその中の位置関係が
あるってこと

これを親子関係も糞もない赤の他人だという主張は非論理的に見えるが

**名前は開発中のものです。** · 2010/02/03(水) 01:15:29

×　それが要素の所属であり、その大元のクラスとやらのメンバ関数の中の
○　君の言うその大元のクラスとやらのメンバ関数の中の

**名前は開発中のものです。** · 2010/02/03(水) 01:16:18

あとよ、ID:rRkqKnAN って誰なの？

**名前は開発中のものです。** · 2010/02/03(水) 01:19:05

それなら親子関係というより兄弟関係といったほうがいいんじゃね

**名前は開発中のものです。** · 2010/02/03(水) 01:23:32

>>475
自弾とは「自機の弾」なのだろう？

**名前は開発中のものです。** · 2010/02/03(水) 01:34:22

>>475
親子関係の仕様を満たすために、兄弟関係の実装を使ったってんなら、
それは親子関係を表現したといえる。逆もまたしかり。
結局、仕様上はどうなってるのかってだけ。仕様を作った奴がどう言い張るのか。そんなもんは知らん。

>>476
自機の弾を子供と見なすかどうかなんて、仕様書書いた本人にしか分からん。
子供ではなくて、単に自機の打った弾のグループです、と言われればそれまで。

**名前は開発中のものです。** · 2010/02/03(水) 01:45:14

自弾も敵弾も敵も一緒くたにリストなり配列なりに入ってる場合はどうなんだろう？
例えば画面外から謎の隕石が飛んできてそれにあたると自機も敵機も死ぬゲームで
自弾もその隕石と同じように処理されてるとしたら
>>469の作ったものは寛容に捉えればそういうものだったんじゃないかと推測するんだが

**ID:bErugn9a** · 2010/02/03(水) 01:54:05

>>465
＞俺の言う親子関係とは例えば敵の吐き出す弾はその吐き出し元の敵を壊せば皆消滅する
＞この場合敵を親、その弾を子と見て、更新関数呼び出す場合は親の更新関数中で子群の更新関数を呼び出せばいいんじゃないかな
＞それとは違い自機と自弾はそういう関係がないから並列に処理すればいいと思うのだが

君の親子関係の定義ってかなり独特というか狭すぎる気がするな
兄弟ってのも何をもって兄弟なんだっつー。赤の他人との閾値は何みたいな

**名前は開発中のものです。** · 2010/02/03(水) 02:12:17

親子関係って生成元と生成先ってだけの関係だったのか
それならすまんかった

**名前は開発中のものです。** · 2010/02/03(水) 02:20:57

タスクシステムにどこまで機能を入れ込むかはそのゲームでの使われ方次第だな・・・

極限までシンプルに、その機能使うタスクだけ別途組込み、という原理主義的な戦略は一見常に正しそうなんだが
実際には全体の８割のタスクが親子関係使ってる、とかのケースなら
タスクシステム自体に親子関係の処理を入れた方が全体では綺麗なコードになる。

全体の一割以下のタスクしか使わない機能をタスクシステムの根幹に組み込む、
とかは肥大化したダメな設計の典型だけど。

要はケースバイケースという当たり前の話。
全てのケースを満たす唯一の最適解という銀の弾丸は無いってことだね。

**名前は開発中のものです。** · 2010/02/03(水) 02:26:54

>>481
ケースバイケースが当たり前なのに、なんで「タスクシステム」と呼ばれるものの存在だけは
前提になってるの？

**名前は開発中のものです。** · 2010/02/03(水) 02:28:17

>>478
それはおそらく複数の侵入式コンテナに格納されてるオブジェクトだろうな。
複数のコンテナのパラメータがオブジェクトのメンバ変数として侵入してる。
例えばその「ごった煮」リストであったり、木構造であったり。片方向かもだが

**名前は開発中のものです。** · 2010/02/03(水) 02:35:20

>>482
使った場合の前提でしょ。当たり前すぎの話だからあえて書く必要無いと思ったんだけど。
タスクシステム以外の方がいいケースなら別の方法採用するのは当たり前。

逆にこんなこと聞いてくる方が疑問。
何で目的に対して手段は一つだけ、と考えちゃうんだろう・・・？

**名前は開発中のものです。** · 2010/02/03(水) 02:44:27

>>484
ふーん。当たり前の話と当たり前すぎの話で書くか書かないか切り分けたんだね。
よくわかんないけど、後ろについてる「疑問」もさっぱり脈絡がわかんないけど、まぁいいや。

**名前は開発中のものです。** · 2010/02/03(水) 02:52:48

>>484
ゆとり教育の弊害じゃね？
ゆとりの学校では一個の問題に一個の答えしか教わらないもんだから
どんな問題でも答えは一つしかないと信じてるんだよ。きっとｗｗ
アンチの頭はみんなこんな感じ。
「タスクシステムは唯一の答えじゃない！だからまったく使えない！」ってｗｗ

**ID:bErugn9a** · 2010/02/03(水) 03:05:03

>>480
自機と自弾の場合、生成先と生成元という関係に終わらないよ
生成後にも自弾と自機には関連性がしっかりとある。
例えば自弾が敵をぶっ壊したら誰がポインヨゲトするのか、とか

自弾のこの状態変化（敵撃破＆消滅）によってポインヨ情報更新処理が
発動する唯一の存在が自機。自弾を所有し放った存在

**ID:bErugn9a** · 2010/02/03(水) 03:06:17

生成先と生成元じゃなくて生成元と生成先かな

**名前は開発中のものです。** · 2010/02/03(水) 03:16:38

そもそもポインヨ管理自機がするのか
俺の場合自機関係せずゲームクラスでやるがなあ
自機はポインヨノー関与よ
態々自機と自弾関連性持たせる必要あるのか
俺のやり方だと自機と自弾は全くの独立した存在

**ID:bErugn9a** · 2010/02/03(水) 03:21:50

ところでゆとり脳の>>448、>>451は死んだのかな？

**ID:bErugn9a** · 2010/02/03(水) 04:20:55

>>489
それ自機に関するパラメータ・処理の置き場所がコード上で
複数箇所に分かれてる（構造体・クラスが違う）というだけで
自弾の状態変化が自機に関するパラメータ・処理にしっかり
作用してるでしょ

例えば自機についてのオブジェクトAとBがあり異なるコンテナ・
オブジェクトに格納され、AとBは相互に作用がないが両者とも
自機についての情報を格納してる。それだけ

**名前は開発中のものです。** · 2010/02/03(水) 04:55:48

ポインヨ＝自機に関するパラメータなのかな
俺はそう捉えてないから違うのかな
俺の場合スコア＝ゲームの所有物だから
スコア＝自機の所有物という捉え方の違いじゃないのか

**名前は開発中のものです。** · 2010/02/03(水) 09:42:21

俺も結局はgGt1YOQGみたいにする。
親子関係なんてどこにもでてこない。
自機と弾はフラットな関係。
それでなーんも問題ない。
相互作用は相互作用として別途用意する。

弾や機体がある使われ方を想定したような設計にしはしない。
何か用のポインタを想定しただけ用意しておくようなことはしない。
弾は弾、機体は機体として自分の内側だけを見とく。

**名前は開発中のものです。** · 2010/02/03(水) 10:23:12

オブジェクト間の直接通信を避けて例えば調停者（mediator?）が
オブジェクト間の通信（作用）を仲介しているということならば
実装上の結合度は下がるもののオブジェクト間の関係が
解消されアカの他人になるわけじゃない。調停者がオブジェクトの
関係を承知している。処理フロー、データフローは調停者を
介して繋がっている

それが兄弟なのか親子なのかというのは俺の知ったこっちゃないが

**名前は開発中のものです。** · 2010/02/03(水) 10:59:01

mediator,obsererパターンもポインタ相手のもってるだけじゃｎ

**名前は開発中のものです。** · 2010/02/03(水) 11:30:42

>>493
各オブジェクトは他オブジェクトの情報を直接持たず、
調停者が全て通知したり制御するってこと？
グラディウスのレーザーとかオプションみたいなものだと
レーザーやオプションに自機の位置を伝えるのは調停者？

**名前は開発中のものです。** · 2010/02/03(水) 21:54:47

誰だよｗ
親子関係とか言ってたクズｗ

**名前は開発中のものです。** · 2010/02/03(水) 22:47:24

で、解決したのでしょうか？

**名前は開発中のものです。** · 2010/02/03(水) 23:23:34

まーた似非平等主義者のお花畑アンチが「私は不当な差別を受けてる」
「差別反対！階級社会断固粉砕！」とか喚いてると聞いて飛んできました

>>497
『あなたと私はフラットな関係です。私を見下さないで下さい（怒）』
ですね。わかります

**名前は開発中のものです。** · 2010/02/04(木) 00:20:19

こう言っちゃ怒られそうだけど言い争ってるの全員糖質っぽく見えるぞ
煽りの内容ももはやタスクシステム関係無いじゃん

**名前は開発中のものです。** · 2010/02/04(木) 01:24:38

「別にアンタ（自機）のために往くんじゃないから。勘違いしないで」　
「これで私も一人前の飛翔体だから。半人前扱いしないで」
「もう行くから。金輪際アンタと私は赤の他人だから。バイバイ」
自弾はそう言い残し敵に体当たりして名誉の戦死を遂げ
遺族への報償金は自機の銀行口座にふり込まれた

ここまで読んだ

**ID:bErugn9a** · 2010/02/04(木) 01:55:43

>>501
いや「自機の銀行口座」ではない
自機の上位の存在、世界の創造主、調停者、神、ゲームクラスが“管理”する銀行口座だ
というのが>>489

それはつまり神が“管理”する自機の銀行口座　ということだろ、というのが俺。>>491
自機というのは別に１Ｐで置換しても可。銀行口座は積立口座で置換しても可。

１Ｐ・２Ｐ協力プレー可能な縦STGなら神は複数の積立口座を“管理”するんだろ。
誰の積立口座なのかを識別する情報が必ずそこにある。１Ｐの口座、２Ｐの口座。
１Ｐに関する情報、２Ｐに関する情報。

**名前は開発中のものです。** · 2010/02/04(木) 09:33:26

>>500
ヒント：このスレはヲチされておりますｗ

**ハry** · 2010/02/04(木) 21:42:38

お前ら少なくともタスクシステムの話しろって。親子関係とかマジどうでも良すぎる。
お前ら本当は頭悪いだろ。俺もそんなに良い方じゃないのに、お前らどうするの？
俺が情報系の学科選んだのも、他学科よりも合格偏差値が低かったからだしなぁ。
おっと、自己紹介はここまで。
さっきから自己紹介の粋を出て無い会話が永遠と続いているから
俺もつい自己紹介したくなった。

**名前は開発中のものです。** · 2010/02/04(木) 21:47:40

http://d.hatena.ne.jp/yaneurao/20090203

これ読みづらくて意味わかんない。。。

**名前は開発中のものです。** · 2010/02/04(木) 21:50:28

はたから見てて、何をもめてるのかさっぱり意味不明なんだが。
ESPの範囲外。道端の石ころにさえ気を配る俺を置いてけぼりにするとは、
なかなかやるなー。頭痛が痛いから珍しく放置に放って置く。

**名前は開発中のものです。** · 2010/02/04(木) 21:59:39

>>505
意味の無いものに意味を見出すためには、
頭を強打するか、悪い薬でもする必要がある。

**名前は開発中のものです。** · 2010/02/04(木) 22:01:41

>>505
読み辛いか？
確かにC++の文法（特にtemplate周り）や型操作、
現代の一般的なコンピュータのアーキテクチャ（メモリの動的な確保のコスト、マルチスレッドや実行の並行性）
に関する知識がないと分からないと思うが
それらは今一般的なコンピュータ上で製作時及び実行時に効率良く動くプログラムを作る上で必須。
使えるものを最大限に利用して徒労を回避するのは当たり前の思考だし、
低レイヤーな部分を記述できるC++でそれを実装しようという試みも間違ってない。