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

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

part7 http://pc11.2ch.net/test/read.cgi/gamedev/1241670786/
part6 http://pc11.2ch.net/test/read.cgi/gamedev/1238725539/
part5 http://pc11.2ch.net/test/read.cgi/gamedev/1234977661/
part4 http://pc11.2ch.net/test/read.cgi/gamedev/1233459490/
part3 http://pc11.2ch.net/test/read.cgi/gamedev/1226199100/
part2 http://pc11.2ch.net/test/read.cgi/gamedev/1196711513/
part1 http://pc11.2ch.net/test/read.cgi/gamedev/1173708588/


・タスクと呼ばれる実装は、非常に多岐に渡ります
　古典タスクシステムについての話題は「>>2」と明示してください
　そうでない場合はカスタム版であることを明示してください

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

古典タスクシステム（このスレでは「>>2」と呼ぶ）

White Paper - Programming
http://homepage3.nifty.com/moha/programming.html

タスクシステム
http://www5f.biglobe.ne.jp/~kenmo/program/task/task.html

CodeZine：本格的なシューティングゲームを実現するタスクシステム（タスクシステム，シューティング，ゲーム）
http://codezine.jp/a/article.aspx?aid=297

Logician Lord　…　【コンピュータゲームのからくり】
※ウェブアーカイブのキャッシュ
http://web.archive.org/web/20041009222313/www.hh.iij4u.or.jp/~peto/Games/games_top.html

タスクシステムのご先祖の「ジョブコン」は
http://game.2ch.net/gamedev/kako/1006/10061/1006184421.html の 810

裸の王様スレ

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でタスクシステムがサポートされるらしい。

>>9
前スレでも出てたよ、そのネタ。

> 909 名前：名前は開発中のものです。[sage] 投稿日：2009/08/14(金) 06:57:44 ID:Q9Cqsnjk
> C#4.0でタスクシステムがサポートされる。
> C# taskでくぐってみろ。
>
> 910 名前：名前は開発中のものです。[sage] 投稿日：2009/08/14(金) 11:51:38 ID:qmLpRBa/
> http://www.google.co.jp/search?q=System.Threading.Tasks
> これか。
>
> http://www.danielmoth.com/Blog/2008/12/introducing-new-task-type.html
> 処理単位ごとに全部 System.Threading.Thread 作ってたらメモリ消費や OS による
> スケジューリングのオーバーヘッドが問題になる。
> ↓
> System.Threading.ThreadPool で解決。でもそれだけじゃ終了待ちとかキャンセルとか
> 自分で実装する必要があって、いまひとつ使いにくい。
> ↓
> 新しいラッパー System.Threading.Tasks を作って解決。
>
>
> メリットとか役割とか明確ですばらしいね。
> それにひきかえゲーム屋のタスクシステムときたら、メリットひとつ挙げられやしない。

C#はゲームに向いてないんじゃないのか

>10
メリット厨は権威に弱いのかな？

「タスクシステム」と呼ぶなよ

今度は『.NET4.0のTPLもタスクシステム！』か。大胆な●●認定を始めたもんだねぇ
それを言うならまずOpenMPやTBBもタスクシステム認定しないと辻褄があわないねぇ
なのになぜあえてTPLなんだろうねぇ。クルクルパーの発想はいつも斜め上杉て面白いねぇ

一生懸命背伸びしてハッタリをかまし、実態の異なるナウいものを引っ張り出してはいちいち
タスクシステム呼ばわり＆事大する必要ないんだけどねぇ。クルクルパーは印象操作に弱いから
タスクシステム（>>2）がバカにされるとTPLとかに縋りたくなるんだろうねぇ

>>10
出てたとは。
落ちてたんで気付かなかった。

>>14 が必死すぎて痛い件

スレ変わってまで番号コテとかw

>>9、>>15
逐次計算すること前提に作られたバカでも分かる簡素な仕組みと
並列計算を前提とする仕組みではまるで正反対のものだよ

タスクという単語が登場するだけでタスクシステムとは中身まるで違う
タスクという言葉を擁護することはタスクシステムを擁護することにはならないし
タスクという言葉を否定することはタスクシステムを否定することにはならないんだよ

それを理解できてなかったファイルシステム君は前スレでアンチの振りしてタスクを否定してたね

> 694 名前：名前は開発中のものです。 投稿日：2009/07/27(月) 23:15:40 CpdnwPwc
> 処理の単位なんて発想が馬鹿げてるんだ。処理に単位も糞もあるかよ。
> 処理はCで言うところの関数なわけで、必要に応じて呼び出すまで。
> 古い価値観は脱ぎ捨てようぜ。

タスクシステムを否定するつもりが何故か処理単位（タスク）を否定してやんの
上司や先輩から言われるがまま鵜呑み・天下り式に何かを使い続けてたから
自分が一体何をやってきたのか、何故そうしてきたのかを理解してないんだろう
だから足元がグラグラだし処理単位（タスク）を否定してしまったりする

前>>909や君も基本的にファイルシステム君と同じだと思うよ

と、いうことにしたいんですね？：）

タスクが使われてるからタスクシステムなんて寝言ほざいていいのは小学生までだな
タスクシステムを拡大解釈したがるバカに付き合うと終いには
「この世界の仕組みこそがタスクシステムなんだよ」「な、（以下略）」とか
言い始めるぜ

バックエンドの構造は単純にする。これがタスクシステマーのドクトリンなんだよ

タスクシステムのタスクってのは割り込みハンドラとセットで語られるような低レベルのもの
OSなしのプラットフォームでドライバやモニターを全て自前で用意してた。そういう時代のもの。
タスクシステムってのはハードを占有しハードの全てをコントロールするモニタープログラム、
あるいはその中でCPUリソースを配当するモジュール。その中で定義された処理単位がタスク。
serial task。これを非プリエンプティブにスケジューリングして更新。周期駆動。バッチ処理。

ゲームプログラマは天邪鬼。そして気まぐれ。自前で複雑なタスクコントローラを用意しても
みんなでメンテしようなんていう発想は希薄。というかいつ辞めるか分からない他人の作った
複雑怪奇なシステムなんて気持ち悪くておっかなくて誰も使いたがらない。そういう荒んだ
現場は今でも珍しくない。余計な機能なんて誰も欲しがらない。アクターモデルによるイベント
駆動型のシステムなんて論外。だから>>2みたいな単純な仕組み、周期的に巡回UPDATE
るだけの自称システムしか共有できなかった。コンセンサスが形成できなかった

みんな自分が大好き。お山の大将。俺が俺が。俺のシステムが一番。そういうものの
共通項を探っていくと>>2くらいしか残らない

タスクシステム（>>2）はparallel computingなんて全く眼中に無いな
そんなもんサポートし始めたら排他制御やら何やらで一気に複雑化。
デバッグも複雑化。並列処理なんて後回し。必要に迫られたら
アドホックな付け焼刃な拡張を加えて対応。そういうもの

言葉尻に囚われて、概念的なものを見過ごしてる人たち多すぎwww

×周期的に巡回UPDATEるだけの自称システムしか共有できなかった
○周期的に巡回UPDATEするだけの自称システムくらいしか認識を共有できなかった

>20
ヒドイ環境で仕事してるんだなw

いわゆる底辺ってやつ？

タスクを否定するアンチは阿呆。これは確定。
TPLやMT Frameworkをタスクシステムとか抜かしてホルホルしてるタスカーは
半島民族。これも確定

適当に書きなぐった後に気付いたがコンセンサスが形成できないって
かなり腹痛が痛い話だね。まぁいいか

>>24
このご時世、底辺のヒドイ環境でもなければタスクシステム（>>2）に
スポットライトが当たることはない。周期的に何かのコレクションの
要素を巡回してUPDATE。そんだけ。それ以上もそれ以下もない。
通常なら巨大なミドルウェアの中に埋没し溶けてなくなってしまうような
お話だ。これにスポットライトを当てるってのは一次精度の陽的
スキームで多体系の運動の時間発展をシミュレートする行為に
スポットライトを当てるくらいに退屈な話だよ

引数君とかメリット君が常に嘲笑されているのはそれを理解してる様子が
微塵も感じられないからだろうな。ゲームが作れないクズ、つまり
タスクシステマー以下だと思われてんだからナメられて当然てこと

ナメられたくなかったら頭使ってタスクシステムを否定してみろってこった

裸の王様の見えない服にまた迫がついたのか？（失笑ｗ

>>18
で、なんでタスクシステム＝ファイルシステムなんだい？
そういうことにしたいんだろう？さっさと作文書きなよ：D

前スレでリストを実装できないstl使いの話があったが・・・
最近の新人はデザインパターンとか、色々勉強はしてるんだが
それら教科書に載ってる手法だけを組み合わせることがプログラムを作ること、
と考えてる節があるんだよね・・・

ゲームプログラムみたいな歴史の浅い分野では理論体系化されて摘出された知識なんて
全体のごく一部でしかなく、体で覚えろ見て盗め、って範囲がほとんどなんだが、
これら教科書に無い技術は認められずに
「そんな技術教科書にありません！教科書に載ってる正しい権威のある技術だけ使ってください！」
という考えの子が増えてるんだよね。

で、古株のプログラマも自分の技術をわざわざ文章化して教えるなんて面倒なことはしないし、
特にタスクシステムなんて古典的なものはCEDECみたいな場に出ることは絶対無いから
技術の断絶が起きてる。

まぁ、新人、特にゲーム専門学校みたいな所でプログラムやったこと無い人間を１〜２年で職場に出すとしたら
デザインパターンとかシェーダーとか、受けの良さそうな知識だけ前提も教えずに使い方だけ詰め込むのは
限られた時間では仕方ないのかも、と思うが。

先人の知恵の結晶は当然知っているべきなんだが、その結晶にたどり着く過程や結晶になる前の知識を
吸収できるだけの柔軟性がないと、末路は数年で使い物にならない使い捨てプログラマだ・・・

うわぁ・・・。ほんとに、「馬鹿には理解できない」と言い続けるしかないんだね。

裸の王様に出てくる仕立て屋ってなかなかの根性だよなｗ

>>7
なるほどな…
それでいつまでたってもメリットが理解できないアンチは最後に「火なんて幻」としか考えられなくなるわけかｗｗｗ

>>24
そんな環境はいっぱいある。
ミリオンタイトルのソースを一度見て見ればあまりの素晴らしさにめまいがするぞ。
美しいコードが面白いゲームを生み出すわけじゃないからな…

>>26
タスクシステムが脚光を浴びないのはあまりにも基本中の基本だからだろ。
双方向リストに関数ポインタ乗っけるだけでそれっぽいのができちゃうわけだから。
あとはdone()でもabone()でも巡回する奴を作ったり、速度を重視してアロケータもくっつけてみたり、etc。

引数君が嘲笑されるのはベクトルが違うから。
引数君：書き換えが危険？→引数を増やす
普通：アロー演算子書くのが面倒→構造体を使わない→引数が増える

だからメリットを感じないｗ

天才プログラマー要製ギプス
http://www.sun-inet.or.jp/~yaneurao/intensive/ggg/log1.html

>私が考える一番エレガントな方法とは、少なくともキャラクターは自立性が有ることです。例えば、
>　　　　new CMissile;
>とすればミサイルが生成され、あとはメインのプログラムからは、ミサイルについて意識しなくても済むような設計が理想です。

自立性があるのは結構だが、
最終的にはゲームとして成り立てるためにシステマティックに振舞ってもらわないと困るわけで。

一旦、個を確立させといて、あとから集団として意味づけするのは、
どう考えても2度手間だよな。

こういうくだらないこと書く人に限って
実際にはゲーム作れなかったりするんだよね。
ゲーム作ったって証拠も出さないし。
信者もアンチも作品出して優劣決めろよな。

そもそも、キャラクタの自立性を確立するのはとても大変なこと。
やねうらおも自分で言ってる。

>たとえば、ホーミング弾にはＳＥが存在するとしましょう。
>前回、話したようにホーミング弾を担うクラスは自立性のあるクラスです。
>ホーミング弾が生成された瞬間にＳＥは鳴らないといけませんから、
>ホーミング弾のコンストラクタは、soundを読み込み、再生しようとします。
>すると、以下のような問題が浮上します。
>１．生成された瞬間にサウンドをファイルから読み込んでいたのではリアルタイム性が損なわれる

キャラクタの自立なんて意味の無いこと実現しようとするから苦労する。
しかも、数々の困難を乗り越えて、やっとこさっとこキャラクタの自立性を確立したところで、
結局はゲームとしてシステマティックに振舞わせるために、
個々の自立キャラクタに集団としての意味づけをしなければならない。

もうやってること意味わからないってレベルじゃねーぞ。

自立性のあるキャラクタ云々がそもそもの間違い。
発想の一番最初から既に間違っている。
なので、どこまで行ってもうまく行かない。
何にもならない。無駄。

>私が考える一番エレガントな方法とは、「少なくとも」キャラクターは自立性が有ることです
↑キャラクタの自立性が発想の根本な人の例。
↑キャラクタには少なくとも自立性がなきゃ話にならないらしいです。
↑かわいそうな人です。

そもそも、キャラクタを自立させることが本当に可能なのかという問題もある。
先の>>36の問題をやねうらおがどう解決したのか。
彼は、SEのロードはSEManagerにまかせて、
キャラクタからはSEの番号を指定して再生してもらう方針で難を逃れた。
しかし、これではたしてキャラクタが自立していると胸を張って言えるのかどうか。
自立キャラクタ単体で解決できない問題を〜Managaerを作ってそっちに任せるという方針だと、
プログラムはいずれ〜Managerだらけになり、しかも、自慢の自立キャラクタは〜Managerに
依存しまくりの何がやりたかったのか意味不明状態に陥りそうだが、どうだろう。
また、そこまでして自立キャラクタを作る必要はあるのか。

仕様が明確になってないのをむりやりプログラムで解決しようとするからなぁ

