1 ：
名前は開発中のものです。 ：
2009/08/19(水) 19:48:11 ID:rSBdI4uX 裸の王様スレ
4 ：
名前は開発中のものです。 ：2009/08/20(木) 00:13:31 ID:zn4cSfxr
http://ja.wikipedia.org/wiki/%E8%A3%B8%E3%81%AE%E7%8E%8B%E6%A7%98 あらすじ
新しいシステムが大好きなゲームプログラマの元に、二人組の詐欺師が
プロのゲーム開発者という触れ込みでやって来る。
彼らは何と、馬鹿や自分にふさわしくない仕事をしている者にはメリットが
理解できない不思議なシステムを紹介してくれるという。
プログラマは大喜びで紹介されたとおりに実装する。
他のプログラマにメリットを聞かれた時、自分がこれまで慣れ親しんだ
コードを正当化してくれるはずのメリットが説明できない。プログラマは
うろたえるが、そのシステムを自慢げに見せた後輩プログラマたちの手前、
本当の事は言えず、ありもしないメリットから目をそらさせるため
「馬鹿には理解できない」と言い続けるしかない。後輩は後輩で、自分には
メリットが理解できないもののそうとは言い出せず、空気を読んで目をそらす。
プログラマはメリットもないシステムに増築を重ねて開発終盤に臨む。
火消しプログラマも馬鹿と思われてはいけないと同じようにそのシステムを
使い続けるが、その中のまだ空気を読めていなかった新入りが、こう叫ぶ。
「このシステム邪魔だよ!」
すっぱい葡萄君は元気だなぁｗｗｗ
>>4 すごい
うまくできてる
次回からテンプレ入り確定だな
火を見たこと無い原住民に「話に聞くマッチとやらのメリットを教えてくれ」と聞かれたとする。
>>1 :: ＿＿＿ :::._ ::
:: ？ ｀？ ｀丶、::. ／￣￣￣￣￣｀ヽ
.::／／ ＼::. ,？ ＿＿ |
::ー=？彡 ＼ ヽ::. | ／ .|
::／／ ＼ ＼ ヽ ::. | ／ (⌒⌒) |
.:::／ ｉ{ ヽ ヽ ハ ::. ￣￣ ヽ／ |
.::// / __八 iィ？ i丁｀ヽ| ＼／ |:: ＼ ノ
.:// 〃 ｢ ､ | ＼ | ｉ ｜ ／＼ |:: 厂￣￣￣￣
::？ | / i ｊｘミ ＼{＼| ﾉ）ﾉ？ | } 八::.
::i .ｲ { {？ ):ハ ｘ=？ミ | ﾊ ＼::.
::| / :|i 八 ﾊ{ {r':xi| / ｊ ／ ! } ＼::.
::|？.:|i ＼ ？ ゞシ / ／ ﾉ ﾊ }ヽハ::.
人 i ＼ ＼ ' ｒ ‐┐/イ ﾉr‐‐くー=ミｊノ::
::ヽ 丿 ゝ￣ ｰ一'？ .イ（ ￣｀ヽ / ヽ.＿＿＿＿__ ::.
.:://／ ﾉ≧=‐----r‐≦ ｊ（ ￣￣）？ ｀丶、::.
::/イ ／}ハﾉハﾉﾊ （￣￣￣ ￣￣ ）::
.::|／ ／⌒{≧｢￣ノ ￣￣￣￣／ ｘ≦？ 厂￣￣￣｢￣￣ .イ::
.::/ { ﾏハ ｀ヽ ／ （,／ / ／ -‐=ﾆ:::
.::〃 ハ ＼ `ｰ-----／'）？ / （？￣｢::
::／/ / ？ ＞‐‐一' ／＿＿___ ﾉ{ ） /::
.::／ / ﾉｲ > '？ .ｲﾉハﾉハﾉﾊ}小､ / /::
::ヽ / {.／ `ー――一く⌒! lヽ. /.／::
.::〉＾⌒ヽ／ ｘr――一' ﾉ ｊ V？::
.:/ ／8 ／＞ｘ ＿フ？ | 厂｀⌒？::
.::/ ／ ８ ／ { l ｜ /:::
C#4.0でタスクシステムがサポートされるらしい。
C#はゲームに向いてないんじゃないのか
>10
「タスクシステム」と呼ぶなよ
14 ：
646 ：2009/08/21(金) 17:31:04 ID:+xQHzCyI
今度は『.NET4.0のTPLもタスクシステム！』か。大胆な●●認定を始めたもんだねぇ
それを言うならまずOpenMPやTBBもタスクシステム認定しないと辻褄があわないねぇ
なのになぜあえてTPLなんだろうねぇ。クルクルパーの発想はいつも斜め上杉て面白いねぇ
一生懸命背伸びしてハッタリをかまし、実態の異なるナウいものを引っ張り出してはいちいち
タスクシステム呼ばわり＆事大する必要ないんだけどねぇ。クルクルパーは印象操作に弱いから
タスクシステム（
>>2 ）がバカにされるとTPLとかに縋りたくなるんだろうねぇ
>>10 出てたとは。
落ちてたんで気付かなかった。
>>14 が必死すぎて痛い件
スレ変わってまで番号コテとかw
>>9 、
>>15 逐次計算すること前提に作られたバカでも分かる簡素な仕組みと
並列計算を前提とする仕組みではまるで正反対のものだよ
タスクという単語が登場するだけでタスクシステムとは中身まるで違う
タスクという言葉を擁護することはタスクシステムを擁護することにはならないし
タスクという言葉を否定することはタスクシステムを否定することにはならないんだよ
それを理解できてなかったファイルシステム君は前スレでアンチの振りしてタスクを否定してたね
> 694 名前：名前は開発中のものです。 投稿日：2009/07/27(月) 23:15:40 CpdnwPwc
> 処理の単位なんて発想が馬鹿げてるんだ。処理に単位も糞もあるかよ。
> 処理はCで言うところの関数なわけで、必要に応じて呼び出すまで。
> 古い価値観は脱ぎ捨てようぜ。
タスクシステムを否定するつもりが何故か処理単位（タスク）を否定してやんの
上司や先輩から言われるがまま鵜呑み・天下り式に何かを使い続けてたから
自分が一体何をやってきたのか、何故そうしてきたのかを理解してないんだろう
だから足元がグラグラだし処理単位（タスク）を否定してしまったりする
前
>>909 や君も基本的にファイルシステム君と同じだと思うよ
と、いうことにしたいんですね？：）
19 ：
名前は開発中のものです。 ：2009/08/21(金) 19:07:15 ID:2g4wYWAz
タスクが使われてるからタスクシステムなんて寝言ほざいていいのは小学生までだな
バックエンドの構造は単純にする。これがタスクシステマーのドクトリンなんだよ
タスクシステムのタスクってのは割り込みハンドラとセットで語られるような低レベルのもの
OSなしのプラットフォームでドライバやモニターを全て自前で用意してた。そういう時代のもの。
タスクシステムってのはハードを占有しハードの全てをコントロールするモニタープログラム、
あるいはその中でCPUリソースを配当するモジュール。その中で定義された処理単位がタスク。
serial task。これを非プリエンプティブにスケジューリングして更新。周期駆動。バッチ処理。
ゲームプログラマは天邪鬼。そして気まぐれ。自前で複雑なタスクコントローラを用意しても
みんなでメンテしようなんていう発想は希薄。というかいつ辞めるか分からない他人の作った
複雑怪奇なシステムなんて気持ち悪くておっかなくて誰も使いたがらない。そういう荒んだ
現場は今でも珍しくない。余計な機能なんて誰も欲しがらない。アクターモデルによるイベント
駆動型のシステムなんて論外。だから
>>2 みたいな単純な仕組み、周期的に巡回UPDATE
るだけの自称システムしか共有できなかった。コンセンサスが形成できなかった
みんな自分が大好き。お山の大将。俺が俺が。俺のシステムが一番。そういうものの
共通項を探っていくと
>>2 くらいしか残らない
タスクシステム（
>>2 ）はparallel computingなんて全く眼中に無いな
そんなもんサポートし始めたら排他制御やら何やらで一気に複雑化。
デバッグも複雑化。並列処理なんて後回し。必要に迫られたら
アドホックな付け焼刃な拡張を加えて対応。そういうもの
言葉尻に囚われて、概念的なものを見過ごしてる人たち多すぎwww
×周期的に巡回UPDATEるだけの自称システムしか共有できなかった
>20
25 ：
名前は開発中のものです。 ：2009/08/21(金) 21:03:26 ID:2g4wYWAz
タスクを否定するアンチは阿呆。これは確定。
適当に書きなぐった後に気付いたがコンセンサスが形成できないって
かなり腹痛が痛い話だね。まぁいいか
>>24 このご時世、底辺のヒドイ環境でもなければタスクシステム（
>>2 ）に
スポットライトが当たることはない。周期的に何かのコレクションの
要素を巡回してUPDATE。そんだけ。それ以上もそれ以下もない。
通常なら巨大なミドルウェアの中に埋没し溶けてなくなってしまうような
お話だ。これにスポットライトを当てるってのは一次精度の陽的
スキームで多体系の運動の時間発展をシミュレートする行為に
スポットライトを当てるくらいに退屈な話だよ
引数君とかメリット君が常に嘲笑されているのはそれを理解してる様子が
微塵も感じられないからだろうな。ゲームが作れないクズ、つまり
タスクシステマー以下だと思われてんだからナメられて当然てこと
ナメられたくなかったら頭使ってタスクシステムを否定してみろってこった
裸の王様の見えない服にまた迫がついたのか？（失笑ｗ
>>18 で、なんでタスクシステム＝ファイルシステムなんだい？
そういうことにしたいんだろう？さっさと作文書きなよ：D
前スレでリストを実装できないstl使いの話があったが・・・
うわぁ・・・。ほんとに、「馬鹿には理解できない」と言い続けるしかないんだね。
裸の王様に出てくる仕立て屋ってなかなかの根性だよなｗ
>>7 なるほどな…
それでいつまでたってもメリットが理解できないアンチは最後に「火なんて幻」としか考えられなくなるわけかｗｗｗ
>>24 そんな環境はいっぱいある。
ミリオンタイトルのソースを一度見て見ればあまりの素晴らしさにめまいがするぞ。
美しいコードが面白いゲームを生み出すわけじゃないからな…
33 ：
名前は開発中のものです。 ：2009/08/22(土) 02:16:44 ID:yhBPAMbr
>>26 タスクシステムが脚光を浴びないのはあまりにも基本中の基本だからだろ。
双方向リストに関数ポインタ乗っけるだけでそれっぽいのができちゃうわけだから。
あとはdone()でもabone()でも巡回する奴を作ったり、速度を重視してアロケータもくっつけてみたり、etc。
引数君が嘲笑されるのはベクトルが違うから。
引数君：書き換えが危険？→引数を増やす
普通：アロー演算子書くのが面倒→構造体を使わない→引数が増える
だからメリットを感じないｗ
天才プログラマー要製ギプス
http://www.sun-inet.or.jp/~yaneurao/intensive/ggg/log1.html >私が考える一番エレガントな方法とは、少なくともキャラクターは自立性が有ることです。例えば、
> new CMissile;
>とすればミサイルが生成され、あとはメインのプログラムからは、ミサイルについて意識しなくても済むような設計が理想です。
自立性があるのは結構だが、
最終的にはゲームとして成り立てるためにシステマティックに振舞ってもらわないと困るわけで。
一旦、個を確立させといて、あとから集団として意味づけするのは、
どう考えても2度手間だよな。
こういうくだらないこと書く人に限って
そもそも、キャラクタの自立性を確立するのはとても大変なこと。
自立性のあるキャラクタ云々がそもそもの間違い。
そもそも、キャラクタを自立させることが本当に可能なのかという問題もある。
先の
>>36 の問題をやねうらおがどう解決したのか。
彼は、SEのロードはSEManagerにまかせて、
キャラクタからはSEの番号を指定して再生してもらう方針で難を逃れた。
しかし、これではたしてキャラクタが自立していると胸を張って言えるのかどうか。
自立キャラクタ単体で解決できない問題を～Managaerを作ってそっちに任せるという方針だと、
プログラムはいずれ～Managerだらけになり、しかも、自慢の自立キャラクタは～Managerに
依存しまくりの何がやりたかったのか意味不明状態に陥りそうだが、どうだろう。
また、そこまでして自立キャラクタを作る必要はあるのか。
仕様が明確になってないのをむりやりプログラムで解決しようとするからなぁ
>>38 引数君と同じ考え方だね。
stdoutやheapが使えないタイプ？
まーたやねうらおの自分弄りが始まったのか。本当に気持ち悪いやつだ
キャラクタを自立させるという設計方針でゲームを作ると、
簡単に言うと、俺はやねうらおじゃ無いのに、
>>42 > ただ、他のキャラクタとかかわりを持たなければならない処理が増えてくる段階に入ると、
ほとんどのゲームではかかわりって言ってもコリジョンとサーチぐらいで必要十分な気がするが
そんな多種多様な関係が必要になるケースって何を想定してるんだろうなぁ…
チームワークで動くAIとかか？
具体例プリーズ
具体的に言うと、キャラクタ同士で連携をとるようになってくると、
訂正： 格→各 (眠い・・・)
なんらかの処理を記述するのなら、処理させたい順番にそのままダラダラ書けるのが理想(というか普通)だろう。
>>45 関係の種類じゃなく順番だけの問題なのね。
プライオリティとかスナップショットとかタスク使う解決方法はいろいろあるけど
それ使うより全種類順番に並べた方が良いという考え方ね。
敵の種類が100種類ぐらいいて、ステージや条件によってそのうち何種類かのインスタンスが
生成され、倒されると削除、みたいなケースをそのやり方で作ると…とても理想的なコードにゃならんと思うが。
49 ：
名前は開発中のものです。 ：2009/08/22(土) 04:33:16 ID:yhBPAMbr
キャラクタって概念がよくわかんないんだけど。
要するにクラスのことなんじゃないの？
>>45 def shotgun(pos, vec)
taskA = new RedBullet
setBullet(taskA, timeA, vecA)
/* 略 */
chainProcess(taskB, taskA, taskC, taskA)
こんなもんでいいんじゃないの？
SlimeBeth = new Slime("SlimeBeth.jpg")
SlimeBeth have a shotgun
みたいな書き方で持たせることもできるし。
自立性のほうはどうしてもわからんがｗ
理想的なクラス設計ってことなんじゃないのか？
>>48 お前が今説明した仕様をそっくりそのままコードにすりゃ良いだろ。
仕様とコードが一対一で対応している誰が見ても分かりやすい理想的なコードが出来上がる。
一体何の問題がある？
それに、
>関係の種類じゃなく順番だけの問題なのね。
とも言い切れない。
自タスクだけで完結する処理？タスクのupdateで処理:タスクシステムもしくは～Managerで処理;
だと、タスクシステムに本来の目的とは違う機能がどんどん追加されていって、
いずれなんだか良く分からない謎の「装置」にしたてあがる。
タスクシステムの実装がゲームによりけりで定義がはっきりしないのも、その辺に原因があるのだろう。
タスクが自立して出来そうなことだけをタスクにさせて、それ以外をタスクシステムなり～Managerなりが
タスクの生命維持装置のごとく面倒を見るという自立してるんだか、して無いんだか、
分かりやしない構図は無意味だと思うね。(切り分け的に)
>26
>
>>24 > このご時世、底辺のヒドイ環境でもなければタスクシステム（
>>2 ）に
> スポットライトが当たることはない。周期的に何かのコレクションの
> 要素を巡回してUPDATE。そんだけ。それ以上もそれ以下もない。
その程度のことしかやってないんなら、底辺だね。
まぁ頑張って這い上がってくれ。
>>49 それだと、taskAの同じ処理が二回実行されると思うのだが。
まぁ、それ以前に、chainProcessってのが既にキモいんだが。
処理は、書いた順に実行されるのが一番シンプルで良いだろうに。
なぜ、タスク間のくだらないチェーンなんぞで処理の順番を制御しようという発想が出てくるのか、
理解に苦しむ。本当にその必要があるのか、今一度問いたい。
それでも処理の順序を動的に変更したい場合はあると思うよ。
54 ：
名前は開発中のものです。 ：2009/08/22(土) 07:29:27 ID:d7e04I9F
>>51 まーた
『ボクのエターナルフォースブリザードシステムはそんなもんじゃない。もっとすごい！』
が始まったのか。永遠の小学生だな
>54
>>42 > ただ、先は無いぞ、継続できないぞ、袋小路だぞ、と。
> 某やねうらおの人生も、なんかそんな感じするでしょ。なんとなくなんとなく。
年収何千万もある人の人生が袋小路に見えるのですか。そうですか。
>>50 ”そのままコードにする”って…
「aに１から１００までの数を加算しなさい」って仕様をベタ書きで全部書くとわかりやすい理想のコードという感じかな？
a+=1;
a+=2;
・・・
a+=100;
for 使って i でカウントして…なんて書いてないしわかりにくいから使わない…
って極端だが意味的にはこんな感じに聞こえる。
for使ったコードでも「仕様そのままのコード」だし
タスク使っても「仕様そのままのコード」なんだけどね。
で、forやタスク使ったコードの場合「1から10000に仕様変更」とかでも対応簡単。
なんか全然関係ないこと言い出したなｗ
accumulate(count_upto(1,100), 0, _1 + _2);
>>50 ＞いずれなんだか良く分からない謎の「装置」にしたてあがる。
タスク自体はコンテナでしかない。
それらを扱うための装置がちんぷんかんぷん＝クラス設計gdgdなのが駄目なんじゃないの？
STLやBoostなんて～Manager相当のものがある（らしい）けど、
その設計部分を意識せずともSTLやBoostは扱えるじゃん。例外はあるけど。
>>52 Bの後に1回、Cの後に1回実行するために書いたんだが。
chainは鎖と言う意味で、タスクを鎖のように順次実行する、という意味でもあったのだが。
書いてて思ったんだが、タスクシステムでもなんでもないな。
＞理解に苦しむ。本当にその必要があるのか、今一度問いたい。
デザイナーにも書かせられる程度に設計が楽になる。
ここらへんはクラス設計とかデザインパターンとか勉強してくれｗ
でました裸の王様の仕立て屋
>>57 だからタスカーは根本的にわかってないんだよ・・・
>>7 の原始人相手に「マッチ（タスク）がわかんないなら火打石（for)で説明」なんてしたって同じこと。
アンチのレベルに合わせてfor程度までレベルを下げればいくらアンチでも理解できるだろう、と思ったんだろうけど
根本的に次元が違うんだって。アンチは。
「石？なんかマッチと全然関係ないこと言い出したなｗ」ってなるに決まってるだろ。
関係が理解できるだけの頭があればアンチなんて卒業してるはずなんだから・・・
63 ：
名前は開発中のものです。 ：2009/08/23(日) 01:05:55 ID:sfWgjnCc
>>61 裸の王様の仕立て屋という比喩がいまいちよくわからないのだが。
今一度説明して頂けないだろうか？
>61
>タスク自体はコンテナでしかない。
キャンプ行くのにマッチを持っていった方が良いかどうか話し合ってるときに、
火打石の説明しだすやつがいたら、
「石？なんかマッチと全然関係ないこと言い出したなｗ」
と普通なるわな。
もともと一連の流れの処理を、
わざわざタスクに細切れにして実行順番割り振って処理順をやりくりする
必要があるのかを話し合っているときに、
for文の話しだすやつがいたら、
「全然関係ないこと言い出したなw」
と普通なるわな。
結局、要は、何がどうなっているかというと、つまりはセンスが無い。
短い物差しと狭い価値基準で物事を捉えるから、
全然関係ない話題が同じものに見えたりしてくる。そこが問題。
>>42 でも忠告しておいたのだがな。
人並みのセンスすら有していないから、何聞いても、馬の耳に念仏、立て板に水。
彼らの洗脳が解けることは永遠に無いのだろう。
68 ：
名前は開発中のものです。 ：2009/08/23(日) 05:34:27 ID:sfWgjnCc
>>65 処理と言うか、描画処理だけじゃないの？
うちはコンテナに乗せたデータを描画処理にかける部分と、
コンテナに乗せたデータを操作する部分を独立させてるけど。
そうなると内部的にタスクっぽいけど外部的にタスクに見えないがな。
>タスクはどっちかって言うと処理
>>66 > キャンプ行くのにマッチを持っていった方が良いかどうか話し合ってるときに、
「マッチ？なにそれメリット何？火って何？」
ってアンチがキャンプなんて行けるのかねｗｗｗ
自分が全然関係ない話をしている自覚はあるんだろうか？
>>64 > オマエは別な意味で馬鹿だな。
別な意味ってどんな意味？ｗｗ
良い意味で馬鹿、みたいな？ｗｗｗ
このスレも男女論の「結婚のメリット」スレと同じで不毛な議論エンドレスに続けてるねぇ…
不毛な議論を隔離するためのスレですから。
>タスクは処理だけでもデータだけでもないのでは
>>77 > 何故、処理とデータを一緒くたに制御する必要がある？
OSのprocessにしても、データとプログラムと両方が同じprocess空間上に置かれてますが？
OSのprocessは実行順番で処理順を制御したりしませんが。
基本的にprocess間で協調して動作していく必要もありませんが。
というか、あなたからはOSのprocessとタスクシステムのタスクが同様なものに見えるの？
俺からは両者は単に構造が似てるってだけで、違った目的を持った別物に見えるが。
それにそもそも俺は、処理ではなくて、処理の「制御」について言及しているのだが。
そういう目に見えない抽象概念は理解できませんか、そうですか。
結局、要は、何がどうなっているかというと、つまりはセンスが無い。
短い物差しと狭い価値基準で物事を捉えるから、
全然関係ない物が同じものに見えたりしてくる。そこが問題。
>>43 と
>>66 でも忠告しておいたのだがな。
そもそも、OSのprocessがああいう形をしているのは、
81 ：
名前は開発中のものです。 ：2009/08/23(日) 18:49:59 ID:3ZApiX4t
>>77 実装の方法がいろいろあるからまずいんじゃない？
それと相まって実装方法ごとに信者がいるとしか。
実装方法がいろいろあってもかまわないのだが、
変な話、別々に実装したほうがまだマシという話も。
データシステムの方はそれなりに便利そうだが、制御システムはどう考えても要らないよな。
頭の中だけでプログラムの動きがほとんどシュミレートできるレベルの
86 ：
名前は開発中のものです。 ：2009/08/23(日) 20:24:05 ID:3ZApiX4t
>>84 制御システムがあるから楽に扱えるんじゃん。
利用してる側からだとそのシステムの中身を意識しなくてもよく、
それを扱うための関数だけ知っていれば描画から何まで自動的にやってくれる。
これが利点だよ。
87 ：
名前は開発中のものです。 ：2009/08/24(月) 00:41:51 ID:CPwmHq/c
>>45 タスクシステムのタスクとはシステム内部の実行待ちキューに投げ込む処理単位（タスク）のことだぞ。
> 具体的に言うと、キャラクタ同士で連携をとるようになってくると、
> とたんに処理の順番が問題になってくる。
処理の順番がある → つまり複数の処理ステップがある → つまり複数のタスクがある
ということ。タスクシステムはレディキューに突っ込まれたタスクを順次処理する。問題は無い
> 今、タスクAとタスクBがあって、
> タスクA::処理1→タスクB::処理1→タスクA::処理2 の順番で処理をしなければならないとする。
この時点で既におかしい。
タスクシステムのタスクとはシステム内部の実行待ちキューに投げ込む処理単位（タスク）のことだぞ。
タスク＝OBJとかタスク＝キャラクタではない。これを否定する自称タスクシステムは何かが狂っている
独自進化の果てに分け分からなくなったミュータント
88 ：
名前は開発中のものです。 ：2009/08/24(月) 00:46:15 ID:CPwmHq/c
>>45 だから
処理単位A::処理1
処理単位A::処理2
こんなことはタスクシステムの知ったことではない。意味分かるか？
システムが把握しているのは
「ユーザーがシステムの実行待ちキューにタスクA、タスクBを突っ込んできた」
それだけ。だからタスクAの中に処理1だの処理2だの複数の処理ステップがあるというなら
それはユーザー定義の処理の中のお話。システムが関知するところではない
であるから、タスクシステムのお話をするなら
今、タスクAとタスクBとタスクBがあって
タスクA→タスクB→タスクC の順番で処理をしなければならないとする
こういうことになる。そしてこの場合
実行待ちキューに処理単位Aを追加
実行待ちキューに処理単位Bを追加
実行待ちキューに処理単位Cを追加
こういうこと
>>45 訂正
× 今、タスクAとタスクBとタスクBがあって
○ 今、タスクAとタスクBとタスクCがあって
だったら普通に関数並べれば良いだろ。
知ってのとおり、関数呼び出しはスタックになってる。
92 ：
名前は開発中のものです。 ：2009/08/24(月) 01:08:45 ID:CPwmHq/c
>>90 ゲーム起動から終了まで一貫して
タスクA→タスクB→タスクC
こういう手続きと確定しているならばひとつのタスクにすればいい
わざわざ別の処理単位に分ける必要はなかろ
この処理が常時走ってるならタスクにする必要もなかろ
>90
>こういう手続きと確定しているならばひとつのタスクにすればいい
つまり、処理の順番が動的に変わることを想定しているのだろうが、
だったら、
>>53 だ。
それに、処理の順番なんてそうそう変動するものではないから、
ポイントポイントで局所的に対応しても事足りるだろう。
95 ：
名前は開発中のものです。 ：2009/08/24(月) 01:42:02 ID:cdmKSMxd
>>90 処理は遅延しないよ。
キューの中にあるタスクがすべて実行される。
だから、関数を並べるのと大差ない。
優先順位に注意しつつ普通に関数を並べるか、
動的にタスクを追加したうえで優先順位を付けるかの違いしかない。
>>91 屁理屈に対して屁理屈で返させて頂くけれども、
それだと実行待ちキューを作る必要性について否定できていないけど。
パンはパン屋で作るから自宅でパンを焼く必要はないって言ってるようなもん。
それを応用するのはこっちの勝手だろｗ
>>93 その理論だったら、ゲーム以外のもの作ってるプロジェクトはどうやってるんだって話になる。
プロジェクト管理にタスクシステムが便利だって言うんなら、アプリプログラマ達にも教えてあげたら？
>>95 >処理は遅延しないよ。
遅延するに決まってるだろ。だってキュー使ってるんだから。
遅延しないのは、スタック、つまり関数呼び出しだ。
関数呼び出しは呼び出した瞬間に関数の処理が開始される。
キュー使うと、登録から実行までに遅延が生じる。
といか、遅延を生じさせるためにキューはあるわけで、
それ以外の使い方してるのなら間違ってる。
>優先順位に注意しつつ普通に関数を並べるか、
>動的にタスクを追加したうえで優先順位を付けるかの違いしかない。
だったら普通に書けよっておもうね。
いちいち処理順番割り振って処理順を制御とか、意味無いと思うね。
でもお前らの話聞いてると、どうもキューというより、ただのリストのようだな。
かなり昔の話だがプログラマの新人研修でSTG作れって課題出したことがあったが
100 ：
名前は開発中のものです。 ：2009/08/24(月) 02:11:14 ID:CPwmHq/c
>>94 >>53 > それでも処理の順序を動的に変更したい場合はあると思うよ。
> たとえば、各キャラクタの座標系に親子関係がある場合などな。
> でも、そんな場合でも、キャラクタに据えついた関数の呼び出し順を動的にするんじゃなくて、
> キャラクタが列挙される順番を動的にすべきだろう。
まずはっきりさせておくが
座標系（フレーム）の親子関係なんざユーザー側で作り出した勝手な都合であり
タスクシステムの実行待ちキューが関知するお話ではない
座標系の親子関係を表すのはタスクシステムの実行待ちキューではなく
例えばシーングラフの中のツリー構造。処理するフレーム・処理する順序を
決定するのはシーングラフのトラバーサ
これを否定する自称タスクシステムは何かが狂ってる。欲張りすぎ、でしゃばりすぎ。
タスク＝OBJという勝手な固定観念に縛られ独自進化を遂げた分けの分からない
ミュータントを使ってるとタスク＝フレーム（座標系）みたいなお話になってしまう
やねうらお状態ってやつだ
× シーングラフの中のツリー構造
>>100 いや、お前の言いたいことは分かるが、その主張は俺も
>>82 とかで述べてるので。
>タスクシステムの実行待ちキュー
ただの処理リストの癖に。
ところで、プログラムのことプログラムリストって言うでしょ。
リストを重複して持つなんて無意味だね。
103 ：
名前は開発中のものです。 ：2009/08/24(月) 02:25:16 ID:cdmKSMxd
>>97 ＞登録の遅延
ポインタの移し替えだけなので10行以内に落とせる。
登録作業もnewを使わなければ誤差にすらならない。
＞遅延を生じさせるためにキューはあるわけで
じゃあ、STLのキューは遅延を生じさせるためのキューなの？
ベル研究所とANSI/ISOは間違ってることでOK？
＞だったら普通に書けよっておもうね。
書いてあるよ。クラスの中に。
>>98 リストだよね。
なんでキューになっちゃったんだろorz
タスク＝処理関数ポインタ＋ワークエリア とある
>>103 何分けのわからないこといってるんだよ。
std::queue<void (*)()> task_queue;
task_queue.push( func ); //登録
・・・//実行まで遅延
while( queue.empty() )
{ task_queue.front()(); task_queue.pop(); } //実行
・タスク＝処理関数ポインタ＋ワークエリア
108 ：
106 ：2009/08/24(月) 03:03:45 ID:lqgMscfV
訂正： while( queue.empty() ) → while( !queue.empty() )
>>103 あと、多分だけど、
>>100 はタスクシステムを処理実行の遅延目的で使ってる。
トラバースして処理を一旦バッファに蓄え、最適化した上で実行するためだろう。
CPUのアウトオブオーダーのような感じ。
制御目的でなく、最適化目的なので、こういうのは個人的にOKかな。
ただ、それをタスクシステムと呼ぶのは個性的過ぎると思うが。
制御は１回きりじゃなく何回も繰り返すんだからリストに追加させるのが普通だろ
void update()
>>106 そういう意味か。ごめんね。
実行速度のこと言ってるのかと思ったｗ
あとキューも自分で言っておきながら間違ってた。
タスクはキューじゃない。面倒くさいことさせて申し訳ない。
一応確認しておくけど、
タスクシステムはオブジェクトが持つ描画関数をタスクの中に保持し、
適当なタイミングでタスクごとに優先順位を考慮しながら描画する。
こういう認識をうちはしてるけど、君はおｋ？
訂正
オブジェクト１つ１つをそれぞれタスクに割り当てれば
面倒だから、俺のやり方を紹介。
//↓orderly～orderly_end間は順番に処理してね、とお願いする
orderly( updating_order/*←
>>100 で言うところのトラバーサの役目*/ )
{
//↓型列挙
each_type( player/*←型名*/ )
{
//この中にplayerの処理を書く。
player_.x+=2; player_.y+=1;//etc
}
each_end
each_type( enemy )
{
//この中にenemyの処理を書く
//インスタンスが複数ある場合は並列実行
enemy_.x+=10;
}
each_end
・・・
}
orderly_end
>オブジェクト１つ１つをそれぞれタスクに割り当てれば
>>118 そうか？
>>117 のような書き方をすると、
player/enemy構造体のメンバすべてがpublicにする必要があって、
内部的な状態も何もかもpublicになっていて凄く気持ち悪いんだけど。
タスクかキャラクターに対してひとつのオブジェクトが割り当たっているというのは
OOPの設計的には、比較的まともだと思うけどな。
>>45 > タスクA::処理1→タスクB::処理1→タスクA::処理2 の順番で処理をしなければならないとする。
> そうすると、タスクに据え付いた一つのupdate関数だけで対処するのは厳しい。
典型的なタスクシステムはタスクに対してpriorityを持っていて、それによって実行の優先順位を管理できるようになっていますが？
配列の添字がpriorityを表現するんですね
>96
>>121 いや…タスク自体に持たせてあるだろ。
古典的なタスクシステムでは必ずと言っていいほど持っていると思うが。
タスク基底クラス、普通はこうなってないか？
class ITask
{
public:
int priority;
virtual ~ITask();
}
124 ：
名前は開発中のものです。 ：2009/08/24(月) 06:16:16 ID:cdmKSMxd
>>107 ＞制御構造とデータ構造をごったにしている時点で糞
クライアント側から煩わしい処理を隠すため。
描画、移動、当たり判定処理などはクライアントに見せる必要はない。
＞動的に処理リストを生成する必要が本当にあるのか
一番顕著なのがSTG。敵キャラクターが大量の弾を発生させるとき。
他にもレベルデザインに特化させるため、処理順という概念を無くすため。
（要するに、データ入力やキャラクターの構築をし易くするためってことだな）
＞タスクという名前がおかしい
慣習だから仕方ない。
>>115 更新忘れて偉い前後してる。
けど眠いからもう寝る。
タスクシステムは簡単すぐるので技術的な話題はない
>>123 その古典的なタスクシステムだと、
> タスクA::処理1→タスクB::処理1→タスクA::処理2 の順番で処理をしなければならないとする。
> そうすると、タスクに据え付いた一つのupdate関数だけで対処するのは厳しい。
は実現できない。
タスクAの処理1をした後に、タスクBの処理をし、もう一度タスクAに立ち返り、
今度はタスクBの処理が終わってからでないと実行できなかった処理2を実行する。
こういった動作は、
>>2 で示されるような古典的タスクシステムでは対応できない。
なぜなら、priority(というかorderが適切だろJK)が一種類しかないから。
一方タスクシステムを使わないで書くと、
タスクA.処理1();
タスクB.処理();
タスクA.処理2();
たったこれだけのこと。
たったこんだけの制御すらままならない、それが古典的タスクシステム。
>113
タスク処理2をタスクCに分けて
129 ：
名前は開発中のものです。 ：2009/08/24(月) 22:38:55 ID:cdmKSMxd
>>126 タスクシステムだってなんでもかんでも関数乗せればいいってわけじゃないよ。
普通、そういう処理はタスクに乗せず、別の場所でやるもんだし、
システム自体、毎フレームごとに一定の処理を行うためのようなもんだから。
回転ずしで皿の上に鉋が乗ってたらおかしいでしょ？
関数ポインタ渡せば何でもかんでも処理を行ってくれるからと言って、
好きな関数を乗せていいわけでもない。
>>126 > priority(というかorderが適切だろJK)
タスクシステムは、もともと画面上に表示するスプライトのようなことをソフトウェアで実現する狙いがあるわけで、
スプライトの優先順位(priority)から名前をもらうことがある。だからorderという名前が適切とは限らない。
> タスクA.処理1();
> タスクB.処理();
> タスクA.処理2();
タスクAの処理1と処理2がそれぞれ何なのかよくわからない。実際にゲームでそういうのが必要になる
ケースが想定できないのだけど、どういったケース？
タスクA.処理2 を別のタスクとして、登録しとくだけの話だけど。疑似コードで書くと次のような感じ。
class TaskA
{
class Task処理1 : public ITask { virtual void update() { ... }; }
class Task処理2 : public ITask { virtual void update() { ... }; }
TaskA() { Task処理1とTask処理2をタスクシステムに登録(); }
}
delegate(or boost::function)を登録するタイプのタスクシステムならそのdelegateを
直接登録しとけばいいわけだし。
そんなわけで、古典的タスクシステムでも実現できる。
>130
>127
>タスクAの処理1と処理2がそれぞれ何なのかよくわからない。実際にゲームでそういうのが必要になる
>ケースが想定できないのだけど、どういったケース？
たとえば、updateと描画。体外の古典的タスクシステムは、updateとdrawを持ってる。
updateの中で描画するわけには行かないからな。
>>130 の言うところのタスクシステムは、その実、単なる関数ポインタのリストのようだけど、
だったら普通に書けと思うね。関数の中に関数の呼び出し並べれば、それは関数のリストなわけで、
わざわざタスクシステムとか作る必要あるか？参照
>>107 >>131 >>2 のような古典的タスクシステムではと前置きしているだろうに。
タスクシステムが制御の管理とオブジェクトの管理までするって言うんなら、
>>133 > たとえば、updateと描画。体外の古典的タスクシステムは、updateとdrawを持ってる。
updateとdrawを二つわけたいなら、タスク基底クラスが
class ITask
{
virtual void draw(const DrawContext& context) = 0;
virtual void update() = 0;
virtual ~ITask() {};
};
こうなっているべきだと思うけどな。
>
>>130 の言うところのタスクシステムは、その実、単なる関数ポインタのリストのようだけど、
関数ポインタのリストではない。
>>123 のようになっている。
>>123 が関数ポインタのリストに見えるなら C++初心者だと言わざるを得ない。
> 関数の中に関数の呼び出し並べれば、それは関数のリストなわけで、
それだと動的に変更できない。タスクAがつねにタスクBのupdateより先行するとは限らない。
また、タスクAのインスタンスがつねに存在するとは限らない。だから固定して並べることは出来ないし、
事前に記述することも出来ない。
>>135 俺も関数ポインタのリストにしかみえないけどな
やってることもそれ以上の効果ないだろ
>>134 > タスクシステムが制御の管理とオブジェクトの管理までするって言うんなら、
> そんな制御構造とデータ構造ごっちゃにしたもの糞だし、
ITaskがタスク基底クラスだとして、タスクシステムが std::list< ITask* > を持っているなら、
タスクシステムはこのlistをtraverseしてupdateを呼び出すのだから、そのupdateのついでに
死亡フラグの立っているタスクを除去(delete)するのは普通の作りだと思うけどな。
タスクシステムがタスクの除去(delete)を管理する以上、タスクシステムが生成を管理していても
おかしくないので、factoryなりbuilderなりをタスクシステムに持たせるのも、よくある実装だと思うけど。
これをまあ、分離してもいいけど、普通分離する必要がないし、面倒だから分離しないと思うけどな。
これを分離しないことでどんなデメリットが生じる？
>>136 > 俺も関数ポインタのリストにしかみえないけどな
> やってることもそれ以上の効果ないだろ
ITaskに仮想デストラクタのplace holderがあることを見てもわかるように、
タスクシステムが ITask派生クラスを安全にdeleteすることが出来る。
単なる関数ポインタとは雲泥の違い。
ひょっとして、ID:7Ki+VW24もID:B8qWF4q6もとんでもないC++初心者なのか？
だとしたらもう話している前提が違うとしか言いようがない。
>>139 意味がわからない。
ITask* なのだから、タスクシステムに、これらのオブジェクトを解体( delete )する権限と責任を持たせることが出来る。
これが単なる関数ポインタ(ex. boost::function )だったとしたら、別途、オブジェクトのstd::listのようなものを持たせない限り、
タスクシステムにオブジェクトの解体をさせることが出来ない。
まあ、オブジェクトの生成/解体を別のところで管理させてもいいけど、それは結局、std::listの無駄使いだと思う。
>133
>
>>131 >>2 のような古典的タスクシステムではと前置きしているだろうに。
2つのタスクが1つのワークを指すようにポインタでつなぐとか考えないの？
何のために汎用ワーク持ってると思ってる？
>134
> タスクシステムが制御の管理とオブジェクトの管理までするって言うんなら、
> そんな制御構造とデータ構造ごっちゃにしたもの糞だし、
> タスクシステムが制御の管理しかしないっていうんなら、
> 存在価値が無いし、
> もう駄目だね。
>133で
>
>>131 >>2 のような古典的タスクシステムではと前置きしているだろうに。
とワザワザ強調しているのに、>134では「タスクシステム」一般にまで話を拡張しちゃうのか。
アタマ湧いてる？
>>141-142 なんか、私の直後に ID:Dhj5jDfF の書き込みがあって、なんか私がID変えて自演してるかのようで
少し悲しい気持ちになった。
いや、いいんだけどね・・・
>>140 だからぁ
この場の話には関係ないでしょ？それ
>>140 何度でも言うが、あんたは何が言いたいのか意味がわからない。
>>136 で、
> 俺も関数ポインタのリストにしかみえないけどな
> やってることもそれ以上の効果ないだろ
と言うから、
・タスクシステムがタスクを安全にdeleteできるという効果がある(
>>140 )
と私は言ってるだけなんだが。
それに、ITaskは、
>>123 に書いてあるように priorityを持っているから、
これに従ってタスクシステムがorderingすることができる。std::list<boost::function>ではこうはいかない。
これが、「この場の話には関係ない」と言うなら、どこがどう関係ないのかハッキリさせてくれないか。
少なくともタスクシステムの実装なのだから、「この場の話」と関係があると思うが。
146 ：
名前は開発中のものです。 ：2009/08/25(火) 08:01:01 ID:mayB8LIz
だから君の主張したいことってこの場の議論に全く関係無いじゃん
>>146 それなら最初からそう言えばいいのに。
>>136 の書き方ではとても読み取れない。
片言の日本語でレスするのは勘弁しとくれ。
それで内容についてだが、
> その実装方法が仮想関数でも関数ポインタでもとりあえずこの場の話では違いがないよね
これについては、
>>145 で書いたが、
> ITaskは、
>>123 に書いてあるように priorityを持っているから、
> これに従ってタスクシステムがorderingすることができる。std::list<boost::function>ではこうはいかない。
である。
だからlist<ITask*>は、単なる関数ポインタ列ではない。
タスク(ITask派生クラス)側の意志によって、呼び出し順序の変更が可能な関数ポインタ列。
前者と後者とでは全然違うと思うのだが。「この場の話」ってなんだと思っているんだ？
>>120 であり
>>45 だろ？
>>45 を議論するのにタスク側がpriorityを持てるかどうかがとても重要なんだが、何故それが関係ないと思えるんだ？
148 ：
名前は開発中のものです。 ：2009/08/25(火) 08:37:05 ID:mayB8LIz
関数ポインタだともてないとでも？
関数ポインタのリストだとそれも持てないし大体各オブジェクトの座標とかも持てないじゃん
>>148 > 関数ポインタだともてないとでも？
std::list<pair<boost::function>,int priority >> となっているなら話は別だけど、これは「単なる関数ポインタ列」ではないよね。
あと、こう実装してしまうと、priorityの制御が呼び出される関数側で出来なくなってしまう。
>>123 より数段劣る実装だろう。
このスレのアンチタスク派って、なんだかゲーム作れるのか
>>137 > タスクシステムがタスクの除去(delete)を管理する以上、タスクシステムが生成を管理していても
> おかしくないので、factoryなりbuilderなりをタスクシステムに持たせるのも、よくある実装だと思うけど。
...
> これを分離しないことでどんなデメリットが生じる？
「factoryなりbuilderなりをタスクシステムに持たせる」ってことは、生成される
具体的なクラスを全部システム側が知ってるとか、そういう状況にならない？
そうなるとあからさまに面倒だと思うんだけど。
そういう状況は回避するように策が打ってあるとしたら、それはそれで面倒な
ような気もするし。
っていうか、管理する理由が「管理していてもおかしくない」からっていう
いいかげんそうなやつなのに、それをやめるほうには「管理してなくても
おかしくないから」とかじゃなくて具体的なデメリットが要るの？おかしくない？
>>152 > 「factoryなりbuilderなりをタスクシステムに持たせる」ってことは、生成される
> 具体的なクラスを全部システム側が知ってるとか、そういう状況にならない？
そりゃもちろん、その場合はタスクシステムに事前にfactoryを登録するんだよ。
だからタスクシステムは具体的なクラスは一切知らなくていい。
> 管理する理由が「管理していてもおかしくない」からっていう
> いいかげんそうなやつなのに、それをやめるほうには「管理してなくても
> おかしくないから」とかじゃなくて具体的なデメリットが要るの？おかしくない？
いい加減な理由じゃないよ。ITaskの派生クラスの生成と解体を管理するために
別途 std::list<ITask*> をタスクシステムとは別のところで用意するとしたら、
それは、二重に std::list<ITask*> を持っているという資源の効率的なデメリットが
あるから、それなら、flexibilityを多少犠牲にしてでもタスクシステムの std::list<ITask*>で
一本化するのは「おかしくない」と言ってるんだ。
メリットも動機もとても具体的だと思うんだが。
>>152 > そういう状況は回避するように策が打ってあるとしたら、それはそれで面倒な
> ような気もするし。
std::map<type_info , boost::function(ITask* ()) > こんな感じになっていて、class IDに対応する
タスククラス(ITask派生クラス) を new して返すような factory methodを持っていればいいだけだ。
生成したいときは、タスクシステムに対して
taskSystem -> AddTask( typeof (HogeTask ) );
にようにするだけだ。 あるいは、AddTaskをtemplate methodにしていれば、単に
taskSystem -> AddTask( HogeTask );
と書くだけだ。
これの何がどう面倒なんだ？
>>152 ついでに言えば、
>>154 は、次のようなマクロを使ってさらに簡略化されていると
使い勝手はいいかも知れない。(このソースを読む第三者的には嫌かも知れないが)
#define newTask(CLASS) taskSystem->AddTask(CLASS);
また、実際は、各タスクが、taskSystemへアクセスするには、mediator的なものがどこかに必要になる。
具体的には、ITask::updateの引数として受け渡すだとか、ITask自体にTaskSystem*を持たせるだとか。
>>153 すばやいレスありがとう。
うまく伝わらなかったようで、ごめん。
std::list<ITask*> をどこにどう持つかは関係なくて、問題だと思ってるのは
「生成を管理」することね。
生成を管理しない状態として想定してるのは、 System.Add(new MyTask(...)) と
要素を追加できる状態。
それに比べたら生成を管理するためにファクトリを登録するだとか >153-154 とか
の方法は、全部なにかしら（比較すれば）面倒になってるよね？
で、その面倒な状態にする理由が今のところ「おかしくないから」しか挙がって
ない。それじゃ利用者が不便になってるだけじゃない？
>>151 それ言ったらここに書いてる人全員ゲーム作れるのか怪しい。
動くサンプルを出す人はいないし。
お前ら本当にそんな実装してんの？いつもの釣りじゃねえの？
>>156 > それに比べたら生成を管理するためにファクトリを登録するだとか >153-154 とか
> の方法は、全部なにかしら（比較すれば）面倒になってるよね？
いや、ユーザーは(タスクシステムの外に)deleteは、
一切書かなくて済むようになるからソースコードは大幅に簡略化されると思うのだけど。
factoryの登録は各タスクに対して1回で済むけど、普通のゲームでは、オブジェクトをdeleteするコードは
いたるところに散乱するのが普通だし、ひとつのクラスに対して記述するdeleteの回数は半端じゃないのが普通だろうから、
それからすれば、1回のfactory登録だけであとはdeleteから逃れられるのは大きなメリットだと思うけどな。
結局、タスクというかオブジェクトの生成～解体まで誰が面倒を見るのかということだと思うよ。
それはタスクシステムを使おうが使うまいが関係なく、C++ではこの問題がずっとつきまとう。
タスクシステムを採用するっていうなら、タスクというオブジェクトの生成/解体責任まですべてこの
タスクシステムが担ってくれれば、タスクシステムのユーザーは、タスクの生成/解体責任から逃れられる。
タスクシステムを使わなくても書けるだろうし、ゲームの種類によっては、タスクシステムが邪魔になることはあるだろうけど
少なくともタスクシステムが生成と解体の面倒を見てくれる限りは、deleteの呼び忘れみたいな問題はほとんど起きない。
>>158 あと factoryの登録も、ITask派生クラスはdefaultでは登録しないでも使えるようにしておく。
例えば、factoryが登録されていないクラスでも newTaskできるようにしたいのであれば、
template <class T> ITask* newTask(T)
{
ITask* task = dynamic_cast<ITask*> ((void*) ( new T() ) );
assert(task!=null);
return task;
}
のようにdynamic_castに成功した場合のみに限れば良い。
これなら、ITask派生クラスはタスクシステムに対して事前にfactoryを登録する必要すらない。
Ｃ＋＋を熟知してないと実装が面倒だ
>>160 C++を熟知している必要は全くないと思うが、最低限、templateの基本的な使い方とRTTI、dynamic_castぐらいは
C++の入門書にでも載っているのだから知っておいてもらいたい。
あと、現場では、タスクシステムのようなライブラリっぽい部分は熟練プログラマが作って、
それを使う部分は、下っ端のプログラマが作ることが多いので、タスクシステムの実装は別に
複雑であろうが、実装が難しかろうが、templateを駆使してあろうが、全く問題ないと思うけどな。
(あくまで実際の現場では、だが)
せっかくだからトリップつけた。
本職の人？
>>159 そのdynamic_castってコンパイルはエラーを素通りさせて
実行時にassertで捕まえるためのもの？
いまいち理解できない orz
>>164 > そのdynamic_castってコンパイルはエラーを素通りさせて
「エラー」という場合、コンパイル時のエラーと実行時のエラーとがあると思うのだが、
おっしゃる通り、コンパイルエラーにはならず、assertがあるのでタスク(ITask派生クラス)以外を
生成しようとすると、実行時エラーになる。
これを静的に(コンパイル段階で)検出しようと思えば、
templateに対して、T が ITask派生クラスであるという制約を書く必要がある。
C#ならwhereで簡単に書けるが、C++でこれを書くのは少し難しい。
C++なら、boost::enable_if とか C++ conceptならrequiresを使って書く…んだろうなぁ。
まあ、なにせそんな事情でややこしいことに触れたくなかったので、実行時エラーでお茶を濁したわけだ。
キャスト使わなければ自動的にコンパイルエラーになると思うんだけど
>>166 ああ、まあ、それはそうなのだけど、うーん。私の書き方が悪かったな、これは。
つまり、私は代入するところでコンパイルエラーになるのではなく、
newTaskの呼び出し側でコンパイルエラーの表示がされて欲しいんだよね。
そのためには呼び出し側に、このtemplate methodは、ITask派生クラス以外は引数に
とれませんよと明示してやる必要があるのだけど、それを表明する手段がC++だと
とても難しいと言いたかったんだ。
エラーの表示位置が気に入らないからコンパイルエラーを素通りさせるってこと？
>>168 実行時エラーなら、スタックフレームから、どこで呼び出しているかが簡単にわかるから。
まあ、そのへんは単なるデバッグの方法論というか個人的な趣味なのであまり気にしないでちょうだい。
(JavaScriptのような言語をずっと触っていると実行時エラーのほうが自然に思えてくるというのはある。)
なるほど JavaScriptか
テンプレートパラメタの型がITaskの派生であることぐらいなら
タスクシステムを使っても使わなくても
あの・・・
>>2 ではboost使ってないんですが・・・
キ・・・
仮に自機のクラスから敵、敵のクラスから自機の情報が必要になったらどこに記述すればいいの？
よう boost使い
さらにC++0xで追加されるValiadic TemplateやRvalue Referenceを使えば
>>154 で言われる「生成を管理しない状態」はほぼ達成できそうだ
これぐらいならC++2003のとboostでエミュレートできる範囲でも頑張れば実装できる
ただし、こんなものは問題の極一部だろうし、タスクシステムとはあまり関係のないものだと思ってる
#include <boost/mpl/assert.hpp>
#include <boost/type_traits/is_base_of.hpp>
#include <boost/tr1/memory.hpp>
namespace tr1 = std::tr1;
struct ITask {};
struct CTask : public ITask {};
struct CTaskFromArg : public ITask {
CTaskFromArg(int){};
CTaskFromArg(int,const char * const){};
};
struct NotTask {};
template <class T, class... Args>
inline tr1::shared_ptr<T> my_new(Args&&... args) {
BOOST_MPL_ASSERT_MSG((boost::is_base_of<ITask, T>::value), ERROR_MSG, (T));
return tr1::shared_ptr<T>(new T(std::forward<Args>(args)...));
}
int main()
{
typedef tr1::shared_ptr<ITask> task_t;
task_t x = my_new<CTask>(); task_t y1 = my_new<CTaskFromArg>(1); task_t y2 = my_new<CTaskFromArg>(1,"foo");
// task_t z = my_new<NotTask>();
}
>>175 情報はデータベースで一括で管理して
タスクの中からそれらの情報に問い合わせるようにすればいいんじゃない？
問合せ元のタスクによってアクセス制御を静的にかけることも一応は可能だし
不要な情報を書き換えるバグを防ぐような対策もできるし
デバッグ実行時にログを取る際にも柔軟にできると思う
>どこに記述すればいいの？
英語にすると
184 ：
名前は開発中のものです。 ：2009/08/25(火) 21:26:26 ID:PL5QMpbV
>>182 ！
あんたがそれをできるように作ればいいんじゃね？
俺も同意見で どこに記述すればいいのか不思議でね
>>158 またもすばやいレス、ありがとう。おそくなってごめんなさい。
>> それに比べたら生成を管理するためにファクトリを登録するだとか >153-154 とか
>> の方法は、全部なにかしら（比較すれば）面倒になってるよね？
>
> いや、ユーザーは(タスクシステムの外に)deleteは、
> 一切書かなくて済むようになるからソースコードは大幅に簡略化されると思うのだけど。
またまたうまく伝えられなくてごめんなさい。 delete についてはシステム内で
済ませてくれると想定しているよ。
そのうえで、生成を管理する・生成を管理しないのどちらがいいという
問いかけを
>>156 (
>>152 ) でしたつもりだった。
で、その後の流れを読んでもやっぱり生成を管理することにした理由が
「してもおかしくない」しか見当たらなくておかしいように思う。他に何か
理由があったんじゃないの？
187 ：
名前は開発中のものです。 ：2009/08/25(火) 23:03:19 ID:PL5QMpbV
>>185 そもそもどこに記述したいのかわからない。
クライアント側の利用の仕方を教えて欲しいのか、開発側の作り方を教えて欲しいのか。
わからないから空気読んで開発側の話をするけど、
まず基本クラスに必要な値を決めておき、それぞれゲッタとセッタを用意する。
タスクに乗せるのはその派生クラスと言うわけだ。
制御側ではタスクの登録と線形処理・探索を行う処理を書いておく。
線形処理・探索とは具体的に言うと、描画処理や当たり判定処理だな。
＞不思議でね
理解できないからと言って理解できないとゴネられても困る。
ゴネるんならコードの一つや二つぐらい書いてから言ってくれ。
>152
189 ：
名前は開発中のものです。 ：2009/08/26(水) 00:31:01 ID:Jc1aOsD2
それはどんなプログラムだろうと関係あることじゃん。
>>179 したら自機クラスに敵クラスの処理があるの？
敵クラスに自機クラスの処理があるの？
どっちか片方しかいらん場合どっちに記述するの？
>>173 > あえて言うなれば、「僕、僕、こんなすごいオナヌー知ってるんだあぁぁぁぁぁ」って感じ
C++の教科書に書いてある程度のことを超絶テクニックかのように言われても困るんだけどな。
アンチタスカーはC++の基本すら知らないのか。そりゃ話にならんはずだわ。
>>174 >
>>2 ではboost使ってないんですが・・・
使いたければ使えばいいし使いたくなければ使わなければいい。
例えば、boost::functionなんかは、C++0xでC++標準になるぐらいC++使いにとってはスタンダードなものであって、
これを何か特別なものかのように言われてもなぁ・・。
>>175 > 仮に自機のクラスから敵、敵のクラスから自機の情報が必要になったらどこに記述すればいいの？
接触判定のように自機と敵クラスの集合との相互干渉による振る舞い(behavior)を書きたいのか、
それとも、単に、敵が自機をめがけてホーミングのような行動をするから自機の座標が取りたいだけなのかどちらだ？
前者と後者とでは全然意味が違うんだけど。
>>176 > よう boost使い
> お前 small talk 知らないだろ？
> 車輪の再開発だよ
> 熟知はしてるようだが
> バ○にしか見えない
boost使いというのは、ID:i74J/de4のことだと思うが、
なんかあんたの煽りのレベルは低いぞ。
そんなレベルの煽りがしたいなら、私も次のように煽り返しておこう。
small talkなんて言語はねーよ。Smalltalkだろ？
言語名も正しく知らない奴が知ったかすんなよｗｗｗ ばーか
>>177 >
>>154 で言われる「生成を管理しない状態」はほぼ達成できそうだ
154を書いたのは私だが、すまないが、
>>177 では何をしたいのかいまひとつわからない。
もちろん、
>>177 のソースの振る舞い自体は私は理解できる。
「生成を管理しない状態」というのが私と認識が違うのかも知れない。
「生成を管理しない状態」について、あなたの認識を聞かせて欲しい。
> これぐらいならC++2003のとboostでエミュレートできる範囲でも頑張れば実装できる
C++2003というのは、Visual C++ 2003？ なぜに2007ではないの？
2003って結構templateが、C++標準に準拠してなくて嫌なのだけど。
>>179 > 情報はデータベースで一括で管理して
> タスクの中からそれらの情報に問い合わせるようにすればいいんじゃない？
うん、そのデータベースとしての機能をタスクシステムに持たせるような実装にするなら、
例えば、型を指定してそのタスクの集合を取り出せればいいということになるな。
var enemies = taskSystem -> getTasks<IEnemy>();
こんな感じだな。getTasksでは、std::list < ITask* >を持っているわけだから、こいつを辿って、
dynamic_castに成功したものの集合を返せばいいわけだな。
疑似コードで示すと次のようになる。
template class <T> std::vector<T> getTasks()
{
std::vector<T> tasks;
foreach(var task in taskList) if (dynamic_cast<T>(task) != null ) tasks.push_back(task);
return tasks;
}
>>193 どっちでも同じじゃない？
関連するもの全部言ってよ
自機と敵の接触とホーミングみたいなもん両方どうやって表現してんの？
仮に自機タスクに敵、敵タスクに自機の処理が必要になっちゃうと
切り離したいときに自機クラス移動したら敵クラスも必要になっちゃうし
敵クラスだけ動かそうとしたら自機クラスまで必要になったりとカプセル化ぶっ壊れてると思う
>>185 > 情報はデータベースで一括管理というが、
> このデータベースもタスクシステムで作られているのか
> そこもまた不思議でね
タスクシステム内に作ってもいいと思うけどね。
タスクシステム外に作ってもいいだろうし。
タスクシステム内に作る動機としては、タスクシステム自体が std::list<ITask*> を持っているということに尽きる。
これと同じ構造のものしかいらないのなら、二重に持つのは資源の無駄だから、タスクシステム内にあるのが自然だ。
std::list<ITask*> より、もっとqueryに迅速に応答できるような構造を用意したいなら、タスクシステムのなかに
ある必然性はあまりない。
タスクの生成自体をタスクシステムで一元管理しているなら、生成のついでにそのタスクをデータベースに登録できるので、
タスクシステム内にあったほうがソースはシンプルになるというのはあるだろうけど。
何が良い実装方法か、なんてゲームの仕様や実行環境によって全然違うものになるだろうに…
>>200 > どっちでも同じじゃない？
全然同じじゃない。次の3パターンがある。
■ オブジェクトの寿命が事前に確定している場合
例えば、自機はホーミングクラスより必ず寿命が長いことがわかっているなら、
ホーミングクラスは単に自機クラスのオブジェクトへのポインタをメンバとして持てばいい。
自機クラスのオブジェクトをどこからもらうかと言えば、
>>197 のようなデータベースかタスクシステムからもらえばいい。
■ 特定のインスタンスを参照したいだけの場合 で かつ、オブジェクトの寿命が事前に確定していない場合
この場合は、参照先のオブジェクトが先にお亡くなりになると不正なポインタになってしまうことがあるので、
boost::shared_ptr のようなもので持っておき、お亡くなりを検知するか、あるいは、Handle化する。
(Windows APIでよく使う、あのhandleだ)
Handle化は、タスクシステムとは無縁のテクニックだから、このスレとはあまり関係ない気もするが、
一応解説する。
typedef TaskHandle ulong;
std::map < TaskHandle , ITask* > handleToTask;
こうね。こうしておいて、敵のTaskHandleを自機クラスがメンバとして持っていればいい。
TaskHandleは、newTaskのときに割り当てるといいと思う。
■ あるクラスのインスタンス集合を参照したい場合で、かつ、オブジェクトの寿命が事前に確定していない場合
アクセスしたくなるごとに、毎回、
>>197 のようなデータベースかタスクシステムからもらえば、
その描画フレーム内は、相手タスクがお亡くなりになることはないだろうから、参照の安全性が保証される。
>>202 > 目的もないのに正しい方法なんて議論しても時間の無駄
アンチタスカーの主張は、タスクシステム自体が無駄で意味のないものだと言うから、
ある特定の状況ではタスクシステムが有効に働くことを私は一連の書き込みで示しているつもりなのだけど。
>>188 > 何をいつ作って何をいつ破棄したか、何がどれだけの時間残ってるのか、きちんと管理
> してないと、バグチェックが辛いぞwww
生成のタイミングは確かに重要なのだけど、破棄されるタイミングというのは、あまり重要じゃないんだよね。
例えば、JavaやC#のようにGarbage Collection(以下、GC)のある言語だと、破棄タイミングはユーザーが規定できない。
「どこからも参照されなくなれば、そのうち破棄されるよ」というだけ。
タスクシステムを使った場合も、死亡フラグが立って明示的に削除される場合は別として、
あと、root object(これらは外部から参照されていなくとも削除されない)も除外するとして、
参照が解除されるかしたときに、自動的に解体するような仕組みが組み込まれていてもいいと思うんだけどね。
まあ…シューティングゲームなんかだと、画面上のほとんどの描画物のタスクがどこにも依存していないので
root objectということになるんだろうから、こういう設計はゲームによって向き/不向きがあるだろうけども。
>>204 まともな頭を持ったプログラマならアンチタスクなんかにならんよ。勝ち目がないから。
タスクに有用性があるということを示したければ有用な条件で動く例を一つ出せば証明できる。
反対にタスクに有用性がない、ということを証明するためには、存在する全てのケースで
有用ではないことを示さなければならない。これは悪魔の証明でアンチに勝ち目は無い。
なのでアンチってのは、示されたタスクの有用性を全て「はぁ？僕ちゃん理解できませんｗｗ」と
相手が根負けするまで白痴のふりをしてとぼけ続けるか、関係ない揚げ足を取って話をはぐらかす
ぐらいしかできない、勝てない戦いを続けるお馬鹿さん。
>>186 > で、その後の流れを読んでもやっぱり生成を管理することにした理由が
> 「してもおかしくない」しか見当たらなくておかしいように思う。他に何か
> 理由があったんじゃないの？
生成をタスクシステム側で一元管理しようという話になった。(
>>154 )
ようするにたった一つのmethodを生成の入り口として、この入り口を通過しないとタスク(ITask派生クラス)は
生成できないということにした。
こうしておくメリットは、すべてのタスクの生成の首根っこを押さえてあるということ。
例えば、データベース(
>>179 ,
>>197 )を作って、そのデータベースから
ある条件に合致するタスク集合(ITask* の std::vector )をもらおうとしたとき、
そのデータベースは現在生成されているタスクを知っていることが大前提となるけど、
タスク生成にはひとつの入り口しかないので、ここでデータベースへタスクを
登録する作業をしておけば、生存しているタスクの列挙漏れは起こらないことが保証される。
このように、何らかのqueryでタスクを列挙することを考えると生成が
一元管理されていることは必須条件であって、生成の窓口の一本化は、これを見越してのこと。
>>206 > タスクに有用性があるということを示したければ有用な条件で動く例を一つ出せば証明できる。
まあ、そうやってタスクシステムを使って書かれたプログラムと、
タスクシステムを使って書かれていない等価な処理を行なうプログラムとで
どらちが良いかというのを比較しようと思うと、それなりの規模のシステムじゃないと
適切に評価できないというのはあるような。
例えば、
>>2 のCodeZineのタスクシステムでは、私にすら全然メリットが伝わってこないというか、
「こんなタスクシステムならいらないよね」というのは、案外、まともな感性のような気はしますけどね。
>>200 > 自機と敵の接触とホーミングみたいなもん両方どうやって表現してんの？
> 仮に自機タスクに敵、敵タスクに自機の処理が必要になっちゃうと
> 切り離したいときに自機クラス移動したら敵クラスも必要になっちゃうし
> 敵クラスだけ動かそうとしたら自機クラスまで必要になったりとカプセル化ぶっ壊れてると思う
私には、「自機クラス移動したら敵クラスも必要になっちゃうし」の意味がわからないんだよね。
「移動」っていうのは画面上の「座標移動」のことなのか、オブジェクトとしてアドレスが
移動(例えば、いったん消滅して、再度別のオブジェクトとして生成されるような場合)なのか
どちらの話？どうも前者っぽい気はするのだけど。
・自機と敵との接触は、常識的には自機が1つで敵が複数いるわけだから、
(常識的には)自機クラスに自機が敵との接触判定を行なうコードを記述する。
・ホーミングはホーミングというタスクがあるわけで、
ホーミングのタスクが自機クラスを取得して、そこからgetterで座標を取得する。
「敵クラスだけ動かそうとしたら自機クラスまで必要になったり」の意味がわからない。
ホーミングは自機を狙うわけだから、ホーミングを動かすのに自機の現在の座標が必要なのは
当然であって、自機の座標を何らかの形で取得できるようになっていないとホーミングは
自機を狙うことすら出来ないと思うのだけど。
だから、自機クラスはgetterで自分の座標を提供する必要がある。
これのどこがカプセル化が壊れているのか私にはさっぱりわからない。
>>207 > タスク生成にはひとつの入り口しかないので、ここでデータベースへタスクを
> 登録する作業をしておけば、生存しているタスクの列挙漏れは起こらないことが保証される。
その「登録する作業」は
>>156 の System.Add(new MyTask(...)) の中でも
できると思うんだけど、違うの？
>175 の質問はどこに書くか問うているが何を書くのか定めてないな。
何を書くのかわからないのにどこに書くか決められないから
答えの無い質問を投げる釣りだな。>183 がネタばらしか。
>>202 だからこその隔離スレ。一応は技術板なんで良い話題が投げられれば
それなりの流れになるとは思うけど。
自機のタスクが敵のタスクリストの場所の情報を保持すればいいんじゃないのか
この勢いでタスクサンプルをうｐする作業に入るんだ
214 ：
名前は開発中のものです。 ：2009/08/26(水) 02:36:50 ID:Jc1aOsD2
>>210 > その「登録する作業」は
>>156 の System.Add(new MyTask(...)) の中でも
> できると思うんだけど、違うの？
呼び出し側でnewしてしまうと何にもならない。デメリットは2つ。
まず、タスクにはそれなりのbuilderが必要だと思うんだ。
タスクごとに初期化や設定のためにいろいろ外部から渡してやる必要があるだろうから。
それはサウンド再生クラスであったり、グローバルタイマーであったり、
まあ、いろいろだけど、何せそういったものを渡してやる必要がある。
呼び出し側でnewすると、builderも呼び出し側に用意する必要がある。
これは凄く嫌。生成と同時にbuilderを呼び出すことを呼び出し側が保証しなくてはならなくなる。
呼び出し側は、もっとお気軽に、特定のタスクの生成を指示したいんだ。
そのタスクに付随するbuilderの呼び出しまで責任を負いたくない。
2つ目のデメリットは、newというキーワードが散乱すること。
タスクをnewしている箇所をもっと限定したいんだ。
メモリリークしていないことの保証がしにくくなるからね。
タスクシステムとタスクのfactoryでしかnewしていないことが保証できると嬉しい。
すなわち、ユーザーコード(ここで言うユーザーとはタスクシステムのユーザー。
タスクシステムとは別の人が書いていると想定)内にnewが一切出てこないで済む。
ユーザーコードをgrepで"new "を探して、見つかったら、そのコードを
書いた奴の頭を張り倒していい。
>>212 > 自機のタスクが敵のタスクリストの場所の情報を保持すればいいんじゃないのか
保持するというのはメンバとしてstd::list<ITask*>のようなものを持つことを
言ってるんだろうけど、敵は動的に解体されるので、参照が無効になりかねない。
私は
>>203 のようにするべきだと思う。
>>213 > この勢いでタスクサンプルをうｐする作業に入るんだ
> お、俺のSTGに組み組んであげてもいいんだからねっ////
タスクシステムに求める機能って、制作物ごとに違うだろうから
自分に合わせたものを作るのが一番いいと思うよ。
218 ：
名前は開発中のものです。 ：2009/08/26(水) 02:50:56 ID:Jc1aOsD2
>>214 挙げといて難だが、重大なバグを発見したｗｗｗ
探してみると笑えるかもしれないｗｗｗ
まあこの流れだと無視されるだろうがな。
ふぅ……
>>214 > そういうのはenumで自機とか敵機の識別子を作っておくんだよ。
そんな実装は嫌だなぁ。
それだと、すべてのタスクの識別子が必要になってくる。
タスクを追加するごとにそのenumを修正する必要が出てきそう。
ITaskはvirtual methodを持つのだから、ITask派生クラスは
RTTIで型情報がとれることは保証されているので、typeid
(いま気づいたが
>>154 はtypeofと書いているのは書き間違いでtypeidが正しい)
でtype_infoを取得して、そいつで識別したほうがいいような気がするのだが。
>>219 タスク自体に持たせるんじゃなくて、自機とか敵機に持たせればいいじゃん。
必要になればシステム自体が識別子を取得するようにすれば面倒なことにはならない。
>>218 > 挙げといて難だが、重大なバグを発見したｗｗｗ
ざっとしかコードを見ていないが、ひとことで言うと何がしたいのかさっぱりわからない。
メモリのpoolerのようだけど、開放の処理がおかしいし、
こんな設計では開放処理できないだろう。
単に vector<T>とかで型ごとにpoolしたほうがいいんじゃないの？
そのほうが開放～再確保のときに無駄が出ないよ。
>>220 > タスク自体に持たせるんじゃなくて、自機とか敵機に持たせればいいじゃん。
> 必要になればシステム自体が識別子を取得するようにすれば面倒なことにはならない。
何を言いたいのかわからない。私なりに日本語を修正すると以下のようになるが
以下の意味であってるのか？
タスクシステム自体に「自機とか敵機の識別子」を書いたenum持たせるんじゃなくて、
自機クラスとか敵機クラスに、そういうenumを持たせればいいじゃん。
あと「必要になればシステム自体が識別子を取得するようにすれば面倒なことにはならない。」
については全く意味不明。「システム」ってなんだ？ここで言う「取得」とは何だ？
何がどう面倒なことにならないんだ？ 具体的なコードで示してくれ。
どうせ質問が来るだろうから事前に書いておく。
■ タスクシステムでbehaviorをどう記述するか
タスク間の相互作用をどのクラスに記述するのかというのは、タスクシステムでよく問題になる。
例えば、惑星のタスクがあって、それぞれの惑星が引力によって相互干渉する場合。
疑似コードで示すと、次のようになる。
for(int i=0;i<planets.count;++i)
for(int j=i+1;j<planets.count;++j)
{
planets[i]とplanets[j]による重力の相互作用により、それぞれの座標を更新する。
}
このように書くと、forで回っている間、移動後の値を参照してしまうので
正しいシミュレーションとは言い難い。次のように移動は先延ばしするのが普通である。
var new_planets = planets.clone();
for(int i=0;i<planets.count;++i)
for(int j=i+1;j<planets.count;++j)
{
planets[i]とplanets[j]による重力の相互作用により、new_planets[i]の値を更新する。
}
planets = new_planets; // 更新しておいた値をcommit
まあ、難しいことはしていないので意味はわかると思うが、このような
behaviorはタスクシステムを使う場合、どこに書くべきなのか。
言うまでもなく、惑星クラスのなかに書くべきではない。
>>215 やっぱりまだおかしいような気がするよ。
> 呼び出し側でnewしてしまうと何にもならない。デメリットは2つ。
>
> まず、タスクにはそれなりのbuilderが必要だと思うんだ。
> タスクごとに初期化や設定のためにいろいろ外部から渡してやる必要があるだろうから。
初期化時に外部からいろいろ渡したいなら、普通に考えてコンストラクタの
引数で渡すのが自然だと思うんだけど、何のために「それなりのbuilder」が
必要だと思うの？（「それなりのbuilder」が無いとどんな問題があるの？）
>>215 つづき
> 2つ目のデメリットは、newというキーワードが散乱すること。
>
> タスクをnewしている箇所をもっと限定したいんだ。
> メモリリークしていないことの保証がしにくくなるからね。
...
> ユーザーコードをgrepで"new "を探して、見つかったら、そのコードを
> 書いた奴の頭を張り倒していい。
プログラム中で new するものはタスクだけじゃないんだから、そんなごく
限られた保証（保証としては中途半端なもの）を得るために、書かないと
いけなくなるコードや発生してる制限が大きすぎると思うよ。
（まさかとは思うけど、タスク以外 new 禁止なんて言われたら、間違いなく
そのシステム邪魔だよ。）
一般的に、 new/delete 周りのメモリリークをつぶしたいんなら、まずは
↓のガイドラインに従うようにしたほうがいいよ。
http://www.boost.org/libs/smart_ptr/shared_ptr.htm#BestPractices これなら対象オブジェクトや対象プログラムを限定しないし、無駄な制限も
かからない。おまけに例外安全もついてくる。
配列 new は std::vector で。あとは boost::ptr_container でおおかた
済むでしょ。
>>223 の続き。
惑星クラスのなかに書いて、上(
>>223 )の後者のコードと等価な処理を行なうのはとても難しい。
明らかに書くべき場所を間違えている。ではどこに書くかと言うと…。
このbehaviorを記述するためのタスクを別途生成するべきだと思う。
で、このbehavior自体は、惑星クラスのインスタンスが一つでも(本当は相互干渉だから2つ以上だが)
存在する限りは、存在しなくてはならない。
タスクシステムによって、生成は一元化されており、どのクラスが生成されたかは把握できるようになっているので、
「惑星クラスのインスタンスをカウントして、2以上なら自動的に生成され、2未満なら自動的に解体される」ような
behavior(これ自体、ITask派生クラス)のfactoryをタスクシステムに条件とともに設定できれば良い。
呼び出し側を疑似コードで示すと、
taskSystem -> registBehaviorFactory( boost::function<ITask*,void> behaviorFactory , Planet , 2 );
// Planetのインスタンスが2以上になれば、behaviorFactoryによって、behaviorを書いたクラスのインスタンスが生成され、
// Planetのインスタンスが2未満になれば、そのインスタンスは自動的に解体される。
まあ、こういうことだな。
>>224 > 初期化時に外部からいろいろ渡したいなら、普通に考えてコンストラクタの
> 引数で渡すのが自然だと思うんだけど、
全然自然じゃない。
いま、あるタスクにサウンドクラスが必要だとする。
そのタスクのbuilderはサウンドクラスを設定してやることが出来る。
ところがあなたの設計だと、コンストラクタでサウンドクラスを渡してやる必要がある。
すなわち、newした側がサウンドクラスにアクセスできる必要がある。
そのタスクを生成したいだけなのに、そのコンテキスト(タスクを生成するコードが
ある場所)においてサウンドクラスへのアクセス権を持っていなければならないことになる。
こんな設計はおかしいと言っているんだ。
>>225 > プログラム中で new するものはタスクだけじゃないんだから、そんなごく
> 限られた保証（保証としては中途半端なもの）を得るために、書かないと
> いけなくなるコードや発生してる制限が大きすぎると思うよ。
>（まさかとは思うけど、タスク以外 new 禁止なんて言われたら、間違いなく
> そのシステム邪魔だよ。）
×タスク以外new禁止
○タスク(ITask派生クラス)内のコードでのnew禁止
例えば、典型的なシューティングゲームで、タスク内のコードでnewする必要性がない。
だから開発物が決まっている状況において、タスク内のnewを禁止するのは、別に厳しい制限ではない
と思うよ。
逆にあなたにお聞きしたいが、タスク内でnewしたいケースというのは、
一体、どういうケースなんだ？
> 一般的に、 new/delete 周りのメモリリークをつぶしたいんなら、まずは
> ↓のガイドラインに従うようにしたほうがいいよ。
>
http://www.boost.org/libs/smart_ptr/shared_ptr.htm#BestPractices > これなら対象オブジェクトや対象プログラムを限定しないし、無駄な制限も
> かからない。おまけに例外安全もついてくる。
shared_ptrは資源の無駄使いだと思う。
別に使ってもいいけど、タスクシステムにshared_ptrは必須じゃないと思うんだけど。
メモリリークは単に、タスク内での明示的なnewを禁止にすればほとんどは防げるのだし。
>>227 >> 初期化時に外部からいろいろ渡したいなら、普通に考えてコンストラクタの
>> 引数で渡すのが自然だと思うんだけど、
...
> そのタスクを生成したいだけなのに、そのコンテキスト(タスクを生成するコードが
> ある場所)においてサウンドクラスへのアクセス権を持っていなければならないことになる。
>
> こんな設計はおかしいと言っているんだ。
別におかしくないと思うんだけど、まぁそこは主観が入るからやめとこう。
具体的に、生成処理から（例として）サウンドクラスへのアクセスを禁止できた
として、何が得られるの？
builder を使った場合でも、生成するタスクに生成処理の一部として渡すん
だったらタスク内では（ファクトリ関数内も？）当然アクセスできちゃう
わけで、どっちにしてもタスク実装者に対して隠蔽できていないという意味で
同じことだと思うんだけど。
>>210 いま思い出したのだが、タスクを呼び出し側でnewしてタスクシステムに渡す構造になっていると
taskSystem -> AddTask( ptr ); // new していないポインタ
とかする奴やら、
IEnemy* enemy = new EnemyBoss123();
taskSystem -> AddTask ( enemy ); // 勝手にupcastしたポインタ
とかする奴やら、いろんな奴が出てくる。(上のコードは簡略化した例だが、実際の現場で遭遇したコードだ)
タスクシステムとタスク側とを書いている人間は別の人間だ。
タスク側を書いている人間がタスクシステムのことを正しく理解しているとは限らない。
タスクシステムはどちらかと言えばライブラリに属するので、
タスク側のコードを書く人間がポカをやったときにそれを検知するための仕組みか、あるいは、
ポカをそもそも出来ないように設計されているべきだ。
一人でゲームを作っているなら、全く関係ない話かも知れないが、であれば、
現場のゲームライブラリ実装者はこう考えている人もいるという風に受け取って欲しい。
>>229 > 具体的に、生成処理から（例として）サウンドクラスへのアクセスを禁止できた
> として、何が得られるの？
いま、static変数は極力廃止してあるという前提で話を進める。(この前提については認めてもらえる？)
タスクを生成するのは、(タスクシステムにおいては)タスクに他ならない。
すなわち、なにかしらのタスクなんだ。
そのタスクは、サウンドクラスにアクセスできるということは、そのタスクは生成時かbuilderでサウンドクラスを
コンストラクタで受け取っているということになる。あなたの話だとbuilderは使わないのだから、コンストラクタで
受け取っていることになる。
いま、タスクAにはサウンドクラスが必要で、タスクBにはサウンドクラスが不要だとしよう。
タスクBがタスクAを生成したくなったら、(あなたの設計では)タスクBのコンストラクタのシグネチャを変更して
サウンドクラスを受け取るようにしなくてはならない。その変更に付随して、タスクBを生成している部分のコードを
書き直さなくてはならない。そして、タスクBを生成しているタスクC,D,E,…に関しても、それらがサウンドクラスを
コンストラクタで受け取っていないなら、それを受け取るようにコード修正をしなくてはならない。
この呪いのようなサウンドクラスをもらうための連鎖とそれに付随するコード修正が限りなく続いていく。これがとても嫌。
232 ：
えいいち ◆GRGSIBERIA ：2009/08/26(水) 03:49:34 ID:Jc1aOsD2
まあ、せっかくだし名乗るか。
>>221 一応、速度重視の汎用アロケータ。
vectorだと遅いし、poolも余計に増える。
テンプレートクラスにして型ごとに取ってくるのも最初は考えたけどメモリ効率が余計悪くなるからやめた。
解放処理はMemoryPoolの寿命と一緒に行うことになってる。
無理に解放しようとするとCPUが100%になったまま固まることがあるのでお勧めしない。
メモリ効率は非常に悪いけどBoost::object_poolより速かったから問題ない。
>>222 一応、おｋ。
＞面倒なこと
typeidで型名取得したときにどうやってタスク内で処理するか、とか。
クラスが増えすぎた場合、どうやって対処するか、とか。
enumなら敵です味方ですラベルです、ぐらいに作っておけばそういう設計で困らない。
>>229 > builder を使った場合でも、生成するタスクに生成処理の一部として渡すん
> だったらタスク内では（ファクトリ関数内も？）当然アクセスできちゃう
> わけで、どっちにしてもタスク実装者に対して隠蔽できていないという意味で
> 同じことだと思うんだけど。
全然同じことじゃない。
factory関数内からはサウンドクラスにはアクセスできる。factoryはclosureになっていて、(factoryを定義コードの)
親スコープからアクセスできたサウンドクラスを設定してある。
タスクA(
>>231 )はサウンドクラスにアクセスできるが、
タスクB,C,D,E,…のfactory + builderではサウンドクラスを提供しない。(渡さない)
よって、
・サウンドクラスを必要とするタスクAに対してしかサウンドクラスは公開されていない。
・タスクB,C,D,E,…からは直接的にはサウンドクラスにアクセスできない。
すなわちサウンドクラスの公開の範囲は適切であって、これはタスクに対して
サウンドクラスは正しく公開/隠蔽されていると言えると思う。
>>232 > 解放処理はMemoryPoolの寿命と一緒に行うことになってる。
生成～開放を繰り返すとメモリを一瞬で使い切ってしまうんだけど、これは仕様なの？
> テンプレートクラスにして型ごとに取ってくるのも最初は考えたけどメモリ効率が余計悪くなるからやめた。
型ごとにとってきてあって、開放～生成で前回開放したところを再利用するなら
メモリ効率はあなたのMemoryPoolの実装よりは遙かにいいと思うけど、
「メモリ効率」は、何をどういう基準で話しているの？
> 無理に解放しようとするとCPUが100%になったまま固まることがあるのでお勧めしない。
部分的に開放するだけだよ。たいした計算コストじゃない。
それでCPU負荷率が100%になるなら、
開放しなくともCPU負荷率は100%なんじゃないかと思うけどね。
>>232 > typeidで型名取得したときにどうやってタスク内で処理するか、とか。
> クラスが増えすぎた場合、どうやって対処するか、とか。
typeid指定してタスクシステムからそのタスクの集合をもらう。
vector<ITask*> getTaskTypeid(const type_info& info)
{
vector<ITask*> list;
foreach(var task in taskList)
if (task.typeid() == info) list.push_back(task);
return list;
}
たったこれだけ。
> enumなら敵です味方ですラベルです、ぐらいに作っておけばそういう設計で困らない。
「そういう設計」の「そういう」というのは、このレス大元である
>>212 の設計のことだと思うんだけど
私は
>>212 がいまひとつどのレスかわからないんだけど、たぶん
>>200 の返答だと思うのだけど、
>>200 の設計をするのに際して「enumなら敵です味方ですラベルです、ぐらいに作っておけば」
何がどう困らない？
ひょっとすると
>>212 のレス元が
>>200 とは違うのかも知れない。なんかよくわからないが
話が噛み合ってない気がする。
>>228 > ×タスク以外new禁止
> ○タスク(ITask派生クラス)内のコードでのnew禁止
うわ、マジで禁止すんの？びっくりした。
微妙に変えてあるけど、どっちでも邪魔だよ。
> 例えば、典型的なシューティングゲームで、タスク内のコードでnewする必要性がない。
> だから開発物が決まっている状況において、タスク内のnewを禁止するのは、別に厳しい制限ではない
> と思うよ。
開発する対象にシステムが依存してるってことになるね。それもびっくり
だなぁ。
>152-153 では「具体的なクラスを全部システム側が知ってる」っていうのが
マズイという認識は共有できていたのに、こっちはかまわないっていう
感覚には、共感できないよ。
> 逆にあなたにお聞きしたいが、タスク内でnewしたいケースというのは、
> 一体、どういうケースなんだ？
いくらでもあるでしょ。出すか出さないか実行時に決まるエフェクトとか？
new が要らないように工夫することも可能だったりするんだろうけど、
システムの制限のせいでそういうことを考えないといけないということだと、
やっぱり邪魔だと思ってしまうよ。
>>228 >> 一般的に、 new/delete 周りのメモリリークをつぶしたいんなら、まずは
>> ↓のガイドラインに従うようにしたほうがいいよ。
>>
http://www.boost.org/libs/smart_ptr/shared_ptr.htm#BestPractices >> これなら対象オブジェクトや対象プログラムを限定しないし、無駄な制限も
>> かからない。おまけに例外安全もついてくる。
>
> shared_ptrは資源の無駄使いだと思う。
>
> 別に使ってもいいけど、タスクシステムにshared_ptrは必須じゃないと思うんだけど。
> メモリリークは単に、タスク内での明示的なnewを禁止にすればほとんどは防げるのだし。
「メモリリークをなくしたい」という目的で、独自のシステムに制限と
コードを加えていくよりも、こういった汎用的な方法を取ったほうが制限も
コードも少なくて済むという話。
shared_ptr の無駄なんて、昨日から挙げてくれてるコードにある
function や map や dynamic_cast と似たようなもんだよ。どうしても
嫌なら std::auto_ptr や scoped_ptr もあるし。
個人的には「newを禁止にすれば」ってサラっとかいてあるのがもう
ありえない選択肢なんだけどね。
>>236 > 開発する対象にシステムが依存してるってことになるね。それもびっくり
> だなぁ。
なんか捉え方がおかしくない？
ミドルウェアってそういうもんでしょうに。
2Dのゲーム作りたいのに、3Dの物理エンジン買ってきて、作ったってしょうがないでしょ？
特定の開発対象にタスクシステムが適合するってだけ。
そのタスクシステムを使うときに、特定のルールを決めておけば、余計なバグが発生しないってだけ。
>
>>152-153 では「具体的なクラスを全部システム側が知ってる」っていうのが
> マズイという認識は共有できていたのに、こっちはかまわないっていう
> 感覚には、共感できないよ。
「具体的なクラスを全部(タスク)システム側が知ってる」というのがマズイとは私は
言っていない。そういう設計にするメリットとデメリットとがあるよね、というだけ。
>>236 のタスク内のnew禁止にしても、そうすることのメリットとデメリットがあって、
特定のプロジェクトにおいてはメリットのほうがデメリットに勝るからそうすることが
あるよって言ってるだけ。「マズイ/マズくない」の問題じゃない。
しかし、newしたものをタスクシステムに渡すことに関しては
233-234に具体的な大きなデメリットがあって、これは私は致命的だと思うから、私は反対。
>>230 > いま思い出したのだが、タスクを呼び出し側でnewしてタスクシステムに渡す構造になっていると
>
> taskSystem -> AddTask( ptr ); // new していないポインタ
これはファクトリから new してないポインタ返すことを考えれば
同じことだよ。
> IEnemy* enemy = new EnemyBoss123();
> taskSystem -> AddTask ( enemy ); // 勝手にupcastしたポインタ
ん？なんでアップキャストが問題になるの？
その問題が、ファクトリ通すとどうにかなるの？
>>236 >> 逆にあなたにお聞きしたいが、タスク内でnewしたいケースというのは、
>> 一体、どういうケースなんだ？
> いくらでもあるでしょ。出すか出さないか実行時に決まるエフェクトとか？
> new が要らないように工夫することも可能だったりするんだろうけど、
> システムの制限のせいでそういうことを考えないといけないということだと、
> やっぱり邪魔だと思ってしまうよ。
例えば、爆発のエフェクトが出したいなら、そのタイミングで
爆発のエフェクトを表示するタスクを生成すればいいことだから。
まあ、それはゲームによりけりだし、そういう設計だとコードが冗長に
なるということはあるだろうけど。
何度も言うけどnew禁止は絶対じゃない。そういうローカルルールを用意して
開発するのも現実的には有効だと言ってるだけなのだが。
241 ：
名前は開発中のものです。 ：2009/08/26(水) 04:22:16 ID:Jc1aOsD2
>>234 ＞生成～開放を繰り返すとメモリを一瞬で使い切ってしまうんだけど、これは仕様なの？
仕様。MemoryPoolをいつまでも使い続けるとメモリが果てるようになってる。
この仕様を維持しつつ、適当にデフラグができたらいいんだけど、いかんせん無理がある。
＞「メモリ効率」は、何をどういう基準で話しているの？
newの呼び出し回数とコンストラクタに渡されるsizeで。
＞部分的に開放するだけだよ。たいした計算コストじゃない。
なんか知らんが固まる。
たぶん、重大なバグが原因だろう。検証はまだしてない。
しかし、どのみち部分的に解放するとその分遅くなるのでfree(...)でどうにかしてる。
部分的な解放ができないこと自体、仕様なので諦めてほしい。
>>231 >> 具体的に、生成処理から（例として）サウンドクラスへのアクセスを禁止できた
>> として、何が得られるの？
> いま、static変数は極力廃止してあるという前提で話を進める。(この前提については認めてもらえる？)
これは大賛成。
> いま、タスクAにはサウンドクラスが必要で、タスクBにはサウンドクラスが不要だとしよう。
...
> この呪いのようなサウンドクラスをもらうための連鎖とそれに付随するコード修正が限りなく続いていく。これがとても嫌。
これがファクトリで解決するってことは、ファクトリのコンテキストには
システム側からサウンドクラスが渡される（あるいはシステムから
取り出せる）んだよね？
それなら、コンストラクタの引数で渡せるように、システムから
サウンドクラスへの参照が取り出せるようになってればいいんじゃないの？
（ SoundClass& System::Sound() って感じで）
生成箇所では System.Add() を呼び出すんだから、そこに System.Sound() が
あっても何の問題も無いでしょ。・・・やっぱり何かあるのかな？
>>237 > 「メモリリークをなくしたい」という目的で、独自のシステムに制限と
> コードを加えていくよりも、こういった汎用的な方法を取ったほうが制限も
> コードも少なくて済むという話。
ふむ、別にそれ(shared_ptrの使用)に関しては私は反対じゃないよ。
>>237 > 個人的には「newを禁止にすれば」ってサラっとかいてあるのがもう
> ありえない選択肢なんだけどね。
new禁止どころか、もっと強い制約を課することもあるよ。
例えばユーザー(タスクシステムを使う側のプログラマ)のコードを、単なるスクリプトと
みなして、特定の命令しか書けないように制約を課したいことだってある。
プログラマーより、さらにプログラムについて理解に乏しい、スクリプターと呼ばれる
ような人たちに、タスク部分のコードを書かせないといけないときは、そうだね。
彼らの書くコードに特定の命令しか書けないように縛りを入れる。
Luaのような外部のスクリプト言語を使ってもいいけど、
C++で特定の命令しか使わせないことで同じことが出来るなら、
C++で書かせたほうが実行効率がいいし、余計なセキュリティ上の問題に晒されなくて済む。
まあ、結局、それは開発スタイルの問題だと思うよ。
あなたは、ゲームをまるごと一人で作ることを想定しているから
「newを禁止なんてありえない！」となるんだ。
実際はゲームはひとりで作れる規模じゃないものだってたくさんある。
分業するには、下位のクラスにあまり大きな権限を持たせるべきではない。
さきほどのサウンドクラスへのアクセス権にしてもそう。
あなたの考えでは、「別にすべてのタスクがサウンドクラスへのアクセス権を
持っててもいいじゃん？それでどんなデメリットが生じるの？」ってことなんだろうけど
規模の大きなゲームでは、下位クラスの開発者にまでそんな余計なアクセス権をもたれると
こちらが想定していない使い方をされたりして開発に支障が出たりするんだよね。
>>239 >> taskSystem -> AddTask( ptr ); // new していないポインタ
> これはファクトリから new してないポインタ返すことを考えれば
> 同じことだよ。
どうも話が噛み合っていないと思う。
あなたは、私の書き込みを飛ばし飛ばしにしか読んでいないからだろうし、
すべて読んでくれとお願いする気もないのでこの場で再度説明しておくけど、
私の提案する実装では、
factoryはタスクシステムに事前に登録しておいて(
>>153 )
タスク側が、他のタスクを生成するときは、タスクシステムに対して、newTask(
>>155 ,159)で
生成するから、factoryからnewしていないポインタをもらって、
それをtaskSystem -> AddTaskなんてことはすること自体が出来ない。
>>239 >> IEnemy* enemy = new EnemyBoss123();
>> taskSystem -> AddTask ( enemy ); // 勝手にupcastしたポインタ
> ん？なんでアップキャストが問題になるの？
> その問題が、ファクトリ通すとどうにかなるの？
タスクデータベース(
>>179 ,197)のようなものをどこかにおいて、
タスクに対するqueryに応答できるようにしたい。
そのためには、タスク生成時に、その生成された型とオブジェクトのアドレスを
何らかの方法で通知する必要がある。
タスクのオブジェクト自体はITask派生クラスであり、かつ、タスクの生成は
タスクシステム側の入り口(エントリーポイント)を必ず通過するようになっていれば
生成自体を捕まえることは出来るが、そのときにオブジェクトの型を知る必要がある。
型自体は、typeidで取得してもいいけども、型ごとに特定の処理をさせたいことも
あるから、特定の型に対しては、
>>159 のnewTaskをtemplateの特殊化で記述できると
都合が良い。
それなのに、勝手にupcastされたポインタを渡されると、templateの特殊化をする
ような実装にしようとしたときに困る。
>>241 > ＞部分的に開放するだけだよ。たいした計算コストじゃない。
> なんか知らんが固まる。
> たぶん、重大なバグが原因だろう。検証はまだしてない。
そんなのバグに決まってるじゃん。ソース出してみなよ。見てあげるよ。
> しかし、どのみち部分的に解放するとその分遅くなるのでfree(...)でどうにかしてる。
だから型ごとにvector用意すればいいじゃん。
型ごとにvector用意したほうが、よっぽど速いと思うけど。
boost::unordered_map<type_info,vector<void*> > maps;
まあ、同じ型のobjectがいっぱいあると開放するには線形時間はかかるだろうけど…。
>>242 >> いま、static変数は極力廃止してあるという前提で話を進める。(この前提については認めてもらえる？)
> これは大賛成。
ふむ、あなたはたぶん、かなり優秀なプログラマなんだと思う。
私はあなたほどは理想主義じゃないんだろうな。たぶん、私は長年、たくさんの
とんでもないヘタレプログラマと一緒に仕事をしてきて、彼らがどんなヘマをしでかすか
(間接的には私のほうに原因があるものもあるのだが)を見て、結構、へこんだり、落ち込んだり、
悩まされたり、胃が痛くなったり、まあ、そんなこんなで、やや現実的になりすぎているのだろう。
>>242 >> いま、タスクAにはサウンドクラスが必要で、タスクBにはサウンドクラスが不要だとしよう。
...
>> この呪いのようなサウンドクラスをもらうための連鎖とそれに付随するコード修正が限りなく続いていく。これがとても嫌。
> これがファクトリで解決するってことは、ファクトリのコンテキストには
> システム側からサウンドクラスが渡される（あるいはシステムから
> 取り出せる）んだよね？
うん。その通り。factoryはclosureで記述されていて、タスクシステムのスタートアップコードに
近いところで設定される。
> それなら、コンストラクタの引数で渡せるように、システムから
> サウンドクラスへの参照が取り出せるようになってればいいんじゃないの？
> （ SoundClass& System::Sound() って感じで）
> 生成箇所では System.Add() を呼び出すんだから、そこに System.Sound() が
> あっても何の問題も無いでしょ。・・・やっぱり何かあるのかな？
ここで言う「システム」とは「タスクシステム」のことかな？
だとして、「タスクシステム」は、サウンドクラスとは無縁のクラスだからそんなところには
サウンドクラス(の参照)をメンバとして持たせたくない。
また、「サウンドクラス」は一例であって、実際は開発時にいろいろあとから追加される
何か(タスクシステムとは別の)グローバルリソースへのアクセスが必要なクラスなんだ。
249の続き。
>>242 「タスクシステム」はfixされた、ソースのいじれないクラスだと思って欲しい。
だからあとから追加された「サウンド」クラスを「タスクシステム」に入れ込むことは出来ない。
もうちょっと具体的に現場の状況を書けば、
「タスクシステム」自体は、クラスとして可搬性のあるように設計されている。
どの環境でも動くように設計されている。移植先が仮にiPhoneだとしてiPhone SDKの
「サウンドクラス」に関する参照をタスクシステムが保持するのはおかしいよね。
そんなことをすると「タスクシステム」は可搬性を失ってしまう。
だから「タスクシステム」にクラスを追加するのはナシ。
>>233 > factory関数内からはサウンドクラスにはアクセスできる。factoryはclosureになっていて、(factoryを定義コードの)
> 親スコープからアクセスできたサウンドクラスを設定してある。
...
> タスクA(
>>231 )はサウンドクラスにアクセスできるが、
> タスクB,C,D,E,…のfactory + builderではサウンドクラスを提供しない。(渡さない)
なるほど。これで >231 にある B が A を作る状況になると、 B が持ってない
サウンドクラスをクロージャが補ってくれるわけだね。確かにこれは直接 A の
コンストラクタを呼ぼうとするとできない。
クロージャによるファクトリ登録に有効な場面があることはわかったよ。
ありがとう。
でもやっぱり全体の仕組みとして組むのはなぁ・・・と思いながらリロードしてレスを
見てたら、・・・
>>246 > そのためには、タスク生成時に、その生成された型とオブジェクトのアドレスを
> 何らかの方法で通知する必要がある。
これだと型を受け取りながら生成しないといけないから、 >154 みたいな
ファクトリが要るね。
この点が見えてなかったのと、あと
>>238 にある、システムが利用側に
依存してもいいっていうのがありえないと思って話してたから、いろいろと
噛み合わない話になっちゃったと思う。ごめんよ。
ひととおりつじつまの合う情報をもらったんで、ようやく理解できたよ。（共感は
できないけどね。）根気強く付き合ってくれてありがとう。
>>242 に付随して、
タスク側がどうやってタスクシステムにアクセスできるのかについてハッキリさせておこう。
■ タスク側がどうやってタスクシステムにアクセスできるのか
タスクは他のタスクをタスクシステムに依頼して生成してもらわなければならない。
すなわちタスクはタスクシステムへのポインタを何らかの形で持っている。
これには二つ方法がある。
class ITask
{
TaskSystem* taskSystem;
// 以下略
のように、タスク基底クラス自体がTaskSystemへのポインタを持っておき、
タスクシステムでのタスク生成時にこいつを設定してもらうことだ。
しかし、グローバルリソースのようなものにタスクがどうやってアクセスするかという話になる。
タスクシステムにサウンドクラスを持たせるような実装が論外であることは
>>249-250 ですでに述べた。
また、すべてのタスク基底クラスがTaskSystem*を保持しているのは、やや無駄である。
>>252 の続き。
そこで、実際は、ITaskのupdateは次のようにする。
virtual void update(TaskSystem* );
タスクシステム自体を引数として渡してやる。では描画はどうする？
ほとんどすべてのタスクは描画する必要がある。描画用のコンテキストも渡すのか？それとも
factory + builderで事前に渡すのか？という問題になる。描画先のスクリーンを切り替えたり
したい時はどうなるんだ？という話になる。
そこで、updateは、このような固定化されたクラスではなく、次のようにゲーム用のコンテキストを
渡すほうが理にかなっている。
template class <GameContext>
virtual void update(const GameContext& context);
このようにtemplateで書く。GameContextは、ゲームによって異なる。
タスクシステムはこのGameContextの内容までは関知したくないのでtemplateになっている。
>>253 の続き。
典型的なゲームでは、
class GameContext
{
TaskSystem* taskSystem;
DrawContext* draw;
SoundManager* sound;
InputManager* input;
};
のようになっているだろう。ITask派生クラスのupdateでは、このcontextに基づいて
描画をしたりサウンドを再生したりする。
こうしておけば、比較的すんなり書けるが(
>>231 の問題が解決！)、
下位のタスクにまでInputManagerにアクセスできて良いのか？
というアクセス制御上、問題があるとも言える。(例
>>244 )
そこで、factory + builder側で渡す方法もある。(例
>>233 )
まあ、どちらの設計が正しいというわけでもないので
シーンごとに適切に使い分けていただきたい。
>>251 > ひととおりつじつまの合う情報をもらったんで、ようやく理解できたよ。（共感は
> できないけどね。）根気強く付き合ってくれてありがとう。
理解できたようで何より。
まあ、こういう設計もアリなんだな、という程度に捉えてもらえるとありがたい。
実際は、
>>252-254 のように設計することのほうが好ましいことが多いと思う。
もしかしたら、
>>252-254 のほうが実装が簡単で、あなたの感性にfitすると思う。
あと、やねうらおが10年以上前に提示したyanesdk3rdのタスクシステムのコードが
>>252-254 のようになっていたと思う。
256 ：
えいいち ◆GRGSIBERIA ：2009/08/26(水) 05:56:10 ID:Jc1aOsD2
>>235 ＞typeid指定してタスクシステムからそのタスクの集合をもらう。
ごめん。タスクシステムの実装がどうなってんのかわかんないから一部だけだとわからない。
＞そういう設計
タスク内でtypeidをどうやって扱うか云々。
当たり判定だったら誰と当たり判定をするのか、って部分が簡単に書ける。
＞話が噛み合ってない気がする。
自分の性格が適当すぎるからそういう意味でかみ合ってない。
>>247 http://kansai2channeler.hp.infoseek.co.jp/cgi-bin/joyful/img/9911.txt とりあえず改修。deleteで止まるのはreinterpret_castが原因だと思う。
＞まあ、同じ型のobjectがいっぱいあると開放するには線形時間はかかるだろうけど…。
これはちょっと困るな。
MemoryPool<T, num> obj; みたいな形でT型num個分の領域を確保しておく、ってのなら速度は維持できるけど。
257 ：
えいいち ◆GRGSIBERIA ：2009/08/26(水) 05:57:29 ID:Jc1aOsD2
と言うわけで落ちます。
>>256 >＞typeid指定してタスクシステムからそのタスクの集合をもらう。
> ごめん。タスクシステムの実装がどうなってんのかわかんないから一部だけだとわからない。
>>197 のgetTasksがその具体的なコード。
> タスク内でtypeidをどうやって扱うか云々。
> 当たり判定だったら誰と当たり判定をするのか、って部分が簡単に書ける。
言ってる意味がよくわからないんだ。
「簡単に書ける」コードを実際に書いてみせてくれないかな。
>>256 > とりあえず改修。deleteで止まるのはreinterpret_castが原因だと思う。
このコードだと、MemeoryPoolを開放するときに
確保していたオブジェクトのデストラクタを呼び出すことを
保証できないよね。このMemoryPool失敗なんじゃ…。
>＞まあ、同じ型のobjectがいっぱいあると開放するには線形時間はかかるだろうけど…。
> これはちょっと困るな。
> MemoryPool<T,num> obj;みたいな形でT型num個分の領域を確保しておく、
> ってのなら速度は維持できるけど。
オブジェクト何個作る気かは知らないけど(私は100個ぐらいを想定していたので
開放に時間がかかってもいいのかと思ったのだけど)、もし開放する速度が気になるなら、
メモリ上に配列がリニアに並んでいるのだから、開放するアドレスをptrとして、
index = ((byte*)ptr - (byte*)&array[0]) / sizeof(T);
でどの要素を開放すべきかはわかるから、こいつを開放されたとして、
reuse用のstackにでも突っ込んでおけばいいだけなんじゃ。
vector<int> reuseStack;
reuseStack.push_pack(index);
次回、ここから一つ取り出して、それに対応する配列のアドレスを返せばいいのでは。
まあ、poolerとしてはよくある実装だと思うね。
>>241 > なんか知らんが固まる。
いま気づいたが、このMemoryPool、馬鹿ほどメモリを消費して、OSのswapが生じてるんじゃないのか。
あとデストラクタすら呼び出されていないクラスがリソースを掴んだまま終了してリソースが未解放になってるんじゃないのか。
いずれにせよ、こんなMemoryPool使い物にならないよ。
ソースもよく見ると、
> public:
> MemoryPool* _next; // 次へのポインタ
何故次へのポインタがpublicである必要があるんだ？
> long pool_itr;
何故ここがlongなんだ？ size_tを指定して確保してあるのだから、範囲はsize_tだろうが。
> size = a_size;
> over = overed_magni;
メンバ変数名と引数で全然違う名前にするの勘弁してくれ。ソースが追いかけにくい。
this.a_size = a_size;
this.overed_magni = overed_magni;
とか、同名にするか、最後にunderbar入れるかにしときなよ。
>>241 あと
> _next = NULL;
先頭アンダーバーから始まる変数名はC++の実装者が使っていることがあるから使用してはいけないはずなのだが。
> itr = _next;
こんなことしたら、メモリを取得できないときは、いくつものMemoryPoolのpool_allocが連鎖的に呼び出されて
パフォーマンスがすこぶる落ちるのだけど。
しかもこの実装は最後にまとめてしかメモリを開放しないから、一度落ちたパフォーマンスが回復することは永遠にないな。
> ptr->~T();
Tのコンストラクタは呼び出さないのに、デストラクタだけ呼び出すんだな。このMemoryPoolは一体、なにがしたいんだ…。
とんだド素人のプログラムだな。こんなもの、0点だ、0点。C++初心者スレで勉強させてもらってきなさい。
262 ：
185 ：2009/08/26(水) 07:44:50 ID:3JaQfvWX
高レベルの話になると調子がいいが
>>262 > 高レベルの話になると調子がいいが
> 具体的な低レベルの話になると途端に煽ってくるのな
え？それは私のことか？
>>185 に対してなら、私は
>>201 で答えているぞ。
私に質問があるなら、私の書き込みに対してアンカー打つか、指名しとくれ。
> で、仮に自機のクラスから敵、敵のクラスから自機の情報が必要になったらどこに記述すればいいの？
自機と敵とのオブジェクトの寿命によって、
>>203 のような分類で決める。
相互作用(behavior)に関するコードなら、
>>223 ,
>>226 。
>>262 > >9ycqcAuWxdGZ
> コードも見てみたけど これを元にあんたの創造するコードを俺らがエスパーすんの？
> 日常会話通じる？深夜しか書き込みしてないけど、自宅警備員？
> 精神病院逝け
これだけ一通り情報があって
>>251 みたいにちゃんと理解できた人もいるわけで、
ここから何も読み取れないとは、よっぽどのC++初心者なんだな。
そりゃ全然、話にならんわ。底辺プログラマに合わせる気は毛頭ないので
それ相応の実力をつけてから戻ってきてね。
>>264 なんかの質疑応答文を読み上げてるだけの某理大臣の答えにしか聞こえないが・・・
あんたの主張はなんだといいたいんだよ
底辺と言われてるが、あんたの答えはあたり前田すぎて
新鮮味にもおもしろみにも欠けるんだが・・・
まぁ、裸の王様だな
>>264 他にもたとえると
台風が来たときに 台風直撃のテレビの前で「台風です！」
と言っている 誰でもみりゃ分かるわボケというレベル
このまま政治家にでもなれば？
多分あんたの部下っていないだろ？
正確に言うとついてこないだろ？
ついていきたくないの 分かる？わかんねーだろうなぁ
>>265 > あんたの主張はなんだといいたいんだよ
タスクシステムは十分使える手法だということだな。
> 底辺と言われてるが、あんたの答えはあたり前田すぎて
そんなことは知らんがな。
あんたが底辺プログラマでないなら、私の提示したタスクシステムから
ソースコードの全貌が想像つくはずだが、それすら「エスパー」しないとわからんのだろ？(
>>262 )
そりゃ全然駄目だわ。話にならんわ。
ここはC++ド素人の厨房のためのスレじゃないんだから
C++の教科書から勉強しなおしてきなよ。
>>266 > 台風が来たときに 台風直撃のテレビの前で「台風です！」
> と言っている 誰でもみりゃ分かるわボケというレベル
違うね。あんたは、ソースが全く読めてないよ。
たとえて言うなら台風が来てるのに「地震だ！」「火事だ！」って騒いでいるキチガイだ。
> ついていきたくないの 分かる？わかんねーだろうなぁ
私なら、あんたみたいな無能な部下はいらんよ。
新着レス多すぎだろ、ドンだけレスしてんだよ
夜中にスレ進みすぎててﾜﾛﾀ
>>197 とか
>>235 とかマジすか？って思うのはC++ド素人だからか
最近のマシンは早いからそういう実装でも問題無いのかな…
>>270 >
>>197 とか
>>235 とかマジすか？って思うのはC++ド素人だからか
> 最近のマシンは早いからそういう実装でも問題無いのかな…
扱うタスクの数によるだろうね。せいぜい1000タスクぐらいを私は想定しているが、
これが1万とか10万とかだというなら、こんな方式をとるべきではない。
1万とか10万もタスクがあるなら、タスク呼び出しのオーバーヘッドすら御免被りたいので、
タスクではなく、単なるactor (要するにただの構造体に簡単なオペレーションのためのmethodがついたもの)として、
そのbehaviorを記述できるようなシステム(タスクシステムとは呼ばないんだろうな。ゲームエンジン？)にするよ。
デバッグ専用か、起動時のみとか数フレームに一回呼ばれるだけとかならおkだけど…
>>272 > 1000タスクもあって、毎フレーム自機と敵とで複数回呼ばれるとすると怖くて使えないなぁ…
> 玄人になるためにも今度実測してみよう、案外たいしたこと無いかもしれないし
1000タスクのうち、敵が999タスクで、その敵が毎フレームすべての敵を列挙する(60frames×999匹×999匹)という話か？
そういう列挙は、1フレーム1回になるように結果をcacheしてよね。
データベースに対するqueryだって、結果をcacheするだろ？
タスクと関係ないが盛り上がってるようで質問
1フレームに2～3回くらいのつもりで発言した
俺なら
>>197 の方式は取らない。
std::list < ITask* >として画一的に扱おうとして、混ぜたものを、
後から選り分ける、というのは設計として退化してる。
画一的に扱いたいものしか、混ぜて使わない。
区別したいものは最初から区別させておく。
この例で言うと、タスクが追加されるとき、
または削除されるとき、taskListと一緒にenemies を操作する。
自分が何に登録されているか、タスクが知っているようにできたら、
Task(*alltasks, *enemies) : alltasks(alltasks), enemies(enemies) {}
Task::enter() {alltasks->push_back(this);enemies->push_back(enemies);}
Task::leave() {alltasks->remove(this);enemies->remove(enemies);}
と出来ちゃうので、生成より参照が多い場合はこれで安心。
>>274 MapClassとUnitClassの寿命は同じと仮定していいのか？
同じなら、
struct Field
{
MapClass map;
UnitClass unit;
}
みたいな入れ物用意して、Field自体をMapClassとUnitClassのコンストラクタかbuilderで
渡してやるのがスマートだと思うけどな。
寿命が違うなら、もう少し抽象化された通信手段を提供する必要がある。例えば、
>>203 。
あるいは、もっと抽象化したければ、相互に通信可能な channel で二つのobjectを結んでやるような実装もありうる。
1つのMapClassに対して複数のUnitClassが対応していて、それぞれのUnitClassに同じ通知を送らないといけないような時などは
こういう仕組みがあると便利かも知れない。
>>276 おっと修正。あのカッコの中はthisな。
>>276 それだと、タスクシステム自体が、Enemyクラスを知っている必要があって、
タスクシステム自体の可搬性が失われているから論外。
それをやるなら、Task::enterとTask::leaveをhookする( callback handler を設定する)ことが出来るようにしておく
ほうがいいだろう。
あるいは、タスクシステムにそんなごてごてした機能を追加したくなければ、
Enemy自体のadaptorを作って、その生成/解体のときに自力でEnemies->push_back/remove を行う良いと思う。
もうひとつ。
> enemies->remove(enemies)
> と出来ちゃうので、生成より参照が多い場合はこれで安心。
これは、vectorのremoveだと思うけど、生成(push_back)より、こっち(解体)のこのコストのほうが馬鹿にならないと思うよ。
1フレームに10個のタスクが消滅するぐらいのペースだと、毎フレーム10回のremoveが生じるわけで、これは空きを詰めるための
コピーだから平均的にはvectorまるごと5回 readとwriteをする程度の時間が必要で、
>>197 のように1フレームに1回列挙するのより
本当に軽いかというと微妙なような…。1フレームに10回というのが多すぎるかどうかは知らないが。
>>274 この例だとUnitClassを更新するとき、足場情報として渡してしまったほうが自然な希ガス。
UnitClass::update(MapClass *mappoint)とか。
あるいはもっと限定的に、抽象的な階層でやるとか。
UnitClass::update(UnitMoveingEnv *env)とか。
地形が崩れるとか、ってのはMapClassインスタンス自体の置き換えとか、
パラメータ与えての更新とかになりそうだから、
MapClassとUnitClassのインスタンス郡を操作する、
上位のレベルで処理を行うべきに見える。
足場情報を与えたりするのも、当然その上位レベルのクラス。
>>276 > std::list < ITask* >として画一的に扱おうとして、混ぜたものを、
> 後から選り分ける、というのは設計として退化してる。
その考え方は間違いだと思うね。
DBとか全部データを放り込んで、それをqueryで取り出すじゃん。
それを事前に選別したり分類したりしてstoreしておくと記憶容積がもったいないじゃん。
取り出されるパターンが類型化していたり事前にわかっていれば、indexを事前に張ったりは出来るけど、
今回は、事前にわかっているという仮定ではないと思うのだけどな…。
>>279 > それだと、タスクシステム自体が、Enemyクラスを知っている必要があって、
> タスクシステム自体の可搬性が失われているから論外。
ゴメン実はタスクシステムってよく知らないんだｗ
Enemyクラスだろうが、何クラスだろうが、
それをインスタンス化して使おうとする、使う側のクラスは、
それらの型情報やインスタンスの保持の仕方を知っているのは当然のこと。
> あるいは、タスクシステムにそんなごてごてした機能を追加したくなければ、
ごてごて？
class Task{
enter();leave();
}
class EnemyTask() : public Task {
EnemyTask(alltasks, enemytasks)
enter() {略}leave{略}
}
こうやってて、
alltasksを実際に扱ってるクラスで、
タスクをインスタンス化するついでに、
new EnemyTask(alltasks, enemytasks)
してやればいいんじゃないのかな。
あとはいたるところでtask.enter(), task.leave()するだけでシンプル。
>>281 > DBとか全部データを放り込んで、それをqueryで取り出すじゃん。
あれはクエリが複雑になるだろうから、
事前に準備しようがないでしょうにｗ
>>264 > これだけ一通り情報があって
>>251 みたいにちゃんと理解できた人もいるわけで、
> ここから何も読み取れないとは、よっぽどのC++初心者なんだな。
なんか調子に乗り過ぎてない？
>>251 で「理解できた」と言っているのは、
>>152 で聞いた「生成を管理」
するかどうかの判断についてどういうメリット・デメリットを考えたら
「生成を管理する」なんて面倒な判断になってしまうのか、ということだけ。
だから、システム全体の意義を理解したわけじゃない。むしろシステム全体の
意義については、まだ不審な点がある。具体的に聞いてみたい点が出てくれば
また聞かせてもらうことになるかもしれない。
このスレの意義としては、システム全体の意義についての批判にも建設的な
答えをして欲しいところ。批判と煽りが混ざっていて不愉快かもしれないけど、
煽られて煽り返すような流れは敢えて断ち切って欲しいなぁ。（煽りは無視
すればいいだけだと思う。）
>>282 ああ、意味がわかった。Task::Enterというのは、EnemyTask::Enterのことか？
単にTaskと書いてあったから、それがタスクシステムであって、タスクシステムのaddTaskで
EnemyTaskだけ ぶんどる話かと誤解した。ごめん。
> new EnemyTask(alltasks, enemytasks)
これは嫌だな。その設計だと、EnemyTaskを生成したいタスクが、
alltasks(すべてのタスクのlist) と enemytasks (敵のタスクのlist )に対してアクセス権を
持っていることになる。
敵タスクを生成するのが、敵タスクだとは限らない(全然別のタスクの可能性だってある)ので、
そういうタスクが、enemytasks にアクセスできるのはおかしい。alltasksに出来るのはもはや論外。
あと、EnemyTaskを列挙したいのは、たとえば自機クラスであって、自機クラス何らかの設計変更によって
突如、敵タスクを列挙したくなったからと言って、EnemyTaskのシグネチャを変更して、かつ、その生成を
行なっているところのコードをすべて修正しないといけないのはおかしい。
要するに設計がおかしい。
>>283 > あれはクエリが複雑になるだろうから、
> 事前に準備しようがないでしょうにｗ
今回のケースだって、事前にqueryは予測できないよ。
敵タスクのみ列挙したいというのは仮定することが出来ないし(と私はこの問題を捉えている)、
仮にその仮定ができたとしても、そもそも
>>276 の実装は
>>279 で書いているようにさほど高速化できている
とは言えず、記憶容積を無駄にしているだけ。
また、設計的にも、
>>285 の欠陥がある。
>>284 > だから、システム全体の意義を理解したわけじゃない。むしろシステム全体の
> 意義については、まだ不審な点がある。具体的に聞いてみたい点が出てくれば
> また聞かせてもらうことになるかもしれない。
どんどん質問しとくれ。あんたの質問なら歓迎だ。
> このスレの意義としては、システム全体の意義についての批判にも建設的な
> 答えをして欲しいところ。
それは出来かねるなぁ・・。
このスレは学校でもなければ教育現場でもないので、本人に知りたいという意欲があって、
かつ、ある程度の理解力があると思ったときだけ私は答えるようにしている。
ひとことで言えば気が向いたときだけ私は質問に答える。
煽りに煽りで返すのが見苦しいと言うのはわからなくはないが、まあ、私は気の向いたようにやるよ。
>>284 >> これだけ一通り情報があって
>>251 みたいにちゃんと理解できた人もいるわけで、
>> ここから何も読み取れないとは、よっぽどのC++初心者なんだな。
> なんか調子に乗り過ぎてない？
これについてだが、私は自分が、調子に乗りすぎているとはこれっぽっちも思わないよ。
少なくとも、あんたは、いま私が想定している「タスクシステム」について
その全体的なソースコードをいま頭のなかにイメージできているはずだ。
それに対して
>>262 は、全くソースコードすらイメージできていないと言うから
それは真面目に読んでいないか、C++等の能力が足りないかだろうと言っているんだ。
> だから、システム全体の意義を理解したわけじゃない
タスクシステムの意義なんか私は全く話してないよ。
タスクシステムは、こう実装して、こう使うというのを一通り見せただけ。
しかし、あんたのように私の文章を本気で読んでくれたなら
どう実装するかぐらいは頭に浮かんだはずだし、どういうケースで
タスクシステムが有効に機能するかぐらいわかると思うんだが。
>>262 本当に聞きたいなら >211 を読んで質問の仕方を変えたら？
詭弁で相手を言い負かしたいだけとしか思えない書き込みも多いから
それと混同されてしまうよ。
>そんなことは知らんがな。
291 ：
名前は開発中のものです。 ：2009/08/26(水) 15:56:26 ID:Jc1aOsD2
>>258 ＞
>>197 のgetTasksがその具体的なコード。
と言われても、やりたいことはわかってもわからんがな。
システム自体、クラス化してるかと思ったらそうでもないし。
正直、想定の範囲外だし、いっぺん作ってみないと想像できん。
＞「簡単に書ける」コードを実際に書いてみせてくれないかな。
グローバルな関数でやるならわからん。
クラス使うんなら、システム側にcheckHitArea(Character* myself, enum target)みたいな関数で、
（Characterをenumにしてもおｋ）特定のタスク対全タスクみたいな感じで処理させるとか。
>>259 ＞確保していたオブジェクトのデストラクタを呼び出すことを保証できないよね。
free(...)で明示的にデストラクタを呼ぶようにしてる。
＞オブジェクト何個作る気かは知らないけど
多くて100個ぐらいかな。
大量に生成する必要がある割にすぐに破棄するような処理。もしくはずっと取っておく場合。
敵機や自機の弾だとか。
＞index = ((byte*)ptr - (byte*)&array[0]) / sizeof(T); 云々
これは同じ型が入っていないとまずいんじゃないの？
一応、汎用（ってことに）してるから現在の実装だと痛い。
同じ型を入れる仕様にしたら参考にする。
292 ：
えいいち ◆GRGSIBERIA ：2009/08/26(水) 16:29:50 ID:Jc1aOsD2
>>260 ＞いま気づいたが、このMemoryPool、馬鹿ほどメモリを消費して、OSのswapが生じてるんじゃないのか。
キャストで領域を割り当ててるからなんじゃないの？
free(...)で呼び出す分には何も起こらないし。
＞何故次へのポインタがpublicである必要があるんだ？
関数呼び出しと命令数削減のためいつの間にかpublicに追い出されてた。
＞何故ここがlongなんだ？ size_tを指定して確保してあるのだから、範囲はsize_tだろうが。
今気付いた。thx
＞メンバ変数名と引数で全然違う名前にするの勘弁してくれ。ソースが追いかけにくい。
悪い。癖だ。
＞Tのコンストラクタは呼び出さないのに、デストラクタだけ呼び出すんだな。
コンストラクタの検証だけやってなかったな。一応、修正した。
まあ、速度はさらに落ちたが。
王様ご就寝ｗ
やべ、王様に勝手に進言しただけで赤字になるｗ
ここまで熟知しておきながら２ｃｈに来るとは・・・目的は タダ単に僕はしゅごいぞ ウルトラマンだぞーか？
この人こわい
>>203 最悪じゃん
意味があるのかないのかわからないポインタずっと内包し続けるとか
どの辺に設計の美学があるのか聞きたいｗ
そんなに下手糞なら引数で渡せよ
>>209 >私には、「自機クラス移動したら敵クラスも必要になっちゃうし」の意味がわからないんだよね。
仮に別のプロジェクトに自機クラスを移動するとしよう
そうするとさ自機クラスは敵クラスがなくても動ける仕様であるにもかかわらず
自機クラスをもってくるには敵クラスが必要になっちゃうんだよね
別に移動なんてしねーよと思うかもしれないけどこれが重要で
これってのは敵クラスを変更したときに自機クラスも影響を受けることを意味してるんだよね
だから自分の必要な処理「だけ」を内側に内包するためのカプセル化なんだよ
それにつながるのは他のクラスの変更に強いクラスにするためだ
だけど、タスクシステムを使うと色んなクラスに根っこを生やすことになる
一つクラスを直したら影響範囲すごく大きくなってしまう
>>285 > 敵タスクを生成するのが、敵タスクだとは限らない(全然別のタスクの可能性だってある)ので、
タスクシステムってそういうものなの？
俺が考えてたのはそれとは違った。そもそも各タスクが他のタスクを生成などしない。
互いに型を知り合ったりはしない。パラメータとして与えられるレベルの型のみを知ってる。
GoFのMediatorを解してのみやりとりすることになる。多対多ではなく、一対多の関係。
タスクシステムってのは相互にグイグイ食い込んで作るものなの？
> あと、EnemyTaskを～はおかしい。
そもそもそんな心配など無い。
> 今回のケースだって、事前にqueryは予測できないよ。
クエリじゃない、フィールドの公開程度のこと。
いくつものテーブルからandで引っ張ったり、
グループ分けして集計したり、サブクエリを結合したりなどしない。
少なくとも敵タスクを列挙したいというのは、
設計段階で分ることであって、実行時のことではない。
> 仮にその仮定ができたとしても～記憶容積を無駄にしているだけ。
容量はそりゃ効果に見合うか次第。速度は…そもそもlistを使いたい。
>>297 流れは読んでないし、完全に横レススマソ状態ですが、
> だから自分の必要な処理「だけ」を内側に内包するためのカプセル化なんだよ
この一文はなんかキラッと輝いてる。
タスクシステムのなんかモヤッとした印象を、
颯爽と振り払う清清しい突風のように見える。
何言ってんだ俺。酒のンでます。
コンパイル時に実行されてただの一連の関数呼び出しになるコンパイル時クエリとか夢が広がりますね
タスクシステムとは、OOPLでオブジェクト郡を操作する場合、
>>296 王様
トリップも変え被害妄想風になってネカフェから書き込みですか？
すばらしい、すばらしい技術の持ち主ですね
ぜひとも今後のタスクシステムの有効性について語っていただきたい
>>290 > boost知ってるってことは少なくともLinux系はいじったことあるはずで・・・
> そんなの何年前かも分からない状況で・・・
boostを何だかミラクルなものだとでも思っているのか知らないが
C++使いなら多少使って当たり前なんだがな。あんたはどんだけ素人プログラマなんだ。
> 王様 迷路ゲームで
> ■■■■■■
> ■◇◇■■■
> ■■◇■■■
> ■■◇■■■
> ■■◇◇◇◇
> ■■■■■■
> のような曲がっている通れる場所はどのように実装されるのでしょうか？
意味がわからない。
その手の迷路は、例えば、
通れる場所を 0 , 通れない場所を 1として2次元配列で持っておくだけだが、
そういう意味ではないのか？
それとも、上のような迷路を自動生成するという話か？
何度でも言うが、あんたの日本語、意味不明なんだ。
日本語がきちんと使えるようになってから出直してきて欲しい。
>>291 > 正直、想定の範囲外だし、いっぺん作ってみないと想像できん。
話が噛み合ってないので、じゃあ、この話はいったん終了。
>＞index？=？((byte*)ptr？-？(byte*)&array[0])？/？sizeof(T); 云々
>これは同じ型が入っていないとまずいんじゃないの？
うん。型ごとにpoolerを持っていると仮定。
>>292 >＞いま気づいたが、このMemoryPool、馬鹿ほどメモリを消費して、OSのswapが生じてるんじゃないのか。？
> キャストで領域を割り当ててるからなんじゃないの？
キャストして領域を割り当てるのは何の問題もない。
replacement newについて勉強しとくれ。
>>296 HSP君、久しぶり。
よかったら、私のタスクシステムについて、感想、聞かせとくれ。
>>297 > 意味があるのかないのかわからないポインタずっと内包し続けるとか
> どの辺に設計の美学があるのか聞きたいｗ
> そんなに下手糞なら引数で渡せよ
ホーミング弾が自機のポインタを内包する話か？
ホーミング弾なのだから、updateのごとに自機の座標が必要に
なるわけで、ホーミング弾が自機のポインタを内包しているのは
おかしくないし無駄でもないと思うがな。
「引数で渡せよ」で思い出したのだが、あんた、引数君か？
ホーミング弾に自機の座標を引数で渡すという話か？
それはどのクラスが？
まさか、
int x,y;
jiki.getPosition(&x,&y);
homing.setJikiPosition(x,y);
こういうことか？
こうするためには、この呼び出しをしている部分では、
自機クラスとホーミングクラスと両方にアクセスできる
ことになるが、シーンクラスのようなものがあると仮定しているのか？
>>297 >>私には、「自機クラス移動したら敵クラスも必要になっちゃうし」の意味がわからないんだよね。
> 仮に別のプロジェクトに自機クラスを移動するとしよう
ああ、意味わかったよ。「移動」っていうのは座標ではなく、
ソースレベルでの移動なんだな。そう書いてくれれば、すぐにわかったんだが。
> そうするとさ自機クラスは敵クラスがなくても動ける仕様であるにもかかわらず
> 自機クラスをもってくるには敵クラスが必要になっちゃうんだよね
うん、それはそうだ。
だから、そういうケースにおいて、ホーミングと自機クラスとの結合度を
下げたほうが良いケースがあるというのは、わかるよ。
特定のゲームの開発だから、結合度を多少犠牲にしてでもソース短く
書いたほうがいい場合と、あんたが指摘しているように、結合度をなるべく弱くして、
それぞれのクラスにコンポーネント性を持たせたほうが良い場合とある。
まあ、おおむね私はそれに対しては反論はないよ。
そのへんはケースバイケースということで。
>>297 ただし、引数として渡すのは、
>>305 のようなソースになるから、
これは、あまりスマートでもないような気がするな。
ホーミングのコンポーネント性を高めるために、自機クラスへの
ポインタをホーミングクラスから外に追い出したのに、こうやって
毎フレームどこかで、自機クラスから座標を取得して、それを
ホーミングに対して設定してやらなければならないのでは、
コンポーネント性が落ちている気がする。
ホーミングのソースと自機のソースを別プロジェクトに持って
行っただけでは機能せず、それを結びつけるglue codeが毎回必要になる。
ホーミングは、結局、自機クラスの座標は必要なのだから、何らかの
形で自機クラスの座標を取得しなくてはならないので、glue codeは
必須には違いないけど、毎フレーム処理する部分のコードがふくれあがると
見通しが悪くなるからbuilderで(要するにオブジェクト生成時に)
bindしてしまうほうが毎フレーム処理する部分は膨れあがらなくて
済むとは思う。(スマートでもないかも知れないが)
>>303 王様 迷路をタスクシステムで実装して欲しいのです
底辺のプログラマである私では王様のタスクシステムを使って
どのようにすればよいのか かいもく検討もつきません
意味がおわかりいただけないなら
ぜひ どのようにして迷路ゲームをタスクシステムを使われて実装されるのでしょうか？
>>298 > 俺が考えてたのはそれとは違った。そもそも各タスクが他のタスクを生成などしない。
> 互いに型を知り合ったりはしない。
ええと、シューティングでボスキャラがザコを生成したいときに、
ボスキャラのコードで、
taskSystem->AddTask(ZakoClass);
のようにタスクシステムに依頼して生成する。
(ようなタスクシステムを私は想定している)
あんたの想定するタスクシステムでは、ボスキャラがザコを生成したいときに
どういうコードを書くんだ？
>>298 > 少なくとも敵タスクを列挙したいというのは、
> 設計段階で分ることであって、実行時のことではない。
いや、敵タスクを列挙したいのは誰かってこと。
例えば、ボスキャラがザコだけ列挙したいということになった。
そしたら、あんたのケースだと、ザコの生成と解体を捕らえて
listに突っ込む必要が出てくるだろ？
現場レベルで言えば、
ボスキャラの設計をしている人間と
ザコキャラの設計をしている人間とは違うことだってあるわけで、
ボスキャラの実装によって、ザコキャラの実装変更が生じるのは
許し難いんだ。
> 速度は…そもそもlistを使いたい。
ん？std::list？
std::listはremoveはマシだけど、traverseはstd::vectorより
桁違いに遅いよ。本当にコード書いて測定してみた？
>>302 >
>>296 > 王様
> トリップも変え被害妄想風になってネカフェから書き込みですか？
え？
>>296 のHSPerは、このスレのpart5から居るじゃん。
HSP君は、HSP君で、また変わった人だとは思うけども。
■ HSP君の特徴
・HSPがメインの言語(釣りかどうかは知らん)
・C/C++はほとんど使わない(使えない?)
・そのわりには結構設計面などに関しては的確な指摘が来る
>>301 > タスクシステムとは、OOPLでオブジェクト郡を操作する場合、
前から気になっていたんだが、
×郡
○群
だ。typoではないようなので指摘しておく。
>>309 > ぜひ どのようにして迷路ゲームをタスクシステムを使われて実装されるのでしょうか？
「ぜひ どのようにして」はなんか支離滅裂だが、それはおいておくとして、
迷路自体は、2値でいいなら、
struct MazeMap
{
bool maze[MAZE_WIDTH][MAZE_HEIGHT];
// その他、初期化、読み込み、自動生成、etc..のmethodを追加すべし。
};
迷路完成。
これを入れるシーンクラス的なものを用意。シーンクラスはタスクにしておこう。
class MazeScene : public ITask
{
MazeMap map; // 迷路
MyChara myChara; // 主人公
virtual void update(Context& context); // 描画用
};
まあこんな感じでないの？MyCharaはMazeSceneに内包させずに、
別のタスクとして扱っても良いが。
まあ、この程度なら、タスクシステムを使うメリットはほとんどないよね。
もっとキャラクターの生成/解体が激しく行なわれるタイプのゲームでないと。
>>314 王様 つたない日本語でもうしわけありません
王様質問なのですが
maze[MAZA_WIDTH][MAZE_HEIGHT];
に爆弾がしかけられるようにするにはどのように実装すればよろしいでしょうか？
■ 引数君とactorについて
このスレのpart3,4あたりで引数君というのが居て、彼は
> update();
> で動くのと
> update(jiki,teki,tama,unko);
> で動くのとじゃ
> プログラムとしては絶対に下のがいい
なんてことを言って、タスクシステム派からキチガイ扱いされていたわけだが、
案外、彼が言いたかったのは、
>>306-308 みたいなことだったのかなぁ。
だとしたら、周りに全く伝わっていなかったというか、なんだか
考えたら気の毒になってきた。
それで、「タスク = actorじゃん。お前ら、actorは許せて、タスクシステムは
許せねーの？」というタスクシステム派がいたが、私はそれはちょっと違うと思う。
actorは普通、他のactorのポインタなどを持ったりしない。
ホーミングactorが自機の座標を欲しければ、自機の座標を外部から設定してもらう。
要するに
>>306 のようになる。
まあ、これでもいいのだけど、actor間の直接的なデータのやりとりもしてみたい。
(つづく)
>>315 > maze[MAZA_WIDTH][MAZE_HEIGHT];
> に爆弾がしかけられるようにするにはどのように実装すればよろしいでしょうか？
属性として、通路と壁と爆弾の三種類があるってこと？
enum MazeChip
{
Blank, // 通路
Wall, // 壁
Bomb, // 爆弾
};
んで、MazeMapを次のように変更。
MazeChip maze[MAZE_WIDTH][MAZE_HEIGHT];
これで爆弾も配置できるようになった。
ところで、これはどこかの学校の宿題なのか？
>>317 王様 もうひとつ質問よろしいでしょうか？
maze には魔法がかかっててあるキーワードを入れないと
そのmazeには入れないようにしたいのですが
どのように拡張されたらよいでしょうか？
そこらへんにころがっている問題の一部です
王様なら簡単に解けるだろうと思い提言したまでです
>>316 のつづき
■ actor間のデータ通信について
actor間でデータをやりとりしたい。
例えば、ホーミング弾actorに自機actorの座標を渡したい。
自機actorを
class Jiki : public ITask,public Position
{
のように多重継承しといて、Jiki actorをPositionにupcastして
ホーミングactorに渡しておくなら、ホーミング弾actorは、
Jikiクラスのインターフェースを知る必要はなく、単に
Positionクラスだけ知っていれば事足りるので、結合度はやや低くなる。
しかし、それでも自機クラス設計時に、Positionクラスから派生されるかどうかの
判断は、ホーミング弾クラスを設計するまでわからないので、こういう設計の仕方は
避けたい。
そこで、シーンクラスみたいなものを作って、そこで
>>306 みたいなコードを書くことに
なるのだけど、自機の座標を必要とするのがホーミング弾クラスだけとは限らず、
また、ホーミング弾もひとつとは限らず、動的に生成されたり、あとから生成されたものが
増えるごとにシーンクラスを書き換えるのはとても嫌だ。
なぜなら、分業で作っていると、ホーミング弾クラスのようなものは何人ものプログラマが
作っていて、シーンクラスを書いているプログラマは一人で、新しく自機を狙う敵キャラを
追加するごとにシーンプログラマの書いているソースコードをいじらなくてはならないのでは
シーンプログラマは自分のソースコードの正しさを検証しきれないからである。
(つづく)
>>318 > maze には魔法がかかっててあるキーワードを入れないと
> そのmazeには入れないようにしたいのですが
> どのように拡張されたらよいでしょうか？
「mazeに入れない」の意味がわからない。
mazeの外に他のmazeがあるのか？
どこからmazeに入るという話？
maze自体はシーンクラスが内包しているのだから、
他のシーンから移ってくるなら、前に居たシーンクラスを
解体して、新たにMazeScene (
>>314 ) をタスクシステムに
生成してもらえば良いだけだが。
MazeSceneシーンへ遷移するかのチェックは、前のシーンが
行なうわけだから、そのシーンで「あるキーワードを入れた」かどうかの
判定をすればいい。
>>316 何をスマートといってるの？
タスクシステムで作ったらグローバル変数にして渡すしかないんだろお前
宙ぶらりんのポインタ保持とか確実にアウトな実装方法しかお前しらねーじゃねーかよ
引数で渡すことやめたら確実にこの問題にぶち当たるんだよ
ホーミングに毎回値を渡すのが面倒とかいってるけど
実装上それが必要なのになんでそれをわずらわしいと思うの？
逆に聞くけどそれが渡せないプログラムって存在しないだろ
渡すようなプログラムだとなにかまずいことおきるの？
なんで必要な処理にも関わらず省略しようとするの？
お前のプログラムを初めて見る人間がホーミングでターゲット設定してる箇所調べるには
どこみたらいいの？
ホーミングと対象物の関連を探すんじゃねぇのかよ
切り離してグローバル変数迂回してアクセスしてたらてめぇに聞かなきゃ発見できねぇだろ
情報の小出しでの質問とか嫌がらせ以外の何でもないな
>>322 なにか前提がかわって不都合が起きたら遠慮なく言えよ
>>321 > タスクシステムで作ったらグローバル変数にして渡すしかないんだろお前
私のコードにstatic変数もグローバル変数もひとつもないよ。
> ホーミングに毎回値を渡すのが面倒とかいってるけど
> 実装上それが必要なのになんでそれをわずらわしいと思うの？
毎フレーム何らかの手段で取得する必要はある。
だけど、それをシーンクラスが行なう必要はない。
このデータのやりとりはもっと抽象化できる。
>>321 > ホーミングに毎回値を渡すのが面倒とかいってるけど
> 実装上それが必要なのになんでそれをわずらわしいと思うの？
わずらわしいのではない。
>>319 の最後の段落のような問題が発生するのが嫌なんだ。
>>320 ご自分でmazeと定義なされていらっしゃいますが
具体的に申し上げますと
maze[0][0] から maze[0][1] に移動する場合
どのようなコードになられるのでしょうか？
>>326 > ご自分でmazeと定義なされていらっしゃいますが
私は、mazeと"定義"はしてないよ。
> MazeChip maze[MAZE_WIDTH][MAZE_HEIGHT];
これ、宣言だろ。しかも配列の要素の型はMazeChip。
> 具体的に申し上げますと
> maze[0][0] から maze[0][1] に移動する場合
> どのようなコードになられるのでしょうか？
だから、それなら、
>>318 は、
MazeChipからMazeChipに移動するときに、
「キーワードを入れないと移動できない」
と書くべきだろ。なんで変数名で書くんだよ。
なんかあんたの日本語は読むのに疲れる。
いい加減疲れてきた。あと何回質問があるんだ？
あんたの宿題に付き合わされるのは、そろそろ御免被りたい。
>>325 しないよ
タスクシステムにわざわざのっかってやらなきゃいけないほうが嫌だよ
ホーミングと対象物とやりとりするにもなにか特殊な手続きがいるようになるんだろ？
>>322 > 情報の小出しでの質問とか嫌がらせ以外の何でもないな
私のことかな？それともID:YflT6adjのことかな？
まあ、仮に私のことだとして、
私は長文で投稿したいんだが、ここは長さ制限があるので10行ぐらいずつしか投稿できないんだわ。
きっちりまとめてCodeZineにでも投稿したほうがいいか？
それならそうするが。
>>327 え？
struct MazeMap
{
bool maze[MAZE_WIDTH][MAZE_HEIGHT];
// その他、初期化、読み込み、自動生成、etc..のmethodを追加すべし。
};
class MazeScene : public ITask
{
MazeMap map; // 迷路
MyChara myChara; // 主人公
virtual void update(Context& context); // 描画用
};
と定義？宣言されてますが・・・
私の宿題につきあうのではなく、あなたの主張するタスクシステムは有用だ
ということをおうかがいいたしてるのですが
>>328 > しないよ
ん？それは何故？
状況をもう少し正確に以下に書いてみるよ。
・シューティングなので自機を狙う敵や自機の座標を必要とする敵はたくさんいる。
・それぞれの敵を何人かで分業して実装させる
・自機を狙う敵を追加するごとに、
>>306 のようなコードがシーンクラスに必要になる
・シューティングなので敵は動的に生成され、動的に解体される。
・シーンクラスを設計している人が、そのシーンでどの敵が出現するのかまで関与したくない。
敵の生成は、スクロールマップ(画面の地形スクロールがどこまで進んだか)によって自動的に決定される。
こうなっているときに、それぞれの自機を狙う敵を追加するごとに、シーンクラスに
>>306 のような
コードを追加することになると思うのだけど、そうではない？
タスクシステムを使わずに実装する話なのか、それともタスクシステムを使うが
>>306 のようなコードは
書かないという話なのか、それとも、タスクシステムを使って
>>306 のようなコードも書くが、だけど問題ないと
言うのかどれ？
> タスクシステムにわざわざのっかってやらなきゃいけないほうが嫌だよ
タスクシステムに乗っかる必要はないよ。タスクシステムとは無縁の抽象化されたデータ通信手段を用意する。
>>330 私は
>>317 で
> んで、MazeMapを次のように変更。
> MazeChip maze[MAZE_WIDTH][MAZE_HEIGHT];
と書いてあるので、その全体ソースはおかしい。
>>317 を見落としてないかい？
333 ：
名前は開発中のものです。 ：2009/08/27(木) 07:26:55 ID:/N8rqxow
335 ：
名前は開発中のものです。 ：2009/08/27(木) 07:34:33 ID:/N8rqxow
何度も言うけど書かなきゃいけない処理まで省略しようとするのはなんでなの？
よく理解できませんが
>>328 > タスクシステムにわざわざのっかってやらなきゃいけないほうが嫌だよ
についてだけど、例えば、次のようにやる。
(C#風の疑似ソースコード)
class Homing
{
// 自機のポジションを返すdelegate
public Position delegate getJikiPosition;
自機の座標が必要なときは、Homingクラスは、このdelegateを使って、
自機の座標を得る。このgetJikiPositionは、Homingクラスの生成のときに、
Homingクラスのfactory (builderを兼ねる)が設定する。
ITask* createHoming()
{
var homing = new Homing();
homing.getJikiPosition = delegate { return jiki.getPosition(); }
return homing;
}
こうなっていれば、シーンクラスのほうにコードの追加はしないで済むし、
ホーミングクラスを別プロジェクトに移動させるなら、このfactoryに手を加えればいい。
>>335 > 何度も言うけど書かなきゃいけない処理まで省略しようとするのはなんでなの？
私は「省略」しようだなんてひとことも言っていない。
「どこかに書かなくてはならない」
それは何度も言ってるだろ？
しかし書くところがおかしい、と言っているんだ。
まあ、議論の前提が違うのかも知れん。あんたがタスクシステムを使う派なのか使わない派なのか
すら教えてくれないので私としては答えようがない。
簡単に言えば、
シーンクラスはホーミング弾クラスを作っている奴は、書き換えられないんだ。
ということ。
だから、
>>337 のような解決案なら、私は賛成なわけだ。
>>336 私へのレスならアンカーを入れてとくれ。
あとで追いかけられなくなる。
>>332 へのレスだよね。
> よく理解できませんが
> enum MazeChip
> {
> とあるので、この共用体は迷路の一部分とみなしてよろしいでしょうか？
迷路の床、1つ分のチップの種類を定義してある。
これは迷路で使われる床の種類を定義しただけであって、
それ自体は迷路の一部じゃない。
> そして、MazeChip maze[MAZE_WIDTH][MAZE_HEIGHT];
> これで、迷路全体を現していると解釈してよろしいでしょうか？
迷路の床全体は、これ。
struct MazeMap
{
MazeChip maze[MAZE_WIDTH][MAZE_HEIGHT];
// その他、初期化、読み込み、自動生成、etc..のmethodを追加すべし。
};
このうち、迷路の床を表現しているのが、
> MazeChip maze[MAZE_WIDTH][MAZE_HEIGHT];
これ。
ここまではいいか？
340 ：
名前は開発中のものです。 ：2009/08/27(木) 07:50:48 ID:/N8rqxow
>>337 自機が死んだり、ターゲットを切り替えたときの処理はどこを見て書いたらいいの？
ちょっとしたことで全部お前のオレオレ仕様にお伺い立てなきゃいけないんだな
>>339 >ここまではいいか？
なんとか理解できたよ
王様は日本語は達者ですが、英語のソースはあまり得意とはいえませんね
>>340 > 自機が死んだり、ターゲットを切り替えたときの処理はどこを見て書いたらいいの？
自機が死んだかの判定はfactoryに書くよ。
具体的には createHoming(
>>337 )のなか。
自機が死んでいるかどうかは、factoryのなかならチェックできるから、
自機が死んでいれば、positionとしてnullを返しておけばいいだろう。
ターゲット切り替えというのは、何かの条件をトリガーとして、
プレイヤ2(二人プレイだとして)を狙うとかそういうこと？
そういう場合は、
Position delegate getPosition(int player);
こういうdelegateにするね。
> ちょっとしたことで全部お前のオレオレ仕様にお伺い立てなきゃいけないんだな
Homingのfactoryを書くのは、Homingクラスの制作者だから、
好きなように書けると思うが？
上のターゲット切り替えにしても、Homingクラスと、そのfactoryしか
いじってないから、Homingクラスの制作者の自由に変更できる。
>>339 >迷路の床、1つ分のチップの種類を定義してある。
>これは迷路で使われる床の種類を定義しただけであって、
>それ自体は迷路の一部じゃない。
すいません 上記の部分 床の種類を定義されてるようですが
爆弾は床ではないですよね？
ここの部分が理解できません
>>341 > 王様は日本語は達者ですが、英語のソースはあまり得意とはいえませんね
意味がわからんが…。
>>336 > では、迷路の一部分から、隣の迷路の一部分への移動は
> どのような方法で、実装されるのでしょうか？
主人公が移動するのだから、MyChara(
>>314 )が移動するなら、
主人公が現在のpositionを持っているだろうから、
MyChara::updateで、移動できるかをチェックして、
移動できれば移動するコードを書けばいいんでないの？
MazeScene::update(
>>314 )のなかでやってもいいけど。
以下、MyChara::updateで行なうサンプルを書く。
void MyChara::update(const Context& gameContext)
{
var input = gameContext -> getInput();
var map = parents->getMaps();
switch (input->getKey())
{
case '2' : // 2,4,6,8キーで下、左、右、上に移動
if (y<MAZE_HEGIHT-1 && map[x][y+1]==MazeChip.blank) y++;
break;
…(省略) // 以下、4,6,8の場合も書くべし。
}
}
>>343 > すいません 上記の部分 床の種類を定義されてるようですが
> 爆弾は床ではないですよね？
> ここの部分が理解できません
うへ。そんな突っ込みが来るとは夢にも思わんかった。
あんた、なかなか面白いな。
それはともかく、「爆弾」は「床」ではないのはもちろんのこと、
厳密に言えば、「壁」にしても「床」じゃないしな。
こういうのを、ゲームの現場で「床」チップと呼ぶことが
多いんだけど(うちだけか？)、なんでそういうものを
「床」と呼ぶかと言うと、昔のゲームは2Dで平面的だったから、
その上に何がおかれていても床っぽかったからじゃないかな。
初代ドラクエとか、木が生い茂っているマップチップでも
床であるかのごとくずんずん進んでいけるしな。
まあ、「床」のくだりは、「迷路を構成するチップ」と
頭のなかで置き換えとくれ。
今日は出かけるのでこのへんで。
もうこいつはID:YflT6adj無視しろよ
>>345 たしかにタスクシステムを使うメリットはあまり見えてこないね
なるほど2Dでとらえてたのね
俺は3Dでとらえてたので
床とは言わずに部屋としてとらえてた
そして、爆弾については
部屋 has 爆弾という思想
class room
{
room *_west;
room *_nishi; // 英語忘れたごめんｗ
object *_what; // ここに爆弾を代入
};
簡単に書けば
Maze has rooms
Maze has player
のようにA has B の関係で解いた
これをタスクシステムを用いてどのように表現するのかを知りたかったわけだが
まぁ、
>>347 のように、構造体で思考停止している奴がわんさかいるんでね
肩身が狭いよ
消えてなくなれオブジェクト指向ってスレもあるしね （もう消えてるっぽいが）
自分の知識の乏しさを露呈してるとしかいえないが
事業内容 情報処理業
お金の話してサーセンｗ
>>348 タスクかどうか知らんけど別の考え方すれば
爆弾 has 部屋、さらに一般化して役者 has 属性 になるんじゃね
役者に識別子があるとすれば、役者は識別子から属性への関数みたいに定義できるな
俺もその方針でちょっと考えてみるか
>>310 > あんたの想定するタスクシステムでは、ボスキャラがザコを生成したいときに
> どういうコードを書くんだ？
ボスはザコを生成しない、列挙もしない。
ボスを生成した側のオブジェクトが、ザコもコントロールする。
具体的なボスやザコの型を知る、ボスシーンオブジェクトを更新させ、
その中でボスとザコとの破棄生成や協調動作の関係を記述する。
タスクは、AbstractTask *として全部に共通する、描画やらなんやら、
それをまんべんなく実行させるために、alltasksリストに入れて使う。
ボスザコの協調動作に必要なリストがあれば、ボスシーンオブジェクトは、
自分のために内部にそれを必要なだけすきな表現で準備する。
>>276 で示したような登録すたいるはアドホックすぎるので、
可能であればそうでもいいし、ムリにあれを貫く必要などはない。
やはり、使用される文脈を想定すべきではないので、よくないね。
>>311 > ボスキャラの実装によって、ザコキャラの実装変更が生じるのは
生じない。
>>276 方式では、生じるｗ
> 桁違いに遅いよ。本当にコード書いて測定してみた？
桁違いには遅くない。というか、traverseってのが何なのか知りません。
vectorの生成、参照、削除は0,0,5922。listは78,0,31。
単位はミリセカンド。ループ100000回の<int>で。
>>313 ありがとう。その二つを区別できてなかったｗ
>>352 横からだが、traverseって山とか登ることだ。ここでは、listを辿っていくこと。
あんたが中学生なのか小学生なのかは知らないが、辞書ぐらい引いたらどうだ。
あと、10万回ループなんか書いて測定しても、それはすべてL1に載っているわけで
差が出なくて当たり前だろ。
辞書も引かないし、測定の仕方もド素人。全然話にならないレベルだぞ。
◆9ycqcAuWxdGZとあんたとではレベルが違いすぎる。
もう少しまともなプログラマに◆9ycqcAuWxdGZへタスクシステムの意義とかに
ついて質問とかして欲しいな。
>>353 辞書は一応引いたよ。そうです、中学生でつ。
「vectorの生成」は間違いで「vectorへの追加」です。
リストってのは、追加した後は順に辿ればよくって、
インデックスで指定してまばらに辿るものではない。
そういう用途だからってのが、リストを選ぶ一つの理由になってる。
> あと、10万回ループなんか書いて測定しても、
ループで使うってのは狙い通りだと思うだけど、
どうすればよかったのかな？
>>351 >爆弾 has 部屋
不可能ではないかもしれんが難しいかもしれんし、複雑怪奇なコードになるかもよ？
部屋 has 爆弾 でもいけるし
部屋 is 爆発 にすれば、これでも爆発する部屋ができる
class Bombroom : public room;
まぁ、こういう多様な考えが構造体世代には理解できんのだろう
>>354 本当に中学生なのか。そりゃ内容が支離滅裂でも仕方ないな。
横から見てると、あんたの相手をさせられている◆9ycqcAuWxdGZが
幼稚園児の相手をしているプロボクサーみたいな感じで
不憫に思えたのでレスさせてもらった。
> そういう用途だからってのが、リストを選ぶ一つの理由になってる。
CPU cacheに対するアクセス速度とか、new/deleteするオーバーヘッドの
大きさとかまったく考慮に入ってなさそうだな。正直、論外だよ。
タスクシステムなんかより先に、コンピュータアーキテクチャの
勉強してきたほうがいいんじゃないの。
中学生ならまだ伸びしろも大きいんだろうし。
>>356 > new/deleteするオーバーヘッドの大きさ
リストとベクタの比較において、なにをnew/delete？
>>356 ＞本当に中学生なのか。そりゃ内容が支離滅裂でも仕方ないな。
あんた、相手が中学生だからと言って言っていいことと悪いことがあるもんだけど、
その区別はちゃんとついているのかい？
>>357 > リストとベクタの比較において、なにをnew/delete？
君の手元にあるSTLの実装では、list/vectorに対して
100回続けて要素の追加を行ない、100回続けて削除を行なった場合、
list/vectorでそれぞれ何バイトの構造体が何回new/deleteされるように
なっているかな？
重箱の隅をつつくような意地悪な質問に思えるかも知れないが、
これはとても基本的なことなんだ。
ここがわかっていないのに、listとvectorでどちらが最適なデータ構造か
だなんて考えられるわけがないのだから。
>>358 いや、俺は彼が本当に中学生とは思っとらんよ。
中学生にしては、ボキャブラリが多すぎるだろう。352とかよく読んでみなよ。
中学生だというのは、本人の「おとげ」「自己軽蔑」の表れなんじゃないかと
思ったので、あえて煽らせてもらった。
本当に中学生なのだとしたら、まあ、将来が楽しみだな。
いまのうちに基礎をきちんと身につけてちょーだいな。> 中学生
347 は人格攻撃しか書いてないし単発IDなのに構造体で思考停止している奴、
後で構造体世代と言い替えているが、とわかるはずがない。
後でつっこまれたときに逃げるための布石としてレッテルを用意したんだな。
>>347 ID:YflT6adj はかなり頭良い奴だ。
少ない手間でいかに相手を馬鹿にして追い詰めるかに長けてる。
相手をしたが最後、疲れ果てるまで粘着されるだろう。
>>347 ではお聞きしますが
なぜ私がキチガイなのですか？
説明していただけますか？
>>361 キチガイと言われてますがｗ
たいてい私をキチガイ扱いする奴は構造体で動くからいいや思考ばかりなんで
もうお決まりのパターンなんですよ
ヲタクがキモイのと一緒で
馬鹿にしてるというか東京で一日で鍛えられた技術ですよ？
床屋逝ってきた
風向きが悪くなると馬鹿のふりをしてごまかそうとするのも常套手段。
何も言わずにただ否定するだけ
ああ、ただの人間不信か
耐性なさすぎﾜﾛﾀ
ID:YflT6adj みたいなのが
>>206 のいう白痴のふりというやつだな。
そこまでして勝てない戦いを続けるのは何でなんだろうなぁ…
普通タスクシステムではvectorよりもlistを使わないか
普通は自前の連結リストを使うんじゃない？
親子間の巡回順のみが重要な場合はtreeにしたりする。
うわぁ、先週あたりまで頑張ってたアンチタスカーだけど、
いやもうね、タスカーってほんとどうしようもないのな。
タスクシステム自体もタスク同士のコミュニケーションが苦手という問題を抱えているけど、
375 ：
100 ：2009/08/29(土) 01:09:58 ID:yvNElBEe
ID:YcewJeTt（new tasksystem ◆9ycqcAuWxdGZ）は
やねうらおレベルの高度な知的生命体だからどうでもいいとして
＞ タスカーは他人と会話が出来ない奴が多いとか暴言吐いてたけど
おまえID:6uucu48Dか。あのとても残念な噛み付き癖のある犬っコロか
とても残念な頭脳の子、ファイルシステム君か。とても残念だよ
さっさと俺の質問に答えな。逃げんなよ
＞
>>765 ＞＞タスクシステム自体もタスク間でのコミュニケーションが苦手という問題を抱えてるが
＞
＞なにそれ怖い。そのチンカスタスクシステム固有の問題、具体的に書いてみ？
答えなさい
お前のタスクシステムはタスクシステムじゃねぇからしらねぇよ。
トラバース→バッファリング→最適化→実行
よりも、
>>117 の方が素直だと思うんだけどどうよ。
型と処理オーダーごとにリスト持っとけばソートの必要も無いしな。
Zソートもバケットソートで高速だ。
>ID:YcewJeTt（new tasksystem ◆9ycqcAuWxdGZ）は
378 ：
100 ：2009/08/29(土) 01:21:09 ID:yvNElBEe
逃げなくていい。ペロっと書いちゃいなよ。どこの誰のタスクシステムの話なのかをよ。
じゃあ、やねうらお式の奴。と言えば通じるだろう。
380 ：
100 ：2009/08/29(土) 01:33:53 ID:yvNElBEe
なんだPCエロゲプログラマ様の考えたボクチンのタスクシステムの話か
いや、お前のタスクシステムも随分意味無いことしているなとは思ってるのよ。
別にタスクリストは1本にしなくてもいいんだぞ
↑処理オーダーごとにも分けとけ。
例えば敵弾と自機の当たり判定取りたい時にリスト1本だと識別とか面倒でしょ
>>382 確かに >117 もタスクシステムとみなす宗派の人もいるかもしれないな。
もともとは配列みたいだからリストを使ったものを
タスクシステムとみなさない宗派の人もいるかもしれないな。
いや、配列とかリストとかどうでも良いだろ、そんなこと。お前ら本当に飽きないな。
着眼点がおかしいんだよ。
ちなみに
>>117 の実装は配列。
実装が配列でも、意味の上でリストと説明する場合もあるし、もう、お前らね。
日本語大丈夫かよ。
>>385 それだけじゃなくて、型情報が死なない点もポイント。
無意味なダウンキャストを無くせる。
389 ：
100 ：2009/08/29(土) 02:26:14 ID:yvNElBEe
工学系四大ないし高専程度のまともなリテラシーを持ち合わせていて
>>385 じゃあ、座標変換みたいに全部ほしいときはどうするの？
>プリエンプションなしの
座標変換？具体的なことはよく分らんけど
393 ：
100 ：2009/08/29(土) 02:40:17 ID:yvNElBEe
>>391 ならばビデオゲームの駆動原理を簡潔に書きたまえ。寝る
>>392 それタスクシステムじゃなくてベタ組みじゃね？
ベタ組み＆引数通しの俺が全面同意できるんだけど？
395 ：
100 ：2009/08/29(土) 02:43:50 ID:yvNElBEe
あー、ついでに古典的な連続系シミュのプログラム構成についても知れ
俺のやってるのタスクシステムじゃないかも知れんけど似たようなもんだと思ってやってる
>>387 だからタスカーとかアンチタスカーとかどうでも良いだろ。正直飽きた。
何がタスクシステムなのかすら定まってないんだから
タスクシステムについてここまで話ができるあんたは立派なタスカーだよ。
>>392 > 頻繁に追加削除あるし、そもそもランダムアクセス必要か？
種類別に添字の範囲を決めることもあったらしい。
>>393 ステートマシン。
ユーザの入力→状態更新→ビデオ出力/音声出力/振動出力。
ゲームは単体アプリだから、マルチタスクも糞も関係ないんだよね。
OSのプロセス管理の真似事なんてする必要なし。
ゲームはOSのプロセス管理とは違って、メインループ部を自由に触れるということ。
>>395 粒子の振る舞いを外部からプログラマブルに定義しないのなら、
ベタ書きで十分だし、処理速度も一番速いし、実装も早い。
>>397 おおよそ全てのタイプのタスクシステムを列挙した上で批判している(
>>107 )
大概どれかに当てはまるでしょ。
> 種類別に添字の範囲を決めることもあったらしい。
>あー、ついでに古典的な連続系シミュのプログラム構成についても知れ
>粒子ベースものがいい。粒子の相互作用の時間発展をシミュレートするものだ
あ、あと、
>>46 とも意見しとく。
俺が愚かだと思う人間。
>401
あー、スマン。
405 ：
名前は開発中のものです。 ：2009/08/29(土) 21:19:58 ID:qNNhrb6t
>>403 401でもないし事情なんて丸っきり知らない俺が聞くけど、そんなもんなんじゃないの？
>405
407 ：
名前は開発中のものです。 ：2009/08/29(土) 22:00:57 ID:qNNhrb6t
>>406 なぜそこでシミュレータになるのかｋｗｓｋ
>407
409 ：
名前は開発中のものです。 ：2009/08/29(土) 23:20:10 ID:qNNhrb6t
>>408 口から出まかせだったのですね。わかります。
厳密にやればそうしなければ駄目だけどそうしなくても十分な場合があるってだけでしょ
ビリヤードとシューティングの当たり判定処理が同じだと思ってる人、リアルに存在してたんだ…。
ナンか名前が今日だけ違うなw
フツーにOOPやってる奴から見るとギョッとするような世界だよな。
こんどはOOP君ですか
>>414 そういうお前は属人クンだよｗ
中身じゃなくて、人格への偏見でしか語らぬ。
416 ：
100 ：2009/08/30(日) 11:18:13 ID:RQNrxHmb
>>404 相互の作用（押し合いへし合い）があるなら「いっせーのーせ」でやるし
相互でなく一方的な作用なら今までどおり端折っちまえばいい
典型的なSTGなら基本的に後者で何も問題ないだろ
ケースバイケース。あとタスクシステム関係ないだろこれ
みんな得意の脳内妄想じゃなくて
>>413 is-a か has-a のどちらが適切か、は何をどうモデル化するかによって変わるんだがなぁ
それとも全てのゲームの仕様をたった一つの設計で済ませられると考えてるのかねぇ・・・
419 ：
100 ：2009/08/30(日) 11:28:37 ID:RQNrxHmb
アンチはSTGも作れんような乞食しかおらんのか
>>416 の意味が分からないのか。そうかー
420 ：
名無しさん＠そうだ選挙に行こう ：2009/08/30(日) 11:35:47 ID:oK3pTspz
>>413 ＞動き方ストラテジ（略）を、最初にパラメータで渡して
動き方の実装も含めて、詳しく。
//パンシューティング
bread("↑↓↓→↑休休↑");
bread(curry_update/*←関数*/);
bread(new curry() );
俺はあまりお勧めしないが。OOPは制御構造がガタガタになるから嫌いだな。
>>416 お前がゲームの動作原理語れとか言うから書いてやったのに無視かよ。
422 ：
名無しさん＠そうだ選挙に行こう ：2009/08/30(日) 13:58:37 ID:RQNrxHmb
>>421 悪いな。阿呆すぎる発言につい呆れてしまったんだよ
>>398 >>>>プリエンプションなしの
>>>タスクを周期駆動でぶんまわす古典的なリアルタイムシステム
>>>そしてこれはゲームには必要ないという。
>>ならばビデオゲームの駆動原理を簡潔に書きたまえ。
> ステートマシン。
はいはい。ビデオゲームの駆動原理はステートマシン。クルクルパーのアンチは
おつむが空っぽでいつも爪先立ちで背伸びしてっから簡潔に書けといわれると
途端に意味の無い抽象論に走り出すね
お前の言い草だと
全てのプログラムは、ソフトウェアは、コンピュータは、機械は、流体・粉体の振る舞いは
社会システムは、いや、世界の仕組みは、有限状態機械モデルで説明できるというお話
になってしまうだろうな。なーんかどっかで書いたような話だな。j過去スレでお前とよく似た
バカの相手をしたことがあるのかもな
さて、ビデオゲームの駆動原理はステートマシンだというならば、なぜ
『プリエンプションなしのタスクを周期駆動でぶんまわす』
この仕組みがゲームに必要ないという発想に至るのかね？
423 ：
名無しさん＠そうだ選挙に行こう ：2009/08/30(日) 14:24:02 ID:RQNrxHmb
>>398 >ユーザの入力→状態更新→ビデオ出力/音声出力/振動出力。
ほう。この手続きを周期的に繰り返しているのが君のビデオゲームなのだろう？
外部入力をポーリングで取得。16[ms]程度で応答するリアルタイムシステムだな。
cyclic executive。周期駆動。だからゲームループがあるわけだ。そうだろう？
『周期駆動でぶんまわす』
この点には流石に異論はないだろうな
メインループ部を直接記述できるから、だと書いてあっただろ。
>>423 その点は異論無いな。
ただ、タスクは要らないだろうと。単にループ部に処理を書いていけば良いだけ。
処理が長くなったり、使いまわす場合は、関数を使う。普通の開発手法。
で、タスクシステムの出る幕は？
あと、周期駆動っつったって、定期的に入力が発生するだけ。
427 ：
名無しさん＠そうだ選挙に行こう ：2009/08/30(日) 14:45:07 ID:RQNrxHmb
>>424 > ゲームの動作原理がステートマシンという主張は、
> ゲームがその辺のGUIアプリとなんら変わり無いという意図。
そんな意図があるなどとはどうして読み取れようか。他人にESPを要求する
人間というのはコミュニケーションが下手だということが理解できてるのかね。
アドホックな屁理屈の積み重ねをするくらいなら前言を撤回・修正・書き直す
大人の常識
>>427 お前が「駆動原理」とかいう抽象的な聞き方するから、
普通のアプリであるゲームの動作原理を説明するのに、
普通のアプリの駆動原理である「ステートマシン」を持ち出すしかなかったんだろ。
質問が抽象的だから抽象的に答えたんだ。
俺からしたら、
『プリエンプションなしのタスクを周期駆動でぶんまわす』
と、『駆動原理』に何の関連性があるのか分からんわけで、
そんな中、駆動原理を簡潔に書けといわれても、
ごく普通のアプリです。ステートマシンです。としか答えようが無いだろ。
第一俺は、『プリエンプションなしのタスクを周期駆動でぶんまわす』は、
メインループ部を固定するという制限から派生したものと考えているわけで、
その制限の無いゲームの『駆動原理』を答えることと、題意がどう繋がってるのか
今でも分かってない。説明よろ。
429 ：
名無しさん＠そうだ選挙に行こう ：2009/08/30(日) 15:03:20 ID:RQNrxHmb
>>425 > その点は異論無いな。
ふーん。へー。それならば何故に君は
>>424 のような面白い発言をしてしまうのかね
>>424 > ゲームがその辺のGUIアプリとなんら変わり無い
おーう。絶望的デース。頭でっかちなだけで筋の悪い学生ちゃんの相手をするのはツカレマース
WindowsのようなOSのGUI機能を利用するアプリは基本的に事象駆動型（イベントドリブン型）で
組むことができるわけだが、なぜ事象駆動型で組めるのか、いや、なぜ事象駆動型の部分しか
組まなくて済むのか理解できてるのかね？
それは下層にWindowsのようなOSがあり、そのGUIを利用するためのAPIがあるからだろうに
意味わかるかね。わからんだろうね
で、君はビデオゲームを周期駆動型ではなく事象駆動型で組んでるのかね。それはどんな
ジャンルのゲームなのかね。紙芝居ADVとか戦略SLGではないのかね？
>>429 もう言ってることがいよいよ神がかってきてるんだが。
俺のエスパー能力にも限界がある。
とりあえずだな、
事象駆動でも、周期的にイベントを発生させれば周期駆動になる。
周期駆動は事象駆動に含まれているということだ。
分けて考える必要なし。
ゲームと普通のGUIアプリが別物だと考えている時点で頭おかしいというか。
あほ：うわぁ、Windowsすげぇ、イベント部だけ書けば良いなんて、MS超優しいね。
433 ：
名無しさん＠そうだ選挙に行こう ：2009/08/30(日) 15:50:05 ID:RQNrxHmb
>>430 超能力能力なんて求めていない
君はそういう突飛な能力を持ってるらしいが俺は持ってない。うらやましいね
> 事象駆動でも、周期的にイベントを発生させれば周期駆動になる。
> 周期駆動は事象駆動に含まれているということだ。
> 分けて考える必要なし。
視野の狭い子だな
周期駆動（時間駆動）のプログラムが使うインターバルタイマーの周期的なトリガーをイベント（事象）のひとつとみなして
これを事象駆動の一種とする捉え方は可能ではなる。が、リアルタイムシステムや科学技術計算の分野では 明確に
対比され区別されている
リアルタイムシステムではtime-triggered-systemとevent-triggered-system
科学技術計算ではcontinuous-simulationとdiscrete-event-simulation
といった感じでね
補足すると、対比され区別されているからといって排他的という意味ではない
両者を組み合わせる形のシステムはちゃんと存在する
ゲームでは時間駆動型の基本システムの上にイベント駆動のシステムを
乗せているビデオゲームだ。画面更新はあくまでも時間駆動。ゲームの
シミュレーション部などが事象駆動。といったハイブリッド型の実装になってる
完全に一体になってるケースもないことはないが普通は層が分かれてる
434 ：
名無しさん＠そうだ選挙に行こう ：2009/08/30(日) 15:53:12 ID:RQNrxHmb
×ゲームでは時間駆動型の基本システムの上にイベント駆動のシステムを
分かりやすく現実世界に当てはめるとこうだ。
436 ：
名無しさん＠そうだ選挙に行こう ：2009/08/30(日) 15:55:00 ID:RQNrxHmb
ついに知能障害をおこしたか
>>433 それと、
「GUIアプリはイベントドリブンだから、周期駆動であるゲームとは違う」という、
お前の主張に何の関連性があるんだ。
お前も、
>周期駆動（時間駆動）のプログラムが使うインターバルタイマーの周期的なトリガーを
>イベント（事象）のひとつとみなして
>これを事象駆動の一種とする捉え方は可能ではなる。
といってるとおり、
>>430 の発言は突っ込むところでは無いだろ。
GUIアプリは水面下でOSが云々も意味不明だし。
イベントドリブンするためにはOSが必要ってわけじゃないし、
周期駆動だって、ループ部を固定するならOSもどきは必要だし。
そもそも、
439 ：
名無しさん＠そうだ選挙に行こう ：2009/08/30(日) 16:34:21 ID:RQNrxHmb
>>398 >ゲームは単体アプリだから、マルチタスクも糞も関係ないんだよね。
>OSのプロセス管理の真似事なんてする必要なし。
>ゲームはOSのプロセス管理とは違って、メインループ部を自由に触れるということ。
本当に視野の狭い子だな
WindowsのようなプリエンプティブなマルチタスクOSに慣れ親しんでいる子にとってタスクという
言葉から連想するものがプロセスしかないというのは同情の余地は在るけどな
「タスクシステム」ではなく「タスク」が必要ないとか言い出すような勇み足アンチは大抵おバカだな
そういやクルクルパーと散々小馬鹿にしてきたHSP君。彼の批判の矛先はあくまでも「タスクシステム(
>>2 )」
であって「タスク」ではなかったな。であるがゆえにタスクシステマーに対しては「タスク」という言葉を
擁護して「タスクシステム」を擁護したつもりになるなだとか、「アンチタスクというのは正確ではない。
俺はアンチタスクシステムだ。」とかキャンキャン吼えてたな。阿呆なりに筋は通っていたな
あと、イベントドリブンとOSの関連性もな。
>>439 どうでも良いから
>>438 、
>>440 の説明だけはしろよ。
お前が言い出したことだからな。
俺の主張は一貫してて、
『プリエンプションなしのタスクを周期駆動でぶんまわす』
はメインループ部を固定する制限から派生しているもので、
『駆動原理』(周期駆動云々)には関係ない。
イベント駆動でも、メインループ部を固定するなら、
『プリエンプションなしのタスクをイベント駆動でまわす』
はありえる。
>417
>419
あと、ゲームとその辺のGUIアプリとの違いの説明もな。>>ID:RQNrxHmb
445 ：
名無しさん＠そうだ選挙に行こう ：2009/08/30(日) 17:22:37 ID:RQNrxHmb
>>398 > 粒子の振る舞いを外部からプログラマブルに定義しないのなら、
> ベタ書きで十分だし、処理速度も一番速いし、実装も早い。
そのベタ書きとやらにも処理単位（処理ステップ、タスク）があるんだな
プリエンプションなしの処理ステップを何らかの時間刻みで繰り返し実行してる
プリエンプションなしのタスクを何らかの時間刻みでぶんまわしてるんだよ
コンピュータ関連の分野ではタスクというのはプロセスに限らず色んなものの
処理単位の意味で使われる。OpenMPやTBBの中にもタスクという言葉が登場する。
タスクシステムに限らず、ゲームプログラムには必ず処理ステップ（タスク）と呼べる
ものが必ずといっていいほど存在する。何らかの時間刻みで数値積分とかしてる
わけだからな
組み込みシステムの分野では非プリエンプティブなタスクというのは沢山使われてきた
RTOSを使わないリアルタイムシステムの中でタスクといったら大抵これ。ただのサブルーチンだ
8bitプロセッサの組み込みシステムなら確実に半分以上、16bitプロセッサでも3割近くが
RTOSを使ってない。プリエンプションありならRTOS使う
『プリエンプションなしのタスクを周期駆動でぶんまわす』
こんなのゲームの中にあって当たり前の仕組み。
これがゲームに必要ないなんてありえないよね。流石に異論はないだろうな
446 ：
名無しさん＠そうだ選挙に行こう ：2009/08/30(日) 17:37:38 ID:RQNrxHmb
> ただのサブルーチンだ
>445
イベントドリブンの仕組みが非プリエンプティブなタスクによって実現されているからといって
> ただのサブルーチンだ
いや、的確な言い方だと思うよ。(お前の中ではな)
俺も多分お前はそういう意味で言ってるんだろうなとは思っていた。
ただ、普通の人はサブルーチンのことを関数と言う。
いいってことよ、俺のエスパー能力が足りなかっただけだ。
for(;;)
{
sub1();←タスク
sub2();←タスク
sub3();←タスク
wait();
}
でも、こうなってくると、タスクシステムと、
『プリエンプションなしのタスクを周期駆動でぶんまわす』
の関係性が希薄になってくるわけだが。
>タスクシステムに限らず、ゲームプログラムには必ず処理ステップ（タスク）と呼べる
>ものが必ずといっていいほど存在する。
一般アプリでも存在するわけだが。
ゲームと一般アプリとの違いの説明よろしく。
あと、イベントドリブンとOSの関連性の説明もよろしく。(
>>440 をふまえたうえでな)
というか、処理をステップに分けて実行する事象を
451 ：
名無しさん＠そうだ選挙に行こう ：2009/08/30(日) 18:48:03 ID:RQNrxHmb
>>440 このコード断片は一体なんなのかね…。何のアプリの断片なのかね…
GUIアプリなのかね。なぜビジーウェイトしてる。シングルプロセスのOSで
動かしているのか。GUIのイベントは誰が突っ込むのかね
意味が分からない
452 ：
名無しさん＠そうだ選挙に行こう ：2009/08/30(日) 18:55:57 ID:RQNrxHmb
ハードウェアの全てを独占的に使う権利を有しているのかね。
>>450 の話は、
俺が前言った、ノイマン型コンピュータの実行はFIFOだから、
処理の遅延目的(ループ部固定にしたときに処理キュー使うのも処理を遅延させて緩和するため)
以外で、処理をキューに突っ込む必要は無いってのとも被る。
往々にして、コンピュータの仕組みを知っているのかと。
>>451 、
>>452 何わけのわからないことを。
>>440 は単にイベント駆動プログラムのサンプルだ。何かのプログラムというわけではない。
OSに頼らなくてもイベント駆動のプログラムは書けると証明したまで。
イベント駆動だからといって、waitしなければならないという理屈も無いし、
協調動作しなければならないという理屈も無い。
>>440 は無限ループしているわけではなく、一連の処理をすばやく終え、
どこかの段階でreturnしていると思えばよい。
たとえば、event3の処理の中でreturnしているのかもしれない。(どうでも良いこと)
>>440 のイベント駆動に何の意味があるのかと思う人もいるかもしれない。
説明しておくと、イベント投げてから実行されるまでの処理の遅延が目的。
どうでも良いから、お前はさっさとイベント駆動とOSの関連性を示せ。
イベント駆動＝協調動作っていう固定観念が邪魔しているのかな。
とりあえずタスクシステムと「～駆動」の関連を３行ほどにまとめてから話してくれないか？
457 ：
名前は開発中のものです。 ：2009/08/30(日) 20:42:34 ID:RQNrxHmb
>>454 私が興味を示している君の主張
--------------------------------------------------------------------------
１．『プリエンプションなしのタスクを周期駆動でぶんまわす』
こんなものはゲームに必要ない。
２．ところでゲームは単体アプリだからマルチタスクも糞も関係ない。OSのプロセス管理の
真似事なんてする必要なし。ゲームはOSのプロセス管理とは違ってメインループ部を
自由に触れるからである。
３．ところでビデオゲームの駆動原理を簡潔に書けと言われればこれはステートマシンである。
これはつまりゲームが【その辺のGUIアプリ】となんら変わり無いということである。
ごく普通のアプリです。ステートマシンです。ゲームと【普通のGUIアプリ】は別物だと
考えるのは頭がおかしい。それはゲームは特別だという思い上がりである
---------------------------------------------------------------------------
君の言う【その辺のGUIアプリ】【普通のGUIアプリ】とは一体何なのかね。
『プリエンプションなしのタスクを周期駆動でぶんまわす』必要のない
【その辺のGUIアプリ】【普通のGUIアプリ】といったら、Windowsのような
OSのGUI機能を利用するアプリのことと解釈してしまうが違うらしい
そして
>>440 である。訳が分からんな
プリオンの話禁止
肉骨粉？食べてませんよ。
えーっと、ここWindows前提だよね？
>>420 色々端折ってるけど、そこは想像して補って欲しい。
public class Movee {public void update() {if (mover != null) mover.move(this);}}
public interface Mover {public void move(Movee movee);}
public class LinearMover implements Mover {
public void move(Movee movee) {
movee.x += movee.vx * movee.ax;
movee.y += movee.vy * movee.ay;
}
}
public class KeyMover implements Mover {
public KeyMover(KeyState keystate, Rectangle validrect) {
this.keystate = keystate;
this.validrect = validrect;
}
public void move(Movee movee) {
if (keystate.up()) movee.vy = -1;
else if (keystate.down()) movee.vy = 1;
else movee.vy = 0;
if (keystate.left()) movee.vx = -1;
else if (keystate.right()) movee.vx = 1;
else movee.vx = 0;
if (keystate.z()) {
movee.ax = movee.ay = 1;
} else {
movee.ax = movee.ay = 3;
}
movee.x += movee.vx * movee.ax;
movee.y += movee.vy * movee.ay;
movee.into(validrect);
}
}
>>460 > えーっと、ここWindows前提だよね？
その前提はどこから出てきたんだ？
Windows用ゲームって・・・
開発機としてはともかく、Windows向けゲームなんて日本で作られてるゲームの１％にも満たないだろ・・・
まだ携帯向けの方が多い。
Windows限定、なんてレアケースあえて扱う意味あるのか？
>>Windows限定、なんてレアケースあえて扱う意味あるのか？
464 ：
選挙見てた ：2009/08/30(日) 23:42:00 ID:FM9g8kNh
>君の言う【その辺のGUIアプリ】【普通のGUIアプリ】とは一体何なのかね。
ワードやエクセルで良いよ。
>WindowsのようなOSのGUI機能を利用するアプリのことと解釈してしまうが違うらしい
あってるよ。
>そして
>>440 である。訳が分からんな
>>440 は最も基本的なイベント駆動プログラム。
お前がイベント駆動はOSがどうとかこうとか言ってたから、
イベント駆動とOSは関係ないと説明したまで。
お前はGUIアプリとゲームの違いは、駆動原理がどうとか言ってたけど、それは関係ない。
駆動原理の観点からは両者とも違いが無い。
周期駆動は周期的にイベントの発生するイベント駆動。
GUIアプリだろうがゲームだろうが、パラパラ降ってきた入力に基づいて、状態を更新し、結果を出力するだけ。
ただ、ゲームの場合は更新を促す入力も一定周期で振ってくる。そんだけ。
GUIアプリでもタイマー使うことはあるし、変わりは無い。
個人や同人ならwindows限定がレアなケースっていう感じではないと思うけど。
Windowsも含める、ならわかるが
467 ：
名前は開発中のものです。 ：2009/08/31(月) 00:18:33 ID:d6qZudqV
私が興味を示している君の主張
468 ：
名前は開発中のものです。 ：2009/08/31(月) 00:28:25 ID:d6qZudqV
> 事象駆動でも、周期的にイベントを発生させれば周期駆動になる。
>>466 > アマチュアに限定しないといけない理由は何だろう？
そりゃコンシューマでもアーケードでも携帯でもトイゲームでも全ての環境で
タスクシステムは使い物になりません、なんて証明できんからな。
このままじゃアンチ惨敗なので個人、同人がWindows環境で作るゲームについてのみ
タスクシステムは不要。ぐらいまで戦線を狭めてきたんだろ。
470 ：
名前は開発中のものです。 ：2009/08/31(月) 07:32:25 ID:QF/DBd4l
頭おかしいのがいるな(笑)
>>469 お前のようにロクに意見も言えずに、
対立を煽って面白がってる奴はこのスレにとって不要。
アンチだの惨敗だのに拘って何が得られるのか。
タスクシステム使っても作れるし
>>468 >現実にはこのような対比・区別が存在するわけだ
区別されてたからって、組み方が変わるわけじゃないだろ。
お前も、
>周期駆動（時間駆動）のプログラムが使うインターバルタイマーの
>周期的なトリガーをイベント（事象）のひとつとみなして
>これを事象駆動の一種とする捉え方は可能ではなる。
と書いているじゃないか。
大概のWindowsアプリのメインループ部は、
for(; 0<GetMessage(); ){ Dispatch～～ }
となってるが、単にこれを、
for(; ; ){ if( PeekMessage() ) for(; PeekMessage();){ Dispatch～～ } wait(); }
と書き換えれば、そのアプリは元の挙動のまま、そのまま周期駆動になる。
入力→状態更新→出力という一連の流れの中で、
イベント駆動/周期駆動は入力の拾い方の違いを示しているだけで、
プログラムのメイン部(状態更新部)の構造にはタッチして無い。
このスレに居るやつは皆、状態更新の方法を(拙い頭で)あれこれ議論しているわけで、
入力部に拘ってるのはお前だけ。お前だけスレ違いで、話のピントがずれてる。
要領が悪いということ。
拙い頭では余計だコラｗ
なんというか
マインスイーパーもタスクシステム使ってるの？
ウインドウズがタスクシステムつかってるから余裕で使ってる
釣りネタだろうけどOSの話とは違うんじゃないの
Windows限定、アマチュア限定になってこのスレ終わったな・・・
タスクシステムって組み込み系のテクニックですよね
アマチュア個人だと作業分担もなければ
わざわざ生存管理をタスクシステムにとられちゃうのが納得いかない
>>482 > それとこっちでnewしたもの勝手にdeleteするな
GCつきの言語を使ったことのない厨房乙
GCは参照のあるオブジェクトを勝手にdeleteしないのだが。
>>484 それを言えば、典型的なタスクシステムにしても、「もう消滅していいよ」ということを意味する delete markerが
ついているからオブジェクトを削除するのであって、勝手にdeleteしているわけではない。
>>485 その実装はマーカーに従って明示的にdeleteしているわけで、
>>482 の言う「勝手にdelete」とは違うんじゃないの？
たとえば、親が死んだら子も死ぬとかが、勝手にdeleteの代表だろう。
>>486 >
>>482 の言う「勝手にdelete」とは違うんじゃないの？
それなら、特に異論はないのだが、しかし、
> たとえば、親が死んだら子も死ぬとかが、勝手にdeleteの代表だろう。
そのタスクシステム、一体どんな実装になってるの？そんな実装のタスクシステムあるか？
一体、何にしたがってオブジェクトを削除してるんだ？
それはお前の気にするところではない。
>>488 > タスクシステムは指定したオブジェクト以外も削除することがある。(予測不能な無効な参照を生む)
だからそんな実装になってるタスクシステム、何の意味があるのか？
そんな現実的にありえないようなタスクシステムを持ち出してこられてもなぁ・・
>>489 いや、大半のタスクシステムが削除しちゃうと思うよ
だって参照カウントみて残ってたら自分を削除できないんだよ
これをどうやって解決する？
参照カウントによって削除させる設計は全て愚か。
>>491 じゃあ、残しておけば
そっちのが多分スタンダードじゃない？
でも最寄のタスクシステム的にどうよ？
参照カウント残ってたら解決できんの？
>>490 > いや、大半のタスクシステムが削除しちゃうと思うよ
> だって参照カウントみて残ってたら自分を削除できないんだよ
どこに参照カウンタ使ってるタスクシステムがあるんだよ。
普通、タスクシステムは参照カウンタなんかみないよ。循環参照してたらどうするんだ？boost::weak_ptrでも使うのか？
ともかく、ふつうにdelete markerがついてるやつだけ削除すればいいじゃん。
ID:SHBZF47D の主張
>>100 ことID:yvNElBEe
vs
アンチタスカーID:43RWv3KZ
「入力部に拘ってるのは
>>100 ことID:yvNElBEeだけ。お前だけスレ違いで、話のピントがずれてる。
要領が悪いということ。」
>>494 ID:SHBZF47Dと私とでは参照カウンタを使わないという点では、一致してるんだ。
ID:SHBZF47Dが勝手に私を参照カウンタ利用者と勘違いして反論しているのがおかしいんだ。
また同時に、ID:SHBZF47Dは、参照カウンタを使わなければ、
> それとこっちでnewしたもの勝手にdeleteするな
のようになると思っているのがおかしいんだ。
delete markerをmarkしたのは、タスクシステムの利用者であって、タスクシステム側ではない。
だから、タスクシステムが勝手にdeleteしたのではなく、タスクシステム利用者の希望によって
タスクシステム側がdeleteしているのに過ぎない。
>>496 だれもdeleteしてくれなんて頼んでないし
なんでdeleteしようとするのかわからない
余計なことするなと本気で思う
普通にクラスにメンバでもってnewしてない奴を認めない理由はなんで？
ゲーム中ずっといるから常駐してる奴をタスクシステムに登録するとおかしくなるよね？
>>497 > なんでdeleteしようとするのかわからない
> 余計なことするなと本気で思う
誰かが生存を管理する必要がある。生成をしたオブジェクトが生存を管理するのは
生成したオブジェクトのほうがlifetimeが長いとは限らないから、そういう設計にすることは出来ない。
だから、タスクシステムを使おうと使うまいと、どこかに生存を管理するmanagerは必須だよ。
> 普通にクラスにメンバでもってnewしてない奴を認めない理由はなんで？
別に持ってもいいよ。lifetimeがそれをメンバに持つオブジェクトと同じで、
あとタスクシステム側から何の恩恵も受けないつもりならね。
あーだんだんID:e3abVnaUの糞実装がおぼろげに見えてきた。
>>499 >生存を管理するmanagerを用意するんじゃなくて、参照を管理するmanagerを用意しなさい。
それでいいよな
それで駄目な理由がわからない
>>500 別にアマチュア限定のスレだからいいんじゃない？
個人、同人限定なんだからへんてこ実装でも誰がこまるわけでもないし・・・
>>501 自分が説明できない理由をそうやって誤魔化そうとするなら
ハナから技術系の板にくるなよお前
タスク程度の何が技術なんだか・・・
>>504 仕様も使用条件もソースも無いのに具体的になんて無意味って気づけよ。
個人個人の脳内前提条件に当てはめれば具体的、のつもりなんだろうけど
他人から見ればただの妄想。
しかもWindowsしか知らないアマチュア限定ならなおさらだ。
全ての条件でたった一つの実装に収束するほと汎用的な話でもなし。
タスクシステムって実装？設計？概要？
Windowsでしかゲーム売れない件
>>507 Windowsでしか”同人”ゲーム売れない件、でしょｗｗ
タスカー側がそんなに使われてるって主張するなら
UNIXでな！
>>510 動かないのは駄目ではないんだろうけどやめてほしいなぁ
>>509 > タスカー側がそんなに使われてるって主張するなら
どこにそんな主張があるのかなぁ？ｗｗｗ
アマチュア同人ならどんな実装でもいいんじゃね、としか言っていないが
>>512 なんだ使われてないのかｗ
やっぱりやねうらおが１人で自演してんだな
悲しい奴だ
>>513 そうそう、タスクシステムなんて君には一生関わりの無い話。
これで安心して寝れるねｗｗｗ
アンチタスクは何故こんなゴミ虫レベルの奴が多いのか
タスクシステム養護派は具体例に欠け
結局のところ 「ググレカス」 に終わり
>>517 アンチはググルこともできない今の時代に適応できないゆとりだ、
と言ってるのねｗｗｗ
だいたいタスクシステム側が納得いくタスクシステムをソース付きで出してくれないと
タスクシステムの不思議
タスクシステマーが本当にしたかったことは、タスクシステムでは無かったということ。
訂正
>>524 うん、俺もそう思うよ。
カプセル化、分割統治、っていう構造をブッ壊して(・∀・)ﾆﾔﾆﾔしてる。
で、こまったことが出てきたらそこを必死で繕ってるような二度手間のイメージ。
>>524 それだけとも違うと思うなぁ
だって仮に３Ｄで座標更新しようと思ったら
ワールドからツリーで追っていかないと親子関係表現できないじゃん
型だけじゃないっしょ
ＳＱＬみたいに自分の条件でオブジェクトを検索してくる「何か？」って感じで
実装するシステムによってどうとでも化ける気がするなぁ
もうホント条件を使う側が自由にできないとどうしようもねぇと思う
>>527 親子関係は親子関係で別に持てばよいだろ。
タスクシステムでも、処理順がコントロールできるだけで、親子関係までは見てくれない。
もし自分のタスクシステムは面倒見てくれるっていうんなら、それはやりすぎ。
親子関係を見て列挙順をコントロールする仕組みは別に用意した方が良い。
たとえば、set_parent()メソッド内で、ワールドまでの階層をしらべて列挙順を変更すればよい。
ただ、型を飛び越えて列挙順が制御できる必要はある。
だから、型ごとだけではなく、列挙順ごとにもリストを持ってるわけで。
//orderly内はeach_type間を飛び越えて列挙順序を守ってね
//列挙順0の親→列挙順0の子→列挙順1の親→列挙順1の子・・・・の順で処理される
orderly( updating_order )
{
each_type( oya, updating_order ){ /*親更新コード*/ }
each_type( ko, updating_order ){ /*子更新コード*/ }
}
マクロだと分かりにくいので。
>>528 なにがやりすぎなのか意味わからないけど
その型がとってこれるっていう局所仕様になんのメリットがあるのかわからない
ようは必要なのはＤＢとＳＱＬで条件指定したらなんでもかんでもとってこれないと駄目なんだろ？
それじゃリアルタイムで動かない
>>531 マジでＤＢ使ってＳＱＬ打ってたら間に合わないけど
遠かれど似たようなものだったら作れるだろ？
俺もタスクシステム使って組まされたときは毎回毎回
必要なオブジェクトの検索を処理の冒頭でしたもんだぜ
これがウザクてな
インスタンス消えてるときもあるしよーｗ
あるオブジェクトの子がもつすべての当たりを取得
っていうアリガチの処理だってだいたいコードが予想できるだろｗ
ステータスであるオブジェクトを特定して、
親子ツリーで子の当たりを総なめするのなｗ
あー、面倒臭ぇ、面倒くせぇ
なんでこんなことやる必要あるんだ？
シーンから引数で素直に渡せばいいだろ常考
なんの恩恵もねーよこのシステムｗ
型で列挙するのにはそれなりに意味はある。
>>533 そんなの下ごしらえの仕方だろ？
どーにでもなる話の議論は無しの方向で
いや、型以外のキーで検索したら、どう頑張ってもダウンキャストが必要。
536 ：
名前は開発中のものです。 ：2009/09/06(日) 13:31:31 ID:TTUz744b
>>482 > わざわざ生存管理をタスクシステムにとられちゃうのが納得いかない
これは
『ボクチンのタスクシステムはねー、手広く且つ決め細やかな謎サービスを
提供してくれるんだー。ほんとお節介な奴で困っちゃうよー。グヘヘ』
という惚気話だろう
生存管理ってなんだ。メモリアロケータを内包しちゃってるのか？ゴミだろ
>>536 ん？
君の立ち位置がよくわからない
内部でdeleteしちゃってるようなのは駄目って言ってるの？
>>533 グヘヘ、っていうのはそもそもの肝かもしれない。
グヘヘ、と思って有り難がってるからこそ、
そんなやつらがムリヤリ頑張ってるからこそ、
こんな野暮ったい仕組みが残ってしまうのかもね。
539 ：
538 ：2009/09/06(日) 13:47:12 ID:RF8wH9Rt
540 ：
名前は開発中のものです。 ：2009/09/06(日) 13:52:43 ID:TTUz744b
タスクシステムと呼ばれるものの本来の役割、本旨は何かを探れば
本来の役割って何ですか？
>>541 キミらの本音を聞きたいね。
俺は
> 無駄な仕事を作って自分の居場所を確保すること？
だと思ってる。ただし、これはどんな職場にも見られる現象であり、
タスクシステムの人々を格別非難しようというもんではない。
本来の役割、本旨とやらに言及しない限りは。
543 ：
名前は開発中のものです。 ：2009/09/06(日) 14:02:38 ID:TTUz744b
関連性の希薄な例え話が大好きで、おつむの出来がとても残念な
544 ：
名前は開発中のものです。 ：2009/09/06(日) 14:06:11 ID:TTUz744b
実行待ちキューに登録されたタスクを順次実行する。これが本旨。
545 ：
名前は開発中のものです。 ：2009/09/06(日) 14:08:39 ID:TTUz744b
ゲームルール上のOBJの生死はタスクシステムの関知するお話ではない
546 ：
名前は開発中のものです。 ：2009/09/06(日) 14:13:12 ID:TTUz744b
あるいは
>>500-501 の主張。参照を管理するmanagerを用意しなさいとかいうもの。
具体的に何をどうマネージメントしてくれるのかは彼らの脳内の話であるが
まぁ例えばOBJの参照関係グラフのようなものがあるとする。こういうものは
タスクシステムとは全く関係ない
>>544-545 へー。それなら話はわからんでもない、というか少し興味は持てる。
そういう、小さい部分だけの話なら、胡散臭さも入る余地無し。
タスクという単位でクライアントをパラメータ化し、順に処理されるだけのものだと？
タスクシステムは、GoFで言うとコマンドパターンが近い？ そういう例えは不要？
>ID:TTUz744b
タスクシステムは要らないといいたいんだよ。
何がややこしいって、
551 ：
名前は開発中のものです。 ：2009/09/06(日) 14:39:17 ID:TTUz744b
デジタルコンピュータの登場当初から存在していた
for(;;)
553 ：
名前は開発中のものです。 ：2009/09/06(日) 14:53:59 ID:TTUz744b
＞このスレの論点は、キックされた後の更新処理。
俺がきれいな方程式を立ててやろう。
>>553 あたりまえだろ
ここはアマチュア限定のスレなんだから。
童貞の妄想するセックステクニックの話に
リア充が突っ込みするような真似はしないことだ。
ちなみに、タスクシステムと周期駆動は何の関係も無い。
今のスペックならSQLでもいけそうだな
だからね、俺がね、何が言いたいかって言うとね、
560 ：
名前は開発中のものです。 ：2009/09/06(日) 16:11:04 ID:TTUz744b
一週間たっても全く成長がないのだな
>>557 はさすがに誤爆だと信じたいｗ
トンチンカンにもほどがあるぞｗ
>>560 はたとえ話や「ぐぐれ」やAAでお茶を濁すので、モヤモヤする。
なぜもっと素直にID:bJbP9YDC氏と話し合えないのか。
stateパターンでググレ
ああ、くやしいから人格非難に走るのか
WaitForSingleObject関数すら知らないのか
やべ ついｗ
>>564 「アンチの想像を絶するアマチュアの妄想テクニックに感じちゃう！くやしい！…ﾋﾞｸﾝ…ﾋﾞｸﾝｯ」ｗｗｗ
ヘイヘイ
>>565 WaitForSingleObjectはイベント駆動と周期駆動の両方に使えるよね。
だからどうかしたの？どっちにしろ、待機中のことを議論しても意味無いわけで。
プログラムがどういう風に待機するかは興味の範疇に無いな。
他の人もそうだと思うけど。
570 ：
名前は開発中のものです。 ：2009/09/06(日) 17:00:39 ID:TTUz744b
>>562 だって…
「おんなのこのからだはそんなもんじゃない。
ぼくが望んでいたのはそんなんじゃない！
ぱんつの中はもっといい匂いがするはず！」
って言われても困るっていうか…
Windows用ゲームの作り方についてはあまり詳しくない俺でも
>>473 を読んだ瞬間に、この子はWindows用の2DSTGはおろか
紙芝居エロゲすら満足に作れない妄想プログラマ君なのだと
確信したのね
俺はお前が周期駆動云々言い出したのみて、
>>569 おめーいっぺん裁判でもいいから訴えられてみろ
そして法廷で「そんなこと知りません」って言って
お願い
573 ：
名前は開発中のものです。 ：2009/09/06(日) 17:18:40 ID:TTUz744b
この子きらい
574 ：
名前は開発中のものです。 ：2009/09/06(日) 17:19:43 ID:TTUz744b
／:::::::::::::::::::＼
きもちいいお(´；ω；｀)
タスクシステム最高
タスクシステム使わないって協調性に欠けるおこちゃまだよね
童貞の語るベットマナー云々なんてただのお笑いだっての。
そうやって悪の道へ人を誘うな。
まずゲームを二本、自力で最後まで完成させてみな。
583 ：
オガワン ：2009/09/06(日) 22:23:49 ID:wuQ6DQVW
＞＞２の見ても何にも分からない。
全然分からない。意味が分からない。理解できない。
だから、タスクシステムっておかしいよ。意味分からないもん。
それでゲームプログラムの王道みたいに言われると虫唾が走るね。
狂ってるよ。OOPも分からない。クラスも分からない。ポインタも分からない。
構造体もめんどくさい。もーやだ、めんどくさいのやだ、プログラムパラダイムを
考えなきゃいけないのやだ。だから、俺は俺のプログラム手法でやるよ。
俺のプログラム。オガワンシステムだ！
狂ってるというのは俺から見たらの話ね、わざわざ小難しいことしなくても
ゲーム作れるもんね俺は俺のオガワンシステムで、そういう意味で狂ってみえる
ということ。
http://loda.jp/rock8/?id=149 キチガイが広めて
>>583 理解力がそんなに乏しくて、社会でやっていけるの？それともニート？
まぁ正常位だろうが騎乗位だろうが側位だろうがヤルことはできる。
まぁ確かに、自力でゲーム１本作り上げたこと無い人はタスクシステムうんぬん以前の話だね。
>>586 俺アンチだけどずっと前のスレで
・タスクシステムがアプリケーションの全体概念および統一実装方法ならばダメ
・タスクシステムがアプリケーションの一部を実装するための方法の一つなら許容
って話も出てた。最近のスレのことは俺が読んでないので知らない。
>使い方の一つとして知ってて損になることは無い。
これは大抵のアンチも許容すると思う。くどいようだけど純粋に実装方法の一つとしてなら。
あと「思想ではなく実装方法の一つならデザパタで定義されてるの使えばいいじゃん。なぜローカル用語？」
というのもアンチから出てた気がする。
つまり
１、統一思想という捉え方でタスクシステムを持ち出すとアンチが出ます。俺とか。
２、実装方法として捉えつつも結局アプリ全体で統一してタスクシステム使っちゃってても出ます。
３、実装方法として捉えて実際アプリの一部分について選択の下にタスクシステム使ってるなら出たり出なかったりします。
出た場合は入門以前の人か、「一部分の実装方法なのにシステム？。実装方法ならデザパタで言えよ」とか
その後「人によってタスクシステムの定義が曖昧でデザパタで言い換えるとなかなか合意取れんね」
ってとこまで話が進んだが人格批判厨が発生して数スレに渡って粘着したのでうやむやになってた希ガス。
入門以前の人しか居ないわけでは無い、と思う。
ゲーム作れないとか作ったことがないとか、C++わからないとか、boost知らないとか、
つまりタスクシステムと言うのは上級者向けの実装方法ってこと？
いや、裸の王様向けってことだよ。
>>589 まともな議論を望んでる人がどれだけいるか。
まともな議論をしたくない人に対して
まともな議論をしようと試みるのはお互いに不幸だ。
>>589 お、クールな人が来てるねぇ。
技術の話ってのは、やっていくノウハウ、
食っていくノウハウに直結するんで、
隠したいと思う奴がいても不思議じゃないし、
また、隠すがゆえに野暮ったいシステムは、
いつまでたっても改善されなかった、
ということだとしても不思議じゃない。
おっとミスった。クールな人とは
>>592 のことな。
未だにタスクシステムを採用するメリットが見えてこない
>>593 相手は情報を隠したがっているという前提では
ほとんど全ての主張は信用できないことになる。
アンチは優れたものに他人が興味を持たないようにするため
信者は役立たずなものに他人が興味を持つようにするため
それぞれ行動しているのかもしれない。
597 ：
名前は開発中のものです。 ：2009/09/07(月) 23:34:57 ID:qwKYGu22
別に情報を隠したがってるわけじゃないんだけど
598 ：
名前は開発中のものです。 ：2009/09/07(月) 23:51:17 ID:qwKYGu22
例えばtime driven cyclic executive とかでググれ。利点も欠点も詳細に解説されてる
600 ：
名前は開発中のものです。 ：2009/09/08(火) 00:29:20 ID:pmhwd1Ha
>599
あ、イラネっていうか作るならゲムデブWIKIのほうにしてくれ。かな？
ごめん知らんかっただけだ。移行する
よくわからんが公式のウィキがあるなら使えばいいんじゃない？
>603
607 ：
名前は開発中のものです。 ：2009/09/08(火) 00:50:18 ID:pmhwd1Ha
うむ。俺がゴミクズ野郎だったようだな。悪かった
>>603 そして乙カレ（・∀・）ﾁｬｰﾝ
gamedev wiki 見てきたけど、真面目そうなサイトだったから、汚すのいやだな。
609 ：
名前は開発中のものです。 ：2009/09/08(火) 01:03:51 ID:pmhwd1Ha
機能A：登録された処理を順次実行する
過去ログをそのアップローダにあげておくだけでいいんじゃない？
タスクシステムライブラリで十分
614 ：
名前は開発中のものです。 ：2009/09/08(火) 01:46:11 ID:pmhwd1Ha
>>610 >>613 なんか厨くさいな。しかもかなり特徴的なやつだ
どっかで嗅いだことのある臭いだ
「確定させたい」っていつも繰り返してた確定乞食
自動並列化を意識したタスクシステムを作ったよ君＝タスクシステムはDBだ君
タスクシステムはファイルシステムだ君
ゲームが作れないID:bJbP9YDC
>>588 その辺の経緯は知らないが俺は定義が無いぞ厨かな。
合意が無いなら無いでせめて勝手定義を示してから
本題を語れば技術的で有意義な議論ができるかもしれないのに
論拠も論理展開も飛ばして結論だけ出してくる人がほとんどだ。
詭弁や人格攻撃を仕込んだ釣り針で馬鹿にする相手を
探していると思しき人がいるのは2chだからしかたない。
俺もそんな人のことを悪く言える立場じゃないし。
でも真面目な話ができなくてもどかしい思いをしてる人はもったいない。
>>616 > でも真面目な話ができなくてもどかしい思いをしてる人はもったいない。
そんな人は過去のスレ見て、とっくに結論出してるんじゃないの。
情報なら十分にあると思うけど。
なんで、英語できるのに日本にくるの？
>>617 過去スレから見出せる範囲の結論で満足ならいい。
>>618 英語の話はよく荒れる。わかってて書いたんだろうけど。
>>593 > 相手は情報を隠したがっているという前提では
隠したいと思う奴がいても不思議じゃない、と言ったまでのこと。
> ほとんど全ての主張は信用できないことになる。
なぜ？ｗ
> アンチは優れたものに他人が興味を持たないようにするため
> 信者は役立たずなものに他人が興味を持つようにするため
だろうがなんだろうが、隠しさえしなければ、
発言さえしていれば、あとは信頼に足るかどうかはいつも読み手の判断。
発言者の背景ではなくて、あくまでここは内容ではかるべき。
ところで、pukiwikiに2chの過去ログをhtml形式で貼り付けたいんだけど、
ID:pazi8cW7
そりゃおめー、アクセス状況の把握にきまってんだろ。
つかあぷろだもあんのかよ
だから、ゲブデブWikiがpukiwikiなんだよ。
628 ：
名前は開発中のものです。 ：2009/09/08(火) 23:07:50 ID:pmhwd1Ha
>>627 サクっとうｐろだにあげとけって。それで十分だろ
まぁなんだ。くだらねーことグダグダ相談して話題逸らしてねーで
>>598 でググってお勉強した成果を見せたまえよ
>620
過去スレ見たが、アンチのほうは、圧倒的に初心者が多いね。
>>630 お前みたいなレスするクズをどうやって叩きだすのかが重要だなｗ
>>631 お前みたいなゲームすら作れない自称プログラマを
このスレから締め出すのが先決だと思うよ。
実に綺麗な「売り言葉に買い言葉」の例ですね
>>2 のリンク先の説明でゲーム作る目的でのタスクシステムの説明としては十分な気がするけど・・・
そんな分類しないといけないほどタスクシステムってたいしたものか？
この程度のものがチンプンカンプンでもっと手取り足取り教えてくれないとわからない！ってのは
自分の頭で考える、とかわからないことは試してみる、とかプログラマとしての素質というか
もっと根本的なところが問題な気がする。
そこまでレベル下げて親切丁寧に説明したとして、ゲームのプログラムしてればタスクシステム
なんかよりもっと難しいこと自力で解かなきゃいけないケースはいくらでもあるんだから・・・
まぁ、ゲーム作る目的じゃなくてあくまで議論のためのだけの分類、って感じなんだろうけど。
↑こういう奴に限って、わかったような気になって満足してるだけの奴。
なんか釣り糸同士が絡まってる…
そんなに煽られたら感じちゃう・・・ﾋﾞｸｯﾋﾞｸｯ
あえて！
640 ：
名前は開発中のものです。 ：2009/09/09(水) 20:54:52 ID:P2GFnk3d
相変わらず
ゲーム以外では使われないってことは、
642 ：
名前は開発中のものです。 ：2009/09/10(木) 22:42:40 ID:LMnNWMto
やーい裸の王様だーとはしゃいでいた狼少年は狼に食われて死んだか？
>>598 のキーワードでぐぐった感想を聞かせてくれや
>>642 突然何を言い出すのか意味不明
何がいいたいのかきちんと説明しろ
相手しなくて良いよ。
せめてタスクシステムの話しろよなｗ
>>642 アンチをこれ以上追い込むのはやめてください。可哀相でしょ
でも、タスクシステム総合スレ創設当初の勢いはもう無いでしょ。
>>648 よく探せよ
まさか、君、見えない・・・とか言わないよね？ｗ
アンチはバカだから1（キャラ）オブジェクト=1Taskという勘違いをしてそうだな
タスクシステムのメリットとしてメインルーチンを
アンチの攻撃対象っていつもCodeZineとかのヘッポコシステムばっかりなんだよね
メインルーチンがイテレータ風って(笑
654 ：
名前は開発中のものです。 ：2009/09/10(木) 23:57:48 ID:LMnNWMto
>>650 まぁそれはCマガとか読んで信者になった若い世代にも言えることだけどな
処理をリストに突っ込んで、優先順位でどうのこうのという時点で既に糞だということ。
656 ：
名前は開発中のものです。 ：2009/09/11(金) 00:09:10 ID:CngAv55G
おつむに糞がつまった残念な子は自分に必要ないものは糞という。
そう、そのとおり。だから、誰かさんの相手はして無い。
つ裸の王様
裸、ありのまま、すばらしいじゃないか。
>>652 > だからCodeZineの記事を教科書的に引用してブログ書いてた
> やねうらおはタスクシステマーに攻撃されてたよね
やねうらおは、CodeZineの記事を引用したなどという事実はないし、
やねうらおは、タスク派の攻撃されていたという事実もない。
よくわからないけど
>>598 が強烈な返り討ちにあったの？
最近このスレほとんど読んでないんでアレだけど
>>650 、
>>654 を読んで更に思ったこと
＞1（キャラ）オブジェクト=1Taskという勘違い
そうかなるほど。感動した。CodeZineがただの自機・敵・弾のごった煮連結リストだったから
過去スレでボッコボコにぶっ叩いてしまったわけだが（不本意だったが）、あの記事は
タスクシステマーから見ても「？」だったのか
単なるエンティティの連結リストをタスクシステムと有難がってる記事が「狂ってる」
ということなら納得だ。そして欠陥アロケータを癒着させたり不定期に発動する
メモリコンパクション機能付けたりとヘンテコ機能をベタベタ付着させて必死に脚色して
なんか強そうに見せてるものが全て後付けの贅肉分だったわけか。それならなら納得だ
巷に転がってるタスクシステムとやらの贅肉分をとっぱらったら
>>660 のリンク先の資料でいうところのtime-triggeredなcyclic executiveだとか
multi-ratedなものだとか割り込みが絡むものだか、そういうものになるというなら納得だ
なんだよ。結局タスクシステムなんて胡散臭い用語を駆使しなくてもちゃんと汎化して
説明できる代物だったんじゃないか。ほんとお前らタスクシステマーってやつは酷いよな
タスクシステムはバズワードとはよく言ったもんだな。俺はタスクシステムの元々の役割？
本旨？とやらには全く罪はないと思う。タスクシステムという怪しげーな単語と、それに
まとわり付く魑魅魍魎・趣味タスク信者が生成する脂肪肝腐れシステムが腐敗臭の原因だな
664 ：
名前は開発中のものです。 ：2009/09/11(金) 01:42:18 ID:CngAv55G
不定期に発動するメモリコンパクション機能って何のことだ？
javaのあいつが真っ先に浮かんだ
そもそもタスクシステムってメモリ確保と解放の概念ってないよな？
基本ある程度のメモリ最初に確保しといてそこから使ったりしてるでしょ
>>667 実装によってはそこらの処理をごっちゃにしてるやつもあったりするんで、
「タスクシステムって」と問われてもなんとも言えないのがタスクシステムクオリティ。
タスクシステムの特徴「単純な仕組みなのでゲームの仕様毎にカスタマイズできる、というかしなきゃ使えん」
なんで「一つの原理・一つの実装」と「応用・柔軟」を両立すればいいと考えないの？
>>671 おーすばらしい。
「一つの原理・一つの実装」で「応用・柔軟」のあるシステムを実現できるんだ。
そんなのがあればタスクシステムなんて使わずに全てのゲームはその実装一つで作れるね。
ささ、早くそれを見せてくれｗｗｗ
それとも今は存在しないけどいつかどこかの天才がきっと実現してくれる・・・はず。って？
まさしく理想主義者・原理主義者タイプ。
現状を受け入れて結果を出すことと、現状に満足してることの違いくらいはわからないとね。
>>671 満足してないから「一つの原理・一つの実装」を否定してるんだろ。
「一つの原理・一つの実装」批判はむしろタスクシステムに
向けられてるじゃん。たとえば >588
それなのに「一つの原理・一つの実装」を目指さないのは
タスクシステムに満足してるからなんて詭弁もいいとこだよ。
>>672 タスクシステムなんかに満足してるからわからないんだよ、で終了。
一つの原理ってのは、まさにタスクシステムの事だと思うがな。
タスクシステムって、リストになった処理をCPUが前から順番に実行していくものだけど、
信者「そもそもの成り立ちは～」
>>674 > 一つの原理ってのは、まさにタスクシステムの事だと思うがな。
タスクシステムは一つの実装では無いわな。
一つの実装を求めるかどうかがアンチかどうかの分かれ道。
「一つの実装」ってなによ。頭おかしいんじゃない？
こんな風に日本語ができない奴が
>>678 そうそう、頭おかしくなきゃありえないよねｗｗｗ
ついに敵味方の区別もつかなくなったか。
ややこしくなってきたので、まとめとく。
ID:D6Mri7diは
>>674 を読んで、
全てのタスクシステム同士のタスクのエントリー(update関数)の引数が固定になると解釈した。
そんな解釈の発想が沸いてくる時点で既に狂ってるだろうというのが
>>678 。
言うまでもなく、「エントリー(update関数)の引数が固定になる」の影響範囲は、
「全てのタスクシステム」ではなく「そのプログラム内」。
そのプログラム内で、全ての処理をタスクシステム上のタスクで統一されるのが嫌。
そのプログラム内で、メインループが固定されるのが嫌。
そのプログラム内で、タスクのエントリー(update関数)の引数が固定されるのが嫌。
そのプログラム内で、タスクの順序をプライオリティーで管理するのが嫌。
そのプログラム内で、それらの統一は、俺には制限にしか感じられない。
役に立たないので嫌
>>682 たまたま(曖昧とはいえ)タスクシステムは名前がついているから
それにとらわれて決められた制限に感じてるだけじゃね。
だいたい名前が悪いし、タスクシステムと呼ぶのを止めれば
もっと冷静で柔軟に見られるんじゃないの。
>>682 「タスクシステム嫌い」の一言で済む内容だな。
しかしその条件だと・・・
タスクシステム以外でも、商用含めゲーム用統合エンジンは全滅だなｗｗｗ
さぁ、凄腕プログラマが現れました
>>685 プロお断り。同人、アマチュア限定のスレで
商用ゲームエンジンの話なんてするなよ。
ゲームエンジンで成功している例って、何よ。
乱用すべきでない（ｷﾘｯ
>>688 そうそう。
アマチュアにはゲームエンジンなんて関係ないしな。
よ！アンチの鏡ｗｗｗ
鑑
>>690 自分で説明もできなくて他のＰＧにいつもでおんぶでだっこのクズＰＧならいくらでも現場にいるけどな
別にプロだから何ってのはないなｗ
クズはどんな会社にいってもクズ
そしてどんな会社にもきっとクズはいる（大手５社経験アリ、任天堂はない）
>>692 大手5社ねぇ
まぁ人の出入りは激しい業界だし、俺も転職経験あるけど
普通２～３社で役職つくなりプロデューサーになるなりして落ち着くもんだけどな。有能なら会社が手放さんし。
数年毎に職場変えるタイプも何人か見てきたけど
周りから次はこいつと一緒に仕事したくないって思われて、次のプロジェクトでお声がかからなくて
居場所が無くなって出てくタイプばかりだったな。
「俺はこんな有能なのに周りはクズばかり！俺の有能さを見抜けない上役もこんな会社もクズだ！」
って捨て台詞残して消えていった人を数人しってるよ。
さぁ、タスクシステムはもはや関係なくなってきて
>>695 あぁすまん。派遣か。
それならよくあることだ。
マ板でやれ
>>696 派遣じゃないな
若いときは同時に２つの会社の仕事を請けるとかやってたけど
もうそんなことはできねｗ
>>698 著名な漫画家とか作曲家なら個人相手に契約するけど、個人契約のプログラマは今まで見たこと無いな。
中小デベロッパはともかく、大手で法人の派遣会社を通さずに直接個人のプログラマに仕事振ったりなんて無いんでない？
うちでは区分的にプログラマは正社員・派遣・外注で自称フリーは派遣の区分にはいってるし。
まぁ派遣会社がそのプログラマにどう説明してるかは知らんけど。
んでも正直派遣プログラマは使いずらい。
見せられないコードの区分けとか社内データへのアクセス制限とか、余計な管理業務が出てくるし
マスター伸びると契約期間の問題でデバッグ途中で居なくなったり。
なんで正直ＵＩの量産箇所とかイベントのスクリプト部分とか、誰でも出来る表層部分以外は任せられない・・・
>>699 一応会社名で請け負ってるよ
実は１人なんです～ｗ的なｗ
外注といいつつね
ゲームＰＧの最終形態・・・だったけどいまはやめたほうがいいな
仕事もねーけどなによりギャラが糞
業務のがいい金だすよ（これは昔からだけど）
税金ぐらいか？フリーでいいところって
>>700 おめぇの食い扶持についてはそんぐらいにして
過去発言のアンカーでも張ってくれや
>>700 独り身で２０代ならそれもいいかもね
しかしプログラマ一人で外注ってほんと？
うちで外注出す場合は企画と仕様はこっちで後は絵も音も出来る中規模デベロッパに出す。
プログラム、絵、音、とか別々に外注に出してたら管理業務が煩雑になりすぎて
やってられんと思うけど・・・
まぁうちは一番小さい開発規模でもＤＳ・ＰＳＰクラスだから、もしかしたら携帯アプリとかやってる
ところはそんなやり方してるのかもしれんけど。
>>702 昔は３人いたしねｗ
いまも名目３人だけど１人はねーちゃんで
もう１人は友達（別の職ついてる）だしねｗ
>>703 知ってる範囲ではなんかリアリティが無いんだが。
ＰＳ１時代ならともかく、その人数で何ができるの？
うちの扱ってない携帯アプリかIPhoneとかそっち系か・・・？
>>704 ＰＧなんて無能が何人いたって邪魔にしかなりゃしないよ
それに昔からやってるから色々ストックがあるからね
仕様によっては工数１Ｈで納品・・・とかできるよ
そーゆーのわかってる相手だと頼みやすいでしょ？
今、新規でっていうのは難しいだろうなー
あくまで昔からの付き合いだね
>>705 ＰＧの人数じゃなくてデザイナとサウンドの話なんだけど。
工数１Ｈとか、ゲーム業界の外注、というかデベロッパとは何かずれてる。
プログラマだけで完結してるＩＴ業界の話みたい。
それに昔からの付き合いで大手５社って・・・
ほんとにゲーム会社の外注したことあるの？
>>706 そりゃね
ゲーム業界潤ってたときに色々仕事したからね
だいたい外注の人間の人数なんて把握してるのかね？
オタクの担当者にしてもｗ
昔はなんの仕事もしないで右から左に仕事を渡すだけでお金が入ってきてた時代もあるよ
いつの時代の話をしてるんだか・・・
まぁ、外注先の中規模デベロッパが子請け孫請けしてるとかまでは
>>708 >そんな仕事があったのはファミコン、スーファミ時代ぐらいまでだろうに。
それはないｗ
>>709 昔はこっちのが給料高いし会社も半ば善意で勧めてた部分はあるだろうね
正社員からフリーにされた人っていると思うよ
いまになって「騙された！」って叫ぶ人もいるけどｗ
明らかにあのときは双方合意でやってたしね
すごい金入ってきたし
>>711 あぁー、そういう立場だとアンチタスクになるのはなんとなくわかるわ。
外注じゃないが、以前社内で派遣使ってたとき、不必要な情報は何も見せるなって
こっち側のシステムとか基底部分のコードは全てライブラリ化して渡してた。
派遣さん達は別室でそのシステムに合わせて末端コードを量産してもらってたんだけど
向こうでバグとか出ても基底のコード無いから追ってくの大変だろうなぁ・・・と思ってた。
基底システムも同時作成だから仕様コロコロ変わってバグもあったしｗｗｗ
これで基底がタスクシステムとかだとタスク憎し！になるのかも仕方ないかとｗｗ
でもそれはタスクシステムの問題とは違うんだけどな。
>>712 そんな意図ねーだろ
単純にプログラムの組み方を知らない人間が増えたってただそんだけでしょ
知っている方法が彼等にとってはそれだけなんだよ
普通に組むの普通って彼等にわかるんだろか？
３Ｄにしてもそうだけどどれだけ原理をわかって使ってる人がいるんだろか？
>>713 派遣や外注の経験は無いが、こっちも中小と大手２社に転職していくつか現場経験してきたけど・・・
会社規模や現場毎に文化やスタンダードが全然違うゲームプログラムで
「普通」に組むって言われてもなぁ・・・
エスパーでないので君にとっての「普通」が何なのか良くわからんよ。
それに３Ｄの原理って具体的に何のことを言ってるんだ？
マトリクス計算できてシェーダー書けて意図したようにモデル描画できただけじゃ何か不足？
コンシューマからアーケードから携帯機からＰＣから、全てに共通した「普通」なんて無いと思うけどね。
タスクシステムにしろ何にしろ、ここではそーいったやり方してるんだなぁ、
ぐらいで郷に入れば郷に従え、って受け入れることができないと、共同作業でゲームなんて作れんぞ。
>>714 ごちゃごちゃうるせぇなｗ
知らないなら一言知らないって言えよｗ
普通ねぇ。
>>716 処理の順番を変えなきゃならないとか、重複する部分を関数に分けるとか、
各プログラマに振り分けるとか、ってタスクシステムが得意とする範疇だけど
それらを実装する「手段」としてタスクシステム使うのが普通じゃなく異常って
理屈はどこから出てくるのかな？
まぁ、メインプログラマじゃない、基底部分から離れた所しか触れない外注とか
末端プログラマから見ればタスクシステムがあるおかげでこんなに苦労する・・・
とか思う所もありそうだけど。
仕事を割り振る都合上、末端プログラマにメインフロー部分まで丸見えになるのは
望ましくなのでね。
タスクシステムにしろ他の管理処理にしろ、個人レベルとかよほど小規模なプログラム
じゃない限り何らかの管理処理をかまして作るよ。
718 ：
名前は開発中のものです。 ：2009/09/13(日) 15:37:55 ID:3c0R0FZj
>>713 ＞普通に組むの普通って彼等にわかるんだろか？
普通って何すか？HSPで説明してよ。ぼくわかんないよ
＞３Ｄにしてもそうだけどどれだけ原理をわかって使ってる人がいるんだろか？
なにそれこわーい。原理が分かるってどの程度のお話なの？
ユークリッド幾何学の講義ができるくらいわかんないとダ、ダメェ～みたいな？
別に数学者になるわけじゃねーし、知識は道具として活用できりゃ
（血肉になれば）それでいいじゃんみたいな
それとも例えば
四元数を使うからにはそれを数学的に論じられなければダ、ダメェ～だとか
「ぼくぅ、今そこの部分で使ってるオイラー法の変形版みたいなコードさ。それの
計算結果がオイラー法よりも良好になっちゃう理由を数学的に説明してみ？」
みたいな強烈にうざーいハッタリ攻撃みたいなものなんでしょうか？
あ、HSPが神言語すぎて分からないならC/C++でもいいよ
またキチガイHSPerのおでましか
722 ：
名前は開発中のものです。 ：2009/09/13(日) 19:53:00 ID:3c0R0FZj
タスクシステムなんて元々は超フリーダムシステムだったのにな
>>717 >処理の順番を変えなきゃならないとか、重複する部分を関数に分けるとか、
>各プログラマに振り分けるとか、ってタスクシステムが得意とする範疇だけど
>それらを実装する「手段」としてタスクシステム使うのが普通じゃなく異常って
>理屈はどこから出てくるのかな？
普通のアプリではタスクシステムを使わないから、
タスクシステムを使うのは特殊と言えるだろう。
724 ：
名前は開発中のものです。 ：2009/09/13(日) 20:54:22 ID:3c0R0FZj
普通のアプリってなんだ。まーたワードとかエクセルがどうのとかか
>>723 ”普通”のアプリがWindowsGUIアプリとかサーバアプリのことを言ってるなら
>処理の順番を変えなきゃならないとか、重複する部分を関数に分けるとか、
>各プログラマに振り分けるとか、ってタスクシステムが得意とする範疇だけど
ってのがそもそもゲーム以外であんまり無いからじゃないのかね。
あとVsync１フレーム内に処理を終わらせないといけないからメッセージ駆動と相性が
悪いとかコンシューマハードのメモリ制限とかの条件が”普通”とは違うから
タスクシステムみたいなのが使われる理由なんでない？
でもこの条件って一般的な”コンシューマゲーム”では普通だと思うけど。
ID:fqn+gvZkだけど
引数さんってすごい人生送ってんだね
>>726 大人になったら「自分の普通と他人の普通は違うもの」ってことを理解しないね。
自分と違う人間は話す価値もない雑魚。みたいに考えてると結婚も就職もうまくいかないぞｗｗ
あと3Dの原理とやらもさ。分かってるかどうかの閾値は何よ
あー。でもよく読んだらID:fqn+gvZkさんって分類上はアンチなのか
731 ：
名前は開発中のものです。 ：2009/09/14(月) 00:42:59 ID:ITTqVfd8
HSP君は噛み付く相手を選ぼうぜ
732 ：
名前は開発中のものです。 ：2009/09/14(月) 01:12:47 ID:ITTqVfd8
しかしまぁ、タスクシステムは本当にただのローカル用語だったのだが
＞今ではすっかり厨房用語
まあ、この辺は言葉の定義が曖昧だからしょうがないかもしれんが、
>>734 Logicianの所にアセンブラ時代は今で言うCPSのようになってた
ことをうかがわせる記述があるね。
>>733 ゲーム作りたい奴なんて昔も今も厨房なんでその指摘は当たってると思う。
ただ独自に発想した結果OSと似たものができたのか
仕組みそのものもOSからパクったものなのかはわからない。
個人的には後者だと思う。
>>733 > 初っ端から厨っぽいハッタリ臭が漂ってると思うよ
( ；∀；)ｲｲﾊﾅｼﾀﾞﾅｰ
> Logicianの所にアセンブラ時代は今で言うCPSのようになってた
738 ：
名前は開発中のものです。 ：2009/09/14(月) 20:33:27 ID:DstoX78Z
一番苦労するのはオブジェクト同士の関連部分なのにそこのサポートがない仕組みがそもそも役に立たないよね
>>727 間違えた。引数さんごめん
引数さんはもっと男前だった気がする
この自営業さんには彼の男気を感じない
>>738 そこをサポートせずに使う側に投げてるのがタスクシステムの利点であり欠点でもある。
オブジェクト同士の連携はゲームの仕様に合わせて勝手にやってね、そこはタスクシステムの
関知するところじゃないから、ってスタンス。
なので純粋なタスクシステムは基本的にゲームに合わせてカスタマイズ、拡張しないと使えない。
ただ、そこに手を出さなかったから生き延びてるってのも事実。
オブジェクト同士の関連はゲーム仕様やハード制限に強く影響を受けるから、もしタスクシステムが
そこをサポートしていたら、タスクシステムはごく一部の仕様やハードスペックに依存した物になる。
そのややこしい部分を内包しないおかげでタスクシステムという仕組み自体はなんだかんだで
絶滅せずに色々なゲームで使われてる。
＞ 1（キャラ）オブジェクト=1Taskという勘違い
>>741 わざわざ僕は馬鹿ですって言いふらさなくてもいいのにwww
そんなんだからいつまでも下っ端の底辺ＰＧなんだよ。
早くプロのゲームプログラマになれるといいねｗｗ
>>740 >そこをサポートせずに使う側に投げてるのがタスクシステムの利点であり欠点でもある。
もうこれだけで駄目
そっから下の文章馬鹿すぎて読めない
なにこれ？なにこの文章？
馬鹿もここまでくるとすごいなｗ
またキチガイHSPerのお通りだぜ
746 ：
名前は開発中のものです。 ：2009/09/14(月) 23:40:07 ID:RKVdgOVY
>>742 ＞時間軸の、スケジューリングの都合
まぁそういう解釈もありなのかな。手続き（処理順序）の都合で分割してるわけだからな。
並行性を満たすための手続きだったり、正しく描画するための手続きだったり。
敵1機や弾1発という分割単位には別に拘束されない。
747 ：
名前は開発中のものです。 ：2009/09/14(月) 23:55:13 ID:RKVdgOVY
>>746 補足
あとは外部の（疎結合の）プロセッサ等に送るコマンド（パケット）サイズの都合で分割されてたり
まぁこれも手続きの都合でありスケジューリングの都合ともいえるのかな。知らん
>並行性を満たすための手続きだったり
内緒だけど、
>>740 >オブジェクト同士の連携はゲームの仕様に合わせて勝手にやってね、そこはタスクシステムの
>関知するところじゃないから、ってスタンス。
>なので純粋なタスクシステムは基本的にゲームに合わせてカスタマイズ、拡張しないと使えない。
>ただ、そこに手を出さなかったから生き延びてるってのも事実。
結局、関知するのかしないのかどっちなんだよ。
関知しないはずなんだけど、関知するようにカスタマイズしないと使えない。
つまり、最終的には関知する。でも、関知しないから生き延びてる。
意味不明。
オブジェクト同士の連携も処理順も、メインループ側から素直に関数呼ぶ実装にしておけば
>>751 > オブジェクト同士の連携も処理順も、メインループ側から素直に関数呼ぶ実装にしておけば
> 明確なはずなのに、
処理順で描画のプライオリティを変更するようなシステムだと、
処理順を変更したいことは結構あるのだけど、↑のような実装になっていると
処理順を変更するのは手間がかかると思うけどな。
典型的なタスクシステムなら、
taskSystem.setPriority(100);
って書くだけで処理順を変更できると思うが、「メインループ側から素直に関数呼ぶ実装」の
場合、どれだけこのためにコードを書かないといけなくなる？
>>752 >処理順で描画のプライオリティを変更するようなシステムだと、
？？？・・・は？・・・
タスクシステムは、ゲームにあわせてカスタマイズしなきゃ使えないって言うんなら、
>処理順で描画のプライオリティを変更するようなシステムだと、
>>755 > 描画も処理の一部として一律にタスクシステムで処理するってんなら、
> 頭おかしいし。
そんなことないね。画面に1000ぐらいオブジェを表示していて、それのソートなんかしたくない。
携帯用のゲームとか書いたことがないんだね。初心者プログラマ乙。
ソートしたくないんだったら、タスクシステム使わずにベタで書けよ。バカじゃね
おまえ、処理の順番変えるから、タスクシステム使いたいとか言っといて、
こんどは、並べ替えたくないとか、何言ってんだ？
>>750 でも指摘したけど、言ってることむちゃくちゃすぎるだろ。
>>746 それだったら何でTask基底クラスなんか継承させてエンティティ作るわけ？バカじゃん？
あと並行性とか意味がわかんないし。そんなの完全無視でゲーム作れるじゃん
タスクシステマーはすぐそうやって高専生にわからない難しい単語を駆使して
煙に巻こうとするよね
>>749 おまえらタスクシステマーはすぐそうやって調子に乗る
タスクシステマーにちょっとでも理解を示すような素振りを見せると
ダークサイドへと、暗黒面へと誘う。気持ち悪い
---------------------------------------------------------
怪物と闘う者は、その過程で自らが怪物と化さぬよう心せよ。
おまえが長く深淵を覗くならば、深淵もまた等しくおまえを見返すのだ。
フリードリヒ・ニーチェ
タスクシステムを（頭ごなしに）否定してる人たちって、
処理順序とやらを動的にする場面なんて2DSTGにあるのか？
764 ：
名前は開発中のものです。 ：2009/09/15(火) 01:53:32 ID:hfHn/VaN
>>760 くっくっく。お前初めてか？まぁ力抜けよ。こっちへおいで
>>758 > おまえ、処理の順番変えるから、タスクシステム使いたいとか言っといて、
> こんどは、並べ替えたくないとか、何言ってんだ？
描画順を調整するためにstd::listやstd::vectorみたいなものをソートしたくないと言ってるんだ。
例えば、毎フレーム、std::sortとか呼びたくない。
処理の順番を変えるのは、タスクシステムが持っているような最初から整順されている
コンテナの適切な所に要素ひとつinsertするだけであって、これは、狭義にはソートとは言わんでしょ。
>>759 > タスクシステマーはすぐそうやって高専生にわからない難しい単語を駆使して
> 煙に巻こうとするよね
ゲームをろくに作ったことのない初心者プログラマはお呼びじゃないよ。
バーカバーカ。もう知らない
>>762 > 処理順序とやらを動的にする場面なんて2DSTGにあるのか？
> 少なくとも俺はそんなの必要になった試しがないから俺は要らない
自機を雲の一部に潜らせたいとして、そのときその部分の雲は自機よりプライオリティ高いよな。
そこに敵を打ち落として、爆発したときに、高度が浮き上がって墜落するように見せたいとする。
雲より一瞬手前に持ってきて、そのあと背景の雲よりさらに後方に持っていかなければならない。
こんな単純な処理ですら、描画プライオリティの変更が発生するが、HSPerはどんだけ
ゲームの製作経験に乏しいのか、どうしてそんなにイマジネーションが貧弱なのか。
俺はそっちのほうを小一時間問い詰めたい。
つられないくまー
770 ：
名前は開発中のものです。 ：2009/09/15(火) 02:34:51 ID:hfHn/VaN
一陣の風が吹き抜けるがごとくHSPバカが通り過ぎていった
>>768 > ゲームの製作経験に乏しいのか、どうしてそんなにイマジネーションが貧弱なのか。
最近の新人プログラマにも多いんだよ、そういうの。ゲー専卒で入ったはずなのに、
HDサイズのポストエフェクト、毎フレームGPU使わずにCPUで1ピクセル単位にgetPixel/setPixelって仮想関数呼び出して
「なんでこんな簡単な処理で60FPS切るんですか？次世代機って遅くてぜんぜん使いものになりせんね」って・・・
こんなレベルのが普通にゲーム会社に入社してくる時代なんだから・・・
しかも、なぜか彼らは共通してOOPとかデザパタが大好きで、そして根拠の無い自信でいっぱいなんだ。
そのやり方じゃ処理速度的にダメだろ・・・って言っても
「は？仮想関数なんてOOPの基本でしょ？それ使わないなんて何原始的なこと言ってるんですか？」
とか、本気で言い返してくるし。
プログラマ辞めて病院行け！と言いたくなるようなのが増えてる。
幸いにもチーム員を選べるだけの権限があるのでこーいう地雷プログラマは他に押し付けて難を逃れてるけど、これがゆとりってやつかねぇ・・・
>>756 ,765,768
その方向で突っ込まれるたびに条件を狭めて反論していくと、
携帯機みたいに CPU リソースが乏しくて、且つ、オブジェクトの数が 1000 単位で、
且つ、優先度の変更がゲームオブジェクトの明示的な状態変更でしかおこらくて、
・・・と、どんどん限定された状況でしかタスクシステムが適切な場面が無くなってる
ことになるんだけど、そういうものってことであってる？
>>772 条件を狭めているつもりは全くないよ。
俺がタスクシステムが使えるシーンとして A,B,Cを例示したからと言って、
タスクシステムが使えるのは、 A && B && Cと限定してわけではない。
こんなのは、初歩的な論理学だと思うんだが。
>>773 ん？おかしいな。
言い換えてみよう。
携帯機みたいに CPU リソースに乏しくなければ毎フレーム描画優先度で
ソートすれば（3Dでは当然）良いし、オブジェクトの数が数十単位なら今時の
携帯機なら毎フレームソートしてもほぼ問題にならないし、毎フレーム優先度が
変わる可能性があるようならそもそも毎フレームソートしないとダメで、やっぱり
どの条件が欠けてもタスクシステムが処理順（＝優先度）を保持してることの
メリットが消えることになりそうなんだけど、そうじゃないの？
>>774 > タスクシステムが処理順（＝優先度）を保持してることの
> メリットが消えることになりそうなんだけど
それは違うね。
タスクシステムが処理順を保持しているのは、描画の優先順位のため以外にも、
呼び出される順番自体を制御したいからだ。
Aというボスに対して、その相対座標(-10,-20)に表示されるザコキャラBを表示したい場合、
Aの移動処理が完了してから、Bの移動処理を行なう必要がある。
だから、ここには、A,Bの移動処理に関して、守るべき呼び出し順序がある。
上のようなことをやろうとするなら、タスクシステムが処理順(優先度)を保持しているのは
必要不可欠なことで、「毎フレーム描画優先度でソートすれば」解決するような問題ではない。
>>775 「移動処理」の順番は静的にコードに書けばいいし、そうしたほうが
いいだろ、という話で >751 に戻ってしまうわけで。
それに、移動処理の順番を保持したいからという理由で描画処理の順番を
保持するのが必要不可欠ってことは、移動処理の順番と描画処理の順番が
同じである（あるいは何らかの関係がある）と言うことが前提になりそうなん
だけど、それもキツイ制約だね。（ぶっちゃけありえない）
移動処理と描画処理の順番に何の前提も持たない場合（個人的には自然な
状態）ではやっぱり描画順をタスクシステムが保持するメリットがあるのは限定
された環境でのみ、って話になりそうだよ。
ちがうの？
>>776 > 「移動処理」の順番は静的にコードに書けばいいし、そうしたほうが
> いいだろ、という話で >751 に戻ってしまうわけで。
だから、動的にボスとかザコとか増えるんだよ。ボスが産み出すザコは限りなかったり、
ボス自体が無数に出てくる。どういうコードをもって静的に書けると言ってるんだ？
サンプルプログラムを書いてみせなよ。
> それに、移動処理の順番を保持したいからという理由で描画処理の順番を
> 保持するのが必要不可欠ってことは、移動処理の順番と描画処理の順番が
> 同じである（あるいは何らかの関係がある）と言うことが前提になりそうなん
> だけど、それもキツイ制約だね。（ぶっちゃけありえない）
そんなことは俺は前提にしてないぞ。
移動処理の呼び出し順と描画順が同じじゃないなら、
タスクシステムがstd::list<Task*>みたいな奴を2本持っていればいいだけ。
その話題は、このスレの過去スレでもさんざん出てきてるだろ。
778 ：
名前は開発中のものです。 ：2009/09/15(火) 07:37:09 ID:mI0eh4Bx
処理順を動的に切り替える設計なんて腐った仕様にしねーよ(笑)
>>778 程度が低いのはお前。
処理順を動的に切り替える設計にしないと要求使用を満足できないんだよ。
現場経験のないド素人プログラマがしゃしゃり出てくんな。
780 ：
名前は開発中のものです。 ：2009/09/15(火) 07:42:43 ID:mI0eh4Bx
動的に増えたってそりゃmanageクラスの保持するインスタンスの数が多いか少ないかの話しだろ
781 ：
名前は開発中のものです。 ：2009/09/15(火) 07:45:20 ID:mI0eh4Bx
３Ｄはツリー状に処理するけどそれだってタスクシステムなんていらねえよ(笑)
>>780 だからサンプルを書いてみせろって。お前が思っているほど甘くないよ。
>>781 タスクシステムがいらない代わりにかなり大がかりな3Dエンジンがいるじゃん。
お前、本当に自分で一度でも3Dのエンジンを自分で書いたことがあるのか？
マスター前に処理落ちやメモリ不足をギリギリまで泊り込みでチューンするのは
784 ：
名前は開発中のものです。 ：2009/09/15(火) 12:45:27 ID:mI0eh4Bx
その辺の仕組みとこの話題は全く関係無いよ(笑)
785 ：
名前は開発中のものです。 ：2009/09/15(火) 12:49:12 ID:mI0eh4Bx
タスクシステムが必要な理由ってそんな恥ずかしいもんでいいの？
>しかも、なぜか彼らは共通してOOPとかデザパタが大好きで、そして根拠の無い自信でいっぱいなんだ。
ただ、一つの方向性は見えてきたと言えるんじゃないか？
for(;;)
>>788 >タスクシステムは、動的に処理順を変更したい場合にメリットがあると
ないだろｗ
じゃあ、３Ｄのツリー構造とかの役に立つのかよｗ
ということで、タスクシステムのメリットはなくなりました。
>>786 > ほれ。
>>117 > 仮想関数も動的な呼び出しも使わないからタスクシステムより高速
117は全然駄目だよ。
player型(型名は先頭大文字にしてくれ！)より enemy型のほうが優先して実行したいのではないんだ。
優先して実行したい順番が型によって決まるのではないんだ。オブジェクトを生成した瞬間に決まるんだ。
ボスがザコを生成する。そのザコがザコ2を生成する。ザコ2はザコの位置から相対で出現するが、かと言って、
つねに、ボス→ザコ→ザコ2 の順番で移動処理を呼びたいわけではない。ザコ2==ザコの場合だってありうる。
だから型ごとに優先順位を持たせようという考え方自体がおかしい。
あんた、本当にゲーム作ったことあんのか？
>>792 は？
どういう場合を想定していってるの？
３Ｄの多関節構造みたいなゲームオブジェクトなんてそんなにねーぞ
足場とかだけど普通型で決まるだろ？
木になってる実が落ちて地面の上で転がって落ちて川に流れてみたいなのやっても
そんな処理順序を制御しないとうまくいかないなんてまずないっていうか
おかしいだろそれ
壁とか足場の当たりの判定を物体の移動毎にやらなきゃいけないとかそういうことならあるけどさ
同列に処理順序を制御していいことってあるか？
それよりも、
1msの処理に何百人が何年もとりかかる
797 ：
名前は開発中のものです。 ：2009/09/16(水) 00:32:11 ID:8HYG9zOk
お？ID:A8I4hqlh = ID:bJbP9YDC なのか？
>>797 なんで２ｃｈの匿名掲示板で人物を特定したがるの？
バカなの？死ぬの？
799 ：
名前は開発中のものです。 ：2009/09/16(水) 00:45:26 ID:8HYG9zOk
ID:z7cESVWf は2D専用オヤジの可能性が高いので優しくすべきである
800 ：
名前は開発中のものです。 ：2009/09/16(水) 00:51:18 ID:8HYG9zOk
なぜ2D専用オヤジに優しくすべきなのか。それはタスクシステムの長所の多くが
>>795 > 型名は先頭大文字にしてくれ！
> に笑っちゃうという。
> それはお前の会社のローカルルールだろ。
違うね。.NET FrameworkやJavaなどで推奨される。
それともお前の会社は、MicrosoftやSun Microsystemsより大きいの？
タスクシステムは推薦されましたか？
>>799 > 本物の2D専用オヤジならタスクシステムがメインループを固定する
> 理由を明快に答えられるだろ
「タスクシステムがメインループを固定する」の意味がわからない。
もう少しまともな日本語は使えないのか。
敵味方関係なく回りに噛み付き出したら末期だな。
>>793 >
>>117 の中身は
>>529 みたいになってて、
> 型間を飛び越えて列挙される順番を指定できる。
529はアンカーミスか？117と529がどう関係あるのかさっぱりわからない。
ちゃんとコンパイルできるソースをuploaderにでもあげてくれないか。
>>794 > 木になってる実が落ちて地面の上で転がって落ちて川に流れてみたいなのやっても
> そんな処理順序を制御しないとうまくいかないなんてまずないっていうか
おかしくないよ。単なる2Dのシューティングでボスキャラの相対位置にザコキャラを表示したいだけであっても、
このときボスの移動処理をザコキャラより先に行なう必要がある。
これはわかるのか？
ここがわからないなら、話はこれで終わりだ。
>>801 MSやその他の会社のAPIが先頭大文字にしてるから、
分ける意味で俺は初っ端のワードだけ小文字にして自分の関数と分けてるけどな
（例）createUnko();
808 ：
名前は開発中のものです。 ：2009/09/16(水) 01:00:40 ID:8HYG9zOk
>>803 ブート後、電源が落とされるまでメインループを共有する理由だ
ずーっと使い続けるタスクのリンクリスト（実行待ちキュー）が
ある理由だよ
>>804 > 敵味方関係なく回りに噛み付き出したら末期だな。
ちなみに、俺はタスクシステム推奨派でも否定派でもないからな。
このスレのゲームすら作ったことのないくせに偉そうにしているアンチタスカーと
並びに、しょーもないタスクシステムをタスクシステムだと言ってるド素人プログラマ、
お前ら、全員、俺の敵！
>>805 おまえロートル過ぎるだろ。
自分で考える頭ないのかよ。
>>801 にしてもそうだけどよ。
どうせタスクシステムも上司が推薦したから使った程度の成り行きなんだろ。
>>807 > 分ける意味で俺は初っ端のワードだけ小文字にして自分の関数と分けてるけどな
> （例）createUnko();
それ関数名の話でしょ。俺がしてるのは、クラス名！
>>808 > ブート後、電源が落とされるまでメインループを共有する理由だ
「メインループを共有」の意味がわからん。もう少し日本語がなんとかならんのか。
タスクシステムのどれを「メインループ」だと言っているのか、それすらわからん。
814 ：
名前は開発中のものです。 ：2009/09/16(水) 01:05:48 ID:8HYG9zOk
>>799 、
>>808 補足だが、別に間違いを指摘する気はない
ちょっとした値踏みだ。考え方でおおよそのところは察せられる
>お前ら、全員、俺の敵！
816 ：
名前は開発中のものです。 ：2009/09/16(水) 01:06:33 ID:8HYG9zOk
>>809 > でも逆はねぇだろ
> そしたら固定じゃん
違うね。処理順は動的に変わるんだよ。
ある瞬間からザコが編隊を成して、その相対位置にボス2を表示しないといけないかも知れない。
でも、あるときには、ボス2の相対位置にザコを表示しないといけないかも知れない。
なんでこれを優先順位固定で設計していいと思えるのか、俺にはそれが不思議だ。
そんなゲームしか作ったことないの？
>>816 回り全員敵だって本人が言ってるじゃん。
職場でも日々そういう状況で性格歪んじゃったんでしょ。
>>811 > 自分で考える頭ないのかよ。
>>801 にしてもそうだけどよ。
違うね。801は、
>>795 で、型名の先頭大文字が俺の会社のローカルルールだって言うから、
俺はもっと世界的規模でそうなっていることを示しただけ。
お前、本当に日本語読めてるか？
>>817 雑魚倒されたときのボスの仕様が見ものだなｗ
>>815 > >このときボスの移動処理をザコキャラより先に行なう必要がある。
> update_boss();
> update_zako();
> 終わり。
全然終わりじゃない。そんな固定順序で処理していいわけではない。
ド素人プログラマならお断わりだ。
823 ：
名前は開発中のものです。 ：2009/09/16(水) 01:11:44 ID:8HYG9zOk
こいつはネット発生型のタスクシステマーだな。素人くさい
>>816 > こいつの警戒っぷりはおかしい
警戒はしてない。ド素人プログラムの集団相手に、警戒などする必要がない。
>>818 > 回り全員敵だって本人が言ってるじゃん。
> 職場でも日々そういう状況で性格歪んじゃったんでしょ。
是が非でもそう思いたいんだな。お前は、可哀想な奴だよ。
>>819 > だから全部同じだって
意味がわからない。片言でじゃべんな。
関数名は、小文字で始まるラクダ表記にするのは勝手にしたらいい。
それは特に弊害はないと思うよ。趣味の問題だ。
どうせ関数を呼び出すには、XXX() のように括弧が必要なのだから。
クラス名を小文字で始めると視認性が悪く、変数名とバッティングするから避けるべきだと言ってるんだ。
>>821 > 雑魚倒されたときのボスの仕様が見ものだなｗ
それはゲームによりけりだな。
>>823 > こいつはネット発生型のタスクシステマーだな。
勝手に決めつけんな。俺は8080の時代からプログラム書いてるよ。
>>826 > どうでも良いから、
>>117 と
>>529 をよーく見比べて、
> どこがどう対応しているか、自分で考える癖を付けろ。
そんな、型名を小文字で書き始めるキチガイの書いたソース読むの嫌だ。
コンパイルが通るソースを出してくれるなら読むというだけ。
831 ：
名前は開発中のものです。 ：2009/09/16(水) 01:21:46 ID:8HYG9zOk
>>829 そんな台詞なら趣味マイコンヲタあがりのやねうらおとかいう
PCエロゲプログラマだって似たような台詞を吐けるだろう
まぁいい。お前の素性はおおよそのところはESPで察せられる
臭うんだよ
そろそろおねんねの時間だぜ(俺が)。
>>828 いや、違うな
雑魚に追従するからなんて理由でボスと雑魚の処理順序を代えちまうようなチャチな仕組みだから
雑魚がボスが死ぬことを知るのは次のフレームだし
また、逆のルーチンが走ってるときはボスが雑魚の全滅を知るのも次のフレームだｗ
シビアなゲーム作ってるときは企画に散々おかしいっていわれるぞｗ
こういう処理やるときって面倒でもちゃんとswitchcaseかifで分けてしっかり書いたほうがいいと思うんだよねｗ
シーンにボスと雑魚の関連処理をちゃんと書いたほうがいいんじゃね？
タスクシステム生かしてボスか雑魚にこの処理書くの？（バグがとまらないなｗ）
>全然終わりじゃない。そんな固定順序で処理していいわけではない。
固定順序で処理してはいけない仕様なんだったら、そこだけ局所的に
動的な処理の呼び出し&スケジューリングをすればよいだろ。
>>817 みたいな有るのか無いのか分からない極まれな事例を持ち出して
ゲーム全体でタスクシステムを使うことの有用性を主張するのは無理があると思うね。
一部がそうだからって、全部をそれにあわせてどうする。
お前みたいな奴に社会全体があわせる必要がないのと同じだ。
>そんな、型名を小文字で書き始めるキチガイの書いたソース読むの嫌だ。
>>834 > 雑魚に追従するからなんて理由でボスと雑魚の処理順序を代えちまうようなチャチな仕組みだから
> 雑魚がボスが死ぬことを知るのは次のフレームだし
それは違うな。そんなこと勝手に決めつけられても。
ザコがボスが死んだことを同フレーム内で関知したいならザコは
boost::shared_ptrでボスのポインタを持つよ。
> タスクシステム生かしてボスか雑魚にこの処理書くの？
そんなことは俺は一言も言っていないよ。
必要があれば、behaviorとして書く。あんたの言うところのシーンクラスか、behavior用のタスクに書く。
>>835 いや、まあ、あるとは思うけど
その解決方法がまずいね
ボスと雑魚の間にあきらかにボスと雑魚を包括するステータスが見えているのに
ボスと雑魚だけを一生懸命意地って解決しようとしてるのはまずい
場合によっては解決できない（ほど複雑になる）こともあると思うぜ
>>835 > 固定順序で処理してはいけない仕様なんだったら、そこだけ局所的に
> 動的な処理の呼び出し&スケジューリングをすればよいだろ。
だからそれが嫌だって言ってんの。タスクシステムなら、
taskSystem.setPriority(XX)
ってして順番指定するだけでそれが出来る。
>>837 じゃあ、処理順序なんて変えないではじめからそれ使ったら？
いきなりの新ワードでそれが何か俺は知らないけどｗ
それ使えば解決できんじゃねーの？
>>838 > ボスと雑魚の間にあきらかにボスと雑魚を包括するステータスが見えているのに
> ボスと雑魚だけを一生懸命意地って解決しようとしてるのはまずい
俺、そんなこと主張してないし、そんなコード書かないぜ。詳しくは
>>837 。
>>841 そうなるとタスクシステムの利点としての処理順序の制御はまだ活きてるの？ｗ
型名を小文字で書いただけで、もう読む気しないという。
>>842 > タスクシステムの利点としての処理順序の制御はまだ活きてるの
タスクシステムで順序変更したい/してメリットがあるときは、タスクシステムを使って処理順序を変更すればいい。
要するにそれだけだ。
そろそろ、もうおねんねだ(俺が)。
おやすみ。
>>843 > 一部を全体に拡張君とでも名づけようか。
俺のことは、全員敵！君 と名付けてくれ。
ド素人プログラマの馴れ合いにはヘドが出るぜ。
>>839 処理の変更が一部で必要なだけなのに、全体をタスクシステムで書くの？
やっぱり頭おかしいね。
まともなエンジニアなら、道具は使い分けるだろ。
流れが早くてついていけないな
848 ：
846 ：2009/09/16(水) 01:41:39 ID:PDg1ax2i
訂正： 処理の変更→処理順の変更
>>846 > 処理の変更が一部で必要なだけなのに、全体をタスクシステムで書くの？
そうだよ。
> やっぱり頭おかしいね。
おかしくないよ。あんたの書いたソース出してみな。俺がレビューしてやるから。
> まともなエンジニアなら、道具は使い分けるだろ。
俺から言わせれば、あんたは頭のおかしいド素人プログラマだ。
確かに、プラスのネジもマイナスドライバーで締めることは出来るから、
>だからそれが嫌だって言ってんの。タスクシステムなら、
852 ：
名前は開発中のものです。 ：2009/09/16(水) 01:58:54 ID:8HYG9zOk
ID:9rR5lXOaにほぼ同意だな
853 ：
名前は開発中のものです。 ：2009/09/16(水) 02:00:00 ID:8HYG9zOk
こういう手合いというのはID:X/yeAXR1だからな。お前だお前。臭い奴だ
>>850 プラスネジに数本マイナスネジが混じるくらいなら、いっそ全部マイナスネジの方がメンテナンスは楽になるな
855 ：
名前は開発中のものです。 ：2009/09/16(水) 02:13:28 ID:XNXMwvpA
今日はいつになくド素人プログラマが大量に釣れてるな。
856 ：
名前は開発中のものです。 ：2009/09/16(水) 02:15:46 ID:8HYG9zOk
釣り宣言とかね。いい歳してやっちゃ駄目。最後まで演じ切る。大人の常識
俺も業界歴は長いが、アマチュアの頃は
>>789 みたいに書いていたが、
おそらく色々な問題に対応するために、タスクシステムを使うようになった。
しかし、何の問題を解決したかったのか、もはや思い出せないw
なんか一周回って、
>>789 でも良い気がしてきた。
>>849 >> 処理の変更が一部で必要なだけなのに、全体をタスクシステムで書くの？
>
> そうだよ。
死亡フラグにしか見えない。
デバッグ中にテスト済みだったはずのところでバグが出て、「何でいまさらこんな
ところで？」って不思議に思ってたら、「あるステージの敵の処理で必要に
なったんで、タスクシステムをカスタマイズ・機能強化して対応しました」とか得意げに
言ってるやつがいるとか・・・
デバッグ中に仕様の穴が見つかって、相談の結果「ここだけ～な感じにすれば
よさそう」って話がまとまりかけてたら、「それは今のシステムでは不可能です。
システムに手を入れる必要があります。しかし今からでは影響範囲が大きくて
危険です」とか悪びれもせず言ってのけるやつがいるとか・・・
859 ：
名前は開発中のものです。 ：2009/09/16(水) 02:27:46 ID:8HYG9zOk
まぁ例えばVS2008EEでC/C++、DirectX使用。
>>859 素人にタスクシステムを使えなんて勧めてるタスカーなんて居たか？過去スレでも見たこと無いぞ。
アンチの発言があまりに突っ込みどころ満載なんで、おもわず突っ込んでるだけで。
861 ：
名前は開発中のものです。 ：2009/09/16(水) 02:51:06 ID:8HYG9zOk
すまん
>789 で update_enemies の中身を出してないのは
>>862 >789 の update_enemies() に、仕様によっては「タスクシステムっぽい」何かが
入ることはあるかもしれないけど、仕様によっては入らないこともあって、つまり
どうでもいいんでしょ。
これに対して、ゲームなら必ずすべて「タスクシステム」が必要になるかのような
ことを言い出すから、おかしな話になるわけで。
でも実際にタスクシステム使う使わない云々は置いといてその考えを知るだけでもプログラミングの参考にはなるがな
>>864 >あと俺もクラス名先頭小文字は気持ち悪いな
気持ち悪いってだけで大した理由も考えずにそこで思考停止？ｗ
お前がMSにあわせちゃうとMSのAPIと区別できないじゃん
実用的な面はまったくみずにただの気持ち悪いってだけで決定しちゃうの？
こういうこと繰り返してるからまったく成長しないんじゃない？
>まあそこでボス依存の雑魚の処理はその部分はタスクオブジェクトをツリー状にするというやり方もあると思う
まだいってる・・・馬鹿だろｗ
ボスと雑魚の間にステータスがあるんだから面倒臭がらず用意しろよ
なんで用意しないの？
現場でいっしょに仕事してたらぶん殴ってる
殴られたら警察沙汰にする
>>865 > お前がMSにあわせちゃうとMSのAPIと区別できないじゃん
APIは関数呼び出しなんだから、末尾に () がついてるわけで、ソース見ればすぐにわかる。
一方、大文字でクラス名を始めないと、同名の変数名とバッティングする。
お前、きっとゴミクズみたいなソース書いてるんだろうな。
>>852 > 釣り宣言とかね。いい歳してやっちゃ駄目。最後まで演じ切る。大人の常識
釣り宣言なんか俺はしてねーぜ。
お前、本当にめんたまついてんのか？
>>859 には
>>860 みたいな指摘がついてるし、お前は早とちりが過ぎる。
>>858 > なったんで、タスクシステムをカスタマイズ・機能強化して対応しました」とか得意げに
> 言ってるやつがいるとか・・・
俺を勝手にそんな馬鹿タスカーと一緒にしないでくれ。
>>851 >>taskSystem.setPriority(XX)
>>ってして順番指定するだけでそれが出来る。
> 全てをそれで制御しなきゃならなくなる弊害は考えないんだな。
弊害って具体的に何だと思ってるんだ？言ってみ。
>>852 > タスクシステムのリンクリスト（実行待ちキュー）内での位置関係で
> 生残OBJ同士の関連性（親子関係、コンストレイント）も表してしまおう
> という発想がイカレているのだ。コンテナの流用、機能の癒着、混濁。
コンテナの流用を悪みたいに思っているところは、あんたが現場経験のない素人プログラマゆえんだな。
基本的にメモリ節約＆パフォーマンス重視。コンテナ流用できるなら流用して当たり前。
もちろん、流用してそれで設計が複雑化したりコーディングがややこしくなるケースなら流用しないがな。
872 ：
名前は開発中のものです。 ：2009/09/16(水) 07:31:18 ID:dJ8I9UGs
>>867 始めのwordだよ
つまりクラスならCunkoUtilになる
>>872 意味がわからない。
クラス名 → HogeClass
API呼び出し → HogeAPI();
変数名 → hogeClass
こうなっているから見ればわかると言うのが俺の主張。
これを、クラス名がAPIと紛らわしいから
>>865 は
クラス名 → hogeClass
API呼び出し → HogeAPI();
変数名 → hogeClass
こう書くと言うことらしいが、これだとクラス名と変数名との区別がつきにくいと俺は言ってるんだ。
そもそも
>>865 みたいな奴がまともなプログラマのはずがなく、俺はただのキチガイだと思うんだが。
命名規則の好みとタスクシステムに何の関係があるんだ？
>>852 > タスクシステムのリンクリスト（実行待ちキュー）内での位置関係で
> 生残OBJ同士の関連性（親子関係、コンストレイント）も表してしまおう
> という発想がイカレているのだ。コンテナの流用、機能の癒着、混濁。
おっ。マトモな人がいるじゃんｗ
>>871 > 基本的にメモリ節約＆パフォーマンス重視。コンテナ流用できるなら流用して当たり前。
おっと？ 最終的にはソレしか言うことなくなっちゃうのかな？
マトモな人間は先に柔軟に設計し、プロファイラを使い、後でチューニングする。
タスクシステムを簡易プロファイラとして使えるのは便利だな
遠くて見づらいが都合の良い >852 を目立つように参照付き引用しつつ
>>877 お前は何と戦ってんのｗ
基本的～。もちろん、～なら～。
だからこれは、何を基本にして、何を例外にしている？
マトモな人にとって、それは全く逆だと言っている。
こうだ。
基本的には柔軟な設計をし、遅い箇所はあとで速くする。
で、お前はコンシューマでゲームなんて作ったこと無い、
などと言い出すんならお前は恥をかくことになるぞ。
879 ：
名前は開発中のものです。 ：2009/09/16(水) 12:49:56 ID:dJ8I9UGs
>>878 柔軟な設計をしないとは書いてないだろ。
都合の良い解釈をして、それに反論することでその都合の言い解釈を
相手が主張しているように見せかける詭弁法だね。
根拠を見せずに一方的にマトモな人と表現することで
いかにも自論が多数派であるかのように見せかける詭弁法も使ってる。
最後の文は脅しなのかな。
敵だとは思ってないし正論で筋を通せばいいのに変な手を使われると
逆に人として負けた気分になる。>877はこっそり伝えたつもりだったのに。
881 ：
名前は開発中のものです。 ：2009/09/16(水) 20:42:10 ID:dJ8I9UGs
タスク信者は詭弁使い多すぎない？
詭弁だとか詭弁使いだとか指摘することに意味はないからやめてほしいな。
詭弁だというなら、その書き込みのおかしな点を指摘すればいいわけで。
>>880 > 柔軟な設計をしないとは書いてないだろ。
書いてあることだけ拾うと、 >871 で
「基本的にメモリ節約＆パフォーマンス重視」という方針で、
「コンテナの流用、機能の癒着、混濁」を受け入れる姿勢が示されている。
機能ごとに明確に分割されたプログラムは、変更の影響の範囲も明確で、
変化に対応しやすい。逆に「機能の癒着、混濁」があると、 >858 の例で
挙げているような、変化に対応しにくいプログラムのもとになる。
一般的に、プログラムが「柔軟」であるとは、プログラムが変化に
対応しやすいことを指す。
つまり、「機能の癒着、混濁」を「基本的に」受け入れてしまう姿勢では、
柔軟でないプログラムができあがりやすい。
>878 が言っている「柔軟な設計」について正確なところはわからないん
だろうけど、こういう解釈が一般的だと思う。
>>882 何を言ってるのかさっぱりわからない
柔軟ってのはタスクシステムの話なの？
処理順序がどうとかいうメリットの話はもうないの？
>>871 「コンテナの流用」が「基本的にメモリ節約＆パフォーマンス重視」
という方針に基づいてるみたいなんだけど、どうしてコンテナの流用が
メモリの節約やパフォーマンスの向上につながるの？
むしろ、場合によってはコンテナを流用してしまうことで最適化の機会が
失われ、結果的にパフォーマンスダウンにつながりそうな気もする。
たとえば std::list のメモリオーバーヘッド（リンクリストのポインタぶん）が
問題になるようなら std::vector に変えるようなことが考えられるんだけど、
コンテナを流用している場合、共用してるプログラムのひとつでも std::list の
特性に依存しているものがあれば、そういった最適化ができないことになる。
この例はメモリについてのものだけど、速度についても同様の状況が発生する
可能性が十分考えられる。
>>883 たぶんあんたにとってはあたりまえの話を、 >880 向けに細かく順を追うように
書いてみただけだよ。無視してもらってかまわない。タスクシステムのメリットを
語る立場でも無いし。（むしろ聞きたいほう）
このバカタレ（ID:/yeAXR1）の言うことに耳を傾けないで欲しい。釣り針デカ過ぎ。
最後の４行はゴミ。２ちゃんねるの書き込み難しいからオジサン即時撤収
>>881 生き方そのものが詭弁なんだろうよ。
都合が悪くなるたびに、極少例の事例を挙げてあーだこーだいう。
局所的に対応しろよ。全部を同じやり方でやる必要なんてねーよ。
そんなことしてたら、結局タスクシステム拡張しつづけないとゲーム作れない。
タスクシステムとタスクという切り分け自体に意味が無くなる。
>
>>117 も肝心の each_type 周辺を隠してるのよね。
かくしてねーよ。マクロの中身は
>>529 で示しているのに、
型名が小文字で始まってるから読む気しないと言われた。
もうむちゃくちゃだろ。どうしろっていうんだよ。
こんなところでコーディングスタイルの話をしても仕方ないが、
俺は、単語と単語の間はアンダーバーで繋ぐ派の人なんだ。
でも、そんなことどうだって良いだろ。
×バック切り替え
890 ：
名前は開発中のものです。 ：2009/09/16(水) 23:35:09 ID:oHTMG8q0
落ち着けよオッサン。そいつが頭おかしいのは既に感づかれてるからよ
>>888 ＞型名が小文字で始まってるから読む気しないと言われた。
＞もうむちゃくちゃだろ。どうしろっていうんだよ。
型名を大文字で始めればいいんじゃね？
892 ：
名前は開発中のものです。 ：2009/09/17(木) 08:36:14 ID:FkJnIZGb
揚げ足取りにしても三流過ぎる
>>888 > >
>>117 も肝心の each_type 周辺を隠してるのよね。
> かくしてねーよ。マクロの中身は
>>529 で示しているのに、
> 型名が小文字で始まってるから読む気しないと言われた。
> もうむちゃくちゃだろ。どうしろっていうんだよ。
「マクロの中身」って、言えば当然マクロの定義を示すべきだろ。
>>529 がマクロの定義か？馬鹿じゃねーの。
タスクって毎フレームの処理や描画を行うプログラムをコンポーネント化するときに便利だから使ってるんじゃないの？ｗ
>>1 だから、さっさと射程1000kmオーバーのMRBMに相当する標的を使えと。
もう何年も前から言われ続けてることだろうが。
射程120kmのしょっぱいSRBMをHit to Killできましたー、じゃお話に
ならないんだよ。
ｺﾞﾊﾞｰｸ
溺れる者は藁をも掴む。
何もつかめない君へありがとう
例の彼はもう来ないのかな。
902 ：
名前は開発中のものです。 ：2009/09/18(金) 00:54:52 ID:hh7+mZiP
>>871 お前は整理整頓されたものを引っ掻き回して全てを台無しにしてしまうタイプだよ
テーブルナプキンで尻を拭いて皿を拭いてしまうような奴はこれからも一人で
仕事をすればいい
903 ：
名前は開発中のものです。 ：2009/09/18(金) 01:16:26 ID:hh7+mZiP
>>886 > 単位時間当たりにこなすべき仕事をパイプラインに突っ込んでバッチ処理。
フレーム単位にこなすべき仕事を繋ぎ合わせてバッチ処理はしているが
パイプラインというのはちょっと違うと思うぞ…。そういう使い方に制限して
使うという話なら分かる
タスクシステム自体はタスク間のデータの受け渡し方法に関知してない
ただのバッチ処理だから実行中のタスクは全リソースにアクセスできる
Pipes ans Filtersのような使い方で拘束するなら、データの受け渡しは
隣接タスク間限定。そういう制限はタスク同士で取り決めるルール
あと、君が言う割り込みハンドラが非同期に突っ込むタスクってのも
前後タスクとのデータの受け渡し、依存関係はないと思う。挿入すれば
パイプラインの分断になるからやっぱりPipes ans Filtersという説明は
違うと思う。ただのバッチ処理、順次処理だ
>>799 固定してるのはメインループではなくメモリ
そこがわかってないとメモリの話をすっとばして
プリエンティブばかり目がいってしまい
本物のタスクシステムを見失う
>>807 ボーランド社員乙
>>808 想定ターゲットの違いがタスクシステムの存在理由の違いとなりえる
このレスについて言えるのはそれだけだな
>>812 クラス名は大文字CをつけるのがMSルールだろ
>>822 この問題定義だとそれが最適解だろｗｗｗ
>>834 そこはプロキシパターンだろ（ｷﾘｯ
>>864 パターンのひとつとしておもしろいけどネットでググると混乱するのでススめられん
だからタスクシステムよりアルゴリズム集見て欲しい希ガス
まぁ、いわゆる情報処理系の本は業務システム寄りになっちゃうのが難だが
弾幕時代のデータ構造はクアッドツリーだよな
リストじゃもう処理が間に合わないだろう
3DSTGから来た定番処理だが2Dゲームも複雑さが増したせいで
オーバーテクノロジーじゃなくなってきた
>>888 アンダーバーはC言語（非C++)の文化
単語ごとに先頭を大文字にするのはC++の文化
先頭のみ小文字で２つめ以降の単語を大文字にするのがDelphiの文化
変数名を見れば出自がわかる
育ちの卑しさは隠しきれない
聞けば聞くほど酷いシステムだなｗ
物事を考える手順を間違えてるよね
タスクシステムとは一見魔法のように便利なシステムとして紹介されることが多いがその実態を知れば知るほど幻滅するものである
信じたものは都合のいいタスクを繰り返し送り出すリスト
>>909 タスカーにしてあげる
だからちょっと覚悟しててよね
消失乙
912 ：
名前は開発中のものです。 ：2009/09/18(金) 01:59:03 ID:hh7+mZiP
>>907 お前はパンに付けるジャムの作り方を聞いている。パンは既に誰かが用意してくれてる。
ところがタスクシステムはパン生地の作り方から話が始まってる。しかも与えられた
道具も材料もとても貧しい。出発点がまるで違うということ。何もかも与えられた飽食の
時代の子にはそれが分からない。ある意味で正常。しかし食糧難時代の食事の作り方を
バカにするのは愚かだ。古典的な時間駆動（周期駆動）型のリアルタイムシステムの
プログラム構成を知れと言っていたのはそういうこと。幻想から目が醒めたかい？
食糧難時代の雑炊や麦飯を珍味と喜んだりするのがタスク信者は頭おかしいので
どうでもいい。
ところで
＞一番複雑になるのはどうしたってゲームオブジェクト同士の関連部分だよ
STGすら作れないアンチは相変わらず哀れだな
913 ：
名前は開発中のものです。 ：2009/09/18(金) 02:35:35 ID:hh7+mZiP
>>904 >弾幕時代のデータ構造はクアッドツリーだよな
>リストじゃもう処理が間に合わないだろう
ハ _
＿＿_ ∥ヾ ハ
/ ヽ ∥::::|l ∥:||.
/ 聞 え | ||:::::::|| ||:::||
| こ ？ | |{:::::∥. . .||:::||
| え | _｣ゝ/'--―- ､|{::ﾉ!
| な 何 | ／ __ `'〈
| い ？ ! /´ /´ ● __ ヽ
ヽ / / ゝ....ノ /´● i
｀ ー―＜ { ゝ- ′ |
厶-― r l＞ |
∠ヽ ゝ-― `r-ﾄ､_,) |
ﾚ^ヾ ヽ>'￣ LL/ 、 /
.l ヾ:ヽ ` ､_ ＼＼ '
l ヾ:ヽ ト`ｰ-r-;;y‐T^
| ヾ ｀ニﾆ｢〈〉ﾌ /∥. j
リストってのはタスクシステムのリンクリスト（実行待ちキュー）の話か？
何の処理が間に合わないって？
四分木がどうのってのはどうせ空間分割の話をしてるんだろうが
それがタスクシステムスレとどう関係してくるんだ？まさかお前は
タスクシステムのリンクリスト（実行待ちキュー）に空間分割の役割まで
与えていたのか？お前も靴磨きのブラシで歯を磨くような奴なんだな
>>912 は？何が主張したいのかさっぱりわからない
スレ違い気味だけど、
ゲーム内オブジェクトの管理方法の比較的新しいものとして
component-based entity system[1]があるんだけど、
そいつにはパフォーマンスの低下以外に、それぞれのcomponent同士の
対話をどうするかというような問題がある[2]らしい。
パターンとしてobserver patternがあるけど、これにもobserverそのものが
複雑になるという問題があるしね。
でこれを見て、
＞一番複雑になるのはどうしたってゲームオブジェクト同士の関連部分だよ
いうような類の問題は、システム部分の設計では解決しにくい問題なのかもしれないと思った。
んで、そういう認識の元では消極的だけど複雑な関連ができないようにロジックを簡略化する、
という道が考えられる。こちらの道にはまだ分割とか階層化とか余地はあるし、
システムでどうにかするよりかは楽そうに見える。
[1]game programming gems 5 1.3
[2]
http://www.gamedev.net/community/forums/topic.asp?topic_id=463508 916 ：
名前は開発中のものです。 ：2009/09/18(金) 08:18:31 ID:hh7+mZiP
>>914 つまりセンスがない。だからタスクシステムという言葉に縋り付き、裏切られ、
そしてキャンキャン吠えているのだろう？
『ボクをバカにするな。ボクが夢想してたのはそんなちっぽけな仕掛けじゃない』
『ボクの夢想しているエターナルフォースブリザードシステムはそんなもんじゃない。』
『今度もしこういうフレームワーク的な何かを作るなら、ちゃんと
【ボクの問題のプライオリティ】を考えて
それを解決できるようなもんを作ってほしいな』
お前の問題のプライオリティはゲームを作れないおつむをまず何とかすること。
ゲームが作れないのだからタスクシステムがどうのとか以前の問題だったのだ
new tasksystem ◆9ycqcAuWxdGZ は涙目で敗走いたしました。
いまだにタスクシステムの利点がわからないとか、そんな奴、ゴミムシ級の自称プログラマだろ。
ゴミムシ級の自称プログラマ＞＞＞タスクシステムの利点が分る王様
ゴミムシが吠えてやがるな ﾌﾟﾌﾟﾌﾟ
なんかアンチって箸使う利点がわからないって人と同じ感じだな。
ねえねえ、各処理をコンポーネント化する為に便利とかって視点はぜんぜんないの？？＞タスクシステム
>>921 俺様も使ってる和ゲー業界の常識であるから文化を尊重してお前らも
タスクシステムを使うべきだ（メリットなんかなくっても）ということですね、
わかりますん。
で、言うんだよね
>>923 「箸が要らない」って意見の否定≠「箸しか使うな」ってのはわかる？
>>924 すしがあるから箸は要らない、と・・・？
サンドイッチがあるからナイフとフォーク要らないとか言う馬鹿は居ないと思うけど。
あえて、あえて言おう！
しかし、ごめんね
敵味方入り乱れて乱戦状態
何このスレおもすれー
>>921 ,926
「タスクシステム」は箸でもナイフでもフォークでもなくて、例えて言うなら
「ナイフとフォークを２つ合わせて逆にもてば箸にもなるんじゃね？」
「箸にも使うんだったらもうちょっと軽い素材にしたほうがよくね？」
「もっと箸っぽく、先っぽを細くして、と、できたできた。」
「ナイフの部分を手で持つとあぶないから、もうちょっと長くして持つとこ広くしたほうがよくね？」
「いいね。さて、俺様の発明したこの画期的な道具を何と呼ぼう？」
「和食にも洋食にも使える道具だから、『食具』とかいいんじゃね？」
「『食具』か。聞いたことないし、なんかかっこいいな。それでいこう。」
って感じ。
確認してみよう。
「関数ポインタと汎用ワーク合わせてリンクリストに突っ込めばリスト一個でいいんじゃね？」
「全体で使うんだったらもうちょっとメモリ確保高速化したほうがよくね？」
「もっとシステムっぽく、マクロで包んで、と、できたできた。」
「処理順ごっちゃになるとあぶないから、処理優先度設定できるようにしたほうがよくね？」
「いいね。さて、俺様の発明したこの画期的なシステムを何と呼ぼう？」
「どんなゲーム中の処理にも使える道具だから、『タスクシステム』とかいいんじゃね？」
「『タスクシステム』か。聞いたことないし、なんかかっこいいな。それでいこう。」
うん。ぴったりだね。
>>931 タスクシステムで作られたゲームはたくさんあるけど
> 「ナイフとフォークを２つ合わせて逆にもてば箸にもなるんじゃね？」
なんて人は見たこと無いなぁ・・・比喩として成り立ってないんでない？
片方は実際に使われて実績出してるし、もう片方は存在しない前提。
それともタスクシステム使ってるゲームなんて都市伝説。
そんなゲームあるわけない。と思ってる人？
俺のやり方はタスクシステムの良さを取り入れ、それに柔軟性を持たせた感じ
934 ：
931 ：2009/09/19(土) 04:38:40 ID:UsvlV3Ou
>>932 そういうツッコミが出てきて話が発散するから例え話は危ないんだよな。
違いがまったく無ければそもそも比喩を使う意味が無いんだけど、
違いがあればその大小にかかわらず「それとこれとは違う」というツッコミを
入れる余地が生まれてしまうわけで。
というわけで、例え話を抜きにして改めて言いたいことを書いてみよう。
「タスクシステム」と呼ばれるものの多くがひとつのコンポーネントで
まとめて提供しているような複数の機能（動的コンテナ、関数ポインタ、
メモリプール、など）は現代のプログラミング環境ではそれぞれ個別の
機能として取捨選択できるものであり、そうしたほうが不要な機能のための
複雑さを押し付けられることがないので望ましい（そうしないと不要な
機能のための複雑さを押し付けられて嫌だ）ということ。
がんばって全部の機能が同時に有用であるケースをひねり出そうと
していた人が居たけど、そういうケースを挙げてもらったとしてもこの点は
変わらない。また、それだけ限定されたケースで使うコンポーネントで
あれば、「タスクシステム」などという実態を表さない名前よりももっと
具体的で良い名前が決められるはずだろう、とも思う。
ここまで読めば、 >931 の比喩でどこを対比させているのかわかって
もらえるんじゃないだろうか？
>>903 俺はPipes and Filtersという表現はなるほどなーと思ったよ。
$ cat ゲームデータ | Filter処理１ | Filter処理３
$ cat ゲームデータ | Filter処理２ | Filter処理１ | Filter処理３
$ cat ゲームデータ | Filter処理２ | Filter処理３
アセンブラで実装した概念はこれってことでしょ。だいぶ割り切ってる。
まず「レトロな」という言葉からタスクシステムが考案された状況を想像する。
・言語に変数の概念が無い(アセンブラ)
・言語に関数という概念が無いかも（アセンブラにcall, retが無いとか）
・メモリ割り当て、ジャンプ先アドレスは自分で管理する
・CPUはZ80かそれよりもっと古いもの。レジスタは8bitとか4bit幅。
・コード書き換えの際に少しでも間違えたらターゲット環境が暴走
・RAM/ROM少ない。コード変更後アセンブルしたら想定より1byte容量が増えて
他の人が使ってるメモリ領域上書きしちゃった、というのも有り得る程度。
・クロス開発。ROM焼きしないと動作確認不可。コード変更後の確認超面倒。
こういう状況下だったら「データ」より「処理」の方が変更しづらくやっかいで
重要なものと認識されてもおかしくない。
データ変更はサイズ変化しないしまだ取り扱いが楽、みたいな。
そうなると、
１、処理はあまり変更したくない小分けにして汎用的にしよう
２、「処理(要アセンブル)」を減らして「データ（アセンブル不要 or DataByte命令で記述可）」を増やそう
３、RAM/ROM少ないしCPUも遅いからゲームオブジェクトは少なくて良い
４、ゲームデータに「処理(Filter)」をどういった順序で適用させるか、
それを「データ」の変更だけで指定可能にすべき
という流れでPipes and Filtersの概念に昇華したのかなぁと。そう思った。
もしこれがレトロな環境でのタスクシステムの概念・狙いだって説明されたら俺は納得できるよ。
C言語以上の高級言語を使用＆32bit以上のCPUならこのシステム必要ないなとも言えそうだし、アンチ的にもOK
>>905 C++プログラマーにはろくなのがいないから、これでいいんだよ。
オブジェクト指向はリソースの管理がうまいだけで、それ以外はさっぱりだ。
オブジェクトごとにカプセル化しようという概念が既におかしい。
カプセル化は機能単位ですればよい。
つまり、一つのソースコードファイル内で閉じてればそれで問題ないんだよ。
生のオブジェクトを受け渡して、呼び出し側でゲッターやセッターを呼んでもらう設計は愚か。
あー、いちおう断っておくけど、オブジェクト指向が駄目と言ってるわけではないよ。
>>931 先割れスプーンとかショクシとか実際にあるもので例えればいいんじゃね？
ほんとうに気持ち悪いのはおまえだけ
それでオブジェクト指向をキチガイ扱いしてるのか
こうしてアセンブラ同士の仲良しクラブ（小学生発想）が生まれ
相手の話を聞き入れない
そして糖尿病になって
それで、屁理屈ばっかり言って子供や部下をないがしろにし
元はどうあれ、昨今のタスクシステムは糞設計でございます。
まだタスクシステムのメリットすらわからないキチガイがいるのかｗｗｗ
偏見と決め付けだけｗ もうお手上げのご様子ｗ
メリットすらわからないってどう見てもお前ゴミクズだろｗ
メリットの前にはシャンプーだよね
>>934 はシャンプーとリンスは別々に提供すべきって話だったのか
951 ：
名前は開発中のものです。 ：2009/09/19(土) 16:53:18 ID:xkwU29ud
>>935 pipes and filtersという表現をなるほどなーと思うのは自然なこと
cyclic executiveの長所とかぶるところは多いからな
ただデータフローは必ずしも一致するわけじゃないってこと
pipes and filtersの要素の繋がりは処理フローとデータフローを表してるが
ready queueとかfunction queueのそれは処理フローしか表してないからな
各タスクの扱うデータ（入出力）については各タスクで設定してる
あとタスク分割の方針も必ずしも一致するわけじゃない
pipes and filtersでは純粋に機能分割で再利用性を高めるが
cyclic executiveはプリエンプションなしのタスクによる
人力スケジューリングの仕組みでもあるから時間分割も考慮
しないといけない（場合がある）。各タスクの処理時間制限に
ひっかかってしまう場合ね。この場合の分割は必ずしも
再利用性と一致しない
例えば戦術情報を取得して意思決定を行ない隷下の部隊に指示を出すコマンダー
捜索・索敵モードのAIタスクは数～数十フレームにわたって処理を分ける
これは必ずしも機能分割と一致しない
どう考えても new tasksystem ◆9ycqcAuWxdGZ やんこいつ
953 ：
名前は開発中のものです。 ：2009/09/19(土) 18:00:51 ID:xkwU29ud
>>952 つまりセンスがない。観察力がない。視野が狭い。想像力がない。
アンチはおつむに糞がつまってるから嗅覚までおかしい。哀れである。
new tasksystem ◆9ycqcAuWxdGZはやねうらおレベルの
高度な知的生命体であり、全くどうでもいい
それよりお前はさっさとゲームを作れるようになれ。話はそれからだ
954 ：
名前は開発中のものです。 ：2009/09/19(土) 18:27:19 ID:Y9+sDnj3
> new tasksystem ◆9ycqcAuWxdGZはやねうらおレベルの
955 ：
名前は開発中のものです。 ：2009/09/19(土) 19:31:49 ID:xkwU29ud
つまりコニャック片手にコイーバをくわえてるような
また新たな電波システマーこないかな。
アンチタスク = ゲームも満足に作れない自称プログラマ ってことだね。
>>951 なんで"cyclic executive"の話題を出した
それはさておき"cyclic executive"ってハードリアルタイム用の実装手法でしょ？
ゲームプログラムはソフトリアルタイムだろうから厳密にその実装手法を使う必要が無い。
差が出てきて当然かと。
というか単にレトロなハードウェアが貧弱すぎて命令数単位で
CPUリソース管理しないといけないから手法改善してったら
結果的にcyclic executiveと似ちゃっただけなんじゃないの？
出発点は全然違うよ。きっと。
"pipes and filters"は泥臭い手法を取らざるを得ない状況をエレガントなもののように
言い表して現場のソフトウェア開発者の溜飲を下げることができる力があるが、
"cyclic executive"はソフトウェアをハードウェアの劣化版と見なす雰囲気が感じられる。
もしcyclic executiveの方が高等で高尚な概念だなんて言ったとしたら
ハード屋さんならいざしらず、ソフトウェア屋が聞いたらむかつくと思うが。
>>959 ねぇねぇ、このアンチは結局何が言いたいわけ？誰か解説して
>>961 １、"pipes and filters"について話している時に
なぜあなたは"cyclic executive"の話題を持ち出したのですか？
２、一応"pipes and filters"と"cyclic executive"が似ているかどうか考えてみたのですが
違うように思われます。
ところでなぜあなたは"cyclic executive"の話題を持ち出したのですか？
と言いたいのですが。
HSPさん、おいたが過ぎるのではないですか？
"このアンチ"も一応人間ですよ？ 割と傷つくんですが
キチガイアンチがキチガイHSPerを攻撃し始めました
>>962 は前々から本格的に頭おかしかった例の童貞アンチだろ
以前はアンチっていってももっとマトモなのがいたような気がするんだが…
印象操作はもう通用しない、と。
聞きたかったら金だしな
>>317 >enum MazeChip
>{
> Blank, // 通路
> Wall, // 壁
> Bomb, // 爆弾
>};
とありますが 爆弾は迷路のchipではないですよね？
>>965 まともな頭をもったアンチはとっくにアンチなんて卒業してるよ
>>206 残ってるのはこんなアンチだけ。
>タスクに有用性があるということを示したければ有用な条件で動く例を一つ出せば証明できる。
理解できなくてもいいから、早く証明してよ。
タスクシステムは～～に有用って結論出して、
>>972 だから違う反応してよ。
アンチは結局その反応しか出来ない、って
>>206 の主張の正しさの証明にしかなってないぞｗｗｗ
なんだ、ここにきて
>>4 に戻るのか。スレの回転業務、乙であります。
>>329 名前： new tasksystem ◆9ycqcAuWxdGZ [sage] 投稿日： 2009/08/27(木) 07:08:31 ID:T5IyzsGb
> きっちりまとめてCodeZineにでも投稿したほうがいいか？
> それならそうするが。
投稿して恥かくところはやく見せてくれよｗ
>>977 んじゃ、まず
>>2 の否定からしてごらん。技術的に。
それが終わったら過去スレで上がった利点の全ての否定だ。
それを全て否定してもまだタスクシステムの否定にはならんけど、アンチがんばれ！ww
使用条件を限定しない限りアンチに勝ち目は無いよ。
「ある種の条件ならタスクシステムも有用」ってのを認めたらアンチ卒業なんだがなぁｗｗ
勝ち負けの話にしたがってるのか、相当視野が狭まってしまっているのか。
>>979 普通、方法の優劣は目的や仕様によって変わってくるんだけど
目的と仕様を明確にせずに優劣はつけられんわな。
でもアンチ君はそれを理解せずに「タスクシステムは無用」と主張するから
>>206 のようになるわけで。
> つまり、積極的に採用する理由はまったく見当たらない。
> アピールが足りないね。一言で言えるようなセールスポイントは無いのかな。
目的や仕様にかかわらずタスクシステムを積極的に採用しろ、なんて主張、過去スレにもどこにの
無いだろ？あったら出してくれ。ｗｗ
「魔法の杖は無い」ってことを理解できれば「タスクシステムは魔法の杖じゃない！だから無用だ！」
ってアンチは卒業できるんだよ。ｗｗｗ
>>978 俺にそんな義務は無い。
悪魔の証明って言うだろ。
証明義務があるのはタスクシステマー側。
このスレいままで見てきていまだにタスクシステムのメリットがわからないとか言ってる奴が池沼だろｗｗｗ
>目的と仕様を明確にせずに優劣はつけられんわな。
ここにきて裸の王様ごっこをはじめたタスクシステム使いさんは
>>934 の言うことに
ついてどう思ってるの？
>>979 みんなを納得させる？誰を納得させる必要があるって？
「ゲーム作ったことないボクはまだ納得できましぇん！許せない！」ってことでしょ
そんなクズまで納得させなくちゃならないならもう介護福祉ボランティアだなｗ
>>980 > 目的や仕様にかかわらずタスクシステムを積極的に採用しろ、なんて主張、過去スレにもどこにの
> 無いだろ？あったら出してくれ。ｗｗ
ムリヤリかお前は。
> 目的と仕様を明確にせずに優劣はつけられんわな。
そこは限定していいから。好きに限定していいから。
タスクシステムが最大に輝くように限定していいから。
この時はこんなにも有効ですよ、というのでいいから。
そのセールスポイントすら今は見えてないと思うが。
タスクシステムが最大に効果を発揮する時でさえ、
他の代替手段のほうがメリットを生むと見てる。俺は懐疑派だから。
>>981 どういう場合に有益なのか、何も証明されて無いじゃん。
>>985 同じこと。彼の脳内で前提としている仕様ではタスクシステムが役に立たないってのと
ある条件ではタスクシステムが役に立つって条件は矛盾しない。
でも彼にはそれがわからない。ただそれだけ。
>>988 >>2 のリンク先、ほんとにちゃんと読んだ？ｗｗｗ
>>986 > みんなを納得させる？誰を納得させる必要があるって？
(ヾﾉ･∀･`)ﾅｲﾅｲ もちろんそれは無いよ。何の義務も無い。
ただし、この議論の流れの上では、キミにとって権利だと思うが。
タスクシステムのよさを、ズドンと示して懐疑派を黙らせるチャンスだと思うが。
>>990 タスクシステムなんて単純な仕組み、特に良さを宣伝しようと思ってるやつはいないよ。
使える条件は限られるし色々デメリットもあるしな。
ただ魔法の杖扱いして勝手に「裏切られた！」って絶望して騒いでるアンチみたいなのが居ると
からかってやりたくなるだけさ、「お前ら馬鹿だな」ｗｗって。
なんだ、結局使えないんじゃん。
>>991 > 使える条件は限られるし色々デメリットもあるしな。
じゃあさらに言葉を絞って尋ねたい。
キミにとって、タスクシステムのメリットは一個で言うと何？
俺は、「シビアなリソースで若干の抽象化を得ること」だと見てるけど？
JAVAとかC#しか知らん素人プログラマが「ポインタなんて糞、リスト使えばいいのにこんなの使ってる
違うだろう。
なんか変なたとえ話はいりました～～
>>955 おｋ。キミの生の声を始めて聞けたきがする。
>>993 まぁ、そういう利点もあるわな。
実際、アーケードから組込みおもちゃから、色々なハードでやってりゃ嫌でもそーいうケースに出くわすし。
WindowsとかLinuxとか汎用機しか見たこと無いプログラマには理解不能な世界だろうけど。
1001 ：
１００１ ：
Over 1000 Thread このスレッドは１０００を超えました。