[表示 : 全て 最新50 1-99 101- 201- 301- 2chのread.cgiへ]
Update time : 05/09 09:54 / Filesize : 120 KB / Number-of Response : 355
[このスレッドの書き込みを削除する]
[+板 最近立ったスレ&熱いスレ一覧 : +板 最近立ったスレ/記者別一覧] [類似スレッド一覧]


↑キャッシュ検索、類似スレ動作を修正しました、ご迷惑をお掛けしました

タスクシステム総合スレ



1 名前:名前は開発中のものです。 [2007/03/12(月) 23:09:48 ID:8bV5Boxt]
どうぞ

14 名前:名前は開発中のものです。 mailto:sage [2007/03/15(木) 21:06:26 ID:ZqsnR0zJ]
Javaでやろうとして挫折した。
ワーク構造体とそれをメンバとしてアタッチするラップクラスを作ったんだが
あまりにも気持ち悪くてそこでやめてしまった。

タスクシステムはCで書くから美しく見えるんじゃないかと思ってしまう。

15 名前:名前は開発中のものです。 mailto:sage [2007/03/15(木) 21:26:14 ID:EXzxsrWu]
JAVAってまともな構造体あったっけ?

16 名前:名前は開発中のものです。 mailto:sage [2007/03/15(木) 22:02:28 ID:qutq4pqL]
Javaならインターフェイスとコレクション使えばすぐできるだろ。
ちなみにフレームレートとかは無視する方向で。

17 名前:名前は開発中のものです。 mailto:sage [2007/03/15(木) 22:05:34 ID:yIBWThbm]
>>14
それは設計が悪いだけ。
ワーク構造体なんか作らなくても、
タスクインターフェースを実装した具体クラスに
好きな変数ガンガンぶち込めば済む。

18 名前:名前は開発中のものです。 mailto:sage [2007/03/15(木) 22:13:03 ID:ZqsnR0zJ]
>>15
ByteBufferってクラス使えば共用体っぽく使えるよ。
ベースはchar配列だけどね。

>>16, 17
極力オブジェクトプールしてくのがタスクシステムじゃなくて?

19 名前:名前は開発中のものです。 mailto:sage [2007/03/15(木) 22:25:27 ID:yIBWThbm]
別に>>16>>17の方法でもプールできると思うんだが…。

20 名前:名前は開発中のものです。 [2007/03/15(木) 22:37:01 ID:PMeVIICQ]
>>17
kwsk

動的生成するのかな?

21 名前:名前は開発中のものです。 mailto:sage [2007/03/15(木) 22:54:30 ID:yIBWThbm]
>>20
別になんてことはない。

interface Task {
  public void update();
  public void draw();
};

class Enemy implements Task{
  private int x;
  private int y;
  public void update() {x++; y++};
  public void draw() {/*ごにょごにょ*/};
};

例えばこんな感じで超テキトーに作ったとすると、
xだのyだのの部分がワーク構造体部分で
updateだのdrawだのが処理関数部分。

あとはTaskを格納するコンテナに
new Enemyだのnew MyShipだのぶち込んで
順番にupdateだのdrawだの呼び出せばいい。

22 名前:名前は開発中のものです。 mailto:sage [2007/03/15(木) 22:58:37 ID:XmQLFBDw]
ワークメモリを分割して使うようなやり方は、高級アセンブラたるC言語ならではといっても良いと思う。
C++ですらそのやり方は馴染まない。ましてや、Javaともなると、メモリ管理を極力隠匿してGCで
自動化しているわけで、それをわざわざ迂回しようとしてるのが>18なんだが、わかってる?
慣れたやり方でやろうとしてしまうのはわかるけども、もう少しオブジェクト指向とか勉強して欲しいとちょっと思った。



23 名前:名前は開発中のものです。 mailto:sage [2007/03/15(木) 23:00:47 ID:b1+VxKry]
オブジェクト指向というか言語仕様というか

24 名前:名前は開発中のものです。 mailto:sage [2007/03/15(木) 23:09:07 ID:ZqsnR0zJ]
それが気持ち悪いからまっさきに避けたんだが、平行線っぽいから議論はやめとく。

25 名前:名前は開発中のものです。 mailto:sage [2007/03/15(木) 23:11:29 ID:yIBWThbm]
>>22
そもそもタスクシステム自体は
全然オブジェクト指向ではないし、
なぜその文脈でオブジェクト指向が出てくるのか。

26 名前:名前は開発中のものです。 [2007/03/15(木) 23:16:11 ID:PMeVIICQ]
>>21
あー、やっぱりそれか・・・。
interfaceないころから、俺は、それでやってた。Javaでないけど。

問題は、メンバが変わるような場合なんですよ。

