2ちゃんねる ★スマホ版★ ■掲示板に戻る■ 全部 1- 最新50  

■ このスレッドは過去ログ倉庫に格納されています

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

1 :名前は開発中のものです。:2009/08/19(水) 19:48:11 ID:rSBdI4uX
タスクシステムについての議論、相談、質問、雑談などのスレです

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 :名前は開発中のものです。:2009/08/19(水) 19:48:21 ID:rSBdI4uX
古典タスクシステム(このスレでは「>>2」と呼ぶ)

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

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

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

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

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

3 :名前は開発中のものです。:2009/08/19(水) 22:56:42 ID:M5mIplU8
裸の王様スレ

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

5 :名前は開発中のものです。:2009/08/20(木) 00:53:25 ID:OiKGDvQB
すっぱい葡萄君は元気だなぁwww

6 :名前は開発中のものです。:2009/08/20(木) 01:11:23 ID:2RGTg85n
>>4
すごい
うまくできてる
次回からテンプレ入り確定だな

7 :名前は開発中のものです。:2009/08/20(木) 01:43:23 ID:jEontBuc
火を見たこと無い原住民に「話に聞くマッチとやらのメリットを教えてくれ」と聞かれたとする。

そんな原住民相手に「マッチとライターを比較したメリット」とか答えるのは根本的に間違ってる。
彼らが理解できないのは実は「マッチ」ではなく「火」。

「タスクのメリット教えろ」ってのも同じ。「タスクとアクターを比較したメリット」とか答えるのは間違い。
アンチが理解できないのは実は「タスクシステム」ではなく「ゲームの作り方」なんだよね。

そこを勘違いして、タスカーは「ゲームの作り方ぐらい理解してるだろ」という前提でタスクの利点を
説明してるのがそもそもの間違い。

8 :名前は開発中のものです。:2009/08/20(木) 20:33:28 ID:ywCP/lZQ
>>1
            :: ___  :::._ ::
         ::  ?         `?  `丶、::.     / ̄ ̄ ̄ ̄ ̄`ヽ
         .:://                  \::.     ,? __       |
    ::ー=?彡           \     ヽ::.  |    /      .|
    :://         \  \   ヽ        ::. |   /   (⌒⌒) |
  .:::/      i{     ヽ   ヽ   ハ     ::.     ̄ ̄   ヽ/ |
  .:://    /  __八       iィ? i丁`ヽ| \/ |::  \         ノ
 .://      〃 「  、    | \  | i | /\ |::    厂 ̄ ̄ ̄ ̄
  ::?   |  / i jxミ \{\|  ノ)ノ? |   }  八::.
  ::i  .イ {   {? ):ハ     x=?ミ |  ハ    \::.
  ::| / :|i 八   ハ{ {r':xi|        / j / !  }   \::.
  ::|?.:|i  \ ? ゞシ         / /  ノ   ハ }ヽハ::.
     人   i \ \   ' r  ‐┐/イ ノr‐‐くー=ミjノ::
     ::ヽ 丿 ゝ ̄    ー一'? .イ(  ̄`ヽ /  ヽ.______  ::.
     .::///  ノ≧=‐----r‐≦  j(  ̄ ̄)?            `丶、::.
     ::/イ  /}ハノハノハ ( ̄ ̄ ̄   ̄ ̄                 )::
      .::|/ /⌒{≧「 ̄ノ  ̄ ̄ ̄ ̄/ x≦? 厂 ̄ ̄ ̄「 ̄ ̄    .イ::
        .::/  {  マハ `ヽ /   (,/    /     /    -‐=ニ:::
        .::〃 ハ  \ `ー-----/')?    /     (? ̄「::
      ::// / ?    >‐‐一' /_____ ノ{       ) /::
   .::/ /   ノイ > '?     .イノハノハノハ}小、    / /::
   ::ヽ /     {./       `ー――一く⌒! lヽ. /./::
    .::〉^⌒ヽ/            xr――一' ノ j  V?::
   .:/   /8    />x _フ? |        厂`⌒?::
  .::/  /   8  /  {    l   |     /:::

9 :名前は開発中のものです。:2009/08/21(金) 00:45:15 ID:7MXGbqnZ
C#4.0でタスクシステムがサポートされるらしい。

10 :名前は開発中のものです。:2009/08/21(金) 02:23:38 ID:jWrj/4kB
>>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 を作って解決。
>
>
> メリットとか役割とか明確ですばらしいね。
> それにひきかえゲーム屋のタスクシステムときたら、メリットひとつ挙げられやしない。

11 :名前は開発中のものです。:2009/08/21(金) 04:19:51 ID:1ch70Fui
C#はゲームに向いてないんじゃないのか

12 :名前は開発中のものです。:2009/08/21(金) 06:47:40 ID:JQiTyHTX
>10
メリット厨は権威に弱いのかな?


13 :名前は開発中のものです。:2009/08/21(金) 09:03:21 ID:jCwBirOU
「タスクシステム」と呼ぶなよ

14 :646:2009/08/21(金) 17:31:04 ID:+xQHzCyI
今度は『.NET4.0のTPLもタスクシステム!』か。大胆な●●認定を始めたもんだねぇ
それを言うならまずOpenMPやTBBもタスクシステム認定しないと辻褄があわないねぇ
なのになぜあえてTPLなんだろうねぇ。クルクルパーの発想はいつも斜め上杉て面白いねぇ

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

15 :名前は開発中のものです。:2009/08/21(金) 18:20:12 ID:7MXGbqnZ
>>10
出てたとは。
落ちてたんで気付かなかった。

16 :名前は開発中のものです。:2009/08/21(金) 18:37:14 ID:jCwBirOU
>>14 が必死すぎて痛い件

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

17 :名前は開発中のものです。:2009/08/21(金) 18:52:09 ID:jNfvN1VN
>>9>>15
逐次計算すること前提に作られたバカでも分かる簡素な仕組みと
並列計算を前提とする仕組みではまるで正反対のものだよ

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

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

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

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

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

18 :名前は開発中のものです。:2009/08/21(金) 18:53:00 ID:wTYx4EIQ
と、いうことにしたいんですね?:)

19 :名前は開発中のものです。:2009/08/21(金) 19:07:15 ID:2g4wYWAz
タスクが使われてるからタスクシステムなんて寝言ほざいていいのは小学生までだな
タスクシステムを拡大解釈したがるバカに付き合うと終いには
「この世界の仕組みこそがタスクシステムなんだよ」「な、(以下略)」とか
言い始めるぜ

20 :名前は開発中のものです。:2009/08/21(金) 19:47:04 ID:TngMECRA
バックエンドの構造は単純にする。これがタスクシステマーのドクトリンなんだよ

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

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

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




21 :名前は開発中のものです。:2009/08/21(金) 19:55:50 ID:TngMECRA
タスクシステム(>>2)はparallel computingなんて全く眼中に無いな
そんなもんサポートし始めたら排他制御やら何やらで一気に複雑化。
デバッグも複雑化。並列処理なんて後回し。必要に迫られたら
アドホックな付け焼刃な拡張を加えて対応。そういうもの

22 :名前は開発中のものです。:2009/08/21(金) 19:58:58 ID:JQiTyHTX
言葉尻に囚われて、概念的なものを見過ごしてる人たち多すぎwww

23 :名前は開発中のものです。:2009/08/21(金) 20:01:51 ID:TngMECRA
×周期的に巡回UPDATEるだけの自称システムしか共有できなかった
○周期的に巡回UPDATEするだけの自称システムくらいしか認識を共有できなかった

24 :名前は開発中のものです。:2009/08/21(金) 20:20:37 ID:JQiTyHTX
>20
ヒドイ環境で仕事してるんだなw

いわゆる底辺ってやつ?

25 :名前は開発中のものです。:2009/08/21(金) 21:03:26 ID:2g4wYWAz
タスクを否定するアンチは阿呆。これは確定。
TPLやMT Frameworkをタスクシステムとか抜かしてホルホルしてるタスカーは
半島民族。これも確定


26 :名前は開発中のものです。:2009/08/21(金) 21:49:21 ID:TngMECRA
適当に書きなぐった後に気付いたがコンセンサスが形成できないって
かなり腹痛が痛い話だね。まぁいいか

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

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

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




27 :名前は開発中のものです。:2009/08/21(金) 23:32:56 ID:wz4uifX+
裸の王様の見えない服にまた迫がついたのか?(失笑w

28 :名前は開発中のものです。:2009/08/22(土) 00:20:32 ID:47K4Zv3C
>>18
で、なんでタスクシステム=ファイルシステムなんだい?
そういうことにしたいんだろう?さっさと作文書きなよ:D

29 :名前は開発中のものです。:2009/08/22(土) 00:43:07 ID:ycLxVhis
前スレでリストを実装できないstl使いの話があったが・・・
最近の新人はデザインパターンとか、色々勉強はしてるんだが
それら教科書に載ってる手法だけを組み合わせることがプログラムを作ること、
と考えてる節があるんだよね・・・

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

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

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

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

30 :名前は開発中のものです。:2009/08/22(土) 01:44:28 ID:y49UgVwu
うわぁ・・・。ほんとに、「馬鹿には理解できない」と言い続けるしかないんだね。

31 :名前は開発中のものです。:2009/08/22(土) 01:46:53 ID:M5+zp9Te
裸の王様に出てくる仕立て屋ってなかなかの根性だよなw

32 :名前は開発中のものです。:2009/08/22(土) 02:02:15 ID:3R7EG+XX
>>7
なるほどな…
それでいつまでたってもメリットが理解できないアンチは最後に「火なんて幻」としか考えられなくなるわけかwww

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

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

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

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

34 :名前は開発中のものです。:2009/08/22(土) 02:20:38 ID:43RWv3KZ
天才プログラマー要製ギプス
http://www.sun-inet.or.jp/~yaneurao/intensive/ggg/log1.html

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

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

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

35 :名前は開発中のものです。:2009/08/22(土) 02:22:05 ID:6Cf+8hWL
こういうくだらないこと書く人に限って
実際にはゲーム作れなかったりするんだよね。
ゲーム作ったって証拠も出さないし。
信者もアンチも作品出して優劣決めろよな。

36 :名前は開発中のものです。:2009/08/22(土) 02:22:10 ID:43RWv3KZ
そもそも、キャラクタの自立性を確立するのはとても大変なこと。
やねうらおも自分で言ってる。

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

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

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

37 :名前は開発中のものです。:2009/08/22(土) 02:24:39 ID:43RWv3KZ
自立性のあるキャラクタ云々がそもそもの間違い。
発想の一番最初から既に間違っている。
なので、どこまで行ってもうまく行かない。
何にもならない。無駄。

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

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

39 :名前は開発中のものです。:2009/08/22(土) 02:38:58 ID:M5+zp9Te
仕様が明確になってないのをむりやりプログラムで解決しようとするからなぁ

40 :名前は開発中のものです。:2009/08/22(土) 02:45:35 ID:3R7EG+XX
>>38
引数君と同じ考え方だね。
stdoutやheapが使えないタイプ?


41 :名前は開発中のものです。:2009/08/22(土) 02:52:40 ID:47K4Zv3C
まーたやねうらおの自分弄りが始まったのか。本当に気持ち悪いやつだ
10年近く前の己の戯言を何度も引っ張り出してまで話題にしてほしいのか?

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

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

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



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

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

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

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

44 :名前は開発中のものです。:2009/08/22(土) 03:11:01 ID:3R7EG+XX
>>42
> ただ、他のキャラクタとかかわりを持たなければならない処理が増えてくる段階に入ると、
ほとんどのゲームではかかわりって言ってもコリジョンとサーチぐらいで必要十分な気がするが
そんな多種多様な関係が必要になるケースって何を想定してるんだろうなぁ…
チームワークで動くAIとかか?

具体例プリーズ

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

46 :名前は開発中のものです。:2009/08/22(土) 03:55:32 ID:43RWv3KZ
訂正: 格→各 (眠い・・・)

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

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

48 :名前は開発中のものです。:2009/08/22(土) 04:14:24 ID:3R7EG+XX
>>45
関係の種類じゃなく順番だけの問題なのね。

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

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


49 :名前は開発中のものです。:2009/08/22(土) 04:33:16 ID:yhBPAMbr
キャラクタって概念がよくわかんないんだけど。
要するにクラスのことなんじゃないの?

>>45
def shotgun(pos, vec)
taskA = new RedBullet
setBullet(taskA, timeA, vecA)
/* 略 */
chainProcess(taskB, taskA, taskC, taskA)

こんなもんでいいんじゃないの?
SlimeBeth = new Slime("SlimeBeth.jpg")
SlimeBeth have a shotgun
みたいな書き方で持たせることもできるし。

自立性のほうはどうしてもわからんがw
理想的なクラス設計ってことなんじゃないのか?

50 :名前は開発中のものです。:2009/08/22(土) 04:56:19 ID:43RWv3KZ
>>48

お前が今説明した仕様をそっくりそのままコードにすりゃ良いだろ。
仕様とコードが一対一で対応している誰が見ても分かりやすい理想的なコードが出来上がる。
一体何の問題がある?

それに、
>関係の種類じゃなく順番だけの問題なのね。
とも言い切れない。
自タスクだけで完結する処理?タスクのupdateで処理:タスクシステムもしくは〜Managerで処理;
だと、タスクシステムに本来の目的とは違う機能がどんどん追加されていって、
いずれなんだか良く分からない謎の「装置」にしたてあがる。
タスクシステムの実装がゲームによりけりで定義がはっきりしないのも、その辺に原因があるのだろう。
タスクが自立して出来そうなことだけをタスクにさせて、それ以外をタスクシステムなり〜Managerなりが
タスクの生命維持装置のごとく面倒を見るという自立してるんだか、して無いんだか、
分かりやしない構図は無意味だと思うね。(切り分け的に)

51 :名前は開発中のものです。:2009/08/22(土) 05:05:43 ID:WSVgl+j3
>26
> >>24
> このご時世、底辺のヒドイ環境でもなければタスクシステム(>>2)に
> スポットライトが当たることはない。周期的に何かのコレクションの
> 要素を巡回してUPDATE。そんだけ。それ以上もそれ以下もない。

その程度のことしかやってないんなら、底辺だね。
まぁ頑張って這い上がってくれ。

52 :名前は開発中のものです。:2009/08/22(土) 05:06:50 ID:43RWv3KZ
>>49
それだと、taskAの同じ処理が二回実行されると思うのだが。

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

53 :名前は開発中のものです。:2009/08/22(土) 05:14:40 ID:43RWv3KZ
それでも処理の順序を動的に変更したい場合はあると思うよ。
たとえば、各キャラクタの座標系に親子関係がある場合などな。
でも、そんな場合でも、キャラクタに据えついた関数の呼び出し順を動的にするんじゃなくて、
キャラクタが列挙される順番を動的にすべきだろう。

54 :名前は開発中のものです。:2009/08/22(土) 07:29:27 ID:d7e04I9F
>>51
まーた
『ボクのエターナルフォースブリザードシステムはそんなもんじゃない。もっとすごい!』
が始まったのか。永遠の小学生だな


55 :名前は開発中のものです。:2009/08/22(土) 07:56:47 ID:WSVgl+j3
>54
> 『ボクのエターナルフォースブリザードシステムはそんなもんじゃない。もっとすごい!』
自己紹介乙w
さすがに馬鹿は思考短絡してて分かりやすいなw

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

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

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

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

56 :名前は開発中のものです。:2009/08/22(土) 08:27:05 ID:B8KZrB8g
>>42
> ただ、先は無いぞ、継続できないぞ、袋小路だぞ、と。
> 某やねうらおの人生も、なんかそんな感じするでしょ。なんとなくなんとなく。

年収何千万もある人の人生が袋小路に見えるのですか。そうですか。

57 :名前は開発中のものです。:2009/08/22(土) 09:21:31 ID:3R7EG+XX
>>50
”そのままコードにする”って…
「aに1から100までの数を加算しなさい」って仕様をベタ書きで全部書くとわかりやすい理想のコードという感じかな?
a+=1;
a+=2;
・・・
a+=100;
for 使って i でカウントして…なんて書いてないしわかりにくいから使わない…
って極端だが意味的にはこんな感じに聞こえる。

for使ったコードでも「仕様そのままのコード」だし
タスク使っても「仕様そのままのコード」なんだけどね。

で、forやタスク使ったコードの場合「1から10000に仕様変更」とかでも対応簡単。

58 :名前は開発中のものです。:2009/08/22(土) 09:30:15 ID:M5+zp9Te
なんか全然関係ないこと言い出したなw

59 :名前は開発中のものです。:2009/08/22(土) 11:13:51 ID:xK9Ysxiu
accumulate(count_upto(1,100), 0, _1 + _2);

60 :名前は開発中のものです。:2009/08/23(日) 00:21:36 ID:sfWgjnCc
>>50
>いずれなんだか良く分からない謎の「装置」にしたてあがる。
タスク自体はコンテナでしかない。
それらを扱うための装置がちんぷんかんぷん=クラス設計gdgdなのが駄目なんじゃないの?
STLやBoostなんて〜Manager相当のものがある(らしい)けど、
その設計部分を意識せずともSTLやBoostは扱えるじゃん。例外はあるけど。

>>52
Bの後に1回、Cの後に1回実行するために書いたんだが。
chainは鎖と言う意味で、タスクを鎖のように順次実行する、という意味でもあったのだが。
書いてて思ったんだが、タスクシステムでもなんでもないな。

>理解に苦しむ。本当にその必要があるのか、今一度問いたい。
デザイナーにも書かせられる程度に設計が楽になる。
ここらへんはクラス設計とかデザインパターンとか勉強してくれw

61 :名前は開発中のものです。:2009/08/23(日) 00:47:29 ID:2kQ/pU4I
でました裸の王様の仕立て屋
相手に説明する立場なのに「当然、知ってるよね?ニヤニヤw」

頭パーなんじゃないかとw

62 :名前は開発中のものです。:2009/08/23(日) 01:01:30 ID:5eA2OfcD
>>57
だからタスカーは根本的にわかってないんだよ・・・
>>7
の原始人相手に「マッチ(タスク)がわかんないなら火打石(for)で説明」なんてしたって同じこと。
アンチのレベルに合わせてfor程度までレベルを下げればいくらアンチでも理解できるだろう、と思ったんだろうけど
根本的に次元が違うんだって。アンチは。

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

63 :名前は開発中のものです。:2009/08/23(日) 01:05:55 ID:sfWgjnCc
>>61
裸の王様の仕立て屋という比喩がいまいちよくわからないのだが。
今一度説明して頂けないだろうか?

64 :名前は開発中のものです。:2009/08/23(日) 01:41:38 ID:L1QTm1mn
>61
共通知識として、どのあたりまで低いレベルを想定しているのかよくワカランな。
そんな>61のような馬鹿には『自己研鑽』という言葉を贈ろう。

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



65 :名前は開発中のものです。:2009/08/23(日) 03:19:26 ID:pg8z5vmP
>タスク自体はコンテナでしかない。
タスクがコンテナな時点で終わってるって事。
タスクはどっちかって言うと処理なのに、データ主体でコンテナとか言い出す時点でもう駄目だろう。

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

66 :名前は開発中のものです。:2009/08/23(日) 03:52:13 ID:pg8z5vmP
キャンプ行くのにマッチを持っていった方が良いかどうか話し合ってるときに、
火打石の説明しだすやつがいたら、
「石?なんかマッチと全然関係ないこと言い出したなw」
と普通なるわな。

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

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

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

67 :名前は開発中のものです。:2009/08/23(日) 04:02:08 ID:pg8z5vmP
訂正 >>42>>43

68 :名前は開発中のものです。:2009/08/23(日) 05:34:27 ID:sfWgjnCc
>>65
処理と言うか、描画処理だけじゃないの?
うちはコンテナに乗せたデータを描画処理にかける部分と、
コンテナに乗せたデータを操作する部分を独立させてるけど。

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

69 :名前は開発中のものです。:2009/08/23(日) 06:11:35 ID:AKyiyqYR
>タスクはどっちかって言うと処理
タスクは処理だけでもデータだけでもないのでは
両方あってタスクなんじゃないの

70 :名前は開発中のものです。:2009/08/23(日) 09:20:09 ID:2kQ/pU4I
>>63
>>4

71 :名前は開発中のものです。:2009/08/23(日) 09:35:54 ID:0s3Ql9fI
>>66
>>7

72 :名前は開発中のものです。:2009/08/23(日) 10:00:09 ID:0s3Ql9fI
>>66
> キャンプ行くのにマッチを持っていった方が良いかどうか話し合ってるときに、
「マッチ?なにそれメリット何?火って何?」
ってアンチがキャンプなんて行けるのかねwww

73 :名前は開発中のものです。:2009/08/23(日) 10:29:02 ID:2kQ/pU4I
自分が全然関係ない話をしている自覚はあるんだろうか?

74 :名前は開発中のものです。:2009/08/23(日) 13:46:53 ID:/cg6wFz1
>>64
> オマエは別な意味で馬鹿だな。
別な意味ってどんな意味?ww
良い意味で馬鹿、みたいな?www

75 :名前は開発中のものです。:2009/08/23(日) 14:12:31 ID:J6kxV+fG
このスレも男女論の「結婚のメリット」スレと同じで不毛な議論エンドレスに続けてるねぇ…

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

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

76 :名前は開発中のものです。:2009/08/23(日) 15:39:05 ID:iYL9j5nG
不毛な議論を隔離するためのスレですから。

順調に機能してますよ。

77 :名前は開発中のものです。:2009/08/23(日) 16:08:05 ID:pg8z5vmP
>タスクは処理だけでもデータだけでもないのでは
>両方あってタスクなんじゃないの

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

78 :名前は開発中のものです。:2009/08/23(日) 16:34:26 ID:RPzAodys
>>77
> 何故、処理とデータを一緒くたに制御する必要がある?

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

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

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

80 :名前は開発中のものです。:2009/08/23(日) 18:49:49 ID:pg8z5vmP
そもそも、OSのprocessがああいう形をしているのは、
アプリケーション開発者にカーネルを自由に書き換えさせるわけにはいかないから、
仕方なくああなってるだけなのだが。

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

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

81 :名前は開発中のものです。:2009/08/23(日) 18:49:59 ID:3ZApiX4t
>>77
実装の方法がいろいろあるからまずいんじゃない?
それと相まって実装方法ごとに信者がいるとしか。

82 :名前は開発中のものです。:2009/08/23(日) 18:58:55 ID:pg8z5vmP
実装方法がいろいろあってもかまわないのだが、
データ構造と制御構造を一緒くたにした時点で、THE END。

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

83 :名前は開発中のものです。:2009/08/23(日) 19:02:40 ID:pg8z5vmP
変な話、別々に実装したほうがまだマシという話も。

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

84 :名前は開発中のものです。:2009/08/23(日) 19:08:37 ID:pg8z5vmP
データシステムの方はそれなりに便利そうだが、制御システムはどう考えても要らないよな。
だって、普通に関数を呼び出したい順に書けばいいだけだから。

85 :名前は開発中のものです。:2009/08/23(日) 19:42:17 ID:J6kxV+fG
頭の中だけでプログラムの動きがほとんどシュミレートできるレベルの
ベテランプログラマじゃないなら、シーケンシャルな記述の方が安全でメリットあるだろう。

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

86 :名前は開発中のものです。:2009/08/23(日) 20:24:05 ID:3ZApiX4t
>>84
制御システムがあるから楽に扱えるんじゃん。
利用してる側からだとそのシステムの中身を意識しなくてもよく、
それを扱うための関数だけ知っていれば描画から何まで自動的にやってくれる。
これが利点だよ。

87 :名前は開発中のものです。:2009/08/24(月) 00:41:51 ID:CPwmHq/c
>>45
タスクシステムのタスクとはシステム内部の実行待ちキューに投げ込む処理単位(タスク)のことだぞ。

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

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

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

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

88 :名前は開発中のものです。:2009/08/24(月) 00:46:15 ID:CPwmHq/c
>>45
だから

処理単位A::処理1
処理単位A::処理2

こんなことはタスクシステムの知ったことではない。意味分かるか?
システムが把握しているのは

  「ユーザーがシステムの実行待ちキューにタスクA、タスクBを突っ込んできた」

それだけ。だからタスクAの中に処理1だの処理2だの複数の処理ステップがあるというなら
それはユーザー定義の処理の中のお話。システムが関知するところではない
であるから、タスクシステムのお話をするなら

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

こういうことになる。そしてこの場合

実行待ちキューに処理単位Aを追加
実行待ちキューに処理単位Bを追加
実行待ちキューに処理単位Cを追加

こういうこと

89 :名前は開発中のものです。:2009/08/24(月) 00:49:25 ID:CPwmHq/c
>>45
訂正
×     今、タスクAとタスクBとタスクBがあって
○     今、タスクAとタスクBとタスクCがあって
 

90 :名前は開発中のものです。:2009/08/24(月) 00:49:59 ID:lqgMscfV
だったら普通に関数並べれば良いだろ。
タスクA();
タスクB();
タスクC();
で問題ないだろ。なぜ実行待ちキューなんかで処理を遅延させる必要があるんだ?

91 :名前は開発中のものです。:2009/08/24(月) 00:53:42 ID:lqgMscfV
知ってのとおり、関数呼び出しはスタックになってる。
では、なぜキューは無いのかというと、ノイマン型コンピュータの実行の基本はFIFOだから、
特別な仕組みを用意しなくても、キューなんだよ。
だから、わざわざ実行待ちキューとか作る意味無いんだ。

92 :名前は開発中のものです。:2009/08/24(月) 01:08:45 ID:CPwmHq/c
>>90
ゲーム起動から終了まで一貫して
タスクA→タスクB→タスクC
こういう手続きと確定しているならばひとつのタスクにすればいい
わざわざ別の処理単位に分ける必要はなかろ

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

93 :名前は開発中のものです。:2009/08/24(月) 01:09:03 ID:joUG/aWl
>90
物量補完のために雇った下請け連中に、システム部分まで触られたくないからだよ。
いわゆるタスク(ウチはタスクとは言わないけど)の制限内でモノを作ってもらうのが原則。

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


94 :名前は開発中のものです。:2009/08/24(月) 01:24:15 ID:lqgMscfV
>こういう手続きと確定しているならばひとつのタスクにすればいい

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

95 :名前は開発中のものです。:2009/08/24(月) 01:42:02 ID:cdmKSMxd
>>90
処理は遅延しないよ。
キューの中にあるタスクがすべて実行される。
だから、関数を並べるのと大差ない。

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

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

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

96 :名前は開発中のものです。:2009/08/24(月) 01:42:08 ID:lqgMscfV
>>93
その理論だったら、ゲーム以外のもの作ってるプロジェクトはどうやってるんだって話になる。
プロジェクト管理にタスクシステムが便利だって言うんなら、アプリプログラマ達にも教えてあげたら?

97 :名前は開発中のものです。:2009/08/24(月) 01:53:36 ID:lqgMscfV
>>95
>処理は遅延しないよ。

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

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

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

98 :名前は開発中のものです。:2009/08/24(月) 02:03:42 ID:lqgMscfV
でもお前らの話聞いてると、どうもキューというより、ただのリストのようだな。

99 :名前は開発中のものです。:2009/08/24(月) 02:07:36 ID:vj+BTbNk
かなり昔の話だがプログラマの新人研修でSTG作れって課題出したことがあったが
特に教えたわけじゃないのにほとんどの新人がタスクシステムと同じような管理処理で
動かしてたけどな。

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

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

100 :名前は開発中のものです。:2009/08/24(月) 02:11:14 ID:CPwmHq/c
>>94
>>53
> それでも処理の順序を動的に変更したい場合はあると思うよ。
> たとえば、各キャラクタの座標系に親子関係がある場合などな。
> でも、そんな場合でも、キャラクタに据えついた関数の呼び出し順を動的にするんじゃなくて、
> キャラクタが列挙される順番を動的にすべきだろう。

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

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

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


101 :名前は開発中のものです。:2009/08/24(月) 02:13:38 ID:CPwmHq/c
× シーングラフの中のツリー構造
○ シーングラフのツリー構造

102 :名前は開発中のものです。:2009/08/24(月) 02:21:54 ID:lqgMscfV
>>100
いや、お前の言いたいことは分かるが、その主張は俺も>>82とかで述べてるので。

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

103 :名前は開発中のものです。:2009/08/24(月) 02:25:16 ID:cdmKSMxd
>>97
>登録の遅延
ポインタの移し替えだけなので10行以内に落とせる。
登録作業もnewを使わなければ誤差にすらならない。

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

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

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

104 :名前は開発中のものです。:2009/08/24(月) 02:46:34 ID:AWts9i2J
>>2
CodeZine:本格的なシューティングゲームを実現するタスクシステム(タスクシステム,シューティング,ゲーム)
http://codezine.jp/a/article.aspx?aid=297

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

105 :名前は開発中のものです。:2009/08/24(月) 02:47:01 ID:QpSYrCK9
タスク=処理関数ポインタ+ワークエリア   とある
それに加えて、複数のタスクを連結リストとして管理するために前後のタスクへのポインタを持つんだとさ

106 :名前は開発中のものです。:2009/08/24(月) 02:52:47 ID:lqgMscfV
>>103
何分けのわからないこといってるんだよ。
std::queue<void (*)()> task_queue;
task_queue.push( func ); //登録
・・・//実行まで遅延
while( queue.empty() )
{ task_queue.front()(); task_queue.pop(); } //実行

107 :名前は開発中のものです。:2009/08/24(月) 03:02:48 ID:lqgMscfV
・タスク=処理関数ポインタ+ワークエリア
 →制御構造とデータ構造をごったにしている時点で糞。
・タスク=処理関数ポインタ
 →プログラム自体が既に処理のリスト。
  動的に処理リストを生成する必要が本当にあるのか。
・タスク=ワークエリア(データ)
 →タスクという名前がおかしい。
・タスク=無能下請けを封じ込めるための檻。
 →他の方法考えろ。

108 :106:2009/08/24(月) 03:03:45 ID:lqgMscfV
訂正: while( queue.empty() ) → while( !queue.empty() )

109 :名前は開発中のものです。:2009/08/24(月) 03:25:07 ID:lqgMscfV
>>103
あと、多分だけど、>>100 はタスクシステムを処理実行の遅延目的で使ってる。
トラバースして処理を一旦バッファに蓄え、最適化した上で実行するためだろう。
CPUのアウトオブオーダーのような感じ。
制御目的でなく、最適化目的なので、こういうのは個人的にOKかな。

110 :名前は開発中のものです。:2009/08/24(月) 03:28:08 ID:lqgMscfV
ただ、それをタスクシステムと呼ぶのは個性的過ぎると思うが。
まぁ、煽りの一種だろう。

111 :名前は開発中のものです。:2009/08/24(月) 03:41:45 ID:QpSYrCK9
制御は1回きりじゃなく何回も繰り返すんだからリストに追加させるのが普通だろ
実行順は実装の仕方にもよるが

112 :ID:lqgMscfV:2009/08/24(月) 03:48:03 ID:ytTj2or3
void update()
{
  //↓何回も繰り返す処理のリスト
  update_player();
  update_camera();
  ・・・
}

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

113 :名前は開発中のものです。:2009/08/24(月) 03:48:24 ID:cdmKSMxd
>>106
そういう意味か。ごめんね。
実行速度のこと言ってるのかと思ったw
あとキューも自分で言っておきながら間違ってた。
タスクはキューじゃない。面倒くさいことさせて申し訳ない。

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

114 :名前は開発中のものです。:2009/08/24(月) 03:58:16 ID:cdmKSMxd
訂正
タスクシステムはオブジェクトが持つ描画関数をタスクの中に保持し、

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

115 :名前は開発中のものです。:2009/08/24(月) 03:58:37 ID:ytTj2or3
>>113
いや、いろんな人が居るから、>>107 という認識。


116 :名前は開発中のものです。:2009/08/24(月) 04:06:08 ID:QpSYrCK9
オブジェクト1つ1つをそれぞれタスクに割り当てれば
それぞれの情報(座標など)とそれぞれの動き(実行関数)が必要だから
ワークエリア、処理関数ポインタ共々必要でしょ

117 :名前は開発中のものです。:2009/08/24(月) 04:23:26 ID:ytTj2or3
面倒だから、俺のやり方を紹介。

//↓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 :名前は開発中のものです。:2009/08/24(月) 04:24:19 ID:ytTj2or3
>オブジェクト1つ1つをそれぞれタスクに割り当てれば
割り当てるなよといいたい。

119 :名前は開発中のものです。:2009/08/24(月) 04:37:20 ID:wlQOC+Hi
>>118
そうか?

>>117のような書き方をすると、
player/enemy構造体のメンバすべてがpublicにする必要があって、
内部的な状態も何もかもpublicになっていて凄く気持ち悪いんだけど。

タスクかキャラクターに対してひとつのオブジェクトが割り当たっているというのは
OOPの設計的には、比較的まともだと思うけどな。

120 :名前は開発中のものです。:2009/08/24(月) 04:49:26 ID:wlQOC+Hi
>>45
> タスクA::処理1→タスクB::処理1→タスクA::処理2 の順番で処理をしなければならないとする。
> そうすると、タスクに据え付いた一つのupdate関数だけで対処するのは厳しい。

典型的なタスクシステムはタスクに対してpriorityを持っていて、それによって実行の優先順位を管理できるようになっていますが?

121 :名前は開発中のものです。:2009/08/24(月) 05:56:18 ID:n42R3Xhq
配列の添字がpriorityを表現するんですね

122 :名前は開発中のものです。:2009/08/24(月) 06:00:18 ID:joUG/aWl
>96
馬鹿か? 馬鹿だろw

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

123 :名前は開発中のものです。:2009/08/24(月) 06:06:18 ID:wlQOC+Hi
>>121
いや…タスク自体に持たせてあるだろ。
古典的なタスクシステムでは必ずと言っていいほど持っていると思うが。

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

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

124 :名前は開発中のものです。:2009/08/24(月) 06:16:16 ID:cdmKSMxd
>>107
>制御構造とデータ構造をごったにしている時点で糞
クライアント側から煩わしい処理を隠すため。
描画、移動、当たり判定処理などはクライアントに見せる必要はない。

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

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

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

125 :名前は開発中のものです。:2009/08/24(月) 20:13:39 ID:I3E9CknK
タスクシステムは簡単すぐるので技術的な話題はない
だいいちどうやってタスクシステムでFPSを管理するんだ?
Windowsの設計思想にそぐわない

126 :名前は開発中のものです。:2009/08/24(月) 20:43:58 ID:ytTj2or3
>>123
その古典的なタスクシステムだと、

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

は実現できない。

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

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

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

127 :名前は開発中のものです。:2009/08/24(月) 21:41:46 ID:joUG/aWl
>113
> タスクシステムはオブジェクトが持つ描画関数をタスクの中に保持し、
> 適当なタイミングでタスクごとに優先順位を考慮しながら描画する。
> こういう認識をうちはしてるけど、君はおk?

大洗海水浴場w

128 :名前は開発中のものです。:2009/08/24(月) 22:18:52 ID:rAt+H780
タスク処理2をタスクCに分けて
タスクA→タスクB→タスクCじゃ駄目なの?

129 :名前は開発中のものです。:2009/08/24(月) 22:38:55 ID:cdmKSMxd
>>126
タスクシステムだってなんでもかんでも関数乗せればいいってわけじゃないよ。
普通、そういう処理はタスクに乗せず、別の場所でやるもんだし、
システム自体、毎フレームごとに一定の処理を行うためのようなもんだから。

回転ずしで皿の上に鉋が乗ってたらおかしいでしょ?
関数ポインタ渡せば何でもかんでも処理を行ってくれるからと言って、
好きな関数を乗せていいわけでもない。

130 :名前は開発中のものです。:2009/08/24(月) 22:41:55 ID:wlQOC+Hi
>>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を
直接登録しとけばいいわけだし。

そんなわけで、古典的タスクシステムでも実現できる。

131 :名前は開発中のものです。:2009/08/25(火) 00:11:50 ID:Dhj5jDfF
>130
 【1タスク = 1ワーク】
とか固定観念が出来ちゃってると、>126程度までしか考えが及ばないんだろうね。



132 :名前は開発中のものです。:2009/08/25(火) 00:12:59 ID:Dhj5jDfF
>127
> 大洗海水浴場w

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

133 :名前は開発中のものです。:2009/08/25(火) 05:02:12 ID:B8qWF4q6
>タスクAの処理1と処理2がそれぞれ何なのかよくわからない。実際にゲームでそういうのが必要になる
>ケースが想定できないのだけど、どういったケース?

たとえば、updateと描画。体外の古典的タスクシステムは、updateとdrawを持ってる。
updateの中で描画するわけには行かないからな。

>>130 の言うところのタスクシステムは、その実、単なる関数ポインタのリストのようだけど、
だったら普通に書けと思うね。関数の中に関数の呼び出し並べれば、それは関数のリストなわけで、
わざわざタスクシステムとか作る必要あるか?参照>>107

>>131 >>2のような古典的タスクシステムではと前置きしているだろうに。

134 :名前は開発中のものです。:2009/08/25(火) 05:04:54 ID:B8qWF4q6
タスクシステムが制御の管理とオブジェクトの管理までするって言うんなら、
そんな制御構造とデータ構造ごっちゃにしたもの糞だし、
タスクシステムが制御の管理しかしないっていうんなら、
存在価値が無いし、
もう駄目だね。

135 :名前は開発中のものです。:2009/08/25(火) 06:12:20 ID:YcewJeTt
>>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のインスタンスがつねに存在するとは限らない。だから固定して並べることは出来ないし、
事前に記述することも出来ない。

136 :名前は開発中のものです。:2009/08/25(火) 06:21:38 ID:7Ki+VW24
>>135
俺も関数ポインタのリストにしかみえないけどな
やってることもそれ以上の効果ないだろ

137 :名前は開発中のものです。:2009/08/25(火) 06:25:24 ID:YcewJeTt
>>134
> タスクシステムが制御の管理とオブジェクトの管理までするって言うんなら、
> そんな制御構造とデータ構造ごっちゃにしたもの糞だし、

ITaskがタスク基底クラスだとして、タスクシステムが std::list< ITask* > を持っているなら、
タスクシステムはこのlistをtraverseしてupdateを呼び出すのだから、そのupdateのついでに
死亡フラグの立っているタスクを除去(delete)するのは普通の作りだと思うけどな。

タスクシステムがタスクの除去(delete)を管理する以上、タスクシステムが生成を管理していても
おかしくないので、factoryなりbuilderなりをタスクシステムに持たせるのも、よくある実装だと思うけど。

これをまあ、分離してもいいけど、普通分離する必要がないし、面倒だから分離しないと思うけどな。

これを分離しないことでどんなデメリットが生じる?

138 :名前は開発中のものです。:2009/08/25(火) 06:27:34 ID:YcewJeTt
>>136
> 俺も関数ポインタのリストにしかみえないけどな
> やってることもそれ以上の効果ないだろ

ITaskに仮想デストラクタのplace holderがあることを見てもわかるように、
タスクシステムが ITask派生クラスを安全にdeleteすることが出来る。

単なる関数ポインタとは雲泥の違い。

ひょっとして、ID:7Ki+VW24もID:B8qWF4q6もとんでもないC++初心者なのか?
だとしたらもう話している前提が違うとしか言いようがない。

139 :名前は開発中のものです。:2009/08/25(火) 06:28:45 ID:7Ki+VW24
>>138
安全かどうかしか違わないでしょ?

140 :名前は開発中のものです。:2009/08/25(火) 06:33:02 ID:YcewJeTt
>>139
意味がわからない。

ITask* なのだから、タスクシステムに、これらのオブジェクトを解体( delete )する権限と責任を持たせることが出来る。

これが単なる関数ポインタ(ex. boost::function )だったとしたら、別途、オブジェクトのstd::listのようなものを持たせない限り、
タスクシステムにオブジェクトの解体をさせることが出来ない。

まあ、オブジェクトの生成/解体を別のところで管理させてもいいけど、それは結局、std::listの無駄使いだと思う。

141 :名前は開発中のものです。:2009/08/25(火) 06:38:00 ID:Dhj5jDfF
>133
> >>131 >>2のような古典的タスクシステムではと前置きしているだろうに。

2つのタスクが1つのワークを指すようにポインタでつなぐとか考えないの?
何のために汎用ワーク持ってると思ってる?

142 :名前は開発中のものです。:2009/08/25(火) 06:40:18 ID:Dhj5jDfF
>134
> タスクシステムが制御の管理とオブジェクトの管理までするって言うんなら、
> そんな制御構造とデータ構造ごっちゃにしたもの糞だし、
> タスクシステムが制御の管理しかしないっていうんなら、
> 存在価値が無いし、
> もう駄目だね。

>133で
> >>131 >>2のような古典的タスクシステムではと前置きしているだろうに。
とワザワザ強調しているのに、>134では「タスクシステム」一般にまで話を拡張しちゃうのか。

アタマ湧いてる?

143 :名前は開発中のものです。:2009/08/25(火) 06:51:23 ID:YcewJeTt
>>141-142
なんか、私の直後に ID:Dhj5jDfF の書き込みがあって、なんか私がID変えて自演してるかのようで
少し悲しい気持ちになった。

いや、いいんだけどね・・・

144 :名前は開発中のものです。:2009/08/25(火) 07:10:23 ID:7Ki+VW24
>>140
だからぁ
この場の話には関係ないでしょ?それ

145 :名前は開発中のものです。:2009/08/25(火) 07:37:26 ID:YcewJeTt
>>140
何度でも言うが、あんたは何が言いたいのか意味がわからない。

>>136で、
> 俺も関数ポインタのリストにしかみえないけどな
> やってることもそれ以上の効果ないだろ

と言うから、

・タスクシステムがタスクを安全にdeleteできるという効果がある(>>140)
と私は言ってるだけなんだが。

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

これが、「この場の話には関係ない」と言うなら、どこがどう関係ないのかハッキリさせてくれないか。
少なくともタスクシステムの実装なのだから、「この場の話」と関係があると思うが。

146 :名前は開発中のものです。:2009/08/25(火) 08:01:01 ID:mayB8LIz
だから君の主張したいことってこの場の議論に全く関係無いじゃん
関数ポインタリストって言ってるのはただのアドレスジャンプ系処理って意味でしかこっちは使ってないよ
その実装方法が仮想関数でも関数ポインタでもとりあえずこの場の話では違いがないよね


147 :名前は開発中のものです。:2009/08/25(火) 08:14:41 ID:YcewJeTt
>>146
それなら最初からそう言えばいいのに。>>136の書き方ではとても読み取れない。
片言の日本語でレスするのは勘弁しとくれ。

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

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

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

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

148 :名前は開発中のものです。:2009/08/25(火) 08:37:05 ID:mayB8LIz
関数ポインタだともてないとでも?

149 :名前は開発中のものです。:2009/08/25(火) 08:40:29 ID:mhGkHmor
関数ポインタのリストだとそれも持てないし大体各オブジェクトの座標とかも持てないじゃん
まさかオブジェクトごとに別々の関数ポインタ持ってるわけじゃないでしょ

150 :名前は開発中のものです。:2009/08/25(火) 08:49:23 ID:YcewJeTt
>>148
> 関数ポインタだともてないとでも?

std::list<pair<boost::function>,int priority >> となっているなら話は別だけど、これは「単なる関数ポインタ列」ではないよね。

あと、こう実装してしまうと、priorityの制御が呼び出される関数側で出来なくなってしまう。
>>123より数段劣る実装だろう。


151 :名前は開発中のものです。:2009/08/25(火) 09:12:32 ID:bHGTB7wl
このスレのアンチタスク派って、なんだかゲーム作れるのか
どうかも怪しい人が多いよね。

言ってることのレベルが低すぎて話が噛み合ってない。

話していることの前提が違うと言えばそれまでだけど、
明らかに経験が不足している人とかいる。

アンチタスク派にも、もっと頑張ってほしい。

152 :名前は開発中のものです。:2009/08/25(火) 09:58:58 ID:5RdfU+QC
>>137
> タスクシステムがタスクの除去(delete)を管理する以上、タスクシステムが生成を管理していても
> おかしくないので、factoryなりbuilderなりをタスクシステムに持たせるのも、よくある実装だと思うけど。
...
> これを分離しないことでどんなデメリットが生じる?

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

そういう状況は回避するように策が打ってあるとしたら、それはそれで面倒な
ような気もするし。

っていうか、管理する理由が「管理していてもおかしくない」からっていう
いいかげんそうなやつなのに、それをやめるほうには「管理してなくても
おかしくないから」とかじゃなくて具体的なデメリットが要るの?おかしくない?

153 :名前は開発中のものです。:2009/08/25(火) 10:20:53 ID:YcewJeTt
>>152
> 「factoryなりbuilderなりをタスクシステムに持たせる」ってことは、生成される
> 具体的なクラスを全部システム側が知ってるとか、そういう状況にならない?

そりゃもちろん、その場合はタスクシステムに事前にfactoryを登録するんだよ。
だからタスクシステムは具体的なクラスは一切知らなくていい。

> 管理する理由が「管理していてもおかしくない」からっていう
> いいかげんそうなやつなのに、それをやめるほうには「管理してなくても
> おかしくないから」とかじゃなくて具体的なデメリットが要るの?おかしくない?

いい加減な理由じゃないよ。ITaskの派生クラスの生成と解体を管理するために
別途 std::list<ITask*> をタスクシステムとは別のところで用意するとしたら、
それは、二重に std::list<ITask*> を持っているという資源の効率的なデメリットが
あるから、それなら、flexibilityを多少犠牲にしてでもタスクシステムの std::list<ITask*>で
一本化するのは「おかしくない」と言ってるんだ。

メリットも動機もとても具体的だと思うんだが。

154 :名前は開発中のものです。:2009/08/25(火) 10:56:51 ID:YcewJeTt
>>152
> そういう状況は回避するように策が打ってあるとしたら、それはそれで面倒な
> ような気もするし。

std::map<type_info , boost::function(ITask* ()) > こんな感じになっていて、class IDに対応する
タスククラス(ITask派生クラス) を new して返すような factory methodを持っていればいいだけだ。

生成したいときは、タスクシステムに対して
 taskSystem -> AddTask( typeof (HogeTask ) );
にようにするだけだ。 あるいは、AddTaskをtemplate methodにしていれば、単に
 taskSystem -> AddTask( HogeTask );
と書くだけだ。

これの何がどう面倒なんだ?

155 :名前は開発中のものです。:2009/08/25(火) 11:02:39 ID:YcewJeTt
>>152
ついでに言えば、>>154は、次のようなマクロを使ってさらに簡略化されていると
使い勝手はいいかも知れない。(このソースを読む第三者的には嫌かも知れないが)

#define newTask(CLASS) taskSystem->AddTask(CLASS);

また、実際は、各タスクが、taskSystemへアクセスするには、mediator的なものがどこかに必要になる。
具体的には、ITask::updateの引数として受け渡すだとか、ITask自体にTaskSystem*を持たせるだとか。

156 :名前は開発中のものです。:2009/08/25(火) 11:26:05 ID:5RdfU+QC
>>153
すばやいレスありがとう。

うまく伝わらなかったようで、ごめん。

std::list<ITask*> をどこにどう持つかは関係なくて、問題だと思ってるのは
「生成を管理」することね。

生成を管理しない状態として想定してるのは、 System.Add(new MyTask(...)) と
要素を追加できる状態。

それに比べたら生成を管理するためにファクトリを登録するだとか >153-154 とか
の方法は、全部なにかしら(比較すれば)面倒になってるよね?

で、その面倒な状態にする理由が今のところ「おかしくないから」しか挙がって
ない。それじゃ利用者が不便になってるだけじゃない?

157 :名前は開発中のものです。:2009/08/25(火) 11:36:54 ID:UHLMYu4b
>>151
それ言ったらここに書いてる人全員ゲーム作れるのか怪しい。
動くサンプルを出す人はいないし。
お前ら本当にそんな実装してんの?いつもの釣りじゃねえの?

158 :名前は開発中のものです。:2009/08/25(火) 11:59:09 ID:YcewJeTt
>>156
> それに比べたら生成を管理するためにファクトリを登録するだとか >153-154 とか
> の方法は、全部なにかしら(比較すれば)面倒になってるよね?

いや、ユーザーは(タスクシステムの外に)deleteは、
一切書かなくて済むようになるからソースコードは大幅に簡略化されると思うのだけど。

factoryの登録は各タスクに対して1回で済むけど、普通のゲームでは、オブジェクトをdeleteするコードは
いたるところに散乱するのが普通だし、ひとつのクラスに対して記述するdeleteの回数は半端じゃないのが普通だろうから、
それからすれば、1回のfactory登録だけであとはdeleteから逃れられるのは大きなメリットだと思うけどな。

結局、タスクというかオブジェクトの生成〜解体まで誰が面倒を見るのかということだと思うよ。
それはタスクシステムを使おうが使うまいが関係なく、C++ではこの問題がずっとつきまとう。

タスクシステムを採用するっていうなら、タスクというオブジェクトの生成/解体責任まですべてこの
タスクシステムが担ってくれれば、タスクシステムのユーザーは、タスクの生成/解体責任から逃れられる。

タスクシステムを使わなくても書けるだろうし、ゲームの種類によっては、タスクシステムが邪魔になることはあるだろうけど
少なくともタスクシステムが生成と解体の面倒を見てくれる限りは、deleteの呼び忘れみたいな問題はほとんど起きない。

159 :名前は開発中のものです。:2009/08/25(火) 13:06:12 ID:YcewJeTt
>>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 :名前は開発中のものです。:2009/08/25(火) 13:15:32 ID:mhGkHmor
C++を熟知してないと実装が面倒だ

161 :名前は開発中のものです。:2009/08/25(火) 13:44:28 ID:YcewJeTt
>>160
C++を熟知している必要は全くないと思うが、最低限、templateの基本的な使い方とRTTI、dynamic_castぐらいは
C++の入門書にでも載っているのだから知っておいてもらいたい。

あと、現場では、タスクシステムのようなライブラリっぽい部分は熟練プログラマが作って、
それを使う部分は、下っ端のプログラマが作ることが多いので、タスクシステムの実装は別に
複雑であろうが、実装が難しかろうが、templateを駆使してあろうが、全く問題ないと思うけどな。
(あくまで実際の現場では、だが)

162 :new tasksystem ◆9ycqcAuWxdGZ :2009/08/25(火) 13:47:49 ID:YcewJeTt
せっかくだからトリップつけた。

163 :名前は開発中のものです。:2009/08/25(火) 15:47:13 ID:11vzXU6M
本職の人?

164 :名前は開発中のものです。:2009/08/25(火) 16:37:57 ID:5qW0dNQT
>>159
そのdynamic_castってコンパイルはエラーを素通りさせて
実行時にassertで捕まえるためのもの?
いまいち理解できない orz

165 :new tasksystem ◆9ycqcAuWxdGZ :2009/08/25(火) 17:12:30 ID:YcewJeTt
>>164
> そのdynamic_castってコンパイルはエラーを素通りさせて

「エラー」という場合、コンパイル時のエラーと実行時のエラーとがあると思うのだが、
おっしゃる通り、コンパイルエラーにはならず、assertがあるのでタスク(ITask派生クラス)以外を
生成しようとすると、実行時エラーになる。

これを静的に(コンパイル段階で)検出しようと思えば、
templateに対して、T が ITask派生クラスであるという制約を書く必要がある。

C#ならwhereで簡単に書けるが、C++でこれを書くのは少し難しい。
C++なら、boost::enable_if とか C++ conceptならrequiresを使って書く…んだろうなぁ。

まあ、なにせそんな事情でややこしいことに触れたくなかったので、実行時エラーでお茶を濁したわけだ。

166 :名前は開発中のものです。:2009/08/25(火) 17:17:24 ID:5qW0dNQT
キャスト使わなければ自動的にコンパイルエラーになると思うんだけど

167 :new tasksystem ◆9ycqcAuWxdGZ :2009/08/25(火) 17:23:24 ID:YcewJeTt
>>166
ああ、まあ、それはそうなのだけど、うーん。私の書き方が悪かったな、これは。

つまり、私は代入するところでコンパイルエラーになるのではなく、
newTaskの呼び出し側でコンパイルエラーの表示がされて欲しいんだよね。

そのためには呼び出し側に、このtemplate methodは、ITask派生クラス以外は引数に
とれませんよと明示してやる必要があるのだけど、それを表明する手段がC++だと
とても難しいと言いたかったんだ。

168 :名前は開発中のものです。:2009/08/25(火) 17:37:09 ID:5qW0dNQT
エラーの表示位置が気に入らないからコンパイルエラーを素通りさせるってこと?
やっぱり理解できないなぁ

169 :new tasksystem ◆9ycqcAuWxdGZ :2009/08/25(火) 17:46:13 ID:YcewJeTt
>>168
実行時エラーなら、スタックフレームから、どこで呼び出しているかが簡単にわかるから。

まあ、そのへんは単なるデバッグの方法論というか個人的な趣味なのであまり気にしないでちょうだい。
(JavaScriptのような言語をずっと触っていると実行時エラーのほうが自然に思えてくるというのはある。)

170 :名前は開発中のものです。:2009/08/25(火) 18:06:01 ID:5qW0dNQT
なるほど JavaScriptか
ずっとC++でやってると、コンパイルエラーを抑止するなんて
バグをわざわざ埋め込んでるようにしか見えなかったよ
少しだけ理解した

171 :名前は開発中のものです。:2009/08/25(火) 18:30:48 ID:i74J/de4
テンプレートパラメタの型が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))’

172 :new tasksystem ◆9ycqcAuWxdGZ :2009/08/25(火) 18:38:39 ID:YcewJeTt
>>171
ああ、いいね。すごくいい。

173 :名前は開発中のものです。:2009/08/25(火) 20:05:50 ID:RxRglwpV
タスクシステムを使っても使わなくても
実装できるわけで
観光地に行くのに飛行機で行こう、車で行こうって意見がわかれてるだけで
なんの進歩もない

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

174 :名前は開発中のものです。:2009/08/25(火) 20:09:21 ID:RxRglwpV
あの・・・
>>2 ではboost使ってないんですが・・・
キ・・・

175 :名前は開発中のものです。:2009/08/25(火) 20:18:33 ID:7Ki+VW24
仮に自機のクラスから敵、敵のクラスから自機の情報が必要になったらどこに記述すればいいの?

176 :名前は開発中のものです。:2009/08/25(火) 20:26:52 ID:RxRglwpV
よう boost使い
お前 small talk 知らないだろ?
車輪の再開発だよ
熟知はしてるようだが
バ○にしか見えない

177 :名前は開発中のものです。:2009/08/25(火) 20:32:08 ID:i74J/de4
さらに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>();
}


178 :名前は開発中のものです。:2009/08/25(火) 20:33:58 ID:RxRglwpV
>>175 に答えろよ

179 :名前は開発中のものです。:2009/08/25(火) 20:40:23 ID:i74J/de4
>>175
情報はデータベースで一括で管理して
タスクの中からそれらの情報に問い合わせるようにすればいいんじゃない?
問合せ元のタスクによってアクセス制御を静的にかけることも一応は可能だし
不要な情報を書き換えるバグを防ぐような対策もできるし
デバッグ実行時にログを取る際にも柔軟にできると思う

180 :名前は開発中のものです。:2009/08/25(火) 20:47:23 ID:PL5QMpbV
>>178
因縁つけすぎwwww

181 :名前は開発中のものです。:2009/08/25(火) 21:15:43 ID:RxRglwpV
>>179
それはソースでかけないんだ

182 :名前は開発中のものです。:2009/08/25(火) 21:17:04 ID:RxRglwpV
>どこに記述すればいいの?

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

答えてない

183 :名前は開発中のものです。:2009/08/25(火) 21:19:22 ID:RxRglwpV
英語にすると
where? と聞いてるのに how to で答えてる
読解力に欠け、異常な頭脳を持つとしかいいきれん

184 :名前は開発中のものです。:2009/08/25(火) 21:26:26 ID:PL5QMpbV
>>182


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

185 :名前は開発中のものです。:2009/08/25(火) 22:01:11 ID:RxRglwpV
俺も同意見で どこに記述すればいいのか不思議でね

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

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

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

186 :名前は開発中のものです。:2009/08/25(火) 22:22:35 ID:5RdfU+QC
>>158
またもすばやいレス、ありがとう。おそくなってごめんなさい。

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

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

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

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

187 :名前は開発中のものです。:2009/08/25(火) 23:03:19 ID:PL5QMpbV
>>185
そもそもどこに記述したいのかわからない。
クライアント側の利用の仕方を教えて欲しいのか、開発側の作り方を教えて欲しいのか。

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

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

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

188 :名前は開発中のものです。:2009/08/25(火) 23:12:12 ID:Dhj5jDfF
>152
> 「factoryなりbuilderなりをタスクシステムに持たせる」ってことは、生成される
> 具体的なクラスを全部システム側が知ってるとか、そういう状況にならない?
> そうなるとあからさまに面倒だと思うんだけど。

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


189 :名前は開発中のものです。:2009/08/26(水) 00:31:01 ID:Jc1aOsD2
それはどんなプログラムだろうと関係あることじゃん。

190 :名前は開発中のものです。:2009/08/26(水) 00:34:31 ID:v5rbTd5J
>>179
したら自機クラスに敵クラスの処理があるの?
敵クラスに自機クラスの処理があるの?
どっちか片方しかいらん場合どっちに記述するの?

191 :new tasksystem ◆9ycqcAuWxdGZ :2009/08/26(水) 00:57:24 ID:7Qo8yLie
>>173
> あえて言うなれば、「僕、僕、こんなすごいオナヌー知ってるんだあぁぁぁぁぁ」って感じ

C++の教科書に書いてある程度のことを超絶テクニックかのように言われても困るんだけどな。

アンチタスカーはC++の基本すら知らないのか。そりゃ話にならんはずだわ。

192 :new tasksystem ◆9ycqcAuWxdGZ :2009/08/26(水) 00:59:06 ID:7Qo8yLie
>>174
> >>2 ではboost使ってないんですが・・・

使いたければ使えばいいし使いたくなければ使わなければいい。

例えば、boost::functionなんかは、C++0xでC++標準になるぐらいC++使いにとってはスタンダードなものであって、
これを何か特別なものかのように言われてもなぁ・・。

193 :new tasksystem ◆9ycqcAuWxdGZ :2009/08/26(水) 01:05:11 ID:7Qo8yLie
>>175
> 仮に自機のクラスから敵、敵のクラスから自機の情報が必要になったらどこに記述すればいいの?

接触判定のように自機と敵クラスの集合との相互干渉による振る舞い(behavior)を書きたいのか、
それとも、単に、敵が自機をめがけてホーミングのような行動をするから自機の座標が取りたいだけなのかどちらだ?

前者と後者とでは全然意味が違うんだけど。

194 :new tasksystem ◆9ycqcAuWxdGZ :2009/08/26(水) 01:10:59 ID:7Qo8yLie
>>176
> よう boost使い
> お前 small talk 知らないだろ?
> 車輪の再開発だよ
> 熟知はしてるようだが
> バ○にしか見えない

boost使いというのは、ID:i74J/de4のことだと思うが、
なんかあんたの煽りのレベルは低いぞ。

そんなレベルの煽りがしたいなら、私も次のように煽り返しておこう。

small talkなんて言語はねーよ。Smalltalkだろ?
言語名も正しく知らない奴が知ったかすんなよwww ばーか

195 :new tasksystem ◆9ycqcAuWxdGZ :2009/08/26(水) 01:17:09 ID:7Qo8yLie
>>177
> >>154で言われる「生成を管理しない状態」はほぼ達成できそうだ

154を書いたのは私だが、すまないが、>>177では何をしたいのかいまひとつわからない。
もちろん、>>177のソースの振る舞い自体は私は理解できる。

「生成を管理しない状態」というのが私と認識が違うのかも知れない。
「生成を管理しない状態」について、あなたの認識を聞かせて欲しい。

> これぐらいならC++2003のとboostでエミュレートできる範囲でも頑張れば実装できる

C++2003というのは、Visual C++ 2003? なぜに2007ではないの?
2003って結構templateが、C++標準に準拠してなくて嫌なのだけど。

196 :new tasksystem ◆9ycqcAuWxdGZ :2009/08/26(水) 01:24:06 ID:7Qo8yLie
>>178
>>193


197 :new tasksystem ◆9ycqcAuWxdGZ :2009/08/26(水) 01:25:12 ID:7Qo8yLie
>>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;
}


198 :名前は開発中のものです。:2009/08/26(水) 01:26:36 ID:Jc1aOsD2
>>195
キャラ変わったな。おもしろい。

199 :new tasksystem ◆9ycqcAuWxdGZ :2009/08/26(水) 01:26:48 ID:7Qo8yLie
>>181-183
>>179を読んで >>197 ぐらいのソースがすぐに頭に浮かばないとは、あんた、C++ド素人だな。

200 :名前は開発中のものです。:2009/08/26(水) 01:31:18 ID:v5rbTd5J
>>193
どっちでも同じじゃない?
関連するもの全部言ってよ

自機と敵の接触とホーミングみたいなもん両方どうやって表現してんの?

仮に自機タスクに敵、敵タスクに自機の処理が必要になっちゃうと
切り離したいときに自機クラス移動したら敵クラスも必要になっちゃうし
敵クラスだけ動かそうとしたら自機クラスまで必要になったりとカプセル化ぶっ壊れてると思う

201 :new tasksystem ◆9ycqcAuWxdGZ :2009/08/26(水) 01:33:44 ID:7Qo8yLie
>>185
> 情報はデータベースで一括管理というが、
> このデータベースもタスクシステムで作られているのか
> そこもまた不思議でね

タスクシステム内に作ってもいいと思うけどね。
タスクシステム外に作ってもいいだろうし。

タスクシステム内に作る動機としては、タスクシステム自体が std::list<ITask*> を持っているということに尽きる。
これと同じ構造のものしかいらないのなら、二重に持つのは資源の無駄だから、タスクシステム内にあるのが自然だ。

std::list<ITask*> より、もっとqueryに迅速に応答できるような構造を用意したいなら、タスクシステムのなかに
ある必然性はあまりない。

タスクの生成自体をタスクシステムで一元管理しているなら、生成のついでにそのタスクをデータベースに登録できるので、
タスクシステム内にあったほうがソースはシンプルになるというのはあるだろうけど。

202 :名前は開発中のものです。:2009/08/26(水) 01:42:17 ID:2pk32YIl
何が良い実装方法か、なんてゲームの仕様や実行環境によって全然違うものになるだろうに…
目的もないのに正しい方法なんて議論しても時間の無駄。永遠に結論なんて出んよ。


203 :new tasksystem ◆9ycqcAuWxdGZ :2009/08/26(水) 01:42:52 ID:7Qo8yLie
>>200
> どっちでも同じじゃない?

全然同じじゃない。次の3パターンがある。

■ オブジェクトの寿命が事前に確定している場合

例えば、自機はホーミングクラスより必ず寿命が長いことがわかっているなら、
ホーミングクラスは単に自機クラスのオブジェクトへのポインタをメンバとして持てばいい。

自機クラスのオブジェクトをどこからもらうかと言えば、>>197のようなデータベースかタスクシステムからもらえばいい。

■ 特定のインスタンスを参照したいだけの場合 で かつ、オブジェクトの寿命が事前に確定していない場合

この場合は、参照先のオブジェクトが先にお亡くなりになると不正なポインタになってしまうことがあるので、
boost::shared_ptr のようなもので持っておき、お亡くなりを検知するか、あるいは、Handle化する。
(Windows APIでよく使う、あのhandleだ)

Handle化は、タスクシステムとは無縁のテクニックだから、このスレとはあまり関係ない気もするが、
一応解説する。

typedef TaskHandle ulong;
std::map < TaskHandle , ITask* > handleToTask;

こうね。こうしておいて、敵のTaskHandleを自機クラスがメンバとして持っていればいい。
TaskHandleは、newTaskのときに割り当てるといいと思う。

■ あるクラスのインスタンス集合を参照したい場合で、かつ、オブジェクトの寿命が事前に確定していない場合

アクセスしたくなるごとに、毎回、>>197のようなデータベースかタスクシステムからもらえば、
その描画フレーム内は、相手タスクがお亡くなりになることはないだろうから、参照の安全性が保証される。

204 :new tasksystem ◆9ycqcAuWxdGZ :2009/08/26(水) 01:46:25 ID:7Qo8yLie
>>202
> 目的もないのに正しい方法なんて議論しても時間の無駄

アンチタスカーの主張は、タスクシステム自体が無駄で意味のないものだと言うから、
ある特定の状況ではタスクシステムが有効に働くことを私は一連の書き込みで示しているつもりなのだけど。

205 :new tasksystem ◆9ycqcAuWxdGZ :2009/08/26(水) 01:52:55 ID:7Qo8yLie
>>188
> 何をいつ作って何をいつ破棄したか、何がどれだけの時間残ってるのか、きちんと管理
> してないと、バグチェックが辛いぞwww

生成のタイミングは確かに重要なのだけど、破棄されるタイミングというのは、あまり重要じゃないんだよね。

例えば、JavaやC#のようにGarbage Collection(以下、GC)のある言語だと、破棄タイミングはユーザーが規定できない。

「どこからも参照されなくなれば、そのうち破棄されるよ」というだけ。

タスクシステムを使った場合も、死亡フラグが立って明示的に削除される場合は別として、
あと、root object(これらは外部から参照されていなくとも削除されない)も除外するとして、
参照が解除されるかしたときに、自動的に解体するような仕組みが組み込まれていてもいいと思うんだけどね。

まあ…シューティングゲームなんかだと、画面上のほとんどの描画物のタスクがどこにも依存していないので
root objectということになるんだろうから、こういう設計はゲームによって向き/不向きがあるだろうけども。

206 :名前は開発中のものです。:2009/08/26(水) 02:01:52 ID:2pk32YIl
>>204
まともな頭を持ったプログラマならアンチタスクなんかにならんよ。勝ち目がないから。

タスクに有用性があるということを示したければ有用な条件で動く例を一つ出せば証明できる。
反対にタスクに有用性がない、ということを証明するためには、存在する全てのケースで
有用ではないことを示さなければならない。これは悪魔の証明でアンチに勝ち目は無い。

なのでアンチってのは、示されたタスクの有用性を全て「はぁ?僕ちゃん理解できませんww」と
相手が根負けするまで白痴のふりをしてとぼけ続けるか、関係ない揚げ足を取って話をはぐらかす
ぐらいしかできない、勝てない戦いを続けるお馬鹿さん。

207 :new tasksystem ◆9ycqcAuWxdGZ :2009/08/26(水) 02:02:39 ID:7Qo8yLie
>>186
> で、その後の流れを読んでもやっぱり生成を管理することにした理由が
> 「してもおかしくない」しか見当たらなくておかしいように思う。他に何か
> 理由があったんじゃないの?

生成をタスクシステム側で一元管理しようという話になった。(>>154)

ようするにたった一つのmethodを生成の入り口として、この入り口を通過しないとタスク(ITask派生クラス)は
生成できないということにした。

こうしておくメリットは、すべてのタスクの生成の首根っこを押さえてあるということ。

例えば、データベース(>>179 , >>197 )を作って、そのデータベースから
ある条件に合致するタスク集合(ITask* の std::vector )をもらおうとしたとき、
そのデータベースは現在生成されているタスクを知っていることが大前提となるけど、
タスク生成にはひとつの入り口しかないので、ここでデータベースへタスクを
登録する作業をしておけば、生存しているタスクの列挙漏れは起こらないことが保証される。

このように、何らかのqueryでタスクを列挙することを考えると生成が
一元管理されていることは必須条件であって、生成の窓口の一本化は、これを見越してのこと。

208 :new tasksystem ◆9ycqcAuWxdGZ :2009/08/26(水) 02:06:20 ID:7Qo8yLie
>>206
> タスクに有用性があるということを示したければ有用な条件で動く例を一つ出せば証明できる。

まあ、そうやってタスクシステムを使って書かれたプログラムと、
タスクシステムを使って書かれていない等価な処理を行なうプログラムとで
どらちが良いかというのを比較しようと思うと、それなりの規模のシステムじゃないと
適切に評価できないというのはあるような。

例えば、>>2 のCodeZineのタスクシステムでは、私にすら全然メリットが伝わってこないというか、
「こんなタスクシステムならいらないよね」というのは、案外、まともな感性のような気はしますけどね。

209 :new tasksystem ◆9ycqcAuWxdGZ :2009/08/26(水) 02:15:59 ID:7Qo8yLie
>>200
> 自機と敵の接触とホーミングみたいなもん両方どうやって表現してんの?
> 仮に自機タスクに敵、敵タスクに自機の処理が必要になっちゃうと
> 切り離したいときに自機クラス移動したら敵クラスも必要になっちゃうし
> 敵クラスだけ動かそうとしたら自機クラスまで必要になったりとカプセル化ぶっ壊れてると思う

私には、「自機クラス移動したら敵クラスも必要になっちゃうし」の意味がわからないんだよね。
「移動」っていうのは画面上の「座標移動」のことなのか、オブジェクトとしてアドレスが
移動(例えば、いったん消滅して、再度別のオブジェクトとして生成されるような場合)なのか
どちらの話?どうも前者っぽい気はするのだけど。

・自機と敵との接触は、常識的には自機が1つで敵が複数いるわけだから、
(常識的には)自機クラスに自機が敵との接触判定を行なうコードを記述する。

・ホーミングはホーミングというタスクがあるわけで、
ホーミングのタスクが自機クラスを取得して、そこからgetterで座標を取得する。

「敵クラスだけ動かそうとしたら自機クラスまで必要になったり」の意味がわからない。

ホーミングは自機を狙うわけだから、ホーミングを動かすのに自機の現在の座標が必要なのは
当然であって、自機の座標を何らかの形で取得できるようになっていないとホーミングは
自機を狙うことすら出来ないと思うのだけど。

だから、自機クラスはgetterで自分の座標を提供する必要がある。
これのどこがカプセル化が壊れているのか私にはさっぱりわからない。


210 :名前は開発中のものです。:2009/08/26(水) 02:18:42 ID:covJ0F+/
>>207
> タスク生成にはひとつの入り口しかないので、ここでデータベースへタスクを
> 登録する作業をしておけば、生存しているタスクの列挙漏れは起こらないことが保証される。

その「登録する作業」は >>156 の System.Add(new MyTask(...)) の中でも
できると思うんだけど、違うの?

211 :名前は開発中のものです。:2009/08/26(水) 02:24:13 ID:K1/j/qf8
>175 の質問はどこに書くか問うているが何を書くのか定めてないな。
何を書くのかわからないのにどこに書くか決められないから
答えの無い質問を投げる釣りだな。>183 がネタばらしか。

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

212 :名前は開発中のものです。:2009/08/26(水) 02:28:37 ID:PkVOSvoy
自機のタスクが敵のタスクリストの場所の情報を保持すればいいんじゃないのか
あるいは敵のタスクが自機のタスクの場所とか

213 :名前は開発中のものです。:2009/08/26(水) 02:36:11 ID:PU+y3J/F
この勢いでタスクサンプルをうpする作業に入るんだ
お、俺のSTGに組み組んであげてもいいんだからねっ////

214 :名前は開発中のものです。:2009/08/26(水) 02:36:50 ID:Jc1aOsD2
>>212
そんなことしたら制御とクライアントで分ける意味がないじゃん。
そういうのはenumで自機とか敵機の識別子を作っておくんだよ。
場合によってはあるシステムを基にあるシステムに対して振る舞うなんて荒技もある。

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

215 :new tasksystem ◆9ycqcAuWxdGZ :2009/08/26(水) 02:44:24 ID:7Qo8yLie
>>210
> その「登録する作業」は >>156 の System.Add(new MyTask(...)) の中でも
> できると思うんだけど、違うの?

呼び出し側でnewしてしまうと何にもならない。デメリットは2つ。

まず、タスクにはそれなりのbuilderが必要だと思うんだ。
タスクごとに初期化や設定のためにいろいろ外部から渡してやる必要があるだろうから。

それはサウンド再生クラスであったり、グローバルタイマーであったり、
まあ、いろいろだけど、何せそういったものを渡してやる必要がある。

呼び出し側でnewすると、builderも呼び出し側に用意する必要がある。
これは凄く嫌。生成と同時にbuilderを呼び出すことを呼び出し側が保証しなくてはならなくなる。

呼び出し側は、もっとお気軽に、特定のタスクの生成を指示したいんだ。
そのタスクに付随するbuilderの呼び出しまで責任を負いたくない。

2つ目のデメリットは、newというキーワードが散乱すること。

タスクをnewしている箇所をもっと限定したいんだ。
メモリリークしていないことの保証がしにくくなるからね。

タスクシステムとタスクのfactoryでしかnewしていないことが保証できると嬉しい。

すなわち、ユーザーコード(ここで言うユーザーとはタスクシステムのユーザー。
タスクシステムとは別の人が書いていると想定)内にnewが一切出てこないで済む。
ユーザーコードをgrepで"new "を探して、見つかったら、そのコードを
書いた奴の頭を張り倒していい。


216 :new tasksystem ◆9ycqcAuWxdGZ :2009/08/26(水) 02:48:02 ID:7Qo8yLie
>>212
> 自機のタスクが敵のタスクリストの場所の情報を保持すればいいんじゃないのか

保持するというのはメンバとしてstd::list<ITask*>のようなものを持つことを
言ってるんだろうけど、敵は動的に解体されるので、参照が無効になりかねない。

私は>>203のようにするべきだと思う。


217 :new tasksystem ◆9ycqcAuWxdGZ :2009/08/26(水) 02:49:17 ID:7Qo8yLie
>>213
> この勢いでタスクサンプルをうpする作業に入るんだ
> お、俺のSTGに組み組んであげてもいいんだからねっ////

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

218 :名前は開発中のものです。:2009/08/26(水) 02:50:56 ID:Jc1aOsD2
>>214
挙げといて難だが、重大なバグを発見したwww
探してみると笑えるかもしれないwww

まあこの流れだと無視されるだろうがな。
ふぅ……

219 :new tasksystem ◆9ycqcAuWxdGZ :2009/08/26(水) 02:53:56 ID:7Qo8yLie
>>214
> そういうのはenumで自機とか敵機の識別子を作っておくんだよ。

そんな実装は嫌だなぁ。

それだと、すべてのタスクの識別子が必要になってくる。
タスクを追加するごとにそのenumを修正する必要が出てきそう。

ITaskはvirtual methodを持つのだから、ITask派生クラスは
RTTIで型情報がとれることは保証されているので、typeid
(いま気づいたが >>154はtypeofと書いているのは書き間違いでtypeidが正しい)
でtype_infoを取得して、そいつで識別したほうがいいような気がするのだが。

220 :名前は開発中のものです。:2009/08/26(水) 03:01:18 ID:Jc1aOsD2
>>219
タスク自体に持たせるんじゃなくて、自機とか敵機に持たせればいいじゃん。
必要になればシステム自体が識別子を取得するようにすれば面倒なことにはならない。

221 :new tasksystem ◆9ycqcAuWxdGZ :2009/08/26(水) 03:02:03 ID:7Qo8yLie
>>218
> 挙げといて難だが、重大なバグを発見したwww

ざっとしかコードを見ていないが、ひとことで言うと何がしたいのかさっぱりわからない。

メモリのpoolerのようだけど、開放の処理がおかしいし、
こんな設計では開放処理できないだろう。

単に vector<T>とかで型ごとにpoolしたほうがいいんじゃないの?
そのほうが開放〜再確保のときに無駄が出ないよ。

222 :new tasksystem ◆9ycqcAuWxdGZ :2009/08/26(水) 03:05:29 ID:7Qo8yLie
>>220
> タスク自体に持たせるんじゃなくて、自機とか敵機に持たせればいいじゃん。
> 必要になればシステム自体が識別子を取得するようにすれば面倒なことにはならない。

何を言いたいのかわからない。私なりに日本語を修正すると以下のようになるが
以下の意味であってるのか?

タスクシステム自体に「自機とか敵機の識別子」を書いたenum持たせるんじゃなくて、
自機クラスとか敵機クラスに、そういうenumを持たせればいいじゃん。


あと「必要になればシステム自体が識別子を取得するようにすれば面倒なことにはならない。」
については全く意味不明。「システム」ってなんだ?ここで言う「取得」とは何だ?
何がどう面倒なことにならないんだ? 具体的なコードで示してくれ。


223 :new tasksystem ◆9ycqcAuWxdGZ :2009/08/26(水) 03:07:36 ID:7Qo8yLie
どうせ質問が来るだろうから事前に書いておく。

■ タスクシステムで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はタスクシステムを使う場合、どこに書くべきなのか。

言うまでもなく、惑星クラスのなかに書くべきではない。

224 :名前は開発中のものです。:2009/08/26(水) 03:14:23 ID:covJ0F+/
>>215
やっぱりまだおかしいような気がするよ。

> 呼び出し側でnewしてしまうと何にもならない。デメリットは2つ。
>
> まず、タスクにはそれなりのbuilderが必要だと思うんだ。
> タスクごとに初期化や設定のためにいろいろ外部から渡してやる必要があるだろうから。

初期化時に外部からいろいろ渡したいなら、普通に考えてコンストラクタの
引数で渡すのが自然だと思うんだけど、何のために「それなりのbuilder」が
必要だと思うの?(「それなりのbuilder」が無いとどんな問題があるの?)

225 :名前は開発中のものです。:2009/08/26(水) 03:15:06 ID:covJ0F+/
>>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 でおおかた
済むでしょ。

226 :new tasksystem ◆9ycqcAuWxdGZ :2009/08/26(水) 03:15:42 ID:7Qo8yLie
>>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未満になれば、そのインスタンスは自動的に解体される。

まあ、こういうことだな。

227 :new tasksystem ◆9ycqcAuWxdGZ :2009/08/26(水) 03:21:51 ID:7Qo8yLie
>>224
> 初期化時に外部からいろいろ渡したいなら、普通に考えてコンストラクタの
> 引数で渡すのが自然だと思うんだけど、

全然自然じゃない。

いま、あるタスクにサウンドクラスが必要だとする。
そのタスクのbuilderはサウンドクラスを設定してやることが出来る。

ところがあなたの設計だと、コンストラクタでサウンドクラスを渡してやる必要がある。
すなわち、newした側がサウンドクラスにアクセスできる必要がある。

そのタスクを生成したいだけなのに、そのコンテキスト(タスクを生成するコードが
ある場所)においてサウンドクラスへのアクセス権を持っていなければならないことになる。

こんな設計はおかしいと言っているんだ。


228 :new tasksystem ◆9ycqcAuWxdGZ :2009/08/26(水) 03:33:04 ID:7Qo8yLie
>>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を禁止にすればほとんどは防げるのだし。

229 :名前は開発中のものです。:2009/08/26(水) 03:41:28 ID:covJ0F+/
>>227
>> 初期化時に外部からいろいろ渡したいなら、普通に考えてコンストラクタの
>> 引数で渡すのが自然だと思うんだけど、
...
> そのタスクを生成したいだけなのに、そのコンテキスト(タスクを生成するコードが
> ある場所)においてサウンドクラスへのアクセス権を持っていなければならないことになる。
>
> こんな設計はおかしいと言っているんだ。

別におかしくないと思うんだけど、まぁそこは主観が入るからやめとこう。

具体的に、生成処理から(例として)サウンドクラスへのアクセスを禁止できた
として、何が得られるの?

builder を使った場合でも、生成するタスクに生成処理の一部として渡すん
だったらタスク内では(ファクトリ関数内も?)当然アクセスできちゃう
わけで、どっちにしてもタスク実装者に対して隠蔽できていないという意味で
同じことだと思うんだけど。

230 :new tasksystem ◆9ycqcAuWxdGZ :2009/08/26(水) 03:41:29 ID:7Qo8yLie
>>210
いま思い出したのだが、タスクを呼び出し側でnewしてタスクシステムに渡す構造になっていると

taskSystem -> AddTask( ptr ); // new していないポインタ

とかする奴やら、

IEnemy* enemy = new EnemyBoss123();
taskSystem -> AddTask ( enemy ); // 勝手にupcastしたポインタ

とかする奴やら、いろんな奴が出てくる。(上のコードは簡略化した例だが、実際の現場で遭遇したコードだ)

タスクシステムとタスク側とを書いている人間は別の人間だ。
タスク側を書いている人間がタスクシステムのことを正しく理解しているとは限らない。

タスクシステムはどちらかと言えばライブラリに属するので、
タスク側のコードを書く人間がポカをやったときにそれを検知するための仕組みか、あるいは、
ポカをそもそも出来ないように設計されているべきだ。

一人でゲームを作っているなら、全く関係ない話かも知れないが、であれば、
現場のゲームライブラリ実装者はこう考えている人もいるという風に受け取って欲しい。

231 :new tasksystem ◆9ycqcAuWxdGZ :2009/08/26(水) 03:49:29 ID:7Qo8yLie
>>229
> 具体的に、生成処理から(例として)サウンドクラスへのアクセスを禁止できた
> として、何が得られるの?

いま、static変数は極力廃止してあるという前提で話を進める。(この前提については認めてもらえる?)

タスクを生成するのは、(タスクシステムにおいては)タスクに他ならない。
すなわち、なにかしらのタスクなんだ。

そのタスクは、サウンドクラスにアクセスできるということは、そのタスクは生成時かbuilderでサウンドクラスを
コンストラクタで受け取っているということになる。あなたの話だとbuilderは使わないのだから、コンストラクタで
受け取っていることになる。

いま、タスクAにはサウンドクラスが必要で、タスクBにはサウンドクラスが不要だとしよう。
タスクBがタスクAを生成したくなったら、(あなたの設計では)タスクBのコンストラクタのシグネチャを変更して
サウンドクラスを受け取るようにしなくてはならない。その変更に付随して、タスクBを生成している部分のコードを
書き直さなくてはならない。そして、タスクBを生成しているタスクC,D,E,…に関しても、それらがサウンドクラスを
コンストラクタで受け取っていないなら、それを受け取るようにコード修正をしなくてはならない。

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


232 :えいいち ◆GRGSIBERIA :2009/08/26(水) 03:49:34 ID:Jc1aOsD2
まあ、せっかくだし名乗るか。

>>221
一応、速度重視の汎用アロケータ。

vectorだと遅いし、poolも余計に増える。
テンプレートクラスにして型ごとに取ってくるのも最初は考えたけどメモリ効率が余計悪くなるからやめた。

解放処理はMemoryPoolの寿命と一緒に行うことになってる。
無理に解放しようとするとCPUが100%になったまま固まることがあるのでお勧めしない。
メモリ効率は非常に悪いけどBoost::object_poolより速かったから問題ない。

>>222
一応、おk。

>面倒なこと
typeidで型名取得したときにどうやってタスク内で処理するか、とか。
クラスが増えすぎた場合、どうやって対処するか、とか。
enumなら敵です味方ですラベルです、ぐらいに作っておけばそういう設計で困らない。

233 :new tasksystem ◆9ycqcAuWxdGZ :2009/08/26(水) 03:53:03 ID:7Qo8yLie
>>229
> builder を使った場合でも、生成するタスクに生成処理の一部として渡すん
> だったらタスク内では(ファクトリ関数内も?)当然アクセスできちゃう
> わけで、どっちにしてもタスク実装者に対して隠蔽できていないという意味で
> 同じことだと思うんだけど。

全然同じことじゃない。

factory関数内からはサウンドクラスにはアクセスできる。factoryはclosureになっていて、(factoryを定義コードの)
親スコープからアクセスできたサウンドクラスを設定してある。

タスクA(>>231)はサウンドクラスにアクセスできるが、
タスクB,C,D,E,…のfactory + builderではサウンドクラスを提供しない。(渡さない)

よって、
・サウンドクラスを必要とするタスクAに対してしかサウンドクラスは公開されていない。
・タスクB,C,D,E,…からは直接的にはサウンドクラスにアクセスできない。

すなわちサウンドクラスの公開の範囲は適切であって、これはタスクに対して
サウンドクラスは正しく公開/隠蔽されていると言えると思う。

234 :new tasksystem ◆9ycqcAuWxdGZ :2009/08/26(水) 03:58:52 ID:7Qo8yLie
>>232
> 解放処理はMemoryPoolの寿命と一緒に行うことになってる。

生成〜開放を繰り返すとメモリを一瞬で使い切ってしまうんだけど、これは仕様なの?

> テンプレートクラスにして型ごとに取ってくるのも最初は考えたけどメモリ効率が余計悪くなるからやめた。

型ごとにとってきてあって、開放〜生成で前回開放したところを再利用するなら
メモリ効率はあなたのMemoryPoolの実装よりは遙かにいいと思うけど、
「メモリ効率」は、何をどういう基準で話しているの?

> 無理に解放しようとするとCPUが100%になったまま固まることがあるのでお勧めしない。

部分的に開放するだけだよ。たいした計算コストじゃない。

それでCPU負荷率が100%になるなら、
開放しなくともCPU負荷率は100%なんじゃないかと思うけどね。

235 :new tasksystem ◆9ycqcAuWxdGZ :2009/08/26(水) 04:05:04 ID:7Qo8yLie
>>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とは違うのかも知れない。なんかよくわからないが
話が噛み合ってない気がする。

236 :名前は開発中のものです。:2009/08/26(水) 04:07:30 ID:covJ0F+/
>>228
> ×タスク以外new禁止
> ○タスク(ITask派生クラス)内のコードでのnew禁止

うわ、マジで禁止すんの?びっくりした。
微妙に変えてあるけど、どっちでも邪魔だよ。

> 例えば、典型的なシューティングゲームで、タスク内のコードでnewする必要性がない。
> だから開発物が決まっている状況において、タスク内のnewを禁止するのは、別に厳しい制限ではない
> と思うよ。

開発する対象にシステムが依存してるってことになるね。それもびっくり
だなぁ。

>152-153 では「具体的なクラスを全部システム側が知ってる」っていうのが
マズイという認識は共有できていたのに、こっちはかまわないっていう
感覚には、共感できないよ。

> 逆にあなたにお聞きしたいが、タスク内でnewしたいケースというのは、
> 一体、どういうケースなんだ?

いくらでもあるでしょ。出すか出さないか実行時に決まるエフェクトとか?
new が要らないように工夫することも可能だったりするんだろうけど、
システムの制限のせいでそういうことを考えないといけないということだと、
やっぱり邪魔だと思ってしまうよ。

237 :名前は開発中のものです。:2009/08/26(水) 04:15:39 ID:covJ0F+/
>>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を禁止にすれば」ってサラっとかいてあるのがもう
ありえない選択肢なんだけどね。

238 :new tasksystem ◆9ycqcAuWxdGZ :2009/08/26(水) 04:16:35 ID:7Qo8yLie
>>236
> 開発する対象にシステムが依存してるってことになるね。それもびっくり
> だなぁ。

なんか捉え方がおかしくない?

ミドルウェアってそういうもんでしょうに。
2Dのゲーム作りたいのに、3Dの物理エンジン買ってきて、作ったってしょうがないでしょ?

特定の開発対象にタスクシステムが適合するってだけ。
そのタスクシステムを使うときに、特定のルールを決めておけば、余計なバグが発生しないってだけ。

> >>152-153 では「具体的なクラスを全部システム側が知ってる」っていうのが
> マズイという認識は共有できていたのに、こっちはかまわないっていう
> 感覚には、共感できないよ。

「具体的なクラスを全部(タスク)システム側が知ってる」というのがマズイとは私は
言っていない。そういう設計にするメリットとデメリットとがあるよね、というだけ。

>>236のタスク内のnew禁止にしても、そうすることのメリットとデメリットがあって、
特定のプロジェクトにおいてはメリットのほうがデメリットに勝るからそうすることが
あるよって言ってるだけ。「マズイ/マズくない」の問題じゃない。

しかし、newしたものをタスクシステムに渡すことに関しては
233-234に具体的な大きなデメリットがあって、これは私は致命的だと思うから、私は反対。


239 :名前は開発中のものです。:2009/08/26(水) 04:18:50 ID:covJ0F+/
>>230
> いま思い出したのだが、タスクを呼び出し側でnewしてタスクシステムに渡す構造になっていると
>
> taskSystem -> AddTask( ptr ); // new していないポインタ

これはファクトリから new してないポインタ返すことを考えれば
同じことだよ。

> IEnemy* enemy = new EnemyBoss123();
> taskSystem -> AddTask ( enemy ); // 勝手にupcastしたポインタ

ん?なんでアップキャストが問題になるの?
その問題が、ファクトリ通すとどうにかなるの?

240 :new tasksystem ◆9ycqcAuWxdGZ :2009/08/26(水) 04:20:50 ID:7Qo8yLie
>>236
>> 逆にあなたにお聞きしたいが、タスク内でnewしたいケースというのは、
>> 一体、どういうケースなんだ?
> いくらでもあるでしょ。出すか出さないか実行時に決まるエフェクトとか?
> new が要らないように工夫することも可能だったりするんだろうけど、
> システムの制限のせいでそういうことを考えないといけないということだと、
> やっぱり邪魔だと思ってしまうよ。

例えば、爆発のエフェクトが出したいなら、そのタイミングで
爆発のエフェクトを表示するタスクを生成すればいいことだから。

まあ、それはゲームによりけりだし、そういう設計だとコードが冗長に
なるということはあるだろうけど。

何度も言うけどnew禁止は絶対じゃない。そういうローカルルールを用意して
開発するのも現実的には有効だと言ってるだけなのだが。


241 :名前は開発中のものです。:2009/08/26(水) 04:22:16 ID:Jc1aOsD2
>>234
>生成〜開放を繰り返すとメモリを一瞬で使い切ってしまうんだけど、これは仕様なの?
仕様。MemoryPoolをいつまでも使い続けるとメモリが果てるようになってる。
この仕様を維持しつつ、適当にデフラグができたらいいんだけど、いかんせん無理がある。

>「メモリ効率」は、何をどういう基準で話しているの?
newの呼び出し回数とコンストラクタに渡されるsizeで。

>部分的に開放するだけだよ。たいした計算コストじゃない。 
なんか知らんが固まる。
たぶん、重大なバグが原因だろう。検証はまだしてない。
しかし、どのみち部分的に解放するとその分遅くなるのでfree(...)でどうにかしてる。
部分的な解放ができないこと自体、仕様なので諦めてほしい。

242 :名前は開発中のものです。:2009/08/26(水) 04:26:21 ID:covJ0F+/
>>231
>> 具体的に、生成処理から(例として)サウンドクラスへのアクセスを禁止できた
>> として、何が得られるの?

> いま、static変数は極力廃止してあるという前提で話を進める。(この前提については認めてもらえる?)
これは大賛成。

> いま、タスクAにはサウンドクラスが必要で、タスクBにはサウンドクラスが不要だとしよう。
...
> この呪いのようなサウンドクラスをもらうための連鎖とそれに付随するコード修正が限りなく続いていく。これがとても嫌。

これがファクトリで解決するってことは、ファクトリのコンテキストには
システム側からサウンドクラスが渡される(あるいはシステムから
取り出せる)んだよね?

それなら、コンストラクタの引数で渡せるように、システムから
サウンドクラスへの参照が取り出せるようになってればいいんじゃないの?
( SoundClass& System::Sound() って感じで)

生成箇所では System.Add() を呼び出すんだから、そこに System.Sound() が
あっても何の問題も無いでしょ。・・・やっぱり何かあるのかな?

243 :new tasksystem ◆9ycqcAuWxdGZ :2009/08/26(水) 04:30:00 ID:7Qo8yLie
>>237
> 「メモリリークをなくしたい」という目的で、独自のシステムに制限と
> コードを加えていくよりも、こういった汎用的な方法を取ったほうが制限も
> コードも少なくて済むという話。

ふむ、別にそれ(shared_ptrの使用)に関しては私は反対じゃないよ。


244 :new tasksystem ◆9ycqcAuWxdGZ :2009/08/26(水) 04:33:26 ID:7Qo8yLie
>>237
> 個人的には「newを禁止にすれば」ってサラっとかいてあるのがもう
> ありえない選択肢なんだけどね。

new禁止どころか、もっと強い制約を課することもあるよ。

例えばユーザー(タスクシステムを使う側のプログラマ)のコードを、単なるスクリプトと
みなして、特定の命令しか書けないように制約を課したいことだってある。

プログラマーより、さらにプログラムについて理解に乏しい、スクリプターと呼ばれる
ような人たちに、タスク部分のコードを書かせないといけないときは、そうだね。

彼らの書くコードに特定の命令しか書けないように縛りを入れる。

Luaのような外部のスクリプト言語を使ってもいいけど、
C++で特定の命令しか使わせないことで同じことが出来るなら、
C++で書かせたほうが実行効率がいいし、余計なセキュリティ上の問題に晒されなくて済む。

まあ、結局、それは開発スタイルの問題だと思うよ。

あなたは、ゲームをまるごと一人で作ることを想定しているから
「newを禁止なんてありえない!」となるんだ。

実際はゲームはひとりで作れる規模じゃないものだってたくさんある。
分業するには、下位のクラスにあまり大きな権限を持たせるべきではない。

さきほどのサウンドクラスへのアクセス権にしてもそう。

あなたの考えでは、「別にすべてのタスクがサウンドクラスへのアクセス権を
持っててもいいじゃん?それでどんなデメリットが生じるの?」ってことなんだろうけど
規模の大きなゲームでは、下位クラスの開発者にまでそんな余計なアクセス権をもたれると
こちらが想定していない使い方をされたりして開発に支障が出たりするんだよね。

245 :new tasksystem ◆9ycqcAuWxdGZ :2009/08/26(水) 04:40:12 ID:7Qo8yLie
>>239
>> taskSystem -> AddTask( ptr ); // new していないポインタ
> これはファクトリから new してないポインタ返すことを考えれば
> 同じことだよ。

どうも話が噛み合っていないと思う。

あなたは、私の書き込みを飛ばし飛ばしにしか読んでいないからだろうし、
すべて読んでくれとお願いする気もないのでこの場で再度説明しておくけど、

私の提案する実装では、
factoryはタスクシステムに事前に登録しておいて(>>153)
タスク側が、他のタスクを生成するときは、タスクシステムに対して、newTask(>>155,159)で
生成するから、factoryからnewしていないポインタをもらって、
それをtaskSystem -> AddTaskなんてことはすること自体が出来ない。

246 :new tasksystem ◆9ycqcAuWxdGZ :2009/08/26(水) 04:44:35 ID:7Qo8yLie
>>239
>> IEnemy* enemy = new EnemyBoss123();
>> taskSystem -> AddTask ( enemy ); // 勝手にupcastしたポインタ
> ん?なんでアップキャストが問題になるの?
> その問題が、ファクトリ通すとどうにかなるの?

タスクデータベース(>>179,197)のようなものをどこかにおいて、
タスクに対するqueryに応答できるようにしたい。

そのためには、タスク生成時に、その生成された型とオブジェクトのアドレスを
何らかの方法で通知する必要がある。

タスクのオブジェクト自体はITask派生クラスであり、かつ、タスクの生成は
タスクシステム側の入り口(エントリーポイント)を必ず通過するようになっていれば
生成自体を捕まえることは出来るが、そのときにオブジェクトの型を知る必要がある。

型自体は、typeidで取得してもいいけども、型ごとに特定の処理をさせたいことも
あるから、特定の型に対しては、>>159のnewTaskをtemplateの特殊化で記述できると
都合が良い。

それなのに、勝手にupcastされたポインタを渡されると、templateの特殊化をする
ような実装にしようとしたときに困る。

247 :new tasksystem ◆9ycqcAuWxdGZ :2009/08/26(水) 04:50:29 ID:7Qo8yLie
>>241
> >部分的に開放するだけだよ。たいした計算コストじゃない。
> なんか知らんが固まる。
> たぶん、重大なバグが原因だろう。検証はまだしてない。

そんなのバグに決まってるじゃん。ソース出してみなよ。見てあげるよ。

> しかし、どのみち部分的に解放するとその分遅くなるのでfree(...)でどうにかしてる。

だから型ごとにvector用意すればいいじゃん。
型ごとにvector用意したほうが、よっぽど速いと思うけど。

boost::unordered_map<type_info,vector<void*> > maps;

まあ、同じ型のobjectがいっぱいあると開放するには線形時間はかかるだろうけど…。

248 :new tasksystem ◆9ycqcAuWxdGZ :2009/08/26(水) 04:58:13 ID:7Qo8yLie
>>242
>> いま、static変数は極力廃止してあるという前提で話を進める。(この前提については認めてもらえる?)
> これは大賛成。

ふむ、あなたはたぶん、かなり優秀なプログラマなんだと思う。

私はあなたほどは理想主義じゃないんだろうな。たぶん、私は長年、たくさんの
とんでもないヘタレプログラマと一緒に仕事をしてきて、彼らがどんなヘマをしでかすか
(間接的には私のほうに原因があるものもあるのだが)を見て、結構、へこんだり、落ち込んだり、
悩まされたり、胃が痛くなったり、まあ、そんなこんなで、やや現実的になりすぎているのだろう。


249 :new tasksystem ◆9ycqcAuWxdGZ :2009/08/26(水) 05:04:57 ID:7Qo8yLie
>>242
>> いま、タスクAにはサウンドクラスが必要で、タスクBにはサウンドクラスが不要だとしよう。
...
>> この呪いのようなサウンドクラスをもらうための連鎖とそれに付随するコード修正が限りなく続いていく。これがとても嫌。
> これがファクトリで解決するってことは、ファクトリのコンテキストには
> システム側からサウンドクラスが渡される(あるいはシステムから
> 取り出せる)んだよね?

うん。その通り。factoryはclosureで記述されていて、タスクシステムのスタートアップコードに
近いところで設定される。

> それなら、コンストラクタの引数で渡せるように、システムから
> サウンドクラスへの参照が取り出せるようになってればいいんじゃないの?
> ( SoundClass& System::Sound() って感じで)
> 生成箇所では System.Add() を呼び出すんだから、そこに System.Sound() が
> あっても何の問題も無いでしょ。・・・やっぱり何かあるのかな?

ここで言う「システム」とは「タスクシステム」のことかな?

だとして、「タスクシステム」は、サウンドクラスとは無縁のクラスだからそんなところには
サウンドクラス(の参照)をメンバとして持たせたくない。

また、「サウンドクラス」は一例であって、実際は開発時にいろいろあとから追加される
何か(タスクシステムとは別の)グローバルリソースへのアクセスが必要なクラスなんだ。

250 :new tasksystem ◆9ycqcAuWxdGZ :2009/08/26(水) 05:05:18 ID:7Qo8yLie
249の続き。

>>242
「タスクシステム」はfixされた、ソースのいじれないクラスだと思って欲しい。
だからあとから追加された「サウンド」クラスを「タスクシステム」に入れ込むことは出来ない。

もうちょっと具体的に現場の状況を書けば、
「タスクシステム」自体は、クラスとして可搬性のあるように設計されている。
どの環境でも動くように設計されている。移植先が仮にiPhoneだとしてiPhone SDKの
「サウンドクラス」に関する参照をタスクシステムが保持するのはおかしいよね。

そんなことをすると「タスクシステム」は可搬性を失ってしまう。
だから「タスクシステム」にクラスを追加するのはナシ。

251 :名前は開発中のものです。:2009/08/26(水) 05:08:27 ID:covJ0F+/
>>233
> factory関数内からはサウンドクラスにはアクセスできる。factoryはclosureになっていて、(factoryを定義コードの)
> 親スコープからアクセスできたサウンドクラスを設定してある。
...
> タスクA(>>231)はサウンドクラスにアクセスできるが、
> タスクB,C,D,E,…のfactory + builderではサウンドクラスを提供しない。(渡さない)

なるほど。これで >231 にある B が A を作る状況になると、 B が持ってない
サウンドクラスをクロージャが補ってくれるわけだね。確かにこれは直接 A の
コンストラクタを呼ぼうとするとできない。


クロージャによるファクトリ登録に有効な場面があることはわかったよ。
ありがとう。

でもやっぱり全体の仕組みとして組むのはなぁ・・・と思いながらリロードしてレスを
見てたら、・・・
>>246
> そのためには、タスク生成時に、その生成された型とオブジェクトのアドレスを
> 何らかの方法で通知する必要がある。
これだと型を受け取りながら生成しないといけないから、 >154 みたいな
ファクトリが要るね。

この点が見えてなかったのと、あと >>238 にある、システムが利用側に
依存してもいいっていうのがありえないと思って話してたから、いろいろと
噛み合わない話になっちゃったと思う。ごめんよ。

ひととおりつじつまの合う情報をもらったんで、ようやく理解できたよ。(共感は
できないけどね。)根気強く付き合ってくれてありがとう。

252 :new tasksystem ◆9ycqcAuWxdGZ :2009/08/26(水) 05:11:50 ID:7Qo8yLie
>>242に付随して、
タスク側がどうやってタスクシステムにアクセスできるのかについてハッキリさせておこう。

■ タスク側がどうやってタスクシステムにアクセスできるのか

タスクは他のタスクをタスクシステムに依頼して生成してもらわなければならない。
すなわちタスクはタスクシステムへのポインタを何らかの形で持っている。

これには二つ方法がある。

class ITask
{
 TaskSystem* taskSystem;
// 以下略


のように、タスク基底クラス自体がTaskSystemへのポインタを持っておき、
タスクシステムでのタスク生成時にこいつを設定してもらうことだ。

しかし、グローバルリソースのようなものにタスクがどうやってアクセスするかという話になる。
タスクシステムにサウンドクラスを持たせるような実装が論外であることは>>249-250ですでに述べた。

また、すべてのタスク基底クラスがTaskSystem*を保持しているのは、やや無駄である。


253 :new tasksystem ◆9ycqcAuWxdGZ :2009/08/26(水) 05:16:06 ID:7Qo8yLie
>>252の続き。

そこで、実際は、ITaskのupdateは次のようにする。

virtual void update(TaskSystem* );

タスクシステム自体を引数として渡してやる。では描画はどうする?
ほとんどすべてのタスクは描画する必要がある。描画用のコンテキストも渡すのか?それとも
factory + builderで事前に渡すのか?という問題になる。描画先のスクリーンを切り替えたり
したい時はどうなるんだ?という話になる。

そこで、updateは、このような固定化されたクラスではなく、次のようにゲーム用のコンテキストを
渡すほうが理にかなっている。

template class <GameContext>
virtual void update(const GameContext& context);

このようにtemplateで書く。GameContextは、ゲームによって異なる。
タスクシステムはこのGameContextの内容までは関知したくないのでtemplateになっている。


254 :new tasksystem ◆9ycqcAuWxdGZ :2009/08/26(水) 05:19:46 ID:7Qo8yLie
>>253の続き。

典型的なゲームでは、

class GameContext
{
 TaskSystem* taskSystem;
 DrawContext* draw;
 SoundManager* sound;
 InputManager* input;
};

のようになっているだろう。ITask派生クラスのupdateでは、このcontextに基づいて
描画をしたりサウンドを再生したりする。

こうしておけば、比較的すんなり書けるが(>>231の問題が解決!)、
下位のタスクにまでInputManagerにアクセスできて良いのか?
というアクセス制御上、問題があるとも言える。(例 >>244)

そこで、factory + builder側で渡す方法もある。(例 >>233)

まあ、どちらの設計が正しいというわけでもないので
シーンごとに適切に使い分けていただきたい。


255 :new tasksystem ◆9ycqcAuWxdGZ :2009/08/26(水) 05:27:57 ID:7Qo8yLie
>>251
> ひととおりつじつまの合う情報をもらったんで、ようやく理解できたよ。(共感は
> できないけどね。)根気強く付き合ってくれてありがとう。

理解できたようで何より。

まあ、こういう設計もアリなんだな、という程度に捉えてもらえるとありがたい。

実際は、>>252-254のように設計することのほうが好ましいことが多いと思う。
もしかしたら、>>252-254のほうが実装が簡単で、あなたの感性にfitすると思う。

あと、やねうらおが10年以上前に提示したyanesdk3rdのタスクシステムのコードが
>>252-254のようになっていたと思う。

256 :えいいち ◆GRGSIBERIA :2009/08/26(水) 05:56:10 ID:Jc1aOsD2
>>235
>typeid指定してタスクシステムからそのタスクの集合をもらう。
ごめん。タスクシステムの実装がどうなってんのかわかんないから一部だけだとわからない。

>そういう設計
タスク内でtypeidをどうやって扱うか云々。
当たり判定だったら誰と当たり判定をするのか、って部分が簡単に書ける。

>話が噛み合ってない気がする。 
自分の性格が適当すぎるからそういう意味でかみ合ってない。

>>247
http://kansai2channeler.hp.infoseek.co.jp/cgi-bin/joyful/img/9911.txt
とりあえず改修。deleteで止まるのはreinterpret_castが原因だと思う。

>まあ、同じ型のobjectがいっぱいあると開放するには線形時間はかかるだろうけど…。
これはちょっと困るな。
MemoryPool<T, num> obj; みたいな形でT型num個分の領域を確保しておく、ってのなら速度は維持できるけど。

257 :えいいち ◆GRGSIBERIA :2009/08/26(水) 05:57:29 ID:Jc1aOsD2
と言うわけで落ちます。

お先に失礼

258 :new tasksystem ◆9ycqcAuWxdGZ :2009/08/26(水) 06:18:27 ID:7Qo8yLie
>>256
>>typeid指定してタスクシステムからそのタスクの集合をもらう。
> ごめん。タスクシステムの実装がどうなってんのかわかんないから一部だけだとわからない。

>>197のgetTasksがその具体的なコード。

> タスク内でtypeidをどうやって扱うか云々。
> 当たり判定だったら誰と当たり判定をするのか、って部分が簡単に書ける。

言ってる意味がよくわからないんだ。
「簡単に書ける」コードを実際に書いてみせてくれないかな。


259 :new tasksystem ◆9ycqcAuWxdGZ :2009/08/26(水) 06:19:08 ID:7Qo8yLie
>>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としてはよくある実装だと思うね。


260 :new tasksystem ◆9ycqcAuWxdGZ :2009/08/26(水) 06:35:29 ID:7Qo8yLie
>>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入れるかにしときなよ。



261 :new tasksystem ◆9ycqcAuWxdGZ :2009/08/26(水) 06:41:08 ID:7Qo8yLie
>>241
あと

> _next = NULL;

先頭アンダーバーから始まる変数名はC++の実装者が使っていることがあるから使用してはいけないはずなのだが。

> itr = _next;

こんなことしたら、メモリを取得できないときは、いくつものMemoryPoolのpool_allocが連鎖的に呼び出されて
パフォーマンスがすこぶる落ちるのだけど。

しかもこの実装は最後にまとめてしかメモリを開放しないから、一度落ちたパフォーマンスが回復することは永遠にないな。

> ptr->~T();

Tのコンストラクタは呼び出さないのに、デストラクタだけ呼び出すんだな。このMemoryPoolは一体、なにがしたいんだ…。

とんだド素人のプログラムだな。こんなもの、0点だ、0点。C++初心者スレで勉強させてもらってきなさい。

262 :185:2009/08/26(水) 07:44:50 ID:3JaQfvWX
高レベルの話になると調子がいいが
具体的な低レベルの話になると途端に煽ってくるのな

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

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

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


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

263 :new tasksystem ◆9ycqcAuWxdGZ :2009/08/26(水) 08:02:24 ID:7Qo8yLie
>>262
> 高レベルの話になると調子がいいが
> 具体的な低レベルの話になると途端に煽ってくるのな

え?それは私のことか?

>>185に対してなら、私は>>201で答えているぞ。

私に質問があるなら、私の書き込みに対してアンカー打つか、指名しとくれ。

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

自機と敵とのオブジェクトの寿命によって、>>203のような分類で決める。
相互作用(behavior)に関するコードなら、>>223, >>226

264 :new tasksystem ◆9ycqcAuWxdGZ :2009/08/26(水) 08:05:11 ID:7Qo8yLie
>>262
> >9ycqcAuWxdGZ
> コードも見てみたけど これを元にあんたの創造するコードを俺らがエスパーすんの?
> 日常会話通じる?深夜しか書き込みしてないけど、自宅警備員?
> 精神病院逝け

これだけ一通り情報があって>>251みたいにちゃんと理解できた人もいるわけで、
ここから何も読み取れないとは、よっぽどのC++初心者なんだな。

そりゃ全然、話にならんわ。底辺プログラマに合わせる気は毛頭ないので
それ相応の実力をつけてから戻ってきてね。

265 :名前は開発中のものです。:2009/08/26(水) 08:21:04 ID:3JaQfvWX
>>264
なんかの質疑応答文を読み上げてるだけの某理大臣の答えにしか聞こえないが・・・
あんたの主張はなんだといいたいんだよ

底辺と言われてるが、あんたの答えはあたり前田すぎて
新鮮味にもおもしろみにも欠けるんだが・・・

まぁ、裸の王様だな

266 :名前は開発中のものです。:2009/08/26(水) 08:25:31 ID:3JaQfvWX
>>264
他にもたとえると
台風が来たときに 台風直撃のテレビの前で「台風です!」
と言っている 誰でもみりゃ分かるわボケというレベル

このまま政治家にでもなれば?
多分あんたの部下っていないだろ?
正確に言うとついてこないだろ?
ついていきたくないの 分かる?わかんねーだろうなぁ

267 :new tasksystem ◆9ycqcAuWxdGZ :2009/08/26(水) 08:28:43 ID:7Qo8yLie
>>265
> あんたの主張はなんだといいたいんだよ

タスクシステムは十分使える手法だということだな。

> 底辺と言われてるが、あんたの答えはあたり前田すぎて

そんなことは知らんがな。

あんたが底辺プログラマでないなら、私の提示したタスクシステムから
ソースコードの全貌が想像つくはずだが、それすら「エスパー」しないとわからんのだろ?(>>262)

そりゃ全然駄目だわ。話にならんわ。

ここはC++ド素人の厨房のためのスレじゃないんだから
C++の教科書から勉強しなおしてきなよ。

268 :new tasksystem ◆9ycqcAuWxdGZ :2009/08/26(水) 08:30:33 ID:7Qo8yLie
>>266
> 台風が来たときに 台風直撃のテレビの前で「台風です!」
> と言っている 誰でもみりゃ分かるわボケというレベル

違うね。あんたは、ソースが全く読めてないよ。
たとえて言うなら台風が来てるのに「地震だ!」「火事だ!」って騒いでいるキチガイだ。

> ついていきたくないの 分かる?わかんねーだろうなぁ

私なら、あんたみたいな無能な部下はいらんよ。

269 :名前は開発中のものです。:2009/08/26(水) 08:56:48 ID:XgDr3Ki9
新着レス多すぎだろ、ドンだけレスしてんだよ
胃がびっくりするだろうが

270 :名前は開発中のものです。:2009/08/26(水) 09:13:53 ID:J18VokP2
夜中にスレ進みすぎててワロタ

>>197とか>>235とかマジすか?って思うのはC++ド素人だからか
最近のマシンは早いからそういう実装でも問題無いのかな…

271 :new tasksystem ◆9ycqcAuWxdGZ :2009/08/26(水) 09:18:47 ID:7Qo8yLie
>>270
> >>197とか>>235とかマジすか?って思うのはC++ド素人だからか
> 最近のマシンは早いからそういう実装でも問題無いのかな…

扱うタスクの数によるだろうね。せいぜい1000タスクぐらいを私は想定しているが、
これが1万とか10万とかだというなら、こんな方式をとるべきではない。

1万とか10万もタスクがあるなら、タスク呼び出しのオーバーヘッドすら御免被りたいので、
タスクではなく、単なるactor (要するにただの構造体に簡単なオペレーションのためのmethodがついたもの)として、
そのbehaviorを記述できるようなシステム(タスクシステムとは呼ばないんだろうな。ゲームエンジン?)にするよ。

272 :名前は開発中のものです。:2009/08/26(水) 10:10:08 ID:J18VokP2
デバッグ専用か、起動時のみとか数フレームに一回呼ばれるだけとかならおkだけど…
1000タスクもあって、毎フレーム自機と敵とで複数回呼ばれるとすると怖くて使えないなぁ…

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

273 :new tasksystem ◆9ycqcAuWxdGZ :2009/08/26(水) 10:29:41 ID:7Qo8yLie
>>272
> 1000タスクもあって、毎フレーム自機と敵とで複数回呼ばれるとすると怖くて使えないなぁ…
> 玄人になるためにも今度実測してみよう、案外たいしたこと無いかもしれないし

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

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

274 :名前は開発中のものです。:2009/08/26(水) 10:44:01 ID:Z0KFUVVj
タスクと関係ないが盛り上がってるようで質問

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

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

何かいい方法を教えて

275 :名前は開発中のものです。:2009/08/26(水) 10:46:16 ID:SqYnNIJH
1フレームに2〜3回くらいのつもりで発言した
たしかに同じ結果を返すものはキャッシュした方がいいだろうな

276 :名前は開発中のものです。:2009/08/26(水) 10:58:04 ID:L5twc2Wr
俺なら>>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);}

と出来ちゃうので、生成より参照が多い場合はこれで安心。

277 :new tasksystem ◆9ycqcAuWxdGZ :2009/08/26(水) 10:58:32 ID:7Qo8yLie
>>274
MapClassとUnitClassの寿命は同じと仮定していいのか?
同じなら、

struct Field
{
 MapClass map;
 UnitClass unit;
}

みたいな入れ物用意して、Field自体をMapClassとUnitClassのコンストラクタかbuilderで
渡してやるのがスマートだと思うけどな。

寿命が違うなら、もう少し抽象化された通信手段を提供する必要がある。例えば、 >>203

あるいは、もっと抽象化したければ、相互に通信可能な channel で二つのobjectを結んでやるような実装もありうる。

1つのMapClassに対して複数のUnitClassが対応していて、それぞれのUnitClassに同じ通知を送らないといけないような時などは
こういう仕組みがあると便利かも知れない。

278 :名前は開発中のものです。:2009/08/26(水) 11:00:06 ID:L5twc2Wr
>>276
おっと修正。あのカッコの中はthisな。

279 :new tasksystem ◆9ycqcAuWxdGZ :2009/08/26(水) 11:10:51 ID:7Qo8yLie
>>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回というのが多すぎるかどうかは知らないが。

280 :名前は開発中のものです。:2009/08/26(水) 11:19:20 ID:L5twc2Wr
>>274
この例だとUnitClassを更新するとき、足場情報として渡してしまったほうが自然な希ガス。
UnitClass::update(MapClass *mappoint)とか。
あるいはもっと限定的に、抽象的な階層でやるとか。
UnitClass::update(UnitMoveingEnv *env)とか。

地形が崩れるとか、ってのはMapClassインスタンス自体の置き換えとか、
パラメータ与えての更新とかになりそうだから、
MapClassとUnitClassのインスタンス郡を操作する、
上位のレベルで処理を行うべきに見える。
足場情報を与えたりするのも、当然その上位レベルのクラス。

281 :new tasksystem ◆9ycqcAuWxdGZ :2009/08/26(水) 11:24:30 ID:7Qo8yLie
>>276
> std::list < ITask* >として画一的に扱おうとして、混ぜたものを、
> 後から選り分ける、というのは設計として退化してる。

その考え方は間違いだと思うね。

DBとか全部データを放り込んで、それをqueryで取り出すじゃん。

それを事前に選別したり分類したりしてstoreしておくと記憶容積がもったいないじゃん。

取り出されるパターンが類型化していたり事前にわかっていれば、indexを事前に張ったりは出来るけど、
今回は、事前にわかっているという仮定ではないと思うのだけどな…。

282 :名前は開発中のものです。:2009/08/26(水) 11:26:15 ID:L5twc2Wr
>>279
> それだと、タスクシステム自体が、Enemyクラスを知っている必要があって、
> タスクシステム自体の可搬性が失われているから論外。

ゴメン実はタスクシステムってよく知らないんだw
Enemyクラスだろうが、何クラスだろうが、
それをインスタンス化して使おうとする、使う側のクラスは、
それらの型情報やインスタンスの保持の仕方を知っているのは当然のこと。

> あるいは、タスクシステムにそんなごてごてした機能を追加したくなければ、

ごてごて?

class Task{
enter();leave();
}
class EnemyTask() : public Task {
EnemyTask(alltasks, enemytasks)
enter() {略}leave{略}
}

こうやってて、
alltasksを実際に扱ってるクラスで、
タスクをインスタンス化するついでに、
new EnemyTask(alltasks, enemytasks)
してやればいいんじゃないのかな。

あとはいたるところでtask.enter(), task.leave()するだけでシンプル。

283 :名前は開発中のものです。:2009/08/26(水) 11:31:33 ID:L5twc2Wr
>>281
> DBとか全部データを放り込んで、それをqueryで取り出すじゃん。

あれはクエリが複雑になるだろうから、
事前に準備しようがないでしょうにw

284 :名前は開発中のものです。:2009/08/26(水) 11:33:07 ID:covJ0F+/
>>264
> これだけ一通り情報があって>>251みたいにちゃんと理解できた人もいるわけで、
> ここから何も読み取れないとは、よっぽどのC++初心者なんだな。

なんか調子に乗り過ぎてない?

>>251 で「理解できた」と言っているのは、 >>152 で聞いた「生成を管理」
するかどうかの判断についてどういうメリット・デメリットを考えたら
「生成を管理する」なんて面倒な判断になってしまうのか、ということだけ。

だから、システム全体の意義を理解したわけじゃない。むしろシステム全体の
意義については、まだ不審な点がある。具体的に聞いてみたい点が出てくれば
また聞かせてもらうことになるかもしれない。

このスレの意義としては、システム全体の意義についての批判にも建設的な
答えをして欲しいところ。批判と煽りが混ざっていて不愉快かもしれないけど、
煽られて煽り返すような流れは敢えて断ち切って欲しいなぁ。(煽りは無視
すればいいだけだと思う。)

285 :new tasksystem ◆9ycqcAuWxdGZ :2009/08/26(水) 11:34:21 ID:7Qo8yLie
>>282
ああ、意味がわかった。Task::Enterというのは、EnemyTask::Enterのことか?

単にTaskと書いてあったから、それがタスクシステムであって、タスクシステムのaddTaskで
EnemyTaskだけ ぶんどる話かと誤解した。ごめん。

> new EnemyTask(alltasks, enemytasks)

これは嫌だな。その設計だと、EnemyTaskを生成したいタスクが、
alltasks(すべてのタスクのlist) と enemytasks (敵のタスクのlist )に対してアクセス権を
持っていることになる。

敵タスクを生成するのが、敵タスクだとは限らない(全然別のタスクの可能性だってある)ので、
そういうタスクが、enemytasks にアクセスできるのはおかしい。alltasksに出来るのはもはや論外。

あと、EnemyTaskを列挙したいのは、たとえば自機クラスであって、自機クラス何らかの設計変更によって
突如、敵タスクを列挙したくなったからと言って、EnemyTaskのシグネチャを変更して、かつ、その生成を
行なっているところのコードをすべて修正しないといけないのはおかしい。

要するに設計がおかしい。

286 :new tasksystem ◆9ycqcAuWxdGZ :2009/08/26(水) 11:36:45 ID:7Qo8yLie
>>283
> あれはクエリが複雑になるだろうから、
> 事前に準備しようがないでしょうにw

今回のケースだって、事前にqueryは予測できないよ。

敵タスクのみ列挙したいというのは仮定することが出来ないし(と私はこの問題を捉えている)、
仮にその仮定ができたとしても、そもそも>>276の実装は>>279で書いているようにさほど高速化できている
とは言えず、記憶容積を無駄にしているだけ。

また、設計的にも、>>285の欠陥がある。

287 :new tasksystem ◆9ycqcAuWxdGZ :2009/08/26(水) 11:43:24 ID:7Qo8yLie
>>284
> だから、システム全体の意義を理解したわけじゃない。むしろシステム全体の
> 意義については、まだ不審な点がある。具体的に聞いてみたい点が出てくれば
> また聞かせてもらうことになるかもしれない。

どんどん質問しとくれ。あんたの質問なら歓迎だ。

> このスレの意義としては、システム全体の意義についての批判にも建設的な
> 答えをして欲しいところ。

それは出来かねるなぁ・・。

このスレは学校でもなければ教育現場でもないので、本人に知りたいという意欲があって、
かつ、ある程度の理解力があると思ったときだけ私は答えるようにしている。

ひとことで言えば気が向いたときだけ私は質問に答える。
煽りに煽りで返すのが見苦しいと言うのはわからなくはないが、まあ、私は気の向いたようにやるよ。

288 :new tasksystem ◆9ycqcAuWxdGZ :2009/08/26(水) 12:01:46 ID:7Qo8yLie
>>284
>> これだけ一通り情報があって>>251みたいにちゃんと理解できた人もいるわけで、
>> ここから何も読み取れないとは、よっぽどのC++初心者なんだな。
> なんか調子に乗り過ぎてない?

これについてだが、私は自分が、調子に乗りすぎているとはこれっぽっちも思わないよ。

少なくとも、あんたは、いま私が想定している「タスクシステム」について
その全体的なソースコードをいま頭のなかにイメージできているはずだ。

それに対して>>262は、全くソースコードすらイメージできていないと言うから
それは真面目に読んでいないか、C++等の能力が足りないかだろうと言っているんだ。

> だから、システム全体の意義を理解したわけじゃない

タスクシステムの意義なんか私は全く話してないよ。
タスクシステムは、こう実装して、こう使うというのを一通り見せただけ。

しかし、あんたのように私の文章を本気で読んでくれたなら
どう実装するかぐらいは頭に浮かんだはずだし、どういうケースで
タスクシステムが有効に機能するかぐらいわかると思うんだが。


289 :名前は開発中のものです。:2009/08/26(水) 12:05:56 ID:vql/az8v
>>262
本当に聞きたいなら >211 を読んで質問の仕方を変えたら?
詭弁で相手を言い負かしたいだけとしか思えない書き込みも多いから
それと混同されてしまうよ。

290 :名前は開発中のものです。:2009/08/26(水) 14:14:38 ID:3JaQfvWX
>そんなことは知らんがな。
こっちも知らんがなw

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

(また、知らんがなとか言うんだろうなw」)


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

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


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

291 :名前は開発中のものです。:2009/08/26(水) 15:56:26 ID:Jc1aOsD2
>>258
>>197のgetTasksがその具体的なコード。 
と言われても、やりたいことはわかってもわからんがな。
システム自体、クラス化してるかと思ったらそうでもないし。
正直、想定の範囲外だし、いっぺん作ってみないと想像できん。

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

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

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

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

292 :えいいち ◆GRGSIBERIA :2009/08/26(水) 16:29:50 ID:Jc1aOsD2
>>260
>いま気づいたが、このMemoryPool、馬鹿ほどメモリを消費して、OSのswapが生じてるんじゃないのか。 
キャストで領域を割り当ててるからなんじゃないの?
free(...)で呼び出す分には何も起こらないし。

>何故次へのポインタがpublicである必要があるんだ?
関数呼び出しと命令数削減のためいつの間にかpublicに追い出されてた。

>何故ここがlongなんだ? size_tを指定して確保してあるのだから、範囲はsize_tだろうが。
今気付いた。thx

>メンバ変数名と引数で全然違う名前にするの勘弁してくれ。ソースが追いかけにくい。
悪い。癖だ。

>Tのコンストラクタは呼び出さないのに、デストラクタだけ呼び出すんだな。
コンストラクタの検証だけやってなかったな。一応、修正した。
まあ、速度はさらに落ちたが。

293 :名前は開発中のものです。:2009/08/26(水) 18:15:15 ID:3JaQfvWX
王様ご就寝w

294 :名前は開発中のものです。:2009/08/26(水) 18:29:38 ID:3JaQfvWX
やべ、王様に勝手に進言しただけで赤字になるw
他の連中も

すばらしい管理体制ですね
さすがゲ板 噂 聞きしに勝る板

295 :名前は開発中のものです。:2009/08/26(水) 19:04:11 ID:3JaQfvWX
ここまで熟知しておきながら2chに来るとは・・・目的は タダ単に僕はしゅごいぞ ウルトラマンだぞーか?
優秀な技術者ならまずこないだろう
トリップもつけて房っぷりも発揮
日本語のやりとりもおぼつかず
専門用語だけ詳しい 真性の奴隷か

60回以上にものぼる赤字の無視
トリップのつけ方も知ってるんだ、知らないではすまないだろう
ついにアク禁か?

296 : ◆HSP4mee/SU :2009/08/26(水) 20:47:41 ID:JMZry9YB
この人こわい

297 :名前は開発中のものです。:2009/08/26(水) 21:19:26 ID:v5rbTd5J
>>203
最悪じゃん
意味があるのかないのかわからないポインタずっと内包し続けるとか
どの辺に設計の美学があるのか聞きたいw
そんなに下手糞なら引数で渡せよ

>>209
>私には、「自機クラス移動したら敵クラスも必要になっちゃうし」の意味がわからないんだよね。
仮に別のプロジェクトに自機クラスを移動するとしよう
そうするとさ自機クラスは敵クラスがなくても動ける仕様であるにもかかわらず
自機クラスをもってくるには敵クラスが必要になっちゃうんだよね

別に移動なんてしねーよと思うかもしれないけどこれが重要で
これってのは敵クラスを変更したときに自機クラスも影響を受けることを意味してるんだよね

だから自分の必要な処理「だけ」を内側に内包するためのカプセル化なんだよ
それにつながるのは他のクラスの変更に強いクラスにするためだ
だけど、タスクシステムを使うと色んなクラスに根っこを生やすことになる
一つクラスを直したら影響範囲すごく大きくなってしまう

298 :名前は開発中のものです。:2009/08/26(水) 22:22:50 ID:L5twc2Wr
>>285
> 敵タスクを生成するのが、敵タスクだとは限らない(全然別のタスクの可能性だってある)ので、

タスクシステムってそういうものなの?
俺が考えてたのはそれとは違った。そもそも各タスクが他のタスクを生成などしない。
互いに型を知り合ったりはしない。パラメータとして与えられるレベルの型のみを知ってる。
GoFのMediatorを解してのみやりとりすることになる。多対多ではなく、一対多の関係。
タスクシステムってのは相互にグイグイ食い込んで作るものなの?

> あと、EnemyTaskを〜はおかしい。

そもそもそんな心配など無い。

> 今回のケースだって、事前にqueryは予測できないよ。

クエリじゃない、フィールドの公開程度のこと。
いくつものテーブルからandで引っ張ったり、
グループ分けして集計したり、サブクエリを結合したりなどしない。

少なくとも敵タスクを列挙したいというのは、
設計段階で分ることであって、実行時のことではない。

> 仮にその仮定ができたとしても〜記憶容積を無駄にしているだけ。

容量はそりゃ効果に見合うか次第。速度は…そもそもlistを使いたい。

299 :名前は開発中のものです。:2009/08/26(水) 22:26:28 ID:L5twc2Wr
>>297
流れは読んでないし、完全に横レススマソ状態ですが、

> だから自分の必要な処理「だけ」を内側に内包するためのカプセル化なんだよ

この一文はなんかキラッと輝いてる。
タスクシステムのなんかモヤッとした印象を、
颯爽と振り払う清清しい突風のように見える。

何言ってんだ俺。酒のンでます。

300 :名前は開発中のものです。:2009/08/26(水) 22:50:58 ID:4R/gisA+
コンパイル時に実行されてただの一連の関数呼び出しになるコンパイル時クエリとか夢が広がりますね

301 :名前は開発中のものです。:2009/08/26(水) 23:17:12 ID:L5twc2Wr
タスクシステムとは、OOPLでオブジェクト郡を操作する場合、
もはやシステムとやらでもなんでもなく、
基底クラスへのポインタリスト、という変数に成り下がってしまう。

…って考えは間違いなのかな。
やっぱり、あるタスクが他のタスクを知ってるとか、
タスクの生成や保持、生存期間について一箇所で管理するんじゃなく、
あくまでバラバラに頑張り、あとは尻拭いも頑張る、というものなのかな。

302 :名前は開発中のものです。:2009/08/27(木) 04:13:51 ID:YflT6adj
>>296
王様
トリップも変え被害妄想風になってネカフェから書き込みですか?

すばらしい、すばらしい技術の持ち主ですね

ぜひとも今後のタスクシステムの有効性について語っていただきたい

303 :new tasksystem ◆9ycqcAuWxdGZ :2009/08/27(木) 04:58:00 ID:T5IyzsGb
>>290
> boost知ってるってことは少なくともLinux系はいじったことあるはずで・・・
> そんなの何年前かも分からない状況で・・・

boostを何だかミラクルなものだとでも思っているのか知らないが
C++使いなら多少使って当たり前なんだがな。あんたはどんだけ素人プログラマなんだ。


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

意味がわからない。

その手の迷路は、例えば、
通れる場所を 0 , 通れない場所を 1として2次元配列で持っておくだけだが、
そういう意味ではないのか?

それとも、上のような迷路を自動生成するという話か?

何度でも言うが、あんたの日本語、意味不明なんだ。
日本語がきちんと使えるようになってから出直してきて欲しい。


304 :new tasksystem ◆9ycqcAuWxdGZ :2009/08/27(木) 05:00:38 ID:T5IyzsGb
>>291
> 正直、想定の範囲外だし、いっぺん作ってみないと想像できん。

話が噛み合ってないので、じゃあ、この話はいったん終了。


>>index?=?((byte*)ptr?-?(byte*)&array[0])?/?sizeof(T); 云々
>これは同じ型が入っていないとまずいんじゃないの?

うん。型ごとにpoolerを持っていると仮定。

>>292
>>いま気づいたが、このMemoryPool、馬鹿ほどメモリを消費して、OSのswapが生じてるんじゃないのか。?
> キャストで領域を割り当ててるからなんじゃないの?

キャストして領域を割り当てるのは何の問題もない。
replacement newについて勉強しとくれ。


305 :new tasksystem ◆9ycqcAuWxdGZ :2009/08/27(木) 05:02:14 ID:T5IyzsGb
>>296
HSP君、久しぶり。
よかったら、私のタスクシステムについて、感想、聞かせとくれ。


306 :new tasksystem ◆9ycqcAuWxdGZ :2009/08/27(木) 05:07:01 ID:T5IyzsGb
>>297
> 意味があるのかないのかわからないポインタずっと内包し続けるとか
> どの辺に設計の美学があるのか聞きたいw
> そんなに下手糞なら引数で渡せよ

ホーミング弾が自機のポインタを内包する話か?
ホーミング弾なのだから、updateのごとに自機の座標が必要に
なるわけで、ホーミング弾が自機のポインタを内包しているのは
おかしくないし無駄でもないと思うがな。

「引数で渡せよ」で思い出したのだが、あんた、引数君か?

ホーミング弾に自機の座標を引数で渡すという話か?
それはどのクラスが?

まさか、
int x,y;
jiki.getPosition(&x,&y);
homing.setJikiPosition(x,y);
こういうことか?

こうするためには、この呼び出しをしている部分では、
自機クラスとホーミングクラスと両方にアクセスできる
ことになるが、シーンクラスのようなものがあると仮定しているのか?


307 :new tasksystem ◆9ycqcAuWxdGZ :2009/08/27(木) 05:17:25 ID:T5IyzsGb
>>297
>>私には、「自機クラス移動したら敵クラスも必要になっちゃうし」の意味がわからないんだよね。
> 仮に別のプロジェクトに自機クラスを移動するとしよう

ああ、意味わかったよ。「移動」っていうのは座標ではなく、
ソースレベルでの移動なんだな。そう書いてくれれば、すぐにわかったんだが。


> そうするとさ自機クラスは敵クラスがなくても動ける仕様であるにもかかわらず
> 自機クラスをもってくるには敵クラスが必要になっちゃうんだよね

うん、それはそうだ。

だから、そういうケースにおいて、ホーミングと自機クラスとの結合度を
下げたほうが良いケースがあるというのは、わかるよ。

特定のゲームの開発だから、結合度を多少犠牲にしてでもソース短く
書いたほうがいい場合と、あんたが指摘しているように、結合度をなるべく弱くして、
それぞれのクラスにコンポーネント性を持たせたほうが良い場合とある。

まあ、おおむね私はそれに対しては反論はないよ。
そのへんはケースバイケースということで。


308 :new tasksystem ◆9ycqcAuWxdGZ :2009/08/27(木) 05:27:40 ID:T5IyzsGb
>>297
ただし、引数として渡すのは、>>305のようなソースになるから、
これは、あまりスマートでもないような気がするな。

ホーミングのコンポーネント性を高めるために、自機クラスへの
ポインタをホーミングクラスから外に追い出したのに、こうやって
毎フレームどこかで、自機クラスから座標を取得して、それを
ホーミングに対して設定してやらなければならないのでは、
コンポーネント性が落ちている気がする。

ホーミングのソースと自機のソースを別プロジェクトに持って
行っただけでは機能せず、それを結びつけるglue codeが毎回必要になる。

ホーミングは、結局、自機クラスの座標は必要なのだから、何らかの
形で自機クラスの座標を取得しなくてはならないので、glue codeは
必須には違いないけど、毎フレーム処理する部分のコードがふくれあがると
見通しが悪くなるからbuilderで(要するにオブジェクト生成時に)
bindしてしまうほうが毎フレーム処理する部分は膨れあがらなくて
済むとは思う。(スマートでもないかも知れないが)


309 :名前は開発中のものです。:2009/08/27(木) 05:27:49 ID:YflT6adj
>>303
王様 迷路をタスクシステムで実装して欲しいのです
底辺のプログラマである私では王様のタスクシステムを使って
どのようにすればよいのか かいもく検討もつきません

意味がおわかりいただけないなら
ぜひ どのようにして迷路ゲームをタスクシステムを使われて実装されるのでしょうか?

310 :new tasksystem ◆9ycqcAuWxdGZ :2009/08/27(木) 05:40:41 ID:T5IyzsGb
>>298
> 俺が考えてたのはそれとは違った。そもそも各タスクが他のタスクを生成などしない。
> 互いに型を知り合ったりはしない。

ええと、シューティングでボスキャラがザコを生成したいときに、
ボスキャラのコードで、
 taskSystem->AddTask(ZakoClass);
のようにタスクシステムに依頼して生成する。
(ようなタスクシステムを私は想定している)

あんたの想定するタスクシステムでは、ボスキャラがザコを生成したいときに
どういうコードを書くんだ?

311 :new tasksystem ◆9ycqcAuWxdGZ :2009/08/27(木) 05:44:08 ID:T5IyzsGb
>>298
> 少なくとも敵タスクを列挙したいというのは、
> 設計段階で分ることであって、実行時のことではない。

いや、敵タスクを列挙したいのは誰かってこと。
例えば、ボスキャラがザコだけ列挙したいということになった。

そしたら、あんたのケースだと、ザコの生成と解体を捕らえて
listに突っ込む必要が出てくるだろ?

現場レベルで言えば、
ボスキャラの設計をしている人間と
ザコキャラの設計をしている人間とは違うことだってあるわけで、
ボスキャラの実装によって、ザコキャラの実装変更が生じるのは
許し難いんだ。

> 速度は…そもそもlistを使いたい。

ん?std::list?

std::listはremoveはマシだけど、traverseはstd::vectorより
桁違いに遅いよ。本当にコード書いて測定してみた?



312 :new tasksystem ◆9ycqcAuWxdGZ :2009/08/27(木) 05:49:29 ID:T5IyzsGb
>>302
> >>296
> 王様
> トリップも変え被害妄想風になってネカフェから書き込みですか?

え?>>296のHSPerは、このスレのpart5から居るじゃん。

HSP君は、HSP君で、また変わった人だとは思うけども。

■ HSP君の特徴

・HSPがメインの言語(釣りかどうかは知らん)
・C/C++はほとんど使わない(使えない?)
・そのわりには結構設計面などに関しては的確な指摘が来る


313 :new tasksystem ◆9ycqcAuWxdGZ :2009/08/27(木) 05:51:46 ID:T5IyzsGb
>>301
> タスクシステムとは、OOPLでオブジェクト郡を操作する場合、

前から気になっていたんだが、

×郡
○群

だ。typoではないようなので指摘しておく。


314 :new tasksystem ◆9ycqcAuWxdGZ :2009/08/27(木) 05:59:00 ID:T5IyzsGb
>>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に内包させずに、
別のタスクとして扱っても良いが。

まあ、この程度なら、タスクシステムを使うメリットはほとんどないよね。
もっとキャラクターの生成/解体が激しく行なわれるタイプのゲームでないと。


315 :名前は開発中のものです。:2009/08/27(木) 06:09:45 ID:YflT6adj
>>314
王様 つたない日本語でもうしわけありません

王様質問なのですが
maze[MAZA_WIDTH][MAZE_HEIGHT];
に爆弾がしかけられるようにするにはどのように実装すればよろしいでしょうか?

316 :new tasksystem ◆9ycqcAuWxdGZ :2009/08/27(木) 06:16:12 ID:T5IyzsGb
■ 引数君とactorについて

このスレのpart3,4あたりで引数君というのが居て、彼は

> update();
> で動くのと
> update(jiki,teki,tama,unko);
> で動くのとじゃ
> プログラムとしては絶対に下のがいい

なんてことを言って、タスクシステム派からキチガイ扱いされていたわけだが、
案外、彼が言いたかったのは、>>306-308みたいなことだったのかなぁ。

だとしたら、周りに全く伝わっていなかったというか、なんだか
考えたら気の毒になってきた。

それで、「タスク = actorじゃん。お前ら、actorは許せて、タスクシステムは
許せねーの?」というタスクシステム派がいたが、私はそれはちょっと違うと思う。

actorは普通、他のactorのポインタなどを持ったりしない。

ホーミングactorが自機の座標を欲しければ、自機の座標を外部から設定してもらう。
要するに >>306 のようになる。

まあ、これでもいいのだけど、actor間の直接的なデータのやりとりもしてみたい。
(つづく)


317 :new tasksystem ◆9ycqcAuWxdGZ :2009/08/27(木) 06:19:31 ID:T5IyzsGb
>>315
> maze[MAZA_WIDTH][MAZE_HEIGHT];
> に爆弾がしかけられるようにするにはどのように実装すればよろしいでしょうか?

属性として、通路と壁と爆弾の三種類があるってこと?

enum MazeChip
{
 Blank, // 通路
 Wall, // 壁
 Bomb, // 爆弾
};

んで、MazeMapを次のように変更。
 MazeChip maze[MAZE_WIDTH][MAZE_HEIGHT];

これで爆弾も配置できるようになった。

ところで、これはどこかの学校の宿題なのか?

318 :名前は開発中のものです。:2009/08/27(木) 06:28:30 ID:YflT6adj
>>317
王様 もうひとつ質問よろしいでしょうか?

maze には魔法がかかっててあるキーワードを入れないと
そのmazeには入れないようにしたいのですが
どのように拡張されたらよいでしょうか?

そこらへんにころがっている問題の一部です
王様なら簡単に解けるだろうと思い提言したまでです

319 :new tasksystem ◆9ycqcAuWxdGZ :2009/08/27(木) 06:32:29 ID:T5IyzsGb
>>316 のつづき

■ actor間のデータ通信について

actor間でデータをやりとりしたい。

例えば、ホーミング弾actorに自機actorの座標を渡したい。

自機actorを
class Jiki : public ITask,public Position
{

のように多重継承しといて、Jiki actorをPositionにupcastして
ホーミングactorに渡しておくなら、ホーミング弾actorは、
Jikiクラスのインターフェースを知る必要はなく、単に
Positionクラスだけ知っていれば事足りるので、結合度はやや低くなる。

しかし、それでも自機クラス設計時に、Positionクラスから派生されるかどうかの
判断は、ホーミング弾クラスを設計するまでわからないので、こういう設計の仕方は
避けたい。

そこで、シーンクラスみたいなものを作って、そこで>>306みたいなコードを書くことに
なるのだけど、自機の座標を必要とするのがホーミング弾クラスだけとは限らず、
また、ホーミング弾もひとつとは限らず、動的に生成されたり、あとから生成されたものが
増えるごとにシーンクラスを書き換えるのはとても嫌だ。

なぜなら、分業で作っていると、ホーミング弾クラスのようなものは何人ものプログラマが
作っていて、シーンクラスを書いているプログラマは一人で、新しく自機を狙う敵キャラを
追加するごとにシーンプログラマの書いているソースコードをいじらなくてはならないのでは
シーンプログラマは自分のソースコードの正しさを検証しきれないからである。
(つづく)

320 :new tasksystem ◆9ycqcAuWxdGZ :2009/08/27(木) 06:38:10 ID:T5IyzsGb
>>318
> maze には魔法がかかっててあるキーワードを入れないと
> そのmazeには入れないようにしたいのですが
> どのように拡張されたらよいでしょうか?

「mazeに入れない」の意味がわからない。

mazeの外に他のmazeがあるのか?
どこからmazeに入るという話?

maze自体はシーンクラスが内包しているのだから、
他のシーンから移ってくるなら、前に居たシーンクラスを
解体して、新たにMazeScene (>>314) をタスクシステムに
生成してもらえば良いだけだが。

MazeSceneシーンへ遷移するかのチェックは、前のシーンが
行なうわけだから、そのシーンで「あるキーワードを入れた」かどうかの
判定をすればいい。

321 :名前は開発中のものです。:2009/08/27(木) 06:38:48 ID:qnsGldOf
>>316
何をスマートといってるの?
タスクシステムで作ったらグローバル変数にして渡すしかないんだろお前
宙ぶらりんのポインタ保持とか確実にアウトな実装方法しかお前しらねーじゃねーかよ

引数で渡すことやめたら確実にこの問題にぶち当たるんだよ
ホーミングに毎回値を渡すのが面倒とかいってるけど
実装上それが必要なのになんでそれをわずらわしいと思うの?
逆に聞くけどそれが渡せないプログラムって存在しないだろ
渡すようなプログラムだとなにかまずいことおきるの?
なんで必要な処理にも関わらず省略しようとするの?

お前のプログラムを初めて見る人間がホーミングでターゲット設定してる箇所調べるには
どこみたらいいの?
ホーミングと対象物の関連を探すんじゃねぇのかよ
切り離してグローバル変数迂回してアクセスしてたらてめぇに聞かなきゃ発見できねぇだろ

322 :名前は開発中のものです。:2009/08/27(木) 06:40:28 ID:5F7LPvpQ
情報の小出しでの質問とか嫌がらせ以外の何でもないな

323 :名前は開発中のものです。:2009/08/27(木) 06:42:15 ID:qnsGldOf
>>322
なにか前提がかわって不都合が起きたら遠慮なく言えよ

324 :new tasksystem ◆9ycqcAuWxdGZ :2009/08/27(木) 06:43:35 ID:T5IyzsGb
>>321
> タスクシステムで作ったらグローバル変数にして渡すしかないんだろお前

私のコードにstatic変数もグローバル変数もひとつもないよ。

> ホーミングに毎回値を渡すのが面倒とかいってるけど
> 実装上それが必要なのになんでそれをわずらわしいと思うの?

毎フレーム何らかの手段で取得する必要はある。

だけど、それをシーンクラスが行なう必要はない。
このデータのやりとりはもっと抽象化できる。

325 :new tasksystem ◆9ycqcAuWxdGZ :2009/08/27(木) 06:48:58 ID:T5IyzsGb
>>321
> ホーミングに毎回値を渡すのが面倒とかいってるけど
> 実装上それが必要なのになんでそれをわずらわしいと思うの?

わずらわしいのではない。>>319の最後の段落のような問題が発生するのが嫌なんだ。

326 :名前は開発中のものです。:2009/08/27(木) 06:49:41 ID:YflT6adj
>>320
ご自分でmazeと定義なされていらっしゃいますが

具体的に申し上げますと
maze[0][0] から maze[0][1] に移動する場合
どのようなコードになられるのでしょうか?

327 :new tasksystem ◆9ycqcAuWxdGZ :2009/08/27(木) 07:01:51 ID:T5IyzsGb
>>326
> ご自分でmazeと定義なされていらっしゃいますが

私は、mazeと"定義"はしてないよ。
> MazeChip maze[MAZE_WIDTH][MAZE_HEIGHT];
これ、宣言だろ。しかも配列の要素の型はMazeChip。

> 具体的に申し上げますと
> maze[0][0] から maze[0][1] に移動する場合
> どのようなコードになられるのでしょうか?

だから、それなら、>>318は、
MazeChipからMazeChipに移動するときに、
「キーワードを入れないと移動できない」
と書くべきだろ。なんで変数名で書くんだよ。

なんかあんたの日本語は読むのに疲れる。

いい加減疲れてきた。あと何回質問があるんだ?
あんたの宿題に付き合わされるのは、そろそろ御免被りたい。


328 :名前は開発中のものです。:2009/08/27(木) 07:07:42 ID:qnsGldOf
>>325
しないよ
タスクシステムにわざわざのっかってやらなきゃいけないほうが嫌だよ
ホーミングと対象物とやりとりするにもなにか特殊な手続きがいるようになるんだろ?

329 :new tasksystem ◆9ycqcAuWxdGZ :2009/08/27(木) 07:08:31 ID:T5IyzsGb
>>322
> 情報の小出しでの質問とか嫌がらせ以外の何でもないな

私のことかな?それともID:YflT6adjのことかな?

まあ、仮に私のことだとして、
私は長文で投稿したいんだが、ここは長さ制限があるので10行ぐらいずつしか投稿できないんだわ。

きっちりまとめてCodeZineにでも投稿したほうがいいか?

それならそうするが。

330 :名前は開発中のものです。:2009/08/27(木) 07:12:25 ID:YflT6adj
>>327
え?

struct MazeMap
{
 bool maze[MAZE_WIDTH][MAZE_HEIGHT];
// その他、初期化、読み込み、自動生成、etc..のmethodを追加すべし。
};

class MazeScene : public ITask
{
 MazeMap map; // 迷路
 MyChara myChara; // 主人公

 virtual void update(Context& context); // 描画用
};

と定義?宣言されてますが・・・

私の宿題につきあうのではなく、あなたの主張するタスクシステムは有用だ
ということをおうかがいいたしてるのですが

331 :new tasksystem ◆9ycqcAuWxdGZ :2009/08/27(木) 07:16:43 ID:T5IyzsGb
>>328
> しないよ

ん?それは何故?

状況をもう少し正確に以下に書いてみるよ。

・シューティングなので自機を狙う敵や自機の座標を必要とする敵はたくさんいる。
・それぞれの敵を何人かで分業して実装させる
・自機を狙う敵を追加するごとに、>>306のようなコードがシーンクラスに必要になる
・シューティングなので敵は動的に生成され、動的に解体される。
・シーンクラスを設計している人が、そのシーンでどの敵が出現するのかまで関与したくない。
 敵の生成は、スクロールマップ(画面の地形スクロールがどこまで進んだか)によって自動的に決定される。

こうなっているときに、それぞれの自機を狙う敵を追加するごとに、シーンクラスに>>306のような
コードを追加することになると思うのだけど、そうではない?

タスクシステムを使わずに実装する話なのか、それともタスクシステムを使うが>>306のようなコードは
書かないという話なのか、それとも、タスクシステムを使って>>306のようなコードも書くが、だけど問題ないと
言うのかどれ?

> タスクシステムにわざわざのっかってやらなきゃいけないほうが嫌だよ

タスクシステムに乗っかる必要はないよ。タスクシステムとは無縁の抽象化されたデータ通信手段を用意する。

332 :new tasksystem ◆9ycqcAuWxdGZ :2009/08/27(木) 07:22:20 ID:T5IyzsGb
>>330

私は >>317
> んで、MazeMapを次のように変更。
>  MazeChip maze[MAZE_WIDTH][MAZE_HEIGHT];

と書いてあるので、その全体ソースはおかしい。>>317を見落としてないかい?


333 :名前は開発中のものです。:2009/08/27(木) 07:26:55 ID:/N8rqxow
>>331
なんの問題があるんだ

334 :new tasksystem ◆9ycqcAuWxdGZ :2009/08/27(木) 07:30:27 ID:T5IyzsGb
>>333
>>325で書いている「>>319の最後の段落のような」問題。

335 :名前は開発中のものです。:2009/08/27(木) 07:34:33 ID:/N8rqxow
何度も言うけど書かなきゃいけない処理まで省略しようとするのはなんでなの?
誰かに脅されてるの?
同じなら同じ処理書いておけばいいじゃん
その方がソース見る側安心できるだろ
逆にあるはずの処理があるはずのところにない方が面倒くさいだろ

336 :名前は開発中のものです。:2009/08/27(木) 07:36:49 ID:YflT6adj
よく理解できませんが
enum MazeChip
{
とあるので、この共用体は迷路の一部分とみなしてよろしいでしょうか?
そして、MazeChip maze[MAZE_WIDTH][MAZE_HEIGHT];
これで、迷路全体を現していると解釈してよろしいでしょうか?

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

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

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

337 :new tasksystem ◆9ycqcAuWxdGZ :2009/08/27(木) 07:37:51 ID:T5IyzsGb
>>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に手を加えればいい。

338 :new tasksystem ◆9ycqcAuWxdGZ :2009/08/27(木) 07:42:42 ID:T5IyzsGb
>>335
> 何度も言うけど書かなきゃいけない処理まで省略しようとするのはなんでなの?

私は「省略」しようだなんてひとことも言っていない。
「どこかに書かなくてはならない」

それは何度も言ってるだろ?
しかし書くところがおかしい、と言っているんだ。

まあ、議論の前提が違うのかも知れん。あんたがタスクシステムを使う派なのか使わない派なのか
すら教えてくれないので私としては答えようがない。

簡単に言えば、
シーンクラスはホーミング弾クラスを作っている奴は、書き換えられないんだ。
ということ。

だから、>>337のような解決案なら、私は賛成なわけだ。

339 :new tasksystem ◆9ycqcAuWxdGZ :2009/08/27(木) 07:48:27 ID:T5IyzsGb
>>336
私へのレスならアンカーを入れてとくれ。
あとで追いかけられなくなる。>>332へのレスだよね。

> よく理解できませんが
> enum MazeChip
> {
> とあるので、この共用体は迷路の一部分とみなしてよろしいでしょうか?

迷路の床、1つ分のチップの種類を定義してある。
これは迷路で使われる床の種類を定義しただけであって、
それ自体は迷路の一部じゃない。

> そして、MazeChip maze[MAZE_WIDTH][MAZE_HEIGHT];
> これで、迷路全体を現していると解釈してよろしいでしょうか?

迷路の床全体は、これ。

struct MazeMap
{
 MazeChip maze[MAZE_WIDTH][MAZE_HEIGHT];
 // その他、初期化、読み込み、自動生成、etc..のmethodを追加すべし。
};

このうち、迷路の床を表現しているのが、

> MazeChip maze[MAZE_WIDTH][MAZE_HEIGHT];
これ。

ここまではいいか?

340 :名前は開発中のものです。:2009/08/27(木) 07:50:48 ID:/N8rqxow
>>337
自機が死んだり、ターゲットを切り替えたときの処理はどこを見て書いたらいいの?
ちょっとしたことで全部お前のオレオレ仕様にお伺い立てなきゃいけないんだな

341 :名前は開発中のものです。:2009/08/27(木) 08:00:12 ID:YflT6adj
>>339
>ここまではいいか?
なんとか理解できたよ
王様は日本語は達者ですが、英語のソースはあまり得意とはいえませんね

342 :new tasksystem ◆9ycqcAuWxdGZ :2009/08/27(木) 08:05:42 ID:T5IyzsGb
>>340
> 自機が死んだり、ターゲットを切り替えたときの処理はどこを見て書いたらいいの?

自機が死んだかの判定はfactoryに書くよ。
具体的には createHoming(>>337)のなか。

自機が死んでいるかどうかは、factoryのなかならチェックできるから、
自機が死んでいれば、positionとしてnullを返しておけばいいだろう。

ターゲット切り替えというのは、何かの条件をトリガーとして、
プレイヤ2(二人プレイだとして)を狙うとかそういうこと?

そういう場合は、
Position delegate getPosition(int player);
こういうdelegateにするね。

> ちょっとしたことで全部お前のオレオレ仕様にお伺い立てなきゃいけないんだな

Homingのfactoryを書くのは、Homingクラスの制作者だから、
好きなように書けると思うが?

上のターゲット切り替えにしても、Homingクラスと、そのfactoryしか
いじってないから、Homingクラスの制作者の自由に変更できる。


343 :名前は開発中のものです。:2009/08/27(木) 08:11:31 ID:YflT6adj
>>339

>迷路の床、1つ分のチップの種類を定義してある。
>これは迷路で使われる床の種類を定義しただけであって、
>それ自体は迷路の一部じゃない。

すいません 上記の部分 床の種類を定義されてるようですが
爆弾は床ではないですよね?

ここの部分が理解できません

344 :new tasksystem ◆9ycqcAuWxdGZ :2009/08/27(木) 08:12:27 ID:T5IyzsGb
>>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の場合も書くべし。
 }
}


345 :new tasksystem ◆9ycqcAuWxdGZ :2009/08/27(木) 08:23:00 ID:T5IyzsGb
>>343
> すいません 上記の部分 床の種類を定義されてるようですが
> 爆弾は床ではないですよね?
> ここの部分が理解できません

うへ。そんな突っ込みが来るとは夢にも思わんかった。
あんた、なかなか面白いな。

それはともかく、「爆弾」は「床」ではないのはもちろんのこと、
厳密に言えば、「壁」にしても「床」じゃないしな。

こういうのを、ゲームの現場で「床」チップと呼ぶことが
多いんだけど(うちだけか?)、なんでそういうものを
「床」と呼ぶかと言うと、昔のゲームは2Dで平面的だったから、
その上に何がおかれていても床っぽかったからじゃないかな。

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

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

346 :new tasksystem ◆9ycqcAuWxdGZ :2009/08/27(木) 08:37:30 ID:T5IyzsGb
今日は出かけるのでこのへんで。

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

347 :名前は開発中のものです。:2009/08/27(木) 08:48:43 ID:Uy4EMmxI
もうこいつはID:YflT6adj無視しろよ
どう見ても基地外だろ

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

348 :名前は開発中のものです。:2009/08/27(木) 09:19:46 ID:YflT6adj
>>345
たしかにタスクシステムを使うメリットはあまり見えてこないね

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

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

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

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

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

349 :名前は開発中のものです。:2009/08/27(木) 09:34:17 ID:YflT6adj
事業内容 情報処理業
職 種 SE&プログラマ
雇用形態 正社員
産 業 情報通信業のうち情報処理・提供サービス業
賃 金月給制 250,000円〜 600,000円

必要な経験等 Java及びC#の経験者/オブジェクト指向での設計が出来る方
          経験3年以上

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

多分君らは月給10〜15万くらいでこきつかわれてるんだろうけどねw

350 :名前は開発中のものです。:2009/08/27(木) 09:53:16 ID:YflT6adj
お金の話してサーセンw

キチガイ以下

351 :名前は開発中のものです。:2009/08/27(木) 10:21:18 ID:5F7LPvpQ
>>348
タスクかどうか知らんけど別の考え方すれば
爆弾 has 部屋、さらに一般化して役者 has 属性 になるんじゃね
役者に識別子があるとすれば、役者は識別子から属性への関数みたいに定義できるな
俺もその方針でちょっと考えてみるか

352 :名前は開発中のものです。:2009/08/27(木) 10:21:38 ID:9InHv7UR
>>310
> あんたの想定するタスクシステムでは、ボスキャラがザコを生成したいときに
> どういうコードを書くんだ?

ボスはザコを生成しない、列挙もしない。
ボスを生成した側のオブジェクトが、ザコもコントロールする。

具体的なボスやザコの型を知る、ボスシーンオブジェクトを更新させ、
その中でボスとザコとの破棄生成や協調動作の関係を記述する。

タスクは、AbstractTask *として全部に共通する、描画やらなんやら、
それをまんべんなく実行させるために、alltasksリストに入れて使う。
ボスザコの協調動作に必要なリストがあれば、ボスシーンオブジェクトは、
自分のために内部にそれを必要なだけすきな表現で準備する。

>>276で示したような登録すたいるはアドホックすぎるので、
可能であればそうでもいいし、ムリにあれを貫く必要などはない。
やはり、使用される文脈を想定すべきではないので、よくないね。

>>311
> ボスキャラの実装によって、ザコキャラの実装変更が生じるのは

生じない。>>276方式では、生じるw

> 桁違いに遅いよ。本当にコード書いて測定してみた?

桁違いには遅くない。というか、traverseってのが何なのか知りません。
vectorの生成、参照、削除は0,0,5922。listは78,0,31。
単位はミリセカンド。ループ100000回の<int>で。

>>313
ありがとう。その二つを区別できてなかったw

353 :名前は開発中のものです。:2009/08/27(木) 10:32:55 ID:eJpYgGpz
>>352
横からだが、traverseって山とか登ることだ。ここでは、listを辿っていくこと。
あんたが中学生なのか小学生なのかは知らないが、辞書ぐらい引いたらどうだ。

あと、10万回ループなんか書いて測定しても、それはすべてL1に載っているわけで
差が出なくて当たり前だろ。

辞書も引かないし、測定の仕方もド素人。全然話にならないレベルだぞ。
◆9ycqcAuWxdGZとあんたとではレベルが違いすぎる。

もう少しまともなプログラマに◆9ycqcAuWxdGZへタスクシステムの意義とかに
ついて質問とかして欲しいな。

354 :名前は開発中のものです。:2009/08/27(木) 10:41:09 ID:9InHv7UR
>>353
辞書は一応引いたよ。そうです、中学生でつ。
「vectorの生成」は間違いで「vectorへの追加」です。

リストってのは、追加した後は順に辿ればよくって、
インデックスで指定してまばらに辿るものではない。
そういう用途だからってのが、リストを選ぶ一つの理由になってる。

> あと、10万回ループなんか書いて測定しても、

ループで使うってのは狙い通りだと思うだけど、
どうすればよかったのかな?

355 :名前は開発中のものです。:2009/08/27(木) 10:49:56 ID:YflT6adj
>>351
>爆弾 has 部屋
不可能ではないかもしれんが難しいかもしれんし、複雑怪奇なコードになるかもよ?

部屋 has 爆弾 でもいけるし


部屋 is 爆発 にすれば、これでも爆発する部屋ができる
class Bombroom : public room;


まぁ、こういう多様な考えが構造体世代には理解できんのだろう

356 :名前は開発中のものです。:2009/08/27(木) 10:51:07 ID:eJpYgGpz
>>354
本当に中学生なのか。そりゃ内容が支離滅裂でも仕方ないな。

横から見てると、あんたの相手をさせられている◆9ycqcAuWxdGZが
幼稚園児の相手をしているプロボクサーみたいな感じで
不憫に思えたのでレスさせてもらった。

> そういう用途だからってのが、リストを選ぶ一つの理由になってる。

CPU cacheに対するアクセス速度とか、new/deleteするオーバーヘッドの
大きさとかまったく考慮に入ってなさそうだな。正直、論外だよ。

タスクシステムなんかより先に、コンピュータアーキテクチャの
勉強してきたほうがいいんじゃないの。

中学生ならまだ伸びしろも大きいんだろうし。

357 :名前は開発中のものです。:2009/08/27(木) 10:53:26 ID:9InHv7UR
>>356
> new/deleteするオーバーヘッドの大きさ

リストとベクタの比較において、なにをnew/delete?

358 :名前は開発中のものです。:2009/08/27(木) 11:21:15 ID:vJUq9zzb
>>356
>本当に中学生なのか。そりゃ内容が支離滅裂でも仕方ないな。
あんた、相手が中学生だからと言って言っていいことと悪いことがあるもんだけど、
その区別はちゃんとついているのかい?

359 :名前は開発中のものです。:2009/08/27(木) 11:31:30 ID:eJpYgGpz
>>357
> リストとベクタの比較において、なにをnew/delete?

君の手元にあるSTLの実装では、list/vectorに対して
100回続けて要素の追加を行ない、100回続けて削除を行なった場合、
list/vectorでそれぞれ何バイトの構造体が何回new/deleteされるように
なっているかな?

重箱の隅をつつくような意地悪な質問に思えるかも知れないが、
これはとても基本的なことなんだ。

ここがわかっていないのに、listとvectorでどちらが最適なデータ構造か
だなんて考えられるわけがないのだから。

360 :名前は開発中のものです。:2009/08/27(木) 11:37:45 ID:eJpYgGpz
>>358
いや、俺は彼が本当に中学生とは思っとらんよ。
中学生にしては、ボキャブラリが多すぎるだろう。352とかよく読んでみなよ。

中学生だというのは、本人の「おとげ」「自己軽蔑」の表れなんじゃないかと
思ったので、あえて煽らせてもらった。

本当に中学生なのだとしたら、まあ、将来が楽しみだな。
いまのうちに基礎をきちんと身につけてちょーだいな。> 中学生

361 :名前は開発中のものです。:2009/08/27(木) 12:38:29 ID:XooKz1f6
347 は人格攻撃しか書いてないし単発IDなのに構造体で思考停止している奴、
後で構造体世代と言い替えているが、とわかるはずがない。
後でつっこまれたときに逃げるための布石としてレッテルを用意したんだな。

>>347
ID:YflT6adj はかなり頭良い奴だ。
少ない手間でいかに相手を馬鹿にして追い詰めるかに長けてる。
相手をしたが最後、疲れ果てるまで粘着されるだろう。

362 :名前は開発中のものです。:2009/08/27(木) 15:24:04 ID:YflT6adj
>>347
ではお聞きしますが
なぜ私がキチガイなのですか?
説明していただけますか?

>>361
キチガイと言われてますがw
たいてい私をキチガイ扱いする奴は構造体で動くからいいや思考ばかりなんで
もうお決まりのパターンなんですよ
ヲタクがキモイのと一緒で
馬鹿にしてるというか東京で一日で鍛えられた技術ですよ?

363 :名前は開発中のものです。:2009/08/27(木) 16:49:45 ID:YflT6adj
床屋逝ってきた
「バリカンでそるかね?」と聞かれ
「バルカンで」と答えてしまったw

スパロボ自重すっかなw

364 :名前は開発中のものです。:2009/08/27(木) 18:41:22 ID:c20hgJ/h
風向きが悪くなると馬鹿のふりをしてごまかそうとするのも常套手段。
そうやって隙をうかがっているから油断するな。

365 :名前は開発中のものです。:2009/08/27(木) 19:18:30 ID:YflT6adj
何も言わずにただ否定するだけ
消えろ お前の仕事は幼稚園児に変わってもらう

366 :名前は開発中のものです。:2009/08/27(木) 19:20:13 ID:YflT6adj
ああ、ただの人間不信か
病院逝け な?

367 :名前は開発中のものです。:2009/08/27(木) 23:50:18 ID:Eglbfyil
耐性なさすぎワロタ
オレモナー

368 :名前は開発中のものです。:2009/08/28(金) 00:51:54 ID:JOs9e0dZ
ID:YflT6adj みたいなのが
>>206
のいう白痴のふりというやつだな。

そこまでして勝てない戦いを続けるのは何でなんだろうなぁ…

369 :名前は開発中のものです。:2009/08/28(金) 03:28:51 ID:oKgBCCXA
普通タスクシステムではvectorよりもlistを使わないか

370 :名前は開発中のものです。:2009/08/28(金) 08:37:00 ID:zvcdpOKo
普通は自前の連結リストを使うんじゃない?

371 :名前は開発中のものです。:2009/08/28(金) 23:24:40 ID:SRsFs6JN
親子間の巡回順のみが重要な場合はtreeにしたりする。

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

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

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

375 :100:2009/08/29(土) 01:09:58 ID:yvNElBEe
ID:YcewJeTt(new tasksystem ◆9ycqcAuWxdGZ)は
やねうらおレベルの高度な知的生命体だからどうでもいいとして

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

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

>>765
>>タスクシステム自体もタスク間でのコミュニケーションが苦手という問題を抱えてるが

>なにそれ怖い。そのチンカスタスクシステム固有の問題、具体的に書いてみ?

答えなさい

376 :名前は開発中のものです。:2009/08/29(土) 01:16:41 ID:39tdLmSm
お前のタスクシステムはタスクシステムじゃねぇからしらねぇよ。
トラバース→バッファリング→最適化→実行
よりも、>>117の方が素直だと思うんだけどどうよ。
型と処理オーダーごとにリスト持っとけばソートの必要も無いしな。
Zソートもバケットソートで高速だ。

377 :名前は開発中のものです。:2009/08/29(土) 01:19:55 ID:39tdLmSm
>ID:YcewJeTt(new tasksystem ◆9ycqcAuWxdGZ)は
>やねうらおレベルの高度な知的生命体だからどうでもいいとして

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

378 :100:2009/08/29(土) 01:21:09 ID:yvNElBEe
逃げなくていい。ペロっと書いちゃいなよ。どこの誰のタスクシステムの話なのかをよ。
それはタスクシステムじゃねーなんて否定しないって。「あっそ。」で終わりだから。な

379 :名前は開発中のものです。:2009/08/29(土) 01:23:03 ID:39tdLmSm
じゃあ、やねうらお式の奴。と言えば通じるだろう。

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


あっそ。

381 :名前は開発中のものです。:2009/08/29(土) 01:44:42 ID:39tdLmSm
いや、お前のタスクシステムも随分意味無いことしているなとは思ってるのよ。
スレ違いな話題になるから突っ込まないが。
というか、お前こそなんでこのスレに居座ってんだよ。
高みの見物+成り行きってんなら、俺とあまり変わらないぞ。

382 :名前は開発中のものです。:2009/08/29(土) 01:46:26 ID:Dgspg8qU
別にタスクリストは1本にしなくてもいいんだぞ
敵リスト、敵弾リスト、自機弾リスト、自機(リスト)等に分ければおk

383 :名前は開発中のものです。:2009/08/29(土) 01:51:32 ID:39tdLmSm
↑処理オーダーごとにも分けとけ。

384 :名前は開発中のものです。:2009/08/29(土) 01:54:11 ID:1XP42yiS
>>382
それって何がいいの?

385 :名前は開発中のものです。:2009/08/29(土) 02:00:12 ID:Dgspg8qU
例えば敵弾と自機の当たり判定取りたい時にリスト1本だと識別とか面倒でしょ
リスト分けると敵弾リストと自機だけチェックすればええやん
あと敵リストと自機、自機弾リストと敵リストとかな
別に自機弾同士でチェックする必要ないでしょ

386 :名前は開発中のものです。:2009/08/29(土) 02:01:00 ID:nIhnL9c2
>>382
確かに >117 もタスクシステムとみなす宗派の人もいるかもしれないな。
もともとは配列みたいだからリストを使ったものを
タスクシステムとみなさない宗派の人もいるかもしれないな。

387 :名前は開発中のものです。:2009/08/29(土) 02:13:21 ID:39tdLmSm
いや、配列とかリストとかどうでも良いだろ、そんなこと。お前ら本当に飽きないな。
着眼点がおかしいんだよ。
ちなみに>>117の実装は配列。
実装が配列でも、意味の上でリストと説明する場合もあるし、もう、お前らね。
日本語大丈夫かよ。

388 :名前は開発中のものです。:2009/08/29(土) 02:15:41 ID:39tdLmSm
>>385
それだけじゃなくて、型情報が死なない点もポイント。
無意味なダウンキャストを無くせる。

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

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

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

390 :名前は開発中のものです。:2009/08/29(土) 02:28:23 ID:1XP42yiS
>>385
じゃあ、座標変換みたいに全部ほしいときはどうするの?

391 :名前は開発中のものです。:2009/08/29(土) 02:31:09 ID:39tdLmSm
>プリエンプションなしの
>タスクを周期駆動でぶんまわす古典的なリアルタイムシステム

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

392 :名前は開発中のものです。:2009/08/29(土) 02:37:29 ID:Dgspg8qU
座標変換?具体的なことはよく分らんけど
全部欲しい場合は敵リスト、敵弾リスト、自機弾リスト、自機(リスト)全部辿ればいいんじゃね

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

393 :100:2009/08/29(土) 02:40:17 ID:yvNElBEe
>>391
ならばビデオゲームの駆動原理を簡潔に書きたまえ。寝る

394 :名前は開発中のものです。:2009/08/29(土) 02:43:08 ID:1XP42yiS
>>392
それタスクシステムじゃなくてベタ組みじゃね?
ベタ組み&引数通しの俺が全面同意できるんだけど?

395 :100:2009/08/29(土) 02:43:50 ID:yvNElBEe
あー、ついでに古典的な連続系シミュのプログラム構成についても知れ
粒子ベースものがいい。粒子の相互作用の時間発展をシミュレートするものだ

396 :名前は開発中のものです。:2009/08/29(土) 02:58:52 ID:Dgspg8qU
俺のやってるのタスクシステムじゃないかも知れんけど似たようなもんだと思ってやってる
あと俺の場合はコンストラクタで与える以外は引数なしだから

397 :名前は開発中のものです。:2009/08/29(土) 03:04:26 ID:nLDK29Yj
>>387
だからタスカーとかアンチタスカーとかどうでも良いだろ。正直飽きた。
何がタスクシステムなのかすら定まってないんだから
タスクシステムについてここまで話ができるあんたは立派なタスカーだよ。

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

398 :名前は開発中のものです。:2009/08/29(土) 03:05:10 ID:39tdLmSm
>>393
ステートマシン。
ユーザの入力→状態更新→ビデオ出力/音声出力/振動出力。

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

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

399 :名前は開発中のものです。:2009/08/29(土) 03:08:36 ID:39tdLmSm
>>397
おおよそ全てのタイプのタスクシステムを列挙した上で批判している(>>107)
大概どれかに当てはまるでしょ。

400 :名前は開発中のものです。:2009/08/29(土) 03:19:14 ID:Dgspg8qU
> 種類別に添字の範囲を決めることもあったらしい。
なるほど。で俺はそのかわりに種類別にリストを作ると

401 :名前は開発中のものです。:2009/08/29(土) 03:32:37 ID:39tdLmSm
>あー、ついでに古典的な連続系シミュのプログラム構成についても知れ
>粒子ベースものがいい。粒子の相互作用の時間発展をシミュレートするものだ

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

402 :名前は開発中のものです。:2009/08/29(土) 12:36:22 ID:4/KEllMG
俺が愚かだと思う人間。

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

403 :名前は開発中のものです。:2009/08/29(土) 13:32:21 ID:WxQw4Qkk
>401
オマエ、ダブルバッファー君か?

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


404 :名前は開発中のものです。:2009/08/29(土) 14:18:22 ID:WxQw4Qkk
あー、スマン。
>395がダブルバッファー君の可能性があるのか。
>401は全然違う人だな。

405 :名前は開発中のものです。:2009/08/29(土) 21:19:58 ID:qNNhrb6t
>>403
401でもないし事情なんて丸っきり知らない俺が聞くけど、そんなもんなんじゃないの?

406 :名前は開発中のものです。:2009/08/29(土) 21:26:19 ID:WxQw4Qkk
>405
シミュレータ作ってるわけじゃネェぞw

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

407 :名前は開発中のものです。:2009/08/29(土) 22:00:57 ID:qNNhrb6t
>>406
なぜそこでシミュレータになるのかkwsk

408 :名前は開発中のものです。:2009/08/29(土) 22:12:07 ID:WxQw4Qkk
>407
ggrks

409 :名前は開発中のものです。:2009/08/29(土) 23:20:10 ID:qNNhrb6t
>>408
口から出まかせだったのですね。わかります。

410 :名前は開発中のものです。:2009/08/29(土) 23:39:26 ID:Dgspg8qU
厳密にやればそうしなければ駄目だけどそうしなくても十分な場合があるってだけでしょ
状況によって使い分ければいいだけの話じゃないのか

411 :名無しさん@そうだ選挙に行こう:2009/08/30(日) 07:14:17 ID:THZL5z2c
ビリヤードとシューティングの当たり判定処理が同じだと思ってる人、リアルに存在してたんだ…。

412 :名無しさん@そうだ選挙に行こう:2009/08/30(日) 07:15:10 ID:THZL5z2c
ナンか名前が今日だけ違うなw
自分は期日前投票に行ったので無問題。

413 :名無しさん@そうだ選挙に行こう:2009/08/30(日) 10:32:56 ID:w92tenCO
フツーにOOPやってる奴から見るとギョッとするような世界だよな。
ボスクラス、ホーミングクラス?タスクシステムクラス?抽象化が雑すぎる。

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

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

414 :名無しさん@そうだ選挙に行こう:2009/08/30(日) 10:54:13 ID:XZH3UKJR
こんどはOOP君ですか
王様とか引数君、ダブルバッファ君、メリット厨、スレッド厨…
そろそろ登場人物についてのまとめが必要になってきそうだな

415 :名無しさん@そうだ選挙に行こう:2009/08/30(日) 10:59:00 ID:w92tenCO
>>414
そういうお前は属人クンだよw
中身じゃなくて、人格への偏見でしか語らぬ。

416 :100:2009/08/30(日) 11:18:13 ID:RQNrxHmb
>>404
相互の作用(押し合いへし合い)があるなら「いっせーのーせ」でやるし
相互でなく一方的な作用なら今までどおり端折っちまえばいい
典型的なSTGなら基本的に後者で何も問題ないだろ

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

417 :名無しさん@そうだ選挙に行こう:2009/08/30(日) 11:20:27 ID:3omGLRgw
みんな得意の脳内妄想じゃなくて
動くサンプル作ってくれ

418 :名無しさん@そうだ選挙に行こう:2009/08/30(日) 11:23:27 ID:RHNnEmWm
>>413
is-a か has-a のどちらが適切か、は何をどうモデル化するかによって変わるんだがなぁ
それとも全てのゲームの仕様をたった一つの設計で済ませられると考えてるのかねぇ・・・

419 :100:2009/08/30(日) 11:28:37 ID:RQNrxHmb
アンチはSTGも作れんような乞食しかおらんのか
>>416の意味が分からないのか。そうかー

420 :名無しさん@そうだ選挙に行こう:2009/08/30(日) 11:35:47 ID:oK3pTspz
>>413
>動き方ストラテジ(略)を、最初にパラメータで渡して

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

421 :名無しさん@そうだ選挙に行こう:2009/08/30(日) 13:42:16 ID:FM9g8kNh
//パンシューティング
bread("↑↓↓→↑休休↑");
bread(curry_update/*←関数*/);
bread(new curry() );
俺はあまりお勧めしないが。OOPは制御構造がガタガタになるから嫌いだな。

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

422 :名無しさん@そうだ選挙に行こう:2009/08/30(日) 13:58:37 ID:RQNrxHmb
>>421
悪いな。阿呆すぎる発言につい呆れてしまったんだよ

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

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

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

> ステートマシン。

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

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

423 :名無しさん@そうだ選挙に行こう:2009/08/30(日) 14:24:02 ID:RQNrxHmb
>>398
>ユーザの入力→状態更新→ビデオ出力/音声出力/振動出力。

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

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

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

424 :名無しさん@そうだ選挙に行こう:2009/08/30(日) 14:24:58 ID:FM9g8kNh
メインループ部を直接記述できるから、だと書いてあっただろ。

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

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

425 :名無しさん@そうだ選挙に行こう:2009/08/30(日) 14:32:13 ID:FM9g8kNh
>>423
その点は異論無いな。
ただ、タスクは要らないだろうと。単にループ部に処理を書いていけば良いだけ。
処理が長くなったり、使いまわす場合は、関数を使う。普通の開発手法。
で、タスクシステムの出る幕は?

426 :名無しさん@そうだ選挙に行こう:2009/08/30(日) 14:43:33 ID:FM9g8kNh
あと、周期駆動っつったって、定期的に入力が発生するだけ。
ほかのアプリとなんら変わらん。

427 :名無しさん@そうだ選挙に行こう:2009/08/30(日) 14:45:07 ID:RQNrxHmb
>>424
> ゲームの動作原理がステートマシンという主張は、
> ゲームがその辺のGUIアプリとなんら変わり無いという意図。

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

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

428 :名無しさん@そうだ選挙に行こう:2009/08/30(日) 14:59:09 ID:FM9g8kNh
>>427
お前が「駆動原理」とかいう抽象的な聞き方するから、
普通のアプリであるゲームの動作原理を説明するのに、
普通のアプリの駆動原理である「ステートマシン」を持ち出すしかなかったんだろ。
質問が抽象的だから抽象的に答えたんだ。

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

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

429 :名無しさん@そうだ選挙に行こう:2009/08/30(日) 15:03:20 ID:RQNrxHmb
>>425
> その点は異論無いな。

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

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

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

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

430 :名無しさん@そうだ選挙に行こう:2009/08/30(日) 15:13:47 ID:FM9g8kNh
>>429
もう言ってることがいよいよ神がかってきてるんだが。
俺のエスパー能力にも限界がある。

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

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

432 :名無しさん@そうだ選挙に行こう:2009/08/30(日) 15:40:44 ID:FM9g8kNh
あほ:うわぁ、Windowsすげぇ、イベント部だけ書けば良いなんて、MS超優しいね。

違う違う逆逆。

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

これが真相。

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

433 :名無しさん@そうだ選挙に行こう:2009/08/30(日) 15:50:05 ID:RQNrxHmb
>>430
超能力能力なんて求めていない
君はそういう突飛な能力を持ってるらしいが俺は持ってない。うらやましいね

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

視野の狭い子だな

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

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

といった感じでね

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

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

434 :名無しさん@そうだ選挙に行こう:2009/08/30(日) 15:53:12 ID:RQNrxHmb
×ゲームでは時間駆動型の基本システムの上にイベント駆動のシステムを
乗せているビデオゲームだ。

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

435 :名無しさん@そうだ選挙に行こう:2009/08/30(日) 15:53:35 ID:FM9g8kNh
分かりやすく現実世界に当てはめるとこうだ。

銀行:お前らのお金管理してあげるよ。お前は仕事だけしてくれればいい。
あほ:仕事に専念できるなんてラッキー

同僚:お前の仕事は俺が振ってあげるよ。お前は作業だけしてくれればいい。
あほ:適当に作業こなして定時で帰れるなんてラッキー。

上司:お前は管理職しなくていいぞ。もっと言えば家で休んでくれてていい。
あほ:えっ!?

あほ:俺は政治家になるぞ!!「今の日本は間違ってる!!」

お前ら選挙行けよ。

436 :名無しさん@そうだ選挙に行こう:2009/08/30(日) 15:55:00 ID:RQNrxHmb
ついに知能障害をおこしたか

437 :名無しさん@そうだ選挙に行こう:2009/08/30(日) 16:10:22 ID:FM9g8kNh
>>433
それと、
「GUIアプリはイベントドリブンだから、周期駆動であるゲームとは違う」という、
お前の主張に何の関連性があるんだ。

お前も、

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

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

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

438 :名無しさん@そうだ選挙に行こう:2009/08/30(日) 16:14:35 ID:FM9g8kNh
そもそも、
『プリエンプションなしのタスクを周期駆動でぶんまわす』

『ゲームの駆動原理』
の説明がなされて無いんだが。

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

439 :名無しさん@そうだ選挙に行こう:2009/08/30(日) 16:34:21 ID:RQNrxHmb
>>398
>ゲームは単体アプリだから、マルチタスクも糞も関係ないんだよね。
>OSのプロセス管理の真似事なんてする必要なし。
>ゲームはOSのプロセス管理とは違って、メインループ部を自由に触れるということ。

本当に視野の狭い子だな

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

440 :名無しさん@そうだ選挙に行こう:2009/08/30(日) 16:34:55 ID:FM9g8kNh
あと、イベントドリブンと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?何の関係があるの?

441 :名無しさん@そうだ選挙に行こう:2009/08/30(日) 16:49:36 ID:FM9g8kNh
>>439
どうでも良いから>>438>>440の説明だけはしろよ。
お前が言い出したことだからな。

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

442 :名無しさん@そうだ選挙に行こう:2009/08/30(日) 16:59:03 ID:THZL5z2c
>417
夏休みの宿題、やらずにここまで過ごしてきたの?

443 :名無しさん@そうだ選挙に行こう:2009/08/30(日) 17:02:41 ID:THZL5z2c
>419
前スレに居たんだよ、『状態をダブルバッファにしてすべてのnからn+1を生成しないと正しく当たり判定
出来ない!!』って一人荒野で叫び続けてた人が。

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

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

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

445 :名無しさん@そうだ選挙に行こう:2009/08/30(日) 17:22:37 ID:RQNrxHmb
>>398
> 粒子の振る舞いを外部からプログラマブルに定義しないのなら、
> ベタ書きで十分だし、処理速度も一番速いし、実装も早い。

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

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

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

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

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

446 :名無しさん@そうだ選挙に行こう:2009/08/30(日) 17:37:38 ID:RQNrxHmb
> ただのサブルーチンだ

乱暴な言い方だったかな

447 :名無しさん@そうだ選挙に行こう:2009/08/30(日) 17:54:47 ID:THZL5z2c
>445
>       『プリエンプションなしのタスクを周期駆動でぶんまわす』
> こんなのゲームの中にあって当たり前の仕組み。
> これがゲームに必要ないなんてありえないよね。流石に異論はないだろうな

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

448 :名無しさん@そうだ選挙に行こう:2009/08/30(日) 17:56:27 ID:1rNxOJqx
イベントドリブンの仕組みが非プリエンプティブなタスクによって実現されているからといって
システム全体を「プリエンプティブなしのタスクを周期駆動でぶんまわす」なんて表現したりはしない。
どんな抽象化レイヤーの上でゲームを構築するかという話では無いのか。

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

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

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

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

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

451 :名無しさん@そうだ選挙に行こう:2009/08/30(日) 18:48:03 ID:RQNrxHmb
>>440
このコード断片は一体なんなのかね…。何のアプリの断片なのかね…
GUIアプリなのかね。なぜビジーウェイトしてる。シングルプロセスのOSで
動かしているのか。GUIのイベントは誰が突っ込むのかね

意味が分からない

452 :名無しさん@そうだ選挙に行こう:2009/08/30(日) 18:55:57 ID:RQNrxHmb
ハードウェアの全てを独占的に使う権利を有しているのかね。
OSも何も供給されない。デバイスドライバからGUIのシステムから
全て自前で用意してるのかね。ディスプレイ装置に出力する映像は
全て自前で生成してるのかね

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

454 :名無しさん@そうだ選挙に行こう:2009/08/30(日) 19:13:31 ID:FM9g8kNh
>>451>>452
何わけのわからないことを。
>>440は単にイベント駆動プログラムのサンプルだ。何かのプログラムというわけではない。
OSに頼らなくてもイベント駆動のプログラムは書けると証明したまで。
イベント駆動だからといって、waitしなければならないという理屈も無いし、
協調動作しなければならないという理屈も無い。
>>440は無限ループしているわけではなく、一連の処理をすばやく終え、
どこかの段階でreturnしていると思えばよい。
たとえば、event3の処理の中でreturnしているのかもしれない。(どうでも良いこと)

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

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

455 :名無しさん@そうだ選挙に行こう:2009/08/30(日) 19:15:23 ID:FM9g8kNh
イベント駆動=協調動作っていう固定観念が邪魔しているのかな。
視野が狭いのはどっちだか。

456 :名無しさん@そうだ選挙に行こう:2009/08/30(日) 19:30:48 ID:k8sAKLJX
とりあえずタスクシステムと「〜駆動」の関連を3行ほどにまとめてから話してくれないか?

457 :名前は開発中のものです。:2009/08/30(日) 20:42:34 ID:RQNrxHmb
>>454
私が興味を示している君の主張
--------------------------------------------------------------------------
1.『プリエンプションなしのタスクを周期駆動でぶんまわす』
  こんなものはゲームに必要ない。

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

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

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

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

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







458 :名前は開発中のものです。:2009/08/30(日) 20:58:47 ID:3RBuyM8s
プリオンの話禁止

459 :名前は開発中のものです。:2009/08/30(日) 21:07:10 ID:1rNxOJqx
肉骨粉?食べてませんよ。

460 :名前は開発中のものです。:2009/08/30(日) 21:24:36 ID:Evk5JevG
えーっと、ここWindows前提だよね?
その為にPCカテゴリに移ったんだから

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

461 :名前は開発中のものです。:2009/08/30(日) 21:26:32 ID:w92tenCO
>>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);
}
}

462 :名前は開発中のものです。:2009/08/30(日) 22:33:13 ID:M6w1lArj
>>460
> えーっと、ここWindows前提だよね?
その前提はどこから出てきたんだ?

Windows用ゲームって・・・
開発機としてはともかく、Windows向けゲームなんて日本で作られてるゲームの1%にも満たないだろ・・・
まだ携帯向けの方が多い。

Windows限定、なんてレアケースあえて扱う意味あるのか?

463 :名前は開発中のものです。:2009/08/30(日) 23:39:33 ID:uxijzm7v
>>Windows限定、なんてレアケースあえて扱う意味あるのか?
ありますよ。CSは個人じゃなかなか扱えないし、
タスクシステムよくご存じなら
XNAやWindowsにも話をもっていけるはずでしょ。
ここはアマチュアが多いしそこに話を持っていく
意味は十二分にあると思いますよ。

464 :選挙見てた:2009/08/30(日) 23:42:00 ID:FM9g8kNh
>君の言う【その辺のGUIアプリ】【普通のGUIアプリ】とは一体何なのかね。
ワードやエクセルで良いよ。

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

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

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

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

465 :名前は開発中のものです。:2009/08/30(日) 23:42:59 ID:lQ/SzS0M
個人や同人ならwindows限定がレアなケースっていう感じではないと思うけど。
ここはプロの集まるスレですか?

466 :名前は開発中のものです。:2009/08/31(月) 00:12:10 ID:GJHa9qyy
Windowsも含める、ならわかるが
あえてWindowsに限定するってことは
プロお断り、アマチュアのみという感じになるが
アマチュアに限定しないといけない理由は何だろう?

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


467 :名前は開発中のものです。:2009/08/31(月) 00:18:33 ID:d6qZudqV
私が興味を示している君の主張
--------------------------------------------------------------------------
1.『プリエンプションなしのタスクを周期駆動でぶんまわす』という仕組みはゲームに必要ない。

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

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

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

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

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

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

訳が分からんな




468 :名前は開発中のものです。:2009/08/31(月) 00:28:25 ID:d6qZudqV
> 事象駆動でも、周期的にイベントを発生させれば周期駆動になる。
> 周期駆動は事象駆動に含まれているということだ。
> 分けて考える必要なし。

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

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

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

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

469 :名前は開発中のものです。:2009/08/31(月) 03:18:32 ID:BlL4aYkd
>>466
> アマチュアに限定しないといけない理由は何だろう?
そりゃコンシューマでもアーケードでも携帯でもトイゲームでも全ての環境で
タスクシステムは使い物になりません、なんて証明できんからな。

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

470 :名前は開発中のものです。:2009/08/31(月) 07:32:25 ID:QF/DBd4l
頭おかしいのがいるな(笑)
そんなにエロゲが作りたいのか?

471 :名前は開発中のものです。:2009/08/31(月) 08:53:03 ID:lK3+LCV3
>>469
お前のようにロクに意見も言えずに、
対立を煽って面白がってる奴はこのスレにとって不要。
アンチだの惨敗だのに拘って何が得られるのか。

472 :名前は開発中のものです。:2009/08/31(月) 16:19:40 ID:hrJaPm5K
タスクシステム使っても作れるし
使わなくても作れるので不毛

473 :名前は開発中のものです。:2009/08/31(月) 20:41:26 ID:h17voCAS
>>468
>現実にはこのような対比・区別が存在するわけだ
区別されてたからって、組み方が変わるわけじゃないだろ。

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

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

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

474 :名前は開発中のものです。:2009/08/31(月) 20:44:46 ID:lK3+LCV3
拙い頭では余計だコラw

475 :名前は開発中のものです。:2009/09/02(水) 21:14:21 ID:M+67RIeI
なんというか
レベルが低すぎて逆にわからん

476 :名前は開発中のものです。:2009/09/04(金) 19:27:50 ID:sohKwZfR
マインスイーパーもタスクシステム使ってるの?

477 :名前は開発中のものです。:2009/09/05(土) 01:05:30 ID:BLuHc9Vl
ウインドウズがタスクシステムつかってるから余裕で使ってる

478 :名前は開発中のものです。:2009/09/05(土) 01:57:31 ID:5ptcCMmv
釣りネタだろうけどOSの話とは違うんじゃないの

479 :名前は開発中のものです。:2009/09/05(土) 12:27:04 ID:heZqu6zG
Windows限定、アマチュア限定になってこのスレ終わったな・・・

480 :名前は開発中のものです。:2009/09/05(土) 14:05:05 ID:BLuHc9Vl
タスクシステムって組み込み系のテクニックですよね

481 :名前は開発中のものです。:2009/09/05(土) 14:31:44 ID:+n5CyLOp
アマチュア個人だと作業分担もなければ
再利用もあまり考えなくていいしタスクシステムのメリットってほとんどないな

482 :名前は開発中のものです。:2009/09/05(土) 14:46:06 ID:SHBZF47D
わざわざ生存管理をタスクシステムにとられちゃうのが納得いかない
んでアクセスするときに判別するのがすげー嫌
登録だけしておいて後はこっちで自由にさせろよ
それとこっちでnewしたもの勝手にdeleteするな

483 :名前は開発中のものです。:2009/09/05(土) 15:27:14 ID:e3abVnaU
>>482
> それとこっちでnewしたもの勝手にdeleteするな

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

484 :名前は開発中のものです。:2009/09/05(土) 15:40:37 ID:irJy1zL4
GCは参照のあるオブジェクトを勝手にdeleteしないのだが。

485 :名前は開発中のものです。:2009/09/05(土) 15:51:47 ID:e3abVnaU
>>484
それを言えば、典型的なタスクシステムにしても、「もう消滅していいよ」ということを意味する delete markerが
ついているからオブジェクトを削除するのであって、勝手にdeleteしているわけではない。

486 :名前は開発中のものです。:2009/09/05(土) 16:09:50 ID:irJy1zL4
>>485
その実装はマーカーに従って明示的にdeleteしているわけで、
>>482の言う「勝手にdelete」とは違うんじゃないの?
たとえば、親が死んだら子も死ぬとかが、勝手にdeleteの代表だろう。

487 :名前は開発中のものです。:2009/09/05(土) 16:21:59 ID:e3abVnaU
>>486
> >>482の言う「勝手にdelete」とは違うんじゃないの?

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

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

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

488 :名前は開発中のものです。:2009/09/05(土) 16:33:53 ID:irJy1zL4
それはお前の気にするところではない。

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

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

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

489 :名前は開発中のものです。:2009/09/05(土) 17:15:51 ID:e3abVnaU
>>488
> タスクシステムは指定したオブジェクト以外も削除することがある。(予測不能な無効な参照を生む)

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

490 :名前は開発中のものです。:2009/09/05(土) 18:27:28 ID:SHBZF47D
>>489
いや、大半のタスクシステムが削除しちゃうと思うよ
だって参照カウントみて残ってたら自分を削除できないんだよ
これをどうやって解決する?

491 :名前は開発中のものです。:2009/09/05(土) 19:03:30 ID:aodQjbKC
参照カウントによって削除させる設計は全て愚か。

492 :名前は開発中のものです。:2009/09/05(土) 19:11:41 ID:SHBZF47D
>>491
じゃあ、残しておけば
そっちのが多分スタンダードじゃない?

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

493 :名前は開発中のものです。:2009/09/05(土) 19:15:19 ID:e3abVnaU
>>490
> いや、大半のタスクシステムが削除しちゃうと思うよ
> だって参照カウントみて残ってたら自分を削除できないんだよ

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

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

494 :名前は開発中のものです。:2009/09/05(土) 19:44:49 ID:irJy1zL4
ID:SHBZF47D の主張
いや、大半のタスクシステムが削除しちゃうと思うよ
だって参照カウントみて残ってたら自分を削除できないんだよ
だから参照カウンタは使わない。

ID:e3abVnaU の反論
どこに参照カウンタ使ってるタスクシステムがあるんだよ。
普通、タスクシステムは参照カウンタなんかみないよ。

495 :名前は開発中のものです。:2009/09/05(土) 20:04:17 ID:aodQjbKC
>>100ことID:yvNElBEe

  vs

アンチタスカーID:43RWv3KZ

「入力部に拘ってるのは>>100ことID:yvNElBEeだけ。お前だけスレ違いで、話のピントがずれてる。
要領が悪いということ。」

496 :名前は開発中のものです。:2009/09/05(土) 20:09:07 ID:e3abVnaU
>>494
ID:SHBZF47Dと私とでは参照カウンタを使わないという点では、一致してるんだ。

ID:SHBZF47Dが勝手に私を参照カウンタ利用者と勘違いして反論しているのがおかしいんだ。

また同時に、ID:SHBZF47Dは、参照カウンタを使わなければ、
> それとこっちでnewしたもの勝手にdeleteするな
のようになると思っているのがおかしいんだ。

delete markerをmarkしたのは、タスクシステムの利用者であって、タスクシステム側ではない。
だから、タスクシステムが勝手にdeleteしたのではなく、タスクシステム利用者の希望によって
タスクシステム側がdeleteしているのに過ぎない。

497 :名前は開発中のものです。:2009/09/05(土) 20:28:56 ID:SHBZF47D
>>496
だれもdeleteしてくれなんて頼んでないし
なんでdeleteしようとするのかわからない
余計なことするなと本気で思う

普通にクラスにメンバでもってnewしてない奴を認めない理由はなんで?
ゲーム中ずっといるから常駐してる奴をタスクシステムに登録するとおかしくなるよね?

498 :名前は開発中のものです。:2009/09/05(土) 20:36:03 ID:e3abVnaU
>>497
> なんでdeleteしようとするのかわからない
> 余計なことするなと本気で思う

誰かが生存を管理する必要がある。生成をしたオブジェクトが生存を管理するのは
生成したオブジェクトのほうがlifetimeが長いとは限らないから、そういう設計にすることは出来ない。

だから、タスクシステムを使おうと使うまいと、どこかに生存を管理するmanagerは必須だよ。

> 普通にクラスにメンバでもってnewしてない奴を認めない理由はなんで?

別に持ってもいいよ。lifetimeがそれをメンバに持つオブジェクトと同じで、
あとタスクシステム側から何の恩恵も受けないつもりならね。

499 :名前は開発中のものです。:2009/09/05(土) 20:48:13 ID:irJy1zL4
あーだんだんID:e3abVnaUの糞実装がおぼろげに見えてきた。
普通にタスクのコンストラクタでattach、デストラクタでdetachで良いだろ。
生存を管理するmanagerを用意するんじゃなくて、参照を管理するmanagerを用意しなさい。

500 :名前は開発中のものです。:2009/09/05(土) 20:50:07 ID:SHBZF47D
>>499
>生存を管理するmanagerを用意するんじゃなくて、参照を管理するmanagerを用意しなさい。
それでいいよな
それで駄目な理由がわからない

501 :名前は開発中のものです。:2009/09/05(土) 21:41:46 ID:heZqu6zG
>>500
別にアマチュア限定のスレだからいいんじゃない?
個人、同人限定なんだからへんてこ実装でも誰がこまるわけでもないし・・・

502 :名前は開発中のものです。:2009/09/05(土) 21:43:24 ID:SHBZF47D
>>501
自分が説明できない理由をそうやって誤魔化そうとするなら
ハナから技術系の板にくるなよお前

503 :名前は開発中のものです。:2009/09/05(土) 21:47:27 ID:heZqu6zG
タスク程度の何が技術なんだか・・・
タスクの使い方わからないなんて
ポインタの使い方わからないってのと同じレベルだろ。
そんな話延々と続けたいか?

504 :名前は開発中のものです。:2009/09/05(土) 21:50:30 ID:SHBZF47D
>>503
具体的な話をしようぜ

505 :名前は開発中のものです。:2009/09/05(土) 22:02:15 ID:heZqu6zG
>>504
仕様も使用条件もソースも無いのに具体的になんて無意味って気づけよ。

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

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


506 :名前は開発中のものです。:2009/09/05(土) 22:21:41 ID:BLuHc9Vl
タスクシステムって実装?設計?概要?

507 :名前は開発中のものです。:2009/09/05(土) 23:04:05 ID:jDXeKU7V
Windowsでしかゲーム売れない件

508 :名前は開発中のものです。:2009/09/05(土) 23:14:23 ID:heZqu6zG
>>507
Windowsでしか”同人”ゲーム売れない件、でしょww

509 :名前は開発中のものです。:2009/09/05(土) 23:45:29 ID:SHBZF47D
タスカー側がそんなに使われてるって主張するなら
ソースがダウンロードできるゲームのサンプルで納得がいくのを見つけてこいよw

510 :名前は開発中のものです。:2009/09/05(土) 23:46:44 ID:jDXeKU7V
UNIXでな!

511 :名前は開発中のものです。:2009/09/05(土) 23:47:43 ID:SHBZF47D
>>510
動かないのは駄目ではないんだろうけどやめてほしいなぁ

512 :名前は開発中のものです。:2009/09/06(日) 00:00:58 ID:Sj7HS1TH
>>509
> タスカー側がそんなに使われてるって主張するなら
どこにそんな主張があるのかなぁ?www
アマチュア同人ならどんな実装でもいいんじゃね、としか言っていないが

513 :名前は開発中のものです。:2009/09/06(日) 00:13:58 ID:uHEt6tr/
>>512
なんだ使われてないのかw
やっぱりやねうらおが1人で自演してんだな
悲しい奴だ

514 :名前は開発中のものです。:2009/09/06(日) 00:30:25 ID:Sj7HS1TH
>>513
そうそう、タスクシステムなんて君には一生関わりの無い話。
これで安心して寝れるねwww

515 :名前は開発中のものです。:2009/09/06(日) 00:53:11 ID:TBqzcqpD
アンチタスクは何故こんなゴミ虫レベルの奴が多いのか

516 :名前は開発中のものです。:2009/09/06(日) 05:10:28 ID:0jKZGYOX
タスクシステム養護派は具体例に欠け
脳内俺俺仕様をおしつけてくるからタチが悪い

517 :名前は開発中のものです。:2009/09/06(日) 05:12:10 ID:0jKZGYOX
結局のところ 「ググレカス」 に終わり
それ以上の話はすすまない
オープンソース時代の今の風流には合わない人間

518 :名前は開発中のものです。:2009/09/06(日) 05:22:26 ID:Sj7HS1TH
>>517
アンチはググルこともできない今の時代に適応できないゆとりだ、
と言ってるのねwww

519 :名前は開発中のものです。:2009/09/06(日) 06:46:47 ID:0jKZGYOX
>>518
あなたとは関わり合いたくないですね

520 :名前は開発中のものです。:2009/09/06(日) 09:36:55 ID:uHEt6tr/
だいたいタスクシステム側が納得いくタスクシステムをソース付きで出してくれないと
話進まないだろ
いつも何かを基準にしてると「これじゃない」っていうし

521 :名前は開発中のものです。:2009/09/06(日) 09:37:30 ID:bJbP9YDC
googleでタスクシステムで検索。以下上位サイト。

「その3 タスクシステムと「ゆるゆる」なキャラクタ」
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
ノーコメント

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

522 :名前は開発中のものです。:2009/09/06(日) 09:46:09 ID:bJbP9YDC
タスクシステムの不思議

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

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

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

523 :名前は開発中のものです。:2009/09/06(日) 09:59:14 ID:RF8wH9Rt
>>500>>501と来た流れでの>>502に対して、
>>503とレスをつけるような奴を相手にしてはならないw

524 :名前は開発中のものです。:2009/09/06(日) 10:06:40 ID:bJbP9YDC
タスクシステマーが本当にしたかったことは、タスクシステムでは無かったということ。
本当にしたかったことは、

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

実装すべきものは、

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

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

525 :名前は開発中のものです。:2009/09/06(日) 10:07:41 ID:bJbP9YDC
訂正
・型を列挙するためのマクロ。( 例: each_type( type ){ /*処理*/ } )

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

526 :名前は開発中のものです。:2009/09/06(日) 10:12:14 ID:RF8wH9Rt
>>524
うん、俺もそう思うよ。
カプセル化、分割統治、っていう構造をブッ壊して(・∀・)ニヤニヤしてる。
で、こまったことが出てきたらそこを必死で繕ってるような二度手間のイメージ。

527 :名前は開発中のものです。:2009/09/06(日) 11:12:23 ID:uHEt6tr/
>>524
それだけとも違うと思うなぁ
だって仮に3Dで座標更新しようと思ったら
ワールドからツリーで追っていかないと親子関係表現できないじゃん
型だけじゃないっしょ

SQLみたいに自分の条件でオブジェクトを検索してくる「何か?」って感じで
実装するシステムによってどうとでも化ける気がするなぁ

もうホント条件を使う側が自由にできないとどうしようもねぇと思う

528 :名前は開発中のものです。:2009/09/06(日) 11:59:37 ID:bJbP9YDC
>>527
親子関係は親子関係で別に持てばよいだろ。
タスクシステムでも、処理順がコントロールできるだけで、親子関係までは見てくれない。
もし自分のタスクシステムは面倒見てくれるっていうんなら、それはやりすぎ。
親子関係を見て列挙順をコントロールする仕組みは別に用意した方が良い。
たとえば、set_parent()メソッド内で、ワールドまでの階層をしらべて列挙順を変更すればよい。
ただ、型を飛び越えて列挙順が制御できる必要はある。
だから、型ごとだけではなく、列挙順ごとにもリストを持ってるわけで。

//orderly内はeach_type間を飛び越えて列挙順序を守ってね
//列挙順0の親→列挙順0の子→列挙順1の親→列挙順1の子・・・・の順で処理される
orderly( updating_order )
{
  each_type( oya, updating_order ){ /*親更新コード*/ }
  each_type( ko, updating_order ){ /*子更新コード*/ }
}

529 :名前は開発中のものです。:2009/09/06(日) 12:06:31 ID:bJbP9YDC
マクロだと分かりにくいので。

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]の更新*/ }
}

530 :名前は開発中のものです。:2009/09/06(日) 12:27:04 ID:uHEt6tr/
>>528
なにがやりすぎなのか意味わからないけど
その型がとってこれるっていう局所仕様になんのメリットがあるのかわからない
ようは必要なのはDBとSQLで条件指定したらなんでもかんでもとってこれないと駄目なんだろ?

531 :名前は開発中のものです。:2009/09/06(日) 13:04:04 ID:bJbP9YDC
それじゃリアルタイムで動かない

532 :名前は開発中のものです。:2009/09/06(日) 13:08:44 ID:uHEt6tr/
>>531
マジでDB使ってSQL打ってたら間に合わないけど
遠かれど似たようなものだったら作れるだろ?
俺もタスクシステム使って組まされたときは毎回毎回
必要なオブジェクトの検索を処理の冒頭でしたもんだぜ
これがウザクてな
インスタンス消えてるときもあるしよーw

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

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

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

533 :名前は開発中のものです。:2009/09/06(日) 13:14:29 ID:bJbP9YDC
型で列挙するのにはそれなりに意味はある。
もし、型以外のキーで列挙すると、列挙した後に、正しい型へのキャストと、正しい処理への分岐が
必要になる。

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

534 :名前は開発中のものです。:2009/09/06(日) 13:16:04 ID:uHEt6tr/
>>533
そんなの下ごしらえの仕方だろ?
どーにでもなる話の議論は無しの方向で

535 :名前は開発中のものです。:2009/09/06(日) 13:27:10 ID:bJbP9YDC
いや、型以外のキーで検索したら、どう頑張ってもダウンキャストが必要。

536 :名前は開発中のものです。:2009/09/06(日) 13:31:31 ID:TTUz744b
>>482
> わざわざ生存管理をタスクシステムにとられちゃうのが納得いかない

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

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

537 :名前は開発中のものです。:2009/09/06(日) 13:45:25 ID:uHEt6tr/
>>536
ん?
君の立ち位置がよくわからない
内部でdeleteしちゃってるようなのは駄目って言ってるの?

538 :名前は開発中のものです。:2009/09/06(日) 13:46:32 ID:RF8wH9Rt
>>533
グヘヘ、っていうのはそもそもの肝かもしれない。
グヘヘ、と思って有り難がってるからこそ、
そんなやつらがムリヤリ頑張ってるからこそ、
こんな野暮ったい仕組みが残ってしまうのかもね。

539 :538:2009/09/06(日) 13:47:12 ID:RF8wH9Rt
×>>533
>>536

540 :名前は開発中のものです。:2009/09/06(日) 13:52:43 ID:TTUz744b
タスクシステムと呼ばれるものの本来の役割、本旨は何かを探れば
生存管理なんてのが枝葉、装飾、後付け機能だということがわかるでしょ

541 :名前は開発中のものです。:2009/09/06(日) 13:56:44 ID:bJbP9YDC
本来の役割って何ですか?
ギャラクシアンを動かすこと?
無能下請けをタスクの殻に閉じ込めること?
無駄な仕事を作って自分の居場所を確保すること?

542 :名前は開発中のものです。:2009/09/06(日) 13:59:11 ID:RF8wH9Rt
>>541
キミらの本音を聞きたいね。
俺は

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

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

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

543 :名前は開発中のものです。:2009/09/06(日) 14:02:38 ID:TTUz744b
関連性の希薄な例え話が大好きで、おつむの出来がとても残念な
ファイルシステム君の真似をすると

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

544 :名前は開発中のものです。:2009/09/06(日) 14:06:11 ID:TTUz744b
実行待ちキューに登録されたタスクを順次実行する。これが本旨。
まずここを否定するタスクシステムは疑ってかかるべきだ。傍系の始まりは
この辺りだ。

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


545 :名前は開発中のものです。:2009/09/06(日) 14:08:39 ID:TTUz744b
ゲームルール上のOBJの生死はタスクシステムの関知するお話ではない
メモリ割り当て上のOBJの生死もタスクシステムの関知するお話ではない

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

546 :名前は開発中のものです。:2009/09/06(日) 14:13:12 ID:TTUz744b
あるいは>>500-501の主張。参照を管理するmanagerを用意しなさいとかいうもの。
具体的に何をどうマネージメントしてくれるのかは彼らの脳内の話であるが
まぁ例えばOBJの参照関係グラフのようなものがあるとする。こういうものは
タスクシステムとは全く関係ない


547 :名前は開発中のものです。:2009/09/06(日) 14:24:13 ID:RF8wH9Rt
>>544-545
へー。それなら話はわからんでもない、というか少し興味は持てる。
そういう、小さい部分だけの話なら、胡散臭さも入る余地無し。

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

548 :名前は開発中のものです。:2009/09/06(日) 14:25:09 ID:uHEt6tr/
>ID:TTUz744b
ごめん
何が言いたいのかさっぱりわからない

549 :名前は開発中のものです。:2009/09/06(日) 14:34:06 ID:bJbP9YDC
タスクシステムは要らないといいたいんだよ。

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

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

550 :名前は開発中のものです。:2009/09/06(日) 14:37:54 ID:bJbP9YDC
何がややこしいって、
タスクシステマーが本当に欲しがってる物は、タスクシステムではないということ。

551 :名前は開発中のものです。:2009/09/06(日) 14:39:17 ID:TTUz744b
デジタルコンピュータの登場当初から存在していた
『プリエンプションなしの タスクを周期駆動でぶんまわす』
古典的なリアルタイムシステムのプログラム構成を知れ

こういうこと

552 :名前は開発中のものです。:2009/09/06(日) 14:45:38 ID:bJbP9YDC
for(;;)
{
sub1();
sub2();
sub3();
wait();
}

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

553 :名前は開発中のものです。:2009/09/06(日) 14:53:59 ID:TTUz744b
>このスレの論点は、キックされた後の更新処理。

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

554 :名前は開発中のものです。:2009/09/06(日) 15:08:08 ID:bJbP9YDC
俺がきれいな方程式を立ててやろう。

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

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

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

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

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

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

555 :名前は開発中のものです。:2009/09/06(日) 15:18:34 ID:bihVQpPT
>>553
あたりまえだろ
ここはアマチュア限定のスレなんだから。

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

556 :名前は開発中のものです。:2009/09/06(日) 15:21:26 ID:bJbP9YDC
ちなみに、タスクシステムと周期駆動は何の関係も無い。
タスクシステムは周期駆動のためにあるわけではない。
周期駆動させてるのはSleep関数。
こいつで一定間隔でOSからキックしてもらうことで周期駆動している。
タスクシステムは状態更新をするためにある。

557 :名前は開発中のものです。:2009/09/06(日) 15:50:12 ID:nQ3Bvnux
今のスペックならSQLでもいけそうだな
組み込み用DBも商用になってきたし
そろそろゲーム用DBも出てくるかな
同人レベルならSQLiteでも間に合いそうな気がするが

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

558 :名前は開発中のものです。:2009/09/06(日) 15:51:14 ID:uHEt6tr/
>>557
はぁ?

559 :名前は開発中のものです。:2009/09/06(日) 16:07:13 ID:bJbP9YDC
だからね、俺がね、何が言いたいかって言うとね、
イベント駆動/周期駆動はそのプログラムの待機の仕方を表しているに過ぎないんだよ。
Windowsだと、
イベント駆動だとGetMessageでメッセージが来るまで待機、
周期駆動だとSleepで一定間隔待機。
だけどね、待機しているってことは、その間そのプログラムは走って無いってこと。
プログラムが走って無いときのことを論点にして、何の意味がある?

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

560 :名前は開発中のものです。:2009/09/06(日) 16:11:04 ID:TTUz744b
一週間たっても全く成長がないのだな

          _Y_
            r'。∧。y.
         ゝ∨ノ     バカがタスクシステムに        ,,,ィf...,,,__
          )~~(            幻惑されてる間に    _,,.∠/゙`'''t-nヾ ̄"'''=ー-.....,,,
         ,i   i,                        ,z'"    ̄ ̄ /n゙゙''''ー--...
         ,i>   <i     文明はどんどん発達し    r”^ヽ      く:::::|::|:::〔〕〔〕
         i>   <i.     ていく・・・・・・。      入_,..ノ ℃      ̄U ̄_二ニ=
`=.,,ー- ...,,,__ |,r'''"7ヽ、|  __,,,... -ー,,.='               >ーz-,,,...--,‐,‐;;:'''""~
  ~''':x.,,  ~"|{ G ゝG }|"~  ,,z:''"                     ___
      ~"'=| ゝ、.3 _ノ |=''"~      <ー<>         /  l ̄ ̄\
        .|))    ((|        / ̄ ゙̄i;:、      「 ̄ ̄ ̄ ̄| ̄| ̄ ̄ ̄\
             ))|       r'´ ̄「中] ̄`ヾv、   `-◎──────◎一'
                   ├―┤=├―┤ |li:,
                   |「 ̄ |i ̄i|「.//||「ln|:;
                   ||//__|L_」||__.||l」u|:;
                   |ニ⊃|  |⊂ニ| || ,|/
                   |_. └ー┘ ._| ||/
                   ヘ 「 ̄ ̄ ̄| /


561 :名前は開発中のものです。:2009/09/06(日) 16:18:46 ID:RF8wH9Rt
>>557はさすがに誤爆だと信じたいw
トンチンカンにもほどがあるぞw

562 :名前は開発中のものです。:2009/09/06(日) 16:24:53 ID:RF8wH9Rt
>>560はたとえ話や「ぐぐれ」やAAでお茶を濁すので、モヤモヤする。
なぜもっと素直にID:bJbP9YDC氏と話し合えないのか。

563 :名前は開発中のものです。:2009/09/06(日) 16:26:01 ID:0jKZGYOX
stateパターンでググレ
まぁ、やねうらお以外がデザパタ言うとキチガイ扱いされるのよね
不思議

564 :名前は開発中のものです。:2009/09/06(日) 16:27:52 ID:0jKZGYOX
ああ、くやしいから人格非難に走るのか
なるほど

565 :名前は開発中のものです。:2009/09/06(日) 16:38:10 ID:0jKZGYOX
WaitForSingleObject関数すら知らないのか
ID:bJbP9YDC はキチガイだ

566 :名前は開発中のものです。:2009/09/06(日) 16:40:08 ID:0jKZGYOX
やべ ついw

567 :名前は開発中のものです。:2009/09/06(日) 16:44:32 ID:bihVQpPT
>>564
「アンチの想像を絶するアマチュアの妄想テクニックに感じちゃう!くやしい!…ビクン…ビクンッ」www


568 :名前は開発中のものです。:2009/09/06(日) 16:44:51 ID:uHEt6tr/
ヘイヘイ
連投が許されるのは小学生までだぜ

569 :名前は開発中のものです。:2009/09/06(日) 16:52:50 ID:bJbP9YDC
>>565
WaitForSingleObjectはイベント駆動と周期駆動の両方に使えるよね。
だからどうかしたの?どっちにしろ、待機中のことを議論しても意味無いわけで。
プログラムがどういう風に待機するかは興味の範疇に無いな。
他の人もそうだと思うけど。

570 :名前は開発中のものです。:2009/09/06(日) 17:00:39 ID:TTUz744b
>>562
だって…
「おんなのこのからだはそんなもんじゃない。
ぼくが望んでいたのはそんなんじゃない!
ぱんつの中はもっといい匂いがするはず!」
って言われても困るっていうか…

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





571 :名前は開発中のものです。:2009/09/06(日) 17:12:14 ID:bJbP9YDC
俺はお前が周期駆動云々言い出したのみて、
関係ないことをさも関係あるかのように語ってみせるペテンだと確信したよ。
タスクシステムと周期駆動に何の関係があるのか書いてみ?

572 :名前は開発中のものです。:2009/09/06(日) 17:16:45 ID:0jKZGYOX
>>569
おめーいっぺん裁判でもいいから訴えられてみろ
そして法廷で「そんなこと知りません」って言って

お願い

573 :名前は開発中のものです。:2009/09/06(日) 17:18:40 ID:TTUz744b
この子きらい

574 :名前は開発中のものです。:2009/09/06(日) 17:19:43 ID:TTUz744b
>>573>>571のこと

575 :名前は開発中のものです。:2009/09/06(日) 19:20:25 ID:0jKZGYOX
        /:::::::::::::::::::\
       /::::::,,-――-、::::\
      /:::::,/∴∵ )ノ∴\::::ヽ
     l.::::/∴∵∴∵∴∵:l.::::|
     .|::::::|∴∵∴∵∴∵∴|.::::l
     |::::::.ヽ∵(・)∴∴(・)∴/::::::|
     |:::::::::ゝ∴/ ○\∵f::::.::::|
     |::::::::l∵/三 .|三ヽ∵l::::::::|
     t:::::::::'ゝ、___..⊥.___ノ:::::::::/
      t::::::::::::::::::::::::::::::::::::::::::::.j
      l.::::::::::::::::::::::::::::::::::::::::::j
       t:::::::::::::::::::::::::::::::::::::::j
       l:::::::::::::::::::::::::::::::::::::j
        |.::::::::::::::::::::::::::::::::.|
        |::::::::::::::::::::::::::::::.│
       │::::::::::::::::::::::::::::::|
      .. |::::::::::::::::::::::.::::::::|
       .│::::::::::::::::::::::::::::|  
     .   ヽ__:::::::::::::_/

576 :名前は開発中のものです。:2009/09/06(日) 19:58:29 ID:0jKZGYOX
きもちいいお(´;ω;`)

577 :名前は開発中のものです。:2009/09/06(日) 19:59:10 ID:0jKZGYOX
タスクシステム最高

578 :名前は開発中のものです。:2009/09/06(日) 20:01:54 ID:0jKZGYOX
タスクシステム使わないって協調性に欠けるおこちゃまだよね
複数人で開発おこなったことないんだろうね
タスクシステムだと、作業が分散できて便利なんだよな

579 :名前は開発中のものです。:2009/09/06(日) 21:17:14 ID:bihVQpPT
童貞の語るベットマナー云々なんてただのお笑いだっての。

まずゲームを一本、自力で最後まで完成させてみな。
ゲーム製作童貞を卒業できればアンチなんて自然と卒業できる。

「経験なんて関係ない!純粋にテクニックの話をしてるんだ!」って実体験が一度も無い
テクニックなんてただの妄想。

経験のある人間が一目見れば、とんでもないトンチンカンな話延々と続けてるのがバレバレ。
本やネットでいくら知識増やしても童貞は童貞ってのを理解しないとな。

580 :名前は開発中のものです。:2009/09/06(日) 21:36:13 ID:bJbP9YDC
そうやって悪の道へ人を誘うな。
気づいてからでは遅いんだぞ。
これからゲームでも作ってみようかと思ってる奴は、
ぜひ一度はタスクシステムを使わずにゲームを完成させてみて欲しい。
タスクシステム使うのはその後からでも遅くない。

581 :名前は開発中のものです。:2009/09/06(日) 22:03:37 ID:pUyipyQN
まずゲームを二本、自力で最後まで完成させてみな。
ジャンルの異なるゲームを製作すればタスクシステムなんて自然と卒業できる。

「テクニックなんてただの妄想 」って一度切りの実体験に縛られてることに気づけ

経験のある人間が一目見れば、とんでもないトンチンカンな話延々と続けてるのがバレバレ。
本やネットで知識増やさないで自分の中の成功体験だけで突き進むもうとしても35歳で詰むってのを理解しないとな。

582 :名前は開発中のものです。:2009/09/06(日) 22:11:25 ID:TBqzcqpD
>>581
ド素人が偉そうに言っても無駄。

583 :オガワン:2009/09/06(日) 22:23:49 ID:wuQ6DQVW
>>2の見ても何にも分からない。
全然分からない。意味が分からない。理解できない。
だから、タスクシステムっておかしいよ。意味分からないもん。
それでゲームプログラムの王道みたいに言われると虫唾が走るね。
狂ってるよ。OOPも分からない。クラスも分からない。ポインタも分からない。
構造体もめんどくさい。もーやだ、めんどくさいのやだ、プログラムパラダイムを
考えなきゃいけないのやだ。だから、俺は俺のプログラム手法でやるよ。
俺のプログラム。オガワンシステムだ!
狂ってるというのは俺から見たらの話ね、わざわざ小難しいことしなくても
ゲーム作れるもんね俺は俺のオガワンシステムで、そういう意味で狂ってみえる
ということ。
http://loda.jp/rock8/?id=149

584 :名前は開発中のものです。:2009/09/06(日) 22:30:23 ID:uHEt6tr/
キチガイが広めて
現場では老害が使うシステムだからな
しかも、当の本人たちはまったく説明できないときてる
みんな不満が出る罠

585 :名前は開発中のものです。:2009/09/06(日) 22:33:05 ID:TBqzcqpD
>>583
理解力がそんなに乏しくて、社会でやっていけるの?それともニート?

586 :名前は開発中のものです。:2009/09/06(日) 22:38:06 ID:bihVQpPT
まぁ正常位だろうが騎乗位だろうが側位だろうがヤルことはできる。
でもたくさん知ってたほうがいいだろ?相手に合わせていろいろとなwww

タスクシステムもそれ使おうが他の方法だろうがゲームも作れるがね
使い方の一つとして知ってて損になることは無い。ジャンルに合わせていろいろとなwww

ま、アンチ童貞はそれ以前の話ってだけ。

587 :名前は開発中のものです。:2009/09/07(月) 00:08:01 ID:YiXXLcWy
まぁ確かに、自力でゲーム1本作り上げたこと無い人はタスクシステムうんぬん以前の話だね。
なぜアンチ限定なのか不思議だけど。


あと俺はジャンルに合わせてっていうより
2Dシューティングじゃないものを1品でも作ってみと言いたかった。
もし作り方分からなくて頭真っ白になってシューティングに戻りたくなったら
技術者としての腕は上がっていない。
タスクシステム捨てて1から出直そう。

要求分析して図書いて、ちびちび不明点無くしてちびちび設計書にまとめてく、
普通のやり方を身に着ける。いったん入門者に戻る。
これを終えれば規模が増えてもシステム構造が変わっても頭が真っ白になることは無くなるぞ。

588 :名前は開発中のものです。:2009/09/07(月) 01:01:43 ID:YiXXLcWy
>>586
俺アンチだけどずっと前のスレで
 ・タスクシステムがアプリケーションの全体概念および統一実装方法ならばダメ
 ・タスクシステムがアプリケーションの一部を実装するための方法の一つなら許容
って話も出てた。最近のスレのことは俺が読んでないので知らない。

>使い方の一つとして知ってて損になることは無い。
これは大抵のアンチも許容すると思う。くどいようだけど純粋に実装方法の一つとしてなら。
あと「思想ではなく実装方法の一つならデザパタで定義されてるの使えばいいじゃん。なぜローカル用語?」
というのもアンチから出てた気がする。

つまり
 1、統一思想という捉え方でタスクシステムを持ち出すとアンチが出ます。俺とか。
 2、実装方法として捉えつつも結局アプリ全体で統一してタスクシステム使っちゃってても出ます。
 3、実装方法として捉えて実際アプリの一部分について選択の下にタスクシステム使ってるなら出たり出なかったりします。
   出た場合は入門以前の人か、「一部分の実装方法なのにシステム?。実装方法ならデザパタで言えよ」とか

その後「人によってタスクシステムの定義が曖昧でデザパタで言い換えるとなかなか合意取れんね」
ってとこまで話が進んだが人格批判厨が発生して数スレに渡って粘着したのでうやむやになってた希ガス。
入門以前の人しか居ないわけでは無い、と思う。

589 :名前は開発中のものです。:2009/09/07(月) 01:07:10 ID:FRcPU02K
ゲーム作れないとか作ったことがないとか、C++わからないとか、boost知らないとか、
デザパタ正しく理解してないとか、ゲーム業界で働いてないとか、他人と協調的にゲームの製作作業をしたことがないだとか、
2Dのゲームしか作ったことがないだとか、5タイトルぐらいしか作ってないだとか、そういうゴミクズみたいな人をすべて排除しないと
まともな議論なんて出来ないよ。

590 :名前は開発中のものです。:2009/09/07(月) 08:03:12 ID:Ok+syAIu
つまりタスクシステムと言うのは上級者向けの実装方法ってこと?

591 :名前は開発中のものです。:2009/09/07(月) 12:26:53 ID:6JK5/sYq
いや、裸の王様向けってことだよ。

592 :名前は開発中のものです。:2009/09/07(月) 14:51:19 ID:obaxvSRN
>>589
まともな議論を望んでる人がどれだけいるか。
まともな議論をしたくない人に対して
まともな議論をしようと試みるのはお互いに不幸だ。

593 :名前は開発中のものです。:2009/09/07(月) 15:10:19 ID:EtB4ix4s
>>589
お、クールな人が来てるねぇ。

技術の話ってのは、やっていくノウハウ、
食っていくノウハウに直結するんで、
隠したいと思う奴がいても不思議じゃないし、
また、隠すがゆえに野暮ったいシステムは、
いつまでたっても改善されなかった、
ということだとしても不思議じゃない。

594 :名前は開発中のものです。:2009/09/07(月) 15:11:13 ID:EtB4ix4s
おっとミスった。クールな人とは>>592のことな。

595 :名前は開発中のものです。:2009/09/07(月) 17:41:13 ID:7CtXwC6H
未だにタスクシステムを採用するメリットが見えてこない

596 :名前は開発中のものです。:2009/09/07(月) 18:29:19 ID:Hp9QXKEe
>>593
相手は情報を隠したがっているという前提では
ほとんど全ての主張は信用できないことになる。
アンチは優れたものに他人が興味を持たないようにするため
信者は役立たずなものに他人が興味を持つようにするため
それぞれ行動しているのかもしれない。

597 :名前は開発中のものです。:2009/09/07(月) 23:34:57 ID:qwKYGu22
別に情報を隠したがってるわけじゃないんだけど
タスクシステムという得体の知れない謎キーワードに幻惑されて
変な夢を追いかけてる童貞君がちょっと哀れに思えたので
さっさとパンツおろして股を開いて綺麗なナニを見せたげただけ

そしたら

『俺をバカにするな。俺が夢想してたのはそんなちっぽけなトコブシじゃない』
『むしろお前の母ちゃんのパンツ寄越せ!匂いを嗅いで採点してやる』

みたいなこと言いやがる

失礼しちゃうよね。ババァの汚ねぇアワビ汁が付いたパンツが見たいとか
ただの変態でしょ。死ねばいい

598 :名前は開発中のものです。:2009/09/07(月) 23:51:17 ID:qwKYGu22
例えばtime driven cyclic executive とかでググれ。利点も欠点も詳細に解説されてる
タスクシステムなんてキーワードでググるよかよっぽどタメになるお話が読めるはず

599 :名前は開発中のものです。:2009/09/08(火) 00:23:46 ID:pazi8cW7
まとめサイト作ったよ。
過去ログとか保守するよ。

http://tasksystem.blog61.fc2.com/

次回からテンプレに追加よろしく。
欠番datファイルも誰か頂戴。。

600 :名前は開発中のものです。:2009/09/08(火) 00:29:20 ID:pmhwd1Ha
得体の知れないゴミクズ野郎のwikiなんて絶対嫌だな
gamedev wiki使えよ
http://wiki.game-develop.com/index.php

これ使わない理由を説明しろ。合理的に


601 :名前は開発中のものです。:2009/09/08(火) 00:31:44 ID:OYn/paam
>599
イラネ

602 :名前は開発中のものです。:2009/09/08(火) 00:37:22 ID:OYn/paam
あ、イラネっていうか作るならゲムデブWIKIのほうにしてくれ。かな?
ゲムデブWIKIを意図的に避ける奴は何かしら胡散臭いよ
他スレのまとめ厨を観察してきた経験から

603 :名前は開発中のものです。:2009/09/08(火) 00:40:37 ID:pazi8cW7
ごめん知らんかっただけだ。移行する

604 :名前は開発中のものです。:2009/09/08(火) 00:42:34 ID:PLYTfgj9
よくわからんが公式のウィキがあるなら使えばいいんじゃない?
あえて使わない理由がよく分かんない

605 :名前は開発中のものです。:2009/09/08(火) 00:43:58 ID:PLYTfgj9
>>603
ごめんかぶったすまん

606 :名前は開発中のものです。:2009/09/08(火) 00:47:04 ID:OYn/paam
>603
有難い。乙であります

607 :名前は開発中のものです。:2009/09/08(火) 00:50:18 ID:pmhwd1Ha
うむ。俺がゴミクズ野郎だったようだな。悪かった >>603

そして乙カレ(・∀・)チャーン

608 :名前は開発中のものです。:2009/09/08(火) 00:57:06 ID:pazi8cW7
gamedev wiki 見てきたけど、真面目そうなサイトだったから、汚すのいやだな。
なんか空気違うし、過去ログとか置く感じじゃないし、どうしたものか。
 タスクシステム(隔離) という項目作って、そんなかで色々するか。
タスクシステムを体系的に分別したり、タスクシステムの歴史書いたり、大変そうだなぁ。
過去ログだけ保守できりゃ良いと考えていたのだが。
明日一日考えるわ。

609 :名前は開発中のものです。:2009/09/08(火) 01:03:51 ID:pmhwd1Ha
公式のうpろだがある。gamedev wikiのtoppage参照

予備ロダ
http://gamdev.hp.infoseek.co.jp/
ゲムデヴあっぷろーだ
http://gmdev.xrea.jp/

wiki使うの面倒ならログファイルだけここにうpるという手もある


610 :名前は開発中のものです。:2009/09/08(火) 01:13:46 ID:pazi8cW7
機能A:登録された処理を順次実行する
機能B:処理の順番を制御する
機能C:処理のコンテキストを保持する
機能D:検索できる
機能E:プール
機能F:デフラグ
機能G:GC
機能E:生存の管理

こんな風にありがちな機能を定義しておいて、
スレで、ABCDEのタスクシステムは〜と書けば、
自分の想定するタスクシステムが明確になって良いかも知れない。
ちなみにA〜Eは、Aに近づくほど制御寄り、Eに近づくほどデータ寄りになるように纏めてある。

611 :名前は開発中のものです。:2009/09/08(火) 01:16:06 ID:PLYTfgj9
過去ログをそのアップローダにあげておくだけでいいんじゃない?
まとめサイトとか作られても主のスキル・立場でフィルタ・バイアスかかるし
なんか不毛な予感しかしない

612 :名前は開発中のものです。:2009/09/08(火) 01:23:35 ID:lPudf9Xw
タスクシステムライブラリで十分

613 :名前は開発中のものです。:2009/09/08(火) 01:34:27 ID:pazi8cW7
タスクシステムの機能を体系化することで、
それぞれの機能のメリットとディメリットも浮き彫りに成ってくるだろう。
不毛な議論をする余地もなくなり、このスレは終焉しちゃうかもしれない。
だからやっぱり駄目かもしれない。枯れ木も山の賑わい。

>>609
流れるまでの期間が不明で怖いな。
誰も使ってなさそうだから、1年ぐらいは持つかな。

>>611
ここの民度でwikiやったら荒らされそうという問題も。
過去ログだけUPってのが現実的かもしれないな。
ただ、現時点でまともなタスクシステムサイトが一つも無いというのも考え物。
まともなタスクシステムサイト作ると、その時点でタスクシステムが終焉するという話も。
参考資料:http://ja.wikipedia.org/wiki/%E6%B0%B8%E4%B9%85%E6%A9%9F%E9%96%A2

614 :名前は開発中のものです。:2009/09/08(火) 01:46:11 ID:pmhwd1Ha
>>613
流れねーよ心配すんな

615 :名前は開発中のものです。:2009/09/08(火) 02:48:00 ID:hOd0h4O6
>>610
>>613
なんか厨くさいな。しかもかなり特徴的なやつだ
どっかで嗅いだことのある臭いだ

「確定させたい」っていつも繰り返してた確定乞食
自動並列化を意識したタスクシステムを作ったよ君=タスクシステムはDBだ君
タスクシステムはファイルシステムだ君
ゲームが作れないID:bJbP9YDC

616 :名前は開発中のものです。:2009/09/08(火) 02:54:54 ID:3SvCrSim
>>588
その辺の経緯は知らないが俺は定義が無いぞ厨かな。

合意が無いなら無いでせめて勝手定義を示してから
本題を語れば技術的で有意義な議論ができるかもしれないのに
論拠も論理展開も飛ばして結論だけ出してくる人がほとんどだ。

詭弁や人格攻撃を仕込んだ釣り針で馬鹿にする相手を
探していると思しき人がいるのは2chだからしかたない。
俺もそんな人のことを悪く言える立場じゃないし。
でも真面目な話ができなくてもどかしい思いをしてる人はもったいない。

617 :名前は開発中のものです。:2009/09/08(火) 03:32:35 ID:KA/zQxOQ
>>616
> でも真面目な話ができなくてもどかしい思いをしてる人はもったいない。

そんな人は過去のスレ見て、とっくに結論出してるんじゃないの。
情報なら十分にあると思うけど。

618 :名前は開発中のものです。:2009/09/08(火) 04:21:56 ID:OQ7DvyVy
なんで、英語できるのに日本にくるの?
嫌味?

619 :名前は開発中のものです。:2009/09/08(火) 04:56:18 ID:YN+0s+np
>>617
過去スレから見出せる範囲の結論で満足ならいい。
>>618
英語の話はよく荒れる。わかってて書いたんだろうけど。

620 :名前は開発中のものです。:2009/09/08(火) 22:06:30 ID:qfhGmTG1
>>593
> 相手は情報を隠したがっているという前提では

隠したいと思う奴がいても不思議じゃない、と言ったまでのこと。

> ほとんど全ての主張は信用できないことになる。

なぜ?w

> アンチは優れたものに他人が興味を持たないようにするため
> 信者は役立たずなものに他人が興味を持つようにするため

だろうがなんだろうが、隠しさえしなければ、
発言さえしていれば、あとは信頼に足るかどうかはいつも読み手の判断。
発言者の背景ではなくて、あくまでここは内容ではかるべき。

621 :名前は開発中のものです。:2009/09/08(火) 22:07:31 ID:qfhGmTG1
>>593じゃなくて>>596な。

622 :名前は開発中のものです。:2009/09/08(火) 22:26:41 ID:pazi8cW7
ところで、pukiwikiに2chの過去ログをhtml形式で貼り付けたいんだけど、
どの変換ツール使えばよい?

623 :名前は開発中のものです。:2009/09/08(火) 22:42:08 ID:TS6rFcbG
ID:pazi8cW7
つーか誰なのこの人?ゲブデブWikiがあるんだから別に使えばよくね?
こいつがしつこく自前のブログスペースとかwikiスペースを借りることに
こだわる理由を誰か解説してくれ

624 :名前は開発中のものです。:2009/09/08(火) 22:45:05 ID:qfhGmTG1
そりゃおめー、アクセス状況の把握にきまってんだろ。
リモートホストと時間帯の把握っしょ。

625 :名前は開発中のものです。:2009/09/08(火) 22:46:50 ID:TS6rFcbG
つかあぷろだもあんのかよ

ログ嫁 → ●ないから見れない → あぷろだにあるからDLして嫁
これで十分じゃね?

626 :名前は開発中のものです。:2009/09/08(火) 22:48:48 ID:TS6rFcbG
>>624
だよなぁ。なんかもう臭すぎるんだよな

627 :名前は開発中のものです。:2009/09/08(火) 22:59:04 ID:pazi8cW7
だから、ゲブデブWikiがpukiwikiなんだよ。

628 :名前は開発中のものです。:2009/09/08(火) 23:07:50 ID:pmhwd1Ha
>>627
サクっとうpろだにあげとけって。それで十分だろ

まぁなんだ。くだらねーことグダグダ相談して話題逸らしてねーで
>>598でググってお勉強した成果を見せたまえよ

629 :名前は開発中のものです。:2009/09/09(水) 02:11:32 ID:HhqWkj5Y
>620
> 発言者の背景ではなくて、あくまでここは内容ではかるべき。

それができれば理想なんだよな。せめて事実と意見の区別くらいしてほしい。
検証不可能な意見だけを書いて、それに賛成か反対かで敵味方を線引きして、
宗教戦争ごっこになるのが現実の定番の流れ。

630 :名前は開発中のものです。:2009/09/09(水) 04:18:08 ID:9x3G7h9G
過去スレ見たが、アンチのほうは、圧倒的に初心者が多いね。
ゲーム本当に作れるの?っていうレベルの人がほとんど。

631 :名前は開発中のものです。:2009/09/09(水) 06:29:54 ID:rON4Oh90
>>630
お前みたいなレスするクズをどうやって叩きだすのかが重要だなw

632 :名前は開発中のものです。:2009/09/09(水) 08:07:33 ID:9x3G7h9G
>>631
お前みたいなゲームすら作れない自称プログラマを
このスレから締め出すのが先決だと思うよ。

633 :名前は開発中のものです。:2009/09/09(水) 08:19:23 ID:dVTV3ErZ
実に綺麗な「売り言葉に買い言葉」の例ですね

634 :名前は開発中のものです。:2009/09/09(水) 08:33:21 ID:IkPAp/Q9
>>630 エスパー乙

635 :名前は開発中のものです。:2009/09/09(水) 11:31:49 ID:ps4Ud/dF
>>2
のリンク先の説明でゲーム作る目的でのタスクシステムの説明としては十分な気がするけど・・・
そんな分類しないといけないほどタスクシステムってたいしたものか?

この程度のものがチンプンカンプンでもっと手取り足取り教えてくれないとわからない!ってのは
自分の頭で考える、とかわからないことは試してみる、とかプログラマとしての素質というか
もっと根本的なところが問題な気がする。

そこまでレベル下げて親切丁寧に説明したとして、ゲームのプログラムしてればタスクシステム
なんかよりもっと難しいこと自力で解かなきゃいけないケースはいくらでもあるんだから・・・

まぁ、ゲーム作る目的じゃなくてあくまで議論のためのだけの分類、って感じなんだろうけど。

636 :名前は開発中のものです。:2009/09/09(水) 14:07:51 ID:TJscpvFZ
↑こういう奴に限って、わかったような気になって満足してるだけの奴。
いざとなったら目が泳ぐ。

637 :名前は開発中のものです。:2009/09/09(水) 14:47:38 ID:SozIkD8l
なんか釣り糸同士が絡まってる…

638 :名前は開発中のものです。:2009/09/09(水) 16:49:34 ID:MuEf1f80
そんなに煽られたら感じちゃう・・・ビクッビクッ

639 :名前は開発中のものです。:2009/09/09(水) 20:44:40 ID:MuEf1f80
あえて!
あえて言おう!

めんどくさい!と

640 :名前は開発中のものです。:2009/09/09(水) 20:54:52 ID:P2GFnk3d
相変わらず
どこでバグったのかわからん実装してんだな
ちゃんと引数通せよ(笑)
ポインタなんて保持しちゃ駄目だぞ

641 :名前は開発中のものです。:2009/09/09(水) 21:08:55 ID:ZzMWpGbf
ゲーム以外では使われないってことは、
そんなに優れたやり方では無いってことだよ。

642 :名前は開発中のものです。:2009/09/10(木) 22:42:40 ID:LMnNWMto
やーい裸の王様だーとはしゃいでいた狼少年は狼に食われて死んだか?
>>598のキーワードでぐぐった感想を聞かせてくれや

643 :名前は開発中のものです。:2009/09/10(木) 23:17:09 ID:wuqNFPOS
>>642
突然何を言い出すのか意味不明
何がいいたいのかきちんと説明しろ

644 :名前は開発中のものです。:2009/09/10(木) 23:22:20 ID:FGzZFzuf
相手しなくて良いよ。
居場所が無いとか、死に場所を求めてるとか、そう言う話でしょ。

645 :名前は開発中のものです。:2009/09/10(木) 23:24:15 ID:wuqNFPOS
せめてタスクシステムの話しろよなw

646 :名前は開発中のものです。:2009/09/10(木) 23:25:13 ID:oTBWMZbN
>>642
アンチをこれ以上追い込むのはやめてください。可哀相でしょ

647 :名前は開発中のものです。:2009/09/10(木) 23:32:46 ID:FGzZFzuf
でも、タスクシステム総合スレ創設当初の勢いはもう無いでしょ。

648 :名前は開発中のものです。:2009/09/10(木) 23:38:39 ID:ouJOE5Kg
>>642
このスレが一番上に来るんだが

649 :名前は開発中のものです。:2009/09/10(木) 23:41:03 ID:wuqNFPOS
>>648
よく探せよ
まさか、君、見えない・・・とか言わないよね?w

650 :名前は開発中のものです。:2009/09/10(木) 23:44:19 ID:UiLtjgrN
アンチはバカだから1(キャラ)オブジェクト=1Taskという勘違いをしてそうだな
松浦本とか読んでるだけのアマチュアなら仕方ないけど

651 :名前は開発中のものです。:2009/09/10(木) 23:48:54 ID:ouJOE5Kg
タスクシステムのメリットとしてメインルーチンを
イテレータ風に書ける事をあげていた人もいるけど
マルチコアマルチスレッドが当たり前となった今、
メインルーチンはどう書くべきなのか?

652 :名前は開発中のものです。:2009/09/10(木) 23:55:09 ID:oTBWMZbN
アンチの攻撃対象っていつもCodeZineとかのヘッポコシステムばっかりなんだよね
あれってタスクシステマーから見てもダメダメなわけで、だからCodeZineの記事を
教科書的に引用してブログ書いてたやねうらおはタスクシステマーに攻撃されてたよね

引数くんが喚いてるときもたいていはCodeZineを引き合いに出してるんだよね

653 :名前は開発中のものです。:2009/09/10(木) 23:56:43 ID:FGzZFzuf
メインルーチンがイテレータ風って(笑
メインルーチンってそのプログラムで一番大事なところなのに、
そこをイテレータ風に書かなきゃならない制限勝手に設けて誰が得するのよ。
なにその自分ルール

654 :名前は開発中のものです。:2009/09/10(木) 23:57:48 ID:LMnNWMto
>>650
まぁそれはCマガとか読んで信者になった若い世代にも言えることだけどな

655 :名前は開発中のものです。:2009/09/11(金) 00:00:48 ID:FGzZFzuf
処理をリストに突っ込んで、優先順位でどうのこうのという時点で既に糞だということ。

656 :名前は開発中のものです。:2009/09/11(金) 00:09:10 ID:CngAv55G
おつむに糞がつまった残念な子は自分に必要ないものは糞という。
でもそれは視野が狭くて理解力と想像力が乏しい己自身の問題なのね。
理解できない対象に責任を転嫁して癇癪を起こされても困るのよ

どうしてわからないことが存在することが気に入らないの?


657 :名前は開発中のものです。:2009/09/11(金) 00:14:17 ID:3g6HJTW7
そう、そのとおり。だから、誰かさんの相手はして無い。

658 :名前は開発中のものです。:2009/09/11(金) 00:23:17 ID:10h7AwoA
つ裸の王様

659 :名前は開発中のものです。:2009/09/11(金) 00:53:24 ID:3g6HJTW7
裸、ありのまま、すばらしいじゃないか。
プログラムもそうあるべきだね。素直な設計が一番。

660 : ◆HSP4mee/SU :2009/09/11(金) 00:54:24 ID:HWTFqcXr
>>598
http://books.google.co.jp/books?id=drlsKjcw3xQC
http://www.embedded.com/story/OEG20010222S0038

これいいね。。。英語は苦手だけどexciteを駆使して楽しく読ませてもらってる
この間、通信機器メーカーに勤めてるOBの人が組み込みプログラミングの講座を
開いてくれたんだけど、その内容の更に詳しい版って感じがする。その講座の中では
スレッドが用意できないような貧弱な制御ボードで複数のジョブ(タスク)をまわしたり
ISRが起動するジョブ(タスク)を挟み込んだりしなくちゃならないときに使うテクニックを
さらっと紹介してくれてたんだけど、あーなるほどこういうことだったんだな
携帯ゲーム機のゲーム作ってる人はこういうの必要なのか?大変だな

まぁでも個人でWin用の同人ゲを配布してるだけの俺にとっては配列でベタ書きが最強だな
趣味でタスクシステムとかマジでねーわwwタスク信者とかほんとアホだなwww
タスクディスパッチャーなんて挟み込む必要全くねーだろバーカ。氏ねゴミクズ

661 :名前は開発中のものです。:2009/09/11(金) 01:13:02 ID:kqHsoKS/
>>652
> だからCodeZineの記事を教科書的に引用してブログ書いてた
> やねうらおはタスクシステマーに攻撃されてたよね

やねうらおは、CodeZineの記事を引用したなどという事実はないし、
やねうらおは、タスク派の攻撃されていたという事実もない。

662 :名前は開発中のものです。:2009/09/11(金) 01:23:54 ID:10h7AwoA
よくわからないけど>>598が強烈な返り討ちにあったの?

663 : ◆HSP4mee/SU :2009/09/11(金) 01:33:27 ID:HWTFqcXr
最近このスレほとんど読んでないんでアレだけど>>650>>654を読んで更に思ったこと

>1(キャラ)オブジェクト=1Taskという勘違い

そうかなるほど。感動した。CodeZineがただの自機・敵・弾のごった煮連結リストだったから
過去スレでボッコボコにぶっ叩いてしまったわけだが(不本意だったが)、あの記事は
タスクシステマーから見ても「?」だったのか
単なるエンティティの連結リストをタスクシステムと有難がってる記事が「狂ってる」
ということなら納得だ。そして欠陥アロケータを癒着させたり不定期に発動する
メモリコンパクション機能付けたりとヘンテコ機能をベタベタ付着させて必死に脚色して
なんか強そうに見せてるものが全て後付けの贅肉分だったわけか。それならなら納得だ

巷に転がってるタスクシステムとやらの贅肉分をとっぱらったら
>>660のリンク先の資料でいうところのtime-triggeredなcyclic executiveだとか
multi-ratedなものだとか割り込みが絡むものだか、そういうものになるというなら納得だ

なんだよ。結局タスクシステムなんて胡散臭い用語を駆使しなくてもちゃんと汎化して
説明できる代物だったんじゃないか。ほんとお前らタスクシステマーってやつは酷いよな

タスクシステムはバズワードとはよく言ったもんだな。俺はタスクシステムの元々の役割?
本旨?とやらには全く罪はないと思う。タスクシステムという怪しげーな単語と、それに
まとわり付く魑魅魍魎・趣味タスク信者が生成する脂肪肝腐れシステムが腐敗臭の原因だな

664 :名前は開発中のものです。:2009/09/11(金) 01:42:18 ID:CngAv55G
>>660
エクセレント

665 :名前は開発中のものです。:2009/09/11(金) 02:49:17 ID:bWGyFb/B
不定期に発動するメモリコンパクション機能って何のことだ?

666 :名前は開発中のものです。:2009/09/11(金) 21:54:18 ID:10h7AwoA
javaのあいつが真っ先に浮かんだ

667 :名前は開発中のものです。:2009/09/12(土) 00:48:47 ID:trXx+E3M
そもそもタスクシステムってメモリ確保と解放の概念ってないよな?

668 :名前は開発中のものです。:2009/09/12(土) 00:56:38 ID:wzwbYpLB
基本ある程度のメモリ最初に確保しといてそこから使ったりしてるでしょ
俺は面倒だから確保解放繰り返してるけど

669 :名前は開発中のものです。:2009/09/12(土) 01:09:27 ID:baoq7HG4
>>667
実装によってはそこらの処理をごっちゃにしてるやつもあったりするんで、
「タスクシステムって」と問われてもなんとも言えないのがタスクシステムクオリティ。

670 :名前は開発中のものです。:2009/09/12(土) 02:42:50 ID:JBU+WF48
タスクシステムの特徴「単純な仕組みなのでゲームの仕様毎にカスタマイズできる、というかしなきゃ使えん」
ってのが、ある種の人たちにとって混乱の元で我慢ならない所なんだろう。

一つの原理!一つの実装!応用?柔軟?そんなものは異端だ!って理想主義者・原理主義者タイプ。

見た目がそれらしく見えて処理落ちしなくてマスターに間に合えばどんな手段でも使うぜ!
って土臭い現実主義が求められるゲームプログラマには向かないタイプだけど。

671 :名前は開発中のものです。:2009/09/12(土) 03:21:44 ID:baoq7HG4
なんで「一つの原理・一つの実装」と「応用・柔軟」を両立すればいいと考えないの?
両立できないと思い込んでるだけじゃないの?
そう思い込んでるからタスクシステムで満足しちゃってるんじゃないの?

672 :名前は開発中のものです。:2009/09/12(土) 04:04:49 ID:JBU+WF48
>>671
おーすばらしい。
「一つの原理・一つの実装」で「応用・柔軟」のあるシステムを実現できるんだ。
そんなのがあればタスクシステムなんて使わずに全てのゲームはその実装一つで作れるね。
ささ、早くそれを見せてくれwww

それとも今は存在しないけどいつかどこかの天才がきっと実現してくれる・・・はず。って?
まさしく理想主義者・原理主義者タイプ。

現状を受け入れて結果を出すことと、現状に満足してることの違いくらいはわからないとね。

673 :名前は開発中のものです。:2009/09/12(土) 04:34:09 ID:+5KbEzRZ
>>671
満足してないから「一つの原理・一つの実装」を否定してるんだろ。

「一つの原理・一つの実装」批判はむしろタスクシステムに
向けられてるじゃん。たとえば >588
それなのに「一つの原理・一つの実装」を目指さないのは
タスクシステムに満足してるからなんて詭弁もいいとこだよ。

>>672
タスクシステムなんかに満足してるからわからないんだよ、で終了。

674 :名前は開発中のものです。:2009/09/12(土) 08:55:45 ID:U9nhXrP+
一つの原理ってのは、まさにタスクシステムの事だと思うがな。
たとえば、
全ての処理をタスクシステム上のタスクで統一してみたりとか、
メインループを固定化してみたりとか、
タスクのエントリー(update関数)の引数が固定だったりとか、
タスクの順序をプライオリティーで管理してみたりとか。
それらの統一は、俺には制限にしか感じられないのだが。

675 :名前は開発中のものです。:2009/09/12(土) 09:03:13 ID:U9nhXrP+
タスクシステムって、リストになった処理をCPUが前から順番に実行していくものだけど、
これに条件分岐と繰り返しとジャンプを付け加えれば、もうバーチャルマシンさながら。
といえば、如何に無駄なことをしているか分かってもらえるだろうか。

676 :名前は開発中のものです。:2009/09/12(土) 09:10:10 ID:XapPeWp5
信者「そもそもの成り立ちは〜」
懐疑「で、今日びメリットあんの?」
信者「え〜、そもそもの成り立ちは〜」
懐疑「だから、メリットあんの?」
信者「成り立ちをぐぐれ><」
懐疑「( ゚д゚) ポカーン」

677 :名前は開発中のものです。:2009/09/12(土) 10:45:47 ID:D6Mri7di
>>674
> 一つの原理ってのは、まさにタスクシステムの事だと思うがな。
タスクシステムは一つの実装では無いわな。
一つの実装を求めるかどうかがアンチかどうかの分かれ道。

678 :名前は開発中のものです。:2009/09/12(土) 10:48:52 ID:U9nhXrP+
「一つの実装」ってなによ。頭おかしいんじゃない?
デザパタですらそんなのありえねぇ。

679 :名前は開発中のものです。:2009/09/12(土) 11:01:55 ID:v1Yqy+M5
こんな風に日本語ができない奴が
実務に投入されてっから後から入る奴にはとてつもなく厳しいのね

680 :名前は開発中のものです。:2009/09/12(土) 11:21:19 ID:D6Mri7di
>>678
そうそう、頭おかしくなきゃありえないよねwww

681 :名前は開発中のものです。:2009/09/12(土) 11:32:08 ID:U9nhXrP+
ついに敵味方の区別もつかなくなったか。

682 :名前は開発中のものです。:2009/09/12(土) 11:58:20 ID:U9nhXrP+
ややこしくなってきたので、まとめとく。

ID:D6Mri7diは>>674を読んで、
全てのタスクシステム同士のタスクのエントリー(update関数)の引数が固定になると解釈した。
そんな解釈の発想が沸いてくる時点で既に狂ってるだろうというのが>>678

言うまでもなく、「エントリー(update関数)の引数が固定になる」の影響範囲は、
「全てのタスクシステム」ではなく「そのプログラム内」。

そのプログラム内で、全ての処理をタスクシステム上のタスクで統一されるのが嫌。
そのプログラム内で、メインループが固定されるのが嫌。
そのプログラム内で、タスクのエントリー(update関数)の引数が固定されるのが嫌。
そのプログラム内で、タスクの順序をプライオリティーで管理するのが嫌。
そのプログラム内で、それらの統一は、俺には制限にしか感じられない。

683 :名前は開発中のものです。:2009/09/12(土) 12:39:40 ID:v1Yqy+M5
役に立たないので嫌

684 :名前は開発中のものです。:2009/09/12(土) 12:41:28 ID:JMWfQLfh
>>682
たまたま(曖昧とはいえ)タスクシステムは名前がついているから
それにとらわれて決められた制限に感じてるだけじゃね。
だいたい名前が悪いし、タスクシステムと呼ぶのを止めれば
もっと冷静で柔軟に見られるんじゃないの。

685 :名前は開発中のものです。:2009/09/12(土) 13:31:30 ID:D6Mri7di
>>682
「タスクシステム嫌い」の一言で済む内容だな。

しかしその条件だと・・・
タスクシステム以外でも、商用含めゲーム用統合エンジンは全滅だなwww

686 :名前は開発中のものです。:2009/09/12(土) 13:48:10 ID:v1Yqy+M5
さぁ、凄腕プログラマが現れました

687 :名前は開発中のものです。:2009/09/12(土) 15:36:19 ID:lX3ERFWA
>>685
プロお断り。同人、アマチュア限定のスレで
商用ゲームエンジンの話なんてするなよ。

688 :名前は開発中のものです。:2009/09/12(土) 15:57:07 ID:U9nhXrP+
ゲームエンジンで成功している例って、何よ。
アンリアルエンジンとかか?
なんにせよ、コールバックは乱用すべきでない。

689 :名前は開発中のものです。:2009/09/12(土) 17:47:36 ID:7ZSZflR2
乱用すべきでない(キリッ

乱用ってなんだよ

690 :名前は開発中のものです。:2009/09/12(土) 19:20:25 ID:lX3ERFWA
>>688
そうそう。
アマチュアにはゲームエンジンなんて関係ないしな。
よ!アンチの鏡www

691 :名前は開発中のものです。:2009/09/12(土) 19:58:54 ID:wlOa8NkW


692 :名前は開発中のものです。:2009/09/12(土) 19:59:07 ID:BV/1PbdD
>>690
自分で説明もできなくて他のPGにいつもでおんぶでだっこのクズPGならいくらでも現場にいるけどな
別にプロだから何ってのはないなw
クズはどんな会社にいってもクズ
そしてどんな会社にもきっとクズはいる(大手5社経験アリ、任天堂はない)

693 :名前は開発中のものです。:2009/09/12(土) 20:36:17 ID:nOtoYr29
>>692
大手5社ねぇ
まぁ人の出入りは激しい業界だし、俺も転職経験あるけど
普通2〜3社で役職つくなりプロデューサーになるなりして落ち着くもんだけどな。有能なら会社が手放さんし。

数年毎に職場変えるタイプも何人か見てきたけど
周りから次はこいつと一緒に仕事したくないって思われて、次のプロジェクトでお声がかからなくて
居場所が無くなって出てくタイプばかりだったな。

「俺はこんな有能なのに周りはクズばかり!俺の有能さを見抜けない上役もこんな会社もクズだ!」
って捨て台詞残して消えていった人を数人しってるよ。

694 :名前は開発中のものです。:2009/09/12(土) 21:25:29 ID:v1Yqy+M5
さぁ、タスクシステムはもはや関係なくなってきて
自分の自慢話に熱が入ってきました

695 :名前は開発中のものです。:2009/09/12(土) 21:36:57 ID:BV/1PbdD
>>693
だってフリーだよもんw

696 :名前は開発中のものです。:2009/09/12(土) 21:47:49 ID:nOtoYr29
>>695
あぁすまん。派遣か。
それならよくあることだ。

697 :名前は開発中のものです。:2009/09/12(土) 22:59:48 ID:Su1dcMt0
マ板でやれ

698 :名前は開発中のものです。:2009/09/13(日) 01:00:41 ID:fqn+gvZk
>>696
派遣じゃないな
若いときは同時に2つの会社の仕事を請けるとかやってたけど
もうそんなことはできねw

699 :名前は開発中のものです。:2009/09/13(日) 01:25:14 ID:pl2tqWb2
>>698
著名な漫画家とか作曲家なら個人相手に契約するけど、個人契約のプログラマは今まで見たこと無いな。
中小デベロッパはともかく、大手で法人の派遣会社を通さずに直接個人のプログラマに仕事振ったりなんて無いんでない?

うちでは区分的にプログラマは正社員・派遣・外注で自称フリーは派遣の区分にはいってるし。
まぁ派遣会社がそのプログラマにどう説明してるかは知らんけど。

んでも正直派遣プログラマは使いずらい。
見せられないコードの区分けとか社内データへのアクセス制限とか、余計な管理業務が出てくるし
マスター伸びると契約期間の問題でデバッグ途中で居なくなったり。
なんで正直UIの量産箇所とかイベントのスクリプト部分とか、誰でも出来る表層部分以外は任せられない・・・

700 :名前は開発中のものです。:2009/09/13(日) 01:41:17 ID:fqn+gvZk
>>699
一応会社名で請け負ってるよ
実は1人なんです〜w的なw
外注といいつつね
ゲームPGの最終形態・・・だったけどいまはやめたほうがいいな
仕事もねーけどなによりギャラが糞
業務のがいい金だすよ(これは昔からだけど)

税金ぐらいか?フリーでいいところって

701 :名前は開発中のものです。:2009/09/13(日) 01:53:26 ID:3+kk58+r
>>700
おめぇの食い扶持についてはそんぐらいにして
過去発言のアンカーでも張ってくれや

702 :名前は開発中のものです。:2009/09/13(日) 01:59:52 ID:pl2tqWb2
>>700
独り身で20代ならそれもいいかもね
しかしプログラマ一人で外注ってほんと?

うちで外注出す場合は企画と仕様はこっちで後は絵も音も出来る中規模デベロッパに出す。
プログラム、絵、音、とか別々に外注に出してたら管理業務が煩雑になりすぎて
やってられんと思うけど・・・

まぁうちは一番小さい開発規模でもDS・PSPクラスだから、もしかしたら携帯アプリとかやってる
ところはそんなやり方してるのかもしれんけど。

703 :名前は開発中のものです。:2009/09/13(日) 02:04:18 ID:fqn+gvZk
>>702
昔は3人いたしねw
いまも名目3人だけど1人はねーちゃんで
もう1人は友達(別の職ついてる)だしねw

704 :名前は開発中のものです。:2009/09/13(日) 02:08:07 ID:pl2tqWb2
>>703
知ってる範囲ではなんかリアリティが無いんだが。
PS1時代ならともかく、その人数で何ができるの?
うちの扱ってない携帯アプリかIPhoneとかそっち系か・・・?

705 :名前は開発中のものです。:2009/09/13(日) 03:25:35 ID:fqn+gvZk
>>704
PGなんて無能が何人いたって邪魔にしかなりゃしないよ
それに昔からやってるから色々ストックがあるからね
仕様によっては工数1Hで納品・・・とかできるよ
そーゆーのわかってる相手だと頼みやすいでしょ?
今、新規でっていうのは難しいだろうなー
あくまで昔からの付き合いだね

706 :名前は開発中のものです。:2009/09/13(日) 03:34:50 ID:pl2tqWb2
>>705
PGの人数じゃなくてデザイナとサウンドの話なんだけど。
工数1Hとか、ゲーム業界の外注、というかデベロッパとは何かずれてる。
プログラマだけで完結してるIT業界の話みたい。

それに昔からの付き合いで大手5社って・・・
ほんとにゲーム会社の外注したことあるの?

707 :名前は開発中のものです。:2009/09/13(日) 03:44:29 ID:fqn+gvZk
>>706
そりゃね
ゲーム業界潤ってたときに色々仕事したからね
だいたい外注の人間の人数なんて把握してるのかね?
オタクの担当者にしてもw

昔はなんの仕事もしないで右から左に仕事を渡すだけでお金が入ってきてた時代もあるよ

708 :名前は開発中のものです。:2009/09/13(日) 03:47:46 ID:pl2tqWb2
いつの時代の話をしてるんだか・・・
そんな仕事があったのはファミコン、スーファミ時代ぐらいまでだろうに。
ここ10年業界でそんな景気の良い話聞いたことないぞ。

709 :名前は開発中のものです。:2009/09/13(日) 03:53:14 ID:pl2tqWb2
まぁ、外注先の中規模デベロッパが子請け孫請けしてるとかまでは
把握はしてないがな・・・

ってかそれだと中間搾取されまくりでとてもゲームPGの最終形態とは
言えないんでは・・・って最終の意味が違う?www

710 :名前は開発中のものです。:2009/09/13(日) 03:53:16 ID:fqn+gvZk
>>708
>そんな仕事があったのはファミコン、スーファミ時代ぐらいまでだろうに。
それはないw

711 :名前は開発中のものです。:2009/09/13(日) 03:55:16 ID:fqn+gvZk
>>709
昔はこっちのが給料高いし会社も半ば善意で勧めてた部分はあるだろうね
正社員からフリーにされた人っていると思うよ
いまになって「騙された!」って叫ぶ人もいるけどw
明らかにあのときは双方合意でやってたしね
すごい金入ってきたし

712 :名前は開発中のものです。:2009/09/13(日) 04:09:10 ID:pl2tqWb2
>>711
あぁー、そういう立場だとアンチタスクになるのはなんとなくわかるわ。
外注じゃないが、以前社内で派遣使ってたとき、不必要な情報は何も見せるなって
こっち側のシステムとか基底部分のコードは全てライブラリ化して渡してた。

派遣さん達は別室でそのシステムに合わせて末端コードを量産してもらってたんだけど
向こうでバグとか出ても基底のコード無いから追ってくの大変だろうなぁ・・・と思ってた。
基底システムも同時作成だから仕様コロコロ変わってバグもあったしwww

これで基底がタスクシステムとかだとタスク憎し!になるのかも仕方ないかとww
でもそれはタスクシステムの問題とは違うんだけどな。

713 :名前は開発中のものです。:2009/09/13(日) 04:32:30 ID:fqn+gvZk
>>712
そんな意図ねーだろ
単純にプログラムの組み方を知らない人間が増えたってただそんだけでしょ
知っている方法が彼等にとってはそれだけなんだよ
普通に組むの普通って彼等にわかるんだろか?
3Dにしてもそうだけどどれだけ原理をわかって使ってる人がいるんだろか?

714 :名前は開発中のものです。:2009/09/13(日) 05:00:31 ID:pl2tqWb2
>>713
派遣や外注の経験は無いが、こっちも中小と大手2社に転職していくつか現場経験してきたけど・・・
会社規模や現場毎に文化やスタンダードが全然違うゲームプログラムで
「普通」に組むって言われてもなぁ・・・
エスパーでないので君にとっての「普通」が何なのか良くわからんよ。

それに3Dの原理って具体的に何のことを言ってるんだ?
マトリクス計算できてシェーダー書けて意図したようにモデル描画できただけじゃ何か不足?

コンシューマからアーケードから携帯機からPCから、全てに共通した「普通」なんて無いと思うけどね。
タスクシステムにしろ何にしろ、ここではそーいったやり方してるんだなぁ、
ぐらいで郷に入れば郷に従え、って受け入れることができないと、共同作業でゲームなんて作れんぞ。

715 :名前は開発中のものです。:2009/09/13(日) 09:31:38 ID:fqn+gvZk
>>714
ごちゃごちゃうるせぇなw
知らないなら一言知らないって言えよw

716 :名前は開発中のものです。:2009/09/13(日) 12:38:55 ID:y9IV6Lib
普通ねぇ。
メインループ部に必要な処理を書いていく。
動的に処理の順番を変えなきゃならない部分だけ、動的な処理の呼び出しをする。
長くなったり重複する部分を関数に分ける。
関数から先を各プログラマに振り分ける。
上記を見越して設計する。
そんぐらいだと思うが。

717 :名前は開発中のものです。:2009/09/13(日) 14:53:59 ID:pl2tqWb2
>>716
処理の順番を変えなきゃならないとか、重複する部分を関数に分けるとか、
各プログラマに振り分けるとか、ってタスクシステムが得意とする範疇だけど
それらを実装する「手段」としてタスクシステム使うのが普通じゃなく異常って
理屈はどこから出てくるのかな?

まぁ、メインプログラマじゃない、基底部分から離れた所しか触れない外注とか
末端プログラマから見ればタスクシステムがあるおかげでこんなに苦労する・・・
とか思う所もありそうだけど。
仕事を割り振る都合上、末端プログラマにメインフロー部分まで丸見えになるのは
望ましくなのでね。
タスクシステムにしろ他の管理処理にしろ、個人レベルとかよほど小規模なプログラム
じゃない限り何らかの管理処理をかまして作るよ。

718 :名前は開発中のものです。:2009/09/13(日) 15:37:55 ID:3c0R0FZj
>>717
噛み付く相手を間違えてないか?

719 : ◆HSP4mee/SU :2009/09/13(日) 17:14:50 ID:2Cmfd9Bi
>>713
>普通に組むの普通って彼等にわかるんだろか?

普通って何すか?HSPで説明してよ。ぼくわかんないよ

>3Dにしてもそうだけどどれだけ原理をわかって使ってる人がいるんだろか?

なにそれこわーい。原理が分かるってどの程度のお話なの?
ユークリッド幾何学の講義ができるくらいわかんないとダ、ダメェ〜みたいな?
別に数学者になるわけじゃねーし、知識は道具として活用できりゃ
(血肉になれば)それでいいじゃんみたいな

それとも例えば
四元数を使うからにはそれを数学的に論じられなければダ、ダメェ〜だとか
「ぼくぅ、今そこの部分で使ってるオイラー法の変形版みたいなコードさ。それの
計算結果がオイラー法よりも良好になっちゃう理由を数学的に説明してみ?」
みたいな強烈にうざーいハッタリ攻撃みたいなものなんでしょうか?

720 : ◆HSP4mee/SU :2009/09/13(日) 17:24:50 ID:2Cmfd9Bi
あ、HSPが神言語すぎて分からないならC/C++でもいいよ
なんならIrrlichtとかBulletとかのフリーのミドルウェアを
例にあげて説明してくれても構わないよ

CodeZineの記事が普通とか言うなら腹の底から笑ってやる

721 :名前は開発中のものです。:2009/09/13(日) 19:33:28 ID:A5v2iphL
またキチガイHSPerのおでましか

722 :名前は開発中のものです。:2009/09/13(日) 19:53:00 ID:3c0R0FZj
タスクシステムなんて元々は超フリーダムシステムだったのにな
いつの間にか制限をかけるためのものみたいな話になってるし
よくわからんね

723 :名前は開発中のものです。:2009/09/13(日) 20:36:56 ID:y9IV6Lib
>>717
>処理の順番を変えなきゃならないとか、重複する部分を関数に分けるとか、
>各プログラマに振り分けるとか、ってタスクシステムが得意とする範疇だけど
>それらを実装する「手段」としてタスクシステム使うのが普通じゃなく異常って
>理屈はどこから出てくるのかな?

普通のアプリではタスクシステムを使わないから、
タスクシステムを使うのは特殊と言えるだろう。

724 :名前は開発中のものです。:2009/09/13(日) 20:54:22 ID:3c0R0FZj
普通のアプリってなんだ。まーたワードとかエクセルがどうのとかか


725 :名前は開発中のものです。:2009/09/13(日) 23:11:30 ID:pl2tqWb2
>>723
”普通”のアプリがWindowsGUIアプリとかサーバアプリのことを言ってるなら
>処理の順番を変えなきゃならないとか、重複する部分を関数に分けるとか、
>各プログラマに振り分けるとか、ってタスクシステムが得意とする範疇だけど
ってのがそもそもゲーム以外であんまり無いからじゃないのかね。

あとVsync1フレーム内に処理を終わらせないといけないからメッセージ駆動と相性が
悪いとかコンシューマハードのメモリ制限とかの条件が”普通”とは違うから
タスクシステムみたいなのが使われる理由なんでない?

でもこの条件って一般的な”コンシューマゲーム”では普通だと思うけど。

726 :名前は開発中のものです。:2009/09/14(月) 00:07:07 ID:b3qZD6eb
ID:fqn+gvZkだけど
普通ってのがわかんねー奴なんて話す価値もない雑魚
だいたいソースにそんなにアドレスジャンプを入れちゃう神経が俺にはわからないけどねw

727 : ◆HSP4mee/SU :2009/09/14(月) 00:21:02 ID:OKDtae38
引数さんってすごい人生送ってんだね

728 :名前は開発中のものです。:2009/09/14(月) 00:29:56 ID:s76DUIJ5
>>726
大人になったら「自分の普通と他人の普通は違うもの」ってことを理解しないね。
自分と違う人間は話す価値もない雑魚。みたいに考えてると結婚も就職もうまくいかないぞww


729 : ◆HSP4mee/SU :2009/09/14(月) 00:32:16 ID:OKDtae38
あと3Dの原理とやらもさ。分かってるかどうかの閾値は何よ
自称のプロのハッタリ攻撃ってほんと面白いな

730 : ◆HSP4mee/SU :2009/09/14(月) 00:36:36 ID:OKDtae38
あー。でもよく読んだらID:fqn+gvZkさんって分類上はアンチなのか
攻撃対象を間違えちゃったかも。まぁいいや

731 :名前は開発中のものです。:2009/09/14(月) 00:42:59 ID:ITTqVfd8
HSP君は噛み付く相手を選ぼうぜ
その自営業君はアンチに味方する数少なーい味方なんだからよ

732 :名前は開発中のものです。:2009/09/14(月) 01:12:47 ID:ITTqVfd8
しかしまぁ、タスクシステムは本当にただのローカル用語だったのだが
どうも厨二魂の琴線に触れてしまったのが運の尽きだったらしい。不幸な話だな
今ではすっかり厨房用語として確固たる地位を築いてるみたいだな

733 : ◆HSP4mee/SU :2009/09/14(月) 01:26:25 ID:OKDtae38
>今ではすっかり厨房用語

えーなにそれ。それ元からじゃないの?
だってコンテキストの保存・切り替えすらできないし
スケジューリングも満足にできない、かなりどうでもいい
仕掛けの癖にTASKとかTCBとかいかにもRTOSあたりから
適用に用語パクってきましたーみたいなカンジじゃんこれ
初っ端から厨っぽいハッタリ臭が漂ってると思うよ

734 :名前は開発中のものです。:2009/09/14(月) 02:27:40 ID:+aTqfCIt
まあ、この辺は言葉の定義が曖昧だからしょうがないかもしれんが、
コンテキストの保存、切り替えをする、今で言うFiberみたいなのも
タスクシステムと呼ぶこともある。
つか、アセンブラの頃はそっちのが主流だったかも。

元々がゲーム「業界用語」なので、適当にパクってきた言葉なのも
しょうがない。

735 :名前は開発中のものです。:2009/09/14(月) 03:02:11 ID:NAes6z1P
>>734
Logicianの所にアセンブラ時代は今で言うCPSのようになってた
ことをうかがわせる記述があるね。

>>733
ゲーム作りたい奴なんて昔も今も厨房なんでその指摘は当たってると思う。
ただ独自に発想した結果OSと似たものができたのか
仕組みそのものもOSからパクったものなのかはわからない。
個人的には後者だと思う。

736 :名前は開発中のものです。:2009/09/14(月) 09:14:04 ID:YkGM1LSO
>>733
> 初っ端から厨っぽいハッタリ臭が漂ってると思うよ

( ;∀;)イイハナシダナー

737 :名前は開発中のものです。:2009/09/14(月) 20:31:50 ID:6Ysib9Lf
> Logicianの所にアセンブラ時代は今で言うCPSのようになってた
> ことをうかがわせる記述があるね。

CPSって継続渡しのこと?
コルーチンのことを言おうとしてる?

アセンブラ時代の元のジョブコンは、コルーチンそのものだった。
それが "劣化" して、C でジョブコンもどきのコールバックリストになったものが、
Logician が説明していた「タスクシステム」。

738 :名前は開発中のものです。:2009/09/14(月) 20:33:27 ID:DstoX78Z
一番苦労するのはオブジェクト同士の関連部分なのにそこのサポートがない仕組みがそもそも役に立たないよね

739 : ◆HSP4mee/SU :2009/09/14(月) 20:35:10 ID:aD5dNgAk
>>727間違えた。引数さんごめん
引数さんはもっと男前だった気がする
この自営業さんには彼の男気を感じない

740 :名前は開発中のものです。:2009/09/14(月) 22:23:54 ID:qgZKctbK
>>738
そこをサポートせずに使う側に投げてるのがタスクシステムの利点であり欠点でもある。
オブジェクト同士の連携はゲームの仕様に合わせて勝手にやってね、そこはタスクシステムの
関知するところじゃないから、ってスタンス。

なので純粋なタスクシステムは基本的にゲームに合わせてカスタマイズ、拡張しないと使えない。
ただ、そこに手を出さなかったから生き延びてるってのも事実。

オブジェクト同士の関連はゲーム仕様やハード制限に強く影響を受けるから、もしタスクシステムが
そこをサポートしていたら、タスクシステムはごく一部の仕様やハードスペックに依存した物になる。
そのややこしい部分を内包しないおかげでタスクシステムという仕組み自体はなんだかんだで
絶滅せずに色々なゲームで使われてる。

741 :名前は開発中のものです。:2009/09/14(月) 22:34:48 ID:b3qZD6eb
>>740
なにいってるかさっぱりわからないw

742 : ◆HSP4mee/SU :2009/09/14(月) 22:46:57 ID:aD5dNgAk
> 1(キャラ)オブジェクト=1Taskという勘違い

敵や弾という分割単位はオブジェクト思考のクラス分割のそれなんだろうと思う

でもこのスレのタスクシステマー達の作文を我慢強く読んでると、タスクシステムの
タスクってのは処理単位、処理ステップだと言う。Cyclic Executiveの処理単位なのだと。
Non-Preemptive Schedulingの仕掛けだから人間の手で処理をぶった切ってる。
このぶった切り方、分割のしかたは時間軸の、スケジューリングの都合でやってるよね。
こういう時間領域での分割ってのはオブジェクト指向のクラス分割とは軸が違うよね

たまに見る「タスクシステムはオブジェクト指向」という説も、この分割の軸の
違いを無視した結果なんじゃないかと思う。クラスは処理とデータのセットだから
タスクと同じだーみたいな。1ワーク=1タスクというのは先入観・l固定観念だームキー
というお話はこういうことなの?ぼくばかだからやっぱよくわかんないや

743 :名前は開発中のものです。:2009/09/14(月) 22:47:09 ID:qgZKctbK
>>741
わざわざ僕は馬鹿ですって言いふらさなくてもいいのにwww

そんなんだからいつまでも下っ端の底辺PGなんだよ。
早くプロのゲームプログラマになれるといいねww

744 :名前は開発中のものです。:2009/09/14(月) 22:52:27 ID:b3qZD6eb
>>740
>そこをサポートせずに使う側に投げてるのがタスクシステムの利点であり欠点でもある。
もうこれだけで駄目
そっから下の文章馬鹿すぎて読めない
なにこれ?なにこの文章?
馬鹿もここまでくるとすごいなw

745 :名前は開発中のものです。:2009/09/14(月) 23:12:36 ID:OqkFZ6jR
またキチガイHSPerのお通りだぜ

746 :名前は開発中のものです。:2009/09/14(月) 23:40:07 ID:RKVdgOVY
>>742
>時間軸の、スケジューリングの都合

まぁそういう解釈もありなのかな。手続き(処理順序)の都合で分割してるわけだからな。
並行性を満たすための手続きだったり、正しく描画するための手続きだったり。

敵1機や弾1発という分割単位には別に拘束されない。

747 :名前は開発中のものです。:2009/09/14(月) 23:55:13 ID:RKVdgOVY
>>746補足
あとは外部の(疎結合の)プロセッサ等に送るコマンド(パケット)サイズの都合で分割されてたり
まぁこれも手続きの都合でありスケジューリングの都合ともいえるのかな。知らん

748 :名前は開発中のものです。:2009/09/14(月) 23:55:30 ID:Nw0HeM76
>並行性を満たすための手続きだったり
ん?ん?並行性を満たすためにタスクシステム使う??
ん?どういうこと?

749 :名前は開発中のものです。:2009/09/14(月) 23:57:40 ID:Nw0HeM76
内緒だけど、
time driven cyclic executiveの中の人とHSPerの中の人は
同一人物ってことでいいんだよね。

750 :名前は開発中のものです。:2009/09/15(火) 00:09:23 ID:A8I4hqlh
>>740
>オブジェクト同士の連携はゲームの仕様に合わせて勝手にやってね、そこはタスクシステムの
>関知するところじゃないから、ってスタンス。
>なので純粋なタスクシステムは基本的にゲームに合わせてカスタマイズ、拡張しないと使えない。
>ただ、そこに手を出さなかったから生き延びてるってのも事実。

結局、関知するのかしないのかどっちなんだよ。
関知しないはずなんだけど、関知するようにカスタマイズしないと使えない。
つまり、最終的には関知する。でも、関知しないから生き延びてる。
意味不明。

751 :名前は開発中のものです。:2009/09/15(火) 00:23:22 ID:A8I4hqlh
オブジェクト同士の連携も処理順も、メインループ側から素直に関数呼ぶ実装にしておけば
明確なはずなのに、
それをせずに、メインループを封じ、
引数固定のわけの分からない細切れのupdate関数内で各々勝手にコミュニケーションさせ、
エディタ上で追いにくいプライオリティー値で処理順を制御しようとする。
ビバタスクシステム

752 :名前は開発中のものです。:2009/09/15(火) 00:40:26 ID:z7cESVWf
>>751
> オブジェクト同士の連携も処理順も、メインループ側から素直に関数呼ぶ実装にしておけば
> 明確なはずなのに、

処理順で描画のプライオリティを変更するようなシステムだと、
処理順を変更したいことは結構あるのだけど、↑のような実装になっていると
処理順を変更するのは手間がかかると思うけどな。

典型的なタスクシステムなら、
taskSystem.setPriority(100);
って書くだけで処理順を変更できると思うが、「メインループ側から素直に関数呼ぶ実装」の
場合、どれだけこのためにコードを書かないといけなくなる?

753 :名前は開発中のものです。:2009/09/15(火) 00:46:03 ID:fCQi+Se2
>>752
>処理順で描画のプライオリティを変更するようなシステムだと、
???・・・は?・・・

754 :名前は開発中のものです。:2009/09/15(火) 00:50:18 ID:A8I4hqlh
タスクシステムは、ゲームにあわせてカスタマイズしなきゃ使えないって言うんなら、
もう、明示的にupdate_player()やらupdate_enemies()やら呼んでも同じことだろ。
カスタマイズはするのに、ゲームループを固定することだけは死守するのはなんでだろう。
ゲームループもゲームにあわせてカスタマイズしてやればよい。

あるタスクを追加するのに、新たな機能をタスクシステム側でサポートしなきゃならないのなら、
結局、タスクシステム側も触らないといけないわけで、
だったら、その処理はタスクなんかで賄おうとせずに、タスクシステム内に直接書けばいいと思うし、
長くなるなら関数に分ければいいと思うし、
一人で書ききれないなら、関数から先を部下に投げればいいと思うし、
初めからタスクシステムなんて要らなかったってことになると思うし。

755 :名前は開発中のものです。:2009/09/15(火) 01:06:55 ID:A8I4hqlh
>処理順で描画のプライオリティを変更するようなシステムだと、
この一文が意味不明すぎて夜も眠れません。
描画用のリストがあって、そこでZソートするって話なら、
それはタスクシステムではなくて、描画エンジンだし、
描画機能も持った鬱陶しいタスクシステムの話なら、
処理順と描画順は独立したプライオリティーを持つだろうし、
描画機能も持った鬱陶しいタスクシステムで、
処理順も描画順も一つのプライオリティーを共有するってんなら、
話にならないし、
描画も処理の一部として一律にタスクシステムで処理するってんなら、
頭おかしいし。

756 :名前は開発中のものです。:2009/09/15(火) 01:09:38 ID:z7cESVWf
>>755
> 描画も処理の一部として一律にタスクシステムで処理するってんなら、
> 頭おかしいし。

そんなことないね。画面に1000ぐらいオブジェを表示していて、それのソートなんかしたくない。

携帯用のゲームとか書いたことがないんだね。初心者プログラマ乙。

757 :名前は開発中のものです。:2009/09/15(火) 01:22:40 ID:A8I4hqlh
ソートしたくないんだったら、タスクシステム使わずにベタで書けよ。バカじゃね

758 :名前は開発中のものです。:2009/09/15(火) 01:24:52 ID:A8I4hqlh
おまえ、処理の順番変えるから、タスクシステム使いたいとか言っといて、
こんどは、並べ替えたくないとか、何言ってんだ?
>>750でも指摘したけど、言ってることむちゃくちゃすぎるだろ。

759 : ◆HSP4mee/SU :2009/09/15(火) 01:30:50 ID:DL5ztsHK
>>746
それだったら何でTask基底クラスなんか継承させてエンティティ作るわけ?バカじゃん?
あと並行性とか意味がわかんないし。そんなの完全無視でゲーム作れるじゃん
タスクシステマーはすぐそうやって高専生にわからない難しい単語を駆使して
煙に巻こうとするよね

760 : ◆HSP4mee/SU :2009/09/15(火) 01:37:17 ID:DL5ztsHK
>>749
おまえらタスクシステマーはすぐそうやって調子に乗る
タスクシステマーにちょっとでも理解を示すような素振りを見せると
ダークサイドへと、暗黒面へと誘う。気持ち悪い

---------------------------------------------------------
怪物と闘う者は、その過程で自らが怪物と化さぬよう心せよ。
おまえが長く深淵を覗くならば、深淵もまた等しくおまえを見返すのだ。
                          フリードリヒ・ニーチェ

761 :名前は開発中のものです。:2009/09/15(火) 01:45:16 ID:gxCgGIPo
タスクシステムを(頭ごなしに)否定してる人たちって、
コンシューマとかで1/60とかのVSyncを意識して
ゲームをちゃんと作ったことあんの?

762 : ◆HSP4mee/SU :2009/09/15(火) 01:46:11 ID:DL5ztsHK
処理順序とやらを動的にする場面なんて2DSTGにあるのか?
少なくとも俺はそんなの必要になった試しがないから俺は要らない
弾は弾の配列。敵は敵の配列。総当り。描画順は基本的に
Zバッファにおまかせ。アルファブレンドする部分だけ仕方なく
ソートして描く。加算合成だけなら順序関係なく描いて終わり



763 : ◆HSP4mee/SU :2009/09/15(火) 01:49:56 ID:DL5ztsHK
>>761
なにそれおいしいの?

764 :名前は開発中のものです。:2009/09/15(火) 01:53:32 ID:hfHn/VaN
>>760
くっくっく。お前初めてか?まぁ力抜けよ。こっちへおいで


765 :名前は開発中のものです。:2009/09/15(火) 01:55:34 ID:z7cESVWf
>>758
> おまえ、処理の順番変えるから、タスクシステム使いたいとか言っといて、
> こんどは、並べ替えたくないとか、何言ってんだ?

描画順を調整するためにstd::listやstd::vectorみたいなものをソートしたくないと言ってるんだ。
例えば、毎フレーム、std::sortとか呼びたくない。

処理の順番を変えるのは、タスクシステムが持っているような最初から整順されている
コンテナの適切な所に要素ひとつinsertするだけであって、これは、狭義にはソートとは言わんでしょ。

766 :名前は開発中のものです。:2009/09/15(火) 01:56:33 ID:z7cESVWf
>>759
> タスクシステマーはすぐそうやって高専生にわからない難しい単語を駆使して
> 煙に巻こうとするよね

ゲームをろくに作ったことのない初心者プログラマはお呼びじゃないよ。

767 : ◆HSP4mee/SU :2009/09/15(火) 01:59:11 ID:DL5ztsHK
バーカバーカ。もう知らない

768 :名前は開発中のものです。:2009/09/15(火) 02:14:00 ID:z7cESVWf
>>762
> 処理順序とやらを動的にする場面なんて2DSTGにあるのか?
> 少なくとも俺はそんなの必要になった試しがないから俺は要らない

自機を雲の一部に潜らせたいとして、そのときその部分の雲は自機よりプライオリティ高いよな。
そこに敵を打ち落として、爆発したときに、高度が浮き上がって墜落するように見せたいとする。

雲より一瞬手前に持ってきて、そのあと背景の雲よりさらに後方に持っていかなければならない。

こんな単純な処理ですら、描画プライオリティの変更が発生するが、HSPerはどんだけ
ゲームの製作経験に乏しいのか、どうしてそんなにイマジネーションが貧弱なのか。

俺はそっちのほうを小一時間問い詰めたい。

769 :名前は開発中のものです。:2009/09/15(火) 02:21:18 ID:zge783nA
つられないくまー

770 :名前は開発中のものです。:2009/09/15(火) 02:34:51 ID:hfHn/VaN
一陣の風が吹き抜けるがごとくHSPバカが通り過ぎていった
毎度、実に惜しいところまで達してパルプンテする子であるな

771 :名前は開発中のものです。:2009/09/15(火) 02:56:13 ID:XbC7nhnm
>>768
> ゲームの製作経験に乏しいのか、どうしてそんなにイマジネーションが貧弱なのか。
最近の新人プログラマにも多いんだよ、そういうの。ゲー専卒で入ったはずなのに、
HDサイズのポストエフェクト、毎フレームGPU使わずにCPUで1ピクセル単位にgetPixel/setPixelって仮想関数呼び出して
「なんでこんな簡単な処理で60FPS切るんですか?次世代機って遅くてぜんぜん使いものになりせんね」って・・・
こんなレベルのが普通にゲーム会社に入社してくる時代なんだから・・・

しかも、なぜか彼らは共通してOOPとかデザパタが大好きで、そして根拠の無い自信でいっぱいなんだ。
そのやり方じゃ処理速度的にダメだろ・・・って言っても
「は?仮想関数なんてOOPの基本でしょ?それ使わないなんて何原始的なこと言ってるんですか?」
とか、本気で言い返してくるし。
プログラマ辞めて病院行け!と言いたくなるようなのが増えてる。

幸いにもチーム員を選べるだけの権限があるのでこーいう地雷プログラマは他に押し付けて難を逃れてるけど、これがゆとりってやつかねぇ・・・

772 :名前は開発中のものです。:2009/09/15(火) 04:30:24 ID:SSpdgbLK
>>756,765,768
その方向で突っ込まれるたびに条件を狭めて反論していくと、
携帯機みたいに CPU リソースが乏しくて、且つ、オブジェクトの数が 1000 単位で、
且つ、優先度の変更がゲームオブジェクトの明示的な状態変更でしかおこらくて、
・・・と、どんどん限定された状況でしかタスクシステムが適切な場面が無くなってる
ことになるんだけど、そういうものってことであってる?

773 :名前は開発中のものです。:2009/09/15(火) 04:36:42 ID:z7cESVWf
>>772
条件を狭めているつもりは全くないよ。

俺がタスクシステムが使えるシーンとして A,B,Cを例示したからと言って、
タスクシステムが使えるのは、 A && B && Cと限定してわけではない。

こんなのは、初歩的な論理学だと思うんだが。

774 :名前は開発中のものです。:2009/09/15(火) 04:46:07 ID:SSpdgbLK
>>773
ん?おかしいな。

言い換えてみよう。

携帯機みたいに CPU リソースに乏しくなければ毎フレーム描画優先度で
ソートすれば(3Dでは当然)良いし、オブジェクトの数が数十単位なら今時の
携帯機なら毎フレームソートしてもほぼ問題にならないし、毎フレーム優先度が
変わる可能性があるようならそもそも毎フレームソートしないとダメで、やっぱり
どの条件が欠けてもタスクシステムが処理順(=優先度)を保持してることの
メリットが消えることになりそうなんだけど、そうじゃないの?

775 :名前は開発中のものです。:2009/09/15(火) 05:01:39 ID:z7cESVWf
>>774
> タスクシステムが処理順(=優先度)を保持してることの
> メリットが消えることになりそうなんだけど

それは違うね。

タスクシステムが処理順を保持しているのは、描画の優先順位のため以外にも、
呼び出される順番自体を制御したいからだ。

Aというボスに対して、その相対座標(-10,-20)に表示されるザコキャラBを表示したい場合、
Aの移動処理が完了してから、Bの移動処理を行なう必要がある。

だから、ここには、A,Bの移動処理に関して、守るべき呼び出し順序がある。

上のようなことをやろうとするなら、タスクシステムが処理順(優先度)を保持しているのは
必要不可欠なことで、「毎フレーム描画優先度でソートすれば」解決するような問題ではない。

776 :名前は開発中のものです。:2009/09/15(火) 05:13:04 ID:SSpdgbLK
>>775
「移動処理」の順番は静的にコードに書けばいいし、そうしたほうが
いいだろ、という話で >751 に戻ってしまうわけで。

それに、移動処理の順番を保持したいからという理由で描画処理の順番を
保持するのが必要不可欠ってことは、移動処理の順番と描画処理の順番が
同じである(あるいは何らかの関係がある)と言うことが前提になりそうなん
だけど、それもキツイ制約だね。(ぶっちゃけありえない)

移動処理と描画処理の順番に何の前提も持たない場合(個人的には自然な
状態)ではやっぱり描画順をタスクシステムが保持するメリットがあるのは限定
された環境でのみ、って話になりそうだよ。

ちがうの?

777 :名前は開発中のものです。:2009/09/15(火) 05:58:14 ID:z7cESVWf
>>776
> 「移動処理」の順番は静的にコードに書けばいいし、そうしたほうが
> いいだろ、という話で >751 に戻ってしまうわけで。

だから、動的にボスとかザコとか増えるんだよ。ボスが産み出すザコは限りなかったり、
ボス自体が無数に出てくる。どういうコードをもって静的に書けると言ってるんだ?

サンプルプログラムを書いてみせなよ。

> それに、移動処理の順番を保持したいからという理由で描画処理の順番を
> 保持するのが必要不可欠ってことは、移動処理の順番と描画処理の順番が
> 同じである(あるいは何らかの関係がある)と言うことが前提になりそうなん
> だけど、それもキツイ制約だね。(ぶっちゃけありえない)

そんなことは俺は前提にしてないぞ。

移動処理の呼び出し順と描画順が同じじゃないなら、
タスクシステムがstd::list<Task*>みたいな奴を2本持っていればいいだけ。

その話題は、このスレの過去スレでもさんざん出てきてるだろ。

778 :名前は開発中のものです。:2009/09/15(火) 07:37:09 ID:mI0eh4Bx
処理順を動的に切り替える設計なんて腐った仕様にしねーよ(笑)
程度が低すぎて相手にしたくないな

779 :名前は開発中のものです。:2009/09/15(火) 07:42:07 ID:z7cESVWf
>>778
程度が低いのはお前。

処理順を動的に切り替える設計にしないと要求使用を満足できないんだよ。
現場経験のないド素人プログラマがしゃしゃり出てくんな。

780 :名前は開発中のものです。:2009/09/15(火) 07:42:43 ID:mI0eh4Bx
動的に増えたってそりゃmanageクラスの保持するインスタンスの数が多いか少ないかの話しだろ
関係無い話をするな

781 :名前は開発中のものです。:2009/09/15(火) 07:45:20 ID:mI0eh4Bx
3Dはツリー状に処理するけどそれだってタスクシステムなんていらねえよ(笑)

782 :名前は開発中のものです。:2009/09/15(火) 08:17:46 ID:z7cESVWf
>>780
だからサンプルを書いてみせろって。お前が思っているほど甘くないよ。

>>781
タスクシステムがいらない代わりにかなり大がかりな3Dエンジンがいるじゃん。
お前、本当に自分で一度でも3Dのエンジンを自分で書いたことがあるのか?

783 :名前は開発中のものです。:2009/09/15(火) 08:52:11 ID:XbC7nhnm
マスター前に処理落ちやメモリ不足をギリギリまで泊り込みでチューンするのは
リソースの厳しい携帯機だけじゃなくPS3とか360でも普通にあるんだけどな。

一度でもマスターの修羅場をくぐり抜けたプログラマーなら
”毎フレームソート”とかを軽々しく使うなんて生理的に受け付けんよ・・・

784 :名前は開発中のものです。:2009/09/15(火) 12:45:27 ID:mI0eh4Bx
その辺の仕組みとこの話題は全く関係無いよ(笑)

785 :名前は開発中のものです。:2009/09/15(火) 12:49:12 ID:mI0eh4Bx
タスクシステムが必要な理由ってそんな恥ずかしいもんでいいの?

786 :名前は開発中のものです。:2009/09/15(火) 22:44:37 ID:A8I4hqlh
>>782
ほれ。>>117
仮想関数も動的な呼び出しも使わないからタスクシステムより高速

787 :名前は開発中のものです。:2009/09/15(火) 22:45:55 ID:A8I4hqlh
>しかも、なぜか彼らは共通してOOPとかデザパタが大好きで、そして根拠の無い自信でいっぱいなんだ。
>そのやり方じゃ処理速度的にダメだろ・・・って言っても
>「は?仮想関数なんてOOPの基本でしょ?それ使わないなんて何原始的なこと言ってるんですか?」
>とか、本気で言い返してくるし。

仮想関数(笑
このスレでそれはタスクシステムの代名詞だ。

788 :名前は開発中のものです。:2009/09/15(火) 22:52:11 ID:A8I4hqlh
ただ、一つの方向性は見えてきたと言えるんじゃないか?
タスクシステムは、動的に処理順を変更したい場合にメリットがあると。
しかし、こうも思うね。
動的に処理の順番を変えなきゃならない部分だけ、局所的に動的な処理の呼び出しを
実装すればすむんじゃないかって。
なにも全部をタスクシステムで賄う必要はないよな、あんな使いにくいもの。

789 :名前は開発中のものです。:2009/09/15(火) 23:01:35 ID:A8I4hqlh
for(;;)
{
  get_input();
  update_player();
  update_enemies();
  render();
  do_post_effects();
  wait();
}
ああなんて分かりやすい。
実際のゲームがもっと複雑になるのはそりゃ分かってるよ。
ただ、上記のスタイルをなるべく維持するよう努めようとするのがまともな感性と言うものだろうよ。

790 :名前は開発中のものです。:2009/09/15(火) 23:36:06 ID:fCQi+Se2
>>788
>タスクシステムは、動的に処理順を変更したい場合にメリットがあると
ないだろw
じゃあ、3Dのツリー構造とかの役に立つのかよw

791 :名前は開発中のものです。:2009/09/15(火) 23:46:25 ID:A8I4hqlh
ということで、タスクシステムのメリットはなくなりました。

792 :名前は開発中のものです。:2009/09/15(火) 23:48:29 ID:z7cESVWf
>>786
> ほれ。>>117
> 仮想関数も動的な呼び出しも使わないからタスクシステムより高速

117は全然駄目だよ。

player型(型名は先頭大文字にしてくれ!)より enemy型のほうが優先して実行したいのではないんだ。
優先して実行したい順番が型によって決まるのではないんだ。オブジェクトを生成した瞬間に決まるんだ。

ボスがザコを生成する。そのザコがザコ2を生成する。ザコ2はザコの位置から相対で出現するが、かと言って、
つねに、ボス→ザコ→ザコ2 の順番で移動処理を呼びたいわけではない。ザコ2==ザコの場合だってありうる。

だから型ごとに優先順位を持たせようという考え方自体がおかしい。

あんた、本当にゲーム作ったことあんのか?

793 :名前は開発中のものです。:2009/09/15(火) 23:51:32 ID:A8I4hqlh
>>792
>>117の中身は>>529みたいになってて、
型間を飛び越えて列挙される順番を指定できる。

794 :名前は開発中のものです。:2009/09/15(火) 23:54:51 ID:fCQi+Se2
>>792
は?
どういう場合を想定していってるの?
3Dの多関節構造みたいなゲームオブジェクトなんてそんなにねーぞ
足場とかだけど普通型で決まるだろ?

木になってる実が落ちて地面の上で転がって落ちて川に流れてみたいなのやっても
そんな処理順序を制御しないとうまくいかないなんてまずないっていうか
おかしいだろそれ

壁とか足場の当たりの判定を物体の移動毎にやらなきゃいけないとかそういうことならあるけどさ
同列に処理順序を制御していいことってあるか?

795 :名前は開発中のものです。:2009/09/15(火) 23:55:47 ID:A8I4hqlh
それよりも、
>型名は先頭大文字にしてくれ!
に笑っちゃうという。
それはお前の会社のローカルルールだろ。
不特定多数が閲覧する掲示板にまで適応しようとするなよな。タスクシステムもそうだけどよ。

796 :名前は開発中のものです。:2009/09/16(水) 00:29:19 ID:i2py24OE
1msの処理に何百人が何年もとりかかる
月給いくらだろうね

797 :名前は開発中のものです。:2009/09/16(水) 00:32:11 ID:8HYG9zOk
お?ID:A8I4hqlh = ID:bJbP9YDC なのか?

798 :名前は開発中のものです。:2009/09/16(水) 00:42:21 ID:i2py24OE
>>797
なんで2chの匿名掲示板で人物を特定したがるの?
バカなの?死ぬの?

799 :名前は開発中のものです。:2009/09/16(水) 00:45:26 ID:8HYG9zOk
ID:z7cESVWf は2D専用オヤジの可能性が高いので優しくすべきである
もしかすると2D専用オヤジを装ってるだけなのかもしれないが…

本物の2D専用オヤジならタスクシステムがメインループを固定する
理由を明快に答えられるだろ

800 :名前は開発中のものです。:2009/09/16(水) 00:51:18 ID:8HYG9zOk
なぜ2D専用オヤジに優しくすべきなのか。それはタスクシステムの長所の多くが
昔のゲーム機、開発環境、開発現場の特性なしには合理的に説明できないからである

801 :名前は開発中のものです。:2009/09/16(水) 00:54:03 ID:X/yeAXR1
>>795
> 型名は先頭大文字にしてくれ!
> に笑っちゃうという。
> それはお前の会社のローカルルールだろ。

違うね。.NET FrameworkやJavaなどで推奨される。
それともお前の会社は、MicrosoftやSun Microsystemsより大きいの?

802 :名前は開発中のものです。:2009/09/16(水) 00:55:04 ID:PDg1ax2i
タスクシステムは推薦されましたか?

803 :名前は開発中のものです。:2009/09/16(水) 00:55:48 ID:X/yeAXR1
>>799
> 本物の2D専用オヤジならタスクシステムがメインループを固定する
> 理由を明快に答えられるだろ

「タスクシステムがメインループを固定する」の意味がわからない。

もう少しまともな日本語は使えないのか。

804 :名前は開発中のものです。:2009/09/16(水) 00:57:19 ID:PDg1ax2i
敵味方関係なく回りに噛み付き出したら末期だな。

805 :名前は開発中のものです。:2009/09/16(水) 00:58:06 ID:X/yeAXR1
>>793
> >>117の中身は>>529みたいになってて、
> 型間を飛び越えて列挙される順番を指定できる。

529はアンカーミスか?117と529がどう関係あるのかさっぱりわからない。

ちゃんとコンパイルできるソースをuploaderにでもあげてくれないか。

806 :名前は開発中のものです。:2009/09/16(水) 00:59:43 ID:X/yeAXR1
>>794
> 木になってる実が落ちて地面の上で転がって落ちて川に流れてみたいなのやっても
> そんな処理順序を制御しないとうまくいかないなんてまずないっていうか

おかしくないよ。単なる2Dのシューティングでボスキャラの相対位置にザコキャラを表示したいだけであっても、
このときボスの移動処理をザコキャラより先に行なう必要がある。

これはわかるのか?

ここがわからないなら、話はこれで終わりだ。

807 :名前は開発中のものです。:2009/09/16(水) 01:00:11 ID:9rR5lXOa
>>801
MSやその他の会社のAPIが先頭大文字にしてるから、
分ける意味で俺は初っ端のワードだけ小文字にして自分の関数と分けてるけどな
(例)createUnko();

808 :名前は開発中のものです。:2009/09/16(水) 01:00:40 ID:8HYG9zOk
>>803
ブート後、電源が落とされるまでメインループを共有する理由だ
ずーっと使い続けるタスクのリンクリスト(実行待ちキュー)が
ある理由だよ

809 :名前は開発中のものです。:2009/09/16(水) 01:01:28 ID:9rR5lXOa
>>806
でも逆はねぇだろ
そしたら固定じゃん

810 :名前は開発中のものです。:2009/09/16(水) 01:01:45 ID:X/yeAXR1
>>804
> 敵味方関係なく回りに噛み付き出したら末期だな。

ちなみに、俺はタスクシステム推奨派でも否定派でもないからな。

このスレのゲームすら作ったことのないくせに偉そうにしているアンチタスカーと
並びに、しょーもないタスクシステムをタスクシステムだと言ってるド素人プログラマ、
お前ら、全員、俺の敵!

811 :名前は開発中のものです。:2009/09/16(水) 01:02:54 ID:PDg1ax2i
>>805
おまえロートル過ぎるだろ。
自分で考える頭ないのかよ。>>801にしてもそうだけどよ。
どうせタスクシステムも上司が推薦したから使った程度の成り行きなんだろ。

812 :名前は開発中のものです。:2009/09/16(水) 01:03:06 ID:X/yeAXR1
>>807
> 分ける意味で俺は初っ端のワードだけ小文字にして自分の関数と分けてるけどな
> (例)createUnko();

それ関数名の話でしょ。俺がしてるのは、クラス名!

813 :名前は開発中のものです。:2009/09/16(水) 01:05:12 ID:X/yeAXR1
>>808
> ブート後、電源が落とされるまでメインループを共有する理由だ

「メインループを共有」の意味がわからん。もう少し日本語がなんとかならんのか。
タスクシステムのどれを「メインループ」だと言っているのか、それすらわからん。


814 :名前は開発中のものです。:2009/09/16(水) 01:05:48 ID:8HYG9zOk
>>799>>808補足だが、別に間違いを指摘する気はない
ちょっとした値踏みだ。考え方でおおよそのところは察せられる

815 :名前は開発中のものです。:2009/09/16(水) 01:06:00 ID:PDg1ax2i
>お前ら、全員、俺の敵!
ついに発狂したか。

>このときボスの移動処理をザコキャラより先に行なう必要がある。
update_boss();
update_zako();
終わり。

816 :名前は開発中のものです。:2009/09/16(水) 01:06:33 ID:8HYG9zOk
>>813
こいつの警戒っぷりはおかしい

817 :名前は開発中のものです。:2009/09/16(水) 01:08:06 ID:X/yeAXR1
>>809
> でも逆はねぇだろ
> そしたら固定じゃん

違うね。処理順は動的に変わるんだよ。

ある瞬間からザコが編隊を成して、その相対位置にボス2を表示しないといけないかも知れない。

でも、あるときには、ボス2の相対位置にザコを表示しないといけないかも知れない。

なんでこれを優先順位固定で設計していいと思えるのか、俺にはそれが不思議だ。
そんなゲームしか作ったことないの?

818 :名前は開発中のものです。:2009/09/16(水) 01:08:22 ID:PDg1ax2i
>>816
回り全員敵だって本人が言ってるじゃん。
職場でも日々そういう状況で性格歪んじゃったんでしょ。

819 :名前は開発中のものです。:2009/09/16(水) 01:08:56 ID:9rR5lXOa
>>812
だから全部同じだって

820 :名前は開発中のものです。:2009/09/16(水) 01:09:35 ID:X/yeAXR1
>>811
> 自分で考える頭ないのかよ。>>801にしてもそうだけどよ。

違うね。801は、>>795で、型名の先頭大文字が俺の会社のローカルルールだって言うから、
俺はもっと世界的規模でそうなっていることを示しただけ。

お前、本当に日本語読めてるか?

821 :名前は開発中のものです。:2009/09/16(水) 01:09:52 ID:9rR5lXOa
>>817
雑魚倒されたときのボスの仕様が見ものだなw

822 :名前は開発中のものです。:2009/09/16(水) 01:10:47 ID:X/yeAXR1
>>815
> >このときボスの移動処理をザコキャラより先に行なう必要がある。
> update_boss();
> update_zako();
> 終わり。

全然終わりじゃない。そんな固定順序で処理していいわけではない。

ド素人プログラマならお断わりだ。

823 :名前は開発中のものです。:2009/09/16(水) 01:11:44 ID:8HYG9zOk
こいつはネット発生型のタスクシステマーだな。素人くさい
ハードウェアに非常に近い、ローレベルの都合がある点を
一切知らんようだ

824 :名前は開発中のものです。:2009/09/16(水) 01:12:21 ID:X/yeAXR1
>>816
> こいつの警戒っぷりはおかしい

警戒はしてない。ド素人プログラムの集団相手に、警戒などする必要がない。

825 :名前は開発中のものです。:2009/09/16(水) 01:13:24 ID:X/yeAXR1
>>818
> 回り全員敵だって本人が言ってるじゃん。
> 職場でも日々そういう状況で性格歪んじゃったんでしょ。

是が非でもそう思いたいんだな。お前は、可哀想な奴だよ。

826 :名前は開発中のものです。:2009/09/16(水) 01:15:59 ID:PDg1ax2i
>>820
どうでも良いから、>>117>>529をよーく見比べて、
どこがどう対応しているか、自分で考える癖を付けろ。

>>825
スレのやり取り見ても分かるとおり、お前に見方なんていねぇよ。

827 :名前は開発中のものです。:2009/09/16(水) 01:16:09 ID:X/yeAXR1
>>819
> だから全部同じだって

意味がわからない。片言でじゃべんな。

関数名は、小文字で始まるラクダ表記にするのは勝手にしたらいい。
それは特に弊害はないと思うよ。趣味の問題だ。

どうせ関数を呼び出すには、XXX() のように括弧が必要なのだから。

クラス名を小文字で始めると視認性が悪く、変数名とバッティングするから避けるべきだと言ってるんだ。

828 :名前は開発中のものです。:2009/09/16(水) 01:16:42 ID:X/yeAXR1
>>821
> 雑魚倒されたときのボスの仕様が見ものだなw

それはゲームによりけりだな。

829 :名前は開発中のものです。:2009/09/16(水) 01:17:30 ID:X/yeAXR1
>>823
> こいつはネット発生型のタスクシステマーだな。

勝手に決めつけんな。俺は8080の時代からプログラム書いてるよ。

830 :名前は開発中のものです。:2009/09/16(水) 01:18:22 ID:X/yeAXR1
>>826
> どうでも良いから、>>117>>529をよーく見比べて、
> どこがどう対応しているか、自分で考える癖を付けろ。

そんな、型名を小文字で書き始めるキチガイの書いたソース読むの嫌だ。

コンパイルが通るソースを出してくれるなら読むというだけ。

831 :名前は開発中のものです。:2009/09/16(水) 01:21:46 ID:8HYG9zOk
>>829
そんな台詞なら趣味マイコンヲタあがりのやねうらおとかいう
PCエロゲプログラマだって似たような台詞を吐けるだろう

まぁいい。お前の素性はおおよそのところはESPで察せられる
臭うんだよ

832 :名前は開発中のものです。:2009/09/16(水) 01:21:48 ID:X/yeAXR1
そろそろおねんねの時間だぜ(俺が)。

あと10分ほど質問を受け付けるが、それで寝るぜ(俺が)。

833 :名前は開発中のものです。:2009/09/16(水) 01:22:37 ID:X/yeAXR1
>>831
やねうらなんて、俺は知らんがな。

834 :名前は開発中のものです。:2009/09/16(水) 01:23:19 ID:9rR5lXOa
>>828
いや、違うな
雑魚に追従するからなんて理由でボスと雑魚の処理順序を代えちまうようなチャチな仕組みだから
雑魚がボスが死ぬことを知るのは次のフレームだし
また、逆のルーチンが走ってるときはボスが雑魚の全滅を知るのも次のフレームだw
シビアなゲーム作ってるときは企画に散々おかしいっていわれるぞw

こういう処理やるときって面倒でもちゃんとswitchcaseかifで分けてしっかり書いたほうがいいと思うんだよねw
シーンにボスと雑魚の関連処理をちゃんと書いたほうがいいんじゃね?
タスクシステム生かしてボスか雑魚にこの処理書くの?(バグがとまらないなw)

835 :名前は開発中のものです。:2009/09/16(水) 01:25:04 ID:PDg1ax2i
>全然終わりじゃない。そんな固定順序で処理していいわけではない。
固定順序で処理してはいけない仕様なんだったら、そこだけ局所的に
動的な処理の呼び出し&スケジューリングをすればよいだろ。
>>817みたいな有るのか無いのか分からない極まれな事例を持ち出して
ゲーム全体でタスクシステムを使うことの有用性を主張するのは無理があると思うね。
一部がそうだからって、全部をそれにあわせてどうする。
お前みたいな奴に社会全体があわせる必要がないのと同じだ。

836 :名前は開発中のものです。:2009/09/16(水) 01:26:45 ID:PDg1ax2i
>そんな、型名を小文字で書き始めるキチガイの書いたソース読むの嫌だ。

837 :名前は開発中のものです。:2009/09/16(水) 01:28:25 ID:X/yeAXR1
>>834
> 雑魚に追従するからなんて理由でボスと雑魚の処理順序を代えちまうようなチャチな仕組みだから
> 雑魚がボスが死ぬことを知るのは次のフレームだし

それは違うな。そんなこと勝手に決めつけられても。

ザコがボスが死んだことを同フレーム内で関知したいならザコは
boost::shared_ptrでボスのポインタを持つよ。

> タスクシステム生かしてボスか雑魚にこの処理書くの?

そんなことは俺は一言も言っていないよ。
必要があれば、behaviorとして書く。あんたの言うところのシーンクラスか、behavior用のタスクに書く。

838 :名前は開発中のものです。:2009/09/16(水) 01:28:58 ID:9rR5lXOa
>>835
いや、まあ、あるとは思うけど
その解決方法がまずいね
ボスと雑魚の間にあきらかにボスと雑魚を包括するステータスが見えているのに
ボスと雑魚だけを一生懸命意地って解決しようとしてるのはまずい

場合によっては解決できない(ほど複雑になる)こともあると思うぜ

839 :名前は開発中のものです。:2009/09/16(水) 01:29:54 ID:X/yeAXR1
>>835
> 固定順序で処理してはいけない仕様なんだったら、そこだけ局所的に
> 動的な処理の呼び出し&スケジューリングをすればよいだろ。

だからそれが嫌だって言ってんの。タスクシステムなら、
taskSystem.setPriority(XX)
ってして順番指定するだけでそれが出来る。

840 :名前は開発中のものです。:2009/09/16(水) 01:30:19 ID:9rR5lXOa
>>837
じゃあ、処理順序なんて変えないではじめからそれ使ったら?
いきなりの新ワードでそれが何か俺は知らないけどw
それ使えば解決できんじゃねーの?

841 :名前は開発中のものです。:2009/09/16(水) 01:30:42 ID:X/yeAXR1
>>838
> ボスと雑魚の間にあきらかにボスと雑魚を包括するステータスが見えているのに
> ボスと雑魚だけを一生懸命意地って解決しようとしてるのはまずい

俺、そんなこと主張してないし、そんなコード書かないぜ。詳しくは>>837

842 :名前は開発中のものです。:2009/09/16(水) 01:32:46 ID:9rR5lXOa
>>841
そうなるとタスクシステムの利点としての処理順序の制御はまだ活きてるの?w

843 :名前は開発中のものです。:2009/09/16(水) 01:34:41 ID:PDg1ax2i
型名を小文字で書いただけで、もう読む気しないという。
一部で処理のスケジューリングが必要だから、全体をタスクシステムで構築する必要があるという。
一人に敵対されたら、全員に敵対されたと発狂する。
なんなんだこいつは。古いタイプなんだろうけど、逆に新鮮だな。
一部を全体に拡張君とでも名づけようか。
心理的に、自分自身が少数派なもんだから、集団全体にそれを要求したくなるとか、
そういうのがあるのだろうか。よくわかんね。

844 :名前は開発中のものです。:2009/09/16(水) 01:36:33 ID:X/yeAXR1
>>842
> タスクシステムの利点としての処理順序の制御はまだ活きてるの

タスクシステムで順序変更したい/してメリットがあるときは、タスクシステムを使って処理順序を変更すればいい。

要するにそれだけだ。

そろそろ、もうおねんねだ(俺が)。
おやすみ。

845 :名前は開発中のものです。:2009/09/16(水) 01:38:33 ID:X/yeAXR1
>>843
> 一部を全体に拡張君とでも名づけようか。

俺のことは、全員敵!君 と名付けてくれ。

ド素人プログラマの馴れ合いにはヘドが出るぜ。

846 :名前は開発中のものです。:2009/09/16(水) 01:38:52 ID:PDg1ax2i
>>839
処理の変更が一部で必要なだけなのに、全体をタスクシステムで書くの?
やっぱり頭おかしいね。
まともなエンジニアなら、道具は使い分けるだろ。

847 :名前は開発中のものです。:2009/09/16(水) 01:41:10 ID:onoPt/rl
流れが早くてついていけないな

>型名は先頭大文字にしてくれ!
これってC++全否定ってこと?

848 :846:2009/09/16(水) 01:41:39 ID:PDg1ax2i
訂正: 処理の変更→処理順の変更

849 :名前は開発中のものです。:2009/09/16(水) 01:42:10 ID:X/yeAXR1
>>846
> 処理の変更が一部で必要なだけなのに、全体をタスクシステムで書くの?

そうだよ。

> やっぱり頭おかしいね。

おかしくないよ。あんたの書いたソース出してみな。俺がレビューしてやるから。

> まともなエンジニアなら、道具は使い分けるだろ。

俺から言わせれば、あんたは頭のおかしいド素人プログラマだ。

850 :名前は開発中のものです。:2009/09/16(水) 01:45:28 ID:nhV6+DhU
確かに、プラスのネジもマイナスドライバーで締めることは出来るから、
マイナスドライバーがあればプラスドライバーは要らないよな(笑

851 :名前は開発中のものです。:2009/09/16(水) 01:50:09 ID:nhV6+DhU
>だからそれが嫌だって言ってんの。タスクシステムなら、
>taskSystem.setPriority(XX)
>ってして順番指定するだけでそれが出来る。

全てをそれで制御しなきゃならなくなる弊害は考えないんだな。


852 :名前は開発中のものです。:2009/09/16(水) 01:58:54 ID:8HYG9zOk
ID:9rR5lXOaにほぼ同意だな

タスクシステムのリンクリスト(実行待ちキュー)内での位置関係で
生残OBJ同士の関連性(親子関係、コンストレイント)も表してしまおう
という発想がイカレているのだ。コンテナの流用、機能の癒着、混濁。

タスクシステムは不衛生であるというのは大変な誤解なのだが
こういう手合いがデカイ面してっとやっぱタスクシステムはウンコ臭い
という話になる。不幸な話だな





853 :名前は開発中のものです。:2009/09/16(水) 02:00:00 ID:8HYG9zOk
こういう手合いというのはID:X/yeAXR1だからな。お前だお前。臭い奴だ

854 :名前は開発中のものです。:2009/09/16(水) 02:04:22 ID:onoPt/rl
>>850
プラスネジに数本マイナスネジが混じるくらいなら、いっそ全部マイナスネジの方がメンテナンスは楽になるな

855 :名前は開発中のものです。:2009/09/16(水) 02:13:28 ID:XNXMwvpA
今日はいつになくド素人プログラマが大量に釣れてるな。

これくらい釣れればID:X/yeAXR1も満足だろう。

856 :名前は開発中のものです。:2009/09/16(水) 02:15:46 ID:8HYG9zOk
釣り宣言とかね。いい歳してやっちゃ駄目。最後まで演じ切る。大人の常識

857 :名前は開発中のものです。:2009/09/16(水) 02:16:01 ID:iTaLOV2Z
俺も業界歴は長いが、アマチュアの頃は>>789みたいに書いていたが、
おそらく色々な問題に対応するために、タスクシステムを使うようになった。

しかし、何の問題を解決したかったのか、もはや思い出せないw

なんか一周回って、>>789でも良い気がしてきた。

858 :名前は開発中のものです。:2009/09/16(水) 02:25:50 ID:B/vr+pyS
>>849
>> 処理の変更が一部で必要なだけなのに、全体をタスクシステムで書くの?
>
> そうだよ。

死亡フラグにしか見えない。

デバッグ中にテスト済みだったはずのところでバグが出て、「何でいまさらこんな
ところで?」って不思議に思ってたら、「あるステージの敵の処理で必要に
なったんで、タスクシステムをカスタマイズ・機能強化して対応しました」とか得意げに
言ってるやつがいるとか・・・

デバッグ中に仕様の穴が見つかって、相談の結果「ここだけ〜な感じにすれば
よさそう」って話がまとまりかけてたら、「それは今のシステムでは不可能です。
システムに手を入れる必要があります。しかし今からでは影響範囲が大きくて
危険です」とか悪びれもせず言ってのけるやつがいるとか・・・

859 :名前は開発中のものです。:2009/09/16(水) 02:27:46 ID:8HYG9zOk
まぁ例えばVS2008EEでC/C++、DirectX使用。
2DSTGをサクサクサクっと作ってしまいたい
そういう学生ちゃんにタスクシステムを薦めるという行為は
ある種の悪意がなければなかなかできないことなのだな
つまりハーメルンの笛吹き男状態。もし悪意がない、つまり
確信犯なら究極のバカ。どっかのエロゲプログラマ状態だ

860 :名前は開発中のものです。:2009/09/16(水) 02:39:24 ID:yeawCnxX
>>859
素人にタスクシステムを使えなんて勧めてるタスカーなんて居たか?過去スレでも見たこと無いぞ。
アンチの発言があまりに突っ込みどころ満載なんで、おもわず突っ込んでるだけで。

861 :名前は開発中のものです。:2009/09/16(水) 02:51:06 ID:8HYG9zOk
すまん

862 :名前は開発中のものです。:2009/09/16(水) 02:59:03 ID:vM/2nlR7
>789 で update_enemies の中身を出してないのは
そこがタスクシステムに似てるのを隠すためかな。
>117 も肝心の each_type 周辺を隠してるのよね。
再三動くコード出せと言われてるのにずっと無視し続けてるし
結局 >206 のいう白痴のふりを実践してるのかな。

863 :名前は開発中のものです。:2009/09/16(水) 03:14:37 ID:B/vr+pyS
>>862
>789 の update_enemies() に、仕様によっては「タスクシステムっぽい」何かが
入ることはあるかもしれないけど、仕様によっては入らないこともあって、つまり
どうでもいいんでしょ。

これに対して、ゲームなら必ずすべて「タスクシステム」が必要になるかのような
ことを言い出すから、おかしな話になるわけで。

864 :名前は開発中のものです。:2009/09/16(水) 05:20:47 ID:yP8KOrYy
でも実際にタスクシステム使う使わない云々は置いといてその考えを知るだけでもプログラミングの参考にはなるがな
あと俺もクラス名先頭小文字は気持ち悪いな
あと、ボスと雑魚は同じ敵タスクの派生オブジェクトのリストで回す方がやりやすいと思うが
まあそこでボス依存の雑魚の処理はその部分はタスクオブジェクトをツリー状にするというやり方もあると思う
それでボス死んだら子分も自滅するとかさせたり

865 :名前は開発中のものです。:2009/09/16(水) 06:45:27 ID:9rR5lXOa
>>864
>あと俺もクラス名先頭小文字は気持ち悪いな
気持ち悪いってだけで大した理由も考えずにそこで思考停止?w
お前がMSにあわせちゃうとMSのAPIと区別できないじゃん
実用的な面はまったくみずにただの気持ち悪いってだけで決定しちゃうの?
こういうこと繰り返してるからまったく成長しないんじゃない?

>まあそこでボス依存の雑魚の処理はその部分はタスクオブジェクトをツリー状にするというやり方もあると思う
まだいってる・・・馬鹿だろw
ボスと雑魚の間にステータスがあるんだから面倒臭がらず用意しろよ
なんで用意しないの?
現場でいっしょに仕事してたらぶん殴ってる

866 :名前は開発中のものです。:2009/09/16(水) 06:53:48 ID:qKixyWvM
殴られたら警察沙汰にする

867 :名前は開発中のものです。:2009/09/16(水) 07:15:53 ID:X/yeAXR1
>>865
> お前がMSにあわせちゃうとMSのAPIと区別できないじゃん

APIは関数呼び出しなんだから、末尾に () がついてるわけで、ソース見ればすぐにわかる。

一方、大文字でクラス名を始めないと、同名の変数名とバッティングする。
お前、きっとゴミクズみたいなソース書いてるんだろうな。



868 :名前は開発中のものです。:2009/09/16(水) 07:17:36 ID:X/yeAXR1
>>852
> 釣り宣言とかね。いい歳してやっちゃ駄目。最後まで演じ切る。大人の常識

釣り宣言なんか俺はしてねーぜ。

お前、本当にめんたまついてんのか?
>>859には>>860みたいな指摘がついてるし、お前は早とちりが過ぎる。



869 :名前は開発中のものです。:2009/09/16(水) 07:18:49 ID:X/yeAXR1
>>858
> なったんで、タスクシステムをカスタマイズ・機能強化して対応しました」とか得意げに
> 言ってるやつがいるとか・・・

俺を勝手にそんな馬鹿タスカーと一緒にしないでくれ。

870 :名前は開発中のものです。:2009/09/16(水) 07:20:15 ID:X/yeAXR1
>>851
>>taskSystem.setPriority(XX)
>>ってして順番指定するだけでそれが出来る。
> 全てをそれで制御しなきゃならなくなる弊害は考えないんだな。

弊害って具体的に何だと思ってるんだ?言ってみ。


871 :名前は開発中のものです。:2009/09/16(水) 07:25:32 ID:X/yeAXR1
>>852
> タスクシステムのリンクリスト(実行待ちキュー)内での位置関係で
> 生残OBJ同士の関連性(親子関係、コンストレイント)も表してしまおう
> という発想がイカレているのだ。コンテナの流用、機能の癒着、混濁。

コンテナの流用を悪みたいに思っているところは、あんたが現場経験のない素人プログラマゆえんだな。

基本的にメモリ節約&パフォーマンス重視。コンテナ流用できるなら流用して当たり前。

もちろん、流用してそれで設計が複雑化したりコーディングがややこしくなるケースなら流用しないがな。

872 :名前は開発中のものです。:2009/09/16(水) 07:31:18 ID:dJ8I9UGs
>>867
始めのwordだよ
つまりクラスならCunkoUtilになる

873 :名前は開発中のものです。:2009/09/16(水) 07:41:44 ID:X/yeAXR1
>>872
意味がわからない。

クラス名 → HogeClass
API呼び出し → HogeAPI();
変数名 → hogeClass

こうなっているから見ればわかると言うのが俺の主張。
これを、クラス名がAPIと紛らわしいから>>865

クラス名 → hogeClass
API呼び出し → HogeAPI();
変数名 → hogeClass

こう書くと言うことらしいが、これだとクラス名と変数名との区別がつきにくいと俺は言ってるんだ。

そもそも>>865みたいな奴がまともなプログラマのはずがなく、俺はただのキチガイだと思うんだが。

874 :名前は開発中のものです。:2009/09/16(水) 08:53:31 ID:yeawCnxX
命名規則の好みとタスクシステムに何の関係があるんだ?
タスクシステムって命名も気に入らないからとか言い出すのか?

875 :名前は開発中のものです。:2009/09/16(水) 09:10:55 ID:1qRFSdio
>>852
> タスクシステムのリンクリスト(実行待ちキュー)内での位置関係で
> 生残OBJ同士の関連性(親子関係、コンストレイント)も表してしまおう
> という発想がイカレているのだ。コンテナの流用、機能の癒着、混濁。

おっ。マトモな人がいるじゃんw

>>871
> 基本的にメモリ節約&パフォーマンス重視。コンテナ流用できるなら流用して当たり前。

おっと? 最終的にはソレしか言うことなくなっちゃうのかな?
マトモな人間は先に柔軟に設計し、プロファイラを使い、後でチューニングする。

876 :名前は開発中のものです。:2009/09/16(水) 09:27:14 ID:QTXjLpDB
タスクシステムを簡易プロファイラとして使えるのは便利だな

877 :名前は開発中のものです。:2009/09/16(水) 11:59:16 ID:p1fe8mfo
遠くて見づらいが都合の良い >852 を目立つように参照付き引用しつつ
都合の悪い >871 の最後の文をスルーして都合の良い敵像を演出するか。
>875 はとても参考になる。

878 :名前は開発中のものです。:2009/09/16(水) 12:08:26 ID:1qRFSdio
>>877
お前は何と戦ってんのw

基本的〜。もちろん、〜なら〜。

だからこれは、何を基本にして、何を例外にしている?
マトモな人にとって、それは全く逆だと言っている。

こうだ。

基本的には柔軟な設計をし、遅い箇所はあとで速くする。

で、お前はコンシューマでゲームなんて作ったこと無い、
などと言い出すんならお前は恥をかくことになるぞ。

879 :名前は開発中のものです。:2009/09/16(水) 12:49:56 ID:dJ8I9UGs
>>873
俺の出したクラスの例は無視かよ(笑)

880 :名前は開発中のものです。:2009/09/16(水) 15:36:37 ID:2LtlPZQN
>>878
柔軟な設計をしないとは書いてないだろ。
都合の良い解釈をして、それに反論することでその都合の言い解釈を
相手が主張しているように見せかける詭弁法だね。
根拠を見せずに一方的にマトモな人と表現することで
いかにも自論が多数派であるかのように見せかける詭弁法も使ってる。
最後の文は脅しなのかな。

敵だとは思ってないし正論で筋を通せばいいのに変な手を使われると
逆に人として負けた気分になる。>877はこっそり伝えたつもりだったのに。

881 :名前は開発中のものです。:2009/09/16(水) 20:42:10 ID:dJ8I9UGs
タスク信者は詭弁使い多すぎない?

882 :名前は開発中のものです。:2009/09/16(水) 21:25:37 ID:B/vr+pyS
詭弁だとか詭弁使いだとか指摘することに意味はないからやめてほしいな。
詭弁だというなら、その書き込みのおかしな点を指摘すればいいわけで。

>>880
> 柔軟な設計をしないとは書いてないだろ。

書いてあることだけ拾うと、 >871 で
「基本的にメモリ節約&パフォーマンス重視」という方針で、
「コンテナの流用、機能の癒着、混濁」を受け入れる姿勢が示されている。

機能ごとに明確に分割されたプログラムは、変更の影響の範囲も明確で、
変化に対応しやすい。逆に「機能の癒着、混濁」があると、 >858 の例で
挙げているような、変化に対応しにくいプログラムのもとになる。

一般的に、プログラムが「柔軟」であるとは、プログラムが変化に
対応しやすいことを指す。

つまり、「機能の癒着、混濁」を「基本的に」受け入れてしまう姿勢では、
柔軟でないプログラムができあがりやすい。

>878 が言っている「柔軟な設計」について正確なところはわからないん
だろうけど、こういう解釈が一般的だと思う。

883 :名前は開発中のものです。:2009/09/16(水) 21:40:50 ID:9rR5lXOa
>>882
何を言ってるのかさっぱりわからない
柔軟ってのはタスクシステムの話なの?
処理順序がどうとかいうメリットの話はもうないの?

884 :名前は開発中のものです。:2009/09/16(水) 21:53:27 ID:B/vr+pyS
>>871
「コンテナの流用」が「基本的にメモリ節約&パフォーマンス重視」
という方針に基づいてるみたいなんだけど、どうしてコンテナの流用が
メモリの節約やパフォーマンスの向上につながるの?

むしろ、場合によってはコンテナを流用してしまうことで最適化の機会が
失われ、結果的にパフォーマンスダウンにつながりそうな気もする。

たとえば std::list のメモリオーバーヘッド(リンクリストのポインタぶん)が
問題になるようなら std::vector に変えるようなことが考えられるんだけど、
コンテナを流用している場合、共用してるプログラムのひとつでも std::list の
特性に依存しているものがあれば、そういった最適化ができないことになる。

この例はメモリについてのものだけど、速度についても同様の状況が発生する
可能性が十分考えられる。

885 :名前は開発中のものです。:2009/09/16(水) 21:56:29 ID:B/vr+pyS
>>883
たぶんあんたにとってはあたりまえの話を、 >880 向けに細かく順を追うように
書いてみただけだよ。無視してもらってかまわない。タスクシステムのメリットを
語る立場でも無いし。(むしろ聞きたいほう)

886 :名前は開発中のものです。:2009/09/16(水) 23:09:51 ID:6WKuEleu
このバカタレ(ID:/yeAXR1)の言うことに耳を傾けないで欲しい。釣り針デカ過ぎ。
吐く台詞の大半が典型的反面教師、アンチパターンの王道を突進してるからな。
最適化ありきでゴミ屋敷を作ることを是認する人間が昔は当たり前だったなんて
思わないで欲しい

タスクシステム(とは呼んでなかったが、こういうような仕組み)は、RAMが少なく
アドレスバスが狭くROMをバック切り替えするレトロなハードでは平凡そのもの。
単位時間当たりにこなすべき仕事をパイプラインに突っ込んでバッチ処理。
ASMではなんのことはない。素直。そして自由。各タスクはフィルタ。鎖で繋ぐ。
Pipes and Filters。データの受け渡しは共有メモリ。シーンが変わればROMの
バンク切り替えでフィルタを交換。そんな感じだ。あとはケースバイケースで
割込ハンドラが非同期に突っ込むタスクがあったり。デバイスドライバのタスク。

組み込み系の知見があるならこのバカタレ(ID:/yeAXR1)のRDQの使い道が
とち狂ってることにすぐ気付く








省メモリ、性能を追求する前にやるべきことをやれということ

共用空間をゴミ屋敷にする人間だ
私は何がどこにあるか分かるから住み心地が良いという
タスクシステムの処理のパイプラインである

887 :名前は開発中のものです。:2009/09/16(水) 23:11:01 ID:6WKuEleu
最後の4行はゴミ。2ちゃんねるの書き込み難しいからオジサン即時撤収

888 :名前は開発中のものです。:2009/09/16(水) 23:14:03 ID:nhV6+DhU
>>881
生き方そのものが詭弁なんだろうよ。
都合が悪くなるたびに、極少例の事例を挙げてあーだこーだいう。
局所的に対応しろよ。全部を同じやり方でやる必要なんてねーよ。
そんなことしてたら、結局タスクシステム拡張しつづけないとゲーム作れない。
タスクシステムとタスクという切り分け自体に意味が無くなる。

> >>117 も肝心の each_type 周辺を隠してるのよね。
かくしてねーよ。マクロの中身は>>529で示しているのに、
型名が小文字で始まってるから読む気しないと言われた。
もうむちゃくちゃだろ。どうしろっていうんだよ。

こんなところでコーディングスタイルの話をしても仕方ないが、
俺は、単語と単語の間はアンダーバーで繋ぐ派の人なんだ。
でも、そんなことどうだって良いだろ。

889 :名前は開発中のものです。:2009/09/16(水) 23:16:38 ID:6WKuEleu
×バック切り替え
○バンク切り替え

×ID://yeAXR1
○ID:X/yeAXR1

890 :名前は開発中のものです。:2009/09/16(水) 23:35:09 ID:oHTMG8q0
落ち着けよオッサン。そいつが頭おかしいのは既に感づかれてるからよ

891 :名前は開発中のものです。:2009/09/17(木) 00:21:24 ID:mjmEkStk
>>888
>型名が小文字で始まってるから読む気しないと言われた。
>もうむちゃくちゃだろ。どうしろっていうんだよ。
型名を大文字で始めればいいんじゃね?

892 :名前は開発中のものです。:2009/09/17(木) 08:36:14 ID:FkJnIZGb
揚げ足取りにしても三流過ぎる

893 :名前は開発中のものです。:2009/09/17(木) 10:14:14 ID:vYS2gYMy
>>888
> > >>117 も肝心の each_type 周辺を隠してるのよね。
> かくしてねーよ。マクロの中身は>>529で示しているのに、
> 型名が小文字で始まってるから読む気しないと言われた。
> もうむちゃくちゃだろ。どうしろっていうんだよ。

「マクロの中身」って、言えば当然マクロの定義を示すべきだろ。
>>529 がマクロの定義か?馬鹿じゃねーの。

894 :名前は開発中のものです。:2009/09/17(木) 14:56:05 ID:sfNcjd3s
タスクって毎フレームの処理や描画を行うプログラムをコンポーネント化するときに便利だから使ってるんじゃないの?w

895 :名前は開発中のものです。:2009/09/17(木) 17:00:06 ID:kuOcRohK
>>1
だから、さっさと射程1000kmオーバーのMRBMに相当する標的を使えと。
もう何年も前から言われ続けてることだろうが。
射程120kmのしょっぱいSRBMをHit to Killできましたー、じゃお話に
ならないんだよ。

896 :名前は開発中のものです。:2009/09/17(木) 17:02:28 ID:kuOcRohK
ゴバーク

897 :名前は開発中のものです。:2009/09/17(木) 17:55:37 ID:5oGvD2YZ
溺れる者は藁をも掴む。
ITドカタはタスクシステムをも掴む。

898 :名前は開発中のものです。:2009/09/17(木) 18:12:08 ID:sfNcjd3s
何もつかめない君へありがとう

899 :名前は開発中のものです。:2009/09/17(木) 21:37:05 ID:tUdTLcNc
例の彼はもう来ないのかな。

900 :名前は開発中のものです。:2009/09/18(金) 00:20:25 ID:O5edBNya
>>4これテンプレ殿堂入り確定だろ

901 :名前は開発中のものです。:2009/09/18(金) 00:43:13 ID:iBnffFgI
じゃぁ>>1-4がテンプレで>>950が次スレを立てるってことで

902 :名前は開発中のものです。:2009/09/18(金) 00:54:52 ID:hh7+mZiP
>>871
お前は整理整頓されたものを引っ掻き回して全てを台無しにしてしまうタイプだよ
テーブルナプキンで尻を拭いて皿を拭いてしまうような奴はこれからも一人で
仕事をすればいい

903 :名前は開発中のものです。:2009/09/18(金) 01:16:26 ID:hh7+mZiP
>>886
> 単位時間当たりにこなすべき仕事をパイプラインに突っ込んでバッチ処理。

フレーム単位にこなすべき仕事を繋ぎ合わせてバッチ処理はしているが
パイプラインというのはちょっと違うと思うぞ…。そういう使い方に制限して
使うという話なら分かる

タスクシステム自体はタスク間のデータの受け渡し方法に関知してない
ただのバッチ処理だから実行中のタスクは全リソースにアクセスできる
Pipes ans Filtersのような使い方で拘束するなら、データの受け渡しは
隣接タスク間限定。そういう制限はタスク同士で取り決めるルール

あと、君が言う割り込みハンドラが非同期に突っ込むタスクってのも
前後タスクとのデータの受け渡し、依存関係はないと思う。挿入すれば

パイプラインの分断になるからやっぱりPipes ans Filtersという説明は
違うと思う。ただのバッチ処理、順次処理だ




904 :名前は開発中のものです。:2009/09/18(金) 01:16:56 ID:imA/2wk9
>>799
固定してるのはメインループではなくメモリ
そこがわかってないとメモリの話をすっとばして
プリエンティブばかり目がいってしまい
本物のタスクシステムを見失う

>>807
ボーランド社員乙

>>808
想定ターゲットの違いがタスクシステムの存在理由の違いとなりえる
このレスについて言えるのはそれだけだな

>>812
クラス名は大文字CをつけるのがMSルールだろ

>>822
この問題定義だとそれが最適解だろwww

>>834
そこはプロキシパターンだろ(キリッ

>>864
パターンのひとつとしておもしろいけどネットでググると混乱するのでススめられん
だからタスクシステムよりアルゴリズム集見て欲しい希ガス
まぁ、いわゆる情報処理系の本は業務システム寄りになっちゃうのが難だが

弾幕時代のデータ構造はクアッドツリーだよな
リストじゃもう処理が間に合わないだろう
3DSTGから来た定番処理だが2Dゲームも複雑さが増したせいで
オーバーテクノロジーじゃなくなってきた

905 :名前は開発中のものです。:2009/09/18(金) 01:19:12 ID:imA/2wk9
>>888
アンダーバーはC言語(非C++)の文化
単語ごとに先頭を大文字にするのはC++の文化
先頭のみ小文字で2つめ以降の単語を大文字にするのがDelphiの文化

変数名を見れば出自がわかる
育ちの卑しさは隠しきれない

906 :名前は開発中のものです。:2009/09/18(金) 01:20:36 ID:O5edBNya
聞けば聞くほど酷いシステムだなw

907 :名前は開発中のものです。:2009/09/18(金) 01:25:28 ID:O5edBNya
物事を考える手順を間違えてるよね
一番複雑になるのはどうしたってゲームオブジェクト同士の関連部分だよ
ここをどうにかする仕組みを考えるならいいけど
タスクシステムはハナからこの世に入らないw
まあ、それがわかっただけでもいいけどね

今度もしこういうフレームワーク的な何かを作るなら
ちゃんと問題のプライオリティを考えてそれを解決できるようなもんを作ってほしいな

908 :名前は開発中のものです。:2009/09/18(金) 01:26:24 ID:r3l2418c
タスクシステムとは一見魔法のように便利なシステムとして紹介されることが多いがその実態を知れば知るほど幻滅するものである

909 :名前は開発中のものです。:2009/09/18(金) 01:32:10 ID:imA/2wk9
信じたものは都合のいいタスクを繰り返し送り出すリスト
割り込みをやめ叩きつけるように走る
最高速のメインループ

910 :名前は開発中のものです。:2009/09/18(金) 01:37:53 ID:gkwWku0M
>>909
タスカーにしてあげる
だからちょっと覚悟しててよね

911 :名前は開発中のものです。:2009/09/18(金) 01:39:17 ID:IHfdZwXv
消失乙

912 :名前は開発中のものです。:2009/09/18(金) 01:59:03 ID:hh7+mZiP
>>907
お前はパンに付けるジャムの作り方を聞いている。パンは既に誰かが用意してくれてる。
ところがタスクシステムはパン生地の作り方から話が始まってる。しかも与えられた
道具も材料もとても貧しい。出発点がまるで違うということ。何もかも与えられた飽食の
時代の子にはそれが分からない。ある意味で正常。しかし食糧難時代の食事の作り方を
バカにするのは愚かだ。古典的な時間駆動(周期駆動)型のリアルタイムシステムの
プログラム構成を知れと言っていたのはそういうこと。幻想から目が醒めたかい?

食糧難時代の雑炊や麦飯を珍味と喜んだりするのがタスク信者は頭おかしいので
どうでもいい。

ところで

>一番複雑になるのはどうしたってゲームオブジェクト同士の関連部分だよ

STGすら作れないアンチは相変わらず哀れだな

913 :名前は開発中のものです。:2009/09/18(金) 02:35:35 ID:hh7+mZiP
>>904
>弾幕時代のデータ構造はクアッドツリーだよな
>リストじゃもう処理が間に合わないだろう
               ハ        _
    ___         ‖ヾ     ハ
  /     ヽ      ‖::::|l    ‖:||.
 / 聞 え  |     ||:::::::||    ||:::||
 |  こ ?  |     |{:::::‖.  . .||:::||
 |  え      |     _」ゝ/'--―- 、|{::ノ!
 |  な 何   |  /   __      `'〈
 |  い ?   ! /´   /´ ●    __  ヽ
 ヽ      / /     ゝ....ノ   /´●   i
  ` ー―< {           ゝ- ′ |
        厶-―    r  l>        |
      ∠ヽ ゝ-―     `r-ト、_,)      |
      レ^ヾ ヽ>' ̄     LL/  、   /
      .l   ヾ:ヽ ` 、_      \\ '
     l    ヾ:ヽ   ト`ー-r-;;y‐T^
      |    ヾ `ニニ「〈〉フ /‖. j
リストってのはタスクシステムのリンクリスト(実行待ちキュー)の話か?
何の処理が間に合わないって?
四分木がどうのってのはどうせ空間分割の話をしてるんだろうが
それがタスクシステムスレとどう関係してくるんだ?まさかお前は
タスクシステムのリンクリスト(実行待ちキュー)に空間分割の役割まで
与えていたのか?お前も靴磨きのブラシで歯を磨くような奴なんだな




914 :名前は開発中のものです。:2009/09/18(金) 06:11:56 ID:O5edBNya
>>912
は?何が主張したいのかさっぱりわからない

915 :名前は開発中のものです。:2009/09/18(金) 07:54:23 ID:rZCkWszn
スレ違い気味だけど、

ゲーム内オブジェクトの管理方法の比較的新しいものとして
component-based entity system[1]があるんだけど、
そいつにはパフォーマンスの低下以外に、それぞれのcomponent同士の
対話をどうするかというような問題がある[2]らしい。
パターンとしてobserver patternがあるけど、これにもobserverそのものが
複雑になるという問題があるしね。

でこれを見て、
>一番複雑になるのはどうしたってゲームオブジェクト同士の関連部分だよ
いうような類の問題は、システム部分の設計では解決しにくい問題なのかもしれないと思った。
んで、そういう認識の元では消極的だけど複雑な関連ができないようにロジックを簡略化する、
という道が考えられる。こちらの道にはまだ分割とか階層化とか余地はあるし、
システムでどうにかするよりかは楽そうに見える。

[1]game programming gems 5 1.3
[2]http://www.gamedev.net/community/forums/topic.asp?topic_id=463508

916 :名前は開発中のものです。:2009/09/18(金) 08:18:31 ID:hh7+mZiP
>>914
つまりセンスがない。だからタスクシステムという言葉に縋り付き、裏切られ、
そしてキャンキャン吠えているのだろう?

『ボクをバカにするな。ボクが夢想してたのはそんなちっぽけな仕掛けじゃない』
『ボクの夢想しているエターナルフォースブリザードシステムはそんなもんじゃない。』

『今度もしこういうフレームワーク的な何かを作るなら、ちゃんと
       【ボクの問題のプライオリティ】を考えて
              それを解決できるようなもんを作ってほしいな』

お前の問題のプライオリティはゲームを作れないおつむをまず何とかすること。
ゲームが作れないのだからタスクシステムがどうのとか以前の問題だったのだ

917 :名前は開発中のものです。:2009/09/18(金) 09:04:56 ID:XtFoYUxh
new tasksystem ◆9ycqcAuWxdGZ は涙目で敗走いたしました。

918 :名前は開発中のものです。:2009/09/18(金) 10:23:23 ID:kdotzuai
いまだにタスクシステムの利点がわからないとか、そんな奴、ゴミムシ級の自称プログラマだろ。

919 :名前は開発中のものです。:2009/09/18(金) 10:42:30 ID:XtFoYUxh
ゴミムシ級の自称プログラマ>>>タスクシステムの利点が分る王様

920 :名前は開発中のものです。:2009/09/18(金) 11:39:32 ID:kdotzuai
ゴミムシが吠えてやがるな プププ

921 :名前は開発中のものです。:2009/09/18(金) 12:24:59 ID:io3ofiC7
なんかアンチって箸使う利点がわからないって人と同じ感じだな。
A:ナイフとフォークしか知らない西洋人
B:素手で食べる原始人
のどちらかのタイプ。

まぁフランス料理屋で箸を頼むとかは馬鹿のすることだけど
和食屋でナイフとフォークを頼んだり、素手で食ったりするのも馬鹿だろ。

Aのタイプは、文化によっては違う食器で食べることもあるって想像力が欠けてるし
Bはそれ以前に文明をしらないから話にならない

922 :名前は開発中のものです。:2009/09/18(金) 14:05:18 ID:MPj7wkX5
ねえねえ、各処理をコンポーネント化する為に便利とかって視点はぜんぜんないの??>タスクシステム

923 :名前は開発中のものです。:2009/09/18(金) 14:20:32 ID:T5bNNtYz
>>921
俺様も使ってる和ゲー業界の常識であるから文化を尊重してお前らも
タスクシステムを使うべきだ(メリットなんかなくっても)ということですね、
わかりますん。

924 :名前は開発中のものです。:2009/09/18(金) 15:14:02 ID:MPj7wkX5
>>921
おれは、すしくうときは素手ですおー

925 :名前は開発中のものです。:2009/09/18(金) 17:03:48 ID:jMO+floB
で、言うんだよね
「アメリカで結論が出た日本は従え」

オブザーバーが複雑ってw
デザパタ涙目wwwwwwwwwwwwwwwwww

926 :名前は開発中のものです。:2009/09/18(金) 17:04:33 ID:io3ofiC7
>>923
「箸が要らない」って意見の否定≠「箸しか使うな」ってのはわかる?

>>924
すしがあるから箸は要らない、と・・・?
サンドイッチがあるからナイフとフォーク要らないとか言う馬鹿は居ないと思うけど。

927 :名前は開発中のものです。:2009/09/18(金) 17:05:07 ID:jMO+floB
あえて、あえて言おう!

  ど こ の 小 学 生 で す か ?   と ! ! !

928 :名前は開発中のものです。:2009/09/18(金) 17:07:09 ID:jMO+floB
しかし、ごめんね
裸の王様の洋服やぶいちゃった
もうくやしくてこないだろうねw
ネタがなくなってごめんね

こんな政治家並のたとえ話で、根本的に技術の話のできないクズが残って

929 :名前は開発中のものです。:2009/09/18(金) 17:16:53 ID:13PfNHgB
敵味方入り乱れて乱戦状態

930 :名前は開発中のものです。:2009/09/18(金) 17:18:35 ID:Y5nvgFEQ
何このスレおもすれー

もっとやれ

931 :名前は開発中のものです。:2009/09/19(土) 02:25:50 ID:UsvlV3Ou
>>921,926
「タスクシステム」は箸でもナイフでもフォークでもなくて、例えて言うなら
 「ナイフとフォークを2つ合わせて逆にもてば箸にもなるんじゃね?」
 「箸にも使うんだったらもうちょっと軽い素材にしたほうがよくね?」
 「もっと箸っぽく、先っぽを細くして、と、できたできた。」
 「ナイフの部分を手で持つとあぶないから、もうちょっと長くして持つとこ広くしたほうがよくね?」
 「いいね。さて、俺様の発明したこの画期的な道具を何と呼ぼう?」
 「和食にも洋食にも使える道具だから、『食具』とかいいんじゃね?」
 「『食具』か。聞いたことないし、なんかかっこいいな。それでいこう。」
って感じ。

確認してみよう。
 「関数ポインタと汎用ワーク合わせてリンクリストに突っ込めばリスト一個でいいんじゃね?」
 「全体で使うんだったらもうちょっとメモリ確保高速化したほうがよくね?」
 「もっとシステムっぽく、マクロで包んで、と、できたできた。」
 「処理順ごっちゃになるとあぶないから、処理優先度設定できるようにしたほうがよくね?」
 「いいね。さて、俺様の発明したこの画期的なシステムを何と呼ぼう?」
 「どんなゲーム中の処理にも使える道具だから、『タスクシステム』とかいいんじゃね?」
 「『タスクシステム』か。聞いたことないし、なんかかっこいいな。それでいこう。」
うん。ぴったりだね。

932 :名前は開発中のものです。:2009/09/19(土) 03:41:18 ID:dU0nt+Sd
>>931
タスクシステムで作られたゲームはたくさんあるけど
> 「ナイフとフォークを2つ合わせて逆にもてば箸にもなるんじゃね?」
なんて人は見たこと無いなぁ・・・比喩として成り立ってないんでない?
片方は実際に使われて実績出してるし、もう片方は存在しない前提。

それともタスクシステム使ってるゲームなんて都市伝説。
そんなゲームあるわけない。と思ってる人?

933 :名前は開発中のものです。:2009/09/19(土) 04:37:57 ID:lylhPpfZ
俺のやり方はタスクシステムの良さを取り入れ、それに柔軟性を持たせた感じ

934 :931:2009/09/19(土) 04:38:40 ID:UsvlV3Ou
>>932
そういうツッコミが出てきて話が発散するから例え話は危ないんだよな。

違いがまったく無ければそもそも比喩を使う意味が無いんだけど、
違いがあればその大小にかかわらず「それとこれとは違う」というツッコミを
入れる余地が生まれてしまうわけで。

というわけで、例え話を抜きにして改めて言いたいことを書いてみよう。


「タスクシステム」と呼ばれるものの多くがひとつのコンポーネントで
まとめて提供しているような複数の機能(動的コンテナ、関数ポインタ、
メモリプール、など)は現代のプログラミング環境ではそれぞれ個別の
機能として取捨選択できるものであり、そうしたほうが不要な機能のための
複雑さを押し付けられることがないので望ましい(そうしないと不要な
機能のための複雑さを押し付けられて嫌だ)ということ。

がんばって全部の機能が同時に有用であるケースをひねり出そうと
していた人が居たけど、そういうケースを挙げてもらったとしてもこの点は
変わらない。また、それだけ限定されたケースで使うコンポーネントで
あれば、「タスクシステム」などという実態を表さない名前よりももっと
具体的で良い名前が決められるはずだろう、とも思う。


ここまで読めば、 >931 の比喩でどこを対比させているのかわかって
もらえるんじゃないだろうか?

935 :名前は開発中のものです。:2009/09/19(土) 08:17:28 ID:FFEDWGft
>>903
俺はPipes and Filtersという表現はなるほどなーと思ったよ。
  $ cat ゲームデータ | Filter処理1 | Filter処理3
  $ cat ゲームデータ | Filter処理2 | Filter処理1 | Filter処理3
  $ cat ゲームデータ | Filter処理2 | Filter処理3
アセンブラで実装した概念はこれってことでしょ。だいぶ割り切ってる。

まず「レトロな」という言葉からタスクシステムが考案された状況を想像する。
 ・言語に変数の概念が無い(アセンブラ)
 ・言語に関数という概念が無いかも(アセンブラにcall, retが無いとか)
 ・メモリ割り当て、ジャンプ先アドレスは自分で管理する
 ・CPUはZ80かそれよりもっと古いもの。レジスタは8bitとか4bit幅。
 ・コード書き換えの際に少しでも間違えたらターゲット環境が暴走
 ・RAM/ROM少ない。コード変更後アセンブルしたら想定より1byte容量が増えて
  他の人が使ってるメモリ領域上書きしちゃった、というのも有り得る程度。
 ・クロス開発。ROM焼きしないと動作確認不可。コード変更後の確認超面倒。

こういう状況下だったら「データ」より「処理」の方が変更しづらくやっかいで
重要なものと認識されてもおかしくない。
データ変更はサイズ変化しないしまだ取り扱いが楽、みたいな。
そうなると、
 1、処理はあまり変更したくない小分けにして汎用的にしよう
 2、「処理(要アセンブル)」を減らして「データ(アセンブル不要 or DataByte命令で記述可)」を増やそう
 3、RAM/ROM少ないしCPUも遅いからゲームオブジェクトは少なくて良い
 4、ゲームデータに「処理(Filter)」をどういった順序で適用させるか、
   それを「データ」の変更だけで指定可能にすべき
という流れでPipes and Filtersの概念に昇華したのかなぁと。そう思った。

もしこれがレトロな環境でのタスクシステムの概念・狙いだって説明されたら俺は納得できるよ。
C言語以上の高級言語を使用&32bit以上のCPUならこのシステム必要ないなとも言えそうだし、アンチ的にもOK

936 :名前は開発中のものです。:2009/09/19(土) 08:33:41 ID:zmEgoqfC
>>905
C++プログラマーにはろくなのがいないから、これでいいんだよ。
オブジェクト指向はリソースの管理がうまいだけで、それ以外はさっぱりだ。
オブジェクトごとにカプセル化しようという概念が既におかしい。
カプセル化は機能単位ですればよい。
つまり、一つのソースコードファイル内で閉じてればそれで問題ないんだよ。
生のオブジェクトを受け渡して、呼び出し側でゲッターやセッターを呼んでもらう設計は愚か。

937 :名前は開発中のものです。:2009/09/19(土) 10:16:09 ID:zmEgoqfC
あー、いちおう断っておくけど、オブジェクト指向が駄目と言ってるわけではないよ。
オブジェクト指向でも、機能ありきで切り分けてあるのはよい。
オブジェクト指向という名前そのままに、オブジェクトありきで切り分けてるのは糞。
そういうのはプログラムも糞なんだけど、作った奴そのものも糞で、関わりあいたくない。
時間の無駄と言うか、不快というか。

938 :名前は開発中のものです。:2009/09/19(土) 10:31:17 ID:mS5voKRg
>>931
先割れスプーンとかショクシとか実際にあるもので例えればいいんじゃね?

939 :名前は開発中のものです。:2009/09/19(土) 11:51:29 ID:/N8izgdv
ほんとうに気持ち悪いのはおまえだけ


ほんとうに気持ち悪いのはおまえだけ〜
あたりまえのことと思ってても
ほんとうに気持ち悪いのはおまえだけ〜さ〜
いますぐにgo to hell

940 :名前は開発中のものです。:2009/09/19(土) 11:58:32 ID:/N8izgdv
それでオブジェクト指向をキチガイ扱いしてるのか
タチ悪すぎだな

ま がんばってアセンブラでやっちゃってくださいよ

941 :名前は開発中のものです。:2009/09/19(土) 12:05:17 ID:/N8izgdv
こうしてアセンブラ同士の仲良しクラブ(小学生発想)が生まれ
匿名のまま なにの進歩もなく スレは続くのでした

942 :名前は開発中のものです。:2009/09/19(土) 12:06:58 ID:/N8izgdv
相手の話を聞き入れない
「気に入らん」
で終わるクソオヤジですね

943 :名前は開発中のものです。:2009/09/19(土) 12:11:19 ID:/N8izgdv
そして糖尿病になって
「へるぱ〜しゃ〜ん、くつした はかして〜」
ってなるんだね
もう50,60歳だろう 人生この先進歩してもしょうがないんだろう
あとは死ぬだけw

944 :名前は開発中のものです。:2009/09/19(土) 12:43:26 ID:bBOoXAfg
それで、屁理屈ばっかり言って子供や部下をないがしろにし
でも、部下の案の方が優秀で、上司もそっちを採用し
つかわれなかったクソオヤジどもが手を組み
新人をここぞとばかりにいじめぬく最悪な連中
犬畜生にも劣る軍団

部落ってあったんだ
もう人生先あまりないしねw

945 :名前は開発中のものです。:2009/09/19(土) 12:45:38 ID:/+1qnMv8
元はどうあれ、昨今のタスクシステムは糞設計でございます。
さぁ、具体的な反論が出なくなってまいりました。

946 :名前は開発中のものです。:2009/09/19(土) 13:10:35 ID:HpgjGovv
まだタスクシステムのメリットすらわからないキチガイがいるのかwww

ゲー専は本当にだめだな

947 :名前は開発中のものです。:2009/09/19(土) 15:11:57 ID:/+1qnMv8
偏見と決め付けだけw もうお手上げのご様子w

948 :名前は開発中のものです。:2009/09/19(土) 15:47:37 ID:HpgjGovv
メリットすらわからないってどう見てもお前ゴミクズだろw

社会の役に立たないゴミクズがゲーム作ってんなwww

949 :名前は開発中のものです。:2009/09/19(土) 16:25:58 ID:bBOoXAfg
メリットの前にはシャンプーだよね

950 :名前は開発中のものです。:2009/09/19(土) 16:46:00 ID:f6POrpr/
>>934はシャンプーとリンスは別々に提供すべきって話だったのか

951 :名前は開発中のものです。:2009/09/19(土) 16:53:18 ID:xkwU29ud
>>935
pipes and filtersという表現をなるほどなーと思うのは自然なこと
cyclic executiveの長所とかぶるところは多いからな
ただデータフローは必ずしも一致するわけじゃないってこと
pipes and filtersの要素の繋がりは処理フローとデータフローを表してるが
ready queueとかfunction queueのそれは処理フローしか表してないからな
各タスクの扱うデータ(入出力)については各タスクで設定してる

あとタスク分割の方針も必ずしも一致するわけじゃない
pipes and filtersでは純粋に機能分割で再利用性を高めるが
cyclic executiveはプリエンプションなしのタスクによる
人力スケジューリングの仕組みでもあるから時間分割も考慮
しないといけない(場合がある)。各タスクの処理時間制限に
ひっかかってしまう場合ね。この場合の分割は必ずしも
再利用性と一致しない

例えば戦術情報を取得して意思決定を行ない隷下の部隊に指示を出すコマンダー
捜索・索敵モードのAIタスクは数〜数十フレームにわたって処理を分ける
これは必ずしも機能分割と一致しない




952 :名前は開発中のものです。:2009/09/19(土) 17:32:18 ID:bBOoXAfg
どう考えても new tasksystem ◆9ycqcAuWxdGZ やんこいつ

953 :名前は開発中のものです。:2009/09/19(土) 18:00:51 ID:xkwU29ud
>>952
つまりセンスがない。観察力がない。視野が狭い。想像力がない。
アンチはおつむに糞がつまってるから嗅覚までおかしい。哀れである。

new tasksystem ◆9ycqcAuWxdGZはやねうらおレベルの
高度な知的生命体であり、全くどうでもいい

それよりお前はさっさとゲームを作れるようになれ。話はそれからだ

954 :名前は開発中のものです。:2009/09/19(土) 18:27:19 ID:Y9+sDnj3
> new tasksystem ◆9ycqcAuWxdGZはやねうらおレベルの
> 高度な知的生命体であり、全くどうでもいい

やねうらおレベルなら超一流なんだろうけどな

955 :名前は開発中のものです。:2009/09/19(土) 19:31:49 ID:xkwU29ud
つまりコニャック片手にコイーバをくわえてるような
一流納税者のタスクシステムエヴァンジェリストが提唱する
近代的厚化粧ババァシステムはどうでもいいということだ

生娘状態で股ひらいてナニ見せたほうが童貞アンチの反応は面白い
ということに気づけばいいものを。ババァは中身に自信がないから
どうしても着飾って見栄を張ろうとする。哀れ

956 :名前は開発中のものです。:2009/09/19(土) 19:34:28 ID:1aotV8/8
また新たな電波システマーこないかな。

957 :名前は開発中のものです。:2009/09/19(土) 19:53:40 ID:HpgjGovv
アンチタスク = ゲームも満足に作れない自称プログラマ ってことだね。


958 :名前は開発中のものです。:2009/09/19(土) 21:05:12 ID:1aotV8/8
επιστημηwwww
http://blogs.wankuma.com/episteme/archive/2008/08/30/154702.aspx

なんというか、やねうらおの上位版みたいなやつだな。

959 :名前は開発中のものです。:2009/09/19(土) 21:25:51 ID:FFEDWGft
>>951
なんで"cyclic executive"の話題を出した

それはさておき"cyclic executive"ってハードリアルタイム用の実装手法でしょ?
ゲームプログラムはソフトリアルタイムだろうから厳密にその実装手法を使う必要が無い。
差が出てきて当然かと。

というか単にレトロなハードウェアが貧弱すぎて命令数単位で
CPUリソース管理しないといけないから手法改善してったら
結果的にcyclic executiveと似ちゃっただけなんじゃないの?

出発点は全然違うよ。きっと。
"pipes and filters"は泥臭い手法を取らざるを得ない状況をエレガントなもののように
言い表して現場のソフトウェア開発者の溜飲を下げることができる力があるが、
"cyclic executive"はソフトウェアをハードウェアの劣化版と見なす雰囲気が感じられる。

もしcyclic executiveの方が高等で高尚な概念だなんて言ったとしたら
ハード屋さんならいざしらず、ソフトウェア屋が聞いたらむかつくと思うが。

960 :名前は開発中のものです。:2009/09/19(土) 21:31:09 ID:1aotV8/8
優先度を宣言的に記述できる並行論理型言語
http://www.brl.ntt.co.jp/people/hirata/Papers/on-2000j.pdf
優先度み基づく 並行論理型言語
http://www.brl.ntt.co.jp/people/hirata/Papers/spa99.pdf

961 :名前は開発中のものです。:2009/09/19(土) 23:21:54 ID:DcUVi+Eq
>>959
ねぇねぇ、このアンチは結局何が言いたいわけ?誰か解説して

962 :名前は開発中のものです。:2009/09/19(土) 23:36:23 ID:FFEDWGft
>>961
1、"pipes and filters"について話している時に
  なぜあなたは"cyclic executive"の話題を持ち出したのですか?

2、一応"pipes and filters"と"cyclic executive"が似ているかどうか考えてみたのですが
  違うように思われます。
  ところでなぜあなたは"cyclic executive"の話題を持ち出したのですか?

と言いたいのですが。
HSPさん、おいたが過ぎるのではないですか?
"このアンチ"も一応人間ですよ? 割と傷つくんですが

963 :名前は開発中のものです。:2009/09/20(日) 00:02:09 ID:HvAEBPVo
キチガイアンチがキチガイHSPerを攻撃し始めました
本格的に頭おかしいなこいつらwwww

964 :名前は開発中のものです。:2009/09/20(日) 00:18:32 ID:5Lh0ngEB
>>962は前々から本格的に頭おかしかった例の童貞アンチだろ


965 :名前は開発中のものです。:2009/09/20(日) 00:48:21 ID:5Lh0ngEB
以前はアンチっていってももっとマトモなのがいたような気がするんだが…
どこいっちまったんだ?もう自縛霊化したクズしか残ってないじゃないか

アンチ陣営がだんだんかわいそうになってきたな…

966 :名前は開発中のものです。:2009/09/20(日) 00:53:49 ID:LV03WdEy
印象操作はもう通用しない、と。

967 :名前は開発中のものです。:2009/09/20(日) 05:37:52 ID:hEuQK+fK
聞きたかったら金だしな

968 :名前は開発中のものです。:2009/09/20(日) 07:12:22 ID:hEuQK+fK
>>317

>enum MazeChip
>{
> Blank, // 通路
> Wall, // 壁
> Bomb, // 爆弾
>};

とありますが 爆弾は迷路のchipではないですよね?

969 :名前は開発中のものです。:2009/09/20(日) 08:24:47 ID:sdLqnzAy
>>965
まともな頭をもったアンチはとっくにアンチなんて卒業してるよ

>>206
残ってるのはこんなアンチだけ。

970 :名前は開発中のものです。:2009/09/20(日) 10:49:04 ID:LV03WdEy
>タスクに有用性があるということを示したければ有用な条件で動く例を一つ出せば証明できる。
はやく証明してよ。

971 :名前は開発中のものです。:2009/09/20(日) 10:56:21 ID:sdLqnzAy
>>970
「はぁ?僕ちゃん理解できませんww」
まんま>>206だなww
釣りか?

972 :名前は開発中のものです。:2009/09/20(日) 11:01:34 ID:LV03WdEy
理解できなくてもいいから、早く証明してよ。

973 :名前は開発中のものです。:2009/09/20(日) 11:04:03 ID:LV03WdEy
タスクシステムは〜〜に有用って結論出して、
早くアンチやめたいなぁ。
〜〜に何が入るのか見ものだが。

974 :名前は開発中のものです。:2009/09/20(日) 11:05:56 ID:sdLqnzAy
>>972
だから違う反応してよ。
アンチは結局その反応しか出来ない、って>>206の主張の正しさの証明にしかなってないぞwww

975 :名前は開発中のものです。:2009/09/20(日) 11:15:13 ID:xKMy+mo5
なんだ、ここにきて >>4 に戻るのか。スレの回転業務、乙であります。

976 :名前は開発中のものです。:2009/09/20(日) 11:16:31 ID:hCl+HYNl
>>329 名前: new tasksystem ◆9ycqcAuWxdGZ [sage] 投稿日: 2009/08/27(木) 07:08:31 ID:T5IyzsGb
> きっちりまとめてCodeZineにでも投稿したほうがいいか?
> それならそうするが。

投稿して恥かくところはやく見せてくれよw

977 :名前は開発中のものです。:2009/09/20(日) 11:17:05 ID:LV03WdEy
>>974
違う反応するから、早く証明してよ。

978 :名前は開発中のものです。:2009/09/20(日) 11:24:28 ID:sdLqnzAy
>>977
んじゃ、まず>>2の否定からしてごらん。技術的に。
それが終わったら過去スレで上がった利点の全ての否定だ。
それを全て否定してもまだタスクシステムの否定にはならんけど、アンチがんばれ!ww

使用条件を限定しない限りアンチに勝ち目は無いよ。
「ある種の条件ならタスクシステムも有用」ってのを認めたらアンチ卒業なんだがなぁww

979 :名前は開発中のものです。:2009/09/20(日) 11:35:04 ID:hCl+HYNl
勝ち負けの話にしたがってるのか、相当視野が狭まってしまっているのか。
ある主張に根拠が示されていなければ、はっきりしていなければ、
疑問が投げかけられるのは当然のこと。問われてるのは主張の根拠。
勝ち目がどうの、アンチがどうの、読んでるほうはウンザリだよ。

俺は懐疑派だけど、有効性は無いか合っても微小かだと見てる。
つまり、積極的に採用する理由はまったく見当たらない。
アピールが足りないね。一言で言えるようなセールスポイントは無いのかな。
みんなを納得させるほどの大きい利点はまだ見えてない。

980 :名前は開発中のものです。:2009/09/20(日) 11:44:47 ID:sdLqnzAy
>>979
普通、方法の優劣は目的や仕様によって変わってくるんだけど
目的と仕様を明確にせずに優劣はつけられんわな。
でもアンチ君はそれを理解せずに「タスクシステムは無用」と主張するから>>206のようになるわけで。

> つまり、積極的に採用する理由はまったく見当たらない。
> アピールが足りないね。一言で言えるようなセールスポイントは無いのかな。
目的や仕様にかかわらずタスクシステムを積極的に採用しろ、なんて主張、過去スレにもどこにの
無いだろ?あったら出してくれ。ww

「魔法の杖は無い」ってことを理解できれば「タスクシステムは魔法の杖じゃない!だから無用だ!」
ってアンチは卒業できるんだよ。www

981 :名前は開発中のものです。:2009/09/20(日) 11:45:28 ID:LV03WdEy
>>978
俺にそんな義務は無い。
悪魔の証明って言うだろ。
証明義務があるのはタスクシステマー側。

982 :名前は開発中のものです。:2009/09/20(日) 11:50:33 ID:vD0LgNoZ
このスレいままで見てきていまだにタスクシステムのメリットがわからないとか言ってる奴が池沼だろwww

983 :名前は開発中のものです。:2009/09/20(日) 11:50:45 ID:sdLqnzAy
>>981
>>2で証明義務終わり。
反論どうぞwww

984 :名前は開発中のものです。:2009/09/20(日) 11:51:50 ID:LV03WdEy
>目的と仕様を明確にせずに優劣はつけられんわな。
だからさっさとタスクシステムが有益に働く場合の目的と仕様と挙げろよ。

985 :名前は開発中のものです。:2009/09/20(日) 11:52:04 ID:xKMy+mo5
ここにきて裸の王様ごっこをはじめたタスクシステム使いさんは >>934 の言うことに
ついてどう思ってるの?

986 :名前は開発中のものです。:2009/09/20(日) 11:52:17 ID:HvAEBPVo
>>979
みんなを納得させる?誰を納得させる必要があるって?
「ゲーム作ったことないボクはまだ納得できましぇん!許せない!」ってことでしょ
そんなクズまで納得させなくちゃならないならもう介護福祉ボランティアだなw

987 :名前は開発中のものです。:2009/09/20(日) 11:55:41 ID:hCl+HYNl
>>980
> 目的や仕様にかかわらずタスクシステムを積極的に採用しろ、なんて主張、過去スレにもどこにの
> 無いだろ?あったら出してくれ。ww

ムリヤリかお前は。

> 目的と仕様を明確にせずに優劣はつけられんわな。

そこは限定していいから。好きに限定していいから。
タスクシステムが最大に輝くように限定していいから。

この時はこんなにも有効ですよ、というのでいいから。
そのセールスポイントすら今は見えてないと思うが。

タスクシステムが最大に効果を発揮する時でさえ、
他の代替手段のほうがメリットを生むと見てる。俺は懐疑派だから。

988 :名前は開発中のものです。:2009/09/20(日) 11:55:41 ID:LV03WdEy
>>981
どういう場合に有益なのか、何も証明されて無いじゃん。

989 :名前は開発中のものです。:2009/09/20(日) 11:57:01 ID:sdLqnzAy
>>985
同じこと。彼の脳内で前提としている仕様ではタスクシステムが役に立たないってのと
ある条件ではタスクシステムが役に立つって条件は矛盾しない。
でも彼にはそれがわからない。ただそれだけ。

>>988
>>2のリンク先、ほんとにちゃんと読んだ?www

990 :名前は開発中のものです。:2009/09/20(日) 11:57:33 ID:hCl+HYNl
>>986
> みんなを納得させる?誰を納得させる必要があるって?

(ヾノ・∀・`)ナイナイ もちろんそれは無いよ。何の義務も無い。

ただし、この議論の流れの上では、キミにとって権利だと思うが。
タスクシステムのよさを、ズドンと示して懐疑派を黙らせるチャンスだと思うが。

991 :名前は開発中のものです。:2009/09/20(日) 12:02:18 ID:sdLqnzAy
>>990
タスクシステムなんて単純な仕組み、特に良さを宣伝しようと思ってるやつはいないよ。
使える条件は限られるし色々デメリットもあるしな。

ただ魔法の杖扱いして勝手に「裏切られた!」って絶望して騒いでるアンチみたいなのが居ると
からかってやりたくなるだけさ、「お前ら馬鹿だな」wwって。

992 :名前は開発中のものです。:2009/09/20(日) 12:02:53 ID:LV03WdEy
なんだ、結局使えないんじゃん。

993 :名前は開発中のものです。:2009/09/20(日) 12:04:13 ID:hCl+HYNl
>>991
> 使える条件は限られるし色々デメリットもあるしな。

じゃあさらに言葉を絞って尋ねたい。
キミにとって、タスクシステムのメリットは一個で言うと何?

俺は、「シビアなリソースで若干の抽象化を得ること」だと見てるけど?

994 :名前は開発中のものです。:2009/09/20(日) 12:04:49 ID:sdLqnzAy
JAVAとかC#しか知らん素人プログラマが「ポインタなんて糞、リスト使えばいいのにこんなの使ってる
CとかC++なんて無用!」とかスレがあれば「馬鹿はお前だww」って突っ込みたくなるのと同じだ。

995 :名前は開発中のものです。:2009/09/20(日) 12:05:15 ID:LV03WdEy
違うだろう。
唯一のメリットは「処理の順序を動的に変えられる」
だろ。それ以外にありえねぇ。

996 :名前は開発中のものです。:2009/09/20(日) 12:06:00 ID:LV03WdEy
なんか変なたとえ話はいりました〜〜

997 :名前は開発中のものです。:2009/09/20(日) 12:06:54 ID:hCl+HYNl
>>955
おk。キミの生の声を始めて聞けたきがする。

998 :名前は開発中のものです。:2009/09/20(日) 12:07:33 ID:sdLqnzAy
>>993
まぁ、そういう利点もあるわな。
実際、アーケードから組込みおもちゃから、色々なハードでやってりゃ嫌でもそーいうケースに出くわすし。
WindowsとかLinuxとか汎用機しか見たこと無いプログラマには理解不能な世界だろうけど。


999 :名前は開発中のものです。:2009/09/20(日) 12:07:53 ID:hCl+HYNl
>>993×一個○一言
>>997×>>955>>995

1000 :名前は開発中のものです。:2009/09/20(日) 12:12:41 ID:sdLqnzAy
結局>>206で終わってる話だ。


1001 :1001:Over 1000 Thread
このスレッドは1000を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。

451 KB
★スマホ版★ 掲示板に戻る 全部 前100 次100 最新50

read.cgi ver 05.02.02 2014/06/23 Mango Mangüé ★
FOX ★ DSO(Dynamic Shared Object)