>>38
引数君と同じ考え方だね。
stdoutやheapが使えないタイプ？

まーたやねうらおの自分弄りが始まったのか。本当に気持ち悪いやつだ
10年近く前の己の戯言を何度も引っ張り出してまで話題にしてほしいのか？

＞自立性のあるキャラクタ云々がそもそもの間違い。
＞発想の一番最初から既に間違っている。
＞なので、どこまで行ってもうまく行かない。
＞何にもならない。無駄。

自分で分かってんじゃん。その通り
自立性のあるキャラクタ云々とタスクシステムは全く関係ない
どっかのPCエロゲプログラマが勝手に何か勘違いして自立性のあるキャラがー
とかわけの分からないことを言い出しただけの話。でっていう

そもそも自立性のあるキャラってなんだ。お前自信意味分かってるの？
自律的なキャラクタなの？結合度が弱いという話なの？
近代がどうのとかやねうらおは特徴的な日本語を使うが本人はそれに気付いてない
その特徴に気付いてないからあちこちで平気で使う

キャラクタを自立させるという設計方針でゲームを作ると、
キャラクタを表示したり、移動させたり、マップを表示したりといった初期段階まではうまく行く。
なぜなら、自立キャラクタは自分自身だけで出来る処理に対してはめっぽう強いから。
ただ、他のキャラクタとかかわりを持たなければならない処理が増えてくる段階に入ると、
急に開発効率が落ちていく。(タスクシステム信者の性質と同じだな)
ゲームがキャラクタ同士が関わって初めて奥深くなるものだということを考えると、
自立キャラクタという考え方はひどく矛盾している。
そもそも、キャラクタが自立することに喜びを覚えるってのは、人としてセンスが悪いというかなんと言うか。
自分が自立出来て無いことへの裏返しなのかなんなのか、その辺は良く分からんが。

まぁ、どんなやり方でも、途中まではそれなりにうまく行くという良い見本だな。
ただ、先は無いぞ、継続できないぞ、袋小路だぞ、と。
某やねうらおの人生も、なんかそんな感じするでしょ。なんとなくなんとなく。

簡単に言うと、俺はやねうらおじゃ無いのに、
平気で本人特定してくるタスクシステム信者はやっぱり考え方が変だということ。
悲しいことに、2chでのたったこれだけのやり取りの中にすら、信者の精神のおかしさは表れてしまう。
何やらしても駄目ってことでもある。

結局、要は、何がどうなっているかというと、つまりはセンスが悪い。
短い物差しと狭い価値基準で物事を捉えるから、
赤の他人が同一人物に見えたりしてくる。そこが問題。

>>42
> ただ、他のキャラクタとかかわりを持たなければならない処理が増えてくる段階に入ると、
ほとんどのゲームではかかわりって言ってもコリジョンとサーチぐらいで必要十分な気がするが
そんな多種多様な関係が必要になるケースって何を想定してるんだろうなぁ…
チームワークで動くAIとかか？

具体例プリーズ

具体的に言うと、キャラクタ同士で連携をとるようになってくると、
とたんに処理の順番が問題になってくる。
今、タスクAとタスクBがあって、
タスクA::処理1→タスクB::処理1→タスクA::処理2　の順番で処理をしなければならないとする。
そうすると、タスクに据え付いた一つのupdate関数だけで対処するのは厳しい。
また、updateにフェーズを付けたとしても、
今度は、プログラマが格タスクの何フェーズ目で何の処理が走るかを把握して、
格タスクに協調的に振舞ってもらえるように段取りをしなくてはならない。
本来なら、
タスクA::処理1();
タスクB::処理1();
タスクA::処理2();
と書けば済む話なのに。

訂正：　格→各　(眠い・・・)

各タスク様に協調的に振舞ってもらうために、こちらであれこれ御膳立てをし、
しかもその実行結果がゲームとして成り立っていなければならないなんて、
無駄な努力だとは思わないか？
俺らは何かのシミュレーションソフトを作っているわけではないんだぞぅ。

なんらかの処理を記述するのなら、処理させたい順番にそのままダラダラ書けるのが理想(というか普通)だろう。
それをわざわざ細切れにして、わけの分からない実行順番で制御しようとするのは、
単純に「変」だろ。愚行だと思うね、方針的に。
変なものを変なまま放置しておいて、そのまま突き進んでも結局どこかで付けがくる。
面白おかしくどんどん歪んでいく。
それを補おうとして珍妙な仕組みを用意したところで、根本的に変なものはどこまで行っても変なまま。
それが袋小路ということ。

>>45
関係の種類じゃなく順番だけの問題なのね。

プライオリティとかスナップショットとかタスク使う解決方法はいろいろあるけど
それ使うより全種類順番に並べた方が良いという考え方ね。

敵の種類が100種類ぐらいいて、ステージや条件によってそのうち何種類かのインスタンスが
生成され、倒されると削除、みたいなケースをそのやり方で作ると…とても理想的なコードにゃならんと思うが。

キャラクタって概念がよくわかんないんだけど。
要するにクラスのことなんじゃないの？

>>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ってのが既にキモいんだが。
処理は、書いた順に実行されるのが一番シンプルで良いだろうに。
なぜ、タスク間のくだらないチェーンなんぞで処理の順番を制御しようという発想が出てくるのか、
理解に苦しむ。本当にその必要があるのか、今一度問いたい。

それでも処理の順序を動的に変更したい場合はあると思うよ。
たとえば、各キャラクタの座標系に親子関係がある場合などな。
でも、そんな場合でも、キャラクタに据えついた関数の呼び出し順を動的にするんじゃなくて、
キャラクタが列挙される順番を動的にすべきだろう。

>>51
まーた
『ボクのエターナルフォースブリザードシステムはそんなもんじゃない。もっとすごい！』
が始まったのか。永遠の小学生だな

>54
> 『ボクのエターナルフォースブリザードシステムはそんなもんじゃない。もっとすごい！』
自己紹介乙w
さすがに馬鹿は思考短絡してて分かりやすいなw

>2程度しか思いつかなくて『タスクシステムってスゲー』なんて言ってる、あるいは>2程度しか
思いつかなくて『タスクシステムなんてダメダメw』なんて言ってる、どっちも同レベルの馬鹿だw

それが集まって職場を成しているのならなおさら。

ちょっとは自分でモノ考えて作れよw

道具が使いにくければ工夫するなり改良するなりすれば？
もっといいアイデアと技術があるなら、とっとと刷新すれば？
アタマ使えよ、もっと。

>>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程度までレベルを下げればいくらアンチでも理解できるだろう、と思ったんだろうけど
根本的に次元が違うんだって。アンチは。

「石？なんかマッチと全然関係ないこと言い出したなｗ」ってなるに決まってるだろ。
関係が理解できるだけの頭があればアンチなんて卒業してるはずなんだから・・・

>>61
裸の王様の仕立て屋という比喩がいまいちよくわからないのだが。
今一度説明して頂けないだろうか？

>61
共通知識として、どのあたりまで低いレベルを想定しているのかよくワカランな。
そんな>61のような馬鹿には『自己研鑽』という言葉を贈ろう。

>57
オマエは別な意味で馬鹿だな。

>タスク自体はコンテナでしかない。
タスクがコンテナな時点で終わってるって事。
タスクはどっちかって言うと処理なのに、データ主体でコンテナとか言い出す時点でもう駄目だろう。

それ以外の部分については論点がずれすぎてて突っ込む気になれない。

キャンプ行くのにマッチを持っていった方が良いかどうか話し合ってるときに、
火打石の説明しだすやつがいたら、
「石？なんかマッチと全然関係ないこと言い出したなｗ」
と普通なるわな。

もともと一連の流れの処理を、
わざわざタスクに細切れにして実行順番割り振って処理順をやりくりする
必要があるのかを話し合っているときに、
for文の話しだすやつがいたら、
「全然関係ないこと言い出したなw」
と普通なるわな。

結局、要は、何がどうなっているかというと、つまりはセンスが無い。
短い物差しと狭い価値基準で物事を捉えるから、
全然関係ない話題が同じものに見えたりしてくる。そこが問題。
>>42でも忠告しておいたのだがな。

人並みのセンスすら有していないから、何聞いても、馬の耳に念仏、立て板に水。
彼らの洗脳が解けることは永遠に無いのだろう。

訂正　>>42→>>43

>>65
処理と言うか、描画処理だけじゃないの？
うちはコンテナに乗せたデータを描画処理にかける部分と、
コンテナに乗せたデータを操作する部分を独立させてるけど。

そうなると内部的にタスクっぽいけど外部的にタスクに見えないがな。

>タスクはどっちかって言うと処理
タスクは処理だけでもデータだけでもないのでは
両方あってタスクなんじゃないの

>>63
>>4

>>66
>>7

>>66
> キャンプ行くのにマッチを持っていった方が良いかどうか話し合ってるときに、
「マッチ？なにそれメリット何？火って何？」
ってアンチがキャンプなんて行けるのかねｗｗｗ

自分が全然関係ない話をしている自覚はあるんだろうか？

>>64
> オマエは別な意味で馬鹿だな。
別な意味ってどんな意味？ｗｗ
良い意味で馬鹿、みたいな？ｗｗｗ

このスレも男女論の「結婚のメリット」スレと同じで不毛な議論エンドレスに続けてるねぇ…

既婚者＝タスカー
未婚者＝アンチ

の永遠に終わらない罵りあい…

不毛な議論を隔離するためのスレですから。

順調に機能してますよ。

>タスクは処理だけでもデータだけでもないのでは
>両方あってタスクなんじゃないの

この時点で既に終わってるってこと。
自分で言ってておかしいとは思わないのか？
何故、処理とデータを一緒くたに制御する必要がある？
これはタスクシステムの根本的な過ちで、
ここから色々な不満が派生している。
でも根本を正すと、タスクシステムでなくなっちゃうという。

>>77
> 何故、処理とデータを一緒くたに制御する必要がある？

OSのprocessにしても、データとプログラムと両方が同じprocess空間上に置かれてますが？

OSのprocessは実行順番で処理順を制御したりしませんが。
基本的にprocess間で協調して動作していく必要もありませんが。
というか、あなたからはOSのprocessとタスクシステムのタスクが同様なものに見えるの？
俺からは両者は単に構造が似てるってだけで、違った目的を持った別物に見えるが。
それにそもそも俺は、処理ではなくて、処理の「制御」について言及しているのだが。
そういう目に見えない抽象概念は理解できませんか、そうですか。

結局、要は、何がどうなっているかというと、つまりはセンスが無い。
短い物差しと狭い価値基準で物事を捉えるから、
全然関係ない物が同じものに見えたりしてくる。そこが問題。
>>43と>>66でも忠告しておいたのだがな。

そもそも、OSのprocessがああいう形をしているのは、
アプリケーション開発者にカーネルを自由に書き換えさせるわけにはいかないから、
仕方なくああなってるだけなのだが。

メインループを直接書き換えることの出来るゲーム開発には関係ない話。

もとより関係ない話なのに、無理やり同じものとみなして、
意味を良く考えずに模範して、いらぬ苦労をするといういつもの流れ。

>>77
実装の方法がいろいろあるからまずいんじゃない？
それと相まって実装方法ごとに信者がいるとしか。

実装方法がいろいろあってもかまわないのだが、
データ構造と制御構造を一緒くたにした時点で、THE END。

では、何でそんなバカみたいなことをするやつが居るのかというと、
・キャラクタを自立させたかった(某や○うらお　左巻きの人)
・その必要も無いのに、OSを模範してみた(センス無し夫　背伸びしたがりの模範厨)
・若気の至り
そんなところだろう。

変な話、別々に実装したほうがまだマシという話も。

・制御システム←(単なる関数ポインタのリスト。データは持たない)
・データシステム←(単なるデータ検索エンジン。制御には関与しない)

データシステムの方はそれなりに便利そうだが、制御システムはどう考えても要らないよな。
だって、普通に関数を呼び出したい順に書けばいいだけだから。

頭の中だけでプログラムの動きがほとんどシュミレートできるレベルの
ベテランプログラマじゃないなら、シーケンシャルな記述の方が安全でメリットあるだろう。

新人プログラマがタスクシステム使ったコードなんて見ても
デバッガでコード追えませんって涙目になるのは目に見えてるし…

>>84
制御システムがあるから楽に扱えるんじゃん。
利用してる側からだとそのシステムの中身を意識しなくてもよく、
それを扱うための関数だけ知っていれば描画から何まで自動的にやってくれる。
これが利点だよ。

>>45
タスクシステムのタスクとはシステム内部の実行待ちキューに投げ込む処理単位（タスク）のことだぞ。

> 具体的に言うと、キャラクタ同士で連携をとるようになってくると、
> とたんに処理の順番が問題になってくる。

処理の順番がある　→　つまり複数の処理ステップがある　→　つまり複数のタスクがある
ということ。タスクシステムはレディキューに突っ込まれたタスクを順次処理する。問題は無い

> 今、タスクAとタスクBがあって、
> タスクA::処理1→タスクB::処理1→タスクA::処理2　の順番で処理をしなければならないとする。

この時点で既におかしい。
タスクシステムのタスクとはシステム内部の実行待ちキューに投げ込む処理単位（タスク）のことだぞ。
タスク＝OBJとかタスク＝キャラクタではない。これを否定する自称タスクシステムは何かが狂っている
独自進化の果てに分け分からなくなったミュータント

>>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があって
　

だったら普通に関数並べれば良いだろ。
タスクA();
タスクB();
タスクC();
で問題ないだろ。なぜ実行待ちキューなんかで処理を遅延させる必要があるんだ？

知ってのとおり、関数呼び出しはスタックになってる。
では、なぜキューは無いのかというと、ノイマン型コンピュータの実行の基本はFIFOだから、
特別な仕組みを用意しなくても、キューなんだよ。
だから、わざわざ実行待ちキューとか作る意味無いんだ。