タスクシステムってのは、実行時に、頻繁にメモリ確保しないのが前提だと思うのですが、
>>21のだと、動的にオブジェクト生成しないといけんよなあ。
まあ、いまどきなら、それでもいいんだけど・・・。
プール使うのは、パーティクルぐらいでも十分の最近の現実。

27 名前:名前は開発中のものです。 mailto:sage [2007/03/15(木) 23:26:21 ID:yIBWThbm]
>>26
>>21の場合でEnemyが頻繁に出入りするような場合は
new Enemyで生成するのではなく、
Enemyを管理するEnemyFactoryクラスを作って
そいつからEnemyを引っ張ってくるようにすればいいだけ。
あなたが>>8で言っているActorのリストみたいなものを
EnemyFactoryに持たせればいい。

28 名前:名前は開発中のものです。 mailto:sage [2007/03/15(木) 23:33:05 ID:XmQLFBDw]
>>24
御意。

>>25
>そもそもタスクシステム自体は全然オブジェクト指向ではないし、
>なぜその文脈でオブジェクト指向が出てくるのか。

プロセスやスレッドだってオブジェクト指向じゃないけど、クラスとして実装されている。
Javaというオブジェクト指向言語上でタスクと同じ役割をするもの(大抵クラスだろう)を
実装するなら、オブジェクト指向からやらないと、オブジェクト指向言語と処理系が
やっていることを理解できないんじゃないかな。

29 名前:名前は開発中のものです。 mailto:sage [2007/03/15(木) 23:40:22 ID:EXzxsrWu]
>>21
その書き方だとたしかにJAVAらしいなあ。
ただ、そうすると、最初にワークスペースを全てのタスクで用意して、というやり方と違って
タスクをアクティブにするときメモリを動的に確保しに行く、ってせざるを得ないのかな?

30 名前:名前は開発中のものです。 [2007/03/16(金) 00:00:01 ID:wlk+IDOq]
>>27
Factoryに、敵別にプールつくって、あらかじめ生成しておいて、
そっからひっぱってくる感じ?

出現する敵の最大数をあらかじめ指定しておいて、
最初に敵出る分全部、生成しておくんかな?ステージのはじめとかに。


敵Aと敵Bが最大10体づつ出る場合、
敵Aのプール10体分と、敵Bのプール10体分とをあらかじめ生成しておくんかいな?

31 名前:名前は開発中のものです。 mailto:sage [2007/03/16(金) 00:00:39 ID:yIBWThbm]
>>28
あなたが言っているのはカプセル化やクラス設計の話であって、
オブジェクト指向の話ではない気がする。
タスクシステムの構造自体がオブジェクト同士の通信などを
不自然なものにする要員になっていると思うんだよね…。まあこの話はいいや。

>>29
>>27読んでけれ

32 名前:名前は開発中のものです。 mailto:sage [2007/03/16(金) 00:15:46 ID:4Zw2Xard]
>>30
最大数分を耳を揃えてきっちり用意する必要は必ずしもない。
以下、例えばの流れ。

準備段階。EnemyFactoryのプール容量は5でまだ空。

敵を4体くれという指令が来る。プールが空なので、慌てて4体newして渡す。

敵の出番が終わる。EnemyFactoryが責任を持ってEnemyを回収。プールに4体入る。

敵を3体くれという指令が来る。プールから3体分引っ張り出して、
メンバ変数を適切に設定し直して渡す。

敵を3体くれという指令がまた来る。プールから残りの1体を取り出して渡す。
2体分足りないので仕方なくnewする。

敵6体の出番が終わる。5体回収し、1体はプールに入らないので捨てた。

こんな感じで合計10体が画面に現れる場合だと、
回収して使い回したのでnewしたのは6体分だけで済む。



33 名前:名前は開発中のものです。 [2007/03/16(金) 00:22:25 ID:wlk+IDOq]
>>32
なるほど・・・
完全に動的確保は拒否するわけではなく、
あくまで、メモリ確保を最小限にする方向なのね
キャッシュみたいなものか

34 名前:名前は開発中のものです。 mailto:sage [2007/03/16(金) 00:26:50 ID:xvDGcZpT]
メインループの中でLazy initializationさせるってありえないんだが・・・

35 名前:名前は開発中のものです。 mailto:sage [2007/03/16(金) 00:43:11 ID:h9V7zR2G]
そうか?
メモリ確保は重くないだろうし、オブジェクトの初期化処理が重いと感じるのか?

36 名前:名前は開発中のものです。 mailto:sage [2007/03/16(金) 00:47:28 ID:4Zw2Xard]
>34
>>32は一通りの動作(不足と超過)を示す例としてわざとこうしただけ。
実際はプールが不足しない程度に容量を増やすし、
メインループに入る前にプールは満たしておく。

プールから引っ張り出してメンバ変数を設定し直すことも含めて
Lazy initializationだと言っているのならば、さすがに気にしすぎだと思うが。
っていうか色々工夫したところで更新処理よりも描画処理の方が格段に重いから困る。

37 名前:名前は開発中のものです。 [2007/03/16(金) 01:18:43 ID:wlk+IDOq]
> っていうか色々工夫したところで更新処理よりも描画処理の方が格段に重いから困る。

まあ、そうなんだよなあ・・・。

超絶弾幕シューティングでもないかぎり、
重いのは3D処理だったり当たり判定だったり・・・

38 名前:29 mailto:sage [2007/03/16(金) 01:29:18 ID:ZxwtzxVV]
>>31
つーことは、同時に出現する敵の数は、そのEnemyFactoryの初期化時に生成する
Enemyのインスタンスの数までという制限があるという認識でおk?

古典的つーか、ワークスペースを確保してタスクごとにワークスペースの分割方法を変える場合は、
敵の最大数は、タスクの最大数に近くなるはずなんだけど、そこらへんに対してウィークポイントになるのかな?

いや、もちろん、>>21の場合、JAVAのオブジェクト指向に則った書き方なので、メモリ周りでバグが出にくいというのは理解している。

39 名前:32 mailto:sage [2007/03/16(金) 01:31:03 ID:ZxwtzxVV]
あ、>>30で割と答えが出てたね、失礼。


40 名前:39 mailto:sage [2007/03/16(金) 01:32:59 ID:ZxwtzxVV]
ごめんdでもない書き間違いしたorz

>>39 は、>>32じゃなくて>>29で、
答えがでたのが>>32だった。

一昨日妹が死んでまだ慌ててるのかなあ。

41 名前:名前は開発中のものです。 mailto:sage [2007/03/16(金) 01:55:58 ID:xob5GmNS]
インスタンス変数初めからプールしちゃうとライフサイクル伸びて

じじい世代発見!→フルGC承認!!→光になれー!!

って重量GCシナリオが見えるんだが・・・
俺どこか間違えてる?

42 名前:名前は開発中のものです。 mailto:sage [2007/03/16(金) 06:47:08 ID:RmBov5WG]
×じじい世代発見!→フルGC承認!!→光になれー!!
○じじい世代が世界に溢れる!→フルGC承認!!→光になれー!!

・初期化時に生成してプール→OLD領域に移動(使い回され領域は無駄にならない)

・短寿命のインスタンスを頻繁に生成→Eden領域がすぐに満杯になる→頻繁にGC発生
 →From・Toが短寿命のインスタンスで溢れる→長寿命でない物もOLD領域に押し込まれる
 →OLD領域が不足→フルGC承認!!→光になれー!!