>>90
ゲーム起動から終了まで一貫して
タスクA→タスクB→タスクC
こういう手続きと確定しているならばひとつのタスクにすればいい
わざわざ別の処理単位に分ける必要はなかろ

この処理が常時走ってるならタスクにする必要もなかろ

>90
物量補完のために雇った下請け連中に、システム部分まで触られたくないからだよ。
いわゆるタスク（ウチはタスクとは言わないけど）の制限内でモノを作ってもらうのが原則。

単体テストもロクにせずバグ込みで一次納品してくるところには、次から仕事まわさない。

>こういう手続きと確定しているならばひとつのタスクにすればいい

つまり、処理の順番が動的に変わることを想定しているのだろうが、
だったら、>>53だ。
それに、処理の順番なんてそうそう変動するものではないから、
ポイントポイントで局所的に対応しても事足りるだろう。

>>90
処理は遅延しないよ。
キューの中にあるタスクがすべて実行される。
だから、関数を並べるのと大差ない。

優先順位に注意しつつ普通に関数を並べるか、
動的にタスクを追加したうえで優先順位を付けるかの違いしかない。

>>91
屁理屈に対して屁理屈で返させて頂くけれども、
それだと実行待ちキューを作る必要性について否定できていないけど。

パンはパン屋で作るから自宅でパンを焼く必要はないって言ってるようなもん。
それを応用するのはこっちの勝手だろｗ

>>93
その理論だったら、ゲーム以外のもの作ってるプロジェクトはどうやってるんだって話になる。
プロジェクト管理にタスクシステムが便利だって言うんなら、アプリプログラマ達にも教えてあげたら？

>>95
>処理は遅延しないよ。

遅延するに決まってるだろ。だってキュー使ってるんだから。
遅延しないのは、スタック、つまり関数呼び出しだ。
関数呼び出しは呼び出した瞬間に関数の処理が開始される。
キュー使うと、登録から実行までに遅延が生じる。
といか、遅延を生じさせるためにキューはあるわけで、
それ以外の使い方してるのなら間違ってる。

>優先順位に注意しつつ普通に関数を並べるか、
>動的にタスクを追加したうえで優先順位を付けるかの違いしかない。

だったら普通に書けよっておもうね。
いちいち処理順番割り振って処理順を制御とか、意味無いと思うね。

でもお前らの話聞いてると、どうもキューというより、ただのリストのようだな。

かなり昔の話だがプログラマの新人研修でSTG作れって課題出したことがあったが
特に教えたわけじゃないのにほとんどの新人がタスクシステムと同じような管理処理で
動かしてたけどな。

弾とか敵とか複数オブジェが動的に生成消滅をする必要のあるケースでは、だいたい
誰が作ってもタスクシステムみたいな管理処理を作るのが”普通”なんじゃないか？

ごく一部、インベーダークラスのゲームを出してきた人たちはベタ書きしてたけど…
彼らは正直プログラマとしての腕前は微妙だった。

>>94
>>53
> それでも処理の順序を動的に変更したい場合はあると思うよ。
> たとえば、各キャラクタの座標系に親子関係がある場合などな。
> でも、そんな場合でも、キャラクタに据えついた関数の呼び出し順を動的にするんじゃなくて、
> キャラクタが列挙される順番を動的にすべきだろう。

まずはっきりさせておくが
座標系（フレーム）の親子関係なんざユーザー側で作り出した勝手な都合であり
タスクシステムの実行待ちキューが関知するお話ではない
座標系の親子関係を表すのはタスクシステムの実行待ちキューではなく
例えばシーングラフの中のツリー構造。処理するフレーム・処理する順序を
決定するのはシーングラフのトラバーサ

これを否定する自称タスクシステムは何かが狂ってる。欲張りすぎ、でしゃばりすぎ。
タスク＝OBJという勝手な固定観念に縛られ独自進化を遂げた分けの分からない
ミュータントを使ってるとタスク＝フレーム（座標系）みたいなお話になってしまう

やねうらお状態ってやつだ

×　シーングラフの中のツリー構造
○　シーングラフのツリー構造

>>100
いや、お前の言いたいことは分かるが、その主張は俺も>>82とかで述べてるので。

>タスクシステムの実行待ちキュー
ただの処理リストの癖に。
ところで、プログラムのことプログラムリストって言うでしょ。
リストを重複して持つなんて無意味だね。

>>97
＞登録の遅延
ポインタの移し替えだけなので10行以内に落とせる。
登録作業もnewを使わなければ誤差にすらならない。

＞遅延を生じさせるためにキューはあるわけで
じゃあ、STLのキューは遅延を生じさせるためのキューなの？
ベル研究所とANSI/ISOは間違ってることでOK？

＞だったら普通に書けよっておもうね。
書いてあるよ。クラスの中に。

>>98
リストだよね。
なんでキューになっちゃったんだろorz

>>2の
CodeZine：本格的なシューティングゲームを実現するタスクシステム（タスクシステム，シューティング，ゲーム）
http://codezine.jp/a/article.aspx?aid=297

上以外で、お勧めのサンプルあるサイトない？

タスク＝処理関数ポインタ＋ワークエリア　　　とある
それに加えて、複数のタスクを連結リストとして管理するために前後のタスクへのポインタを持つんだとさ

>>103
何分けのわからないこといってるんだよ。
std::queue<void (*)()> task_queue;
task_queue.push( func ); //登録
・・・//実行まで遅延
while( queue.empty() )
{ task_queue.front()(); task_queue.pop(); }　//実行

・タスク＝処理関数ポインタ＋ワークエリア
　→制御構造とデータ構造をごったにしている時点で糞。
・タスク＝処理関数ポインタ
　→プログラム自体が既に処理のリスト。
　　動的に処理リストを生成する必要が本当にあるのか。
・タスク＝ワークエリア(データ)
　→タスクという名前がおかしい。
・タスク＝無能下請けを封じ込めるための檻。
　→他の方法考えろ。

訂正：　while( queue.empty() )　→　while( !queue.empty() )

>>103
あと、多分だけど、>>100　はタスクシステムを処理実行の遅延目的で使ってる。
トラバースして処理を一旦バッファに蓄え、最適化した上で実行するためだろう。
CPUのアウトオブオーダーのような感じ。
制御目的でなく、最適化目的なので、こういうのは個人的にOKかな。

ただ、それをタスクシステムと呼ぶのは個性的過ぎると思うが。
まぁ、煽りの一種だろう。

制御は１回きりじゃなく何回も繰り返すんだからリストに追加させるのが普通だろ
実行順は実装の仕方にもよるが

void update()
{
　　//↓何回も繰り返す処理のリスト
　　update_player();
　　update_camera();
　　・・・
}

int main()
{
　　for(;;)　//ゲームのメインループ
　　{
　　　　update();
　　}
}

>>106
そういう意味か。ごめんね。
実行速度のこと言ってるのかと思ったｗ
あとキューも自分で言っておきながら間違ってた。
タスクはキューじゃない。面倒くさいことさせて申し訳ない。

一応確認しておくけど、
タスクシステムはオブジェクトが持つ描画関数をタスクの中に保持し、
適当なタイミングでタスクごとに優先順位を考慮しながら描画する。
こういう認識をうちはしてるけど、君はおｋ？

訂正
タスクシステムはオブジェクトが持つ描画関数をタスクの中に保持し、
↓
タスクシステムはタスクのリストであり、
オブジェクトが持つ描画関数をタスクの中に保持し、

>>113
いや、いろんな人が居るから、>>107　という認識。

オブジェクト１つ１つをそれぞれタスクに割り当てれば
それぞれの情報（座標など）とそれぞれの動き（実行関数）が必要だから
ワークエリア、処理関数ポインタ共々必要でしょ

面倒だから、俺のやり方を紹介。

//↓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
馬鹿か？　馬鹿だろw

どんなソフトも同じ作り方で通用すると思ってるのか？
適材適所って知ってるか？

>>121
いや…タスク自体に持たせてあるだろ。
古典的なタスクシステムでは必ずと言っていいほど持っていると思うが。

タスク基底クラス、普通はこうなってないか？

class ITask
{
public:
　int priority;
　virtual ~ITask();
}

>>107
＞制御構造とデータ構造をごったにしている時点で糞
クライアント側から煩わしい処理を隠すため。
描画、移動、当たり判定処理などはクライアントに見せる必要はない。

＞動的に処理リストを生成する必要が本当にあるのか
一番顕著なのがSTG。敵キャラクターが大量の弾を発生させるとき。
他にもレベルデザインに特化させるため、処理順という概念を無くすため。
（要するに、データ入力やキャラクターの構築をし易くするためってことだな）

＞タスクという名前がおかしい
慣習だから仕方ない。

>>115
更新忘れて偉い前後してる。
けど眠いからもう寝る。

タスクシステムは簡単すぐるので技術的な話題はない
だいいちどうやってタスクシステムでＦＰＳを管理するんだ？
Windowsの設計思想にそぐわない

>>123
その古典的なタスクシステムだと、

> タスクA::処理1→タスクB::処理1→タスクA::処理2　の順番で処理をしなければならないとする。
> そうすると、タスクに据え付いた一つのupdate関数だけで対処するのは厳しい。

は実現できない。

タスクAの処理1をした後に、タスクBの処理をし、もう一度タスクAに立ち返り、
今度はタスクBの処理が終わってからでないと実行できなかった処理2を実行する。
こういった動作は、>>2で示されるような古典的タスクシステムでは対応できない。
なぜなら、priority(というかorderが適切だろJK)が一種類しかないから。

一方タスクシステムを使わないで書くと、
タスクA.処理1();
タスクB.処理();
タスクA.処理2();
たったこれだけのこと。

たったこんだけの制御すらままならない、それが古典的タスクシステム。

>113
> タスクシステムはオブジェクトが持つ描画関数をタスクの中に保持し、
> 適当なタイミングでタスクごとに優先順位を考慮しながら描画する。
> こういう認識をうちはしてるけど、君はおｋ？

大洗海水浴場w

タスク処理2をタスクCに分けて
タスクA→タスクB→タスクCじゃ駄目なの？

>>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
　【1タスク = 1ワーク】
とか固定観念が出来ちゃってると、>126程度までしか考えが及ばないんだろうね。

>127
> 大洗海水浴場w

それを理解できるのは、相当年齢高くないとムリwww

>タスク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++初心者なのか？
だとしたらもう話している前提が違うとしか言いようがない。

>>138
安全かどうかしか違わないでしょ？

>>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
それなら最初からそう言えばいいのに。>>136の書き方ではとても読み取れない。
片言の日本語でレスするのは勘弁しとくれ。

それで内容についてだが、
> その実装方法が仮想関数でも関数ポインタでもとりあえずこの場の話では違いがないよね

これについては、>>145で書いたが、
> ITaskは、>>123に書いてあるように priorityを持っているから、
> これに従ってタスクシステムがorderingすることができる。std::list<boost::function>ではこうはいかない。
である。

だからlist<ITask*>は、単なる関数ポインタ列ではない。
タスク(ITask派生クラス)側の意志によって、呼び出し順序の変更が可能な関数ポインタ列。

前者と後者とでは全然違うと思うのだが。「この場の話」ってなんだと思っているんだ？>>120であり>>45だろ？
>>45を議論するのにタスク側がpriorityを持てるかどうかがとても重要なんだが、何故それが関係ないと思えるんだ？

関数ポインタだともてないとでも？

関数ポインタのリストだとそれも持てないし大体各オブジェクトの座標とかも持てないじゃん
まさかオブジェクトごとに別々の関数ポインタ持ってるわけじゃないでしょ

>>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か
ずっとC++でやってると、コンパイルエラーを抑止するなんて
バグをわざわざ埋め込んでるようにしか見えなかったよ
少しだけ理解した

テンプレートパラメタの型がITaskの派生であることぐらいなら
単に静的アサートの中で型述語使うだけだからそこまで難しくないかと
エラーメッセージもそこまで読みにくくはない筈

#include <boost/mpl/assert.hpp>
#include <boost/type_traits/is_base_of.hpp>

struct ITask {};
struct CTask : public ITask {};
struct NotTask {};

template <typename T> void foo() {
BOOST_MPL_ASSERT_MSG(( boost::is_base_of<ITask, T>::value ),
ERROR_FOO_REQUIRES_ITask_IS_BASE_OF_T,
(T));
}

int main()
{
// foo<NotTask>(); コンパイルエラー
foo<CTask>();
return 0;
}

// コンパイルエラーの例
ITask.cxx: In function ‘void foo() [with T = NotTask]’:
ITask.cxx:16: instantiated from here
ITask.cxx:9: error: no matching function for call to ‘assertion_failed(mpl_::failed************
(foo() [with T = NotTask]::ERROR_FOO_REQUIRES_ITask_IS_BASE_OF_T::************)(NotTask))’

>>171
ああ、いいね。すごくいい。

タスクシステムを使っても使わなくても
実装できるわけで
観光地に行くのに飛行機で行こう、車で行こうって意見がわかれてるだけで
なんの進歩もない

あえて言うなれば、「僕、僕、こんなすごいオナヌー知ってるんだあぁぁぁぁぁ」って感じ

あの・・・
>>2 ではboost使ってないんですが・・・
キ・・・

仮に自機のクラスから敵、敵のクラスから自機の情報が必要になったらどこに記述すればいいの？

よう　boost使い
お前 small talk 知らないだろ？
車輪の再開発だよ
熟知はしてるようだが
バ○にしか見えない

さらに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 に答えろよ

>>175
情報はデータベースで一括で管理して
タスクの中からそれらの情報に問い合わせるようにすればいいんじゃない？
問合せ元のタスクによってアクセス制御を静的にかけることも一応は可能だし
不要な情報を書き換えるバグを防ぐような対策もできるし
デバッグ実行時にログを取る際にも柔軟にできると思う

>>178
因縁つけすぎｗｗｗｗ

>>179
それはソースでかけないんだ

>どこに記述すればいいの？

>タスクの中からそれらの情報に問い合わせるようにすれば

答えてない

英語にすると
where? と聞いてるのに how to で答えてる
読解力に欠け、異常な頭脳を持つとしかいいきれん

>>182
！

あんたがそれをできるように作ればいいんじゃね？

俺も同意見で　どこに記述すればいいのか不思議でね

情報はデータベースで一括管理というが、
このデータベースもタスクシステムで作られているのか
そこもまた不思議でね

熟知しているようでそこらへんを問い合わせているんだが

まぁ、こんなやつがゲ板でＶＩＰ扱いされてるんだろうな
ほかに行く場所もないしｗ

>>158
またもすばやいレス、ありがとう。おそくなってごめんなさい。

>> それに比べたら生成を管理するためにファクトリを登録するだとか >153-154 とか
>> の方法は、全部なにかしら（比較すれば）面倒になってるよね？
>
> いや、ユーザーは(タスクシステムの外に)deleteは、
> 一切書かなくて済むようになるからソースコードは大幅に簡略化されると思うのだけど。

またまたうまく伝えられなくてごめんなさい。 delete についてはシステム内で
済ませてくれると想定しているよ。

そのうえで、生成を管理する・生成を管理しないのどちらがいいという
問いかけを >>156(>>152) でしたつもりだった。

で、その後の流れを読んでもやっぱり生成を管理することにした理由が
「してもおかしくない」しか見当たらなくておかしいように思う。他に何か
理由があったんじゃないの？

>>185
そもそもどこに記述したいのかわからない。
クライアント側の利用の仕方を教えて欲しいのか、開発側の作り方を教えて欲しいのか。

わからないから空気読んで開発側の話をするけど、
まず基本クラスに必要な値を決めておき、それぞれゲッタとセッタを用意する。
タスクに乗せるのはその派生クラスと言うわけだ。

制御側ではタスクの登録と線形処理・探索を行う処理を書いておく。
線形処理・探索とは具体的に言うと、描画処理や当たり判定処理だな。

＞不思議でね 
理解できないからと言って理解できないとゴネられても困る。
ゴネるんならコードの一つや二つぐらい書いてから言ってくれ。

>152
> 「factoryなりbuilderなりをタスクシステムに持たせる」ってことは、生成される
> 具体的なクラスを全部システム側が知ってるとか、そういう状況にならない？
> そうなるとあからさまに面倒だと思うんだけど。

何をいつ作って何をいつ破棄したか、何がどれだけの時間残ってるのか、きちんと管理
してないと、バグチェックが辛いぞwww

それはどんなプログラムだろうと関係あることじゃん。

>>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++標準に準拠してなくて嫌なのだけど。

>>178
>>193

>>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;
}

>>195
キャラ変わったな。おもしろい。

>>181-183
>>179を読んで >>197 ぐらいのソースがすぐに頭に浮かばないとは、あんた、C++ド素人だな。

>>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
だからこその隔離スレ。一応は技術板なんで良い話題が投げられれば
それなりの流れになるとは思うけど。

自機のタスクが敵のタスクリストの場所の情報を保持すればいいんじゃないのか
あるいは敵のタスクが自機のタスクの場所とか

この勢いでタスクサンプルをうｐする作業に入るんだ
お、俺のSTGに組み組んであげてもいいんだからねっ////

>>212
そんなことしたら制御とクライアントで分ける意味がないじゃん。
そういうのはenumで自機とか敵機の識別子を作っておくんだよ。
場合によってはあるシステムを基にあるシステムに対して振る舞うなんて荒技もある。

＞一同
タスクとは微妙に関係ないけど、暇だったらコードレビューしてみて。
http://kansai2channeler.hp.infoseek.co.jp/cgi-bin/joyful/img/9910.txt

>>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に組み組んであげてもいいんだからねっ////

タスクシステムに求める機能って、制作物ごとに違うだろうから
自分に合わせたものを作るのが一番いいと思うよ。

>>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,…に関しても、それらがサウンドクラスを
コンストラクタで受け取っていないなら、それを受け取るようにコード修正をしなくてはならない。

この呪いのようなサウンドクラスをもらうための連鎖とそれに付随するコード修正が限りなく続いていく。これがとても嫌。

まあ、せっかくだし名乗るか。

>>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禁止は絶対じゃない。そういうローカルルールを用意して
開発するのも現実的には有効だと言ってるだけなのだが。

>>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のようになっていたと思う。

>>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個分の領域を確保しておく、ってのなら速度は維持できるけど。

と言うわけで落ちます。

お先に失礼

>>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++初心者スレで勉強させてもらってきなさい。

高レベルの話になると調子がいいが
具体的な低レベルの話になると途端に煽ってくるのな

で、仮に自機のクラスから敵、敵のクラスから自機の情報が必要になったらどこに記述すればいいの？

答えてないんだけど・・・

ダイナミックキャストやら設計する時点でそんな危険な橋を渡るようなもの作らんのだが
アンチタスカーに映るようだが、あえてタスクシステムのメリットを聞いている
って、タスクシステム使わなくても実装できるのよねって話聞いてないよね


>9ycqcAuWxdGZ
コードも見てみたけど　これを元にあんたの創造するコードを俺らがエスパーすんの？
日常会話通じる？深夜しか書き込みしてないけど、自宅警備員？
精神病院逝け

>>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だけど…
1000タスクもあって、毎フレーム自機と敵とで複数回呼ばれるとすると怖くて使えないなぁ…

玄人になるためにも今度実測してみよう、案外たいしたこと無いかもしれないし

>>272
> 1000タスクもあって、毎フレーム自機と敵とで複数回呼ばれるとすると怖くて使えないなぁ…
> 玄人になるためにも今度実測してみよう、案外たいしたこと無いかもしれないし

1000タスクのうち、敵が999タスクで、その敵が毎フレームすべての敵を列挙する(60frames×999匹×999匹)という話か？

そういう列挙は、1フレーム1回になるように結果をcacheしてよね。
データベースに対するqueryだって、結果をcacheするだろ？

タスクと関係ないが盛り上がってるようで質問

MapClass　：　地形(Map)によるUnitへの影響 (沼地だとUnitの動きが鈍くなるとか)
UnitClass　：　Unitから地形(Map)への影響　（ある地点を通過すると地形が崩れるとか）

これらを実現するためにお互いメッセージのやりとりが必要
そのために、お互いのクラスが相手側のアドレスを保持するのはあまりスマートじゃないような気がする

何かいい方法を教えて

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 を読んで質問の仕方を変えたら？
詭弁で相手を言い負かしたいだけとしか思えない書き込みも多いから
それと混同されてしまうよ。

>そんなことは知らんがな。
こっちも知らんがなｗ

説明もできないの？それはできないと解釈されるのよ？
日本人あんた？

（また、知らんがなとか言うんだろうなｗ」）


裸の王様をつつくスレかｗ

boost知ってるってことは少なくともLinux系はいじったことあるはずで・・・
そんなの何年前かも分からない状況で・・・
ゲ板に来て・・・


王様　迷路ゲームで
■■■■■■
■◇◇■■■
■■◇■■■
■■◇■■■
■■◇◇◇◇
■■■■■■
のような曲がっている通れる場所はどのように実装されるのでしょうか？

>>258
＞>>197のgetTasksがその具体的なコード。 
と言われても、やりたいことはわかってもわからんがな。
システム自体、クラス化してるかと思ったらそうでもないし。
正直、想定の範囲外だし、いっぺん作ってみないと想像できん。

＞「簡単に書ける」コードを実際に書いてみせてくれないかな。
グローバルな関数でやるならわからん。
クラス使うんなら、システム側にcheckHitArea(Character* myself, enum target)みたいな関数で、
（Characterをenumにしてもおｋ）特定のタスク対全タスクみたいな感じで処理させるとか。

>>259
＞確保していたオブジェクトのデストラクタを呼び出すことを保証できないよね。
free(...)で明示的にデストラクタを呼ぶようにしてる。

＞オブジェクト何個作る気かは知らないけど
多くて100個ぐらいかな。
大量に生成する必要がある割にすぐに破棄するような処理。もしくはずっと取っておく場合。
敵機や自機の弾だとか。

＞index = ((byte*)ptr - (byte*)&array[0]) / sizeof(T);　云々
これは同じ型が入っていないとまずいんじゃないの？
一応、汎用（ってことに）してるから現在の実装だと痛い。
同じ型を入れる仕様にしたら参考にする。

>>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を見落としてないかい？

>>331
なんの問題があるんだ

>>333
>>325で書いている「>>319の最後の段落のような」問題。

何度も言うけど書かなきゃいけない処理まで省略しようとするのはなんでなの？
誰かに脅されてるの？
同じなら同じ処理書いておけばいいじゃん
その方がソース見る側安心できるだろ
逆にあるはずの処理があるはずのところにない方が面倒くさいだろ

よく理解できませんが
enum MazeChip
{
とあるので、この共用体は迷路の一部分とみなしてよろしいでしょうか？
そして、MazeChip maze[MAZE_WIDTH][MAZE_HEIGHT];
これで、迷路全体を現していると解釈してよろしいでしょうか？

質問を小出しにするのは順を追って説明していただきたいためです

では、迷路の一部分から、隣の迷路の一部分への移動は
どのような方法で、実装されるのでしょうか？

ここでは、迷路の一部分に入るために魔法をとくキーワードは必要ないとします

>>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];
これ。

ここまではいいか？

>>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で平面的だったから、
その上に何がおかれていても床っぽかったからじゃないかな。

初代ドラクエとか、木が生い茂っているマップチップでも
床であるかのごとくずんずん進んでいけるしな。

まあ、「床」のくだりは、「迷路を構成するチップ」と
頭のなかで置き換えとくれ。

今日は出かけるのでこのへんで。

私がここで書いた記事はあとでまとめてCodeZineにでも投稿しとくよ。

もうこいつはID:YflT6adj無視しろよ
どう見ても基地外だろ

ID:/N8rqxowもキチガイ一歩手前
おそらく複数人で組んだ事ないんだろ

>>345
たしかにタスクシステムを使うメリットはあまり見えてこないね

なるほど2Dでとらえてたのね
俺は3Dでとらえてたので
床とは言わずに部屋としてとらえてた

そして、爆弾については
部屋　has 爆弾という思想
class room
{
room *_west;
room *_nishi; // 英語忘れたごめんｗ
object *_what; // ここに爆弾を代入
};

簡単に書けば
Maze has rooms
Maze has player
のようにA has B の関係で解いた

これをタスクシステムを用いてどのように表現するのかを知りたかったわけだが

まぁ、>>347 のように、構造体で思考停止している奴がわんさかいるんでね
肩身が狭いよ
消えてなくなれオブジェクト指向ってスレもあるしね　（もう消えてるっぽいが）
自分の知識の乏しさを露呈してるとしかいえないが

事業内容 情報処理業
職　種 ＳＥ＆プログラマ
雇用形態 正社員
産　業 情報通信業のうち情報処理・提供サービス業
賃　金月給制 250,000円〜 600,000円

必要な経験等 Ｊａｖａ及びＣ＃の経験者／オブジェクト指向での設計が出来る方
　　　　　　　　　　経験３年以上

かわいそうなんで求職だしておくね

多分君らは月給１０〜１５万くらいでこきつかわれてるんだろうけどねｗ

お金の話してサーセンｗ

キチガイ以下

>>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にしたりする。

うわぁ、先週あたりまで頑張ってたアンチタスカーだけど、
皆覚えてくれてる？
しかし、またひどいのが沸いたんだな。
彼の文章ちゃんと読んでないけど(読む意味無いけど)斜め読みしただけでもうね。
こいつは俺には治療できんww
愛すべきバカって感じでも無いし、相手する気しねぇ。
こんな自分がバカだと気づかない勘違いバカは、
早く病院行って自分が病気だと自覚できれば幸せになれるのに。
タスクシステムスレは彼のせいで死んだな。もう、エントロピーが臨界点でしょ。
なんとか流れ戻せるように策練るわ。

いやもうね、タスカーってほんとどうしようもないのな。
もはや、俺がごちゃごちゃ言うまでも無いね。
俺ね、タスクシステムスレで昔、
タスカーは他人と会話が出来ない奴が多いとか暴言吐いてたけど、
これで分かってくれたでしょ。
なんていうか、基本左巻きなのよ。だから自立キャラクターみたいな変な方向へ行くの。
キャラクターを自立させたって意味が無いということが分からないのよ。
キャラクターなんて手足で十分。
キャラクターはプログラマーがキャラクタの外側から積極的にドライブしていくもの。
なんか良く分からないけど、キャラクタ作っとけば後は勝手に動いてくれるよ〜みたいな
他人を当てにすることしか頭に無いような発想はおかしいし、世間で通用しないし、何も出来ん。
子供なんだよ。

タスクシステム自体もタスク同士のコミュニケーションが苦手という問題を抱えているけど、
自分もコミュニケーションが苦手なもんだから、それに気づかないというか、気づけないというか、
もとより気にしていないというか、感覚が欠落しているというか、なんというか。
一言で言うと、センスが無いってことなんだけど、
自分にセンスが無いことを逆にセンスが良いと勘違いしている彼みたいなのもいるし、
言葉の定義があいまいな人と会話するのは難しい。

ID:YcewJeTt（new tasksystem ◆9ycqcAuWxdGZ）は
やねうらおレベルの高度な知的生命体だからどうでもいいとして

＞ タスカーは他人と会話が出来ない奴が多いとか暴言吐いてたけど

おまえID:6uucu48Dか。あのとても残念な噛み付き癖のある犬っコロか
とても残念な頭脳の子、ファイルシステム君か。とても残念だよ
さっさと俺の質問に答えな。逃げんなよ

＞>>765
＞＞タスクシステム自体もタスク間でのコミュニケーションが苦手という問題を抱えてるが
＞
＞なにそれ怖い。そのチンカスタスクシステム固有の問題、具体的に書いてみ？

答えなさい

お前のタスクシステムはタスクシステムじゃねぇからしらねぇよ。
トラバース→バッファリング→最適化→実行
よりも、>>117の方が素直だと思うんだけどどうよ。
型と処理オーダーごとにリスト持っとけばソートの必要も無いしな。
Zソートもバケットソートで高速だ。

>ID:YcewJeTt（new tasksystem ◆9ycqcAuWxdGZ）は
>やねうらおレベルの高度な知的生命体だからどうでもいいとして

つまり、人ではあるが、人間では無いってことな。
new tasksystem ◆9ycqcAuWxdGZ　はその意味良く理解しろよ。

逃げなくていい。ペロっと書いちゃいなよ。どこの誰のタスクシステムの話なのかをよ。
それはタスクシステムじゃねーなんて否定しないって。「あっそ。」で終わりだから。な

じゃあ、やねうらお式の奴。と言えば通じるだろう。

なんだPCエロゲプログラマ様の考えたボクチンのタスクシステムの話か
糞つまんねーバッタモンを引っ張り出してんのな。CodeZineのウンコ
みたいなデフラグ機能付きウンコシステムを擁護しちゃう聡明な人の
言うことなんざ聞き流しちゃえばいいのに。なんで目が離せないの？
だから自分弄りじゃねーのっつってんだよ。


あっそ。

いや、お前のタスクシステムも随分意味無いことしているなとは思ってるのよ。
スレ違いな話題になるから突っ込まないが。
というか、お前こそなんでこのスレに居座ってんだよ。
高みの見物＋成り行きってんなら、俺とあまり変わらないぞ。

別にタスクリストは1本にしなくてもいいんだぞ
敵リスト、敵弾リスト、自機弾リスト、自機（リスト）等に分ければおｋ

↑処理オーダーごとにも分けとけ。

>>382
それって何がいいの？

例えば敵弾と自機の当たり判定取りたい時にリスト1本だと識別とか面倒でしょ
リスト分けると敵弾リストと自機だけチェックすればええやん
あと敵リストと自機、自機弾リストと敵リストとかな
別に自機弾同士でチェックする必要ないでしょ

>>382
確かに >117 もタスクシステムとみなす宗派の人もいるかもしれないな。
もともとは配列みたいだからリストを使ったものを
タスクシステムとみなさない宗派の人もいるかもしれないな。

いや、配列とかリストとかどうでも良いだろ、そんなこと。お前ら本当に飽きないな。
着眼点がおかしいんだよ。
ちなみに>>117の実装は配列。
実装が配列でも、意味の上でリストと説明する場合もあるし、もう、お前らね。
日本語大丈夫かよ。

>>385
それだけじゃなくて、型情報が死なない点もポイント。
無意味なダウンキャストを無くせる。

工学系四大ないし高専程度のまともなリテラシーを持ち合わせていて
ちゃんとした情報にアクセスできるアンテナ張れてる、ゲームプログラマとして
筋のいい学生ちゃんのために、ググれば適切な情報に遭遇するよう
できるだけ適切な技術用語を散りばめてるんだけどな

このタスクシステムという、ゲーム業界内のローカル用語（もはやバズワードだが）
の指し示す物の実態が何なのか。当初の姿、当初からの本分は何だったのかが
分かるように書いてるんだがな。物事の始まり、物事の土台・基盤を軽んじる者は
TASK=OBJだの1TASK=1OBJだのと勘違いしてみたり、タスクシステムとは
赤ちゃん級のユーザーのための歩行器や小児用自転車の補助輪であると勘違いし
タスクシステムを再定義・再解釈する。そしてウンコみたいな添加物機能を後から
ゴテゴテ付け加えては新タスクシステムだの近代タスクシステムだのと唱え普及を
試みる。これらは全てペテン師である

デジタルコンピュータの登場当初から存在していたプリエンプションなしの
タスクを周期駆動でぶんまわす古典的なリアルタイムシステムのプログラム構成を知れ

>>385
じゃあ、座標変換みたいに全部ほしいときはどうするの？

>プリエンプションなしの
>タスクを周期駆動でぶんまわす古典的なリアルタイムシステム

そしてこれはゲームには必要ないという。

座標変換？具体的なことはよく分らんけど
全部欲しい場合は敵リスト、敵弾リスト、自機弾リスト、自機（リスト）全部辿ればいいんじゃね

タスクはリストでしょ
頻繁に追加削除あるし、そもそもランダムアクセス必要か？

>>391
ならばビデオゲームの駆動原理を簡潔に書きたまえ。寝る

>>392
それタスクシステムじゃなくてベタ組みじゃね？
ベタ組み＆引数通しの俺が全面同意できるんだけど？

あー、ついでに古典的な連続系シミュのプログラム構成についても知れ
粒子ベースものがいい。粒子の相互作用の時間発展をシミュレートするものだ

俺のやってるのタスクシステムじゃないかも知れんけど似たようなもんだと思ってやってる
あと俺の場合はコンストラクタで与える以外は引数なしだから

>>387
だからタスカーとかアンチタスカーとかどうでも良いだろ。正直飽きた。
何がタスクシステムなのかすら定まってないんだから
タスクシステムについてここまで話ができるあんたは立派なタスカーだよ。

>>392
> 頻繁に追加削除あるし、そもそもランダムアクセス必要か？
種類別に添字の範囲を決めることもあったらしい。

>>393
ステートマシン。
ユーザの入力→状態更新→ビデオ出力/音声出力/振動出力。

ゲームは単体アプリだから、マルチタスクも糞も関係ないんだよね。
OSのプロセス管理の真似事なんてする必要なし。
ゲームはOSのプロセス管理とは違って、メインループ部を自由に触れるということ。

>>395
粒子の振る舞いを外部からプログラマブルに定義しないのなら、
ベタ書きで十分だし、処理速度も一番速いし、実装も早い。

>>397
おおよそ全てのタイプのタスクシステムを列挙した上で批判している(>>107)
大概どれかに当てはまるでしょ。

> 種類別に添字の範囲を決めることもあったらしい。
なるほど。で俺はそのかわりに種類別にリストを作ると

>あー、ついでに古典的な連続系シミュのプログラム構成についても知れ
>粒子ベースものがいい。粒子の相互作用の時間発展をシミュレートするものだ

あ、あと、>>46 とも意見しとく。

俺が愚かだと思う人間。

1) 自前の用語を公の場で使う
2) それを指摘され、知らないほうが悪いと責任転嫁
3) 自分の言葉で説明できない用語をかざし、それを調べろと言う
4) 理屈で言えない分、権威で補おうとする
5) 瑣末な問題だけいつもピックアップする
6) 何が大事かの優先順位がおかしい、つまりセンスがない

>401
オマエ、ダブルバッファー君か？

厳密に状態nと状態n+1を分離しないと正しく当たり判定できないよ、って馬鹿なことほざいてたヤツ？
違う？

あー、スマン。
>395がダブルバッファー君の可能性があるのか。
>401は全然違う人だな。

>>403
401でもないし事情なんて丸っきり知らない俺が聞くけど、そんなもんなんじゃないの？

>405
シミュレータ作ってるわけじゃネェぞw

やりたいなら止めはしないがw

>>406
なぜそこでシミュレータになるのかｋｗｓｋ

>407
ggrks

>>408
口から出まかせだったのですね。わかります。

厳密にやればそうしなければ駄目だけどそうしなくても十分な場合があるってだけでしょ
状況によって使い分ければいいだけの話じゃないのか

ビリヤードとシューティングの当たり判定処理が同じだと思ってる人、リアルに存在してたんだ…。

ナンか名前が今日だけ違うなw
自分は期日前投票に行ったので無問題。

フツーにOOPやってる奴から見るとギョッとするような世界だよな。
ボスクラス、ホーミングクラス？タスクシステムクラス？抽象化が雑すぎる。

自機、敵機、ボス、弾、これらに型の別なんていらないだろう。
動き方ストラテジや耐久性とかを、最初にパラメータで渡して生成するだけ。

アンパンクラスとカレーパンクラスを設計するような奴は糞。
OOPやってるやつなら、中身クラスとパンクラスを作り、
実行時にそれらのインスタンスは組み合わされて使われる。

こんどはOOP君ですか
王様とか引数君、ダブルバッファ君、メリット厨、スレッド厨…
そろそろ登場人物についてのまとめが必要になってきそうだな

>>414
そういうお前は属人クンだよｗ
中身じゃなくて、人格への偏見でしか語らぬ。

>>404
相互の作用（押し合いへし合い）があるなら「いっせーのーせ」でやるし
相互でなく一方的な作用なら今までどおり端折っちまえばいい
典型的なSTGなら基本的に後者で何も問題ないだろ

ケースバイケース。あとタスクシステム関係ないだろこれ

みんな得意の脳内妄想じゃなくて
動くサンプル作ってくれ

>>413
is-a か has-a のどちらが適切か、は何をどうモデル化するかによって変わるんだがなぁ
それとも全てのゲームの仕様をたった一つの設計で済ませられると考えてるのかねぇ・・・

アンチはSTGも作れんような乞食しかおらんのか
>>416の意味が分からないのか。そうかー

>>413
＞動き方ストラテジ（略）を、最初にパラメータで渡して

動き方の実装も含めて、詳しく。

//パンシューティング
bread("↑↓↓→↑休休↑");
bread(curry_update/*←関数*/);
bread(new curry() );
俺はあまりお勧めしないが。OOPは制御構造がガタガタになるから嫌いだな。

>>416
お前がゲームの動作原理語れとか言うから書いてやったのに無視かよ。

>>421
悪いな。阿呆すぎる発言につい呆れてしまったんだよ

>>398
>>>>プリエンプションなしの
>>>タスクを周期駆動でぶんまわす古典的なリアルタイムシステム

>>>そしてこれはゲームには必要ないという。

>>ならばビデオゲームの駆動原理を簡潔に書きたまえ。

> ステートマシン。

はいはい。ビデオゲームの駆動原理はステートマシン。クルクルパーのアンチは
おつむが空っぽでいつも爪先立ちで背伸びしてっから簡潔に書けといわれると
途端に意味の無い抽象論に走り出すね
お前の言い草だと
全てのプログラムは、ソフトウェアは、コンピュータは、機械は、流体・粉体の振る舞いは
社会システムは、いや、世界の仕組みは、有限状態機械モデルで説明できるというお話
になってしまうだろうな。なーんかどっかで書いたような話だな。j過去スレでお前とよく似た
バカの相手をしたことがあるのかもな

さて、ビデオゲームの駆動原理はステートマシンだというならば、なぜ
『プリエンプションなしのタスクを周期駆動でぶんまわす』
この仕組みがゲームに必要ないという発想に至るのかね？

>>398
>ユーザの入力→状態更新→ビデオ出力/音声出力/振動出力。

ほう。この手続きを周期的に繰り返しているのが君のビデオゲームなのだろう？
外部入力をポーリングで取得。16[ms]程度で応答するリアルタイムシステムだな。
cyclic executive。周期駆動。だからゲームループがあるわけだ。そうだろう？

　　　　　　　　　　　　　　　　『周期駆動でぶんまわす』

この点には流石に異論はないだろうな

メインループ部を直接記述できるから、だと書いてあっただろ。

ゲームの動作原理がステートマシンという主張は、
ゲームがその辺のGUIアプリとなんら変わり無いという意図。
ごく普通のプログラムを記述するのに、普通
『プリエンプションなしのタスクを周期駆動でぶんまわす』
は必要無い。必要になるのは、メインループ部を固定する場合。(例：OSのプロセス管理)
メインループを直接触れるゲームには関係ない。

逆に、何故『プリエンプションなしのタスクを周期駆動でぶんまわす』が
ゲームに必要なのかの説明は無いんだな。

>>423
その点は異論無いな。
ただ、タスクは要らないだろうと。単にループ部に処理を書いていけば良いだけ。
処理が長くなったり、使いまわす場合は、関数を使う。普通の開発手法。
で、タスクシステムの出る幕は？

あと、周期駆動っつったって、定期的に入力が発生するだけ。
ほかのアプリとなんら変わらん。

>>424
> ゲームの動作原理がステートマシンという主張は、
> ゲームがその辺のGUIアプリとなんら変わり無いという意図。

そんな意図があるなどとはどうして読み取れようか。他人にESPを要求する
人間というのはコミュニケーションが下手だということが理解できてるのかね。

アドホックな屁理屈の積み重ねをするくらいなら前言を撤回・修正・書き直す
大人の常識

>>427
お前が「駆動原理」とかいう抽象的な聞き方するから、
普通のアプリであるゲームの動作原理を説明するのに、
普通のアプリの駆動原理である「ステートマシン」を持ち出すしかなかったんだろ。
質問が抽象的だから抽象的に答えたんだ。

俺からしたら、
『プリエンプションなしのタスクを周期駆動でぶんまわす』
と、『駆動原理』に何の関連性があるのか分からんわけで、
そんな中、駆動原理を簡潔に書けといわれても、
ごく普通のアプリです。ステートマシンです。としか答えようが無いだろ。

第一俺は、『プリエンプションなしのタスクを周期駆動でぶんまわす』は、
メインループ部を固定するという制限から派生したものと考えているわけで、
その制限の無いゲームの『駆動原理』を答えることと、題意がどう繋がってるのか
今でも分かってない。説明よろ。

>>425
> その点は異論無いな。

ふーん。へー。それならば何故に君は>>424のような面白い発言をしてしまうのかね

>>424
> ゲームがその辺のGUIアプリとなんら変わり無い

おーう。絶望的デース。頭でっかちなだけで筋の悪い学生ちゃんの相手をするのはツカレマース
WindowsのようなOSのGUI機能を利用するアプリは基本的に事象駆動型（イベントドリブン型）で
組むことができるわけだが、なぜ事象駆動型で組めるのか、いや、なぜ事象駆動型の部分しか
組まなくて済むのか理解できてるのかね？
それは下層にWindowsのようなOSがあり、そのGUIを利用するためのAPIがあるからだろうに
意味わかるかね。わからんだろうね

で、君はビデオゲームを周期駆動型ではなく事象駆動型で組んでるのかね。それはどんな
ジャンルのゲームなのかね。紙芝居ADVとか戦略SLGではないのかね？

>>429
もう言ってることがいよいよ神がかってきてるんだが。
俺のエスパー能力にも限界がある。

とりあえずだな、
事象駆動でも、周期的にイベントを発生させれば周期駆動になる。
周期駆動は事象駆動に含まれているということだ。
分けて考える必要なし。

ゲームと普通のGUIアプリが別物だと考えている時点で頭おかしいというか。
ゲームは特別なんだという思い上がりというか。
Windowsのウィンドウ周りのAPIがああいう構造しているのは、
仕様不明のウィンドウ同士を協調動作させなければならない制限からああなってるわけで。
そのためにウィンドウ周りのループ部(←カーネルのな)は固定になってて、
仕方なくイベントドリブンしているという。
別にイベントドリブン自体が目的ではない。発想の出発点がおかしいというかなんというか。
どっちにしろ、単体アプリのゲームにはやっぱり関係ない話ではある。

あほ：うわぁ、Windowsすげぇ、イベント部だけ書けば良いなんて、MS超優しいね。

違う違う逆逆。

MS：仕様不明のウィンドウ同士を協調させるために、
　　　ウィンドウの管理部はこっちで固定しとかなきゃならんな。勝手なことされたら困るからな。
　　　アプリ開発者にはイベント駆動部だけを書かせることにしよう。
　　　せいぜい俺らの作った仕様の中だけで暴れてね。

これが真相。

だからタスクシステマーは左巻きだと常々・・・

>>430
超能力能力なんて求めていない
君はそういう突飛な能力を持ってるらしいが俺は持ってない。うらやましいね

> 事象駆動でも、周期的にイベントを発生させれば周期駆動になる。
> 周期駆動は事象駆動に含まれているということだ。
> 分けて考える必要なし。

視野の狭い子だな

周期駆動（時間駆動）のプログラムが使うインターバルタイマーの周期的なトリガーをイベント（事象）のひとつとみなして
これを事象駆動の一種とする捉え方は可能ではなる。が、リアルタイムシステムや科学技術計算の分野では 明確に
対比され区別されている

リアルタイムシステムではtime-triggered-systemとevent-triggered-system
科学技術計算ではcontinuous-simulationとdiscrete-event-simulation

といった感じでね

補足すると、対比され区別されているからといって排他的という意味ではない
両者を組み合わせる形のシステムはちゃんと存在する

ゲームでは時間駆動型の基本システムの上にイベント駆動のシステムを
乗せているビデオゲームだ。画面更新はあくまでも時間駆動。ゲームの
シミュレーション部などが事象駆動。といったハイブリッド型の実装になってる
完全に一体になってるケースもないことはないが普通は層が分かれてる

×ゲームでは時間駆動型の基本システムの上にイベント駆動のシステムを
乗せているビデオゲームだ。

○ゲームでは時間駆動型の基本システムの上にイベント駆動のシステムを
乗せているものが存在する。

分かりやすく現実世界に当てはめるとこうだ。

銀行：お前らのお金管理してあげるよ。お前は仕事だけしてくれればいい。
あほ：仕事に専念できるなんてラッキー
↓
同僚：お前の仕事は俺が振ってあげるよ。お前は作業だけしてくれればいい。
あほ：適当に作業こなして定時で帰れるなんてラッキー。
↓
上司：お前は管理職しなくていいぞ。もっと言えば家で休んでくれてていい。
あほ：えっ！？
↓
あほ：俺は政治家になるぞ！！「今の日本は間違ってる！！」

お前ら選挙行けよ。

ついに知能障害をおこしたか

>>433
それと、
「GUIアプリはイベントドリブンだから、周期駆動であるゲームとは違う」という、
お前の主張に何の関連性があるんだ。

お前も、

>周期駆動（時間駆動）のプログラムが使うインターバルタイマーの周期的なトリガーを
>イベント（事象）のひとつとみなして
>これを事象駆動の一種とする捉え方は可能ではなる。

といってるとおり、>>430の発言は突っ込むところでは無いだろ。

GUIアプリは水面下でOSが云々も意味不明だし。
イベントドリブンするためにはOSが必要ってわけじゃないし、
周期駆動だって、ループ部を固定するならOSもどきは必要だし。

そもそも、
『プリエンプションなしのタスクを周期駆動でぶんまわす』
と
『ゲームの駆動原理』
の説明がなされて無いんだが。

お前の主張どおり、ゲームを周期駆動と位置づけたとしても、
タスクの出番が無いのだが。

>>398
>ゲームは単体アプリだから、マルチタスクも糞も関係ないんだよね。
>OSのプロセス管理の真似事なんてする必要なし。
>ゲームはOSのプロセス管理とは違って、メインループ部を自由に触れるということ。

本当に視野の狭い子だな

WindowsのようなプリエンプティブなマルチタスクOSに慣れ親しんでいる子にとってタスクという
言葉から連想するものがプロセスしかないというのは同情の余地は在るけどな
「タスクシステム」ではなく「タスク」が必要ないとか言い出すような勇み足アンチは大抵おバカだな
そういやクルクルパーと散々小馬鹿にしてきたHSP君。彼の批判の矛先はあくまでも「タスクシステム(>>2)」
であって「タスク」ではなかったな。であるがゆえにタスクシステマーに対しては「タスク」という言葉を
擁護して「タスクシステム」を擁護したつもりになるなだとか、「アンチタスクというのは正確ではない。
俺はアンチタスクシステムだ。」とかキャンキャン吼えてたな。阿呆なりに筋は通っていたな

あと、イベントドリブンとOSの関連性もな。
お前はまったく関係の無い事柄をさも関連性があるかのように語るのが好きだよな。

//単純なイベントドリブン
std::queue<event> events;

for(;;)
{
　　switch(events.front())
　　{
　　　　case event1: /*処理*/ events.push(event2); events.push(event3); break;
　　　　case event2: /*処理*/ events.push(event3); break;
　　　　case event3: /*処理*/ break;
　　　　default:;
　　}
　　events.pop();
}

OS？何の関係があるの？

>>439
どうでも良いから>>438、>>440の説明だけはしろよ。
お前が言い出したことだからな。

俺の主張は一貫してて、
『プリエンプションなしのタスクを周期駆動でぶんまわす』
はメインループ部を固定する制限から派生しているもので、
『駆動原理』(周期駆動云々)には関係ない。
イベント駆動でも、メインループ部を固定するなら、
『プリエンプションなしのタスクをイベント駆動でまわす』
はありえる。

>417
夏休みの宿題、やらずにここまで過ごしてきたの？

>419
前スレに居たんだよ、『状態をダブルバッファにしてすべてのnからn+1を生成しないと正しく当たり判定
出来ない！！』って一人荒野で叫び続けてた人が。

それがダブルバッファ君だ。

アンチタスク派には、そういうキチガイも混じってる、ということ。

あと、ゲームとその辺のGUIアプリとの違いの説明もな。>>ID:RQNrxHmb
また駆動原理云々言い出すんなら、
駆動原理と
『プリエンプションなしのタスクを周期駆動でぶんまわす』
との関連性もな。
周期駆動させるだけなら、for(;;){ /*処理*/ wait(); }でもできる。
なぜ、「プリエンプションなしのタスクを」のくだりが必要なのか、その辺明確にな。

>>398
> 粒子の振る舞いを外部からプログラマブルに定義しないのなら、
> ベタ書きで十分だし、処理速度も一番速いし、実装も早い。

そのベタ書きとやらにも処理単位（処理ステップ、タスク）があるんだな
プリエンプションなしの処理ステップを何らかの時間刻みで繰り返し実行してる
プリエンプションなしのタスクを何らかの時間刻みでぶんまわしてるんだよ

コンピュータ関連の分野ではタスクというのはプロセスに限らず色んなものの
処理単位の意味で使われる。OpenMPやTBBの中にもタスクという言葉が登場する。
タスクシステムに限らず、ゲームプログラムには必ず処理ステップ（タスク）と呼べる
ものが必ずといっていいほど存在する。何らかの時間刻みで数値積分とかしてる
わけだからな

組み込みシステムの分野では非プリエンプティブなタスクというのは沢山使われてきた
RTOSを使わないリアルタイムシステムの中でタスクといったら大抵これ。ただのサブルーチンだ
8bitプロセッサの組み込みシステムなら確実に半分以上、16bitプロセッサでも3割近くが
RTOSを使ってない。プリエンプションありならRTOS使う

　　　　　　『プリエンプションなしのタスクを周期駆動でぶんまわす』

こんなのゲームの中にあって当たり前の仕組み。
これがゲームに必要ないなんてありえないよね。流石に異論はないだろうな

> ただのサブルーチンだ

乱暴な言い方だったかな

>445
> 　　　　　　『プリエンプションなしのタスクを周期駆動でぶんまわす』
> こんなのゲームの中にあって当たり前の仕組み。
> これがゲームに必要ないなんてありえないよね。流石に異論はないだろうな

アンチタスク派はそうは思ってないようだけどね。

イベントドリブンの仕組みが非プリエンプティブなタスクによって実現されているからといって
システム全体を「プリエンプティブなしのタスクを周期駆動でぶんまわす」なんて表現したりはしない。
どんな抽象化レイヤーの上でゲームを構築するかという話では無いのか。

> ただのサブルーチンだ
いや、的確な言い方だと思うよ。(お前の中ではな)
俺も多分お前はそういう意味で言ってるんだろうなとは思っていた。
ただ、普通の人はサブルーチンのことを関数と言う。
いいってことよ、俺のエスパー能力が足りなかっただけだ。
for(;;)
{
sub1();←タスク
sub2();←タスク
sub3();←タスク
wait();
}
でも、こうなってくると、タスクシステムと、
『プリエンプションなしのタスクを周期駆動でぶんまわす』
の関係性が希薄になってくるわけだが。

>タスクシステムに限らず、ゲームプログラムには必ず処理ステップ（タスク）と呼べる
>ものが必ずといっていいほど存在する。
一般アプリでも存在するわけだが。
ゲームと一般アプリとの違いの説明よろしく。

あと、イベントドリブンとOSの関連性の説明もよろしく。(>>440をふまえたうえでな)

というか、処理をステップに分けて実行する事象を
プリエンプティブなしのタスクを駆動している、と表現するのはどうかと。
ノイマン型コンピュータは基本的に同時に1命令しか実行できないわけで、
全てのプログラムは処理をステップに分けて実行されていると言える。
a=1;//ステップ1
b=a;//ステップ2
sub1();//ステップ3
sub2();//ステップ4
これを見て、プリエンプティブなしのタスクを駆動している、とは普通言わないだろう。
わざわざそう言うということは、何らかの特別な仕組みを期待するだろう。
じゃないと、「ノイマン型コンピュータは実はタスクシステムだった」　???<「なんだってー」
になりかねん。そう言うレベルの話になっちゃう。

自分のエスパー力を棚に上げてなんだが、
掲示板で会話する上では無理があると思うよ。

>>440
このコード断片は一体なんなのかね…。何のアプリの断片なのかね…
GUIアプリなのかね。なぜビジーウェイトしてる。シングルプロセスのOSで
動かしているのか。GUIのイベントは誰が突っ込むのかね

意味が分からない

ハードウェアの全てを独占的に使う権利を有しているのかね。
OSも何も供給されない。デバイスドライバからGUIのシステムから
全て自前で用意してるのかね。ディスプレイ装置に出力する映像は
全て自前で生成してるのかね

>>450の話は、
俺が前言った、ノイマン型コンピュータの実行はFIFOだから、
処理の遅延目的(ループ部固定にしたときに処理キュー使うのも処理を遅延させて緩和するため)
以外で、処理をキューに突っ込む必要は無いってのとも被る。
往々にして、コンピュータの仕組みを知っているのかと。

>>451、>>452
何わけのわからないことを。
>>440は単にイベント駆動プログラムのサンプルだ。何かのプログラムというわけではない。
OSに頼らなくてもイベント駆動のプログラムは書けると証明したまで。
イベント駆動だからといって、waitしなければならないという理屈も無いし、
協調動作しなければならないという理屈も無い。
>>440は無限ループしているわけではなく、一連の処理をすばやく終え、
どこかの段階でreturnしていると思えばよい。
たとえば、event3の処理の中でreturnしているのかもしれない。(どうでも良いこと)

>>440のイベント駆動に何の意味があるのかと思う人もいるかもしれない。
説明しておくと、イベント投げてから実行されるまでの処理の遅延が目的。

どうでも良いから、お前はさっさとイベント駆動とOSの関連性を示せ。

イベント駆動＝協調動作っていう固定観念が邪魔しているのかな。
視野が狭いのはどっちだか。

とりあえずタスクシステムと「〜駆動」の関連を３行ほどにまとめてから話してくれないか？

>>454
私が興味を示している君の主張
--------------------------------------------------------------------------
１．『プリエンプションなしのタスクを周期駆動でぶんまわす』
　　こんなものはゲームに必要ない。

２．ところでゲームは単体アプリだからマルチタスクも糞も関係ない。OSのプロセス管理の
　　真似事なんてする必要なし。ゲームはOSのプロセス管理とは違ってメインループ部を
　　自由に触れるからである。

３．ところでビデオゲームの駆動原理を簡潔に書けと言われればこれはステートマシンである。
　　これはつまりゲームが【その辺のGUIアプリ】となんら変わり無いということである。
　　ごく普通のアプリです。ステートマシンです。ゲームと【普通のGUIアプリ】は別物だと
　　考えるのは頭がおかしい。それはゲームは特別だという思い上がりである

---------------------------------------------------------------------------

君の言う【その辺のGUIアプリ】【普通のGUIアプリ】とは一体何なのかね。
『プリエンプションなしのタスクを周期駆動でぶんまわす』必要のない
【その辺のGUIアプリ】【普通のGUIアプリ】といったら、Windowsのような
OSのGUI機能を利用するアプリのことと解釈してしまうが違うらしい

そして>>440である。訳が分からんな

プリオンの話禁止

肉骨粉？食べてませんよ。

えーっと、ここWindows前提だよね？
その為にPCカテゴリに移ったんだから

100歩譲ってもせいぜいデスクトップLinuxやMACまでが範疇
なんでゲーム機やRT OSの話してる奴がいるの？

>>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限定、なんてレアケースあえて扱う意味あるのか？
ありますよ。CSは個人じゃなかなか扱えないし、
タスクシステムよくご存じなら
XNAやWindowsにも話をもっていけるはずでしょ。
ここはアマチュアが多いしそこに話を持っていく
意味は十二分にあると思いますよ。

>君の言う【その辺のGUIアプリ】【普通のGUIアプリ】とは一体何なのかね。
ワードやエクセルで良いよ。

>WindowsのようなOSのGUI機能を利用するアプリのことと解釈してしまうが違うらしい
あってるよ。

>そして>>440である。訳が分からんな
>>440は最も基本的なイベント駆動プログラム。
お前がイベント駆動はOSがどうとかこうとか言ってたから、
イベント駆動とOSは関係ないと説明したまで。

お前はGUIアプリとゲームの違いは、駆動原理がどうとか言ってたけど、それは関係ない。
駆動原理の観点からは両者とも違いが無い。
周期駆動は周期的にイベントの発生するイベント駆動。

GUIアプリだろうがゲームだろうが、パラパラ降ってきた入力に基づいて、状態を更新し、結果を出力するだけ。
ただ、ゲームの場合は更新を促す入力も一定周期で振ってくる。そんだけ。
GUIアプリでもタイマー使うことはあるし、変わりは無い。

個人や同人ならwindows限定がレアなケースっていう感じではないと思うけど。
ここはプロの集まるスレですか？

Windowsも含める、ならわかるが
あえてWindowsに限定するってことは
プロお断り、アマチュアのみという感じになるが
アマチュアに限定しないといけない理由は何だろう？

正直、ゲームプラットフォームとしてはWindowsはゲーム業界の主流から離れた異端な環境。
”Windowsしか知らないプログラマ"っていえば平気でメガ単位のスタック使ったり
メモリのピークや負荷に無頓着だったりでかなり痛いプログラマの代名詞なんだが・・・

私が興味を示している君の主張
--------------------------------------------------------------------------
１．『プリエンプションなしのタスクを周期駆動でぶんまわす』という仕組みはゲームに必要ない。

２．ところでゲームは単体アプリだからマルチタスクも糞も関係ない。OSのプロセス管理の
　　真似事なんてする必要なし。ゲームはOSのプロセス管理とは違ってメインループ部を
　　自由に触れるからである。

３．ところでビデオゲームの駆動原理を簡潔に書けと言われればこれはステートマシンである。
　　これはつまりゲームが【その辺のGUIアプリ】となんら変わり無いということである。
　　【その辺のGUIアプリ】とはワードやエクセルのこと。WindowsのようなOSのGUI機能を
　　利用するアプリのこと。ごく普通のアプリです。ステートマシンです。
　　ゲームと【普通のGUIアプリ】は別物だと考えるのは頭がおかしい。それはゲームは特別だ
　　という思い上がりである

４．GUIアプリとゲームの駆動原理の観点からは両者とも違いが無い。
　　周期駆動は周期的にイベントの発生するイベント駆動。

---------------------------------------------------------------------------

『GUIアプリとゲームの違いは駆動原理の観点からは両者とも違いが無い』というにも関わらず
『プリエンプションなしのタスクを周期駆動でぶんまわすという仕組みはゲームに必要ない』
という。

『周期駆動は周期的にイベントの発生するイベント駆動』というにも関わらず
『プリエンプションなしのタスクを周期駆動でぶんまわすという仕組みはゲームに必要ない』
という。

訳が分からんな

> 事象駆動でも、周期的にイベントを発生させれば周期駆動になる。
> 周期駆動は事象駆動に含まれているということだ。
> 分けて考える必要なし。

しかし本当に視野の狭い子だな

周期駆動（時間駆動）のプログラムが使うインターバルタイマーの周期的なトリガーをイベント（事象）のひとつとみなして
これを事象駆動の一種とする捉え方は可能ではなる。が、リアルタイムシステムや科学技術計算の分野では 明確に
対比され区別されている

リアルタイムシステムではtime-triggered-systemとevent-triggered-system
科学技術計算ではcontinuous-simulationとdiscrete-event-simulation

といった感じでね。現実にはこのような対比・区別が存在するわけだ

>>466
> アマチュアに限定しないといけない理由は何だろう？
そりゃコンシューマでもアーケードでも携帯でもトイゲームでも全ての環境で
タスクシステムは使い物になりません、なんて証明できんからな。

このままじゃアンチ惨敗なので個人、同人がWindows環境で作るゲームについてのみ
タスクシステムは不要。ぐらいまで戦線を狭めてきたんだろ。

頭おかしいのがいるな(笑)
そんなにエロゲが作りたいのか？

>>469
お前のようにロクに意見も言えずに、
対立を煽って面白がってる奴はこのスレにとって不要。
アンチだの惨敗だのに拘って何が得られるのか。

タスクシステム使っても作れるし
使わなくても作れるので不毛

>>468
>現実にはこのような対比・区別が存在するわけだ
区別されてたからって、組み方が変わるわけじゃないだろ。

お前も、
>周期駆動（時間駆動）のプログラムが使うインターバルタイマーの
>周期的なトリガーをイベント（事象）のひとつとみなして
>これを事象駆動の一種とする捉え方は可能ではなる。
と書いているじゃないか。

大概のWindowsアプリのメインループ部は、
for(; 0<GetMessage(); ){ Dispatch〜〜 }
となってるが、単にこれを、
for(; ; ){ if( PeekMessage() ) for(; PeekMessage();){ Dispatch〜〜 } wait(); }
と書き換えれば、そのアプリは元の挙動のまま、そのまま周期駆動になる。

入力→状態更新→出力という一連の流れの中で、
イベント駆動/周期駆動は入力の拾い方の違いを示しているだけで、
プログラムのメイン部(状態更新部)の構造にはタッチして無い。
このスレに居るやつは皆、状態更新の方法を(拙い頭で)あれこれ議論しているわけで、
入力部に拘ってるのはお前だけ。お前だけスレ違いで、話のピントがずれてる。
要領が悪いということ。

拙い頭では余計だコラｗ

なんというか
レベルが低すぎて逆にわからん

マインスイーパーもタスクシステム使ってるの？

ウインドウズがタスクシステムつかってるから余裕で使ってる

釣りネタだろうけどOSの話とは違うんじゃないの

Windows限定、アマチュア限定になってこのスレ終わったな・・・

タスクシステムって組み込み系のテクニックですよね

アマチュア個人だと作業分担もなければ
再利用もあまり考えなくていいしタスクシステムのメリットってほとんどないな

わざわざ生存管理をタスクシステムにとられちゃうのが納得いかない
んでアクセスするときに判別するのがすげー嫌
登録だけしておいて後はこっちで自由にさせろよ
それとこっちでnewしたもの勝手にdeleteするな

>>482
> それとこっちでnewしたもの勝手にdeleteするな

GCつきの言語を使ったことのない厨房乙

GCは参照のあるオブジェクトを勝手にdeleteしないのだが。

>>484
それを言えば、典型的なタスクシステムにしても、「もう消滅していいよ」ということを意味する delete markerが
ついているからオブジェクトを削除するのであって、勝手にdeleteしているわけではない。

>>485
その実装はマーカーに従って明示的にdeleteしているわけで、
>>482の言う「勝手にdelete」とは違うんじゃないの？
たとえば、親が死んだら子も死ぬとかが、勝手にdeleteの代表だろう。

>>486
> >>482の言う「勝手にdelete」とは違うんじゃないの？

それなら、特に異論はないのだが、しかし、

> たとえば、親が死んだら子も死ぬとかが、勝手にdeleteの代表だろう。

そのタスクシステム、一体どんな実装になってるの？そんな実装のタスクシステムあるか？
一体、何にしたがってオブジェクトを削除してるんだ？

それはお前の気にするところではない。

お前はただ、以下の勝手にdelete度順位を覚えればよい。

GC<<<delete/free<<<タスクシステム

GCはオブジェクトがどこかから参照されている限り削除しない。(無効な参照を生まない)
delete/freeはオブジェクトが参照されていようがいまいが即削除する。(無効な参照を生む)
タスクシステムは指定したオブジェクト以外も削除することがある。(予測不能な無効な参照を生む)

>>488
> タスクシステムは指定したオブジェクト以外も削除することがある。(予測不能な無効な参照を生む)

だからそんな実装になってるタスクシステム、何の意味があるのか？
そんな現実的にありえないようなタスクシステムを持ち出してこられてもなぁ・・

>>489
いや、大半のタスクシステムが削除しちゃうと思うよ
だって参照カウントみて残ってたら自分を削除できないんだよ
これをどうやって解決する？

参照カウントによって削除させる設計は全て愚か。

>>491
じゃあ、残しておけば
そっちのが多分スタンダードじゃない？

でも最寄のタスクシステム的にどうよ？
参照カウント残ってたら解決できんの？

>>490
> いや、大半のタスクシステムが削除しちゃうと思うよ
> だって参照カウントみて残ってたら自分を削除できないんだよ

どこに参照カウンタ使ってるタスクシステムがあるんだよ。
普通、タスクシステムは参照カウンタなんかみないよ。循環参照してたらどうするんだ？boost::weak_ptrでも使うのか？

ともかく、ふつうにdelete markerがついてるやつだけ削除すればいいじゃん。

ID:SHBZF47D の主張
いや、大半のタスクシステムが削除しちゃうと思うよ
だって参照カウントみて残ってたら自分を削除できないんだよ
だから参照カウンタは使わない。
↓
ID:e3abVnaU　の反論
どこに参照カウンタ使ってるタスクシステムがあるんだよ。
普通、タスクシステムは参照カウンタなんかみないよ。

>>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の糞実装がおぼろげに見えてきた。
普通にタスクのコンストラクタでattach、デストラクタでdetachで良いだろ。
生存を管理するmanagerを用意するんじゃなくて、参照を管理するmanagerを用意しなさい。

>>499
>生存を管理するmanagerを用意するんじゃなくて、参照を管理するmanagerを用意しなさい。
それでいいよな
それで駄目な理由がわからない

>>500
別にアマチュア限定のスレだからいいんじゃない？
個人、同人限定なんだからへんてこ実装でも誰がこまるわけでもないし・・・

>>501
自分が説明できない理由をそうやって誤魔化そうとするなら
ハナから技術系の板にくるなよお前

タスク程度の何が技術なんだか・・・
タスクの使い方わからないなんて
ポインタの使い方わからないってのと同じレベルだろ。
そんな話延々と続けたいか？

>>503
具体的な話をしようぜ

>>504
仕様も使用条件もソースも無いのに具体的になんて無意味って気づけよ。

個人個人の脳内前提条件に当てはめれば具体的、のつもりなんだろうけど
他人から見ればただの妄想。
しかもWindowsしか知らないアマチュア限定ならなおさらだ。

全ての条件でたった一つの実装に収束するほと汎用的な話でもなし。

タスクシステムって実装？設計？概要？

Windowsでしかゲーム売れない件

>>507
Windowsでしか”同人”ゲーム売れない件、でしょｗｗ

タスカー側がそんなに使われてるって主張するなら
ソースがダウンロードできるゲームのサンプルで納得がいくのを見つけてこいよｗ

UNIXでな！

>>510
動かないのは駄目ではないんだろうけどやめてほしいなぁ

>>509
> タスカー側がそんなに使われてるって主張するなら
どこにそんな主張があるのかなぁ？ｗｗｗ
アマチュア同人ならどんな実装でもいいんじゃね、としか言っていないが

>>512
なんだ使われてないのかｗ
やっぱりやねうらおが１人で自演してんだな
悲しい奴だ

>>513
そうそう、タスクシステムなんて君には一生関わりの無い話。
これで安心して寝れるねｗｗｗ

アンチタスクは何故こんなゴミ虫レベルの奴が多いのか

タスクシステム養護派は具体例に欠け
脳内俺俺仕様をおしつけてくるからタチが悪い

結局のところ　「ググレカス」　に終わり
それ以上の話はすすまない
オープンソース時代の今の風流には合わない人間

>>517
アンチはググルこともできない今の時代に適応できないゆとりだ、
と言ってるのねｗｗｗ

>>518
あなたとは関わり合いたくないですね

だいたいタスクシステム側が納得いくタスクシステムをソース付きで出してくれないと
話進まないだろ
いつも何かを基準にしてると「これじゃない」っていうし

googleでタスクシステムで検索。以下上位サイト。

「その３ タスクシステムと「ゆるゆる」なキャラクタ」
ttp://marupeke296.com/GDEV_No3_TaskSystem.html
ゆるゆる

「本場のタスクシステムはスゲェな...」
ttp://www.game-create.com/archives/1299#more-1299
本場ですらスゲェんだな(謎

「萌えプロ タスクシステム基本篇」
ttp://akira812.spaces.live.com/Blog/cns!96B4C8D0C2C59D62!202.entry
ノーコメント

タスクシステムでググっても、ろくなサイトが出てこない件

タスクシステムの不思議

多くのタスクシステムには、型によるタスクの検索が実装されているが、
それがあるのなら、初めからタスクシステムのメインループ部は

updatables = get_tasks<updatable>();
for( itr=updatables.begin(); itr!=updatables.end(); ++itr )
{
　　(*itr)->update();
}

と書けるわけで、結局タスクシステムは型による検索エンジンさえあれば良く、
タスクシステムなんて用意する必要が無かったということになる。

>>500、>>501と来た流れでの>>502に対して、
>>503とレスをつけるような奴を相手にしてはならないｗ

タスクシステマーが本当にしたかったことは、タスクシステムでは無かったということ。
本当にしたかったことは、

・型によるインスタンスの列挙
・列挙順の制御

実装すべきものは、

・型と列挙順位ごとにインスタンスを収集する仕組み。
・上記で使う、空き領域管理機能付きのカスタムvector。
・型を列挙するためのマクロ。( 例： each_type( type ){ /*処理*/ } )

勝手にupdateなりdrawなりを呼び、処理フェーズ(処理ステップ)を固定化し、
制御構造をズタズタにしやがる、糞タスクシステムは、
やりすぎというか、無意味というか、。

訂正
・型を列挙するためのマクロ。( 例： each_type( type ){ /*処理*/ } )
↓
・型で列挙するためのマクロ。( 例： each_type( type ){ /*処理*/ } )

>>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 ){ /*子更新コード*/ }
}

マクロだと分かりにくいので。

oya *oyas[16][16];
ko *kos[16][16];

for( size_t order=0; order<16; ++order )
{
　　for( size_t i=0; i<16; ++i ){ /*oyas[order][i]の更新*/ }
　　for( size_t i=0; i<16; ++i ){ /*kos[order][i]の更新*/ }
}

>>528
なにがやりすぎなのか意味わからないけど
その型がとってこれるっていう局所仕様になんのメリットがあるのかわからない
ようは必要なのはＤＢとＳＱＬで条件指定したらなんでもかんでもとってこれないと駄目なんだろ？

それじゃリアルタイムで動かない

>>531
マジでＤＢ使ってＳＱＬ打ってたら間に合わないけど
遠かれど似たようなものだったら作れるだろ？
俺もタスクシステム使って組まされたときは毎回毎回
必要なオブジェクトの検索を処理の冒頭でしたもんだぜ
これがウザクてな
インスタンス消えてるときもあるしよーｗ

あるオブジェクトの子がもつすべての当たりを取得

っていうアリガチの処理だってだいたいコードが予想できるだろｗ
ステータスであるオブジェクトを特定して、
親子ツリーで子の当たりを総なめするのなｗ

あー、面倒臭ぇ、面倒くせぇ
なんでこんなことやる必要あるんだ？
シーンから引数で素直に渡せばいいだろ常考
なんの恩恵もねーよこのシステムｗ

型で列挙するのにはそれなりに意味はある。
もし、型以外のキーで列挙すると、列挙した後に、正しい型へのキャストと、正しい処理への分岐が
必要になる。

if( hoge *=dynamic_cast< hoge *>(p) ){}
else if( piyo *=dynamic_cast< piyo *>(p) ){}
・・・

>>533
そんなの下ごしらえの仕方だろ？
どーにでもなる話の議論は無しの方向で

いや、型以外のキーで検索したら、どう頑張ってもダウンキャストが必要。

>>482
> わざわざ生存管理をタスクシステムにとられちゃうのが納得いかない

これは
『ボクチンのタスクシステムはねー、手広く且つ決め細やかな謎サービスを
提供してくれるんだー。ほんとお節介な奴で困っちゃうよー。グヘヘ』
という惚気話だろう

生存管理ってなんだ。メモリアロケータを内包しちゃってるのか？ゴミだろ

>>536
ん？
君の立ち位置がよくわからない
内部でdeleteしちゃってるようなのは駄目って言ってるの？

>>533
グヘヘ、っていうのはそもそもの肝かもしれない。
グヘヘ、と思って有り難がってるからこそ、
そんなやつらがムリヤリ頑張ってるからこそ、
こんな野暮ったい仕組みが残ってしまうのかもね。

×>>533
○>>536

タスクシステムと呼ばれるものの本来の役割、本旨は何かを探れば
生存管理なんてのが枝葉、装飾、後付け機能だということがわかるでしょ

本来の役割って何ですか？
ギャラクシアンを動かすこと？
無能下請けをタスクの殻に閉じ込めること？
無駄な仕事を作って自分の居場所を確保すること？

>>541
キミらの本音を聞きたいね。
俺は

> 無駄な仕事を作って自分の居場所を確保すること？

だと思ってる。ただし、これはどんな職場にも見られる現象であり、
タスクシステムの人々を格別非難しようというもんではない。

本来の役割、本旨とやらに言及しない限りは。

関連性の希薄な例え話が大好きで、おつむの出来がとても残念な
ファイルシステム君の真似をすると

正体を暴きたければ服をひん剥けということ。男の子なら分かるでしょ
生存管理云々についてなんやかんや議論してる連中の正体というのは
服をひん剥いてもらってるのに、なぜかパッドとかタンポンに着目してる。
匂いを嗅いで臭いとか言ってる。それがアンチ。話のピントがずれてる。
要領が悪いということ

実行待ちキューに登録されたタスクを順次実行する。これが本旨。
まずここを否定するタスクシステムは疑ってかかるべきだ。傍系の始まりは
この辺りだ。

ここを基準に考えれば、例えばOBJ生存管理（ゲームルール上の生死であれ
メモリ割り当ての話であれ）なんていうものが傍系というか枝葉というか
それはユーザー側のOBJコントローラじゃねーの、ということに気付くはずなんだが…

ゲームルール上のOBJの生死はタスクシステムの関知するお話ではない
メモリ割り当て上のOBJの生死もタスクシステムの関知するお話ではない

deletemarkerを定義するのはユーザー。操作するのもユーザー。
deletemarkerを参照してOBJを殺すのはユーザー定義のタスク

あるいは>>500-501の主張。参照を管理するmanagerを用意しなさいとかいうもの。
具体的に何をどうマネージメントしてくれるのかは彼らの脳内の話であるが
まぁ例えばOBJの参照関係グラフのようなものがあるとする。こういうものは
タスクシステムとは全く関係ない

>>544-545
へー。それなら話はわからんでもない、というか少し興味は持てる。
そういう、小さい部分だけの話なら、胡散臭さも入る余地無し。

タスクという単位でクライアントをパラメータ化し、順に処理されるだけのものだと？
タスクシステムは、GoFで言うとコマンドパターンが近い？　そういう例えは不要？

>ID:TTUz744b
ごめん
何が言いたいのかさっぱりわからない

タスクシステムは要らないといいたいんだよ。

>実行待ちキューに登録されたタスクを順次実行する。これが本旨。

こんなもん無くても、普通に書けば上から順番に逐次実行されていく、
これがノイマン型コンピュータの基本。

何がややこしいって、
タスクシステマーが本当に欲しがってる物は、タスクシステムではないということ。

デジタルコンピュータの登場当初から存在していた
『プリエンプションなしの タスクを周期駆動でぶんまわす』
古典的なリアルタイムシステムのプログラム構成を知れ

こういうこと

for(;;)
{
sub1();
sub2();
sub3();
wait();
}

はいおわり。こんなの知ったって何にもならないよ。さようなら。
駆動原理も関係ないよ。単にプログラムがどのタイミングでキックされるかってことだけだからな。
このスレの論点は、キックされた後の更新処理。
キックのされ方に興味あるのは誰かさんだけ。

＞このスレの論点は、キックされた後の更新処理。

STGすらつくれないアンチにはこまったものだ

俺がきれいな方程式を立ててやろう。

やねうらお式奇形タスクシステム　-　ID:TTUz744b式タスクシステム　=　タスクシステマーが求めてたもの

両辺をタスクシステムで割ると、

やねうらお - ID:TTUz744b = 求めていたもの

つまり、ID:TTUz744bは、誰もが最も興味の無い部分をわざと持ち上げ、スレを荒らす。
やねうらおの絞りカスのような存在。

だって、だれも駆動原理(周期駆動etc)になんか興味ないでしょ。
イベント駆動→イベントがあるとキックされる
周期駆動→周期的にキックされる
で？？だから？？でしょ。キックされた後の更新処理が論点なのに。

肝心なことは何も言わないのなら、ID:TTUz744bの存在自体が意味が無い。
これだったらまだやねうらおの方がマシともいえる。

>>553
あたりまえだろ
ここはアマチュア限定のスレなんだから。

童貞の妄想するセックステクニックの話に
リア充が突っ込みするような真似はしないことだ。

ちなみに、タスクシステムと周期駆動は何の関係も無い。
タスクシステムは周期駆動のためにあるわけではない。
周期駆動させてるのはSleep関数。
こいつで一定間隔でOSからキックしてもらうことで周期駆動している。
タスクシステムは状態更新をするためにある。

今のスペックならSQLでもいけそうだな
組み込み用DBも商用になってきたし
そろそろゲーム用DBも出てくるかな
同人レベルならSQLiteでも間に合いそうな気がするが

データ処理にSQL使えるようになったら生産性段違いだよなぁ

>>557
はぁ？

だからね、俺がね、何が言いたいかって言うとね、
イベント駆動/周期駆動はそのプログラムの待機の仕方を表しているに過ぎないんだよ。
Windowsだと、
イベント駆動だとGetMessageでメッセージが来るまで待機、
周期駆動だとSleepで一定間隔待機。
だけどね、待機しているってことは、その間そのプログラムは走って無いってこと。
プログラムが走って無いときのことを論点にして、何の意味がある？

他の人がプログラムが走っているときの話をしているのに対して、
ID:TTUz744bはプログラムが待機しているときの話をしている。
他の人が自プログラムのことを話しているのに対して、
ID:TTUz744bはOSのことを話している。(そりゃ自プログラムが待機中のことを議論するんだからそうなるわな)
俺がID:TTUz744bは左巻きだとか、論点がズレてるとか言ってるのはそう言うこと。

一週間たっても全く成長がないのだな

　　　　　　　　　　_Y_
　 　 　 　 　 　 ｒ'｡∧｡ｙ.
　　　　　　　　　ゝ∨ノ　　　　　バカがタスクシステムに　 　 　 　 ,,,ｨf...,,,__
　　　　　　　　　 ）~~（ 　 　 　 　 　　　幻惑されてる間に 　 　_,,.∠/ﾞ`'''t-nヾ￣"'''=ー-.....,,,
　　　　　　　　　,i　　 i, 　 　 　 　 　 　　　　　　　　　　　　　,z'"　　　￣￣　／nﾞﾞ''''ー--...
　　　　　　　　 ,ｉ>　　 <ｉ 　 　 文明はどんどん発達し　 　 r”^ヽ 　　　　　く:::::|::|:::〔〕〔〕
　　　　　　　　 ｉ>　　　<ｉ. 　 　 ていく・・・・・・。　　　　　　入_,..ﾉ ℃ 　　　　￣U￣＿二ﾆ＝
`=.,,ｰ- ...,,,__ |,ｒ'''"7ヽ､|　 __,,,... -ｰ,,.=' 　 　 　 　 　　　 　 >ーｚ-,,,...--,‐,‐;;:'''""~
　　~''':x.,,　 ~"|{ G ゝG }|"~　 ,,z:''" 　 　 　 　 　 　 　 　 　　　 ＿＿＿
　　　　　 ~"'=| ゝ､.3 _ノ |=''"~ 　 　 　＜ー＜> 　　　　　　　　／　　l￣￣＼
　　　　　　　 .|）) 　　　(（| 　 　　　　　/￣￣ﾞｉ;:､ 　　　　　「￣￣￣￣|￣|￣￣￣＼
　　　　　　　　　　　　　))| 　 　 　 ｒ'´￣「中]￣｀ヾv､　　　`-◎──────◎一'
　　　 　　　　　　　　　　　　　　　├―┤＝├―┤　|li:,
　　　　　　　　　　　　　　　　　　　|「￣ |ｉ￣ｉ|「.//||「ｌn|:;
　　　　　　　　　　　　　　　　　　　||//__|Ｌ_」||＿_.||ｌ」u|:;
　　　　　　　　　　　　　　　　　　　|ニ⊃|　　|⊂ニ| || ,|/
　　　　　　　　　　　　　　　　　　　|＿. └ｰ┘ .＿| ||/
　　　　　　　　　　　　　　　　　　　ﾍ　「￣￣￣|　/

>>557はさすがに誤爆だと信じたいｗ
トンチンカンにもほどがあるぞｗ

>>560はたとえ話や「ぐぐれ」やAAでお茶を濁すので、モヤモヤする。
なぜもっと素直にID:bJbP9YDC氏と話し合えないのか。

stateパターンでググレ
まぁ、やねうらお以外がデザパタ言うとキチガイ扱いされるのよね
不思議

ああ、くやしいから人格非難に走るのか
なるほど

WaitForSingleObject関数すら知らないのか
ID:bJbP9YDC　はキチガイだ

やべ　ついｗ

>>564
「アンチの想像を絶するアマチュアの妄想テクニックに感じちゃう！くやしい！…ﾋﾞｸﾝ…ﾋﾞｸﾝｯ」ｗｗｗ

ヘイヘイ
連投が許されるのは小学生までだぜ

>>565
WaitForSingleObjectはイベント駆動と周期駆動の両方に使えるよね。
だからどうかしたの？どっちにしろ、待機中のことを議論しても意味無いわけで。
プログラムがどういう風に待機するかは興味の範疇に無いな。
他の人もそうだと思うけど。

>>562
だって…
「おんなのこのからだはそんなもんじゃない。
ぼくが望んでいたのはそんなんじゃない！
ぱんつの中はもっといい匂いがするはず！」
って言われても困るっていうか…

Windows用ゲームの作り方についてはあまり詳しくない俺でも
>>473を読んだ瞬間に、この子はWindows用の2DSTGはおろか
紙芝居エロゲすら満足に作れない妄想プログラマ君なのだと
確信したのね

俺はお前が周期駆動云々言い出したのみて、
関係ないことをさも関係あるかのように語ってみせるペテンだと確信したよ。
タスクシステムと周期駆動に何の関係があるのか書いてみ？

>>569
おめーいっぺん裁判でもいいから訴えられてみろ
そして法廷で「そんなこと知りません」って言って

お願い