(チューニングしてEden領域を大きくして(New領域を大きくして)、MaxTenuringThreshholdを増やせばFullGCは起きにくくなるか?

Javaには詳しくないから、嘘書いてたらエロイ人突っ込みヨロシク



43 名前:名前は開発中のものです。 mailto:sage [2007/03/17(土) 00:02:48 ID:ZM3wMuqd]
>>41
殿堂入りしたオブジェクトがゲーム終了まで参照を持つのに何故フルGCが起きる?
キャッシュさせたいインスタンスはさっさと殿堂入りさせる。
そしてキャッシュしないと決めたインスタンスは短いスパンで確実に使い捨てする。
フルGCを起こさせないための基本的なリソース管理だよ。

FPSを意識するゲームであるなら、ピーク時に的を絞ればいいだけだから簡単だよ。

44 名前:名前は開発中のものです。 mailto:sage [2007/03/18(日) 13:30:17 ID:opYiOvzt]
ゲームにおけるデータ構造・クラス設計・パターン
pc11.2ch.net/test/read.cgi/gamedev/1155209226/

話題的に上記のスレが適当だと思う。
っていうかタスクシステム単体で語るようなことが思い浮かばない。

45 名前:名前は開発中のものです。 [2007/03/21(水) 19:40:49 ID:v8Vhdcv6]
トラックバック:pc11.2ch.net/test/read.cgi/gamedev/1155209226/

46 名前:名前は開発中のものです。 [2007/03/23(金) 12:53:45 ID:28C6AFOi]
敵といってもたくさん種類いるし
敵以外にも色んなタスクがある場合、それぞれ個別にプールしとけってのか?

47 名前:名前は開発中のものです。 mailto:sage [2007/03/23(金) 13:23:37 ID:vxAgs8Dc]
>>46
そんなのは場合によるだろ。
ただ、たくさん種類がいるからめんどくせーって理由だけで
プーリングを放棄するのはただの怠け者。

48 名前:名前は開発中のものです。 mailto:sage [2007/03/23(金) 20:59:09 ID:V2teaCuf]
>>46
俺もそれ悩んだことがある。

で、悩んだ結果オブジェクトのプーリングはやめてnew/deleteを乗っ取って
自分でフリーリストを実装することにした。(キャッシュするものを一段低レベルな
ところに持っていくってことね。) C++の話でJavaでできるかは知らん。

ただ、敵が何体以上は出ないってゲームも割と当たり前なんで、プーリングの
数をハードコーディングしてしまっても別にいいとも思う。

49 名前:名前は開発中のものです。 mailto:sage [2007/03/23(金) 21:08:45 ID:ZM8fpxF3]
new/delete 置き換えてできることなんて、大抵はデフォルトの実装でも
同じことやってるんじゃないの?

明確なボトルネックを見つける前から独自のメモリ管理を追加するのは
面倒なバグの元になるだけで終わる可能性がある。
もうちょっとコンパイラ(ライブラリ)実装者を信用してもいいんじゃないかと思う。

50 名前:名前は開発中のものです。 mailto:sage [2007/03/23(金) 21:36:19 ID:V2teaCuf]
>>49
> new/delete 置き換えてできることなんて、大抵はデフォルトの実装でも
> 同じことやってるんじゃないの?

フリーリスト自体はCRT内にもあるものだし、汎用の用途ならdlmallocが最強(?)かも
しれないけど、例えば確保のサイズが大部分固定だったり、確保開放のパターンが
FIFO的だったりとか文脈に依存したパターンを見つけることで、もっと高速にする余地が
あるんだ。

> 明確なボトルネックを見つける前から独自のメモリ管理を追加するのは
> 面倒なバグの元になるだけで終わる可能性がある。
> もうちょっとコンパイラ(ライブラリ)実装者を信用してもいいんじゃないかと思う。

これは至極もっともだ。俺も自分でなんでも作りすぎるのはちょっと悪い癖だと思ってる。

51 名前:名前は開発中のものです。 mailto:sage [2007/03/23(金) 21:57:58 ID:P2V386bO]
ある程度組み終わった後でも使用するアロケータを楽に変更できるように
組むことなんて可能なのかいな?

52 名前:名前は開発中のものです。 mailto:sage [2007/03/23(金) 22:32:14 ID:V2teaCuf]
>>51
アロケータをオブジェクトにして種類別に派生させる。
生成部分を取り替えられるようにするって意味で、デザパタでいうところのアブストラクトファクトリに近いかな。



53 名前:名前は開発中のものです。 mailto:sage [2007/03/23(金) 22:53:52 ID:vxAgs8Dc]
メモリ確保方法によらず、常に同じ記述で
オブジェクトの生成・破棄が行えると楽だな。
オブジェクト毎にメモリ確保方法が異なっていて、
さらに生成・破棄手順が違うとかだと悲惨だ。

自前でメモリ確保機構を作りたいって人は、
通常のnew、boostのobject_pool、LokiのSmallObj、
Efficient C++のMemoryPoolのソースを全部見てからにした方がいい。
大抵はこいつらで事足りる。
個人的に、boostのobject_poolが最強だと思う。

54 名前:名前は開発中のものです。 mailto:sage [2007/03/24(土) 00:17:00 ID:OuD128ry]
自分で作ると最速のコードに出来ることがあっても
準標準級のライブラリに似たようなのがあれば作らないってのも勇気だわね

55 名前:名前は開発中のものです。 mailto:sage [2007/03/24(土) 00:46:35 ID:SQuGfhfH]
>>50
> しれないけど、例えば確保のサイズが大部分固定だったり、確保開放のパターンが
> FIFO的だったりとか文脈に依存したパターンを見つけることで、もっと高速にする余地が

operator new にはサイズしか渡されないし operator delete にはポインタひとつしか
渡されないので、そういう文脈に依存した処理を組み込むのは難しい。
「new/delete 置き換えてできること」と限定したのはそういう意味だったんだが。

56 名前:名前は開発中のものです。 mailto:sage [2007/03/24(土) 01:18:26 ID:8HwaAyp8]
>>55
> operator new にはサイズしか渡されないし operator delete にはポインタひとつしか
> 渡されないので、そういう文脈に依存した処理を組み込むのは難しい。
> 「new/delete 置き換えてできること」と限定したのはそういう意味だったんだが。

俺が>49で言ってた「乗っ取って」というのは字面通りの単純な置換って意味じゃなくて
生成機構を変更するって意味なので、まぁ、ほんとに置換しかやらないのなら、
そうですね、としか。
というか、オブジェクトプールがどうこうって流れだったんだからその辺は変更できるってのが
前提じゃないの?

57 名前:名前は開発中のものです。 mailto:sage [2007/03/24(土) 01:21:37 ID:8HwaAyp8]
アンカーミスった。>49じゃなくて>48っすね。

58 名前:名前は開発中のものです。 mailto:sage [2007/03/24(土) 02:30:22 ID:oJPw3lLB]
お前らはplacement newを知らないのか?

59 名前:名前は開発中のものです。 mailto:sage [2007/03/24(土) 05:25:57 ID:SQuGfhfH]
>>56
グローバル opeartor new/delete の置き換えと勘違いしてたみたい。ごめんよ。

60 名前:名前は開発中のものです。 mailto:sage [2007/03/24(土) 05:27:06 ID:SQuGfhfH]
>>58
知ってるけど、この流れでは当たり前というか関係ないというか、どうでもいい。

61 名前:名前は開発中のものです。 mailto:sage [2007/03/26(月) 22:37:04 ID:sS1yrghH]
タスカー様を復活させるのだ

62 名前:名前は開発中のものです。 mailto:sage [2007/03/26(月) 23:35:38 ID:15IZtZoB]
タスク・オム



63 名前:名前は開発中のものです。 mailto:sage [2007/04/02(月) 00:01:32 ID:xHA5oFU3]
タスケテシステムとスレタイ読み違えた

64 名前:名前は開発中のものです。 mailto:sage [2007/04/02(月) 22:36:55 ID:rjkFdofu]
いや、実は読み違えていない。スレ主が書き間違えてるんだ。

65 名前:名前は開発中のものです。 mailto:sage [2007/04/02(月) 22:55:04 ID:QJ3NujtS]
誰かボスケテシステムスレも建ててよ

66 名前:名前は開発中のものです。 mailto:sage [2007/04/10(火) 21:51:55 ID:DVQJ95h4]
Javaでタスクシステムをつくるとき、
各タスクに描画させるのか?(敵のタスクならその機体の描画とか。)

それともタスクは座標だけupdateして、別にTimerとかでPanelをrepaintさせるのか?

67 名前:名前は開発中のものです。 [2007/04/11(水) 08:50:01 ID:0dv8Cb9u]
>>66
ちらつく。
ダブルバファリングしても無理。

68 名前:名前は開発中のものです。 mailto:sage [2007/04/11(水) 09:13:43 ID:J3mbPVHZ]
LWJGL使えよ

69 名前:名前は開発中のものです。 [2007/04/11(水) 21:16:36 ID:S5YhMrov]
スプライトシステムか。

70 名前:名前は開発中のものです。 [2007/04/11(水) 23:21:45 ID:S5YhMrov]
YaneuraoGameSDK.NETのタスクシステムってどうよ。

yanesdkdotnet.sourceforge.jp/wiki/index.php?FrontPage

こういうののJava版とかないかね?


71 名前:名前は開発中のものです。 mailto:sage [2007/04/11(水) 23:58:37 ID:qhNv6z5v]
至って普通。フレームワークにするまでもないというか、使い方覚えるほうが面倒くさくね?というか。
でも、やね氏の作るものは氏が飽きたらそれまでなので今ならXNAでも使っといたほうがいいんじゃないかな。

72 名前:名前は開発中のものです。 [2007/04/12(木) 09:21:05 ID:gzUpXrks]
「シューティングゲームマニアックス」にタスクシステム結構詳しく載ってて、構造体キャスト使ってたけど、結構きつい様な気もする
どうなんだろう




73 名前:名前は開発中のものです。 mailto:sage [2007/04/12(木) 20:30:27 ID:mQKUb85m]
Javaの場合だとひとつのGraphics2Dをコンテキストとするから
タスクが描くってよりも、フレームワークが取り込むって形になりそう

74 名前:名前は開発中のものです。 [2007/04/14(土) 17:35:53 ID:F0D9RwXy]
統合開発環境やデバッガとの連携を全く考慮していない
聳え立つ糞のようなタスクシステムをしこしこ作ってる
孤独なオナニープログラマ諸君。
 
デバッグの容易さとか、保守のしやすさを考えて作ってますか?

75 名前:名前は開発中のものです。 mailto:sage [2007/04/14(土) 17:53:16 ID:3N17piRe]
>>74
あたりまえじゃん

76 名前:名前は開発中のものです。 mailto:sage [2007/04/14(土) 18:33:42 ID:tHggo9K5]
>>74
君はそんなものしか作れなかったのかな?
それはタスクシステムが悪いんじゃなくて、
君のセンスがないだけだから心配することないよ!

77 名前:名前は開発中のものです。 mailto:sage [2007/04/14(土) 18:56:15 ID:KurcdpHU]
そういや、今は亡きCマガにトンデモなタスクシステム紹介記事があったが
あれが出た辺りからタスクシステムというキーワードがすっかり香ばしくなったな。
今では>>13のリンク先の通り、厨房技術用語としての地位は不動のものだな。

78 名前:名前は開発中のものです。 mailto:sage [2007/04/14(土) 20:10:39 ID:KVgw3R/b]
Cマガの記事を書いたライターはおそらく、つか間違いなくド素人。

当時ウェブ上に転がってた情報を拾い集めて書いただけの内容だった。
Logician何とかというサイトの記述漏れや記述ミス(というか独自解釈か)
をご丁寧に全て継承していた。

ウェブ上で都市伝説のように紹介されていたものをまんま丸写しして
「いまどきwのプロが使うゲーム開発の秘技」みたいに神格化して
紙媒体を使って流布したおかげで、言葉だけが一人歩きを始めた。

実装方法は千差万別のローカル用語なのにね。

79 名前:名前は開発中のものです。 mailto:sage [2007/04/14(土) 20:19:46 ID:g5jEBpoC]
フレームワークみたいなもんだろ。
使えるというのは自前の実装で言ってるから判るんだが
使えないというのは自前の実装がへぼいと宣伝してるのかね。

それともあまりにもひどい実装を見たのだろうか。

80 名前:名前は開発中のものです。 mailto:sage [2007/04/15(日) 02:36:38 ID:0Q+hD2uu]
タスクシステムに限らず、こういうフレームワーク的なものは
利点や欠点を見極めた上で採用不採用を決定するのが当然なわけだけど、
それを怠って何でもタスクシステムにすりゃいいと思っている
初心者が絶賛大量量産中だから困る。
そういう馬鹿どもが勝手に困る分には全く構わないが、
blogで上級者ぶって布教活動をしたり、
頓珍漢な質問をして場を混乱させたりするのは勘弁してくれ。

81 名前:名前は開発中のものです。 mailto:sage [2007/04/15(日) 02:43:26 ID:KRgQ3nwE]
使えるというのは自前の実装で言ってるから判るんだが
使えないというのは自前の実装がへぼいと宣伝してるのかね?

82 名前:名前は開発中のものです。 mailto:sage [2007/04/15(日) 03:12:12 ID:vOubHFUU]
>>81
まあ、そうなんだろう。
結局タスクシステムにしたってオブジェクト指向にしたって、理解できなかった奴が否定しているんだしね。



83 名前:名前は開発中のものです。 mailto:sage [2007/04/15(日) 03:38:07 ID:ib4ZSVvj]
タスクシステムやオブジェクト指向よりも
ちょっと前のレスをわざわざコピペした>>81の真意が理解できません><

84 名前:名前は開発中のものです。 mailto:sage [2007/04/15(日) 04:14:42 ID:xBb5xlIW]
ヒント:自作自演

85 名前:名前は開発中のものです。 mailto:sage [2007/04/15(日) 04:28:01 ID:vOubHFUU]
そういや、単発IDが連続してるなここ

86 名前:名前は開発中のものです。 mailto:sage [2007/04/15(日) 04:39:19 ID:W1PnAJQl]
同一ID:配列
単発ID:リスト→このスレで言うところのタスクシステム。

うむ、スレ違いじゃない。問題無い

87 名前:名前は開発中のものです。 mailto:sage [2007/04/15(日) 04:47:32 ID:0Q+hD2uu]
>>86の例えが理解できる人、解説プリーズ

88 名前:名前は開発中のものです。 mailto:sage [2007/04/15(日) 04:59:44 ID:KRgQ3nwE]
日付が変わってID変わっただけだアホ。

89 名前:名前は開発中のものです。 mailto:sage [2007/04/15(日) 05:00:52 ID:W1PnAJQl]
まぁまぁ、隔離スレで熱くなるなよ。

90 名前:名前は開発中のものです。 mailto:OOもタスクシステムも御神託だね [2007/04/15(日) 05:45:42 ID:5XtjNBFQ]
82 : 「●●を正しく理解しない者が●●を否定するのだ。」

 

( ^??^?)…
●●を魔法か何かと勘違いして布教する厨房が否定されてるだけだろ。

タスクシステムの定義もOOと同様に抽象的なものでしかないわけだが
カビの生えた糞実装(しかも驚くほど似たものばかりが蔓延している)付きで
布教する厨房が頑張ってくれたおかげで、いつの間にかその糞実装込みで
タスクシステムという言葉が定義付けられてしまった感があるな。

91 名前:名前は開発中のものです。 mailto:sage [2007/04/15(日) 07:11:04 ID:3dsdfwPB]
同列に語るならデザインパターンとだろう。

92 名前:名前は開発中のものです。 mailto:sage [2007/04/15(日) 07:21:05 ID:5XtjNBFQ]
例えばだけどさ
複数の有限状態機械の相互作用・状態遷移を時間刻み冲の数値積分などで
逐次計算していく(時間発展させる)仕掛けになっていれば、皆タスクシステム
としての体を成してるんじゃないか?
 
>>13のリンク先の連中は、言っちゃ悪いが頭の引き出しが少ないんじゃないかな。
一般化して説明できるはずのものを遠まわしに分かりづらく説明してしまってるね。

結果、頭の引き出しが少ない視野偏狭な読者は、タスクシステムをゲーム業界固有の
ハイパーテクノロジーであるかのように錯覚する。>>13のリンク先を聖経のように
有難がってる趣味プログラマの人はもう少し見識を広めたほうがいいよ。



93 名前:名前は開発中のものです。 mailto:sage [2007/04/15(日) 11:33:45 ID:vOubHFUU]
>>90
だから、おまいさんがタスクシステムを理解しているというのなら、
何が糞実装なのか教えてくれよせっかくだからさ。

後学のために俺も知りたい。

94 名前:名前は開発中のものです。 [2007/04/15(日) 12:09:21 ID:bzLlTmPF]
>>93
それは俺もしりたい。

上では、糞実装っというより、方言があるものを統一の定番のものように見せているのを
怒っているようにも思うけど。

95 名前:名前は開発中のものです。 mailto:sage [2007/04/15(日) 12:59:53 ID:vOubHFUU]
>>94
そうかもねえ。
とにかく、具体的なことを、ID:5XtjNBFQが一切書かないおかげで、
なんか偉そうなことを長文で言っているように見えるけど、
実際に何を言いたいのか訳わからんし。

96 名前:名前は開発中のものです。 mailto:sage [2007/04/15(日) 15:01:20 ID:+CRNM9AG]
>>82みたいなレスをする奴が何を叫んでも
まともに相手にされないだけだと思うが

97 名前:名前は開発中のものです。 mailto:sage [2007/04/15(日) 15:07:19 ID:vOubHFUU]
はいはい

あいかわらず具体的な話が全く出てこなくなったなここは

98 名前:名前は開発中のものです。 mailto:sage [2007/04/15(日) 16:27:50 ID:I+ZXuliP]
他人を否定したい。
でも具体的な話をすると自分が否定されるから絶対出来ない。
人間とはそういうもの。

99 名前:名前は開発中のものです。 mailto:sage [2007/04/15(日) 16:35:35 ID:5XtjNBFQ]
   ∧,,∧
  (・∀ ・) < はいはい、あいかわらず具体的な話が
.  ノ(  )ヽ   全く出てこなくなったなここは。わろすわろすw
   <  >

pc11.2ch.net/test/read.cgi/gamedev/1173708588/82n
pc11.2ch.net/test/read.cgi/gamedev/1173708588/85n
pc11.2ch.net/test/read.cgi/gamedev/1173708588/93n
pc11.2ch.net/test/read.cgi/gamedev/1173708588/95n
pc11.2ch.net/test/read.cgi/gamedev/1173708588/97n

●理解できなかった奴が否定しているんだ
●偉そうなことを言っているように見える
●実際に何を言いたいのか訳わからん

      ズコー
   ヽ(・ω・)/ 
   \(.\ ノ

100 名前:名前は開発中のものです。 mailto:sage [2007/04/15(日) 16:45:56 ID:vOubHFUU]
ID:5XtjNBFQ は、相変わらず顔真っ赤にして必死だなあw
早くどういう実装が糞実装なのか教えてよwww

101 名前:名前は開発中のものです。 mailto:sage [2007/04/15(日) 19:44:58 ID:n9DKuG7P]
>>90>>92
暇だからググってみたけど、関数アドレス+汎用ワークのリンクリストという
環境(ゲーム)依存のひとつの手段に過ぎなかったものを、やたら例として
あげたがる所が多いみたいね。ちょっと意外だったわ。ネット文化なのかね。

これ、情報(都市伝説)の出所を辿れば同じところに行き着くんじゃないの。

102 名前:名前は開発中のものです。 mailto:sage [2007/04/15(日) 20:39:48 ID:n9DKuG7P]
タスクシステムはゲームを駆動させるコア部分=ゲームエンジンなんだから
Quake系あたりの有名どころのオープンソースなゲームエンジンの実装を
引き合いに出して解説すればいいのに、ネット上で「タスクシステム」と
名の付く解説文って何故かそういうことはしないんだよね。単に別物だと
勘違いしてるのか、アーケードゲーム創成期の懐古趣味者だからなのか
アンテナ張れてない脳味噌コチコチのフェードアウトおやじだからなのか
酸素欠乏症に陥ったテム・レイだからなのか。



103 名前:名前は開発中のものです。 mailto:sage [2007/04/15(日) 21:47:11 ID:PxGC7SLd]
オブジェクト指向やデザパタの説明するのに、
有名オープンソースアプリを引き合いにしないのと一緒ってことじゃない?

104 名前:名前は開発中のものです。 mailto:sage [2007/04/15(日) 21:51:00 ID:/fPrY/bJ]
確かに、タスクシステムと他のゲームエンジンを比較する記事は
全く目にしないな。タスクシステムを解説するサイトのほとんどが
ゲームエンジンという概念を持たない奴を対象としているみたいだから、
仕方の無いことだとは思う。
問題なのは、解説者自身が、解説の対象となる連中と
さほどレベルが変わらないということ。

105 名前:名前は開発中のものです。 mailto:sage [2007/04/15(日) 22:03:11 ID:TiBHGm8x]
>>102
おまえはコンパイラの仕組みを解説するのにいちいちgccのソースを持ち出すのか?

106 名前:名前は開発中のものです。 mailto:sage [2007/04/15(日) 22:05:22 ID:/fPrY/bJ]
>>103
お前はオープンソースって単語につられすぎ。
タスクシステムと他のゲームエンジンって組み合わせなんだから、
オブジェクト指向の対となるのは構造化プログラミングとか
アスペクト指向とかだろ。

107 名前:名前は開発中のものです。 mailto:sage [2007/04/15(日) 22:13:00 ID:PxGC7SLd]
>>106
???

誰かエスパーの人翻訳ぷりーず

108 名前:名前は開発中のものです。 mailto:sage [2007/04/15(日) 22:37:34 ID:BFtC8cga]
うちでもタスクシステムという用語自体は
今でもゲームエンジンとほぼ同義で使ってるな。

キャラクタのオブジェクトのことをタスクと呼んだり
ユニットと呼んだりエンティティと呼んだりするのと
同じで、他所では意味合いはすこし違うかもだが。

ま、所詮はローカル用語だな。
確固たる経典があるわけでもなく無理矢理普及
させようとしても都市伝説化するのが関の山だろ。

大人しくゲームエンジンとでも呼んどけってこった。

>>92
>複数の有限状態機械の相互作用・状態遷移を時間刻み冲の数値積分などで
>逐次計算していく(時間発展させる)仕掛け

共通の定義を模索していくとそんな感じになるかな。

仮想空間内に配置したエンティティを時間ステップ毎に
駆動させたり、エンティティ同士の情報のやりとりを仲介したり。
ゲームエンジンは自己駆動粒子系のシミュレータの一種だね。

109 名前:名前は開発中のものです。 mailto:sage [2007/04/15(日) 23:49:58 ID:oEvaf3OR]
ウェブ上で出回ってるタスクシステム講座はたしかに
どれも一様に古臭いな。統制が取れた古臭さとでもいうか。

一線を退いて久しいオサーンが昔を懐かしむ人向けの
読み物と断わった上で公開してるページもあるみたいだが
Code Zineの記事の中の子はガチで浦島太郎になってて
ちょっとカワイソス。
彼には最新のUnrealのMOD開発用ゲームソースでも
読ませてやりたい。

110 名前:名前は開発中のものです。 mailto:sage [2007/04/16(月) 01:16:12 ID:W5lbbWwm]
主張・文体・時間帯・改行の癖・その他諸々を考慮して、
IDを隠して眺めてみると面白いな。
昨日19時からのログわ。

111 名前:名前は開発中のものです。 mailto:sage [2007/04/16(月) 01:27:08 ID:MDcwQB1m]
のちのコナンである。

112 名前:名前は開発中のものです。 mailto:sage [2007/04/16(月) 01:59:47 ID:B1Dtb12v]
タイガアドベンチャーだね



113 名前:名前は開発中のものです。 [2007/04/16(月) 02:25:04 ID:QiSCSZ7+]
>>104
いや、ある意味、タスクシステム自体が、ゲームエンジンの一種なのでは?


114 名前:名前は開発中のものです。 mailto:sage [2007/04/16(月) 04:52:10 ID:I2bg0tSF]
19時からのログよりも>>79-100の方が面白い。
何故か同じことを繰り返して言った>>79>>81
2回目の方にレスをつける>>82(ID:vOubHFUU)。
>>93で再登場したID:g5jEBpoCに向けて
定期的に書き込まれる単発IDによる援護射撃。
そして、ID:g5jEBpoCがいない時間帯には
決して現われない上記のような面々。






[ 続きを読む ] / [ 携帯版 ]

前100 次100 最新50 [ このスレをブックマーク! 携帯に送る ] 2chのread.cgiへ
[+板 最近立ったスレ&熱いスレ一覧 : +板 最近立ったスレ/記者別一覧]( ´∀`)<120KB

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef