タスクシステム総合スレ

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

どうぞ

2 ：名前は開発中のものです。：2007/03/12(月) 23:11:13 ID:0dA4mIiS

重複です。

【新人は】ｹﾞｰﾑ業界人の実情を吐露するｽﾚ【20♀】
http://ex21.2ch.net/test/read.cgi/ghard/1171817509/

3 ：名前は開発中のものです。：2007/03/13(火) 00:18:53 ID:GEtPEl1r

タスクシステムって基底クラス型ポインタに実オブジェクトを代入したらあかんの？

4 ：名前は開発中のものです。：2007/03/13(火) 01:05:48 ID:lSPAnQVN

暇だったんで書いてみた。添削できる人がいたらよろしく。

タスク

プロセス・スレッド・ファイバなど実行パスの総称。
この用語はシステムによって異なるものを指すため、動作システムを明らかに
するか、「実行する何か」といった抽象的な意味でのみ使うことが推奨される。

古典タスク (別名: ファイバ/軽量スレッド/マイクロスレッド/ノンプリエンプティブスレッド)

→ファイバの項を参照

ただし、ゲームのプロセス管理システムとして実装されたものは、コンテキストスイッチの他に
優先順位や実行順序のソートなど各種管理機能を備えたものが通常である。

擬似タスク (別名: 関数ポインタリスト)

関数ポインタ・クラス・(関数ポインタを持った)構造体などをリストで繋いだもの。
古典タスクの機能のうち個々のタスクをリストで繋ぐ部分のみを継承したものと思われる。
データ構造にツリーや配列などの変種がある。一部のゲームプログラマのローカル用語。

注: Winedows3.1等の擬似マルチタスクとは関数のリターンが必要なところは同じであるが、
コンテキストスイッチが伴わないところが異なるため、同じものとは言い難い。

5 ：名前は開発中のものです。：2007/03/13(火) 01:06:36 ID:lSPAnQVN

プロセス[Process]

→http://ja.wikipedia.org/wiki/%E3%83%97%E3%83%AD%E3%82%BB%E3%82%B9

注: 組み込み業界ではプロセスをタスクと呼ぶ慣習がある。
ゲーム業界は組み込みに近いシステムから同時代のPC並のものまで主流なシステムが
増えたため、異なる方面のエンジニアが交じり合い用語の混乱を招いていると思われる。

スレッド[Thread] (別名: ライトウェイトプロセス/プリエンプティブスレッド)

→http://ja.wikipedia.org/wiki/%E3%82%B9%E3%83%AC%E3%83%83%E3%83%89_%28%E3%82%B3%E3%83%B3%E3%83%94%E3%83%A5%E3%83%BC%E3%82%BF%E3%83%97%E3%83%AD%E3%82%B0%E3%83%A9%E3%83%9F%E3%83%B3%E3%82%B0%29

ファイバ[Fiber] (別名: 古典タスク/軽量スレッド/マイクロスレッド/ノンプリエンプティブスレッド)

軽量スレッドとも呼ばれる。並列的な記述が可能だが、スレッドで必要な
ロックが必要ない点がメリットである。コンテキストスイッチをOSではなく
アプリケーションが明示的に行うスレッド。WindowsではCreateFiber()で作成できる。

6 ：名前は開発中のものです。：2007/03/13(火) 20:18:34 ID:oceFcbYg

コルーチンってやつだよね＞ファイバ
スクリプト言語だと結構実装されてる。

7 ：名前は開発中のものです。：2007/03/14(水) 16:01:25 ID:r4GZS4Co

最近はどうでもよくなってきたな、この辺の話。
どんな方法でやっても絶対どっかで引っかかって、
工数もバグの数も実行性能も結局一緒になるんだよ。

タスク、というかゲームオブジェクト管理周辺って永遠に何か気持ち悪いままなんじゃね。
自分のゲームは薄氷の上で踊ってるようにしか見えんし、
他人のゲームは堅牢に動いてるように見える。そのギャップはたぶん埋まらない。むかつくけど。

8 ：名前は開発中のものです。：2007/03/15(木) 10:57:04 ID:PMeVIICQ

一応、タスク関連ということで、脱タスクな話もいいよね？

実は、最近、タスクは古いかな？という気がして、
今は、ABAさんのソース参考にして書いてる。

Titanion
http://www.asahi-net.or.jp/~cs8k-cyu/windows/ttn.html

昔から、ABA氏のソースは、追っているんだけど、大分洗練されていて面白い。

・敵、弾、パーティクルなどのActorがあり、タスクの代わりに、それぞれのリストを持つ
・これらのリストはいわゆるオブジェクトプールで、あらかじめ（敵なら敵の）インスタンスを生成しておくもの
・様々な行動パターン（仕様Spec）などは、個別にActorに割り当てられるようになっている。
例えば
パーティクルActor + 四角いパーティクルSpec
パーティクルActor + 線形のパーティクルSpec
みたいな感じ。
・Actor自身は、あまり情報を持っておらず、状態は、Stateオブジェクトに放り込む
別にこれはやらんでもいい気がするけど・・・
Actor自身においてもいいんじゃないの？という気がする

9 ：名前は開発中のものです。：2007/03/15(木) 11:02:03 ID:PMeVIICQ

追記

・実際の動きや、描画は、Actorに随時割り当てられた、Specが担当する
パーティクルActor + 四角いパーティクルSpec なら、四角く描画
パーティクルActor + 線形のパーティクルSpec なら、ラインで描画

といったように

欠点としてはだな。
・Stateは、複数のSpecで共通なので状態は、融通が利かない。
例えば、
パーティクルActor + 四角いパーティクルSpec と
パーティクルActor + 線形のパーティクルSpec とで、
（というか、パーティクルActorに関連するSpecすべて）
Stateが共通なので、メンバなんかが煩雑に増えている

そこで、往年の方々なら、タスクシステムよろしく、ワーク領域用意して、
StateをSpecごとに無理やり定義とかやるんでしょうけど、
遭えてやってない感じ。（ABA氏はけっこう古くからいる人のはずなので）

10 ：名前は開発中のものです。：2007/03/15(木) 11:04:26 ID:PMeVIICQ

ABA氏のゲームは、基本的にゲーム中にメモリの再確保はしない方向になってて、
逆を言えば、初期化時ならば、オブジェクトの生成はバンバンやってます。
それがわかれば、ソースは読みやすいし、理解し易い思います。

11 ：名前は開発中のものです。：2007/03/15(木) 15:40:53 ID:b1+VxKry

最初に確保してあとは使いまわしという事は
リソースプール見たいな感じなのかな

12 ：名前は開発中のものです。：2007/03/15(木) 18:57:37 ID:4gWi6T6s

脱タスクとか、タスクは古いかな、とかもうね。チラ裏じゃん。
僕の肛門も閉鎖しそうです並みの俺ニュースだろ。

まず俺定義・俺解釈・俺実装の「タスク」について補足説明しろ。
脱だの古いだの閉鎖しそうですだの言うのはそれからだ。

13 ：名前は開発中のものです。：2007/03/15(木) 19:16:14 ID:VzhOi8YW

まあ、そもそも、関連リンクもなしに>>1がスレ立てたのが悪いのだが……。

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

いまどきのタスクシステムの実装
http://omoikane.my-sv.net/gcss/tasksystem/index.php

ゲーム・ノ・シクミ第11回 C++によるタスクシステムの実現
今は無き C MAGAZINE 2006年1月号
http://www.cmagazine.jp/contents/200601.html

「処理関数へのポインタ付きワーク構造体の連結リスト」ってのがしっくりくる

14 ：名前は開発中のものです。：2007/03/15(木) 21:06:26 ID:ZqsnR0zJ

Javaでやろうとして挫折した。
ワーク構造体とそれをメンバとしてアタッチするラップクラスを作ったんだが
あまりにも気持ち悪くてそこでやめてしまった。

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

15 ：名前は開発中のものです。：2007/03/15(木) 21:26:14 ID:EXzxsrWu

JAVAってまともな構造体あったっけ？

16 ：名前は開発中のものです。：2007/03/15(木) 22:02:28 ID:qutq4pqL

Javaならインターフェイスとコレクション使えばすぐできるだろ。
ちなみにフレームレートとかは無視する方向で。

17 ：名前は開発中のものです。：2007/03/15(木) 22:05:34 ID:yIBWThbm

>>14
それは設計が悪いだけ。
ワーク構造体なんか作らなくても、
タスクインターフェースを実装した具体クラスに
好きな変数ガンガンぶち込めば済む。

18 ：名前は開発中のものです。：2007/03/15(木) 22:13:03 ID:ZqsnR0zJ

>>15
ByteBufferってクラス使えば共用体っぽく使えるよ。
ベースはchar配列だけどね。

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

19 ：名前は開発中のものです。：2007/03/15(木) 22:25:27 ID:yIBWThbm

別に>>16や>>17の方法でもプールできると思うんだが…。

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

>>17
kwsk

動的生成するのかな？

21 ：名前は開発中のものです。：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 ：名前は開発中のものです。：2007/03/15(木) 22:58:37 ID:XmQLFBDw

ワークメモリを分割して使うようなやり方は、高級アセンブラたるC言語ならではといっても良いと思う。
C++ですらそのやり方は馴染まない。ましてや、Javaともなると、メモリ管理を極力隠匿してGCで
自動化しているわけで、それをわざわざ迂回しようとしてるのが>18なんだが、わかってる？
慣れたやり方でやろうとしてしまうのはわかるけども、もう少しオブジェクト指向とか勉強して欲しいとちょっと思った。

23 ：名前は開発中のものです。：2007/03/15(木) 23:00:47 ID:b1+VxKry

オブジェクト指向というか言語仕様というか

24 ：名前は開発中のものです。：2007/03/15(木) 23:09:07 ID:ZqsnR0zJ

それが気持ち悪いからまっさきに避けたんだが、平行線っぽいから議論はやめとく。

25 ：名前は開発中のものです。：2007/03/15(木) 23:11:29 ID:yIBWThbm

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

26 ：名前は開発中のものです。：2007/03/15(木) 23:16:11 ID:PMeVIICQ

>>21
あー、やっぱりそれか・・・。
interfaceないころから、俺は、それでやってた。Javaでないけど。

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

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

27 ：名前は開発中のものです。：2007/03/15(木) 23:26:21 ID:yIBWThbm

>>26
>>21の場合でEnemyが頻繁に出入りするような場合は
new Enemyで生成するのではなく、
Enemyを管理するEnemyFactoryクラスを作って
そいつからEnemyを引っ張ってくるようにすればいいだけ。
あなたが>>8で言っているActorのリストみたいなものを
EnemyFactoryに持たせればいい。

28 ：名前は開発中のものです。：2007/03/15(木) 23:33:05 ID:XmQLFBDw

>>24
御意。

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

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

29 ：名前は開発中のものです。：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 ：名前は開発中のものです。：2007/03/16(金) 00:00:39 ID:yIBWThbm

>>28
あなたが言っているのはカプセル化やクラス設計の話であって、
オブジェクト指向の話ではない気がする。
タスクシステムの構造自体がオブジェクト同士の通信などを
不自然なものにする要員になっていると思うんだよね…。まあこの話はいいや。

>>29
>>27読んでけれ

32 ：名前は開発中のものです。：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 ：名前は開発中のものです。：2007/03/16(金) 00:26:50 ID:xvDGcZpT

メインループの中でLazy initializationさせるってありえないんだが・・・

35 ：名前は開発中のものです。：2007/03/16(金) 00:43:11 ID:h9V7zR2G

そうか？
メモリ確保は重くないだろうし、オブジェクトの初期化処理が重いと感じるのか？

36 ：名前は開発中のものです。：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：2007/03/16(金) 01:29:18 ID:ZxwtzxVV

>>31
つーことは、同時に出現する敵の数は、そのEnemyFactoryの初期化時に生成する
Enemyのインスタンスの数までという制限があるという認識でおｋ？

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

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

39 ：32：2007/03/16(金) 01:31:03 ID:ZxwtzxVV

あ、>>30で割と答えが出てたね、失礼。

40 ：39：2007/03/16(金) 01:32:59 ID:ZxwtzxVV

ごめん㌧でもない書き間違いしたorz

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

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

41 ：名前は開発中のものです。：2007/03/16(金) 01:55:58 ID:xob5GmNS

インスタンス変数初めからプールしちゃうとライフサイクル伸びて

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

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

42 ：名前は開発中のものです。：2007/03/16(金) 06:47:08 ID:RmBov5WG

×じじい世代発見！→フルGC承認！！→光になれー！！
○じじい世代が世界に溢れる！→フルGC承認！！→光になれー！！

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

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

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

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

43 ：名前は開発中のものです。：2007/03/17(土) 00:02:48 ID:ZM3wMuqd

>>41
殿堂入りしたオブジェクトがゲーム終了まで参照を持つのに何故フルGCが起きる？
キャッシュさせたいインスタンスはさっさと殿堂入りさせる。
そしてキャッシュしないと決めたインスタンスは短いスパンで確実に使い捨てする。
フルGCを起こさせないための基本的なリソース管理だよ。

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

44 ：名前は開発中のものです。：2007/03/18(日) 13:30:17 ID:opYiOvzt

ゲームにおけるデータ構造・クラス設計・パターン
http://pc11.2ch.net/test/read.cgi/gamedev/1155209226/

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

45 ：名前は開発中のものです。：2007/03/21(水) 19:40:49 ID:v8Vhdcv6

トラックバック:http://pc11.2ch.net/test/read.cgi/gamedev/1155209226/

46 ：名前は開発中のものです。：2007/03/23(金) 12:53:45 ID:28C6AFOi

敵といってもたくさん種類いるし
敵以外にも色んなタスクがある場合、それぞれ個別にプールしとけってのか？

47 ：名前は開発中のものです。：2007/03/23(金) 13:23:37 ID:vxAgs8Dc

>>46
そんなのは場合によるだろ。
ただ、たくさん種類がいるからめんどくせーって理由だけで
プーリングを放棄するのはただの怠け者。

48 ：名前は開発中のものです。：2007/03/23(金) 20:59:09 ID:V2teaCuf

>>46
俺もそれ悩んだことがある。

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

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

49 ：名前は開発中のものです。：2007/03/23(金) 21:08:45 ID:ZM8fpxF3

new/delete 置き換えてできることなんて、大抵はデフォルトの実装でも
同じことやってるんじゃないの？

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

50 ：名前は開発中のものです。：2007/03/23(金) 21:36:19 ID:V2teaCuf

>>49
> new/delete 置き換えてできることなんて、大抵はデフォルトの実装でも
> 同じことやってるんじゃないの？

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

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

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

51 ：名前は開発中のものです。：2007/03/23(金) 21:57:58 ID:P2V386bO

ある程度組み終わった後でも使用するアロケータを楽に変更できるように
組むことなんて可能なのかいな？

52 ：名前は開発中のものです。：2007/03/23(金) 22:32:14 ID:V2teaCuf

>>51
アロケータをオブジェクトにして種類別に派生させる。
生成部分を取り替えられるようにするって意味で、デザパタでいうところのアブストラクトファクトリに近いかな。

53 ：名前は開発中のものです。：2007/03/23(金) 22:53:52 ID:vxAgs8Dc

メモリ確保方法によらず、常に同じ記述で
オブジェクトの生成・破棄が行えると楽だな。
オブジェクト毎にメモリ確保方法が異なっていて、
さらに生成・破棄手順が違うとかだと悲惨だ。

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

54 ：名前は開発中のものです。：2007/03/24(土) 00:17:00 ID:OuD128ry

自分で作ると最速のコードに出来ることがあっても
準標準級のライブラリに似たようなのがあれば作らないってのも勇気だわね

55 ：名前は開発中のものです。：2007/03/24(土) 00:46:35 ID:SQuGfhfH

>>50
> しれないけど、例えば確保のサイズが大部分固定だったり、確保開放のパターンが
> FIFO的だったりとか文脈に依存したパターンを見つけることで、もっと高速にする余地が

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

56 ：名前は開発中のものです。：2007/03/24(土) 01:18:26 ID:8HwaAyp8

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

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

57 ：名前は開発中のものです。：2007/03/24(土) 01:21:37 ID:8HwaAyp8

アンカーミスった。>49じゃなくて>48っすね。

58 ：名前は開発中のものです。：2007/03/24(土) 02:30:22 ID:oJPw3lLB

お前らはplacement newを知らないのか？

59 ：名前は開発中のものです。：2007/03/24(土) 05:25:57 ID:SQuGfhfH

>>56
グローバル opeartor new/delete の置き換えと勘違いしてたみたい。ごめんよ。

60 ：名前は開発中のものです。：2007/03/24(土) 05:27:06 ID:SQuGfhfH

>>58
知ってるけど、この流れでは当たり前というか関係ないというか、どうでもいい。

61 ：名前は開発中のものです。：2007/03/26(月) 22:37:04 ID:sS1yrghH

タスカー様を復活させるのだ

62 ：名前は開発中のものです。：2007/03/26(月) 23:35:38 ID:15IZtZoB

タスク・オム

63 ：名前は開発中のものです。：2007/04/02(月) 00:01:32 ID:xHA5oFU3

タスケテシステムとスレタイ読み違えた

64 ：名前は開発中のものです。：2007/04/02(月) 22:36:55 ID:rjkFdofu

いや、実は読み違えていない。スレ主が書き間違えてるんだ。

65 ：名前は開発中のものです。：2007/04/02(月) 22:55:04 ID:QJ3NujtS

誰かボスケテシステムスレも建ててよ

66 ：名前は開発中のものです。：2007/04/10(火) 21:51:55 ID:DVQJ95h4

Javaでタスクシステムをつくるとき、
各タスクに描画させるのか？（敵のタスクならその機体の描画とか。）

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

67 ：名前は開発中のものです。：2007/04/11(水) 08:50:01 ID:0dv8Cb9u

>>66
ちらつく。
ダブルバファリングしても無理。

68 ：名前は開発中のものです。：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のタスクシステムってどうよ。

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

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

71 ：名前は開発中のものです。：2007/04/11(水) 23:58:37 ID:qhNv6z5v

至って普通。フレームワークにするまでもないというか、使い方覚えるほうが面倒くさくね？というか。
でも、やね氏の作るものは氏が飽きたらそれまでなので今ならXNAでも使っといたほうがいいんじゃないかな。

72 ：名前は開発中のものです。：2007/04/12(木) 09:21:05 ID:gzUpXrks

「シューティングゲームマニアックス」にタスクシステム結構詳しく載ってて、構造体キャスト使ってたけど、結構きつい様な気もする
どうなんだろう

73 ：名前は開発中のものです。：2007/04/12(木) 20:30:27 ID:mQKUb85m

Javaの場合だとひとつのGraphics2Dをコンテキストとするから
タスクが描くってよりも、フレームワークが取り込むって形になりそう

74 ：名前は開発中のものです。：2007/04/14(土) 17:35:53 ID:F0D9RwXy

統合開発環境やデバッガとの連携を全く考慮していない
聳え立つ糞のようなタスクシステムをしこしこ作ってる
孤独なオナニープログラマ諸君。
　
デバッグの容易さとか、保守のしやすさを考えて作ってますか？

75 ：名前は開発中のものです。：2007/04/14(土) 17:53:16 ID:3N17piRe

>>74
あたりまえじゃん

76 ：名前は開発中のものです。：2007/04/14(土) 18:33:42 ID:tHggo9K5

>>74
君はそんなものしか作れなかったのかな？
それはタスクシステムが悪いんじゃなくて、
君のセンスがないだけだから心配することないよ！

77 ：名前は開発中のものです。：2007/04/14(土) 18:56:15 ID:KurcdpHU

そういや、今は亡きCマガにトンデモなタスクシステム紹介記事があったが
あれが出た辺りからタスクシステムというキーワードがすっかり香ばしくなったな。
今では>>13のリンク先の通り、厨房技術用語としての地位は不動のものだな。

78 ：名前は開発中のものです。：2007/04/14(土) 20:10:39 ID:KVgw3R/b

Cマガの記事を書いたライターはおそらく、つか間違いなくド素人。

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

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

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

79 ：名前は開発中のものです。：2007/04/14(土) 20:19:46 ID:g5jEBpoC

フレームワークみたいなもんだろ。
使えるというのは自前の実装で言ってるから判るんだが
使えないというのは自前の実装がへぼいと宣伝してるのかね。

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

80 ：名前は開発中のものです。：2007/04/15(日) 02:36:38 ID:0Q+hD2uu

タスクシステムに限らず、こういうフレームワーク的なものは
利点や欠点を見極めた上で採用不採用を決定するのが当然なわけだけど、
それを怠って何でもタスクシステムにすりゃいいと思っている
初心者が絶賛大量量産中だから困る。
そういう馬鹿どもが勝手に困る分には全く構わないが、
blogで上級者ぶって布教活動をしたり、
頓珍漢な質問をして場を混乱させたりするのは勘弁してくれ。

81 ：名前は開発中のものです。：2007/04/15(日) 02:43:26 ID:KRgQ3nwE

使えるというのは自前の実装で言ってるから判るんだが
使えないというのは自前の実装がへぼいと宣伝してるのかね？

82 ：名前は開発中のものです。：2007/04/15(日) 03:12:12 ID:vOubHFUU

>>81
まあ、そうなんだろう。
結局タスクシステムにしたってオブジェクト指向にしたって、理解できなかった奴が否定しているんだしね。

83 ：名前は開発中のものです。：2007/04/15(日) 03:38:07 ID:ib4ZSVvj

タスクシステムやオブジェクト指向よりも
ちょっと前のレスをわざわざコピペした>>81の真意が理解できません＞＜

84 ：名前は開発中のものです。：2007/04/15(日) 04:14:42 ID:xBb5xlIW

ヒント：自作自演

85 ：名前は開発中のものです。：2007/04/15(日) 04:28:01 ID:vOubHFUU

そういや、単発IDが連続してるなここ

86 ：名前は開発中のものです。：2007/04/15(日) 04:39:19 ID:W1PnAJQl

同一ID：配列
単発ID：リスト→このスレで言うところのタスクシステム。

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

87 ：名前は開発中のものです。：2007/04/15(日) 04:47:32 ID:0Q+hD2uu

>>86の例えが理解できる人、解説プリーズ

88 ：名前は開発中のものです。：2007/04/15(日) 04:59:44 ID:KRgQ3nwE

日付が変わってID変わっただけだアホ。

89 ：名前は開発中のものです。：2007/04/15(日) 05:00:52 ID:W1PnAJQl

まぁまぁ、隔離スレで熱くなるなよ。

90 ：名前は開発中のものです。：2007/04/15(日) 05:45:42 ID:5XtjNBFQ

82　：　「●●を正しく理解しない者が●●を否定するのだ。」

　

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

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

91 ：名前は開発中のものです。：2007/04/15(日) 07:11:04 ID:3dsdfwPB

同列に語るならデザインパターンとだろう。

92 ：名前は開発中のものです。：2007/04/15(日) 07:21:05 ID:5XtjNBFQ

例えばだけどさ
複数の有限状態機械の相互作用・状態遷移を時間刻み⊿tの数値積分などで
逐次計算していく（時間発展させる）仕掛けになっていれば、皆タスクシステム
としての体を成してるんじゃないか？
　
>>13のリンク先の連中は、言っちゃ悪いが頭の引き出しが少ないんじゃないかな。
一般化して説明できるはずのものを遠まわしに分かりづらく説明してしまってるね。

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

93 ：名前は開発中のものです。：2007/04/15(日) 11:33:45 ID:vOubHFUU

>>90
だから、おまいさんがタスクシステムを理解しているというのなら、
何が糞実装なのか教えてくれよせっかくだからさ。

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

94 ：名前は開発中のものです。：2007/04/15(日) 12:09:21 ID:bzLlTmPF

>>93
それは俺もしりたい。

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

95 ：名前は開発中のものです。：2007/04/15(日) 12:59:53 ID:vOubHFUU

>>94
そうかもねえ。
とにかく、具体的なことを、ID:5XtjNBFQが一切書かないおかげで、
なんか偉そうなことを長文で言っているように見えるけど、
実際に何を言いたいのか訳わからんし。

96 ：名前は開発中のものです。：2007/04/15(日) 15:01:20 ID:+CRNM9AG

>>82みたいなレスをする奴が何を叫んでも
まともに相手にされないだけだと思うが

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

はいはい

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

98 ：名前は開発中のものです。：2007/04/15(日) 16:27:50 ID:I+ZXuliP

他人を否定したい。
でも具体的な話をすると自分が否定されるから絶対出来ない。
人間とはそういうもの。

99 ：名前は開発中のものです。：2007/04/15(日) 16:35:35 ID:5XtjNBFQ

　　 ∧,,∧
　　(・∀ ・)　＜はいはい、あいかわらず具体的な話が
. 　ノ(　　)ヽ　　　全く出てこなくなったなここは。わろすわろすｗ
　　　<　 >

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

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

　　　　　ｽﾞｺｰ
　　　ヽ(･ω･)/　
　　　＼(.＼ノ

100 ：名前は開発中のものです。：2007/04/15(日) 16:45:56 ID:vOubHFUU

ID:5XtjNBFQ は、相変わらず顔真っ赤にして必死だなあw
早くどういう実装が糞実装なのか教えてよwww

101 ：名前は開発中のものです。：2007/04/15(日) 19:44:58 ID:n9DKuG7P

>>90 >>92
暇だからググってみたけど、関数アドレス+汎用ワークのリンクリストという
環境（ゲーム）依存のひとつの手段に過ぎなかったものを、やたら例として
あげたがる所が多いみたいね。ちょっと意外だったわ。ネット文化なのかね。

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

102 ：名前は開発中のものです。：2007/04/15(日) 20:39:48 ID:n9DKuG7P

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

103 ：名前は開発中のものです。：2007/04/15(日) 21:47:11 ID:PxGC7SLd

オブジェクト指向やデザパタの説明するのに、
有名オープンソースアプリを引き合いにしないのと一緒ってことじゃない？

104 ：名前は開発中のものです。：2007/04/15(日) 21:51:00 ID:/fPrY/bJ

確かに、タスクシステムと他のゲームエンジンを比較する記事は
全く目にしないな。タスクシステムを解説するサイトのほとんどが
ゲームエンジンという概念を持たない奴を対象としているみたいだから、
仕方の無いことだとは思う。
問題なのは、解説者自身が、解説の対象となる連中と
さほどレベルが変わらないということ。

105 ：名前は開発中のものです。：2007/04/15(日) 22:03:11 ID:TiBHGm8x

>>102
おまえはコンパイラの仕組みを解説するのにいちいちgccのソースを持ち出すのか？

106 ：名前は開発中のものです。：2007/04/15(日) 22:05:22 ID:/fPrY/bJ

>>103
お前はオープンソースって単語につられすぎ。
タスクシステムと他のゲームエンジンって組み合わせなんだから、
オブジェクト指向の対となるのは構造化プログラミングとか
アスペクト指向とかだろ。

107 ：名前は開発中のものです。：2007/04/15(日) 22:13:00 ID:PxGC7SLd

>>106
？？？

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

108 ：名前は開発中のものです。：2007/04/15(日) 22:37:34 ID:BFtC8cga

うちでもタスクシステムという用語自体は
今でもゲームエンジンとほぼ同義で使ってるな。

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

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

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

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

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

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

109 ：名前は開発中のものです。：2007/04/15(日) 23:49:58 ID:oEvaf3OR

ウェブ上で出回ってるタスクシステム講座はたしかに
どれも一様に古臭いな。統制が取れた古臭さとでもいうか。

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

110 ：名前は開発中のものです。：2007/04/16(月) 01:16:12 ID:W5lbbWwm

主張・文体・時間帯・改行の癖・その他諸々を考慮して、
IDを隠して眺めてみると面白いな。
昨日19時からのログわ。

111 ：名前は開発中のものです。：2007/04/16(月) 01:27:08 ID:MDcwQB1m

のちのコナンである。

112 ：名前は開発中のものです。：2007/04/16(月) 01:59:47 ID:B1Dtb12v

タイガアドベンチャーだね

113 ：名前は開発中のものです。：2007/04/16(月) 02:25:04 ID:QiSCSZ7+

>>104
いや、ある意味、タスクシステム自体が、ゲームエンジンの一種なのでは？

114 ：名前は開発中のものです。：2007/04/16(月) 04:52:10 ID:I2bg0tSF

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

115 ：名前は開発中のものです。：2007/04/16(月) 05:02:51 ID:I2bg0tSF

ID:g5jEBpoCじゃなくてID:vOubHFUUだったわ。
ってどうでもいいか。周りのスルー力を見習お。

116 ：82：2007/04/16(月) 11:01:09 ID:5cCE7ez3

え、全部俺の自作自演？
そいつはすごいやw

117 ：名前は開発中のものです。：2007/04/16(月) 23:49:42 ID:vg95lefp

タスクとリフレッシュレートはゲ製の鬼門

118 ：名前は開発中のものです。：2007/04/17(火) 08:47:02 ID:Aek8raYd

>>117
KWSK

119 ：名前は開発中のものです。：2007/04/18(水) 23:28:57 ID:jsz7ODUC

　
　
　　　　　菊門と聞いて飛ん来ますた
　
　

120 ：名前は開発中のものです。：2007/04/19(木) 00:02:19 ID:jsz7ODUC

…。
　
　
　
>>104
>>113
ゲームエンジンなんて御洒落な言葉を耳にするようになったのはPS1末期のあたりだな。
それ以前は△△ドライバだの△△君だのタスクシステムだの皆好き勝手に呼んでたぞ。

121 ：名前は開発中のものです。：2007/04/19(木) 01:15:58 ID:7k3O26Dk

ようするにタスクシステムって、ゲーム内のいろんな要素をオブジェクトとして扱って、それをリストにして管理してフレーム毎に実行するだけ？
俺の場合、古めのゲームプログラマが連載形式で解説してるのをネットで見たのが最初だった。
そのちょっとあとぐらいに、やね氏がそのサイトを紹介してた気がする…。

それに感化されてやってみたんだけど、親子関係にあるオブジェクトの場合、平等な関係のタスクで扱うのが面倒くさかった。
素人なんで俺がへっぽこなだけだとおもうけど。
ゲームごとに、オブジェクトごとに最適な管理方法を考える方が楽な気がする。

122 ：名前は開発中のものです。：2007/04/19(木) 01:18:17 ID:0zzWAwAX

タスクがタスクを扱えるようにすればいくらでも楽勝っす。

123 ：名前は開発中のものです。：2007/04/19(木) 02:06:27 ID:Pm183gqV

タスクシステムを最初に見たときは、オブジェクト指向とは全く違う
自由度と再利用性の高い汎用的な管理の仕方だなと感心したよ。
それ以前の俺は、ゲームプログラミングなんて言ったら

CWaitCtrl WaitCtrl;
CRander Rander;
CPlayerCtrl player;
CEnemy enemy[NumofEnemy];
for(;;){
　player.func();//プレイヤーの移動処理など
　for(int i=0;i<NumofEnemy;i++)
　　enemy.func(&player);//敵の移動処理など

　Rander.Draw(&player);//うっふん描画
　Rander.Draw(&enemy);//あっはん描画
　WaitCtrl.func();//フレームレート調整
}

みたいにやってたからな・・・。
タスクシステムと比べたらまるでイソギンチャクとメガマウスの差だよ。

124 ：名前は開発中のものです。：2007/04/19(木) 02:25:55 ID:EeW/BzCK

>>120
それ以前というか、今でもそんな感じです。うちの場合。
　
PS2用RPGのチームに異動したときは内製エンジンをタスクシステムと呼んでた。
>>13で紹介されてるそれとはかけ離れた代物になってたけどね。
　
>>121
タスクシステムとゲームエンジンは等価。
ゲームエンジンという単語は元々は海外で使われてたの。
それが日本にも浸透したってだけ。
浸透する以前は内製のゲームエンジンはそれぞれ別の呼び方していた。
タスクシステムとか俺様ライブラリとか様々な方言があったと思うよ。
　
＞リストにして管理して
　
竹やりで万歳突撃？

125 ：名前は開発中のものです。：2007/04/19(木) 02:26:33 ID:vUHs3Nla

>>123
メガマウスの具体的な例をお願いします…。
ぱっと見だけど、かなり場数を踏んでる（プロの）方？

126 ：名前は開発中のものです。：2007/04/19(木) 02:35:14 ID:Pm183gqV

>>125
メガマウスってでかいんだぜ。
ジンベエザメよりも、シロナガスクジラよりもでかいんだぜ。
でもイソギンチャクって小さいんだぜ。
あと俺みたいな奴がプロだったら
日本はもっとデフレ状態になっても誰も就職に困らないだろうな。

127 ：名前は開発中のものです。：2007/04/19(木) 02:36:33 ID:Pm183gqV

あ、メガマウス小さかった。
なんだったけな、最大の海洋生物って。

128 ：名前は開発中のものです。：2007/04/19(木) 02:54:09 ID:EeW/BzCK

>>123
タスクシステムは特定の実装方法を指すものではない。
　
「古代の究極奥義、ダイエットシステムでこんなに痩せた！」
　
とか言わないのと一緒。

129 ：名前は開発中のものです。：2007/04/19(木) 08:09:39 ID:E/KhOlb0

>>123
コンテナクラスを内包したEnemyFactoryを作って
処理ループではメンバ関数一つ呼べば管理が楽にならん？
Class EnemyFactory {
Vector<CEnemy> EnemyArray;
(略)
public:
func(CPlayerCtrl& player)
}

enemyfactory.func(&player);を一回呼び出せば全てを処理してくれるように。
って、これがタスクシステムなのか？

130 ：名前は開発中のものです。：2007/04/19(木) 14:16:22 ID:KkZ4qP8H

だからさー、お前の脳内定義でのタスクシステムに必須条件って何よ。
ダンボール紙の盾をイージスシステムと名付けるのはお前の自由だが
他人に同意を求めるような話じゃねーだろと。

たかがローカル用語に、具体的な実装も含めた意味付けをして
再定義して普及させようとする仕切り行為は全て徒労に終わる。
　
ゲームプログラマは基本的に天邪鬼だからな。

131 ：名前は開発中のものです。：2007/04/19(木) 21:20:45 ID:I+5EKnEr

>>127
スレと関係ないけどメガロドンじゃね？大昔の巨大サメ。

>>130
>必須条件
これじゃ駄目なのか？

http://en.wikipedia.org/wiki/Task_%28computers%29

>A task is "an execution path through address space".In other words, a set of program instructions that is loaded in memory.
>タスクは「アドレス空間を通る実行パス」です。言いかえれば、メモリにロードされるプログラム命令のセット。

風呂桶でも紙コップでもなくて「入れ物」に相当する用語がタスクなんだけど、
それを「俺んちの風呂桶」の意味で使う奴がいるのが問題なんじゃないかと思う。

132 ：名前は開発中のものです。：2007/04/19(木) 21:56:37 ID:let+IdBl

そういうこったな。
taskはprocess並に汎用的な技術用語。
そのケツにsystemを付け加えるだけで

＞タスクシステムを最初に見たときは、オブジェクト指向とは全く違う
＞自由度と再利用性の高い汎用的な管理の仕方だなと感心したよ。

↑こんな胡散臭い話になる。マジでお勧め。
「去年まで金無し君だったけど」の改造コピペ文が作れるな

133 ：名前は開発中のものです。：2007/04/19(木) 22:42:06 ID:EeW/BzCK

>>123
なんか釣りっぽいが、君の言うタスクシステムってのはこんなやつ？
http://codezine.jp/a/article.aspx?aid=297
　
これ、ゲームプログラミングの基礎教材としては優良だとは思うが
タスクシステムという単語の使われ方はキッパリ忘れたほうがいい。
　
これ読んで「タスクシステムすげー！」「マジ感動！」
と歓喜して許されるのはリア厨、リア工まで。

それ以上なら技術者(の卵)として最低限のリテラシーが
欠けてるかもしれないと疑ったほうがいい。

何でもいいからオペレーティングシステムの教科書でも
一冊買ってみて読んだほうが遥かに勉強になると思うよ。

134 ：名前は開発中のものです。：2007/04/19(木) 22:47:04 ID:Pm183gqV

リア工なので許されるという

135 ：名前は開発中のものです。：2007/04/19(木) 22:48:45 ID:EeW/BzCK

アンカーミス。>>132じゃなくて>>129

136 ：名前は開発中のものです。：2007/04/19(木) 22:49:58 ID:EeW/BzCK

>>134
RTOSの本が面白いと思うよ。

137 ：名前は開発中のものです。：2007/04/19(木) 22:58:21 ID:let+IdBl

>>135
俺かいｗ

つーのは冗談として。。。
組み込み系の書籍はたしかに参考になるな。

俺も井の中の蛙にならんように精進せんと。

138 ：名前は開発中のものです。：2007/04/19(木) 23:00:12 ID:GlQD7rdS

タスクシステムってメモリに対して最適化した設計スタイルなんじゃねーの？
ギャラガとかの古の時代の産物なんだから、言葉自体を葬った方がいいんじゃないかと。

139 ：名前は開発中のものです。：2007/04/19(木) 23:02:37 ID:let+IdBl

>>138
＞タスクシステムってメモリに対して最適化した設計スタイルなんじゃねーの？
＞タスクシステムという言葉自体を葬った方がいいんじゃないかと。

本来はタスクシステムのローカル定義

140 ：名前は開発中のものです。：2007/04/19(木) 23:04:29 ID:let+IdBl

途中で送信しちまった。
　
＞タスクシステムってメモリに対して最適化した設計スタイルなんじゃねーの？

そのタスクシステムのローカル定義を葬ったほうがいいのであって
タスクシステムという言葉自体に罪は無いぞ。立派な技術用語だ。

141 ：名前は開発中のものです。：2007/04/19(木) 23:37:23 ID:EeW/BzCK

「ギャラクシアン」「タスクシステム」でぐぐると
ナムコ信者とかレトロゲーマニアの知ったかウンチク話として
「タスクシステム」が再定義され広まったのがよく分かる。

こういう出典不在＆伝聞のみで造られたゲームファン用語を
真に受けた素人がCマガの記事を書いて更に広めたのは
致命的だったね。

142 ：名前は開発中のものです。：2007/04/19(木) 23:54:13 ID:9JdMu3w7

どっかのスレで「古典タスク」とかいう謎の言葉を見かけたな。
あとは「タスクシステムはもう古い」とかいう珍発言もたまに見る。

ゲームファン用語というより知ったかワナビー用語だろ。

143 ：名前は開発中のものです。：2007/04/20(金) 00:01:20 ID:cgQq0Bo+

ローカル定義だけ葬るのはもう無理か。
ゲームエンジンでいいよもう。

というわけで関数アドレス+汎用ワークメモリのリンクリストが～とか
どうでもいい仕掛けを車輪の再発明して延々その素晴らしさを語ってる
オナニストが作ってるのはセンズリシステムでいいよもう。

Irrlicht使おうぜ。

144 ：名前は開発中のものです。：2007/04/20(金) 00:16:48 ID:65Qprn+K

俺はCrysis Engineを触りたい。

145 ：名前は開発中のものです。：2007/04/20(金) 02:10:06 ID:cGzgTfv7

しかしデリゲートをベクターコンテナにぶち込んで使う

146 ：名前は開発中のものです。：2007/04/20(金) 03:42:12 ID:RUahNebB

オレはIrrlichtに自前のタスクシステムを乗せるよ。

147 ：名前は開発中のものです。：2007/04/20(金) 07:42:04 ID:ZqUifK9K

関数ポインタだとか汎用ワークメモリだとかは
初心者にとって勉強になるから再発明上等なんだが、
その程度のレベルの奴が悟った気になって
中途半端な理解で解説を書いて広めるからタチが悪い。

148 ：名前は開発中のものです。：2007/04/20(金) 11:42:46 ID:EI0MmUU2

>>147
そこまでおっしゃるんなら
是非みんなの目が覚めるような解説サイトを作ってください
ID:ZqUifK9K先生！

149 ：名前は開発中のものです。：2007/04/20(金) 12:17:21 ID:ohBEpQ/x

タスクシステムを紹介してる人を叩くスレはここですか

150 ：名前は開発中のものです。：2007/04/20(金) 13:19:25 ID:J62A1B0A

また>>82が来たのか

151 ：名前は開発中のものです。：2007/04/20(金) 13:44:21 ID:EI0MmUU2

また>>90が来たのか

152 ：名前は開発中のものです。：2007/04/20(金) 14:51:16 ID:ignHfO5a

確かにタスクシステムは可用性の高いやり方ではあると思うけど、
実態は単なるリストのデータ構造なので（勿論それから拡張された高度なものも存在するけど）、
「タスク」やら「システム」やらの単語は不似合いに思えないことも無い。
そしてそういう単語で付け上がるような中二病野朗は非常にたちが悪い。
死んでくれとは言わないけど、考えを改め直して現実を見て欲しい。

153 ：名前は開発中のものです。：2007/04/20(金) 20:30:26 ID:RUahNebB

というかC++でいうオブジェクトをリスト管理するのが
タスクシステムなんだよ。

アセンブラだけで開発してた頃に使ってたから割と
いい発明だったんだよね。

154 ：名前は開発中のものです。：2007/04/20(金) 20:38:17 ID:EI0MmUU2

>>153
＞というかC++でいうオブジェクトをリスト管理するのが
＞タスクシステムなんだよ。

なんかちがわね？

155 ：名前は開発中のものです。：2007/04/20(金) 20:39:36 ID:VkPjbBgj

もうタスクじゃない別の呼び名をつけてあげたら？

156 ：名前は開発中のものです。：2007/04/20(金) 20:44:06 ID:KK8Da6ng

重要度思考設計とか？

157 ：名前は開発中のものです。：2007/04/20(金) 21:32:26 ID:fGL33psr

タスクシステムを古いとか古典とかいう人は、
どうやって実装しているの？
XXというフレームワークとか開発キットをつかっている、という答えでもいいけど、それ自体はタスクシステムをつかっていないの？

あと、たとえばマルチスレッドを使うとタスクシステムはいらなくなる？

158 ：名前は開発中のものです。：2007/04/20(金) 23:05:53 ID:UGzQxCti

>>157
その前におまえの脳内定義上のタスクシステム
について説明したまえよ。

＞それ自体はタスクシステムをつかっていないの？

お前の言うそのタスクシステムとやらの定義によるな。

＞あと、たとえばマルチスレッドを使うとタスクシステムはいらなくなる？

お前の言うそのタスクシステムとやらの定義によるな。
で、お前の定義したタスクシステムを前提にした場合の
上記質問事項についてのお前の経験に基づく見解を聞かせてくれよ。

159 ：名前は開発中のものです。：2007/04/20(金) 23:42:39 ID:RUahNebB

便利なものはすべてタスクシステムだ！

160 ：名前は開発中のものです。：2007/04/20(金) 23:49:49 ID:cGzgTfv7

マルチスレッドプログラミングもタスクシステムの一種？

161 ：名前は開発中のものです。：2007/04/20(金) 23:53:22 ID:KC13gbVA

Q. タスクシステムって何？
A. 言語仕様の進歩により実体を失なうシステムのこと。

162 ：名前は開発中のものです。：2007/04/20(金) 23:55:47 ID:0083p4+e

関数ポインタ+汎用ワークのリンクリストをタスクシステムと呼ぶのは個人の自由だし
木製骨格+羽布張り+マキシム機関銃の飛行機をステルス戦闘機と呼ぶのも自由だけど
声を大にして言うとキチガイと思われるから気を付けようね、というごく基本的な話。

163 ：90：2007/04/20(金) 23:58:56 ID:0083p4+e

>>151
それは被害妄想だよ。

164 ：名前は開発中のものです。：2007/04/21(土) 00:01:14 ID:ohBEpQ/x

ガンダムみたいなIDだな

165 ：名前は開発中のものです。：2007/04/21(土) 00:18:39 ID:b9DOuvNS

>>118
遅レスでやんすが
熱い論争が巻き起こるものの、結局結論が出ないので不毛この上ない
という意味でござんす。

166 ：名前は開発中のものです。：2007/04/21(土) 00:26:45 ID:ohzUMwwU

リフレッシュレートは、3倍して計算というナイスな結論が出てた様な気がするけど、
あの後まと話がこじれたのかいな？

167 ：名前は開発中のものです。：2007/04/21(土) 00:57:21 ID:Cncyo4d6

だいたい液晶はリフレッシュしてないし。

168 ：名前は開発中のものです。：2007/04/21(土) 03:08:49 ID:96E91bg8

現状を憂うのは大変結構な事だけど
意見をまとめたコラムをどっかに投稿したり、サイト作ったりしないの？
掲示板の書き込みを追っていくのは辛い

169 ：名前は開発中のものです。：2007/04/21(土) 08:33:00 ID:qfI0z2jN

>>158
たとえば↓この本で書かれているタスクシステムを「タスクシステム」と定義してみるとどうだ？
http://cgi32.plala.or.jp/higpen/book/shtPro/shtPro.shtml

170 ：名前は開発中のものです。：2007/04/21(土) 09:31:26 ID:rc3MbHen

>>169
その本を書いた松浦健一郎が大混乱の元凶なわけだが

171 ：名前は開発中のものです。：2007/04/21(土) 09:40:41 ID:FI1lzfn8

で、その本の中では何て定義してるの？

172 ：名前は開発中のものです。：2007/04/21(土) 10:35:11 ID:qfI0z2jN

>>170
おいおい、やっとタスクシステムを定義しようと努力して、これから
マルチスレッドとか他の実装方法との比較を論じようとしているんだから、
「大混乱」とか結論ありきのワンセンテンスメッセージはやめようよ。

おれは、この本のタスクシステムをみたとき、ふつうにマルチスレッドでキャラを動かせばいいじゃない
（わざわざオブジェクトをNEWしてリストに組み込んでいかなくてもいいのに）
と思った。
開発効率とか品質（スピード）などからの面でどのくらいメリットがあるのか、疑問におもった。

その辺の意見をききたい。
自分ではこの本と同じものをマルチスレッドで書いたりする余裕もないからね。

173 ：名前は開発中のものです。：2007/04/21(土) 11:09:21 ID:laYGd4sA

読み進めたけど話が進まないね
タスクシステムってなんなのか調べてみた

ttp://www5f.biglobe.ne.jp/~kenmo/program/task/task.html
ttp://www5f.biglobe.ne.jp/~kenmo/program/task/task2/task2.html
ttp://homepage3.nifty.com/moha/prog_task.html

わからなかった

　　　　　　　　　　　　　　　　　　　　　　糸冬　わ　　り

174 ：名前は開発中のものです。：2007/04/21(土) 11:17:18 ID:Cncyo4d6

>>172
そんなことしたら、シングルコアCPUなら普通に動くけど
マルチコアCPUにするとまともに動かない素敵なシステムになりますよ。

175 ：名前は開発中のものです。：2007/04/21(土) 12:15:44 ID:3GQIcX1J

沖縄県の方へ（命に関わる注意事項です）

沖縄県での選挙ですが、どうか民主党だけは避けてください。県民の生命に関わる可能性があります。
民主党の最大の公約は一国二制度（※）ですが、一度「一国二制度　沖縄　三千万」等で検索をお願いします。
この際、民主党のＨＰで調べても良いです。以下の注釈↓と矛盾することは書いてないはずですから…

※一国二制度
　簡単に言えば沖縄を中国と日本の共有物にし、そこに3000万人の中国人を入植させます。
　（つまり沖縄人口の 96% を中国人にして、実質、沖縄を中国人の居住地とします。）
　さらに「自主」の名の下、沖縄で有事が起きても自衛隊は干渉できません。
　3000万人の中国人が、少数派となった130万人の日本人に何をしても、です。
　そして反日教育を受けた中国人の反日感情の強さは、ほとんどの日本人の理解を超えるものです。

今回の選挙で民主党が勝った場合、「自主」「発展」を連呼しつつ段階的に進めていくことになります。
自主と言っても、自主を認めるのが「住人の96%が中国人となった」後だということに気をつけてください。
発展と言っても、新沖縄の少数派となった「少数民族日本人」の発展ではないことに気をつけてください。

176 ：名前は開発中のものです。：2007/04/21(土) 13:08:27 ID:laYGd4sA

>>175みたいなネトウヨきもいな
言われなくても分かってるだろ普通に・・・
今まで無知だった自分への恥隠しのつもりか何かか？

177 ：名前は開発中のものです。：2007/04/21(土) 13:13:02 ID:qfI0z2jN

>>174
つまり、マルチスレッドだとマルチコアCPUの場合、まともに動かなくなる。
軽量スレッドであるタスクシステムだと、CPUのアーキテクチャに依存せずに動作する。
以上のようなメリットがタスクシステムにはある、ということだな。

178 ：名前は開発中のものです。：2007/04/21(土) 13:14:51 ID:Cncyo4d6

ぜんぜん違いますよ。タスクをマルチスレッドで実装するのは
難易度が高い。

その辺を認識せずにスレッド使えばいいとか言ってるアホには
無理なんじゃねってこと。

179 ：名前は開発中のものです。：2007/04/21(土) 14:16:13 ID:sEVsPTrc

古典ゲームタスクシステムはリストの任意位置にロギングタスクを仕込むなど
リソース最適化のためのロジックを入れやすい強みがあるからダメダメってわけでもない。

180 ：名前は開発中のものです。：2007/04/21(土) 15:28:49 ID:iSBz72w9

＞ID.qfI0z2jN
ねー、だから>>169の本の中でのタスクシステムは
どういう定義になってるんだい？

181 ：名前は開発中のものです。：2007/04/21(土) 19:46:23 ID:445SE7r4

今求められているもの

・タスクシステムの定義（俺の見る限りではワーク領域を持ったリスト構造のことを指している事が多い木がする）
・なぜワーク領域のあるリスト構造をタスクシステムと呼んではいけないのかに対する回答
・結局どうやって実装するのがいいのか（一概には言えないっていう答えが妥当ならそれでスレ終了）

182 ：名前は開発中のものです。：2007/04/21(土) 22:03:55 ID:qfI0z2jN

>>181

タスクシステムの定義は>>169のリンク先からサンプルコードをダウンロードしてList3-1と3-2だけみればわかると思う。
List3-1はタスクの構造体、List3-2はそれの実行ルーチンをあらわしている。余裕があったらC++の実装版もみてみるといい。

二番目の回答はどうでもいいような気がする。

で、３番目。
「一概には言えない」でもいけど、マルチスレッドとの比較というテーマなら具体的に比較できると思うぞ。
いまのところCPUをシングルコアという条件で限定すればタスクシステムは、マルチスレッドに対してメリットがあるという答えはでてきてない。

でもマルチスレッドはリソースを多く消費しそうなきがするんだよな。タスクシステムは軽量の自家製スレッドだから
スピードも早くメモリ消費も少ないというレポートがあってもいいように思うんだが。

183 ：名前は開発中のものです。：2007/04/21(土) 23:08:52 ID:6oOZ9JbV

>>181
＞・タスクシステムの定義（俺の見る限りではワーク領域を持ったリスト構造のことを指している事が多い木がする）
狭義
固定サイズのワーク領域を持った単方向リスト構造でサブルーチンの交換が可能なもの
ギャラクシアンの実装を原典とする

広義
ワーク領域を持ったリスト構造
ギャラクシアンの設計を原典とする

＞・なぜワーク領域のあるリスト構造をタスクシステムと呼んではいけないのかに対する回答
ほかの用語（↓）と混同するから
プリエンプティブマルチタスクとは【preemptive multitasking】 - 意味・解説： IT用語辞典 e-Words
http://e-words.jp/w/E38397E383AAE382A8E383B3E38397E38386E382A3E38396E3839EE383ABE38381E382BFE382B9E382AF.html

＞・結局どうやって実装するのがいいのか（一概には言えないっていう答えが妥当ならそれでスレ終了）
一概には言えない
……が「あのゲームを俺が実装するならこうするね」的な話は有意義だと思う
もし俺が2DSTGを実装するならリストよりツリー構造を使うよ
親子関係をもつキャラクタを適切な順番でまわすのに適しているし
キャラクタのグルーピングがしやすいので敵キャラだけ舐めたいときなどに無駄な処理が減る

184 ：名前は開発中のものです。：2007/04/21(土) 23:20:34 ID:Ii4A4TL3

C++ で言えば、毎フレームの処理を実装したクラスインスタンスのリストだろ？
そんなの画面ごとに std::list<Task*> なりで持てばいい。よく使うなら適当に
ラップしたクラス用意すればいいだろう。

「タスクシステム」とか呼ぶ人は、何でもかんでもグローバルだったり、
プログラム全体にこの構造を当てはめる傾向があって嫌い。

185 ：名前は開発中のものです。：2007/04/21(土) 23:23:05 ID:96E91bg8

>ほかの用語（↓）と混同するから
JAVAスクリプトみたいなもんか

186 ：名前は開発中のものです。：2007/04/21(土) 23:37:57 ID:sEVsPTrc

「タスクシステム」
飽くまで全てをひとつのリストに押し込めようとする努力が多くて、
手段が目的となってる感のあるアプローチのこと。

187 ：名前は開発中のものです。：2007/04/22(日) 00:00:51 ID:SVESfasi

マルチスレッドで効率よく使えない技法なぞ過去の遺物じゃ

188 ：名前は開発中のものです。：2007/04/22(日) 00:31:08 ID:useOh8AV

>>182
おいおいサンプルのダウンロードなんかできないぞ。

189 ：名前は開発中のものです。：2007/04/22(日) 00:53:25 ID:useOh8AV

>>182
＞マルチスレッドとの比較というテーマなら

どういう比較をするつもりなのか知らないが、まさかとは思うが
お前の定義するそのタスクシステムのタスクひとつひとつを
スレッドに置換するような形で比較するのではあるまいな。

＞タスクシステムは、マルチスレッドに対してメリットが

お前の定義するそのタスクシステムとやらは
マルチスレッドとは排他的な存在のようだから
やはり上記の「まさか」は当たっているということか。

＞タスクシステムは軽量の自家製スレッドだから

タスクシステムとマルチスレッドをなぜ排他的な存在

いまのところCPUをシングルコアという条件で限定すればタスクシステムは、マルチスレッドに対してメリットがあるという答えはでてきてない。

でもマルチスレッドはリソースを多く消費しそうなきがするんだよな。タスクシステムは軽量の自家製スレッドだから
スピードも早くメモリ消費も少ないというレポートがあってもいいように思うんだが。

190 ：名前は開発中のものです。：2007/04/22(日) 00:55:49 ID:useOh8AV

上は送信ミスだ。

>>182
＞マルチスレッドとの比較というテーマなら

どういう比較をするつもりなのか知らないが、まさかとは思うが
お前の定義するそのタスクシステムのタスクひとつひとつを
スレッドに置換するような形で比較するのではあるまいな。

＞タスクシステムは、マルチスレッドに対してメリットが

お前の定義するそのタスクシステムとやらは
マルチスレッドとは排他的な存在のようだから
やはり上記の「まさか」は当たっているということか。

＞タスクシステムは軽量の自家製スレッドだから

それならファイバーやマイクロスレッドと呼べばいいんじゃないか。

191 ：名前は開発中のものです。：2007/04/22(日) 01:11:41 ID:QxI8Jcnw

だいたいわかった。

>>184
のように、タスクシステムというのはふつうに使われている。
ただし、一部（多数？）の人は、わざわざタスクシステムなんていって仰々しく議論することに違和感がある。
ちなみにファイバーとかマイクロスレッドなどと呼べばまだましらしい。

192 ：名前は開発中のものです。：2007/04/22(日) 03:36:04 ID:gWESM4cO

>>191
それなんかちょっと違和感が．
前の方はあんま読んでないんだけど，自分の感覚では以下な感じ．
fiberは「非時分割で非プリエンプティブ（協調型）なスレッド」
タスクシステムは「エージェント集合でゲームを作るシステム」
現実には同期問題からエージェント=fiberの実装が多いけど，
スレッドでも同期エージェントを作れば，タスクシステムは成り立つと思う．

fiberの場合のみに限定したとしても，fiberは実装方法であって，
「エージェント集合」が肝であるタスクシステムとは別だと思うんだけど．

#名前付けるほどのことか，という話には納得する面もあるんだけど，名前なんて大体そんなもんだと思う．
#あとワーク領域がうんたらって話は化石過ぎるんじゃないかしら．

193 ：名前は開発中のものです。：2007/04/22(日) 04:51:35 ID:YZWy+Lh2

>>172
> おれは、この本のタスクシステムをみたとき、ふつうにマルチスレッドでキャラを動かせばいいじゃない
無理無理ｗ
キャラクター1000体表示したら、1000個マルチスレッド動かすのかy。

しかも、全部好き勝手、平行に走るんだぜ？
1000体分同期取るんだぜ？

194 ：名前は開発中のものです。：2007/04/22(日) 08:07:47 ID:KD72KCOk

素朴な疑問なんだけど、ゲームって条件判断つきのアニメだよな。
パラパラアニメに分岐があるだけだよな。分岐ってか、インタラクティブってか。
入力があって、計算して、描画、音再生して、その繰り返し。たかが、それだけなのに、
なんちゃらかんちゃらカタカナが飛び交うってのも、不思議だと思った。
きょうびのパソコンなら、if文が１万あっても、フレームレートへの影響って
微々たるものではないかと、察するのだが、推測なので、実際分からんけど、
感覚的には、そんな感じで。
だからさ、お前ら、アポだな、と思った。いや、アポなのは俺かも知れないけど、
正直な気持ちとして、そう思ったのだ。

195 ：名前は開発中のものです。：2007/04/22(日) 08:29:39 ID:YZWy+Lh2

誤爆？

196 ：名前は開発中のものです。：2007/04/22(日) 08:36:23 ID:U5lotNIv

ヒトのやってる事にケチつけないと気がすまないのか？
マジメにやってる奴を馬鹿にするレスは不愉快なだけ。
だいたいここはゲームの技術について語る場所だ。
なんとなく思っただけの事ならチラシの裏にでも書いてろ。
俺の言いたいのは以上だ。
もう二度とつまらん書き込みするなよ。

197 ：名前は開発中のものです。：2007/04/22(日) 09:25:02 ID:ridILpBz

>>196
おまえもなー

198 ：名前は開発中のものです。：2007/04/22(日) 09:38:30 ID:KD72KCOk

ぶっちゃけ、俺はタスクシステムが分からない。>>１２３みたいな実装だな。
つーか、それで、何が問題なのか分からないんだ。具体例はないし、どこ
ぞの信者が、わけわからず布教してるだけなスレだな。いくら、あーたら、
こーたら、書き連ねても、何の生産性もないよね。１２３がもっと、詳しくそ
の説明ってか、具体的にどう、メガマウスなのか、コードを交えて、解説を
やって欲しいけど、名無し掲示板だと、どうにも議論的な発展がないな。い
ろいろな発言があるようで、大して、書いてる人はいないなら、HNがあるほ
うが、放置ってか逃亡が認識できて終わりが分かるのでいい気がするっす。

199 ：名前は開発中のものです。：2007/04/22(日) 10:24:01 ID:QxI8Jcnw

>>193
サンキュー。やっと具体的な議論ができる発言がでてきたな。
つまりタスクシステムは、

　「同期を取る必要がある数1000にものぼるオブジェクトを対象とする並行処理（１つの処理は短時間）を、
　少ないリソースで実現させることができる。」

というメリットがあるわけだ。
それをマルチスレッドやったら重過ぎると。
たしかに「組込みマルチタスキングプログラミング」という本をよむとマルチタスキングの４つの基本要件として、
①コンテキストスイッチング、②タスク間通信、③実行優先度、④タイミング制御
があげられているがこれらを少ないリソースで実現でき、かつ構造化されている手法がタスクシステムということだな。

200 ：名前は開発中のものです。：2007/04/22(日) 14:33:04 ID:lvPS3FuZ

タスクシステムを構築するのに、内側でマルチスレッドを使っても問題はない。
よってリソースがどうこう言う利点は当てはまらない。
結局は実装方法によりけり。

201 ：名前は開発中のものです。：2007/04/22(日) 14:52:48 ID:f5nllPrq

>>194 >>198は昔からいろんなスレで
阿呆なことばかり言っている奴なので気にしない方向で

202 ：名前は開発中のものです。：2007/04/22(日) 15:05:20 ID:kFHvjrd1

所謂タスクシステムとは団子の数が増減する串団子みたいな物だよな

●→先頭
◎→しんがり
○→プレイヤーオブジェクト

ゲーム開始時はこんな感じ
●○◎

敵キャラやらアイテムなどのオブジェクトが必要に応じて生成されると
●○△△△◇×△◎

原始的な手法と言うと語弊があるが、所謂配列型のシステムが
常に一定のメモリを使用するのに対して
所謂タスクシステムは必要な時に必要な分のメモリしか使わない
リソースを使いたい放題の富豪的なプログラミングが許される今となっては
積極的に使用する意味はない

203 ：名前は開発中のものです。：2007/04/22(日) 15:07:29 ID:gWESM4cO

>>200
自分もそう思うんだけど，
このスレ的にはfiberな古典実装のみを扱うのかな？

>>199
間違いでは無いと思うんだけど，視点がちょっとずれてる気がする．
それはスレッドとfiberの対比に近くて，利点としては副次的なものじゃないかな．
タスクシステムはエージェント(タスク)集合にすることで
エージェントごとのコードを1箇所に集められるとか，依存性から実装を取り除けるというみたいな，
所謂OO的な利点が主なんじゃないかしらん．

204 ：名前は開発中のものです。：2007/04/22(日) 15:44:05 ID:KD72KCOk

富豪的プロぐらっむって、他に、学術的な呼称はないの？

205 ：名前は開発中のものです。：2007/04/22(日) 15:45:03 ID:CSfmZnZe

>>203
タスクシステムというとなんとなくノンプリエンプティブな気がする。
現在のOSが持ってるスレッドはプリエンプティブだから、
OSの用意したスレッドでタスクシステムを実装するのは不便な気がする。

マルチコアCPUで高速化するために、複数のタスクシステムを
マルチスレッドで並列実行とかならありだと思うけど。

206 ：名前は開発中のものです。：2007/04/22(日) 16:00:54 ID:29CA+INJ

PCゲーの場合、CPUコア数なんてばらばらなんだから
スレッドプールでごにょごにょってのは
frame per scondの存在しないゲームくらいでしか有効じゃないと思う

207 ：名前は開発中のものです。：2007/04/22(日) 16:06:58 ID:4Cp/kF21

実際に実測して検証したわけじゃないけど

なんとなくポインタ使ったリスト形式のタスクシステム？（名前が悪い！ｗ）
が速いような気がするから1フレーム(60FPSなら16ms位?)におさめるのに性能を重視する
ゲームで使われてるんだと思います

ていうか俺はイメージで使ってるｗ
なんか、new,deleteとか遅いイメージあるし。
ましてやstdなんてごにょごにょ・・・

208 ：名前は開発中のものです。：2007/04/22(日) 16:14:42 ID:YZWy+Lh2

>>200
ちげーよｗ
拡大解釈すなｗ
本来のタスクシステムの話してんじゃねーよ

少なくとも、このスレのタスクシステムはゲームでの古典的な擬似タスク（もうこの単語も鼻水でるが）の話。
だから、基本マルチスレッドは使ってない。

209 ：名前は開発中のものです。：2007/04/22(日) 16:17:57 ID:YZWy+Lh2

>>207
実際に動的生成で、速度駄目かどうかってのは、計った方がいいよ。
動的生成の方が楽できるんだし。

はっきりいって、ゲームによる。キャラクターが少ないなら、動的でいい。
パーティクルとかは、さすがに、動的生成でもプールするけど。

もちろん、高速なメモリマネージャを使うのを前提だけどな・・・

210 ：名前は開発中のものです。：2007/04/22(日) 16:27:38 ID:4Cp/kF21

>>209
動的に生成したほうが手軽だし、リソースの管理にしたってクラス作ったほうが楽なのはわかってるけど

なんかゲーム作成となると古典的なCの手法の方が速いような気がするんですよね（これもイメージだけど）ｗ
ちなみにゲームじゃなけりゃ。俺もstd::vectorとかclassとか使いまくります。

まあ、やっぱり一番よいのは実測して問題ない方法を使うことなのかも・・・

211 ：名前は開発中のものです。：2007/04/22(日) 16:36:46 ID:KD72KCOk

これは具体的だね。

http://mkmqwerty.hp.infoseek.co.jp/programing/tips/tips_index.html
「なんだか煩雑なソースになってきました。実際にはこれに加えて、タイトル画面、
エンディング、スタッフロール等の分岐があり、敵の種類ももっと多いでしょう。上
記のようなソースでもゲームを、とりあえずつくることはできますが、ソースが読み
づらく管理が難しいです。そこでタスク処理と呼ばれるものを導入します」

俺は、上記のようなソースでも、作れる。
だから、タスク処理いらない。
なんだ、タスクって、逃げかよ。

212 ：名前は開発中のものです。：2007/04/22(日) 16:39:05 ID:O3yavdGP

動的に領域を確保するやり方のなにがいけないの
ゲームによるけど動的に確保するのも悪くないだろ
↓
（いまここ）
やっぱり一番良いのは速度計ったりして検討した方法だね
↓
それならPCごとに差が出てもおかしくないだろ　できるだけ汎用性のあるやり方をするべき
領域確保の失敗処理も最初の一回で済むし、逐次的な動的確保より
やっぱりタスクシステム（鼻水でる単語だけど）の方が良いね
↓
（一番最初へもどる）

213 ：名前は開発中のものです。：2007/04/22(日) 16:43:49 ID:O3yavdGP

>>211
かるいミニゲームとかならそれで十分かもしれないが、
巨大なものを組むならお前の言ってるつくり方ではまず難しすぎる。
それに複雑な面を組むときは、1フレームごとに数百、数千のifを見なくちゃいけないのか？
いくらなんでもそれは馬鹿馬鹿しい。

というかその言い分はなに？タスク処理からの逃げかよ、と突っ込まざるを得ない。

214 ：名前は開発中のものです。：2007/04/22(日) 16:54:16 ID:4Cp/kF21

>>212
うは！不毛だ

コンシューマ機なら一定の性能だけど。。。
パソはね・・・・

215 ：名前は開発中のものです。：2007/04/22(日) 16:55:46 ID:KD72KCOk

>>213
CPUからして見れば、数千のif文なんて、目くそじゃんｗ
人間的には、当該コードだけ眺めればいいわけで、頭からけつまで見る必要
ないしｗ

「富豪VSタスク」戦争の勃発ですね。（むふー）

216 ：名前は開発中のものです。：2007/04/22(日) 17:08:03 ID:tSd7SPRg

ここでいわれているタスクシステムか、
もっと素直なやり方しか知らないってのが大きい気がする。

ってか、他の方法にはどんなのがあるの？

217 ：名前は開発中のものです。：2007/04/22(日) 17:11:10 ID:O3yavdGP

ゲームループ中で、膨大な数の弾や敵機の存在フラグをifで見るのは愚行というもの。
ある程度まともで、リアルタイムなレスポンスが要求されるゲームなら、動かすべきものは優に1000を超える。
そしてそういうものはfpsも60以上が相場なので、画面上に何も無かったとしても、
単なる内部処理で1secに60000という条件分岐を処理しなければならない。
条件分岐のコストというのは非常に高く、昔は、1secに60000まではないとしても多くの条件分岐を処理させたのでは
パフォーマンスに関わることが多かった。
そして今でも、高速性が求められるものでは条件分岐のコストを考慮せざるを得ないので、
タスクシステムの需要も無いわけではない。
処理の負担を考慮しない無計画な設計というのは、巨大なゲームを組む時は許されない。
コード全体が失敗した設計に依存してしまうことが多く、取り返しが付かなくなってしまうからだ。
というかそろそろID:KD72KCOkはあぼーんしておいたほうがいいな。馬鹿にもほどがある。どうせ釣りなんだろうが。

218 ：名前は開発中のものです。：2007/04/22(日) 17:26:48 ID:KD72KCOk

>>217
たかたが、スーパーマリオのコピーアンドソースも見当たらない、低レベルな
ゲ製作技術板で、そんなこと言われてもなぁ。

219 ：名前は開発中のものです。：2007/04/22(日) 17:29:32 ID:5nxQbdiI

タスクシステムで分岐の負荷が消えるかのような書き方は
感心できないね。関数ポインタで分岐してたら根本的には
解決してないだろ。

存在フラグなんてものを全対象分用意した場合にくらべて
処理しない場合の無駄な分岐は削除できるけど、
それは C++ での仮想関数で十分実現できるよね？

220 ：名前は開発中のものです。：2007/04/22(日) 17:44:24 ID:BUzInjQ8

多人数で開発する時にシステム化しておくと楽っしょ？
戦闘シーンやフィールド・メニューやショップの処理も、共通のルールで相手がどんな処理（シーン）か知らなくても自由に以降できる汎用性の高いシステムで、わりかし簡単なのがタスクシステムなんじゃないの？
ゲームのオブジェクトだけじゃなく、当たり判定からタイムカウントもシーンの管理も全部タスクに突っ込めるのは楽でいいよ。
いまならそれを発展させて、ツリーでもなんでも好きに作ればいい

221 ：名前は開発中のものです。：2007/04/22(日) 17:45:43 ID:BUzInjQ8

あと、処理の順番も優先度で明確に出来るし、フレームごとのきっちりしたエフェクトするのも向くかも
いまのフレームレートに依存しないタイプのゲームではどうなのかわからんけど

222 ：名前は開発中のものです。：2007/04/22(日) 18:06:34 ID:v/ich/HT

>>220
>共通のルールで相手がどんな処理（シーン）か知らなくても自由に以降(移行?)できる

タスクシステムじゃなくてタスクパターンとでも呼んだ方がわかりやすい気がする。
主観だがシステムというともう少し硬い機械よりなものをイメージするんだよね。

223 ：擬似タスクｗ：2007/04/22(日) 18:17:11 ID:aF9z9yRP

「リフレッシュレートに関する論争」
「タスクシステムに関する論争」

うはｗｗｗｗゲームにおけるデータ構造・クラス設計・パターンｗｗｗｗｗｗｗ

224 ：名前は開発中のものです。：2007/04/22(日) 18:30:35 ID:gWESM4cO

>>ID:O3yavdGP，ID:KD72KCOk
動的/静的とか富豪/貧乏みたいなコスト面で見る事自体が本質を見誤ってる．
>>211の引用の通り，
べた書きは煩雑で管理が難しい->タスクで処理，依存性を分離すると楽
という話．

>>221
>あと、処理の順番も優先度で明確に出来るし、フレームごとのきっちりしたエフェクトするのも向くかも
優先度による同期の代わりに「キャラ全員の移動完了を待って当たり判定タスクを起動」するような同期タスクでもOKでしょ？

225 ：名前は開発中のものです。：2007/04/22(日) 18:41:05 ID:3Cbey4i0

>>217,220
多態の一言で済む話をタスクだなんだとゴチャゴチャ言ってるから
低レベルとか古臭いとか言われるんだよ

226 ：名前は開発中のものです。：2007/04/22(日) 18:42:08 ID:ZoaDc3VU

タスクシステムをフレームワークに置き換えて読めば
自分たちがどれほど恥ずかしいことを言ってるかすぐわかる。

フレームワークがなんなのか判らない奴には判らんかｗ

227 ：名前は開発中のものです。：2007/04/22(日) 18:50:14 ID:YZWy+Lh2

>>224
べた書きで難しいなら、普通、今時なら、多態使うだろう。
ロートルじゃあるまいし。

見るべきは、コスト面じゃないのか？

228 ：名前は開発中のものです。：2007/04/22(日) 19:30:55 ID:5nxQbdiI

ロートルがタスクを宣伝しやがったおかげで多態とかの一般的な技術よりも
先に「タスクシステム」とやらに手をつける奴が多いのよ。

その流れで関数ポインタやらリスト構造やらメモリプールやらを
初めて知ることになると、「タスクシステム」が何か偉大な技術みたいに
錯覚しちゃうんじゃないかと思うんだ。

今で言えば関数ポインタは仮想関数で、リスト構造は std::list で済む。
メモリプールも最近の環境では不要なことのほうが多いだろう。

229 ：名前は開発中のものです。：2007/04/22(日) 19:41:55 ID:GAzy/Bcl

>>228
逆じゃね？
最近は、オブジェクト指向を一通り理解したやつしかタスクシステムに手を出していないと思うよ。

230 ：名前は開発中のものです。：2007/04/22(日) 19:44:55 ID:QxI8Jcnw

>>224のまとめ方は納得できるものだな。
素直に理解できる。

だが、「多様」というキーワードがでてきているのが気になる。
書き方はもっともらしい文体だが、内容はよく読むとなにもない。
無視していいような気がするがID:gWESM4cO他みなさんはどう思う？

231 ：名前は開発中のものです。：2007/04/22(日) 19:50:39 ID:KD72KCOk

もういい。わけわかカタカナが飛び交うオナニープログラムはいい。
変数はすべてグローバル、ユーザー定義関数は使わない。制御はループとイフと
フォーの３つのみ。制御用の変数はフラグ（多値）とカウンタのみ。使用言語はLGP。
俺は、これで、FF１４でも、スーパーマリオ１０でも、メタルギアソリッド７でも
モーターストーム３でも、ドラゴンクエスト１４でも、なんでも、作っちゃうんだからね。（むふー（鼻息））
たかだか、パラパラアニメですから、楽勝ですよ。
むふー。
まぁ、いつか。な。

232 ：名前は開発中のものです。：2007/04/22(日) 19:57:07 ID:gWESM4cO

>>227
そうなんだけど，違うというか．．
ワタシのＩＤのレス見てもらえば分かると思うんだけど，
多態に限らずストラウストラップ的OOの(エージェント/オブジェクト/タスク)集合により
ゲームを構築するシステムをタスクシステムと言うんであって，
リストが，fiberが，というような実装の話は実例であってそれ以上ではないと思う．

1実装例（データ構造）のコストを挙げて，タスクシステム(アルゴリズム，パターン)の良し悪しを言うのはお門違いというか．

233 ：名前は開発中のものです。：2007/04/22(日) 20:04:34 ID:v/ich/HT

>>232
> 多態に限らずストラウストラップ的OOの(エージェント/オブジェクト/タスク)集合により
> ゲームを構築するシステムをタスクシステムと言うんであって，

誰か翻訳してもらえませんか。

234 ：名前は開発中のものです。：2007/04/22(日) 20:08:12 ID:4/EgVnhk

"ストラウストラップ" の検索結果約 773 件
"ストラウストラップ的" の検索結果 1 件

235 ：名前は開発中のものです。：2007/04/22(日) 20:11:45 ID:4/EgVnhk

※1 ストラウストラップ的OO

ビアルネ・ストラウストラップのオブジェクト指向。

データ型を定義するのに、「クラス」（もともとはオブジェクト指向とは関係のない SIMULA の言語機能）と
その特徴である「継承」を活用するプログラミング手法。

ストラウストラップが '80 年代半ばごろまでに C++ の設計を通じて整理したもので、
現在主流のオブジェクト指向の考え方。

236 ：名前は開発中のものです。：2007/04/22(日) 20:29:47 ID:5nxQbdiI

>>232
> 多態に限らずストラウストラップ的OOの集合によりゲームを構築する

これだけじゃ「C++ 使ってゲーム作ってます」ってだけだろ。
システムでもなんでもない。

237 ：名前は開発中のものです。：2007/04/22(日) 20:30:50 ID:v/ich/HT

>>235
マジレスされても困るんだが。(それにそこだけ書いても普通理解できない、コピペ元を貼るべき。)
ttp://d.hatena.ne.jp/sumim/20040525/p1

多態性にC++もSmalltalkもないし、タスクはデータよりも処理に注目する考え方、故に元コメントは
意味がわからん、と言う意味だったんだが。

238 ：名前は開発中のものです。：2007/04/22(日) 20:50:33 ID:gWESM4cO

>>236
それを言われちゃおしまいなんですが，名前なんて得てしてそんなもんだと思うんです．
あとC++はマルチパラダイムだからC++なOOで～とかのが正確？（どうでもいいね）

>>237
そこをホントに読んだんでしょうか．
Smalltalk（は1のアランケイのと読み替えてもいいんですよね？）は
1.“メッセージングによる可能な限り動的な処理・実装・設計”（メッセージ指向とも）
を読んで多態性という言葉が出てくるのは驚きです．

239 ：名前は開発中のものです。：2007/04/22(日) 20:52:24 ID:1cO9U5KH

タスクシステム（サブルーチンがぶらさがってるリスト）とスレッドの相性は悪いんだろうか？

タスクを食っていくループでCPU資源にうまく割り振れば問題ないはずだ
2～8個程度のスレッドを生成してサブルーチンを処理するたびに次のポインタを受け取る
タスクが銀行のようにフォーク並びをしているのを想像して欲しい
並んでいる人がタスクでATMがスレッドだ

ここで問題になるのは実行する順番が入れ替わったり同時であった場合の影響のことだ
STGであればキャラクタの種別（敵キャラ、弾など）ごとに処理すれば
並列実行の影響を考える必要はない
だから、タスクごとに種別IDを割り振っておけばよい
種別IDが切り替わる所で一度全部のスレッドが処理を終わらせるまで待つことで同期をとる
（もちろんゲームによってはそう簡単にはいかないが……）

いままでタスクシステムでゲームをつくってきた人はループにちょっとした仕掛けを作るだけで
マルチコアCPUに対応できる可能性がある
現状のPC事情を考えると果たして意味がある行為なのかは疑問だがおもしろいTipsじゃなかろうか？
（現状のPC事情・・・マルチコアCPU＝ハイスペック。といってもローエンド機が置き換わるのも時間の問題だろうけども）

240 ：名前は開発中のものです。：2007/04/22(日) 21:12:35 ID:v/ich/HT

>>238
メッセージ指向だから多態(ポリモーフィズム)がないとでも言うのか？ますますわからん。
どちらにしろこのスレでOOと言えばおまいさんの言うストラウストラップ的なやつがデフォ
なのでわざわざ断わられると混乱するだけだよ。

241 ：名前は開発中のものです。：2007/04/22(日) 23:10:29 ID:WXusdEx1

>>239

タスクリストを複数持つのは面白いアイデアだけど、意味なし。
なぜなら、現在のゲームにおいてボトルネックはまず間違いなく、
描画だから。

しかも描画はハード的処理により、スレッド化などしなくても
並列処理にできる。

242 ：名前は開発中のものです。：2007/04/22(日) 23:15:44 ID:P6iYulT4

>現状のPC事情を考えると果たして意味がある行為なのかは疑問だがおもしろいTipsじゃなかろうか？
マルチコアといっても、大抵2CPUしか積まれていないので、
どんなに良くなっても2倍。ほとんど無意味ではあるかな。

コンシューマ機なら話は大きく変わる。
タスク処理を239のようにするのはデフォになる。
ただ、違うスレッドに居るタスク同士が情報をやり取りするとクラッシュするので、
タスクの基礎部分でだけなんとかするのはムリ。

>なぜなら、現在のゲームにおいてボトルネックはまず間違いなく、
>描画だから。
「現在の」じゃなくて、「一昔前の」ならそうかな。
今は物理計算があるから、そうともいえない。

243 ：名前は開発中のものです。：2007/04/23(月) 00:46:11 ID:D3wQozch

>>239はこれだね
ttp://www.watch.impress.co.jp/game/docs/20070131/3dlp.htm

244 ：名前は開発中のものです。：2007/04/23(月) 12:56:56 ID:kPTKND6z

>>241涙目ｗｗｗｗｗｗ

245 ：名前は開発中のものです。：2007/04/23(月) 13:28:32 ID:ofnNc5u7

タスクシステム信奉者の致命的な欠点は古い物にこだわりすぎて、
時代をしっかり把握できないことだな
>>241が代表例

246 ：名前は開発中のものです。：2007/04/23(月) 14:37:15 ID:sF8jML+T

>>241がタスクシステム信奉者なんてどういう見解だよｗ

247 ：名前は開発中のものです。：2007/04/23(月) 23:02:50 ID:59B/D9d+

>>243を見てると、タスクシステムがどうだとかいう議論がむなしくなるなw

248 ：名前は開発中のものです。：2007/04/24(火) 02:12:23 ID:rP75YEIH

>>247
タスクシステムを気軽に楽しめばいいんだよ。
世の中には、いろいろなプログラムを作っている人がいて役立つ人もいる。

手のとどく範囲のプログラムにおいて、タスクシステム（タスクパターン）を使ったら設計が簡単でパフォーマンスも
あがった、なんてレスがあったらいいんじゃないかな。

おれが思ったのは、GUIのキャラクタの移動や、あとはパケットの取得/処理なんかのネットワークプログラミングに
気軽に応用できそうなきがする。いままでThreadたちあげてwhile(true)でまわしていた処理をすべて見直してるところだ。
だれかそういうTipsを集めたWikiつくってくれ。

249 ：名前は開発中のものです。：2007/04/24(火) 02:49:26 ID:icr09Pcb

だからそれはマイクロスレッドとかファイバーだろ。

250 ：名前は開発中のものです。：2007/04/24(火) 03:10:26 ID:pD/5kZWi

ゲーム制作における所謂「タスクシステム」がきちんと定義されてないから終わらんな。

曖昧なまま広がって時が流れすぎた。
みんな自分のタスクシステムこそ正義と信じて、終わり無き議論が続いていく。

まとめられるカリスマｗも現れないだろうしな。
出来る奴はこんな瑣事に関わろうともしない。

251 ：名前は開発中のものです。：2007/04/24(火) 03:59:44 ID:Tdee1eAV

どうせ2chだし、仕事みたいに方向性が別にはっきりとあるわけでもないからな。

252 ：名前は開発中のものです。：2007/04/24(火) 04:08:33 ID:nLYBhYy0

まーた定義厨か。

実装はさておき「サブルーチンがぶらさがってるリスト」では
彼の気が済まないんだろうか。

253 ：名前は開発中のものです。：2007/04/24(火) 06:19:19 ID:0Y4cOVot

今日からこのスレでは
タスクシステム＝サブルーチンがぶらさがってるリスト
になりました

254 ：名前は開発中のものです。：2007/04/24(火) 06:21:41 ID:nLYBhYy0

オーケー、これで議論のループはめでたく終了な。

255 ：名前は開発中のものです。：2007/04/24(火) 08:20:55 ID:rP75YEIH

このスレ自体がタスクシステムで、最近のレスしか読めない人は定義から入ろうとするし
いろんなタスク（ファイバー）が走ってると思えばいいじゃない。
でも、ここからはタスクシステム書いてみるなりして実装方向の
話にうつらないと定義ファイバーしか走らないスレになるな。

256 ：名前は開発中のものです。：2007/04/24(火) 08:30:38 ID:Cn47ifyt

＞実装方向の話にうつらないと

また実装乞食か。好きなように作れよ。
サブルーチンがぶらさがってるリストなんだろ？

257 ：名前は開発中のものです。：2007/04/24(火) 09:17:07 ID:wt/UedOB

なんで早朝からカリカリしてんの？

258 ：名前は開発中のものです。：2007/04/24(火) 11:33:46 ID:BSew7CHC

所謂タスクシステムと、所謂ファイバーは全然違うモノなのに、
なんでここでは同じモノになっちゃってるの？

259 ：名前は開発中のものです。：2007/04/24(火) 11:57:00 ID:aJzi4MOG

タスクシステムの公的な定義なんて存在しないし、
人それぞれにバラバラな解釈をしているんだから、まとまるはずがない。
定義できると思いこんでいるのは、自分の勝手な解釈を他人にもさせようとする、
脳味噌が足りない馬鹿だけ。

260 ：名前は開発中のものです。：2007/04/24(火) 12:37:27 ID:pYdxlQj1

>>259
定義しなくても議論はできるさ。
例をあげて話し合えばいい。
問題は90レスほどするとせっかく提示した事例を無視して定義について云々いう奴が現れることだ。

261 ：名前は開発中のものです。：2007/04/24(火) 18:18:54 ID:DJmpRTH+

ファイバーを「サブルーチンがぶらさがってるリスト」とか表現したら笑われるよ。

262 ：名前は開発中のものです。：2007/04/24(火) 19:00:32 ID:gy8tG6E1

固定された時間分のCPUリソースを各タスクに均一に割り当てるパターンを研究してくれ。

263 ：名前は開発中のものです。：2007/04/24(火) 19:02:48 ID:nLYBhYy0

ファイバの肝はユーザモードでのコンテキストスイッチだもんな。
つーか>>4-5

264 ：名前は開発中のものです。：2007/04/24(火) 19:08:20 ID:nLYBhYy0

>>262
そこまでいくとRTOSを移植したほうが早いだろうな。
しかしゲームにおいてCPU時間リソースを均一に割り振るメリットは殆ど無いと思うのだが。
何か思いつく？

265 ：名前は開発中のものです。：2007/04/24(火) 19:32:32 ID:gy8tG6E1

リアルタイム戦略SLGとか？

266 ：名前は開発中のものです。：2007/04/24(火) 21:55:18 ID:sh8YE+KJ

>>259
＞タスクシステムの公的な定義なんて存在しないし
　
フェードアウト組が大好きなタスクシステムについてはそのとおりだな。
「俺の自慢のタスクシステム」の素晴らしさについてグダグダ語る前に
せめてテメェの脳内定義上のタスクシステムについて説明してから
発言しろ、というごく基本的な話だな。

＞定義できると思いこんでいるのは、自分の勝手な解釈を他人にもさせようとする、
＞脳味噌が足りない馬鹿だけ。

上に同じ。（公的な）定義ができると思い込んでるのは狂信者であり
お前の言う通りの連中だ。

267 ：名前は開発中のものです。：2007/04/24(火) 22:48:36 ID:HwcF2GDq

定義できないとかいっているやつは
他人と協調も議論もできない自分勝手なやつだけだろ

268 ：名前は開発中のものです。：2007/04/24(火) 23:01:09 ID:wt/UedOB

というか通じるよね？定義とかしなくてもさ。
実装してクレとか言ってるわけじゃないんだし、人によって全く違う動作をするようなものじゃないんだから。

269 ：名前は開発中のものです。：2007/04/24(火) 23:31:17 ID:Meuc1va2

面接官「特技はタスクシステムとありますが？」
学生　「はい。タスクシステムです。」
面接官「タスクシステムとは何のことですか？」
学生　「サブルーチンがぶらさがってるリストです。」
面接官「え、サブルーチンがぶらさがってるリスト？」
学生　「はい。サブルーチンがぶらさがってるリストです。」
面接官「…で、そのタスクシステムは当社において働くうえで何のメリットがあるとお考えですか？」
学生　「はい。オブジェクト指向とは全く違う自由度と再利用性の高い汎用的な管理ができるようになります。」
面接官「ほう。もうすこし詳しく聞かせてください。」
学生　「詳しくはCマガジン2006年1月号を参照ください。」
面接官「いえ、あなたの言葉でお願いします。サブルーチンがぶらさがってるリストは何故に
　　　　　　オブジェクト指向とは全く違う自由度と再利用性の高い汎用的な管理ができるのですか？」
学生　「やねうらお先生のサイトも参照ください。URLは・・・」
面接官「いえ、あなたの見解を伺ってるのですが。」
学生　「あれあれ？怒らせていいんですか？使いまｓ」
面接官「帰れよ。」

270 ：名前は開発中のものです。：2007/04/24(火) 23:35:21 ID:nLYBhYy0

自分で自分にレスして「上に同じ」もねぇよなぁ

271 ：名前は開発中のものです。：2007/04/24(火) 23:40:15 ID:sh8YE+KJ

自作自演認定されちゃったよ

272 ：名前は開発中のものです。：2007/04/24(火) 23:44:07 ID:Meuc1va2

>>270
あなたを、タスクシステム普及委員長です

273 ：名前は開発中のものです。：2007/04/25(水) 00:09:37 ID:d3y1YdqK

定義できるのは、ここではタスクシステムをこういう概念で扱いますとローカルで宣言する場合だけ。
グローバルに定義することなど不可能だし、そういうことをしようとする奴は自分の意見を一方的に押し付ける身勝手なやつだけ。
その結果、結局は宗教論争のようになる。

274 ：名前は開発中のものです。：2007/04/25(水) 00:56:02 ID:qAG7MKWl

毎回列に並びなおして、工程ごとに仕事を聞きに来る従業員システムと言えばいいんじゃないの？

275 ：名前は開発中のものです。：2007/04/25(水) 06:27:40 ID:RAoN/rs2

このスレで通じればいいからローカル定義で十分

276 ：名前は開発中のものです。：2007/04/25(水) 08:10:39 ID:Rf7pmltu

>>269
そのレスを建設的な意見ととらえてみる。
たしかに「詳しく議論を」面接官にいわれて、そこからなんにもいいレスは現れてないな。このスレの現状は。

くだらん質問でもいいから、具体的にだれかアプリをタスクシステムで作ってつまづいたところとか
質問すればいいんじゃない？

たとえば２ｃｈブラウザにタスクシステムを取り入れてつくったらどうなる？具体的にはHTTPで
スレをもってくる処理をタスクにしてみてはどう？

277 ：名前は開発中のものです。：2007/04/25(水) 12:18:45 ID:XXwI0rZa

タスクシステムなんてのはあくまで実装の仕方なだけで、
それが良い悪いというのは言語同士の争いと同じく不毛
結局のところ言語と一緒で、自分の使い慣れたものを使えばいいだけ
ただ>>276の提示したような明らかに用途が違うものに適用するのは馬鹿げてる

278 ：名前は開発中のものです。：2007/04/25(水) 12:40:36 ID:Yl4vGAsK

実装の共通点といえば処理をタスクというものにまとめて扱うところぐらいだろ
よーするにオブジェクト指向に近い話だと思うんだけど

279 ：名前は開発中のものです。：2007/04/25(水) 16:16:35 ID:tVRJOqln

> たとえば２ｃｈブラウザにタスクシステムを取り入れてつくったらどうなる？具体的にはHTTPで
> スレをもってくる処理をタスクにしてみてはどう？
それこそ、マルチスレッドの出番だろｗ

280 ：名前は開発中のものです。：2007/04/26(木) 00:53:16 ID:zB6RGP0j

>>279
タスクとやらでやってみたけど、劇的に早くなるな。すぐに作れるしソースもきれいにできる。
いろいろ改良してみるよ。

まあ、固定概念にひたってるやつは頭が固いってことだよ。

281 ：名前は開発中のものです。：2007/04/26(木) 01:58:51 ID:ScANyKa7

サビキ仕掛け

282 ：名前は開発中のものです。：2007/04/26(木) 15:18:59 ID:LD+Ad5uI

>>280
釣れますか？

283 ：名前は開発中のものです。：2007/04/26(木) 17:45:46 ID:EAeyMYqP

頭がやわらかすぎるのも考え物だな

284 ：名前は開発中のものです。：2007/04/26(木) 17:54:31 ID:ltksUv3A

脳死者の脳は
溶けちゃってるっていうしなあ

285 ：名前は開発中のものです。：2007/04/26(木) 19:42:12 ID:4pZ8geJG

お前らってタスクリストってソート使う？

286 ：名前は開発中のものです。：2007/04/26(木) 19:53:28 ID:hISFYhVD

OT使ってるからソートはしない。
けど最近のPCは速いからソートしても良いかもなー

287 ：名前は開発中のものです。：2007/04/26(木) 23:47:26 ID:LD+Ad5uI

OTってOrderingTable？これも業界用語だよな・・・

288 ：名前は開発中のものです。：2007/04/28(土) 13:18:26 ID:xqg9LfBt

>>280
その劇的に早いきれいなソースを出さないのは何故？
いや、まぁネタにマジレスするのもどうかとは思ったんだけど

289 ：名前は開発中のものです。：2007/04/28(土) 15:51:51 ID:ABQqrv+P

>>288
教えたくないから。
これって起業レベルのノウハウかもしれないから。社内で提案するかもしれないものをここにはさらせないでしょ。

290 ：名前は開発中のものです。：2007/04/28(土) 16:05:29 ID:B/ltLmOS

289 < 俺・・・このタスクが完成したら起業するんだ・・・

291 ：名前は開発中のものです。：2007/04/28(土) 16:50:13 ID:QLBq9OY8

タスクシステムで起業とか、お前は小学生かと。

292 ：名前は開発中のものです。：2007/04/28(土) 18:47:35 ID:/H8LY+k/

技術が儲けになると思う御年頃なんだろ
インド、中国、韓国あたりに行くのなら、技術が儲けになるという話も間違いではないけど・・・

293 ：名前は開発中のものです。：2007/04/28(土) 19:16:43 ID:00qBiuMZ

釣られんのよｗ

294 ：名前は開発中のものです。：2007/04/28(土) 23:22:08 ID:XL3V8yE3

ソートはしないな。最初からリストの最後もしくは最初に追加するようにするから。
タスク作成時に必要なリストを作る。

まあ、動的に変化するものは専用の管理クラスかなんか作るだろうな。
プライオリティとかは標準的な制御に入れない。美しくないし。

295 ：名前は開発中のものです。：2007/04/28(土) 23:51:37 ID:F7O57cEz

おまいらなんの目的でソートしてる？

コリジョン判定の回数を減らすためなら、おいらは2分木でデータを追加していくから実質ソート済み。

296 ：名前は開発中のものです。：2007/04/29(日) 01:14:38 ID:KdpdkeKK

他のタスク（郡）にアクセス（干渉（値見たり書き換えたり））するとき

297 ：名前は開発中のものです。：2007/04/29(日) 01:21:54 ID:HaLkae7w

いきなり話かわるけど線形リスト（単方向リスト、チェーン・・・・呼び方はいろいろあるけど）だと挿入や削除は早いけど探索は遅い
これが配列（ベクター、固定領域）だとまったく逆の性質になる

実はゲームに不向きなんじゃないか？タスクシステムって

298 ：名前は開発中のものです。：2007/04/29(日) 01:30:25 ID:yZTB6Hgr

自分のプログラムに向いたコンテナを使えばいいじゃん。
タスクがリストだってイメージはメモリの動的管理をケチるような
(ヒープじゃなくてワークとか言ってるような)時代の名残じゃないかと思う。

299 ：名前は開発中のものです。：2007/04/29(日) 01:30:47 ID:KdpdkeKK

そんな事言ったらコンピュータ自体がゲーム作るのに不利になるって結論に達すると思う。
vectorだと揮発性だからポインタ辺りが面倒くさいし、固定領域だとスタックオーバーフローとか何とかが起こるしね。

300 ：名前は開発中のものです。：2007/04/29(日) 01:37:24 ID:oN9CX2Ee

固定領域でスタックオーバーフローって意味不明。
馬鹿は下手に用語を使うな。

301 ：名前は開発中のものです。：2007/04/29(日) 01:39:24 ID:KdpdkeKK

固定領域じゃスタックオーバーフローは起こらんな。
ちょっとボケてた。

302 ：名前は開発中のものです。：2007/04/29(日) 02:20:56 ID:ybvN8RFV

>>297
リストの配列にすればいいさ
リストから一つのオブジェクトだけを探索したいときは遅いままだけど
そういうときはあらかじめハンドルなりポインタなり握っておけばいい

303 ：名前は開発中のものです。：2007/04/29(日) 07:36:23 ID:HDYBA+tg

Javaの場合だけどリストでもなくBlockingQueue<Task>にいれてる。優先度別にqueueも複数ある
queue内のすべてのタスクのupdateと必要な描画処理が20ms以内ならまずまずかな

304 ：名前は開発中のものです。：2007/04/29(日) 14:50:39 ID:LzYPF20u

>>289みたいなのがいる限りタスクシステム（笑）も安泰だな

305 ：名前は開発中のものです。：2007/04/29(日) 14:52:33 ID:nUOoY/JG

イテレートの速い順序付けツリーってあるの？

306 ：名前は開発中のものです。：2007/04/29(日) 15:34:08 ID:tvNJg+l3

>>305
順序付けツリーなら C++ の set や map がだいたいそんな感じだろう。
で、イテレートの遅いコンテナなんてあるの？

307 ：名前は開発中のものです。：2007/05/01(火) 13:07:57 ID:Nbo+fhA7

deque？
わかんねｗ

308 ：名前は開発中のものです。：2007/05/01(火) 22:39:08 ID:2cazExNO

アドレスがばらけるコンテナはキャッシュミスが起きやすい。
ハッシュのコンテナも構築時間を犠牲にしないものはスカスカのテーブルをそのまま辿るしかないな。

309 ：名前は開発中のものです。：2007/09/01(土) 14:23:53 ID:pqs4xK60

皆さんのやってるプラットホームはやはりPC？
コンシューマなひと、いなさそうだが・・・

310 ：名前は開発中のものです。：2007/09/01(土) 15:27:45 ID:AAlSvZp8

それを何故このスレで聞くのか

311 ：名前は開発中のものです。：2007/09/01(土) 17:38:15 ID:m1OoG9Xt

一応居るけど

312 ：名前は開発中のものです。：2007/09/01(土) 18:08:30 ID:e9oT09wF

メガドラやってるよｗ
あのスレは見てない

313 ：名前は開発中のものです。：2007/09/01(土) 19:38:53 ID:X2Bn3rtL

コンシューマやってるけど何が聞きたいの
ハードに依存してない部分だしPCとあんまり変わらんよ？

314 ：名前は開発中のものです。：2007/09/02(日) 04:39:14 ID:OA6cGu0G

そうなん？
てっきり、いまだにタスクシステム使ってるのかと

315 ：名前は開発中のものです。：2007/09/02(日) 04:49:20 ID:4YT1t12/

君の思うタスクシステムの具体的な実装が
どういうもんか言ってもらわんと答えようがないなあ
その通りかもしれないしそうじゃないかもしれないよ

316 ：名前は開発中のものです。：2007/09/02(日) 14:53:28 ID:O3956k1d

なんかGDGDだなこのスレｗ
でも、嫌いじゃないので、おいらもGDGDカキコ

タスクの良いところってのはその柔軟性だよな。
技術的にはぜんぜんたいした事をしてるわけじゃない。
とくに、このスレではタスク＝リストになってるが、別にリストなんて「高度」な
事をしなくても、ただの配列でもまったく問題なく実現できる。
（無論効率は若干落ちるが、即時にデータ起動の並列もどきルーチンが
作れるのでいろんな環境で便利）

唯一凄いと思えるのは、歴史的な経緯かな。
プログラム主体の8bit時代において、
プログラムでデータを管理するのではなく、データで、プログラムを管理(プログラムを選ぶ)
すると言う、データ主体の発送が凄かった。

317 ：名前は開発中のものです。：2007/09/02(日) 16:25:59 ID:OA6cGu0G

リストが高度とか、時代錯誤もは（ｒｙ

318 ：名前は開発中のものです。：2007/09/02(日) 20:53:53 ID:O3956k1d

>>316
おいおいｗ
わざわざ「」付で言ってるんだから
比喩に決まってるだろ

リストが「高度」な技術と言える程、
タスクの実装に技術はいらないって意味だ
ゆとりじゃあるまいし、勘弁しておくれｗ

319 ：名前は開発中のものです。：2007/09/02(日) 22:16:13 ID:UfEehfKc

茶でも飲んで落ち着けｗ

320 ：名前は開発中のものです。：2007/09/02(日) 23:01:13 ID:O3956k1d

うむ、そうするか

∧＿∧
( ´･ω･) ｽﾞｽﾞｰ
( つ旦O
と＿)＿)

321 ：名前は開発中のものです。：2007/09/02(日) 23:14:50 ID:O3956k1d

せっかくなのでリストを使わないタスクをネタ代わりに投下
てきとーに作っただけなので、コンパイルすらしてないけどなｗ
#define MAX_TASK 256;
struct tcb{
void (*proc)(tcb*); //処理関数
int work[10]; //ワーク
};
tcb* make((void (*proc)(tcb*)){
//生成
for(int i=0;i<MAX_TASK;i++){
if(TCB[i].proc == null){
TCB[i].proc = proc;
return &TCB[i];
}
}
return null;
}
void del(tcb* deltcb ){
deltcb->proc = null;
}
void exec(){
//実行
for(int i=0;i<MAX_TASK;i++){
if(TCB[i].proc != null)TCB[i].proc(&TCB[i]);
}
}
tcb TCB[MAX_TASK];

322 ：名前は開発中のものです。：2007/09/02(日) 23:19:25 ID:O3956k1d

void main()
{
//初期化
for(int i=0;i<MAX_TASK;i++)TCB[i].proc = null;
//実行
exec()
}

まあ、リストに対するアンチテーゼと、
こんなに短くてもそこそこ機能するってのが言いたかっただけなんだけどね
なんにせよ、タスク（というか、並列動作もどき）ってのは、そんなご大層なものじゃないんで、
もう少し気軽に使えてもいいと思うな。

323 ：名前は開発中のものです。：2007/09/02(日) 23:25:34 ID:4YT1t12/

std::vectorとclass Hoge { virtual void Update() = 0; };なら
そのソースの1/3くらいで終わる

324 ：名前は開発中のものです。：2007/09/02(日) 23:34:48 ID:O3956k1d

>>322
そうか、よかったな。

ただ、このソースは４KのRAMでも動くんだ。
あと、Cを始めて２日の初心者でも理解できるぞ。
ついでに言えば、C++のない環境でも動く。
別に煽ってるわけじゃなくて、316で書いたように
柔軟性が高いということが言いたいだけなんだ。

シンプルなロジックであるが故の柔軟性
かつ、高い並列性がタスクの凄いとこなんだよな

325 ：名前は開発中のものです。：2007/09/02(日) 23:44:30 ID:O3956k1d

>ただ、このソースは４KのRAMでも動くんだ。

おっと、タスク数を256にしていたか、4Kじゃ動かんなｗ
まあ、意図はわかると思うんで、適当に読み替えてくだちぃ

326 ：名前は開発中のものです。：2007/09/03(月) 00:13:38 ID:OKOrcl0B

うーん、まあ好きなように作ってればいいと思うよ

327 ：名前は開発中のものです。：2007/09/03(月) 00:50:28 ID:eAiA8cQA

>>324
数メガの RAM と C++ コンパイラのある環境で得意げに >>321 みたいな
コードを書かないでいてくれるなら文句は無い。

328 ：名前は開発中のものです。：2007/09/03(月) 01:11:08 ID:tpNXAe5A

>326
いや、無論自分自身は好きに作ってる。
ただ、タスク＝LIST管理とかなってきてて、
デザパタとか絡ませる風潮がなんとなくいやなんだ。
もちろん、そういった事を否定するわけじゃなくて、
もっとシンプルなものって事が言いたいだけだよ。

> 数メガの RAM と C++ コンパイラのある環境で得意げに >>321 みたいな
> コードを書かないでいてくれるなら文句は無い。

いや、得意気もなにも普通に組むよ。
無論システムとしては組まないけどね。

というか、逆に聞きたいんだけど、並列ではないシステムで（要するにシングル）で組んでて、
一時的に、並列的な挙動が欲しい時って、どうやって組んでるの？
まさか、システムに組み込ませるわけじゃないよね？

自分はそういったことが頻繁にあるんで、
そんな中での小技テクとして、上記のようなコードをチョコチョコつかってる。
逆に言うと、タスクなんてその程度のもの。
無論、システム化してべったりって好きだけど、その環境だけで組めるわけじゃないからね。

329 ：名前は開発中のものです。：2007/09/03(月) 01:35:46 ID:eAiA8cQA

>>328 >>323

330 ：名前は開発中のものです。：2007/09/03(月) 01:47:58 ID:OKOrcl0B

＞というか、逆に聞きたいんだけど、並列ではないシステムで（要するにシングル）で組んでて、
＞一時的に、並列的な挙動が欲しい時って、どうやって組んでるの？
まさしく>>323

331 ：名前は開発中のものです。：2007/09/03(月) 02:06:52 ID:tpNXAe5A

>>329
なるほど、STLに行くのか。
て事は基本的な方向性(末端でタスク生成)は変わらないんだよね？

ちなみに自分がかかわったプロジェクトでは、STLはメモリの消費量と、
ガベコレを意識できないプログラマがいて、使えなかった。
厳密には使えたんだが、STLの類は、みんな使うとなったら、とことん使うので、
あっという間に使用量が膨れ上がって、パンクしたｗ。
（搭載メモリは16Mな）
別の件でSTLはおろか、Cの標準ライブラリすらない環境もあったので、
頼らない組み方が基準にはなった。
確かに、つかえりゃ楽なんだけど、
Window以外は、鬼門なことがままあるからなあ＞STL

あと、新人に理解させる期間が必要という現実的な問題もあるしなｗ

ま、タスクの話からは若干それたが、
329の環境が、STLが使えるような環境を基準に出来れば、それはいいことだと思うよ。
こっちは中々難しいんで、小技テクでごまかして進むしかないけどｗ

332 ：名前は開発中のものです。：2007/09/03(月) 02:37:16 ID:eAiA8cQA

>>331
関数ポインタと固定ワーク領域（＋無理やりキャスト）が仮想関数に
置き換わっただけで、基本的な考え方は同じ。

あと、新人に理解させるって点で言っても、関数ポインタや無理やりな
キャストよりも仮想関数のほうが自然で理解しやすいはず。特にアセンブラを
やらない今の時代では。

生配列と vector の違いについては今の話にはほとんど関係ないけど、
「それ何年前の話？」ってぐらいの時代遅れ感がする。
vector 出しただけで STL 全体の話になってたり、「ガベコレ」とか言ってる
あたりで理解も怪しいし。

333 ：名前は開発中のものです。：2007/09/03(月) 02:54:20 ID:OKOrcl0B

＞ちなみに自分がかかわったプロジェクトでは、STLはメモリの消費量と、
＞（ｒｙ
もうこの辺って用途によるんじゃないかなぁ
360とかPS3みたいにメモリが贅沢な環境でも切り詰めりしなきゃならない場面もあるから
>>321みたいな実装になることもあるよ

勘違いして欲しくないのは、本来やりたいことってのが
大量の「関数と実行コンテキストのペア」を如何に管理するかって話なんだから
>>321の例にしても>>323の例にしても、所詮はその実現方法の1つに過ぎないことかな

逆に質問してみるけど
9割が128バイトのサイズのタスクと残りが1024バイトのタスクが混在するような状況下で
あなたはどうやって管理するんでしょうか

334 ：名前は開発中のものです。：2007/09/03(月) 02:58:58 ID:sckJXuMq

まあvectorだと、「削除や挿入などの操作」と「タスクへのポインタの保持」が背反するんだけどな。
321みたいな配列系は、リスト用のポインタ変数すら削りたいほどメモリが逼迫してて、
順番の制御が要らないのならいいんじゃね？

335 ：名前は開発中のものです。：2007/09/03(月) 03:27:47 ID:Ic41WPtX

>>332

> 関数ポインタと固定ワーク領域（＋無理やりキャスト）が仮想関数に
> 置き換わっただけで、基本的な考え方は同じ。

なるほど、ここは了解っす。

> vector 出しただけで STL 全体の話になってたり、「ガベコレ」とか言ってる

いやいやｗ、実際使用する段になったら、vectorだけ使用してOKって話にはならんでしょ。
これがだめ、あれがOKって細かく指定するならよいんだけど、そこまでして
STL使うプロジェクトには参加したことないなぁ。それに制限するならSTLの意義が薄れてくるし。
（確かに、vector使えるだけでもかなり変わるとは思うけどね）

ガベコレについては、話が飛びすぎの感があったんで細かく触れなかったが、
メモリの断片化による、ガベコレの処理落ち、あと、メモリ確保エラーのコトな。
現在のSTLでこれらが一切起こらないことが保証されてるならいいけど、
そうでないなら、対処を知らない人のために、何らかの対策や方針が必要になる。
件のプロジェクトではそれがなくてヤバいことになった。

> あと、新人に理解させるって点で言っても、関数ポインタや無理やりな
> キャストよりも仮想関数のほうが自然で理解しやすいはず。

あー、ここは同意。
無理やりキャストよりは、言語使用に沿った概念のほうがいいからね。

336 ：名前は開発中のものです。：2007/09/03(月) 03:46:43 ID:Ic41WPtX

>>333
基本的には1024byteのタスクを先に生成して(起動するまでSLEEP)から、128byteタスクの生成かな。
途中でどうしても、フルに使わなきゃならない場合は、グループでの生成と削除を行う。
この例だと、8タスクを1グループとして、生成と削除を行う。
大体、こんなかんじっす。

337 ：名前は開発中のものです。：2007/09/03(月) 03:48:53 ID:eAiA8cQA

>>335
ほんと、胡散臭いな。 vector は許可が無いと使えないのが当たり前だと
思ってそうだし。

標準ライブラリに使用制限を付けるほうが異常でしょ？制限を付けるには
理由が要る。コンテナの動的メモリ確保に問題があって禁止するなら、
アルゴリズム系ライブラリまで "STL" とまとめて禁止することは無い。

C++ の言語仕様にも標準ライブラリにもガベコレは無い。 Boehm GC でも
使ってるの？

メモリの断片化がどうのこうの云うなら malloc も new も同じことなんだけど、
それらも使わないことにしてるの？
あー。 new が禁止になってるなら仮想関数を使わないのかな？

338 ：名前は開発中のものです。：2007/09/03(月) 04:13:34 ID:Ic41WPtX

>>337
いや、なにをうさんくさがってるのか知らないけど、
自分の考えや方針と違う人がいるのがそんなに気に入らないのかな？

> ほんと、胡散臭いな。 vector は許可が無いと使えないのが当たり前だと
> 思ってそうだし。

そんなことは思ってもいないが、STL使用時はメインの人に確認はするよ。
まあ別に、どうでもいいけどね。

> メモリの断片化がどうのこうの云うなら malloc も new も同じことなんだけど、

別にmallocは禁止にしてないけど、ほとんど使わないね。
仮想関数は、c++が使える環境かどうかとメモリ量によるね

339 ：名前は開発中のものです。：2007/09/03(月) 05:14:29 ID:eAiA8cQA

>>338
気に入らないのは、不確かな理由で複雑なコードを書いてしまうこと。

vector を使えない理由をいろいろと説明しようとしてくれていたけど、その理由の
真偽が胡散臭いってことね。

ただ、これ以上追究する気もなくなった。

340 ：名前は開発中のものです。：2007/09/03(月) 09:21:14 ID:y2Xn2ykc

>>338
提示したソースが洗練されてるとは言わんが、
ほぼすべてのC環境で動くコードが、
最近の環境に適したコードではないからといって、
胡散臭がられるとは思わなかったｗ
短くて、美しいソースが正義とか思ってそうだね。

341 ：名前は開発中のものです。：2007/09/03(月) 09:50:46 ID:OKOrcl0B

>>336
君のやり方って1フレーム中に
毎フレーム256個のタスクがアクティブかどうかチェックするための
オーバーヘッドが発生するんだけど(これ自体がそもそも重大な問題なのに)
そのメモリの割り当て方はそれを上長させますよ

342 ：名前は開発中のものです。：2007/09/03(月) 10:28:10 ID:2Imr3kJv

>>340
id:O3956k1d ＝ id:y2Xn2ykc なのはいいとして（レス番が一個ずつずれてるぞ）
胡散臭いと言われてるのはSTLとガベコレを混同してるid:tpNXAe5A ＝ id:Ic41WPtXd の存在自体
であって、君のことじゃないだろう？

343 ：名前は開発中のものです。：2007/09/03(月) 11:23:55 ID:VocmouaK

つか、なんで>>331でガベコレの話がいきなり出てきたわけ？

344 ：名前は開発中のものです。：2007/09/03(月) 11:40:25 ID:ckJtc0Qf

>>331
>（搭載メモリは16Mな）
ドリーｍあｑｓｗでｆｒｇｔｙふじｋ

胡散臭がってる人とかPCの人には分らんかもしれんがコンシューマだと
プロジェクトによってはSTLはおろかC++も使えないことがあるよ。
C++許可でもnew禁止、とかさ。
古い人（ちょっと偉い人）がプロジェクトに混じるとC主体になったりするし。

>>340
正義がまかり通る職種ではないし、主義主張を煽るような発言は荒れるぜー。
プログラマは性格悪いからなｗ

345 ：名前は開発中のものです。：2007/09/03(月) 11:44:32 ID:ckJtc0Qf

>>343
C++かSTLにガベコレなんて実装されてたっけ？
記憶にないんだけど。

346 ：名前は開発中のものです。：2007/09/03(月) 12:25:32 ID:rM0ce6hj

>>344
ゲームじゃないけど
RAM128バイトでcコンパイラも無いターゲットで仕事したことあるぞ

347 ：名前は開発中のものです。：2007/09/03(月) 13:20:45 ID:BR9raoz2

　 /'　　　　　　　　　　!　　　━━┓┃┃
-‐'―ニ二二二二ニ＞ヽ､　　　　┃　　　━━━━━━━━
ァ　　 /,,ｨ=-;;,,, , ,,＿　ト-､）　　 ┃　　　　　　　　　　　　　　　┃┃┃
'　　 Y　　ｰ==j 〈,,二,ﾞ !　　)　　　　｡　　　　　　　　　　　　　　　　　　┛
ゝ.　 {､　　-　,.　ヾ "^ }　　}　ﾟ　｡
　　　）　　,. ‘-,,'　　　≦　三　
ゞ,　∧ヾ　ゝ'ﾟ　　　　　　　≦　三　ﾟ｡　ﾟ
'=-/　ヽﾟ｡≧　　　　　　　　　三　＝=-
/　|ヽ　＼-ｧ,　　　　　　　　　　≧=-　。
　　!　＼　　ｲﾚ,､　　　　　　　　　＞三　　｡ﾟ　･　ﾟ
　　|　　＞≦｀Vヾ　　　　　　　　ヾ　≧
　　〉　,く　｡ﾟ　/｡･ｲﾊ､､　　　　　｀ミ　｡ﾟ　｡･

348 ：名前は開発中のものです。：2007/09/03(月) 13:31:16 ID:ckJtc0Qf

128バイト？キーチェーンとかでももう少しありそうなんだが。

つか、8bit以下のCPUならコンパイラよりもアセンブラだろ。
小さいならバイナリを打ち込んだりとか。

349 ：名前は開発中のものです。：2007/09/03(月) 22:41:28 ID:l9Qlmw/p

ワークがちょびっとしかなくても
ROMが十分あればどうとでもなる

350 ：名前は開発中のものです。：2007/09/04(火) 02:25:05 ID:+Mg349f+

もちろんアセンブラ
他に選択肢は無いし
ちなみに、CypressのCY7C63101か何かだった

351 ：名前は開発中のものです。：2007/09/07(金) 22:50:02 ID:CXdTTUEg

時代錯誤のロートルはもう死んでくれ。
お前の糞テクニックなんて今はもう害悪にしかならんよ。

352 ：名前は開発中のものです。：2007/09/10(月) 00:23:29 ID:QZRbzkCO

＼|／
/⌒ヽ　　　／￣￣￣￣￣￣
| ゜Θ゜）＜　そうでもないよ。
|　∵　つ　＼＿＿＿＿＿＿
|　∵　.|
＼＿／

353 ：名前は開発中のものです。：2007/09/12(水) 13:27:57 ID:ZYdwKK9S

>>346
それってPICだろ・・・・

354 ：名前は開発中のものです。：2007/09/12(水) 15:51:28 ID:+wMsl3iC

>>353
Cypressの8bitマイコンです

355 ：名前は開発中のものです。：2007/11/08(木) 23:19:03 ID:uB/1dczJ

惜しいな。面白いスレになりしょうな感じなんだが。

誰か、カプコンのMTフレームワークの実装について
知ってる人居る？

356 ：名前は開発中のものです。：2007/11/09(金) 00:00:08 ID:99bw+ohL

「惜しいな。」などと一段高いところから
ご感想を述べてみるクレクレ厨であった

357 ：名前は開発中のものです。：2007/11/09(金) 02:09:23 ID:0f4u8oj2

>>355
概要だけならPC Watchの記事でも見とけ

358 ：名前は開発中のものです。：2007/11/09(金) 06:38:45 ID:mfpq6ZYz

>>355
MTフレームワークってこれか？

西川善司の3Dゲームファンのための「ロストプラネット」グラフィックス講座
http://www.watch.impress.co.jp/game/docs/20070131/3dlp.htm

タスクシステムつーか、統合的なゲームエンジンな気がするが

359 ：名前は開発中のものです。：2007/11/09(金) 08:43:04 ID:0f4u8oj2

まあタスクのMT実行が主要部分でもあるわけだし。
なにせ"MT"フレームワークだからな…

360 ：名前は開発中のものです。：2007/11/11(日) 13:02:25 ID:lu+hzgEU

ところで、擬似タスクの実装方法についてなんだけど、あるキャラクターをあらわすタスクが、
ほかのキャラクターのタスクを参照しだす(当たり判定とか、AIとか)と
タスクに分割したもの同士が相互に参照しあって、
モジュールを分割してインターフェイスを最低限に抑えることが出来なくなって
とたんに実装がめちゃくちゃになりだすような気がするんだけど、これって何かいい方法があるの？

キャラクター同士の当たり判定を取り持つコンテナのようなタスクを用意して
そいつがそれぞれのキャラクターを表すタスクに対して当たり判定を行うということなら分かるけど、
それってタスクシステムの概念(連結リストであるとか、ワークを持つとか)と相性が悪い気がするんですが…

361 ：名前は開発中のものです。：2007/11/11(日) 13:07:36 ID:lu+hzgEU

>タスクに分割したもの同士が相互に参照しあって、
>モジュールを分割してインターフェイスを最低限に抑えることが出来なくなって
の補足ですが、キャラクターのタスクの中で当たり判定などをやろうとすると…

class Character{
public:
　　void Destroy(void){
　　　　valid = false;
　　　　いろんな処理 …
　　}
　　void HitTest(Character& c){
　　　　if ( 当たり判定… ){
　　　　　　c.valid = false; // これが出来てしまう。望むべきは t.Destroy();
　　　　}
　　}
private:
　　bool valid;
};

362 ：名前は開発中のものです。：2007/11/11(日) 13:19:18 ID:tG71RUEc

>>361
ああ、はいはい。
それは色々考え方がある思うんだけど、Characterの内部処理で当たり
判定をするという思想自体が間違っているというのが１つの答え。
例えば当たり判定を別のクラスでやるとかすればそのへんの問題は消える。

363 ：名前は開発中のものです。：2007/11/11(日) 13:20:52 ID:LIlfAb5k

同じことを書こうとしてたら既に書かれてた件

364 ：名前は開発中のものです。：2007/11/11(日) 13:26:54 ID:tG71RUEc

>>361
けどね、そういうのはむしろ気にしなくていいと思うよ。
同じクラス内での辻褄ぐらいは合わせような。
言語仕様に頼りすぎ。

365 ：名前は開発中のものです。：2007/11/11(日) 13:54:46 ID:lu+hzgEU

>>362
でも、それをすると、「ワークを持つ優先度つきの連結リスト」という
タスクシステム自体の設計と相反することになると思うんです。

当たり判定を別のクラスでやる場合、当たり判定タスクのクラスは対象のキャラクターを表す
タスクのクラスへのポインタを持つわけですが、タスクシステム全体を取り仕切るタスクが
すべてのタスクへの連結リストを持っているわけです。
そうすると、当たり判定タスクが持っているキャラクターへのポインタと
タスクシステムの持つ連結リストとの同期をとる必要が出てくると思うんです。
この同期取りは、キャラクターのタスクが自分で自分を解放しだしたりすると困難になりませんか？

366 ：名前は開発中のものです。：2007/11/11(日) 14:02:16 ID:IaJaT3b9

好きなように組みゃいいと思うが
判定が終わったら当たり判定用のリストを捨てて
毎回登録しなおすというのも一つの解だ。

367 ：名前は開発中のものです。：2007/11/11(日) 14:02:25 ID:2/00o71/

横からスマンが俺はスマートポインタを使って
解放するのを遅らせて対処してるよ。

368 ：名前は開発中のものです。：2007/11/11(日) 14:08:13 ID:LIlfAb5k

>>365
リストのイテレーション中にリスト自身に対する変更を加えてるのが問題
AddやRemoveの履歴をキューに溜めて
タスクリストを全更新した後に適応すればいい

後は>>366みたいに毎フレーム物理世界を構築したり
>>367みたいにスマートポインタ使ったり
タスク更新直前にダブルバッファにしてしまったりとか
色々あるけど個人的にはキューが好きかな

369 ：名前は開発中のものです。：2007/11/11(日) 14:08:29 ID:lu+hzgEU

>>366 >>367
ありがとう、やっぱりそういう方法を使うしかないですよね？
私も結局はそういう方法で解決しているんですが、
そうすると今度は「優先度つき」という意味がなくなりませんか？
本来は並列化できることをわざわざ出来なくしているような気がするんです。
もうすでに時代はマルチコアなので、もったいないなぁ。と思うんですが。

370 ：名前は開発中のものです。：2007/11/11(日) 14:10:35 ID:LIlfAb5k

>>369
マルチスレッドのこと考えるなら
そもそも「タスク」とは何ぞやってことを考えなきゃならん
エンティティとタスクの違いが分からないと良い設計は出てこないと思う

371 ：名前は開発中のものです。：2007/11/11(日) 14:17:05 ID:lu+hzgEU

>>370
う～ん、なんとなく分かるんですが、
擬似タスクはタスク自体にワーク領域を持たせてしまうために、
タスクとエンティティを別物として扱うと
いろいろと尻拭いをしなければならないと思うんです。
本来はエンティティに対してそれぞれのワークを持たせないといけないと思うんです。
そこらへんの認識はどうでしょう？

372 ：名前は開発中のものです。：2007/11/11(日) 14:29:32 ID:LIlfAb5k

>>371
そこまで分かってればあと一息
その上で、

①エンティティはdt時間だけ更新する→いわゆるUpdate関数を持つ
②エンティティに更新命令を出すのは誰なのか？
③どういう順序で実行するのか？

ここまで考えればタスクとはなんじゃらほいというのが分かると思う

373 ：名前は開発中のものです。：2007/11/11(日) 14:38:39 ID:lu+hzgEU

>>372
はい、そういう実装が一番シンプルに行くと思うのですが、
そういう風に切り分けるともはや擬似タスクではないような気がするのですが…

タスクとワークがペアになっているのが擬似タスクだという理解でいいですよね？
エンティティ単位で考えると複数のエンティティに参照されるワークがあるわけで。

374 ：名前は開発中のものです。：2007/11/11(日) 14:40:48 ID:Ur8IlWLa

>>373
さっきから「タスクシステム」（「擬似タスク」）と相性が悪かったり設計に反したり
尻拭いをしなければならなくなったりする要素を自分でいろいろ挙げてるのに、なんで
「タスクシステム」を捨てて好きにすればいいってことにならないの？

375 ：名前は開発中のものです。：2007/11/11(日) 14:54:36 ID:lu+hzgEU

>>374
ごめんなさい、分かりにくかったですね。私の意見はそういうことです。

ただ、ここはタスクシステム総合スレなので、
私の意見には何か穴があってもしかしたら上手い方法があるのではないかと思って
質問してみたわけです。結局「タスクシステムは駄目だ」でいいんですかねぇ？
とすると、このスレの存在意義が…

376 ：名前は開発中のものです。：2007/11/11(日) 15:02:52 ID:CfVXMW8x

タスクシステムってアセンブラだけでゲーム作ってた頃の
遺産だからあんまりこだわらないほうがいいよ。

377 ：名前は開発中のものです。：2007/11/11(日) 15:04:58 ID:CfVXMW8x

>>375
駄目じゃないけどあんまり細かいこと突っ込むとボロが出るんだよ。
万能じゃねーからさ。

378 ：名前は開発中のものです。：2007/11/11(日) 15:08:54 ID:lu+hzgEU

すんません、皆様、ご丁寧にどうもありがとうございました。
すっきりしました。

379 ：名前は開発中のものです。：2007/11/11(日) 15:18:17 ID:LIlfAb5k

ていうかみんなこのスレ大好きだなｗ
2ヶ月くらい放置されてたのにｗ

380 ：名前は開発中のものです。：2007/11/11(日) 15:32:08 ID:DWuF3ISC

相談にしては明らかに情報後出し君だしどうしたものかと思ったが…
なんの事は無い。タスクスキーがｳﾖｳﾖいやがるｗ

381 ：名前は開発中のものです。：2007/11/11(日) 15:34:13 ID:Ur8IlWLa

>>375
このスレの存在意義は、あっちこっちのスレで発生する無限ループを集約させることにある。
今回の流れも、変にタスクシステムをひきずってぐちゃぐちゃになりつつある人への有用な
サンプルのひとつになったと思うよ。

382 ：名前は開発中のものです。：2007/11/11(日) 18:58:20 ID:T6+V3ZZx

タスクスキーもうざいけど、脊髄反射で喚き出す奴もうざいなぁ。
過去によほど嫌な事があったのかな。

俺的には>>376が解だけど、いまだ低スペックのプラットフォームでの開発があることを考えると
自身が作っているゲーム以外の想定されない実装は害悪、おまえの実装は間違っている、
などという視野の狭い見方しかできなくなる危険がある気がする。

まぁどうでもいいや。ゲームが作れれば。

383 ：名前は開発中のものです。：2007/11/11(日) 19:20:51 ID:84xwHPzx

もう終わったみたいだけど、こっちのスレには張ってないみたいだから張り。
ttp://www.issei.org/blog/archives/000225.html

結局、373の
>タスクとワークがペアになっているのが擬似タスク
という勝手な理解で自縛してただけか。

384 ：名前は開発中のものです。：2007/11/11(日) 19:37:03 ID:Qree7kq2

タスクの数だけタスクがあるんだよ。
一つにこだわる必要ないだろ。

385 ：名前は開発中のものです。：2007/11/11(日) 19:56:03 ID:T6+V3ZZx

相手を貶め、自分が優位に立たないと気が済まないのな。
一つの見方に縛られてるのはあんたのほうなんじゃないの？
もっと本質を見ようよ。

つーか、自分の思う正論を押し付けるようなその独善的な態度がキモイ。

386 ：名前は開発中のものです。：2007/11/11(日) 22:40:11 ID:F1CWGjS4

吉岡たすくシステム。

387 ：名前は開発中のものです。：2007/11/11(日) 23:28:50 ID:A2izw4PO

>>380
情報小出しって言うか、必要最小限に抑えただけのつもりですが。
最初から私の思考の流れを全部書いたら恐ろしい長文レスになるよ。
今回も全部の考えを書いたわけじゃないし。

>>383
>結局、373の
>>タスクとワークがペアになっているのが擬似タスク
>という勝手な理解で自縛してただけか。
私の理解が違います？ならどう違うか教えていただけます？

388 ：名前は開発中のものです。：2007/11/11(日) 23:47:11 ID:DWuF3ISC

触ったら負けｗ

389 ：名前は開発中のものです。：2007/11/11(日) 23:55:50 ID:LIlfAb5k

擬似タスクとはタスクとワークのペアとかそういう定義はどうでもいいのよ
その定義が合ってるかどうかの問題じゃない

要するに、手段が目的になってないか？ってこと
ゲーム作るために必要ならその手段を使う、不要なら使わない、
ただそれだけの話だと思うけれども

390 ：名前は開発中のものです。：2007/11/12(月) 00:01:37 ID:Z5/maecn

タスクシステムは汎用技術用語として分かるが
「擬似タスク」って何なの。これ本当に聞いたことないよ？
何が擬似なの

出典不明の怪しげな脳内生成単語を、何の解説も無しに
使うの止めてくれ

391 ：名前は開発中のものです。：2007/11/12(月) 00:12:30 ID:2KUQxW4r

誘導されてきました

C++でのゲームの組み方について質問よいでしょうか

現在シューティングゲームを作ってるのですが、以下のようなタスクシステムで行なっています

class ITask
{
virtual void task()=0;
virtual void draw()=0;
};

class CEnemyZakoA : public ITask
class CEnemyZakoB : public ITask
class CEnemyFactory : public ITask
class CBg : public ITask
class CItem : public ITask

こんな感じで、全てのオブジェクトはITaskを継承し、一つのITaskリストに登録しています。
そこで疑問なのですが、Task同士が連携するにはどうすればよいでしょうか？

例えば「CBgの持つ『どのくらいスクロールしたか』の情報によって、CEnemyFactoryは生み出すZakoの種類を変える」
といった場合です。
一応素人考えながらこういう手を考えましたが、一般的にはどうするべきなのでしょうか？

１・FacotryのようなほかのTaskの情報に依存するものは、リストに登録せず特別扱いする（CEnemyFactryとして保持しておく）べき
２・他のTaskに依存するTaskは、その生成時にそのTaskへのポインタをもらっておくべき
３・他のTaskに影響を与える情報をまとめた構造体を持ち、それへのポインタをtask()の引数で渡してあげるべき

1はいまいちだと思います。特別が増えるたびに管理が増えますし、何のためのITaskリストなのかわかりません
2はなかなかいい手ですが、CBgが削除された時などに困ります（share_ptrを使うべき？）
3は構造体に新しい情報が加わるたびに、全てのCXXX.cppが再コンパイルになるのが不満です

392 ：名前は開発中のものです。：2007/11/12(月) 00:17:49 ID:Z5/maecn

あと、「エンティティとタスクの違い」とかシレっと書いてる奴がいたけど
これに何の疑問も抱かずにレス返してる奴がいて会話が成立してるのは
非常に驚きだ。この会話は普通、赤の他人じゃ絶対に成立しない

環境（ツール）ごとに単語の意味合いが微妙に違う。例えばHL2とかの
レベルエディタに出てくるエンティティという単語のことだよ、とか
そういう何らかの補足情報が要るだろ普通

393 ：名前は開発中のものです。：2007/11/12(月) 00:24:38 ID:ddRxOA+T

エンティティって普通そういうもの指すんじゃないのか
それ以外のエンティティってどんな奴？

394 ：名前は開発中のものです。：2007/11/12(月) 00:34:39 ID:ddRxOA+T

>>391
2でいいんじゃないの？
削除はスマートポインタなり使って解決すりゃいい。
ていうかそもそもCBgってゲーム中に生成されたり消えたりするもんなのか？

1はCEnemy1とCEnemy2の連携とかあったときに破綻するだろ。
3は実質グローバル変数経由の更新であって非常によくない。

395 ：名前は開発中のものです。：2007/11/12(月) 00:35:06 ID:XbsUO0Z/

エンティティは初級シスアドで勉強するような意味でいいんじゃね？

396 ：名前は開発中のものです。：2007/11/12(月) 00:36:01 ID:7UQEArlO

変数、クラス、関数、名前空間、モジュール、ライブラリ
プログラミング中に出てくるこれらの要素はどれもentityらしい

397 ：名前は開発中のものです。：2007/11/12(月) 00:38:17 ID:yStfrx7f

>>389
ごめんなさい、意図していることが全然理解できない。

私の思考の出発点は
「タスクとワークがペアになっている擬似タスクは
　近代的なゲームシステムにおいては好ましい実装とはいえないのではないか？」
そこで、私の考え方に穴が無いかをこのスレッドで聞いてみた。そしたら
「やっぱり擬似タスクでは上手く表せないようなパターンが存在する」
という結論になった。それに対してあなたの発言
「タスクとワークがペアになっているのが擬似タスクという勝手な理解で自縛してた」
そこで「勝手な理解とはどういうことか？」と聞いたら「手段が目的になってないか？」
最初の私の意見に戻っている気がするんですけど、ちがいます？

398 ：名前は開発中のものです。：2007/11/12(月) 00:38:57 ID:ddRxOA+T

そういうもんなのか。
ゲームでエンティティたら>>392の言うものだと思ってた。

ていうかシスアドとか勉強してねーよ…

399 ：名前は開発中のものです。：2007/11/12(月) 00:40:59 ID:sMI0O0XQ

>>397 せっかく ID 出てるんだから良くみようぜ。 383 と 389 は別人だろ。

400 ：名前は開発中のものです。：2007/11/12(月) 00:45:14 ID:yStfrx7f

>>392
まあ、そうなんだけど、それを言い出すと
「オブジェクト」とか「インターフェイス」とかも毎回確認を取らないといけないので、
その場の雰囲気でなんとなく会話しなければだめじゃない？

401 ：名前は開発中のものです。：2007/11/12(月) 00:51:25 ID:ddRxOA+T

そこで誤解が生じてグダグダになるのが
タスク議論の大半な気がするがな…

402 ：名前は開発中のものです。：2007/11/12(月) 01:15:17 ID:kB5Tm7/h

>>397
なんかスレみると１人で奮闘してるみたいに見えるので俺もレス
俺もお前と同じ考え
擬似タスクは害にしかならない

ゲームで一番複雑な部分はオブジェクト同士の関連の管理のはずなのに
擬似タスクはそれを全然管理できない上にむしろ悪化させる
せっかくついてる言語の機能も無視していらんアクシデントを増やす

擬似タスク信者に何を聞いても無駄
なぜなら彼らはよくよく話をきいてみるとこれ以外のプログラムの組み方を知らない
だから比較して検討することもできずにひたすら意味不明な言葉を吐き続ける

言語の微妙な機能までもってきて（大抵テンプレートｗ）これで解決できますよ
とか意味不明な戯言を吐く
なにかと思ってみてみりゃ、グローバル変数の代替機能みたいなのを作って喜んでるだけ
さらに型をごまかして「汎用性が・・・」とか言語に型ができた理由をまったく理解してないとか
ひどいありさま

そいつらと話するだけ無駄だと思うけどねｗ

403 ：名前は開発中のものです。：2007/11/12(月) 01:17:34 ID:fV4Kmw0i

そろそろまとめようよテンプレ、FAQ。長所と短所、用語、設計をふまえてさ。
各々ゲームの設計が違うのは当然だから、どんどん補足していく感じで。
これで意思の疎通も円滑になり、喧嘩罵倒もなくなる、精神衛生も良くなり、「テンプレ嫁」で済むようになるよ（・∀・）ｷﾓﾁｲｲ!

まずはよく出てくる単語でも羅列してみようか。
・・・。

404 ：名前は開発中のものです。：2007/11/12(月) 01:23:02 ID:XbsUO0Z/

んなこといったって、
言語の機能を無視とか型ができた理由とか言ってもしょうがないと思う

速さ最優先のゲームに向いた言語ってのが
少なくともC++より後ではまともに出てきていない状況で、
ハードウェアの進化におんぶにだっこなコードを書きたくない人はこの先延々残るでしょ

しかしなんだって、C++より後では富豪的な言語ばっかりなんだろうね

405 ：名前は開発中のものです。：2007/11/12(月) 01:29:08 ID:fV4Kmw0i

タスクシステムでぐぐると結構ヒットするねぇ。
昔は全然だったけど、これも信者が増えたからだろうなぁ。

頭ごなしに悪いと言うのではなく、論理的な説明をもって良い部分悪い部分を理解することができれば
盲目的な信者もきっとわかってくれるようになるはずさ。

ではあとは頼んだ。

406 ：名前は開発中のものです。：2007/11/12(月) 01:33:47 ID:kB5Tm7/h

普通に
・グローバル変数は使わない
・別のインスタンスのポインタを保持しない
とか守って組む方法を考えればそれでいいのに
基本のところ無視してテンプレートに手を出すとか意味不明なことするし
たぶん、教科書に書いてある機能を使いこなすのがいいと思ってんだろうけど
学校の勉強とプログラムは違うんでねって話

C言語の入門書に書いてある項目極めようと頑張ると延長で
こう成長すんだろうなｗ悪いけど使えねｗ

407 ：名前は開発中のものです。：2007/11/12(月) 01:40:43 ID:sMI0O0XQ

>>404
C++ の言語機能や型システムに沿ったからって「ハードウェアの進化におんぶにだっこなコード」には
ならないでしょ。それが C++ のいいところだと思うよ。言語の機能を変に避けたり、型システムを
壊すようなコードは良くない。そして、「タスクシステム」とよばれるものはそれを助長することが多い。

408 ：名前は開発中のものです。：2007/11/12(月) 01:44:00 ID:3TstTFxn

>>406
・基本のところ無視してテンプレートに手を出す
・教科書に書いてある機能を使いこなすのがいいと思ってる
・C言語の入門書に書いてある項目極めようと頑張る

これ全部あんたの他人に対する勝手な思い込みでしょ。
このスレで「テンプレート」とか言葉を持ち出してんのあんただけ。

409 ：名前は開発中のものです。：2007/11/12(月) 02:06:12 ID:fV4Kmw0i

ここで言い合っている間にも、外では狂信的な布教活動によって
洗脳されてゆく者達が・・・

道筋のわからぬ暗闇、かすかに見えた灯りを目指して歩んだ者達をどうして笑うことができようか
今こそ救いを！そう俺達はレジスタンス！

410 ：名前は開発中のものです。：2007/11/12(月) 02:08:08 ID:kB5Tm7/h

>>408
あ、そういう会話する？
もう認識はしてんだろ？
わざとはぐらかしてうぜーなー
ばっかみて
一人でやってろ

411 ：名前は開発中のものです。：2007/11/12(月) 02:10:56 ID:fV4Kmw0i

俺だけシカト！？

412 ：名前は開発中のものです。：2007/11/12(月) 02:19:12 ID:7UQEArlO

boost使ってうまく解決できないかなぁ…

413 ：名前は開発中のものです。：2007/11/12(月) 02:33:43 ID:3TstTFxn

>>410
あんたのレスをきちんと読んだ上での意見だし、何もはぐらかしていないんだが。
はぐらかしてんのはあんただろ？

414 ：名前は開発中のものです。：2007/11/12(月) 03:17:55 ID:fV4Kmw0i

　　　 _,,..,,,,_
　　./ ,' 3　 `ヽｰっ
　　l　　 ⊃　⌒_つ
　　 `'ｰ---‐'''''"

415 ：名前は開発中のものです。：2007/11/12(月) 03:40:45 ID:AxMl0fyO

私怨を愚痴ってるだけにしか見えんなぁ。

416 ：383：2007/11/12(月) 04:12:31 ID:zH4GMJ+e

>387
所謂タスクシステム（擬似タスク？）は、定義が曖昧だから、
・ワークを持つ優先度つきの連結リスト
・タスクとワークがペアになっている
などの実装規定があるという訳ではない。

何が言いたいのかというと「タスクシステム」という言葉を使う時は曖昧さを自覚してきちんと修飾して、と。
×「タスクシステムは駄目だ」
△「俺の思ってるタスクシステムは駄目だ」
○「アセンブラやCの時代から用いられていたワークを持つ優先度つきの連結リストで実装されたタスクシステムはほかのキャラクターのタスクを参照しだすと設計的には駄目だ」

説明する時は、必要最小限よりも可能な限り多い方がいいと思う。
特に今回は最初にこれがあればもうちょっとスマートに行けたんじゃないだろうか。
>「タスクとワークがペアになっている擬似タスクは
>　近代的なゲームシステムにおいては好ましい実装とはいえないのではないか？」
概ねyesだと俺も思う。「擬似タスク」が、ではなく、「タスクとワークがペアになっている擬似タスク」が、ね。

>411
自分で出来ないことを他人にまるなげされても。

417 ：名前は開発中のものです。：2007/11/12(月) 06:03:36 ID:J0UbLqll

このスレって「処理関数へのポインタ付きワーク構造体の連結リスト」に「タスクシステム」って名前を付けて宣伝しまくる奴がいたから隔離用に作られたんじゃ無かったっけ？
だからこのスレでは「タスクシステム」＝「処理関数へのポインタ付きワーク構造体の連結リスト」でいいと思うのだが。

418 ：名前は開発中のものです。：2007/11/12(月) 06:42:00 ID:zggKJn88

>>390
2000年頃にム板のコンシューマスレで
RTOSのタスクという概念に対して圧倒的に機能が貧弱すぎるものを
タスクなどと呼ぶな、と騒いだ奴がいた。
その流れから擬似タスクという言葉が使われるようになった。

そもそもタスクシステムは汎用技術用語なんかじゃない。
汎用だったら>>250 >>259や>>416 >>417のような「俺定義」の確認は要らない。

>>397は藪をつついて蛇を出したな。

419 ：名前は開発中のものです。：2007/11/12(月) 12:30:37 ID:XbsUO0Z/

>>407
そこらのタスクシステムと呼ばれる代物は、Cの言語機能と矛盾するものは少なくね？
C++のオブジェクト志向と矛盾するものは多いけど。

で、タスクシステム信者と呼ばれる人は、C++のオブジェクト志向による
パフォーマンス低下（実際そんなもんどれだけあるかしらんが）が気にくわなくて
自分で代替品を構築しようとしているんだと思う。
それを無意味だと思う奴と思わない奴がこのスレで喧嘩していると思うんだな。

420 ：名前は開発中のものです。：2007/11/12(月) 13:07:06 ID:OJMQF6Wo

>>418
それなら擬似ですらないような…

「簡易」じゃないの

421 ：名前は開発中のものです。：2007/11/12(月) 14:14:26 ID:zggKJn88

ごめん418は間違い。「擬似」って言葉を使うなって話だった。
http://piza.2ch.net/tech/kako/983/983126091.html#144

「擬似」に対する文句はこいつに言ってね。
http://web.archive.org/web/20020616073551/http://giggle.cside6.com/hotate/shoot/step03.htm

422 ：名前は開発中のものです。：2007/11/12(月) 14:20:52 ID:zggKJn88

昨日から>>365 >>369の優先度という言葉が引っかかってたんだけど
>>421で出したURLの解説によると、
一本のリストに連結されたタスク種別を区別するためだけに使ってるみたいだから
今なら種別ごとにリストを作るだけの話だよね。

マジで優先度を考慮してたらRTOSのタスクと変わらん気もするな。

423 ：名前は開発中のものです。：2007/11/14(水) 22:43:17 ID:5rMSNQab

今北産業。すっかり出遅れ。

>>409
> ここで言い合っている間にも、外では狂信的な布教活動によって
某ゲーム企業だと、新人研修で紹介してたからなぁ。困ったもんだ。

424 ：名前は開発中のものです。：2007/11/15(木) 03:58:37 ID:YwpN8MgT

まるで狂信者たちの宗教戦争だな

425 ：名前は開発中のものです。：2007/11/15(木) 04:21:16 ID:76QbprdD

いつものことだ。

426 ：名前は開発中のものです。：2007/11/16(金) 08:06:58 ID:cird3CIU

>>424
諸君

私はタスクシステムが好きだ
私はタスクシステムが好きだ
私はタスクシステムが大好きだ

(ry

427 ：名前は開発中のものです。：2007/11/16(金) 13:59:29 ID:f8Jo/xdK

タスクシステムを食わず嫌いする連中は、信者を言語仕様やオブジェクト志向を富豪的に理解できない奴らと非難するし、
タスクシステムを盲信する連中は、アンチを言語仕様の速度的な限界に無関心な奴らと非難するし、
困ったもんだな

428 ：名前は開発中のものです。：2007/11/16(金) 19:02:50 ID:Cd5477Ro

最新のC++設計、コーディングテクニックを使って
いっちょ格好いいタスクシステムライブラリを作ってくれよ

429 ：名前は開発中のものです。：2007/11/16(金) 19:56:27 ID:oD4S4TLt

デザインパターンみたいに
それぞれのタスクシステムに名前つければいいんじゃね

430 ：名前は開発中のものです。：2007/11/16(金) 22:08:24 ID:cird3CIU

>>428
最新なんていわなくても、純粋仮想関数使うだけで終わりな気がするが。

431 ：名前は開発中のものです。：2007/11/17(土) 00:01:35 ID:rpxumafg

継承というシステム自体が、タスクシステムに生かしてくれといわんばかりの相性のよさだよね

432 ：名前は開発中のものです。：2007/11/17(土) 00:42:54 ID:n01xfW4B

>>431
そうけ？

433 ：名前は開発中のものです。：2007/11/17(土) 01:03:43 ID:oBpbXrjM

擬似タスク使うと言語の型という型すべてが邪魔に感じねぇか？

言語は進化するたびに制限を増やしてきたんだぜ
～ができるようになった進化はないんだ
どうしてプログラム言語は機能を増やす進化をせずに制限を増やす進化をしてきたのか？
そこをもうちょっと考えたほうがいい
言語から型が消えたらどうなるとか考えたりね

擬似タスク使うとグローバル変数みたいなもんが必須になるし
インスタンスから別のインスタンスにアクセスする仕組みも必要になるしよ
言語の進化をすべて否定すると擬似タスクは使い勝手がよくなるぜｗ

たとえばデータ構造の型を全部捨ててvoid*でもってフォーマットは
ID（４バイト）＋サイズ（４バイト）＋XXXXXXXXXX・・・
って形に統一するとこれまた使いやすくなるｗ

ひたすら、言語の進化と相容れないシステムが擬似タスクｗ

434 ：名前は開発中のものです。：2007/11/17(土) 01:15:24 ID:n01xfW4B

>>433
まあそういうことなんだろうな

人が同時に覚えていなくちゃいけないことを減らすために、
多少の実行時のパフォーマンスの低下とひきかえに生まれたのが
構造化でありオブジェクト志向なわけだが、
疑似タスクを考えた人達は、後者をよしとしなかったということだろ。

435 ：名前は開発中のものです。：2007/11/17(土) 02:22:35 ID:YnGCHPdB

擬似タスクって何だ？まーた変な単語を普及させようとしてね？

436 ：名前は開発中のものです。：2007/11/17(土) 02:25:15 ID:fC9Mdmzp

うんち君のスレはここですか？

437 ：名前は開発中のものです。：2007/11/17(土) 04:21:58 ID:3LkIon8X

継承ベースの設計は多くのC++嫌いを生み出した元凶なのにそれと相性のいいタスクシステムなんて…

438 ：名前は開発中のものです。：2007/11/17(土) 05:31:01 ID:DPRDnI/O

>>437
だけど、結局世の中の主流は継承ベースの設計なわけだが。

プロトタイプベースのOOも小規模なプログラムだと悪くないし、関数型言語も
ある種の処理には良いんだが、どうもニッチを抜け出せんな。

439 ：名前は開発中のものです。：2007/11/17(土) 14:00:05 ID:GbFSCaDk

継承ベース設計嫌いならC++使わずC使えばいいような・・・

440 ：名前は開発中のものです。：2007/11/17(土) 16:06:17 ID:tjJHhoDY

「継承ベース」といっても、深い継承ツリーを作ってしまうもの（実装継承あり）と、
薄いインターフェースを多重継承で組み合わせるようなもの（実装継承なし）とでは全然違う。
>437 の言ってるのは前者で、 >438 の言ってるのは後者じゃないか？

441 ：名前は開発中のものです。：2007/11/17(土) 19:47:56 ID:LV+Iy8AZ

タスクとタスクの間に依存関係をもたせる。
例えばSTGで敵TASKが自機TASKへのポインタを持ち、自機にむかってつっこんでくるとします

この際、自機TASKの前に処理された敵TASKと、自機TASKの後に処理された敵TASKでは、つっこむ座標が微妙にずれてしまいますよね
どういう風に解決しますか？

１・処理前のデータも保持するようにし、全ての依存処理は依存相手の「処理前のデータ」を参照するようにする。最後に更新処理を行なう
コピーもっとくのがあほらしいし、重い

２・TASKの処理順番はリストの先頭からなのだから、敵敵敵自敵敵のようにならないように気をつけてリストに登録する
登録周りが煩雑です

３・TASK毎に処理優先順位を表すデータを持たせる
追加、削除のたびにソート。またはリスト自体をstd::mapのようなものにする必要がある
当然単純なリストよりも処理が重い

４・自機TASKリスト（2人同時プレイとかもありえるから）。敵TASKリスト。アイテムTASKリスト。のようにリスト自体を分けてしまう

442 ：名前は開発中のものです。：2007/11/17(土) 20:15:40 ID:/2CjWoyg

>>441
オブジェクトの毎処理用のタスクと
当たり判定チェック用のタスクと
当たり判定処理用のタスクを分けるしかないだろ？
俺がいたところで疑似タスク使ってたところはそうやってた

443 ：名前は開発中のものです。：2007/11/17(土) 20:31:15 ID:tjJHhoDY

>>441
タスクに依存先タスクを列挙する機能を持たせておいてトポロジカルソート（？）を使う、とか。

444 ：名前は開発中のものです。：2007/11/17(土) 20:45:39 ID:LV+Iy8AZ

>>442
当たり判定ならばそうやって分けるでしょうし、私も分けてますが
「相手の居る座標に依存して追尾」の場合は困るってわけなのです

445 ：443：2007/11/17(土) 20:47:12 ID:tjJHhoDY

試しにコード書いてみて気づいたんだけど、循環依存で死にそうな気がした。

446 ：名前は開発中のものです。：2007/11/17(土) 21:08:33 ID:fdBmFgBa

>>441
俺は４。
listをvectorで包むくらいで十分でしょ。
listの中で優先順位が必要になるケースはほぼ無いし、
必要になってもせいぜい生成順序に気をつけるくらいだ。

447 ：名前は開発中のものです。：2007/11/17(土) 21:09:28 ID:/2CjWoyg

>>444
そうするとアルゴリズムの問題じゃね？
追尾なんだから、同じ時間軸に存在するオブジェクトが
次の行動を決めるときに今の相手の座標をみて次の行動を決めるわけだし
ひとつ前の座標を追うしかないだろ？

448 ：名前は開発中のものです。：2007/11/17(土) 21:11:05 ID:/2CjWoyg

あ、俺はデータの持ち方、つまり実装をどうのこうのするって問題ではなくて
実装者がアルゴリズムを理解していないのが問題っていいたいわけね

449 ：名前は開発中のものです。：2007/11/17(土) 22:20:48 ID:NPl8p4A0

５・気にしない。って言うのもあるぞ。
実際、そのズレは問題になるほどの大きさなのか？

450 ：名前は開発中のものです。：2007/11/17(土) 23:47:29 ID:YnGCHPdB

＞コピーもっとくのがあほらしいし、重い

メモリ4GB積んでる俺様のPCにとっては
鼻糞どころかダニの糞みたいな話だな

451 ：名前は開発中のものです。：2007/11/18(日) 00:01:54 ID:StjYIyi5

そういやダニの糞ってみたことねーな

452 ：名前は開発中のものです。：2007/11/18(日) 00:54:51 ID:T7PhuuM8

>>449
とりあえずタスクシステムなのに、登録順によって挙動がかわるのはまずくねーか？

453 ：名前は開発中のものです。：2007/11/18(日) 03:57:13 ID:CGVEuKtX

なんとなくわかってきたな
多分、>>441はやならなきゃいけないことも
自分がどういうミスをしたのかもわかってるな

ただ、その修正がどういう作業をするのかわかってて
それを認めたくなくてこんなところでくだ巻いてやがんだな

御名答ｗ正しく組むにはお前(>>441)の考えるように１フレームごとに
インスタンスのコピーが必須になりますｍ9(^Д^)ぷぎゃー

この部分、オブジェクトをクラス使って組んでると正直死ねる
各パラメータをコピーする仕組みを作るだけで死ねる

俺も長いことPGやってるけど正直ゲームのオブジェクトと
C++って相性がすげー悪い

454 ：名前は開発中のものです。：2007/11/18(日) 04:06:56 ID:CGVEuKtX

ゲームのオブジェクトって見た目、オブジェクト扱い＝クラスになりそうだけど
実際に作るときはパラをエクセルの表にでもして並べるように組んだほうが
よっぽどゲームが作りやすい

名前　種別　座標X 座標Y　ステ　HP　AT　DF・・・　オブジェクト
キャラA　人・男　554　441・・・
キャラB　人・女
・
・
・
　　
みたいな感じか・・・
時代とは逆行してるけどね
表示はキャラのステと今実行中のアクションやら
なにやらも全部パラメーター化するクラスにはしないほうがいい（経験上）

455 ：名前は開発中のものです。：2007/11/18(日) 04:15:05 ID:CGVEuKtX

インスタンスを頻繁にデータとして保持して複製参照改変、
または複製して改変したものをさらに複製したりする
必要がある時点でもう現実のオブジェクトに即した
設計（一応オブジェクト指向の理想系？ｗ）なんて追うだけ無駄
まあ、やりゃクラスでもできんことはないけど

俺はゲームに使うパラは必要とあらば全部吐き出して見れたほうがいいと思う
バグったときとかにも便利だし

あ、勘違いされると困るんだけど
別にクラスを駄目だって言ってるわけじゃなくて、ゲームにはあわないって話ね

３D・その他のシステム部分とか主にライブラリとかハードよりの部分はいいと思うよ
ゲームみたいにそうおかしな使い方すること滅多にないし
この部分はC＋＋で組むべきだと思う

でも、ゲームのパラに関してはエクセルの表にできるような組み方のが楽だと思う
生成・コピー・挿入できるところまでエクセルと似せた構造で

456 ：名前は開発中のものです。：2007/11/18(日) 13:07:15 ID:T7PhuuM8

よくわからんが、クラスのインスタンスは=演算子で簡単にコピーできるわけだが・・・

457 ：名前は開発中のものです。：2007/11/18(日) 13:28:54 ID:CGVEuKtX

>>456
んーそういうわけにはいかない構造してるっしょ？多分
そりゃ数値の上ではそうだけど
実際には初期化処理やらほかのインスタンスとの接続処理が流れるわけで
本当にコピーというならそういう接続も含めてコピーしなきゃいけない
けどクラスの機能、たとえばポインタの保持やらインスタンスのインスタンスにまでなってると
中のインスタンス（わかりずらくてすまん）が初期化されて
あるべきステータス（オリジナルと同義という意味ではなく複製物としての）になってるかどうか
マジな話わからないよね？

ってこと、おｋ？

458 ：名前は開発中のものです。：2007/11/18(日) 13:38:54 ID:yrx1nk+8

また富豪的なことを言う奴がでてきたな

459 ：名前は開発中のものです。：2007/11/18(日) 14:18:46 ID:T7PhuuM8

キャラの座標値コピーするだけでいいのに、インスタンスへのポインタだのなんだの富豪的な奴だなぁ

460 ：名前は開発中のものです。：2007/11/18(日) 14:26:11 ID:CGVEuKtX

>>459
実際はそうはいかない場合が多いと思うぜ
ステータスもみないとすでに死んでる可能性もあるわけだし（敵を倒す型のゲームだと）

461 ：名前は開発中のものです。：2007/11/18(日) 14:31:45 ID:XM7Kgebk

その話題は元の問題と違うような
それに仮にそういう設計になってたとしても解決にはならんような

462 ：名前は開発中のものです。：2007/11/18(日) 14:48:33 ID:T7PhuuM8

>>460
いかない場合も多いぜ。って言われても、質問主は座標の話してるだけだろ？
「全ての状況に対応できるタスクシステム」なんてものは絶対作れないし、それなのにそれを目指して意味の無い拡張をしてもしょうがない。
適材適所。

みんな「質問主の質問に即したシステム」を返してるのに、それを見て「汎用性がないね！」って返すのはおかしい

463 ：名前は開発中のものです。：2007/11/18(日) 15:00:10 ID:XM7Kgebk

俺ならとりあえず4.(conceptの違うクラスは別の扱いにする)か>>449の5.だね
敵→自機の依存しか無いとすればそれで解決する筈
敵→敵とか、敵→自機とか、依存先が複数存在するとかそういうのならオーバーヘッド覚悟でmemento使うけど

とりあえず実際のコードが見たいです廃

464 ：名前は開発中のものです。：2007/11/18(日) 15:02:09 ID:T7PhuuM8

俺も多分4にするだろうけど、３ってどうなんだ？
mapってそんなに挿入と削除重かったっけ？

優先順位を生成時に気軽に指定できるシステムってのは、なかなかよさそうな気がするんだが

465 ：名前は開発中のものです。：2007/11/18(日) 15:04:52 ID:CGVEuKtX

>>463
他、どんな意見があろうがかまわんが５だけはありえない
プログラムが管理できてない上にどんなバグり方するのかも想像ができない
かなり危険だし、プログラマの仕事を放棄してるように見える
なにより、怖くてリリースできない
プロジェクトならみんなで一斉にキャラの状態をすべてあらって
どこでどうまずいのか１つ１つチェックしていけば２～３日で終わるのではないだろうか？

466 ：名前は開発中のものです。：2007/11/18(日) 15:13:05 ID:zUd2g0wj

>>464
優先順位を指定できるということは優先順位を正しく指定しないといけないということに
なって、かえってバグが増える元になりそう。数値で指定するとしたら、グローバルな
優先順位表とか管理しないといけなさそうだし。静的な処理の呼び出し順で解決できるなら
それで済ませておくのがいいでしょ。つまり４ね。

間を取る形になるのが >443 で挙げたやつなんだけど、だれも食いつかないね。４が
選択肢にあるってことは循環参照は無いものと仮定できそうなんだけど、ダメなのかな？

467 ：名前は開発中のものです。：2007/11/18(日) 15:21:35 ID:CGVEuKtX

>>466
いや、つか、そもそも生成時から処理順序を変える必要がある場面が想像できない
キャラの種別によって順序はすでに確定してるだろ？
それともちがうことかんがえてる？

468 ：名前は開発中のものです。：2007/11/18(日) 15:47:31 ID:zUd2g0wj

>>467
とりあえず「生成時から処理順序を変える」なんて話はしてないよ。

469 ：名前は開発中のものです。：2007/11/18(日) 16:36:39 ID:T7PhuuM8

>>466
でもさ、例えば自キャラはPRI_PLAYER
雑魚は PRI_ZAKO
アイテムは PRI_ITEM
って感じでやるなら管理も楽だしよくね？

470 ：名前は開発中のものです。：2007/11/18(日) 16:39:21 ID:wtZ07r57

とことん話がかみ合わないみたいだな

471 ：名前は開発中のものです。：2007/11/18(日) 18:15:27 ID:k8RP4Efz

だから一本のリストに全てまとめようとするのが間違いなんだよ。

472 ：名前は開発中のものです。：2007/11/18(日) 18:30:06 ID:T7PhuuM8

一本のリストに全てまとめようとするのは必ずしも正しくないが、
正しく（実行効率もよく）一本にまとめられるなら、それにこしたことはない。と思うんだが・・・

新しいリストを作る手間もはぶけるし

473 ：名前は開発中のものです。：2007/11/18(日) 18:53:55 ID:zUd2g0wj

>>469,472
優先度を定数で持てば管理が楽だというが、そもそもリストを分けていればその点の
「管理」というものがまったく必要ない。実行効率についても、優先度の比較が必要ない分
リストが分かれていたほうが上。新しいリストを作る手間っていうのも std::list なんてのが
標準ライブラリにある現状でどれだけかかるというのか。

総じてメリットが理解できない。

474 ：名前は開発中のものです。：2007/11/18(日) 19:07:49 ID:T7PhuuM8

それもそうか。考えてみれば1行書き換えるか程度の手間しかないや
今思いついたマイナスが使えるという利点も、マイナスにならないように作ればいいだけの話だしな

475 ：名前は開発中のものです。：2007/11/18(日) 23:11:25 ID:mDvA2is2

>>472
> 新しいリストを作る手間もはぶけるし
それ enum に一行付け加えるだけじゃない？　コードは、せいぜいこんなモンでしょ。

enum TASK_PRIO { TASK_PRIO_PLAYER, TASK_PRIO_ENEMY, TASK_PRIO_MAX };

struct ITask;
typedef std::list<ITask*> TaskList;
TaskList task_list[TASK_PRIO_MAX];

void add(ITask* task, TASK_PRIO prio) { task_list[prio].push_back(task); }

476 ：名前は開発中のものです。：2007/11/18(日) 23:52:20 ID:Wa1vgxuh

何そのC言語的ソースはｗｗｗ

477 ：名前は開発中のものです。：2007/11/18(日) 23:59:14 ID:mDvA2is2

>>476
ITask が純粋仮想関数しか定義してない抽象基底クラスなら、むしろいかにも C++ な
コードだと思うんだが。

478 ：名前は開発中のものです。：2007/11/19(月) 00:05:52 ID:KTA8755F

明らかなクズソースだと思う。

479 ：名前は開発中のものです。：2007/11/19(月) 00:37:02 ID:2O26VKh3

どこらへんが明らかなのかさっぱりわからん
ごく普通だと思うんだが…
強いてあげればスマートポインタのリストじゃなくて、生ポインタのリストなところか？？
それもdelが対処してればどうでもいい話だし…

480 ：名前は開発中のものです。：2007/11/19(月) 00:38:36 ID:1qCZ2s5F

俺はそのコードそのものに違和感を感じないが
ITaskが何を意味しているのかによってはブチ切れる

481 ：名前は開発中のものです。：2007/11/19(月) 00:44:02 ID:Og0NPPF4

１０年以上プログラマやってるけど
いまだにstructの意味知らないぜ俺ｗ
typedefつけないとなんかバグるって程度だｗ

482 ：名前は開発中のものです。：2007/11/19(月) 00:46:27 ID:2O26VKh3

>>480
どうだとブチきれるのかまで書けよｗ

483 ：名前は開発中のものです。：2007/11/19(月) 00:59:01 ID:Og0NPPF4

voidなんじゃねぇの？

484 ：名前は開発中のものです。：2007/11/19(月) 01:06:09 ID:0JfcioSs

>>475
そのコードだと Player というクラスを TASK_PRIO_ENEMY で登録できてしまう。
C++ 的と言いたいならもっと型システムを利用したほうがいいんじゃないか？

具体的に言うと↓みたいな感じね。
class Player;
class Enemy;
std::list<Player*> players;
std::list<Enemy*> enemies;

プレイヤーの数は固定で済むことが多そうだな。
Player* player とか Player* players[2] とかでいけるともっといい。

485 ：名前は開発中のものです。：2007/11/19(月) 01:06:12 ID:1qCZ2s5F

>>482
class ITask
{
　D3DXVECTOR3 m_pos;
public:
　virtual Update( float dt ) = 0;
};
とかだったら発狂

486 ：名前は開発中のものです。：2007/11/19(月) 01:13:17 ID:1qCZ2s5F

突っ込まれる前に念のため補足
class ITask
{
public:
　virtual Update( float dt ) = 0;
};
class GameObj : public ITask
{
　D3DXVECTOR3 m_pos;
};
とかでも一緒。

487 ：名前は開発中のものです。：2007/11/19(月) 01:22:52 ID:0JfcioSs

>>486
何が気に入らないのかよくわからないな。なんでそんなに情報を小出しにするの？
すぱっと言っちゃってよ。

488 ：名前は開発中のものです。：2007/11/19(月) 01:42:31 ID:J+PXhoOI

継承させずにGameObjにint Update(float)を実装して
template<class Updatable>
int Update(Updatable& obj, float dt) { return obj.Update(dt); }
みたいなのに放り込むようにしろって事？？？？

489 ：名前は開発中のものです。：2007/11/19(月) 01:55:39 ID:1qCZ2s5F

>>487
ごめん。てか今更気づいたんだけど
そのタスクリストに対して次のような操作をする関数があることも更に前提に…
void CollideTasks();

ゲーム内インスタンスのコレクション自体は問題ないとしても
そのコレクションの順序で仕事順序まで管理しているのが問題なんじゃね？

で、>>475の例はそれを同一視してるんだよね？
そういうことをして管理してるから、全ての敵キャラに対して処理を行う、とかいうときに
for( size_t i = 0; i < tasks_list[TASK_PRIO_ENEMY].size(); i++ )
　Foo( ((Enemy*)task_list[i]) );
みたいにダウンキャストとか発生しそうなんだけど(Visitorという手もあるが)

それくらいどうでもいい、って人にはほんとにどうでもいい話なんだろうけど。

>>488
いや、それは解決策の一つだけど、そういうことではないです。
言った手前恥ずかしい話なんだけど、>>486のような例で、
タスクリストに対して更新以外の処理を行わないければそれは理想的でした。
(その前提を翻すために衝突の関数があることを条件に加えた)

490 ：名前は開発中のものです。：2007/11/19(月) 07:18:15 ID:0JfcioSs

>>489
あぁ。「単一のリストでなんでもやろうとする」病の典型って感じかな。たしかに、
こういうリストをただのリストじゃなくて「タスクシステム」なんて呼んでる人には当てはまる
人が多そうだから、リストの型名に Task なんてついてたら警戒すべきかもしれないね。
そういう人は古い「タスクシステム」の実装のせいで無理キャストに抵抗無かったりするし。

>489 のはそういうのを実際に見たり（またはひどい目にあったり）したことがあるのかな？

やっぱり「タスク」っていう言葉は意味が不明瞭すぎるよねぇ。

491 ：名前は開発中のものです。：2007/11/19(月) 07:48:01 ID:Og0NPPF4

別に型なんてつけたって
グローバル変数にアクセス必須になる事態はかわんないじゃん
俺にとっちゃ区別してるほうが意味不明だっつの
下手糞がどんぐりの背比べしてるだけに見える

492 ：名前は開発中のものです。：2007/11/19(月) 08:29:33 ID:J+PXhoOI

なぜにそこでグローバル変数が出てくるのか

493 ：名前は開発中のものです。：2007/11/19(月) 10:16:41 ID:n4NqKyad

タスクシステムと呼ばれる代物に
グローバル変数は必須じゃないよな

494 ：名前は開発中のものです。：2007/11/19(月) 19:14:49 ID:m5Hr8VBl

だが、グローバル変数を入れることで、
俺のプログラムも地球規模のグローバリズムの流れには逆らえなかったか、
と、感慨に耽ることができる。

わけがない。

495 ：名前は開発中のものです。：2007/11/19(月) 19:25:22 ID:JV/bT05F

>>489
普通に考えれば、EnemyはPlayerに対するポインタもってるんじゃね？
んでEnemyはPlayerとのコリジョンを行って、当たっていたらその胸を
pPly->hit(this)
って感じでプレイヤーに通知するんじゃね？

プレイヤー側は（必要ならば）もらったポインタをリストとしてもっておいて、自分の次のUpdate時に自殺するんじゃね？

496 ：名前は開発中のものです。：2007/11/19(月) 19:56:27 ID:n4NqKyad

なんか過去レスさかのぼってみると、
タスクシステムってグローバル変数が必須とか勘違いしている奴が延々いるな。
一人なのか複数なのか知らんけど。

自分でコード書けばそんなのすぐわかるのに、自分で試しもせずにこのスレに居ずわらんでほしいな。
タスクシステム批判に食わず嫌いのレッテルが付くと、このスレじゃまともな議論が出来なくなる。

497 ：名前は開発中のものです。：2007/11/19(月) 20:43:22 ID:JV/bT05F

近視観的にレスするけど、EnemyとPlayerとの依存関係がある場合
ポインタを持っていない限りリストをグローバル変数にせざるをえないって意味じゃね？

498 ：名前は開発中のものです。：2007/11/19(月) 20:52:21 ID:n4NqKyad

参照の依存関係で、ポインタを持たなければグローバルにする必要があるってのは、
別にゲームに限らないよなー。
やっぱりタスクシステムと関連づけるのは間違いだろうよ。

499 ：名前は開発中のものです。：2007/11/19(月) 21:16:08 ID:SUdXAADt

ポインタもグローバルもバグの温床というだけであって、
キッチリ管理されていれば何ら問題はないんだがなｗ
そこまで潔癖症なら仮想継承すればと思うけど、
実質ポインターだからそれもだめかね？

500 ：名前は開発中のものです。：2007/11/19(月) 21:27:46 ID:FRIZOmef

>>495
> 普通に考えれば、EnemyはPlayerに対するポインタもってるんじゃね？
それやると、Enemy と Player の寿命管理でバグる可能性があって嫌な感じだ。
個人的には Manger クラスに Enemy と Player を集約させて、

1)Player, Enemy が必要に応じて Manager に聞きに行く
2)Player, Enemy は Hit 判定に必要なメソッドを実装し、Manager 側でヒット判定して
　結果を Player, Enemy に通知

どっちかが良いと思うが。

501 ：名前は開発中のものです。：2007/11/19(月) 21:34:22 ID:JV/bT05F

>>500
スマートポインタならいいかなーとも思ったけど、確かにマネージャ作ったほうが安心だね
常に最新のプレイヤー（STGとかならプレイヤーが死んで、新しくその場復活する場合もあるからな）へのポインタを取得できるし

502 ：名前は開発中のものです。：2007/11/19(月) 22:03:38 ID:5KKJw7Ik

「EnemyとPlayerとの依存関係」が現実の何をモデル化したものか再考し
EnemyがPlayerのポインタを持つという実装の異常性を理解すべきだな

実際のEnemyはレーダーなり光学センサーなどの索敵装置が捉えた像から
Playerに関する限定的な情報(方位、距離、速度、敵味識別信号の有無、など)
を取得してるに過ぎない

それを実装した結果がPlayerのポインタ保持というのは、ある意味で究極の端折り方

503 ：名前は開発中のものです。：2007/11/19(月) 22:18:24 ID:FRIZOmef

>>502
別に現実のモデル化する必要はないと思うが。ゲームの世界観によっては
テレパシーかもしれんし。

まぁ、バグなくメンテしやすく動けば何でもいいよ。

504 ：名前は開発中のものです。：2007/11/19(月) 22:32:50 ID:JV/bT05F

>>502
ギャラガの敵がそんな高度なことしてるかｗ

505 ：名前は開発中のものです。：2007/11/19(月) 22:38:58 ID:5KKJw7Ik

テレパシーとかどうでもいいよ
>>441あたりの話を基点にしているだけだし

506 ：名前は開発中のものです。：2007/11/19(月) 22:41:09 ID:J+PXhoOI

2Dゲームの誘導ミサイルみたいなものが保有するデータとして、
追尾対象のハンドルを持つのは別におかしいことじゃないと思うがね
個と関係をグラフとして内部にハンドルを持たせる以外の管理の方法もあることはあるけどさ
単に生ポインタとして持つのはやめろという主張だったら何も言えないけど

507 ：名前は開発中のものです。：2007/11/19(月) 23:08:03 ID:5KKJw7Ik

＞ハンドル

そう。とにかく間接的な形でリンクを張ってくれと思う

508 ：名前は開発中のものです。：2007/11/19(月) 23:27:47 ID:m5Hr8VBl

そういうややこしいことをしてると、追尾対象が消滅した瞬間に落ちたりするけどな。

509 ：名前は開発中のものです。：2007/11/19(月) 23:30:18 ID:1qCZ2s5F

落ちるってハングってこと？

単に参照先が消えたことに対するnullチェックだの
その辺の処理を怠ってるだけじゃなくて？

510 ：名前は開発中のものです。：2007/11/19(月) 23:39:28 ID:5KKJw7Ik

>>508
間に何らかの機構を噛ませてるのに
何で追尾対象が消滅した瞬間に落ちるんだよｗ

目標が堕ちたり障害物介在で視界外に行ってしまったら
FCSが推定位置を算出して返すなり、目標ロストと認定して
目標再捜索モードに移行するなりその場で自爆するだけだろ

511 ：名前は開発中のものです。：2007/11/19(月) 23:41:08 ID:5KKJw7Ik

FCSが→ハンドルが

512 ：名前は開発中のものです。：2007/11/20(火) 00:01:41 ID:vkrh1bH5

久しぶりきたらまたやってるよｗｗｗｗ
定期的にわくんだな

すべての機能を実装したサンプルソースのひとつもあげないで議論しても無駄

断片的なソースの一部だけでみんなバラバラなこと言うから

おれはこのタスクシステムとやらが何を指すのかよくわからないので出せないけどなｗ

513 ：名前は開発中のものです。：2007/11/20(火) 00:04:55 ID:pV/XuAjA

　　　　　　　　　　_, ._
　　　　　　　　（　・ω・）　　　.　　.
　　　　　　　　　○=｛=｝〇, ; .'´　｀. ﾞ ;　｀
　　　　　　　　　|:::::::::＼,.'.;´," :´,´'　. ﾞ　.｀　.
　.,,.,.,,,.,.,,,.,.,,,.,.,,,.,.,し,,.,.,`（.＠）ｗｗｗｗ

514 ：名前は開発中のものです。：2007/11/20(火) 00:12:37 ID:AiN86IUF

>>512
そうやって人の意図を微塵も汲まないで会話する奴には
サンプルソースなんてあったってなくたって結局自分の有利なように
相手のいうことをわざと曲解して受け取って返すくせがついてるから
話し合いそのものが無駄だと思う
人の意見を聞くっていうよりもう自分の中に解があるから
だれのどんな意見にも結局耳をかさない

嫌いな奴のレスには揚げ足をとる
全然関係ないことをさも重要そうにしゃべりだす

こういう奴って何人も見てきた
いま、この場で>>512みたいな意見を出す奴ってもうなにを言っても無駄だと思う

515 ：名前は開発中のものです。：2007/11/20(火) 00:19:41 ID:AiN86IUF

>>499
グローバル変数を使った時点で管理できてねぇと思うんだがな

とりあえず

１．グローバル変数使用禁止
２．別インスタンスのポインタ保持禁止

は昔っから言われてることだし
ちょっとは守れと・・・
１は引数を通さないことによって起こる予測不可能なアクセスによる変更がまずい
２はDirectX触ったことあるならデバイスロストで散々痛い目みただろ？

516 ：名前は開発中のものです。：2007/11/20(火) 00:26:44 ID:MI1ZA76A

無能なPGは、アクセスを予測できないし、
デバイスロストっつーか、

浮き輪を付けたまま泳ごうとするから、溺れるんじゃね？

517 ：名前は開発中のものです。：2007/11/20(火) 00:35:02 ID:AnxMhEvE

>>515
１と２禁止した場合、どうやって他のTASKの情報を知るんだ？
上で言ってるようにマネージャ使ったり、間接ポインタ（相当のもの）を使ったりってこと？

518 ：名前は開発中のものです。：2007/11/20(火) 00:39:13 ID:AiN86IUF

>>517
だからタスクシステム使うとグローバル変数必須になるっていってんじゃんｗ

強引にvoid*で必要なもん全部渡してもいいけどｗ
この場合、たとえ引数で渡してもグローバルとかわんないっしょ

タスクシステム自体、プログラム的にあんまりうまい組み方じゃない

519 ：名前は開発中のものです。：2007/11/20(火) 00:47:57 ID:ViDcgrYi

てことは、タスク使わないで書いてるの？
どうやって書いてるの？

私はタスクシステムマンセーとかいう人ではないけど、純粋に興味あるよ
(むしろ「タスクシステム」なんて単語が大嫌いなほうなので)

520 ：名前は開発中のものです。：2007/11/20(火) 00:56:06 ID:oM8i1X0R

だからタスクシステムを使ったってグローバル変数は必須にならねーよ

他のタスクを覗くためのクラスを作ってそのメソッドを使えばいいんだからさ。
で、タスクが、そのクラスの参照を持つか、メソッドの参照を持つかはケースバイケース

521 ：名前は開発中のものです。：2007/11/20(火) 00:58:37 ID:jZLXymZJ

相変わらずシャドウボクシングの毎日

522 ：名前は開発中のものです。：2007/11/20(火) 01:04:20 ID:pV/XuAjA

>>515
ID:5KKJw7Ikだけど、一人で作るゲームとか小規模で使い捨てできるコードなら
１も２も普通にアリだと思う。でもこのスレでは「ダメっ！絶対！」ぽい雰囲気なのは
たぶん他人から見てかっこいいかどうかっていう見栄の観点が大きいからだと思う

ログ読んでても、多人数でゲーム作ったことある奴は少数派だと思う

523 ：名前は開発中のものです。：2007/11/20(火) 01:19:07 ID:AiN86IUF

>>520
だからって「ポインタ保持」使ってたら意味ないぜ

524 ：名前は開発中のものです。：2007/11/20(火) 01:20:45 ID:AiN86IUF

>>519
え？
じゃ、君、タスクシステム使わないとゲーム組めないの？
そっちのほうが違和感ねぇ？
自分でおかしいとちょっとも思わないところがなんかいやーんな感じ

525 ：名前は開発中のものです。：2007/11/20(火) 01:27:42 ID:pV/XuAjA

どうでもいいけど、ネトラン厨クラスのワナビー界にまで普及してしまった
タスクシステムというキーワードも、見栄の観点から言えばこれももはや
「ダメっ！絶対！」だと思う

＞オブジェクト指向とは全く違う自由度と再利用性の高い汎用的な管理の仕方

とか持ち上げてる奴らが、誘導弾に目標インスタンスの生ポインタを平気で
持たせたりするんだ

このキーワードを発したら脳みそカチンコチンもフェードアウトレトロゲームマニアオヤジ
と認定するくらいの言葉狩りをしたほうが個人的に胸がスカっとする

526 ：名前は開発中のものです。：2007/11/20(火) 01:31:41 ID:oM8i1X0R

>>523
だから、生ポインタを扱うような汚れ仕事は一部のクラスにさせちゃうの。
他のタスクとかクラスは、ハンドルなりそのクラスのメソッドを使うの。
グローバル変数を使うよりずっと危険が少ない。

そもそも、そういう設計って、別にゲームに限った話じゃないじゃん。

527 ：名前は開発中のものです。：2007/11/20(火) 01:31:45 ID:ViDcgrYi

>>524
別に使わなくても組めるけど、それよりはクラスちゃんと分けて作ったほうがいいじゃん。
それより質問に答えてよ。

528 ：名前は開発中のものです。：2007/11/20(火) 01:35:55 ID:oM8i1X0R

つか、このスレでここんところ言われてるけど、
グローバル変数かタスクによる生ポインタ保持が必須ってのは明らかに間違いだ。

なんか延々どちらかが必須みたいな言い方している奴がずっといるけど、
こいつは無効なポインタ操作による例外発生を避けるために、
自分でハンドルを作るコードとか書いたこと無いのか？

529 ：名前は開発中のものです。：2007/11/20(火) 07:17:43 ID:bDNdDBC1

>>517
引数で渡す。

もちろん引数で個別の情報を全部渡していたら引数の数が多くなりすぎるし、
仕様変更時に修正箇所多くて死ぬから、コールバック的に使えるように
>>383 みたいに書く。

530 ：名前は開発中のものです。：2007/11/20(火) 12:53:08 ID:U9Kc6nfF

コールバックなんてもっとわかりずれぇよ

531 ：名前は開発中のものです。：2007/11/20(火) 12:59:32 ID:U9Kc6nfF

>>526
アフォだな
ハンドルなんか使ったって
結局、管理クラスに当たるモンはどんぶりなんだろ？
本質からかなりズレちゃってることはわかるだろ
引数で普通に渡せよ
引数多くしちゃいけないなんて誰も言ってないだろ

532 ：名前は開発中のものです。：2007/11/20(火) 13:57:11 ID:oM8i1X0R

>>531
どんぶりってなんだ
普通の日本語で話せ

533 ：名前は開発中のものです。：2007/11/20(火) 15:37:51 ID:tJLleETF

通信対応を目論んでるならハンドル挟むのが必須だね
関係ないとこならweak referenceを自作して使ってみてはどうか
メモリ開放の順番が確定的で相当頻繁に参照する必要があるなら
ポインタ直持ちしてもいいんじゃないかシンプルでいいじゃん別に

534 ：名前は開発中のものです。：2007/11/20(火) 16:10:59 ID:tJLleETF

weak referenceでさらに参照対象が無効になったときにnullじゃなくて
null objectが帰ってくるようになってたらかっこよすぎてうんこ漏らす

535 ：名前は開発中のものです。：2007/11/20(火) 19:45:03 ID:Vx2QdF3D

int main() {
　...
　while (loop) {
　　move_background();
　　move_player();
　　move_enemy();
　　move_effects();
　　clear();
　　draw_background();
　　draw_enemy();
　　draw_player();
　　draw_effects();
　　wait();
　}
}

もうなんか、こんなんでいい気がしてきた。

536 ：名前は開発中のものです。：2007/11/20(火) 19:57:51 ID:jLfmggJd

>>535
日本の市販ゲームの９割はそんな感じ。

537 ：名前は開発中のものです。：2007/11/20(火) 20:49:26 ID:bDNdDBC1

>>535
基本的にそうなるけど、問題はプレイヤーを追尾するような敵がいた場合に、
move_enemy() からどうやってプレイヤー位置参照するかじゃないの？

538 ：名前は開発中のものです。：2007/11/20(火) 20:54:44 ID:Hm7LKt2C

move_enemy(p);

539 ：名前は開発中のものです。：2007/11/20(火) 21:11:18 ID:bDNdDBC1

>>538
俺は >>529 で書いたとおり、基本的にそうだけどさ。(p) ではなく (this) の
コトが多いけど。

540 ：名前は開発中のものです。：2007/11/20(火) 21:36:20 ID:S0LnO3bu

タスクシステムをもってしても、
君達タスクシステム厨の苦手なポインターは回避できないから、
いいかげん諦めろ……タスクシステムをｗ

541 ：名前は開発中のものです。：2007/11/20(火) 21:43:16 ID:OVlMufIS

仮にthreadやfiberを使っても共有リソースのアクセス問題とか実行順序とか問題は出てくるじゃない
これはこれは固有の問題というよりconcurrentの問題だと思うがなぁ

542 ：名前は開発中のものです。：2007/11/20(火) 22:05:40 ID:S0LnO3bu

そうだねタスクシステムじゃ回避できないよね

543 ：名前は開発中のものです。：2007/11/20(火) 22:24:45 ID:4/iV+cP/

むしろポインタだいすきっこがタスクシステムという代物をありがたがってる実態

544 ：名前は開発中のものです。：2007/11/20(火) 22:24:50 ID:ViDcgrYi

>>519
で、いい加減質問に答えてくれないですか？

545 ：名前は開発中のものです。：2007/11/20(火) 23:16:18 ID:U9Kc6nfF

>>535
正解！
俺、会社ちょくちょく変わってるけど
その組み方が一番多い
んでもって一番バグが少ない
タスクシステム使ってるところは普通に組むところの十倍ぐらいバグが多くなる
>>544
タスクシステム使わないで組むってこういう感じよ
>>535みたいな組み方ね
タスク使ってもさ
この部分の管理って省けないでしょ？ｗ

546 ：名前は開発中のものです。：2007/11/20(火) 23:18:24 ID:TPsgIBy6

タスクシステムの定義として、とりあえずこれらには異論ないだろ？

(1)それぞれのタスクは大抵、自己を表現するための変数領域を持つ。
(2)それぞれのタスクが、その上位の存在から呼び出される形で動作する。
(3)動作の内容は（大抵の場合極短い）単位時間分の自己の更新である。
(4)単位時間は、全てのタスクで共通の長さであり、また変動もしない。

タスクシステムのすごさは、(3)と(4)だよな
シングルタスクなマシンであっても、擬似的にスレッド的に動かせる。
本当のスレッドと違って、同期をとるのがとても簡単。
フレームスキップも楽勝。
（乱数や入力さえ再現すれば）確実に状況を再現できる再現性の高さ。

547 ：名前は開発中のものです。：2007/11/20(火) 23:19:44 ID:TPsgIBy6

>>545
で、その正解な535システムでは、あるオブジェクトから別のオブジェクト。
例えば敵Aからプレイヤーをどうやって参照するの？
そこまで書いてやっと「みたいな組み方」でしょ

548 ：名前は開発中のものです。：2007/11/20(火) 23:28:30 ID:U9Kc6nfF

>>547
>>538
冗談抜きで

549 ：名前は開発中のものです。：2007/11/20(火) 23:34:43 ID:U9Kc6nfF

あ、でも敵とプレイヤーの関連なら引数で渡さないかも
ただ、こっからはホントＣ言語風味で組んでる
フツーにな
フツーに

550 ：名前は開発中のものです。：2007/11/20(火) 23:36:23 ID:ViDcgrYi

>>545
何を言いたいのかは分かった。
例えばdraw_enemy()をタスクとして扱うのは問題外ってことでしょ？
それは同意する。
ていうか、そんなところをタスクで管理する奴はこの世から消えて欲しい。

>>546
あんたの言いたいことは分かるんだけど、
タスクって英語を直訳したら仕事じゃないの？
仕事が位置とか速度の状態を持つの？　概念的におかしいよ。
まず名前付けから考え直して欲しいとつくづく思う。

551 ：名前は開発中のものです。：2007/11/20(火) 23:37:15 ID:AnRrpX9/

>>546
なぁ釣りだろ？釣りなんだよな？

このスレ、たまーに素でリテラシーのかけらもない
タスクシステム厨が出現するから油断できない

552 ：名前は開発中のものです。：2007/11/20(火) 23:40:54 ID:TPsgIBy6

>>551
釣り要素まじってた？
最大公約数的な部分だけ抜き出したつもりだったんだが

>>550
仕事は位置とか速度持つだろう
「カリフォルニア州からユタ州へトラックで荷物を運ぶ仕事」
現在どこにいるのか
どのくらいの速度で走っているのか
何を積んでいるのか

553 ：名前は開発中のものです。：2007/11/20(火) 23:45:59 ID:4/iV+cP/

むしろこれでいいんじゃね

int main() {
　...
　while (loop) {
　　move_background(move_player(move_enemy(move_effects())));
　　clear();
　　draw_background(draw_enemy(draw_player(draw_effects())));
　　wait();
　}
}

名付けて、メガマックシステム。

554 ：名前は開発中のものです。：2007/11/20(火) 23:48:46 ID:ViDcgrYi

>>552
位置を持ってるのはトラックじゃないの？

555 ：名前は開発中のものです。：2007/11/20(火) 23:54:28 ID:AnxMhEvE

つきつめればそうだが、それなら（必殺）仕事人システムにでもしろというのか

556 ：名前は開発中のものです。：2007/11/21(水) 00:09:51 ID:dPFcJEqp

>>552
釣り要素満載すぎ

君の定義するタスクシステムとやらには
わざわざ命名をするほどの新規性とか
独自性が何もない

一定の時間刻みで数値積分を繰り返して
時間発展させる、ごくありふれた数値計算
でしょ？

>タスクシステムのすごさは、(3)と(4)だよな
>シングルタスクなマシンであっても、擬似的にスレッド的に動かせる。

タスクシステムとやらを使わなくても普通に
できるでしょ。どこが凄いの

>本当のスレッドと違って、同期をとるのがとても簡単。

タスクシステムとやらはシングルスレッド前提なの？
ネットに出回るレトロゲーマニアの
化石情報とかソフバンのゴミ本ばっか
読みすぎじゃね？

>フレームスキップも楽勝。

これはタスクシステムだけにしかできないの？
普通にできるでしょ？

>（乱数や入力さえ再現すれば）確実に状況を再現できる再現性の高さ。

これも同じく

557 ：名前は開発中のものです。：2007/11/21(水) 00:18:07 ID:y72QUY/t

「古典文学なんて古臭いね。新規制も独自性も無い。現代においてごくありふれた表現法でしょ」

558 ：名前は開発中のものです。：2007/11/21(水) 00:19:44 ID:3I3vCjH2

>>556
確認用の再定義に対して何を言ってるんだｗ釣りか？ｗ

559 ：名前は開発中のものです。：2007/11/21(水) 00:26:06 ID:y72QUY/t

煽るだけだと同類だな俺も
>>556

> >タスクシステムのすごさは、(3)と(4)だよな
> >シングルタスクなマシンであっても、擬似的にスレッド的に動かせる。
> タスクシステムとやらを使わなくても普通に
> できるでしょ。どこが凄いの

どうやるのか純粋に興味あるから、教えてくれ。
全てのオブジェクトを少しずつ更新し、オブジェクトリストを持つ親が同期を簡単に管理できるタスクシステム。
とは違う方法で。

あとお前の文章「普通に」が多いんだが、俺は「普通に」やるなら>>546でいうタスクシステムを使うわ

560 ：名前は開発中のものです。：2007/11/21(水) 00:36:08 ID:Vcv4RdfS

>>557
その例えは明らかにおかしいだろー
だってよー、旧石器時代のゲームプログラマとかその狂信者であるレトロゲーマニア共が
タスクシステムとか崇めてるソレってのは古典文学ではなく、出典不明の都市伝説なわけじゃん？

80年代にどっかの誰かが「俺様って天才！これって大発明じゃん！」とか一人で勘違いして
チラシの裏に書き留めたものをどっかの誰かがゴミ箱から拾って「これスゲ！マジお宝！」
とか勘違いして有難がって祭り上げてるに過ぎないだろ

理工系四大の1年次生とか高専学生が基礎教養として学ぶ計算機科学の初歩がちょっとでもあれば
ゲー専学生が涙を流して喜んでるソレが、いかにくっだらねーチャチな代物か分かるだろ

561 ：名前は開発中のものです。：2007/11/21(水) 00:41:52 ID:dPFcJEqp

>>559

>>535でできるでしょ
それともこれがタスクシステムなの？

562 ：名前は開発中のものです。：2007/11/21(水) 00:48:55 ID:uKQ7oJIx

なんかやけにスレを流したい奴がいそうだな
あ、俺の書き込みはこのｉｄとU9Kc6nfFだけな

563 ：名前は開発中のものです。：2007/11/21(水) 00:54:30 ID:5kUYGpBy

タスクシステムをざっと眺めてみたが
なんかC使いがリストと関数ポインタ使って
オブジェクト指向してみました、みたいな感じだな

564 ：名前は開発中のものです。：2007/11/21(水) 01:03:02 ID:wwzD49Zq

>>563
ちがうんじゃね？

565 ：名前は開発中のものです。：2007/11/21(水) 01:07:33 ID:5kUYGpBy

>>564
どう違うのかkwsk

566 ：名前は開発中のものです。：2007/11/21(水) 01:13:06 ID:5kUYGpBy

つーか>>563は>>4の擬似タスクの方か

567 ：名前は開発中のものです。：2007/11/21(水) 01:14:16 ID:wwzD49Zq

多態性はともかく、カプセル化が希薄だし、継承もタスクの実行メソッドだけだし。

568 ：名前は開発中のものです。：2007/11/21(水) 01:18:02 ID:5kUYGpBy

「希薄」とか「だけ」とか言われても・・・
あんたがどのくらい強いオブジェクト指向を想定してるのか知らんわけで

569 ：名前は開発中のものです。：2007/11/21(水) 01:18:31 ID:rGdz/3mh

>>561
じゃあそのmove_enemyの中はどうなってんの？

570 ：名前は開発中のものです。：2007/11/21(水) 01:30:27 ID:wwzD49Zq

>>568
俺もおまいさんがどんだけオブジェクト志向のコードを
書き分けたのか知らんしな

571 ：名前は開発中のものです。：2007/11/21(水) 01:45:32 ID:5kUYGpBy

>>567
カプセル化も継承もやればできるような・・・
というか、そんなに厳密にオブジェクト指向の定義与えたら
OOPL使ってもOOPしてないことになるような
まあそういう主張は可能だろうけど（それとも構成要件に入ってんの？）

572 ：名前は開発中のものです。：2007/11/21(水) 01:50:24 ID:5kUYGpBy

wikipediaで見た限りでは構成要件に入ってるみたいね
じゃあ>>563を「オブジェクト指向っぽくしてみました」に変える

573 ：名前は開発中のものです。：2007/11/21(水) 01:55:39 ID:rGdz/3mh

>>555
俺視点で見たら、タスクシステムよりは仕事人システムのほうがまだマシ。

個々の人が周辺環境を見ながら自立的に進行していくってモデルを進めていったら
巷で言われているタスクシステムそっくりになりました、ってことはよくあるだろうて。
ただ、たまたまコード上はタスクシステムと同じ実装になっているだけで、
単なる物体のコレクションというのが適切な名前なんじゃないのかと。

あと、これは物体のコレクションなんだから、それ以外のものは入れてはならない。
enemyは入れてよいが、move_enemy()をコレクションに入れてはならない。
それを無理してできるようにComposite構造にするのは改悪としか言いようがない。

574 ：名前は開発中のものです。：2007/11/21(水) 03:28:34 ID:cQXGr6XX

つか、オブジェクト指向の三本柱もわかっていないような奴が、
偉そうにタスクシステムとオブジェクト指向を比較する
このスレってなんなのよ

575 ：名前は開発中のものです。：2007/11/21(水) 03:43:36 ID:A/IsnB6U

部分を見て全体を語るバカは消えろ

576 ：名前は開発中のものです。：2007/11/21(水) 03:53:26 ID:cQXGr6XX

>>575
じゃあ>>574を「奴ってなんなのよ」に変えるw

577 ：名前は開発中のものです。：2007/11/21(水) 04:00:31 ID:M0cAZzvh

人を批判するんじゃなくて意見を批判しろよ

578 ：名前は開発中のものです。：2007/11/21(水) 07:21:16 ID:U87PpE2S

>>563
C使いというか、もともとはアセンブリ言語の時代に出てきた話だよな。
メモリも少ない、C++のような言語処理系による多態のサポートもない
80年代なら適切な手法だったとは思うよ。

579 ：名前は開発中のものです。：2007/11/21(水) 07:53:48 ID:UJikmbN+

CS機でC++が安定したのは2000年を過ぎた辺り。
あの名作も！あの大作も！思い出の作品も！
半分くらいは大嫌いなタスクシステムで作られております。

580 ：名前は開発中のものです。：2007/11/21(水) 08:22:38 ID:uKQ7oJIx

>>579
まちがい
タスク派は声がでかいだけで実は少数派
フツーは>>535で組む

581 ：ただの受験生・・・・：2007/11/21(水) 08:45:23 ID:Eii7i8ot

自分は正直、未だにタスクシステムがイマイチなんだが・・・
普通に関数ポインタやクラス処理でやるだけじゃ何か問題あるのか？

なんか、面倒な事してるわりには内容が微妙と言うか
普通にスマートな方法で進めたほうが保守も開発も設計も楽じゃないの？
ABAさんの所意外で、お勧めのコードとかあったらぜひ教えて欲しい。

582 ：名前は開発中のものです。：2007/11/21(水) 09:00:16 ID:rGdz/3mh

>>580
改めて聞くけどmove_enemyの中はどうなってんの？

583 ：名前は開発中のものです。：2007/11/21(水) 09:07:49 ID:rGdz/3mh

あ、別人か、失敬。まあ別に誰でもいいんだけど
>>535で普通に組む人のmove_enemyの関数の中がどうなってるかは知りたい。
ていうか俺も>>535で普通に組むけどな。

584 ：名前は開発中のものです。：2007/11/21(水) 09:20:50 ID:3I3vCjH2

void move_enemy()
{
　for(i=0;i<MAX_ENEMY;++i)
　　listEnemy[i]->move();
}

ってなってんだろどうせ
>>546とどう違うのかわからんが

585 ：名前は開発中のものです。：2007/11/21(水) 12:38:25 ID:uKQ7oJIx

お好きな方法でどうぞとしかいえない
作るモンによって柔軟に変えたほうが楽

586 ：名前は開発中のものです。：2007/11/21(水) 14:00:00 ID:3I3vCjH2

>>585
ただ関数名並べただけじゃねーか
実装も書かずに何が「正解」だ死ねボケ

587 ：名前は開発中のものです。：2007/11/21(水) 14:22:45 ID:UJikmbN+

こうして宗教戦争は激化していくんだな。

588 ：名前は開発中のものです。：2007/11/21(水) 14:50:48 ID:AzYiiqGh

いや、つりしてるやつが一人だかいるっぽいな
まあだいたい死ねボケだのバカかあんただの
文末につけとけば勝手にヒートアップしてくれるよ最近の人は
技術系のスレが勢いで一着をとるなんてすばらしいじゃないか
一人でやってろｗ

↑こんなかんじで

589 ：名前は開発中のものです。：2007/11/21(水) 14:55:52 ID:Vcv4RdfS

宗教っていうか
教養ゼロ視野偏狭のタスクシステム厨が一方的に殺戮されてるだけだろ

＞関数アドレス(orインデックス番号)入りワークメモリのリスト構造

こんな道端の石コロみたいな実装にわざわざお名前付けて
「これ凄い！独創的！」「ゲーム業界が生み出した至宝！」
とか叫んで世の中に触れ回ってりゃ、そりゃ馬鹿にされるわな

590 ：名前は開発中のものです。：2007/11/21(水) 15:07:22 ID:UJikmbN+

お兄さんは誰と戦ってるの？

591 ：名前は開発中のものです。：2007/11/21(水) 15:09:35 ID:Vcv4RdfS

お魚と戦ってるんだよ

592 ：名前は開発中のものです。：2007/11/21(水) 15:25:03 ID:7oe1EO6y

>>535を普通にC++で使えるようにするとこんな感じだろうか。
ところでこれってタスクシステムなん？

class IEnemy { ... };
class EnemyContext { ... };

class EnemyManager {
public:
　void update(EnemyContext &ctx) {foreach(e in m_enemies) {e.update(ctx); } }
　void draw()(EnemyContext &ctx) {foreach(e in m_enemies) {e.draw(ctx); } }
private:
　sorted_list<IEnemy*> m_enemies; // 優先順位でソートする
};

int main() {
　EnemyManager enemyManager;
　Player player;
　...
　while (loop) {
　　backgroundManager.update(BackgroundContext(...));
　　player.update(PlayerContext(...));
　　enemyManager.update(EnemyContext(...));
　　effectManager.update(EffectContext(...));
　　clear();
　　backgroundManager.draw(BackgroundContext(...));
　　enemyManager.draw(EnemyContext(...));
　　player.draw(PlayerContext(...));
　　effectManager.draw(EffectContext(...));
　　wait();
　}
}

593 ：名前は開発中のものです。：2007/11/21(水) 19:41:22 ID:VfU3BH7w

>>592
君、C++書いたことないだろ…。
他言語の激しい臭気が混ざっていて、吐きそうになった。

594 ：名前は開発中のものです。：2007/11/21(水) 19:45:29 ID:nY+5zEHH

boost::って書いとけばそれなりにC++っぽく見える気がする（ｗ

595 ：名前は開発中のものです。：2007/11/21(水) 20:11:53 ID:SZbRSKhJ

言うに事欠いて仮想コードの文法に
因縁を付けるしかないとは。。。

タスクシステム厨共、詰んでんな

596 ：名前は開発中のものです。：2007/11/21(水) 20:14:08 ID:U87PpE2S

>>594
>>584をC++っぽくすると、こうですか？(＞＜)

std::for_each(listEnemy.begin(), listEnemy.end(), boost::bind(&Enemy::move, ::_1, this));

597 ：名前は開発中のものです。：2007/11/21(水) 21:34:16 ID:IRnrhrcc

言うに事欠いてオブジェクト指向の三要素すら
わかっていないとは。。。

アンチタスクシステム厨共、詰んでんな

598 ：名前は開発中のものです。：2007/11/21(水) 21:54:50 ID:k+2FhM2A

>>597の投げたブーメランが次々とタスクシステム狂信者の首をハネてる光景が
見えるんだがこれはきっと俺の気のせいに違いない！

599 ：名前は開発中のものです。：2007/11/21(水) 22:03:46 ID:IRnrhrcc

そうだろう。

600 ：名前は開発中のものです。：2007/11/21(水) 22:31:24 ID:rGdz/3mh

>>585
move_enemyの中にタスクシステム使ってても正解なんだな？
お好きな方法でよいんだろ？

601 ：名前は開発中のものです。：2007/11/21(水) 22:32:19 ID:y72QUY/t

＞600
もう構うなよ、ただの荒らしだったんだから

602 ：名前は開発中のものです。：2007/11/21(水) 22:35:30 ID:TJbMhPVF

とりあえず、タスクシステム狂信者とかタスクシステム厨というのは

関数ポインタ付きワークのリストとかいう割とどうでもいい仕掛けを
タスクシステムなどと命名して憚らない井の中の蛙のことだと理解した

603 ：名前は開発中のものです。：2007/11/21(水) 22:55:07 ID:nY+5zEHH

要はシングルタスク環境でのマルチタスクのエミュレーションでしょ
だから(シングルタスク環境でマルチ)タスク(のエミュレーションをする)システム
ほらこれで違和感なくなる

604 ：名前は開発中のものです。：2007/11/21(水) 22:59:37 ID:U87PpE2S

>>603
全然違うが…

UNIX V6 や MINIX ぐらいの小さいヤツでも良いから、OSのコード読んだことあるか？

605 ：名前は開発中のものです。：2007/11/21(水) 23:03:05 ID:nY+5zEHH

無いよ
ちなみに環境ってのはOSを指してるわけじゃないよ

606 ：名前は開発中のものです。：2007/11/21(水) 23:18:49 ID:U87PpE2S

>>605
シングルタスク/マルチタスクという文脈でタスクという言葉を使う場合、最低でも
タスク固有のリソースとしてレジスタとスタックぐらいは持つのがふつーじゃない？
低機能なモニタだと、データ領域やヒープは共有の場合もあるけど。

タスクのスケジューリングや、スタック切り替え、レジスタの退避・復元をやらない
となったら、単なる関数呼び出して、わざわざタスクなんて名前付ける実体が
何もないし。

607 ：名前は開発中のものです。：2007/11/21(水) 23:22:07 ID:Vcv4RdfS

>>603
紙飛行機を手に山手線の中を走り回って
「これステルス戦闘機だよ！ステルス機！」と乗客たちに真顔で叫べ

>>605
和書でもいいからRTOSの本でも一冊読んだほうがいいと思われる

608 ：名前は開発中のものです。：2007/11/21(水) 23:31:40 ID:7oe1EO6y

>>593
C++書いたことありますよ。ちなみにこれは
foreach(e in m_enemies) {
　↓
BOOST_FOREACH(IEnemy *e, m_enemies) {
で実際に動くようになるんですが、
これだと妙にこいつが存在を主張しやがるんで、やめました。

609 ：名前は開発中のものです。：2007/11/21(水) 23:32:51 ID:nY+5zEHH

とりあえず挙げられたMINIXのソースとそれOS関連の本読んで出直します m(__)m
コード読んでるだけじゃデータの構造ぐらいしか分からなかったわ

610 ：名前は開発中のものです。：2007/11/21(水) 23:33:03 ID:U87PpE2S

>>607
> 和書でもいいからRTOSの本でも一冊読んだほうがいいと思われる
俺は、タネンバウム先生の「オペレーティングシステム -設計と理論および
MINIXによる実装」を勧めておこう。

コード読むなら、マイクロカーネルの L4 あたりがお手頃。

611 ：名前は開発中のものです。：2007/11/21(水) 23:44:08 ID:Vcv4RdfS

それ定番だけど絶版だべ
モダン～のほうはアマゾンでも買えるけんど

612 ：名前は開発中のものです。：2007/11/21(水) 23:48:34 ID:U87PpE2S

>>611
マジ？　ヘネパタ本とかも絶版にならんだろうな……

613 ：名前は開発中のものです。：2007/11/22(木) 00:16:34 ID:blZKzYk7

しかしなんでいちいちつっかかるのかね？

＞関数ポインタ付きワークのリストとかいう割とどうでもいい仕掛けを
関数ポインタ付きワークという仕組みを、構造化プログラムが流行るより前に編み出したからこそ素晴らしかったんだろ
アルミニウムは昔、黄金より高かったんだぜ？

614 ：名前は開発中のものです。：2007/11/22(木) 00:44:52 ID:Ks9LgXrZ

新説！構造化プログラミングはタスクシステムのパクリだった！

615 ：名前は開発中のものです。：2007/11/22(木) 01:02:49 ID:yipIIsDo

少し落ち着いたか

616 ：名前は開発中のものです。：2007/11/22(木) 07:22:05 ID:jwSfKsPE

>>613
http://minnie.tuhs.org/UnixTree/V6/usr/sys/tty.h.html

1975年5月にリリースされた UNIX V6 の TTY デバイスドライバのコード。
struct tty 参照。あと cdevsw とかも見てみ。

時代的には 1979年に出たギャラクシアンより前だぜ。

617 ：616：2007/11/22(木) 07:27:01 ID:jwSfKsPE

書いてから気づいたが tty は関数ポインタ使ってなかった。だいぶ
耄碌してるな orz

http://minnie.tuhs.org/UnixTree/V6/usr/sys/systm.h.html
http://minnie.tuhs.org/UnixTree/V6/usr/sys/conf.h.html

代わりに、このへんでよろしく。

618 ：名前は開発中のものです。：2007/11/22(木) 07:45:52 ID:tr1HPVJM

>>581
実は、今のプロジェクトは、ABA氏のソースも参考にしてたのだが、
あれは、オブジェクトPool そのものなので、
パーティクルなどの単純でたくさん出現するエンティティには、有効なのだが、
複雑なエンティティ（個別にたくさんのメンバーを持ったり、もしくは、継承したり、
または、コンポジット的に複数のオブジェクトを併せ持ったようなの）
には不向きなのだよね・・・。

で、結局、複雑なエンティテイ用には、オブジェクトPoolではなく、
汎用list + 動的生成で、作り直してしまっている orz

まあ、前は、それでやってたから、いいんだけどねｗ

>>592 を詳しくしりたいなあ・・・
俺は、C++使いではないので、他の他言語臭さが混じっても全然問題ないんだけどｗ
boostとか、本質でないので、どうでもいいというか

Contextって、グローバル変数を使わないために、引数をラッピングしたもの？
ということでいいんですよね。

Playerが、EnemyManagerほしくなったら、PlayerContextにenemyManagerつっこんで渡す？
という感じなのでしょうか？

以前、引数でコンテキスト渡しをやったことがあるのですが、
たらい回しになってしまい、嫌になってしまった覚えがあります。
結局、グローバル変数にまとめてしまう罠。
似たようなことをやっている方はどのように、解決しているのかなーと。思います。

>>593
C++以外も多めに見てやって下さい

619 ：名前は開発中のものです。：2007/11/22(木) 08:34:41 ID:/RmxASqP

何かにつけて叩くやつがいるね。

俺としては色々な実装を見れるようなスレになってほしいな。
各々が自分はこうやってるというのを示して、それを見た人が取捨選択すれば良いのだけれど、
現状では、実装晒し→叩き、の流れになりそうだね。

620 ：名前は開発中のものです。：2007/11/22(木) 09:02:49 ID:yipIIsDo

>>618
＞Playerが、EnemyManagerほしくなったら、PlayerContextにenemyManagerつっこんで渡す？

ほんとにEnemyManager本体を取得する必要があるのか検討したほうがいいかも。
実際にはEnemyManagerの1つのメソッドを呼びたいだけとかconstでいいとか色々あるはずなんで…
だからPlayerContextは純粋仮想関数のインタフェイスにして、必要最小限のものだけ記述する。

まあ、処理のたらいまわしであることについては間違いないし、
Context実装するのも面倒くさいんだけどね…

621 ：名前は開発中のものです。：2007/11/22(木) 09:44:56 ID:iT4MLKru

>>617
んじゃ「ゲーム業界で働く一般プログラマに普及させた」でもいいや
とりあえず昔の功績を今の価値基準で裁くなって言いたいだけだし

622 ：名前は開発中のものです。：2007/11/22(木) 09:53:30 ID:yipIIsDo

>>595は文脈からして
>>595はタスクを使わなくて、>>592の形式で書いているんだよね？

多分>>595は、メインループの
　　enemyManager.update(EnemyContext(...));
とか
　　effectManager.update(EffectContext(...));
みたいな各要素をタスクにするのは厨だと考えているけど
そのマネージャの中の実装には言及していない。

逆にタスクシステム使ってるよ派の人は、
そもそもそんな要素はタスクになり得ないし、
マネージャの中の実装にタスクシステムを使っている
(オブジェクトをタスクとして扱う)と言う。

結局同じもの指してるようにしか見えないけどねぇ

623 ：名前は開発中のものです。：2007/11/22(木) 10:05:42 ID:iT4MLKru

結局のところ、
・複数のオブジェクトをリスト形式で管理する
・毎フレーム、リストに登録されている全てのオブジェクトでUPDATE処理を行なう
のがタスクシステムなんだから、結局は同じものを指すことになるだろ

「一部のオブジェクトは毎フレーム呼ばれるわけじゃない！」とかくらいはあるかもしれんが

624 ：618：2007/11/22(木) 10:50:21 ID:tr1HPVJM

>>620
ああ、わかりました。

逆の例の方がいいか。
EnemyManagerの中のEnemyが、Playerの現在位置を取得したかったら、
例えば、PlayerContext.getPlayerPosition()なるメソッドを作り、
PlayerContext（=interface）を作って、Playerはそれを実装し、
EnemyManager経由で、PlayerContextを渡すということですね。

以前に、どこかでプログラマーさんのページで、
タスクシステムの代わりにこうやるんだ、という、
これとほとんど同じのコンテキストを使った、最小限のソースを見た覚えがあるのですが、
昔ダウンロードしたはずのHDDの中には、見つけられず orz

2000年前後の日記かブログだったか・・・
「タスクシステム Context ゲーム」あたりで検索しても、見つけられず・・・
ページ自体消滅したのかも。

625 ：618：2007/11/22(木) 11:12:47 ID:tr1HPVJM

やっと見つけてきた。
レスくれた人サンクス。

ゲームにおけるデータ構造・クラス設計・パターン
http://pc11.2ch.net/test/read.cgi/gamedev/1155209226/

このスレ経由で、
http://www.issei.org/blog/archives/000225.html
ここに、ありましたです。

てか、この話題、上のスレで語られてて、
しかも、質問してたのも俺だたｗ

626 ：618：2007/11/22(木) 12:49:53 ID:tr1HPVJM

>>624間違いでした orz
この話の場合、
EnemyManager に渡すのは、EnemyContext ですね。
プレイヤーの位置情報なら、 EnemyManager.getPlayerPosition() か？

（HogeManagerとかの塊りな）グローバル変数の参照と比べて、
Context渡しの考えられる特徴は、

・いちいちブリッジ処理を書く必要があるのが面倒
　ちょっとした、オブジェクトの状態の参照も、Contextに書いて、
　Contextを実装するManagerに処理を書く必要がある。

　Enemyが自機座標を得たい場合、
　Player.getPosition()と書くところを、（まあ、CPlayer.getInstance.getPosition()でもいい）
　・EnemyContext.getPlayerPosition()を宣言
　・Manager.getPlayerPosition() 実装
　　なかみは、Manager.m_player.getPosition() でいいのか？
　が必要

・依存性を切り離しやすい
　・単体テストがやりやすい。
　　実際、グローバル変数管理だと、単体テストなのに、本体全部ごとコンパイルする必要があったり。
　　上記の場合、生成してないオブジェクトの null チェックをしたり等の気配りが必要。
　・部分部分で独立して、ツールなどを作りやすい
　　のかなぁ？

想像力が足りないので、
あとの問題は、大きなプロジェクトで使ってみたいとわかんないや('A`)
他にあったら、教えてほしい。
実際使っている人とか。

一応、疑似タスクシステムの代替案ということで、スレ違い？の話題ではないと思います。

627 ：名前は開発中のものです。：2007/11/22(木) 20:03:53 ID:iT4MLKru

class ITask
{
　static HANDLE system_counter = 0;

　HANDLE m_counter;
　bool m_killFlg;
　ITask():m_counter(++system_counter),m_killFlg(false){}
public:
　HANDLE getHandle()const{return m_counter;}
　bool getKillFlg()const{return m_killFlg}
　void kill(){m_killFlg = true;}

　virtual void task(void *p) = 0;
　virtual void draw(void *p)const = 0;
};
class CTaskManager
{
　std::map<HANDLE, ITask* > m_list;
public:
　void task()
　{
　　foreach(m_list.begin(), m_list.end())
　　　it->task(this);
　}
　void draw(){(省略)}
　void kill(){(getKillFlg()がtrueを返す奴らをリストから削除)}

　CPlayerTask *getPlayerTask(HANDLE handle);
　CEnemyTask *getPlayerTask(HANDLE handle);
};

628 ：名前は開発中のものです。：2007/11/22(木) 20:07:32 ID:iT4MLKru

ネタ振りな。超最低限のタスクシステムの実装
・Taskは自殺するとき、killFlgを利用してManagerに削除してもらう
・HANDLEを使うことで、ポインタと違ってTaskからTaskへの参照が安全になる（既に死んでたらNULLが返る）
・taskの引数わvoid*でいいわ。キャストしろ

リストがmapだったり、そこに入れるのが生ポインタだったり、foreachとかいう構文は、説明のための簡略化な

629 ：名前は開発中のものです。：2007/11/23(金) 00:36:57 ID:j4mzysAq

で、どうしろと？

630 ：名前は開発中のものです。：2007/11/23(金) 00:47:13 ID:62aAVQ/a

このスレの流れを追ってると、タスクとかタスクシステムというものがこのスレの中で
どんどん拡大解釈され再定義されているように見えるけど、これ混乱の元だと思う

一次ソース（オリジナルのタスクの開発者の証言なり文書、各自でアケ基板のROMを
ぶっこ抜いて各自で解析した結論)を各自が持たない＝まともな出典がどこにもない
というのはやはり致命的だと思う

ネットに流出した情報の中で、俺が大昔に実際に見聞きしてきたものと附合する点が
一番多かったのはLogician Lordというサイトだったのだが、どうもこれは消失してるみたいだ
http://web.archive.org/web/20041009222313/www.hh.iij4u.or.jp/~peto/Games/games_top.html

631 ：名前は開発中のものです。：2007/11/23(金) 01:19:42 ID:62aAVQ/a

それと、このスレで使われるタスクっていう単語は、所詮は社内的なローカル用語と
理解したほうがいいと思う

これを拡大解釈して再定義して一般に浸透させようとする試みは
オペレーティングシステムで既に浸透している「タスク(プロセス)」、「マルチタスクシステム」
といったキーワードの定義との矛盾によって必ず混乱し失敗する

632 ：名前は開発中のものです。：2007/11/23(金) 01:24:24 ID:BEEU5ypU

そろそろ収束か。
今回は割りといい感じで終われた気がするｗ

633 ：名前は開発中のものです。：2007/11/23(金) 01:44:28 ID:sTtLbUbQ

>>626
あと利点としては、プレイヤーが死んだときにインスタンス delete しちゃう
ような場合に、

> Player.getPosition()

だと dangling pointer 参照で死ぬけど、それをマネージャレベルで隠蔽できる。

> ・依存性を切り離しやすい
ツールに関しては、たとえばエフェクトを対話的に作成するようなツールを作る
ときに便利。実際の例だと、キャラクタにくっつくようなエフェクトを作りたいという
話が出てきて

// 本番ゲームシステム
class Manager : public ICtxEffect { };
// エフェクト対話的編集ツール
class EffectEditor : public ICtxEffect {};

みたいな実装にして、同一バイナリでゲーム本番処理とエフェクト編集処理と
両方組み込んで、それなりに動くようにしたり。

634 ：名前は開発中のものです。：2007/11/23(金) 07:38:56 ID:5cQAXJ2k

タスクシステムがバグる原因は>>535をタスクで表現するのが非常に困難だからだ
それに気が付きにくい
たったこれだけでもプライオリティ付けてソートしなきゃなんねーし
多くの奴がこの関連部分の管理が頭に入ってない
一番複雑になるのはここなのにここの管理に目を向けない

635 ：名前は開発中のものです。：2007/11/23(金) 07:46:10 ID:t28kGfzr

the game loopって呼び方があるんだなぁ
なんとなく検索したら色々ひっかかってびっくりした
これの実装例も検索で見つかるかな？

636 ：名前は開発中のものです。：2007/11/23(金) 08:53:11 ID:6Q/wgBBZ

タスクシステムとＣ＋＋って別物ですか？
ゲームはほとんどＣ＋＋で作られていると聞いていたので気になりました。

637 ：名前は開発中のものです。：2007/11/23(金) 08:56:29 ID:sTtLbUbQ

>>636
少しは過去ログ嫁

638 ：名前は開発中のものです。：2007/11/23(金) 09:09:46 ID:6g4wMaBN

>>627
自殺フラグかっこわるいな
task()の返値でそれを一生最後のtask()実行にするかどうか判定されるように
してみたらどうなのか

639 ：名前は開発中のものです。：2007/11/23(金) 09:36:35 ID:BEEU5ypU

>>634
そこにタスクシステム使わなきゃいいじゃん

640 ：名前は開発中のものです。：2007/11/23(金) 10:48:40 ID:4/POEhpT

>>638
・そうするとタスクマネージャ側で死亡タスクを記録する必要がある（全員のtaskを呼んでから殺すために）
・自殺フラグがあれば、死ぬタスク（ボス）を参照しているタスク（雑魚）が、ボスの死亡を検知できる

当然雑魚はボスより処理プライオリティを低くしておく
>627にはその機構までは書かなかったけど、ボスを先に生成するようにすれば問題ない

641 ：名前は開発中のものです。：2007/11/23(金) 12:45:03 ID:zjg9deXc

かっこ悪いとか関係あんの？
目的の動作をスマートに分りやすく実装できればどうでもいいと思うんだけど。

642 ：名前は開発中のものです。：2007/11/23(金) 16:06:58 ID:sTtLbUbQ

>>641
かっこ悪い＝スマートじゃない

同じコト言ってるようにしか見えない

643 ：名前は開発中のものです。：2007/11/23(金) 17:27:38 ID:6g4wMaBN

>>640
＞死亡タスクを記録する必要がある
まったくそのとおりだけど自殺フラグが記録してた分と相殺できないかなあ
＞ボスを先に生成するようにすれば問題ない
居心地の悪さがさらにプラスされてるような…
ハンドル引いて調べるのじゃ駄目なの？それで間に合わんようなクリティカルな
機能ならなおさら自殺フラグを勝手に代用すべきじゃないと思うんだ

644 ：618：2007/11/23(金) 18:24:31 ID:RNrXHefy

俺は、自殺フラグは使ってるな・・・
削除は、イテレート中(foreach中？)の扱いがめんどい
あとで、ガーベジコレクトと称して、リストから、フラグ立ってるのを削除というよくあるパターン。

それでも、他のタスク(エンティテイ)参照する場合は、不正な参照問題のためにいわゆる、
ハンドルで間接参照するけど。

>>633
㌧
>> Player.getPosition()
>だと dangling pointer 参照で死ぬけど、それをマネージャレベルで隠蔽できる。

アー、それだと、ハンドルとかスマートポインタを使う必要すらないのかー。
なるほど・・・

> // エフェクト対話的編集ツール
実は、対話的編集ツール自体がわかってなかったりするんですが、
実機で動く、簡易GUI付きの、パラメータをぴこぴこ弄ったりできる
（最終的にパラメータを出力するような）ツール？ということでしょうか。

つか、あれか、たまに、ゲームの裏ワザのデバッグ画面とかで見れる、
エフェクトとか、モーションとかだけ、再生できるあれの編集できる版？

うちは、スクリプトか、コード直書きでしか、エフェクト作ってなかったりしてｗ

645 ：名前は開発中のものです。：2007/11/23(金) 18:24:43 ID:5cQAXJ2k

よくわからんがインスタンスの存在の有無をゲームオブジェクトが参照するのはダメだぞ
ボスが死んだはボスのステータスだろ？

646 ：名前は開発中のものです。：2007/11/23(金) 18:35:30 ID:sTtLbUbQ

>>644
> > // エフェクト対話的編集ツール
> 実は、対話的編集ツール自体がわかってなかったりするんですが、
> 実機で動く、簡易GUI付きの、パラメータをぴこぴこ弄ったりできる
> （最終的にパラメータを出力するような）ツール？ということでしょうか。
Yes

これ作っておくと、デザイナさんだけで作業進められるので楽だよ。

647 ：名前は開発中のものです。：2007/11/23(金) 19:10:50 ID:hpN6XUeQ

>>643
ボスを先に生成するようにすれば～は、プライオリティ機構が無い場合の代替案。
実際はプライオリティ機構を作るよ

ハンドル引いて死亡を調べる方法も問題はないが、1フレーム挙動が遅れる。
問題があるかどうかはゲームしだい。

648 ：名前は開発中のものです。：2007/11/23(金) 19:19:52 ID:5cQAXJ2k

ヘタクソにもほどがあるな
クリア条件を雑魚の80パーセントが死んだらとか
ちょっとした仕様変更でも死にそう
根本の定義にプログラム言語の都合を入れるからおかしくなってる感じがする

649 ：名前は開発中のものです。：2007/11/23(金) 19:22:45 ID:BEEU5ypU

C++的なインスタンスの死亡と
ゲーム的なインスタンスの死亡を
同一視してる時点で問題

650 ：名前は開発中のものです。：2007/11/23(金) 19:33:39 ID:RPahHia5

>>648
は？
クリア条件を管理するTaskはどこにも示されていないのに、なに仮想的と戦ってるの？ｗ

>>649
同一な時もあれば、同一でない時もある。
同一でない時に同一視したら問題だが？

651 ：名前は開発中のものです。：2007/11/23(金) 19:42:58 ID:5cQAXJ2k

ある時点でダメなんだよ
このヘタクソ
言い訳ばっかりしやがって
ゲームのシステムにプログラムの都合が入ってる設計がクソだって言ってんだろ

652 ：名前は開発中のものです。：2007/11/23(金) 19:45:01 ID:RPahHia5

・何が「ある」のか不明
・何が「ヘタクソ」なのか不明
・どこが「言い訳」なのか不明
・どこが「プログラムの都合」なのか不明

明示的によろしく

653 ：名前は開発中のものです。：2007/11/23(金) 19:52:50 ID:5cQAXJ2k

また言い訳
ホントはなんのことかわかってるのにわざとはぐらかす
こういう奴は自分の設計の間違いに気が付いてるのに絶対修正しない
だから著しくレベルが低い
適切に間違いを指摘されてるのに言い訳に言い訳を重ねる
弱すぎ
自分の常識が覆されることを怖がってる臆病者
プログラム以前の問題

654 ：名前は開発中のものです。：2007/11/23(金) 20:06:37 ID:hpN6XUeQ

いつもの奴か。素直にやり方教えてくださいって言えば教えてあげるよ。

素直にtaskの引数で勝利条件管理クラスへのポインタを渡せばOK
死ぬときに勝利条件管理クラスへ「俺死にました」って通知すればいいよ

え？いままで作った（死を通知しない）雑魚を使いまわしたい？
贅沢な奴だなぁ
それなら、雑魚を管理するタスクを作ろうね
例えば100体雑魚が出て、そのうち80%を倒したらだとするよ。

100体生成時にそれらへのハンドルを持つ雑魚群管理タスクを作る。
状態を見張って死をカウントしたらいいね。
プライオリティを下げて「自殺フラグ」を見てもいいし、ハンドルの失効を見てもいいよね（死ぬ以外でも失効する場合は駄目ね）

655 ：名前は開発中のものです。：2007/11/23(金) 22:03:22 ID:6g4wMaBN

>>654
翻訳してみたよ

＞task()への引数で勝利条件を管理するクラスへのポインタを渡し、
＞死ぬタイミングをそこへ報告すればいい

うん、多分>>654を責めてる人は直接エンティティを参照するのが
悪いっていってるわけじゃないよ誤解のある書き方だったかもしれんが
エンティティのライフタイムを制御するはずの自殺フラグを
ゲームの体裁の制御に利用すんなっていってるんじゃないかな

ゲームオブジェクトのメモリ上の寿命とゲームの体裁上の寿命は
一致するほうが珍しいんだから

それ以下は蛇足だな
誰もそんなこと訊いてないんだし
＞いままで作った（死を通知しない）エンティティをそのまま使いたいときは
＞それらを管理するタスクを新たに設ければいい
＞…１００体うんぬんかんぬん

656 ：名前は開発中のものです。：2007/11/23(金) 22:13:50 ID:hpN6XUeQ

使える時は使えばいいし、使うべきでないときは使わなければいい
ただそれだけの話
なのに自分の脳内ゲームに当てはまらないからと罵倒語並べてくるのはおかしい

657 ：名前は開発中のものです。：2007/11/23(金) 22:16:19 ID:RPahHia5

5cQAXJ2kと6g4wMaBNは同一人物か、同程度の馬鹿だろ…
相手するなよ
どんなゲームにも当てはまる超汎用的タスクシステムなんていう夢を追いかけてんだろ

658 ：名前は開発中のものです。：2007/11/25(日) 18:37:47 ID:kzcKTOJ0

超汎用的タスクシステムは滅びぬ！
何度でも蘇るさ！

659 ：名前は開発中のものです。：2007/11/25(日) 20:07:18 ID:eCkVPP3v

脳内定義で薀蓄垂れられても困る…
そりゃ、>>652と同じ疑問を持つ人もいるだろう
俺も同じだよん

660 ：名前は開発中のものです。：2007/11/25(日) 23:33:52 ID:H/hr6nVT

まぁ、何度も言われてる通り
ここで話題に出る「タスク」「タスクシステム」というのはローカル用語だからな。
つまり「A Task」「A Task-System」ではない

よって赤の他人同士の会話の中で何の説明も無しにただ単に「タスク」とか
「タスクシステム」とか叫んでも理解されない。（理解されてはならない）

最大限に脳内補間して解釈してやるなら、ギャラクシアンとその直系の実装に
与えられる固有名詞のことを言ってるのだな、と理解されるだろう

この場合は「The Task」「The Task-System」だ

ギャラクシアンとその直系の実装以外の最発明や再定義や俺解釈の亜種珍種奇形は
世間的には「The Task」「The Task-System」ではないし、「A Task」「A Task-System」
でもない

661 ：名前は開発中のものです。：2007/11/25(日) 23:37:50 ID:YyuP5gsO

おかしいのは分かったからそれに変わる管理方法教えてくれよ

662 ：名前は開発中のものです。：2007/11/25(日) 23:46:26 ID:kzcKTOJ0

管理と言えば鞭だな。
タスクどもを柵の中に集めて、言うことを聞かなタスクどもには鞭を打つ。
飴と鞭、という言葉があるが、あれはもう過去のものだ。
現代のタスク、そして低学歴を統率するために必要なのは、鞭と鞭だ。

663 ：名前は開発中のものです。：2007/11/25(日) 23:50:24 ID:YqcdiWMr

タスクシステムなんて捨てて、C++で書けば良い。
自然とタスクシステムを包含しかつ凌駕するソースコードが現れ出でるだろう！

てか、タスクシステムってC言語ベースの観念だよねｗ
タスクシステムタスクシステムって連呼する奴ってC++以降失敗組？？？

664 ：名前は開発中のものです。：2007/11/25(日) 23:55:03 ID:da6/lWYV

>>663
既存の言語仕様にのっとって記述するのを良ししない連中。

どれもこれもオブジェクト指向言語ばっかりだからな。

665 ：名前は開発中のものです。：2007/11/25(日) 23:55:08 ID:tx3G2xtz

>>660
否定文を使わずに文章を書く練習をしましょう。

666 ：名前は開発中のものです。：2007/11/25(日) 23:56:42 ID:nB9FNcfG

>>661
>>535

667 ：名前は開発中のものです。：2007/11/25(日) 23:59:26 ID:H/hr6nVT

＞C言語ベースの観念
＞C言語ベースの観念
＞C言語ベースの観念
＞C言語ベースの観念

日本語でおｋ

668 ：名前は開発中のものです。：2007/11/26(月) 00:04:16 ID:O0gpbRD6

>>665
くやしいのうｗｗｗｗ

669 ：名前は開発中のものです。：2007/11/26(月) 01:01:07 ID:jBUDnBWR

今日も皆さんお元気ですねぇ

>>666
move_enemyの中はどうやって管理するの？
って何度も上で出てるんだけど>>666にも聞いておこうか

>>664
多分言いたいことはエスパーで分かったので、
単なる揚げ足になる気がするけど、あえて指摘する

既存の言語仕様に則って記述するかどうかって
関数ポインタで実装せずに仮想関数で実装するかどうか、
みたいな話を言ってるように見えるんだけど
まさかそういうことじゃないよね？

670 ：名前は開発中のものです。：2007/11/26(月) 01:24:22 ID:NdLrwaPc

>>669
俺は敵一匹の毎処理のつもりで言ったから管理も糞もないよ
同じ種類の複数の敵がいるならループで数だけ回せばいいんじゃない？
なんでこんな簡単なこと聞くのかさっぱりわからないけど
何を想定してる？

671 ：名前は開発中のものです。：2007/11/26(月) 01:34:15 ID:uBlNGAN9

>>669
一例を挙げると、タスクシステムを現在存在するオブジェクト指向言語の仕様と併用すると、問題になるのが、タスクの生成および終了。
タスクをクラスとして定義した場合、タスクの生成および終了を言語的に動的にメモリを確保・解放するか、
オブジェクトプールを作って確保・解放するかを選ばなくてはならない。

現在存在する言語の仕様では、前者がプログラミング的にエレガント。コーディングが楽。
だけど、パフォーマンスが悪いとかメモリフラグメントが生じるとかを嫌がる人達がいる。

そういう人達は、オブジェクトプールを使うわけだけど、既存の言語では、
子クラスのインスタンスは親クラスのインスタンスよりサイズが大きいから、複数種類のクラスのオブジェクトプールが面倒。
わざわざ最大サイズのワークスペースのクラスなり構造体なりを宣言してとか、共用体を使うとかあるけど、エレガントじゃない。
バグが出たときもメモリ領域破壊のバグが多いから、原因が掴めない非常に修正困難なバグに出くわすこと多い。
一応、タスクの種類ごとにオブジェクトプールを作る方法もあるけど、種類が多すぎて非現実的。

というわけで、誰か、言語仕様で親クラスに大きなワークスペースがとれて、子クラスからそこを使えるTaskable Cとかいう言語を作ってくれ。
もちろん3Dじゃないエロゲとかだったらわざわざタスクシステムなんて使わなくていいと思うお。

672 ：名前は開発中のものです。：2007/11/26(月) 01:38:00 ID:uBlNGAN9

って、しゃしゃり出た割にはろくなこと書いてねーな俺。
スルーしてくれ。

673 ：名前は開発中のものです。：2007/11/26(月) 01:41:33 ID:Pf2ldD+c

体言止めをいっぱい使うと文章がかっこよく見えるとか思ってんのかね

674 ：名前は開発中のものです。：2007/11/26(月) 01:45:52 ID:uBlNGAN9

>>673
脳内で、「です」でも「だ」でも補間しとくれ。

675 ：名前は開発中のものです。：2007/11/26(月) 01:46:43 ID:jBUDnBWR

>>670
>>666は「move_enemy」みたいな関数そのものを
タスクとして扱うのはやめろ、と言っているんだよね？
そうでなければ>>535を回答例とするようなレスはしないと思うから。

＞同じ種類の複数の敵がいるならループで数だけ回せばいいんじゃない？

だよね？　それなら多分典型的な実装方法ってこうなるんだよね？

for( EnemyListType::iterator it = enemyList.begin(); it != enemyList.end(); ++it )
　(*it)->Update( dT );

で、こういうのもタスクシステムって言う人も居るようですよ。
(ま、ぶっちゃけ俺もこんなものタスクシステムでも何でもないと思うがなｗ)
タスクという言葉が何を指しているかの違いでしかないんだけど、
こういうときは相手側の定義を想定しておいたほうがいいかなと思うんで…
だから>>535を回答例にするのは良い回答とは言えないんじゃないかね

676 ：名前は開発中のものです。：2007/11/26(月) 01:55:29 ID:NdLrwaPc

>>675
そんなあるんだかないんだかわからん想定の話は止めろ
実際にそういう奴がいたら説明すればいい
お前自身がそう思ってないならこれに関する疑問はもうないってことでいいんだろ？

677 ：名前は開発中のものです。：2007/11/26(月) 01:59:57 ID:jBUDnBWR

>>671
オブジェクトを割り当てる専用のヒープを用意しておけばいいんじゃない？
placement newあたりでぐぐったら幸せになれると思うよ

678 ：名前は開発中のものです。：2007/11/26(月) 02:07:27 ID:jBUDnBWR

>>676
タスクシステムの話と違うところ突っ込むのやめない？
なんかスッキリしないなあ…

679 ：名前は開発中のものです。：2007/11/26(月) 02:15:45 ID:NdLrwaPc

>>678
は？意味不明
俺は具体的に何を答えればよかったの？

680 ：名前は開発中のものです。：2007/11/26(月) 02:28:32 ID:jBUDnBWR

>>679
私の聞き方がものすごく悪かったよ。

for( EnemyListType::iterator it = enemyList.begin(); it != enemyList.end(); ++it )
　(*it)->Update( dT );

これをタスクシステムの実装だと思っている人だとして答えてくれればよかった。

っていうか、もう面倒くさくて答えるのもだるいだろうから、好きにして欲しい
邪魔して悪かった。ごめんね

681 ：名前は開発中のものです。：2007/11/26(月) 07:35:39 ID:MsXImaFY

このスレでもう２～３ループいけそうだな。いい調子だ。

682 ：名前は開発中のものです。：2007/11/26(月) 08:00:30 ID:mRg8odX/

>>664
> どれもこれもオブジェクト指向言語ばっかりだからな。
オブジェクト指向プログラミング言語の何がマズいんだ？

GC必須とかだとゲームだと辛い場面もあるが、C++ の仮想関数なんかは
実装も明らかだし、何も問題なかろう。例外も gcc の SjLj 系だと性能に
悪影響出るけど、VC++ や gcc DWARF2 系なら例外投げない限りは
ほとんど影響ないし。

683 ：名前は開発中のものです。：2007/11/26(月) 09:24:22 ID:PlFjoTQQ

>>680
それをタスクシステムと呼んでるんだよ
>>623

それがタスクシステムと呼ばれるのが気に食わないなら、リスト巡回UPDATE型エンジンとかでもいいが。

684 ：名前は開発中のものです。：2007/11/26(月) 11:54:05 ID:O0gpbRD6

>>683
＞それをタスクシステムと呼んでるんだよ

ローカル（自宅内、社内）用語という認識はありますか？ｗ

685 ：名前は開発中のものです。：2007/11/26(月) 11:58:10 ID:PlFjoTQQ

別に世界でどういわれてるかじゃなくて、このスレ内の話だが？

言葉の定義なんてどうでもいいから、リスト巡回UPDATE型エンジンを>>648のように言った奴はきちんと代替案を書き込めよ

686 ：名前は開発中のものです。：2007/11/26(月) 12:17:58 ID:O0gpbRD6

こういう指摘が出ると「このスレ内の話」とか言い出す人がいるようですが
日記スレじゃなくて仮にも技術ｗスレなんですから、世間で通じない方言を
当然のごとく使うのは失笑の的では？

687 ：名前は開発中のものです。：2007/11/26(月) 12:22:02 ID:O0gpbRD6

何の説明もなしにタスクシステムとか言い出すならせめて
過去発言から自身の思う「タスクシステム」とやらが分かるよう
IDを晒すなり番号コテを名乗るなりしたらどうですか？

688 ：名前は開発中のものです。：2007/11/26(月) 12:55:29 ID:nYw3KX8z

人のプログラムみるときも
癪に障る命名規則だったりインデントだったりしても我慢しなきゃいけないんだ
いちいちくだらんことに文句つけてスレ伸ばすな

689 ：名前は開発中のものです。：2007/11/26(月) 12:57:07 ID:o4MnOpxn

>>685
このスレ内の話って、、、

for( EnemyListType::iterator it = enemyList.begin(); it != enemyList.end(); ++it )
　(*it)->Update( dT );

これをタスクシステムの実装だとする珍説がコンセンサスを得ていたみたいな口ぶりだな

精一杯仲間を増やそうとして『スレ内』とかいうミミッチイ括りを持ち出す奴の脳内では
自分に都合の良い『スレの結論』というものが生成されてるのかね

セコイ真似せずに堂々と「俺の考えたタスクシステム」とでも呼べよ。常に

690 ：名前は開発中のものです。：2007/11/26(月) 13:02:20 ID:PlFjoTQQ

また、方言で会話してる他人の間に勝手に割り込んできて「それは標準語では●●というですよﾌﾌﾝ」系の話かよ。

で、いつになったら実装の話に入るのかね？
リスト巡回UPDATE型エンジンの代わりになるエンジンとは？

691 ：名前は開発中のものです。：2007/11/26(月) 13:11:07 ID:O0gpbRD6

方言で会話してる他人の間に勝手に割り込んで、とおっしゃいますが
方言で独り言を呟いてる一人の人間なので「間」が視認できませんよ

＞リスト巡回UPDATE型エンジンの代わりになるエンジンとは？

SceneGraph world;
(中略)
void Update()
{
　　world.Traverse();
}

692 ：名前は開発中のものです。：2007/11/26(月) 13:12:35 ID:PlFjoTQQ

>>689
＞これをタスクシステムの実装だとする珍説がコンセンサスを得ていたみたいな口ぶりだな

まるでリスト巡回UPDATE型エンジン以外のタスクシステムがこのスレで提案されていたみたいな口ぶりだな
1つ（リスト巡回UPDATE型）しか提案されたことがないのだから、このスレでタスクシステムと言えばそれを指すのが当然だろ

693 ：名前は開発中のものです。：2007/11/26(月) 13:18:43 ID:o4MnOpxn

>>692
とりあえずLogician Lord読めよ
今ネットで入手し得る都市伝説の手掛かりはこれぐらいなんだからさ

タスクシステムとはリスト巡回UPDATEのことである
などという話にはなってないだろ

694 ：名前は開発中のものです。：2007/11/26(月) 13:19:47 ID:iOCgoqG0

Qt等のsignal&slotは関数を登録して
signal<signature> s;
s.connect( function );

それを同じ引数で一気に呼び出すことが出来る
s( arg );

updateを纏めて呼び出すという要求だけならこれが使える

695 ：名前は開発中のものです。：2007/11/26(月) 13:24:50 ID:PlFjoTQQ

>>693
別にここは「タスクシステムとは何なのかスレ」ではないんだが？

>>694
内部的にはリストじゃん
「updateをまとめて呼び出すという別の方法」を要求しているわけではなく、上のほうで誰かが騒いでいた、
「毎フレーム全てのオブジェクトのupdateを呼ぶなんてダサい実装じゃなくて、普通はもっとエレガント」
と言っていたその方法を聞きたいんだ

696 ：名前は開発中のものです。：2007/11/26(月) 13:39:31 ID:o4MnOpxn

>>695
>別にここは「タスクシステムとは何なのかスレ」ではないんだが？

逃げたかｗ

697 ：名前は開発中のものです。：2007/11/26(月) 13:41:00 ID:pjGruOMZ

>>695
>>672で>>671についてはスルーしてくれと言ってるのに、
その方法を聞きたいと言っても出てこないと思うけど？

698 ：名前は開発中のものです。：2007/11/26(月) 13:46:17 ID:PlFjoTQQ

別に672に聞いてるわけじゃないんだが
(本人は皮肉のつもりで書いたのだろうが)>>535とか、それを絶賛した奴とかに聞いてる

699 ：名前は開発中のものです。：2007/11/26(月) 13:48:23 ID:O0gpbRD6

>>695
その調子だと、リストを使うと
「あ、それタスクシステム！タスクシステムだよね！？俺知ってる！」
とか言い出しそうですけど、大丈夫ですか？

＞「毎フレーム全てのオブジェクトのupdateを呼ぶなんてダサい実装じゃなくて、普通はもっとエレガント」

キーワードで検索かけても引っかかりませんよ？誰の発言だよそれ。
タイマー駆動のポーリングでやるかイベントドリブンでやるかって話なら
そんなんモノによるでしょ

グリグリ動くオブジェクト群ならアニメーションさせなくちゃいけないんだから
原則的に毎フレーム更新要るでしょ

700 ：名前は開発中のものです。：2007/11/26(月) 13:50:03 ID:O0gpbRD6

タイマー駆動→別にV-Syncでも可

701 ：名前は開発中のものです。：2007/11/26(月) 13:54:26 ID:PlFjoTQQ

>>546
>>551
>>556
>>559
>>561
>>569
あたりだな

702 ：名前は開発中のものです。：2007/11/26(月) 14:08:37 ID:O0gpbRD6

>>701
＞「毎フレーム全てのオブジェクトのupdateを呼ぶなんてダサい実装じゃなくて、普通はもっとエレガント」

こんな趣旨の発言どこにもないじゃん

703 ：名前は開発中のものです。：2007/11/26(月) 14:13:55 ID:PlFjoTQQ

ログも読めないのなら、会話に参加しなくてもいいよ

704 ：名前は開発中のものです。：2007/11/26(月) 14:19:20 ID:o4MnOpxn

>>701
>>703
>毎フレーム全てのオブジェクトのupdateを呼ぶなんてダサい実装じゃなくて、普通はもっとエレガント

で、どれよ？

705 ：名前は開発中のものです。：2007/11/26(月) 14:24:09 ID:PlFjoTQQ

＞どうやるのか純粋に興味あるから、教えてくれ。
＞全てのオブジェクトを少しずつ更新し、オブジェクトリストを持つ親が同期を簡単に管理できるタスクシステム。
＞とは違う方法で。

＞>>535でできるでしょ

ほんとにログも読めないんだな
ログも他人が他人に行なった返答の一種なんだが、ログ読めなけりゃ俺の返答も読めないだお

706 ：名前は開発中のものです。：2007/11/26(月) 14:25:57 ID:O0gpbRD6

>>535はタスクシステムを体をなしてないじゃん

707 ：名前は開発中のものです。：2007/11/26(月) 14:31:28 ID:PlFjoTQQ

>>706
>>687

708 ：名前は開発中のものです。：2007/11/26(月) 14:31:55 ID:o4MnOpxn

>>705
Logician Lord読めって
それ>>535の組み方した時点で既にタスクシステムじゃないから
中でどんな組み方しようがタスクシステムになりえない

709 ：名前は開発中のものです。：2007/11/26(月) 14:32:40 ID:O0gpbRD6

あー、すまん。今さっきLogician Lord読んできた

710 ：名前は開発中のものです。：2007/11/26(月) 14:39:23 ID:O0gpbRD6

>>707
>>706はLogician Lordに記載されたタスクシステムの解釈で

711 ：名前は開発中のものです。：2007/11/26(月) 14:40:03 ID:PlFjoTQQ

なんだー？
今度は「俺が解釈したLogician Lord的タスクシステム披露会」か？
いつになったらリスト巡回UPDATE型以外のエンジンがでてくるんだか・・・
そんなもの無いなら無いで、不毛に名前論争してるよりリスト巡回型の実装の話でもしようや

712 ：名前は開発中のものです。：2007/11/26(月) 14:41:42 ID:O0gpbRD6

まーた逃げた

713 ：名前は開発中のものです。：2007/11/26(月) 14:44:19 ID:PlFjoTQQ

>>712
お前はさっきから>>691の実装を説明せず逃げ回ってるわけだが

名前論争したいなら俺の負けでいいよ。負け負け。ごめんなさい。
タスクシステムとか曖昧な名前使って悪かった、すまん。ごめん謝ります。あなたが正しい、素晴らしい。俺なんてゴミです。

ですから>>691の実装について解説してね

714 ：名前は開発中のものです。：2007/11/26(月) 14:45:45 ID:O0gpbRD6

結局

＞「毎フレーム全てのオブジェクトのupdateを呼ぶなんてダサい実装じゃなくて、普通はもっとエレガント」

なんて誰も言ってなかったってわけで

715 ：名前は開発中のものです。：2007/11/26(月) 14:47:43 ID:O0gpbRD6

Graph Traverseでいくらでも出てきますよ→実装
これがタスクシステムだと強弁するなら止めはしませんが

716 ：名前は開発中のものです。：2007/11/26(月) 14:49:06 ID:PlFjoTQQ

>>715
その中身を教えて欲しいんだけど
中身がなけりゃ>>691は、ただ関数とクラスと実体に名前つけただけじゃん。知りたいのは実装。
まさか中で「リスト巡回UPDATE型エンジン」を使ってたりはしませんよね？

717 ：名前は開発中のものです。：2007/11/26(月) 14:53:20 ID:o4MnOpxn

>まさか中で「リスト巡回UPDATE型エンジン」を使ってたりはしませんよね？

ヤケクソになってるな、こいつ

718 ：名前は開発中のものです。：2007/11/26(月) 15:04:53 ID:O0gpbRD6

>>716
グラフがリストだと強弁するなら止めはしません

719 ：名前は開発中のものです。：2007/11/26(月) 15:36:21 ID:PlFjoTQQ

グラフがリストの一種ではないと強弁できる理由を知りたいんだが

お前の言うグラフって探索木の一種だろ？
結局全ての要素を呼び出してるだけじゃねーか

「std::listじゃなくてstd::setを使ってます」相当だと言えば分かるか？
アホか。
また「リストとは」とかいう言葉遊びでも始める気か？

720 ：名前は開発中のものです。：2007/11/26(月) 15:41:36 ID:O0gpbRD6

>まさか中で「リスト巡回UPDATE型エンジン」を使ってたりはしませんよね？

言葉遊びでも始める気か？

721 ：名前は開発中のものです。：2007/11/26(月) 15:44:30 ID:PlFjoTQQ

>>720
>>683で明示的に定義されているが？
で、お前のいうグラフってなんだったの？まさか探索木じゃないとは思うから念のため。
定義を明示的に主張するか、参考サイトのURLを張ってくれ

722 ：名前は開発中のものです。：2007/11/26(月) 15:58:59 ID:O0gpbRD6

固定オブジェクト(部屋、portal)で空間分割してる場合
コンパイル済みマップのグラフ走査の実装は配列の
リニアアクセスになる

723 ：名前は開発中のものです。：2007/11/26(月) 16:05:38 ID:PlFjoTQQ

リニアアクセスになるかならないかなんて、今の話にまったく関係無いわけだが？
お前「グラフ走査」って言っちまってるしな
ID変え自演までして長々やって、結論がこれかよ

724 ：名前は開発中のものです。：2007/11/26(月) 16:06:39 ID:iOCgoqG0

むしろ優先度付きのリスト構造へのアクセスが先行制約グラフの走査の一例であって、
グラフの方がより抽象度が高いと思う
あとグラフを基調に考えることでグラフ理論を利用したアルゴリズムが使えるとか
>>691の考え方はこのような利点を踏まえて「代替」ってこと？

725 ：名前は開発中のものです。：2007/11/26(月) 16:10:32 ID:O0gpbRD6

言うに事欠いて自演認定ですか・・・バカの相手は楽しいですね
グラフのTraverseだから横行ですかね。まぁ誤訳ということで

726 ：名前は開発中のものです。：2007/11/26(月) 16:11:13 ID:O0gpbRD6

>>724
はい

727 ：名前は開発中のものです。：2007/11/26(月) 16:19:03 ID:PlFjoTQQ

>>726
このタイミングでお前をかばうように>>724が出てくるわけもねーだろｗ

抽象度が高い？
グラフ理論アルゴリズムが使える？
一体俺とお前の対話の中でのどこに、そんな話を持ち出す要素があったんだよ

お前は
＞リスト巡回UPDATE型エンジンの代わりになるエンジンとは？
という問いに対してGraph Traverseを持ち出したんだろが
なのに何？「はい」って

728 ：名前は開発中のものです。：2007/11/26(月) 16:23:40 ID:O0gpbRD6

駄目だこいつ

729 ：名前は開発中のものです。：2007/11/26(月) 16:26:43 ID:o4MnOpxn

>>723
俺も自演ID認定？
どんだけ被害妄想なんだよ

730 ：名前は開発中のものです。：2007/11/26(月) 16:30:00 ID:O0gpbRD6

タスクシステム厨とか実装乞食っていうレッテル貼りは嫌いだったけど
これからはたまに使おうかと思います

731 ：名前は開発中のものです。：2007/11/26(月) 16:46:46 ID:PlFjoTQQ

>>729
俺一言もお前が自演なんて言ってないけど？
何自爆してんの

>>730
実装乞食も何も、俺の側はすでに実装を明示的に提示してあるじゃん
結局お前が書いた実装って
class COresama ore;
（中略）
void CallOresama()
{
　ore.run();
}
だけなんだが？

732 ：名前は開発中のものです。：2007/11/26(月) 16:51:20 ID:o4MnOpxn

お前に反論する奴はみんな自演なんだろ？ｗ

733 ：名前は開発中のものです。：2007/11/26(月) 16:54:48 ID:O0gpbRD6

乞食って、視野狭いですね
portalとか空間分割とかコンパイル済みマップとか
キーワードをいっぱい散りばめてやってるんだから
少しはググレばいいのに

2D-STGしか頭に無いロートルなんでしょうか？
グラフライブラリの実装を知りたいなら適当に
フリーの奴をDLして眺めればいいじゃないですか

734 ：名前は開発中のものです。：2007/11/26(月) 17:00:57 ID:PlFjoTQQ

>>733
5.資料を示さず持論が支持されていると思わせる >>733
6.一見、関係がありそうで関係のない話を始める >>722
11.レッテル貼りをする >>730
12.決着した話を経緯を無視して蒸し返す >>733
15.新しい概念が全て正しいのだとミスリードする >>715

さっさと資料か実装を示せ
class COresama; だけじゃ2D-STGすら動かんよ
グラフライブラリの実装？探索木だろが

735 ：名前は開発中のものです。：2007/11/26(月) 17:06:28 ID:O0gpbRD6

なんだ
結局>>722の意味が理解できないからってファビョってるんですか。

736 ：名前は開発中のものです。：2007/11/26(月) 17:14:23 ID:PlFjoTQQ

>>735
なんで「巡回UPDATEなのかそうでないのか」の話で、リニアアクセスうんたらの話になるのかがわからね。
悪いが俺はエスパーじゃないんでね。理解できるように頼むよ
今のところ一人足りとも>>722が分かるって書き込みは無いが？

自演はやめろよ？
あと面白がって分からないのに分かるという書き込みもご法度だ。分かるってやつは噛み砕いて説明しなおしてくれ

737 ：名前は開発中のものです。：2007/11/26(月) 17:19:58 ID:o4MnOpxn

くやしいけど…すごく…わかるっ…！（ﾋﾞｸﾋﾞｸｯ

738 ：名前は開発中のものです。：2007/11/26(月) 17:42:15 ID:O0gpbRD6

君がリスト巡回UPDATEって言ってるのは
STGで言えば更新したい敵オブジェクトをリストで繋いで
毎度その鎖を辿ってるって話ですよね？

その敵オブジェクトって一個当たり容量どんぐらいなんですか？

739 ：名前は開発中のものです。：2007/11/26(月) 17:51:24 ID:PlFjoTQQ

お好きなサイズでいいので、都合のいい大きさで実装してみて

740 ：名前は開発中のものです。：2007/11/26(月) 18:02:20 ID:O0gpbRD6

class 敵
{
　　状態変数
　　カウンター
　　位置
　　速度
　　方向
}
多く見積もっても64バイトくらいでしょ
編隊飛行しなければ相互参照もない
リストである必要どこにもないでしょ

何で普通にvectorにでも放り込んじゃ駄目なの？

741 ：名前は開発中のものです。：2007/11/26(月) 18:03:09 ID:O0gpbRD6

「何で」は不要

742 ：名前は開発中のものです。：2007/11/26(月) 18:10:58 ID:PlFjoTQQ

何の話してるのお前
さっさとグラフとやらを使って、オブジェクトを総巡回UPDATEするのではない技法とやらを見せてくれよ

743 ：名前は開発中のものです。：2007/11/26(月) 18:11:42 ID:O0gpbRD6

あー、はぐらかした

744 ：名前は開発中のものです。：2007/11/26(月) 18:14:34 ID:PlFjoTQQ

なんだ、また逃げるのか

745 ：名前は開発中のものです。：2007/11/26(月) 18:16:22 ID:O0gpbRD6

わざわざボケ中年のために身近な例をあげて
順々に説明してあげてるんですよ。がんばってください

746 ：名前は開発中のものです。：2007/11/26(月) 18:20:53 ID:PlFjoTQQ

で、std::listだろうがstd::vectorだろうが、それはリスト巡回UPDATE型エンジンのお話
お前の実装とやらを早く見せろよ

747 ：名前は開発中のものです。：2007/11/26(月) 18:21:53 ID:UwVKS71I

>>742
「リスト巡回UPDATE型エンジン」の代替案を示す必要性ってどこにあるの？
「タスクシステム」の代替案ならともかく、
こんなの自然に作ってればどこかに出てくるだろうし、
名前をつける必要も無いくらいありふれた実装なんだけど。

748 ：名前は開発中のものです。：2007/11/26(月) 18:25:14 ID:PlFjoTQQ

>>747
俺もありふれてると思うよ
てかこれ以外で組むなら、ファイバーとか使うしかないかなと思うくらいな

でもID:O0gpbRD6 が>>691で別のエンジンがあるっていうのでヒアリングしてるんだが、もったいつけてばかりで答えてくれないんだ

749 ：名前は開発中のものです。：2007/11/26(月) 18:26:23 ID:o4MnOpxn

>>746
>std::listだろうがstd::vectorだろうが、それはリスト巡回UPDATE型エンジンのお話

あらやだ聞いた？配列もリストなんですってよ、奥さん。。。怖いわぁ

750 ：名前は開発中のものです。：2007/11/26(月) 18:29:36 ID:O0gpbRD6

配列走査をリスト巡回と強弁するなら止めはしませんが

751 ：名前は開発中のものです。：2007/11/26(月) 18:32:53 ID:PlFjoTQQ

>>750
まさかここまでひっぱっといて「僕はstd::listじゃなくて、配列を使うんだよ！まったく新しいね！」とか言うつもりか？

しかもその指摘>>719-721でされてるのに否定しなかったから、今更言い分けにならんぞ

752 ：名前は開発中のものです。：2007/11/26(月) 18:36:29 ID:e5gOLxzA

ID:PlFjoTQQ は論点をずらされるのが得意だなｗ

753 ：名前は開発中のものです。：2007/11/26(月) 18:37:15 ID:O0gpbRD6

散々人の話をスルーしておいて自分の書き込みがスルーされると
否定しなかったから、肯定だよな？ですか。なるほど、すばらしい
あなたの枝葉末節の質問に全部お付き合いしていたら日が暮れますよ
あ、暮れましたね

754 ：名前は開発中のものです。：2007/11/26(月) 18:38:10 ID:UwVKS71I

>>751
よく分からんが、
配列を使っていたら「配列巡回UPDATE型エンジン」だし
探索木を使っていたら「探索木巡回UPDATE型エンジン」
になるんじゃないの？
型関係なくすべての要素を巡回するエンジンなら「オブジェクト巡回型エンジン」にでもなるだろう。

755 ：名前は開発中のものです。：2007/11/26(月) 18:38:17 ID:PlFjoTQQ

>>752
まーもう完全ネタだってのは分かってるからなー
暇つぶしにはなったけど、リスト巡回UPDATE式以外の方法ってのも世の中にあるなら知ってみたくはあったんだがなぁ・・・

756 ：名前は開発中のものです。：2007/11/26(月) 18:41:56 ID:iOCgoqG0

>>680のようなものを「コンテナの中の各要素に対して関数を適用する」って解釈して
巡回UPDATE型エンジン＝タスクシステムと定義しちゃうと、std::for_eachとか使ってるのは、
全て巡回(ryになっちゃうわけで…

だから俺としては巡(ryの代替があるか否かより
Logician Lordの記事を元にしたこのスレなりのタスクシステムの解釈が必要に思える
元はといえば各人のイメージする「タスクシステム」が食い違ってるのが原因っぽいしさ

757 ：名前は開発中のものです。：2007/11/26(月) 18:59:40 ID:MkpiHi91

おまえらちょっと茶でも飲んで落ち着け

758 ：名前は開発中のものです。：2007/11/26(月) 19:01:24 ID:PlFjoTQQ

>>756
>>546でいいじゃん
std::listか、std::vectorか、std::mapかなんてゲームによって相性があんだから。
STGとかだと削除と挿入が頻繁だろうからstd::listが採用されやすいってだけだろ。
まぁlistのイテレーションはキャッシュ効率が悪くてかなり遅いらしいが。

759 ：名前は開発中のものです。：2007/11/26(月) 19:10:55 ID:/e4hWy8N

俺は>>13が言う「処理関数へのポインタ付きワーク構造体の連結リスト」だと思う。

全てのオブジェクトを同じサイズの構造体のリストで持つ事で以下の効果を期待する
1.処理の優先順序の判定を毎フレーム行わないで済む→速度アップを期待
　オブジェクトをリストに挿入する時点で決定されるので、毎フレームチェックしない
2.処理をポインタ関数に持つ事で、処理の分岐を毎フレーム行わないで済む→速度アップを期待
　オブジェクトにステータス変数を持たせてswitch～caseで分岐ってやり方だと毎フレームチェックが必要
3.オブジェクトの生成/破壊を繰り返してもメモリ使用総量が変化しない→メモリの無駄を省く
　構造体のサイズが同じなので、メモリの抜けが発生しない

まあ、スレ建て前に宣伝してた奴の内容そのままなんだけどね

760 ：名前は開発中のものです。：2007/11/26(月) 19:16:33 ID:Kp8OBlhv

みなさんお帰り＾＾
今日もお仕事おつかれさま＾＾

761 ：名前は開発中のものです。：2007/11/26(月) 19:23:30 ID:PlFjoTQQ

>>759
なんというか、それだと話が派生作りづらくないか？
タスクシステムとは
ITaskSystem
であるべきで、759のは
CTaskSystemWithFixedSizeObjecsとかじゃね？
実装の一つとしてはいいもんだと思うけどね

762 ：名前は開発中のものです。：2007/11/26(月) 19:30:28 ID:PtFOoRDR

>>761
～であるべき、とか断定するから話が厄介になるんだよ

763 ：名前は開発中のものです。：2007/11/26(月) 19:40:13 ID:PlFjoTQQ

曖昧にしてたら何も技術的な会話できんぞ
断定してる内容がおかしいなら、何故おかしいのかを説明して修正すりゃいいだろ

764 ：名前は開発中のものです。：2007/11/26(月) 19:42:38 ID:UwVKS71I

>>535といわゆる「タスクシステム」の一番の違いは
「move_enemy」の扱いだと思う。

これを悪だと考える人がこのスレでは多そうな雰囲気だけど、
タスクシステムならmove_enemyをタスクにすることが可能になる。
元のタスクシステムの考え方から言えば、
これを避ける必要性はどこにもないし賞賛されることすらあるんじゃないのかな。

765 ：名前は開発中のものです。：2007/11/26(月) 19:44:58 ID:PlFjoTQQ

>>764
vector< list< shared_ptr<ITask> > >
の話が散々された後に、画期的な新システムかのように>>535を賞賛する奴が現れたから（535自身は皮肉のつもりで出したと思われる）問題だったんだろ

766 ：名前は開発中のものです。：2007/11/26(月) 19:51:00 ID:mRg8odX/

>>694
ときどきでいいから、boost::signal も思い出してあげてください。

767 ：名前は開発中のものです。：2007/11/26(月) 19:59:58 ID:UwVKS71I

>>765
「vector< list< shared_ptr<ITask> > >」？？
そんな話をしててたのは誰だ？
何を言いたいのか全く分からないのだけど。

768 ：名前は開発中のものです。：2007/11/26(月) 20:00:53 ID:PtFOoRDR

>>763
一行目には同意

>>759とタスクシステムの解釈についてズレがあるのをわかっていながら、
断定的にオレオレ定義を使うのは馬鹿らしいよ。

自分はこう定義した上で話を進める～という流れとか、
せめてこのスレ内だけで通じるローカル定義を決めようとかって話にするのならわかるんだけどね。

769 ：名前は開発中のものです。：2007/11/26(月) 20:05:06 ID:PlFjoTQQ

>>767
「プライオリティ」で検索しろ

770 ：名前は開発中のものです。：2007/11/26(月) 20:11:34 ID:UwVKS71I

>>769
http://d.hatena.ne.jp/keyword/%A5%D7%A5%E9%A5%A4%A5%AA%A5%EA%A5%C6%A5%A3
> 「プライオリティ」とは
> 優先順位や優先度のこと。

それともこれ？
http://www.franklincovey.co.jp/training/priority.html
> プライオリティ
> 1, 限られた時間を有効に使い、生産性を高める
> 2, 人生のバランスをとり、自分の中心を見失わない

> 曖昧にしてたら何も技術的な会話できんぞ
というのはあなたの発言ですが^^

771 ：名前は開発中のものです。：2007/11/26(月) 20:11:35 ID:/e4hWy8N

>>763
>>546だと各オブジェクトのマネージャクラスを作るってやり方も入らない？
それにまず始めにCTaskSystemWithFixedSizeObjecsがあって、それをタスクシステムって取り上げた記事があって、そこから話をしようって事だろ
記事に書かれてる「タスクシステム」について話をするなら、当然CTaskSystemWithFixedSizeObjecsの話になると思うよ
CTaskSystemWithFixedSizeObjecsを「タスクシステム」と定めて、このスレは「タスクシステム」及び「タスクシステムを元にしたシステム」について語る、じゃ駄目？

話を派生したいのなら、
・>>759で期待された内容が現在ではどの程度有効か
・CTaskSystemWithFixedSizeObjecsを踏まえて、欠点を克服した手段/システムを考える
とかどうよ

772 ：名前は開発中のものです。：2007/11/26(月) 20:37:31 ID:O0gpbRD6

>>758
＞STGとかだと削除と挿入が頻繁だろうからstd::listが採用されやすいってだけだろ。
＞まぁlistのイテレーションはキャッシュ効率が悪くてかなり遅いらしいが。

削除と挿入と言ってる時点で敵や弾だと思うんですが
STGの敵や弾なんてサイズ小さいし相互参照が基本的に無いんだからstd::vectorで
いいと思うんですけど。リスト大好きオジサンがなんでわざわざリストに繋がれてる
順番に辿りたいのか理解に苦しみます。敵同士ならプライオリティもへったくれもないん
だからリストに繋がってる順番なんて情報価値ゼロでしょ

773 ：名前は開発中のものです。：2007/11/26(月) 20:52:56 ID:mRg8odX/

>>772
list だと削除が O(1) で済むけど、vector だと O(n) っつー話じゃない？

774 ：名前は開発中のものです。：2007/11/26(月) 20:54:01 ID:O0gpbRD6

削除したいときは最終要素で上書きして最終要素を削除すればおｋ

775 ：名前は開発中のものです。：2007/11/26(月) 20:58:43 ID:mRg8odX/

>>774
コレクションが殻の場合とか、最終要素も削除する場合とか考えると、ちょっと
面倒だな。

その辺マジメに実装して、STL 互換の swap_vector とか作っちゃったほうが良いかも。

776 ：名前は開発中のものです。：2007/11/26(月) 20:58:46 ID:O0gpbRD6

粘着っぽいけど更にレス
あと、listのイテレーションはキャッシュ効率が悪いってどんだけの大きさなんだよ。
STGの敵や弾なんてサイズ小さいし、数なんて多くて500やそこらでしょ。
知ったかぶっこいてないでVTuneの体験版でもDLして測定してみるといい。
そんなに気になるならboostの固定長メモリプールアロケータでも使えばいい

777 ：名前は開発中のものです。：2007/11/26(月) 21:03:08 ID:mRg8odX/

>>776
vector だと連続記憶域に入ってるけど、list だと ++it が全然違うところにあることも
多いので、キャッシュミス率は結構上がるよ。特にデータキャッシュ 8KB しかない
EE だと。

778 ：名前は開発中のものです。：2007/11/26(月) 21:03:46 ID:MpmnG+UG

C++のメモリアロケーションは、
比較的中規模～大規模の割り当てを想定して作られているので、
頻繁に割り当てと解除を繰り返すのはあまり美しくない。

placement newなり、固定長で最初に確保した方が良い。

（理屈上は。）

779 ：名前は開発中のものです。：2007/11/26(月) 21:17:40 ID:O0gpbRD6

>>775
ゲームロジック（プレイヤーどこ、弾発射、被弾、脂肪）のコードにとって
自分自身や弾のコンテナが何であるかは隠蔽されてるものだと思うので
その辺の面倒は、少なくともゲームロジック側からは無関係だからおｋかと

>>777
そうなんですか。無意識のうちに最近のPCを基準に書いてしまいました。
研究室でサボってる学生風情なのでコンシューマ機のこととかよく分かりません

780 ：名前は開発中のものです。：2007/11/26(月) 21:26:10 ID:PlFjoTQQ

>>770
スレ内をだよ！！

781 ：名前は開発中のものです。：2007/11/26(月) 21:31:47 ID:O0gpbRD6

>>778
C++のメモリアロケーションは、というかこれまたPC前提で恐縮ですが
MSVC付属のSTLの標準アロケータが内部で呼び出してるのはmallocで
これが内部で呼び出してるのはWin32APIのHeapAllocなんですが
この可変長メモリアロケータで弾や敵の生成破棄を繰り返しまっても
何ら不都合が生じないというのが実際です

782 ：名前は開発中のものです。：2007/11/26(月) 21:35:02 ID:mRg8odX/

>>778
C++ のメモリアロケーションというのが ::operator new を指してるのか、それとも
std::allocator 指してるのか不明だが…

後者なら、たとえば STLport の node_allocator は小さなオブジェクトを効果的に
扱うための仕組みが入ってる。

783 ：名前は開発中のものです。：2007/11/26(月) 21:35:34 ID:PlFjoTQQ

>>779
＞そうなんですか。無意識のうちに最近のPCを基準に書いてしまいました。
馬鹿か
コンシューマどころかキャッシュのでかいPCのほうが致命的だ
お前そんな知識も無くて偉そうにのたまってたのか

784 ：名前は開発中のものです。：2007/11/26(月) 21:39:15 ID:mRg8odX/

>>783
> コンシューマどころかキャッシュのでかいPCのほうが致命的だ
最近の PC は、キャッシュサイズはデカくなったが、レイテンシも相応に
でかくなったからな…

785 ：名前は開発中のものです。：2007/11/26(月) 21:44:53 ID:mRg8odX/

>>781
そりゃ、GHz で動く CPU 使って Z80 4MHz と同じような程度の処理しかしてなければ、
どんな書き方だろうと動くさ。

786 ：名前は開発中のものです。：2007/11/26(月) 21:45:44 ID:O0gpbRD6

>>783
やはり本当に底抜けの馬鹿みたいですねーこのオッサンは。
「イテレーションはキャッシュ効率が悪くてかなり遅いらしい」
ってアンタ結局何を基準に遅いの速いの言ってるんですか？
同一環境内でstd::listとそれ以外の何かで比較して、でしょ？
敵や弾でベンチ取ればすぐ分かるけどそれデマですよ

787 ：名前は開発中のものです。：2007/11/26(月) 21:52:05 ID:mRg8odX/

>>786
DTL-T15000 でデータとって比較した結果だが。

ライブラリチームのほうは仮想関数使うと命令キャッシュが、と言って
関数の並び順も気にしてたけど、さすがにゲーム本体書いてる方は
CPUの効率よりプログラマの効率優先だった。

788 ：名前は開発中のものです。：2007/11/26(月) 21:56:48 ID:PlFjoTQQ

>>786
お前電波なのか？いや、電波なんだろうけど
>>758にそのものが書かれてるじゃねーか
お前と違って電波受信して書いてるわけじゃねーから文脈読め

お前はさっさとオブジェクト巡回UPDATE型じゃないエンジンの実装を書け
何が「無意識のうちに最近のPCを基準に書いてしまいました」だ。巨大な墓穴掘ってんじゃねーよ

789 ：名前は開発中のものです。：2007/11/26(月) 21:58:54 ID:UwVKS71I

>>780
いやだからスレ内のどの部分かを具体的に語ってくれ。
曖昧にしてたら何も技術的な会話できんぞ？ｗ

790 ：名前は開発中のものです。：2007/11/26(月) 22:01:35 ID:PlFjoTQQ

>>784
まぁそうだよねぇ。
それに描画が処理のほとんどを占めるから、描画ルーチンくらいでしかキャッシュヒットは気にしないかもね
よっぽど無数のタスクが登録されるゲームじゃなければイテレーションの速度なんて誤差だし、逆によっぽど無数が登録されるなら（ソート済み）vectorで挿入するわけにもいかんしな

リスト内ではプライオリティが関係しないように作って、プライオリティはリストの外側のリストとして実装するのもいい
（この話はさんざ既出だが）

791 ：名前は開発中のものです。：2007/11/26(月) 22:03:55 ID:M+b7sffh

実況ニュー速並みにIDが赤いですね、皆さん。

792 ：名前は開発中のものです。：2007/11/26(月) 22:04:38 ID:PlFjoTQQ

「プライオリティ」でこのスレ検索かけて、そこから30レスくらい読み直した

・リストのイテレーションはキャッシュヒットの関係で遅い
・タスクリストのリストを持って、プライオリティは外側のタスクで行う

両方書いてあって苦笑いした

793 ：名前は開発中のものです。：2007/11/26(月) 22:08:23 ID:O0gpbRD6

>>788
>>772

794 ：名前は開発中のものです。：2007/11/26(月) 22:10:20 ID:PlFjoTQQ

>>793
意味わからん。772のどこに「オブジェクト巡回UPDATE型じゃないエンジン」が書かれてるんだ？
あぶりだしかなにかか？

795 ：名前は開発中のものです。：2007/11/26(月) 22:10:40 ID:O0gpbRD6

>>788
加えて>>774

これがリスト巡回UPDATE型エンジンｗだと強弁するなら止めはしませんが

796 ：名前は開発中のものです。：2007/11/26(月) 22:12:25 ID:O0gpbRD6

あなたリストオジサンなんだからリスト巡回に情熱を燃やすべきですよ
いつのまにかオブジェクト巡回とか主張を捻じ曲げないでくださいね
白旗を揚げるときはもっと素直に神妙な顔をしてオズオズとお願いします

797 ：名前は開発中のものです。：2007/11/26(月) 22:16:28 ID:PlFjoTQQ

教授　「登録順が重要な巡回リストを作っておいてくれたまえ」
研究員生　「なんでわざわざリストに繋がれてる順番に辿りたいのか理解に苦しむので嫌です」
教授　「・・・」

798 ：名前は開発中のものです。：2007/11/26(月) 22:18:41 ID:O0gpbRD6

>>797
おかしいですね。STGの弾って登録順が重要なんでしょうか

799 ：名前は開発中のものです。：2007/11/26(月) 22:20:52 ID:PlFjoTQQ

代替案としてGraph Traverseを持ち出しといて何を言ってるんだ？
いつのまにかSTG専用になってるし
お前の代替案ってのはSTG特化エンジンだったの？ｗ

800 ：名前は開発中のものです。：2007/11/26(月) 22:22:48 ID:UclGLYJR

>>798
結局君の案って、listじゃなくてvectorにして、登録優先度機能は削除ってだけなの？

801 ：名前は開発中のものです。：2007/11/26(月) 22:23:23 ID:O0gpbRD6

>>758

802 ：名前は開発中のものです。：2007/11/26(月) 22:26:46 ID:PlFjoTQQ

>>801
お前がGraph Traverseを代替案として持ち出したのは、758よりずっと前の>>691だ
ごまかすな

803 ：名前は開発中のものです。：2007/11/26(月) 22:28:25 ID:QGQySzTg

なんか、O0gpbRD6とPlFjoTQQがリストで繋がってるように見えるんだけど…
これがタスクシステム？

804 ：名前は開発中のものです。：2007/11/26(月) 22:28:28 ID:O0gpbRD6

＞STGとかだと削除と挿入が頻繁だろうからstd::listが採用されやすい
＞STGとかだと削除と挿入が頻繁だろうからstd::listが採用されやすい
＞STGとかだと削除と挿入が頻繁だろうからstd::listが採用されやすい

STGで削除挿入が頻繁なのは敵や弾ですし、これらはほとんどの場合
相互参照がありません。こうしたオブジェクト同士の場合、リストを辿る
必要性が皆無だと指摘していますが、反論ありますか？

わざわざSTG大好きリスト大好きオヤジのために話をデチューンして
身近な例を出して矛盾点を指摘しているだけなんですが

805 ：名前は開発中のものです。：2007/11/26(月) 22:29:47 ID:UwVKS71I

>>800
そういうことを言い出すと
「リスト巡回UPDATE型エンジン」ってリストを巡回するだけなの？
って話になる。
元がこれだからちょっと変更しただけでも相当な変更になるんじゃないのか？
よく分からんけど。

806 ：名前は開発中のものです。：2007/11/26(月) 22:31:27 ID:PlFjoTQQ

>>804
その話はリスト巡回UPDATE型の「リスト」を何で作るかの話だろ
>>691のGraph Traverseとはまったく関係無い。ごまかすな

807 ：名前は開発中のものです。：2007/11/26(月) 22:34:08 ID:O0gpbRD6

>>806
ですから、何度も申し上げてる通り

グラフがリストだと強弁するなら別に止めはしませんよ

808 ：名前は開発中のものです。：2007/11/26(月) 22:39:45 ID:UclGLYJR

>>O0gpbRD6
リスト巡回って言われたら、普通は双方向リンクドリストじゃなくて何かしらの順番にアクセス可能な領域を指すと思うぞ
グラフも配列も可変長配列も双方向リンクドリストも全てひっくるめてリストだろう

809 ：名前は開発中のものです。：2007/11/26(月) 22:40:36 ID:PlFjoTQQ

>>807
お前の中のリンクの定義が知りたいわ
双方向リンクのリストしかリストと呼びません！ってだけかよ

810 ：名前は開発中のものです。：2007/11/26(月) 22:41:07 ID:PlFjoTQQ

リストの定義だったわ

811 ：名前は開発中のものです。：2007/11/26(月) 22:47:37 ID:O0gpbRD6

なるほど
となるとID:PlFjoTQQに言わせると「タスクシステム」＝「リスト巡回UPDATE」だから
>>808の解釈でいくとどんな組み方をしても「タスクシステム」になるということですね？

私はタスクシステムを見縊っていたようです。大変失礼いたしました。
謹んでお詫び申し上げます

812 ：名前は開発中のものです。：2007/11/26(月) 22:50:07 ID:PlFjoTQQ

>>719でももろ同じこと指摘されてるのに、今更それはねーわ

813 ：名前は開発中のものです。：2007/11/26(月) 22:52:15 ID:UclGLYJR

>>758　子供達「FFって色んな楽しみ方ができるよね」
>>772　おじさん「お、おじさんもFF好きだぞ。マクドナルドで一番美味しいよね」
>>773　子供達「誰もフィレオフィッシュバーガーの話なんてしてないよ」
>>776　おじさん「な、なーんだあれか。あっちのFFか。おじさんハガーに似てないかい？」
>>777　子供達「誰もファイナルファイトの話なんてしてねーよ…うぜえ」
>>779　おじさん「そ、そうなんだ。無意識のうちにゲームの話だと思っちゃったよ」
>>ROM　子供達「ゲーム（ファイナルファンタジー）の話だよ！知ったかぶりすんなボケ！」

814 ：名前は開発中のものです。：2007/11/26(月) 22:53:20 ID:O0gpbRD6

で、>>804なんですが

815 ：名前は開発中のものです。：2007/11/26(月) 22:56:35 ID:PlFjoTQQ

リストをたどらずに、どうやって各オブジェクト（リストの要素）を呼び出すんだ？
魔法か？

816 ：名前は開発中のものです。：2007/11/26(月) 23:00:10 ID:O0gpbRD6

やはりこれもタスクシステムということですか。
タスクシステム厨からは配列厨と散々馬鹿にされていた僕ですが
これからは正々堂々とタスクシステム厨を名乗っていいんですね

どうしてこんな素晴らしい用語に確固たる出典がないのか不思議ですね

817 ：名前は開発中のものです。：2007/11/26(月) 23:01:29 ID:PlFjoTQQ

>>804
>>815
>>816
の会話がどう見ても繋がってないんだが

それにお前>>811と>>816も繋がってないぞ
本当に頭大丈夫か？

818 ：名前は開発中のものです。：2007/11/26(月) 23:02:09 ID:Ynm1L1D3

あー、わかった。
O0gpbRD6はあるオブジェクトが別のオブジェクトを参照する時に
リストからたどって参照してると思ってるんじゃないかな
と>>804だけみて妄想してみるテスト

819 ：名前は開発中のものです。：2007/11/26(月) 23:02:20 ID:UclGLYJR

相互干渉があるなしに関わらず、リストは辿らないと。

820 ：名前は開発中のものです。：2007/11/26(月) 23:03:55 ID:PlFjoTQQ

>>818
ねーよｗ
もはや日本語読めてないじゃねーかそれじゃｗ

821 ：名前は開発中のものです。：2007/11/26(月) 23:06:30 ID:Ynm1L1D3

>>820
えー、だって相互参照しなけりゃリストたどる必要は皆無だなんて
こうとでも解釈しないと漏れには理解できないよｗ

822 ：名前は開発中のものです。：2007/11/26(月) 23:07:54 ID:UclGLYJR

配列を連結リストの一種だと知らない人間だから、十分ありえると思った

823 ：名前は開発中のものです。：2007/11/26(月) 23:11:31 ID:UclGLYJR

連結リストの一種ってのは言い過ぎだったので撤回する

824 ：名前は開発中のものです。：2007/11/26(月) 23:16:03 ID:NdLrwaPc

まず、日本語の定義からはっきりしてもらわないとレスつけられない

825 ：名前は開発中のものです。：2007/11/26(月) 23:18:15 ID:PlFjoTQQ

やべぇ…出てこなくなった
マジで>>818だったのかよ
研究室って「ふたばようちえん、つみきけんきゅうしちゅ」とかだったのかな

826 ：名前は開発中のものです。：2007/11/26(月) 23:30:41 ID:O0gpbRD6

今、研究室で酒席が設けられてまして、はい

>>818
ノン、ノン。それは違います
相互参照とは親子関係とでも読み替えてください
敵や弾同士には基本的には親子関係はありませんから
実行優先順位もありません。std::listで、つまり双方向リストで
繋げたものをイテレータ使って走査する必要なくね？って話です

827 ：名前は開発中のものです。：2007/11/26(月) 23:31:55 ID:O0gpbRD6

相互参照＝衝突判定でも構いません

828 ：名前は開発中のものです。：2007/11/26(月) 23:34:12 ID:PlFjoTQQ

まともなネタ振りでもするか

マルチコアだとタスクリストのそれぞれのタスクを並列処理するために、タスクリスト内はお互いに参照しあわないってルールがあるらしいね
>>475のように、プライオリティリストの中にタスクリストを持つようにすれば楽に実装できそうだな

でも、どうしてもお互いを参照しあう場合はどうするべきかね？
例えばSTGの敵の弾同士が反射しあう仕様で、300個とかいっきに出てくる場合。

「敵の弾タスク」を管轄するタスクリストの前に、弾同士のあたり判定を行うタスクリスト（「あたり管理判定タスク」が1個登録されてるだけ）を持って、
判定結果を「敵の弾タスク」に書き込んでおくべきかね？

829 ：名前は開発中のものです。：2007/11/26(月) 23:36:54 ID:UclGLYJR

>>826
相互参照のあるなしは、リストにstd::listを使うのかstd::vectorを使うのかを決めるファクターにはならない

830 ：名前は開発中のものです。：2007/11/26(月) 23:39:28 ID:Ynm1L1D3

親子関係があろうとなかろうとリストはたどらないと描画も更新もできないんだけど・・・
なんというか根本的にかみ合ってないことだけはわかりますた

831 ：名前は開発中のものです。：2007/11/26(月) 23:40:11 ID:O0gpbRD6

>>829
なぜですか？
実行優先順位があるから、std::listに繋がってる順に走査するわけでしょ？
この場合、実行優先順位でソートされてるんじゃないんですか？

実行優先順位のない（等しい）大量の要素だけで構成されているなら
ソートされている必要は無く、std::vectorの走査で済むじゃないですか

832 ：名前は開発中のものです。：2007/11/26(月) 23:41:19 ID:UclGLYJR

>>828
300個もの物体が当たりあう当たり判定テストを、並列化できない「タスクリストに唯一存在するタスク」として登録するのはやだな・・・

833 ：名前は開発中のものです。：2007/11/26(月) 23:44:02 ID:UclGLYJR

>>831
vectorはオブジェクトの移動が発生するので、その要素を刺すポインタのライフラインが不明となる
同じリスト内の相互参照どうのなんて、リストの実装にどのコンテナを使うかを決めるファクターにはならない
君、STLまったく分かってないでしょ

834 ：名前は開発中のものです。：2007/11/26(月) 23:49:08 ID:cKEAb1A4

>>831
優先順位あったらstd::setやstd::priority_queue使わないかなぁ

それはそうと
>>826で敵や弾同士には基本的には親子関係はありませんから
と言ってるけど、敵を倒したら、その敵が吐いた弾も消えるとかってのはよくある話だと思うよ。

835 ：名前は開発中のものです。：2007/11/26(月) 23:56:55 ID:UclGLYJR

>>830の感覚が普通なんだろうなぁ
いまだにリストを辿らないでリストの要素を呼び出す方法ってのが>>815の魔法（笑）以外に思いつかない

836 ：名前は開発中のものです。：2007/11/27(火) 00:00:52 ID:M9k+XAkU

>>828
とりあえず質問なんだけど、
「敵の弾タスク」　これは敵の弾の時間更新のことで
「あたり管理判定タスク」　これは弾2つへの参照を持って判定を取るタスクで、
敵の弾タスクを更新する前に当たり判定タスクを実行する
っていう解釈でいいすか？
(もちろん、(a,b)のペアで衝突判定したら(b,a)のペアで衝突判定は行わないようにするとして)

837 ：名前は開発中のものです。：2007/11/27(火) 00:05:07 ID:sqxvoHfT

>>836
おおむねそれでOKなんだが「弾2つへの参照を持つタスク」ってのだときついと思う
300個ある弾全てで判定するとしたら、その「弾2つへの参照を持つタスク」だけで300*299/2個必要になる

『「敵の弾タスク」のリストを全てなめて、それぞれのあたり判定を行うタスク』というタスクを1つ持つとしたい。

838 ：名前は開発中のものです。：2007/11/27(火) 00:08:44 ID:WmLtqP1H

>>833
＞vectorはオブジェクトの移動が発生するので

それ普通に不要な要素をerase()してることを想定してませんか？
>>774の使い方でいつどのオブジェクトの移動が発生してるか分かりますよね？
それは要素削除時で、移動するのは最終要素だけです。

ライフライン云々ですがerase()予定の要素を別のvectorに保持してUpdate用の
走査終了後にまとめて削除すれば同一vector内の同一フレーム上では保証されます

>>834
その場合は敵、弾で別配列を作るということで

839 ：名前は開発中のものです。：2007/11/27(火) 00:11:04 ID:WmLtqP1H

×同一vector内の同一フレーム上では
○同一フレーム上では

840 ：名前は開発中のものです。：2007/11/27(火) 00:11:45 ID:uRAEiYZn

二分木とか、エリアとかに弾を登録するとか…

…考え付かないタスクシステム厨はPGやる資格無し。

841 ：名前は開発中のものです。：2007/11/27(火) 00:13:33 ID:sqxvoHfT

>>838
同一フレーム上でだけ保証されてどうすんだ馬鹿
読まないのは俺の話だけかと思ったら、他のやつのも読めないのな

vector選ぶかlist選ぶかmap選ぶかなんて、ゲームによって決めればいいんだよ
重要なのは総巡回できるかどうかだろが

842 ：名前は開発中のものです。：2007/11/27(火) 00:17:41 ID:yMpie7iD

>>838
まともに議論できる規模のソース持ってきてくれ。断片的に話しても、そろそろ
意味なくなってきた。

843 ：名前は開発中のものです。：2007/11/27(火) 00:19:59 ID:sqxvoHfT

>>840
エリア分けするにしても、エリアAに居た弾がエリアBに移動する場合誰がそれを行うかとか
エリアをまたぐ大きさの弾がある場合どうするかとか
色々話は膨らませられるっしょ

とりあえず>>828は「ビリヤードの玉」をどう処理するかで実装の話をしてみないか
それぞれの玉タスクのUPDATEは、並列化を行いたいので、お互い参照も変更もできないものとする

844 ：名前は開発中のものです。：2007/11/27(火) 00:23:34 ID:uRAEiYZn

> エリア分けするにしても、エリアAに居た弾がエリアBに移動する場合誰がそれを行うかとか
> エリアをまたぐ大きさの弾がある場合どうするかとか
ｺｲﾂ馬鹿ﾅﾉ？

845 ：名前は開発中のものです。：2007/11/27(火) 00:23:39 ID:ecqZOO+y

>512
にループか？

846 ：名前は開発中のものです。：2007/11/27(火) 00:24:42 ID:nt8BfAfa

エリアの意味が違ってたらどうしようｗ
>>843は画面上の一部を構成する区域と解釈したっぽいけど

847 ：名前は開発中のものです。：2007/11/27(火) 00:27:01 ID:M9k+XAkU

>>837
了解です。流石にそこまで分割してしまうと
タスク取得の同期オーバーヘッドが馬鹿にならんですね。

で、ところでその順序って、衝突→時間更新→描画ってこと？
これはなんか色々と都合悪いはず。

マルチスレッドのことを抜きにして、ゲームのフローって一般的には
時間更新→衝突(何らかのイベント発生)→描画
だと思うんだけど、こうしなかった理由は？

>>840
エリア分けした上で更に並列更新するだけの話では？

848 ：名前は開発中のものです。：2007/11/27(火) 00:33:02 ID:WmLtqP1H

>>833
＞同じリスト内の相互参照どうのなんて、リストの実装にどのコンテナを使うかを決めるファクターにはならない

親子関係で相互参照してるなら実行優先順位が生じますから
コンテナ内の要素はソート済みである必要がありますよね？

実行優先順位が無いならソート済みである必要もないんですから
結果、無造作にstd::vector+>>774でやっても何も問題ないですよね？

相互参照の有無がコンテナを決めるファクターになってるじゃないですか

849 ：名前は開発中のものです。：2007/11/27(火) 00:36:26 ID:S6ilEu/w

オフトピックだけども
ライフライン＝生命線って意味じゃぞ？よいかの？

850 ：名前は開発中のものです。：2007/11/27(火) 00:37:36 ID:uRAEiYZn

> エリア分けした上で更に並列更新するだけの話では？
ｺｲﾂﾓ馬鹿ﾅﾉ？

851 ：名前は開発中のものです。：2007/11/27(火) 00:40:17 ID:nt8BfAfa

そろそろuRAEiYZnの言うエリアの定義を聞こうか

852 ：名前は開発中のものです。：2007/11/27(火) 00:40:53 ID:WmLtqP1H

ライフタイムと脳内補間してました。焼酎飲みすぎて吐きそうです

853 ：名前は開発中のものです。：2007/11/27(火) 00:43:07 ID:nt8BfAfa

std::vectorを使ったらそれはタスクシステムじゃないってこと？

854 ：名前は開発中のものです。：2007/11/27(火) 00:46:20 ID:WmLtqP1H

>>848
＞その要素を刺すポインタのライフラインが不明となる

あと、そもそも相互参照するためのポインタ（orインデックスナンバー）なわけで
参照されない限り自分向きのポインタは存在しないわけで、どこに移動しようが自由でしょ

855 ：名前は開発中のものです。：2007/11/27(火) 00:46:50 ID:8jtUDac7

もう寝るか
明日の朝までに1000いってスレ落ちてるとか無しな

856 ：名前は開発中のものです。：2007/11/27(火) 00:47:30 ID:WmLtqP1H

相互が余計だった

857 ：名前は開発中のものです。：2007/11/27(火) 01:01:12 ID:wmmwA/ZN

>>838
std::vectorは要素追加時にもオブジェクトの移動が発生するよ

>erase()予定の要素を別のvectorに保持してUpdate用の走査終了後にまとめて削除
std::vectorは削除1回毎にオブジェクトの移動が発生するからそのやり方ならlistの方が速度面で有利だと思う

>その場合は敵、弾で別配列を作るということで
敵のvectorと弾のvectorの2種類だとオブジェクトの移動が発生した時にやっかいだよね？
敵毎に弾のvectorを持つって事？

858 ：名前は開発中のものです。：2007/11/27(火) 01:02:58 ID:uRAEiYZn

総当りの判定は避けるべきであって、
これは弾同士の判定でも同様であり、
実際に総当り判定を避ける手段はいくらでもある。

よって総当り判定に関する議論をするにあたって、
弾同士の判定は不適切であり、
議論の収束を見ないのは明らかである。

ほんと、馬鹿に付ける薬はないな。

859 ：名前は開発中のものです。：2007/11/27(火) 01:14:15 ID:M9k+XAkU

総当り判定することが前提の話だと思ってたのか・・・低レベルだなぁ
暫く放置しとこう、色々面白いこと言ってくれそうだし

860 ：名前は開発中のものです。：2007/11/27(火) 01:26:50 ID:WmLtqP1H

>>857
std::vector+>>774のやり方の場合
要素はソート済みである必要無しという前提ですから
std::vectorへの要素追加は常にpush_back()
要素削除は常にpop_back()です

＞敵毎に弾のvectorを持つって事？

はい。親(敵)が子(弾)のvectorを持ちます

861 ：名前は開発中のものです。：2007/11/27(火) 01:52:30 ID:S6ilEu/w

多分誰も相手してくれないのに嫌気して
ステレオタイプな煽りをしてきてるんじゃないかのう
無駄にスレ伸びるし疑心暗鬼な空気になるし本当迷惑なはなしだ

適当に空気読まず書いちゃいなよ
んでつっこみ要素でも入れときゃいいじゃん誤字とか

862 ：名前は開発中のものです。：2007/11/27(火) 02:18:20 ID:wmmwA/ZN

>>860
容量を超えて要素が追加される時、vectorは容量の大きい配列を新しく作成して、元のコピー/破棄を行うそうな
つまりメモリの再割り当てが発生する訳で、push_back()でもこれは同じ
あらかじめ容量を指定しておけば防げるけど、それだと固定配列使ってるのと同じで、1フレームに最大のオブジェクト数がいくらになるか考えながら作らなきゃならなくなる

>erase()予定の要素を別のvectorに保持してUpdate用の走査終了後にまとめて削除
100個ある要素のうち2番目と5番目を削除したい場合
1.2と5というインデックスを別vectorに保存
2.要素3、4、6～最後までを前ににずらす（コピー）
3.最後尾の要素を2つ削除
4.別vectorに保存した内容をクリア
ってなると思うけど、2.のコピーのコストが無駄じゃない？敵弾にしろ自機弾にしろ、先に生成された方が早く削除されるだろうから、こういうケースは常にあると思うんだけど
それにわざわざ削除用のvectorを持って、それを見ながら削除するってコード書かなきゃならないのは面倒だと思う

>親(敵)が子(弾)のvectorを持ちます
描画する時どうするの？
接敵して倒したら敵の下に別の敵の弾があった、なんてならないように全ての敵を描画→全ての弾を描画って処理にすると思うけど、この場合
1.敵のvectorを描画
2.敵のvectorを検査して弾のvectorがあれば描画
って事になるよね
敵のvectorを検査するコスト分余計じゃない？

863 ：名前は開発中のものです。：2007/11/27(火) 09:12:15 ID:sqxvoHfT

総当り判定を、エリア分割によって一部にするとしても、そのエリアの中では「総当り」なわけなんだけどねぇ…。
エリア分割だのは「（エリアごとの）総当り判定の総量を減らすテクニック」であって、総当り判定をしないテクニックではない。
当然有意義なテクニックだけど、論点ではない。

>>847
時間更新　＞　衝突判定　＞　描画　でもＯＫ
結局、衝突判定タスク（ビリヤード玉総当り判定タスク）は玉タスクの中身（座標とか）を直接書き換えるわけにはいかないと考えたんだ。

だから描画には影響しないので、時間更新と衝突判定の順番はどちらでも構わないかなと思った。

俺の脳内設計だと、衝突判定タスクは、玉タスク内の「発生イベント保存キュー」のみ例外的に書き込みOKとし、そこに「お前は誰と当たったぞ」と書き込む。
書き込まれた玉は自分のupdate()内でキューを調べ「あ、俺あいつと当たったらしい。計算して方向変えて動こう」と自己更新をする。
って感じ。

864 ：名前は開発中のものです。：2007/11/27(火) 09:41:04 ID:M9k+XAkU

>>863
衝突判定したあとに移動させるタイミングが無いために
弾が別の弾にめり込んだまま表示される可能性が高い？
この1フレーム遅延を許容するのであれば全く問題なさそう。

衝突判定した後、描画の前にもう一度オブジェクトに対して
何らかの動作をさせるタイミングはあってもいいと思う。
これは全オブジェクトに対して呼び出すのではなく、
衝突タスク側から衝突した物体に対してコールバックを返す。

並列性については、衝突可能性のある群の中だけスレッドセーフであればよいのだから、
その群ごとに並列タスクとして分割されていれば問題ないはず。
(逆に言うと、この粒度で並列タスクにした場合、巨大な群が1個できると全く並列化されない)

あと、その群以外のところに影響を及ぼすような「ゲーム的」な仕組みがあると、
それはそれで気をつけなきゃなんないな。

865 ：名前は開発中のものです。：2007/11/27(火) 10:08:07 ID:wvXzVuoh

>>863
話の流れとは関係ないけど s/タスク// しても話が通じるあたりがこのスレ的におもしろい。
「タスク」の情報量ゼロ、みたいな。

866 ：名前は開発中のものです。：2007/11/27(火) 14:12:22 ID:WmLtqP1H

>>862
そりゃreserve()での設定数を超えればそうなっちゃうけど
普通はそうならないように使うもんじゃない？
STGに限らず（ステージとか弾幕を）作ってる段階で
リソースの使われ方は測定してるはずだし

手間だから嫌と言われたらそれまでだけど

＞2.要素3、4、6～最後までを前ににずらす（コピー）

6～最後までを前にずらす（コピー）必要あるのかな？
　・2番目要素に100番目要素を上書き
　・5番目要素に 99番目要素を上書き
で2要素削除にコピーは2要素分で済むんじゃない？

＞それにわざわざ削除用のvectorを持って、それを見ながら削除するってコード書かなきゃならないのは面倒だと思う

これは、同一vector内の要素同士が参照するような場合
例えば相互に当たり判定などの作用があるとか
つまり走査終了後でないと要素を削除できない場合に
仕方なくの「後でまとめて削除用vector」だから
（要素内に削除フラグを立てておいて後でもう一回走査でもいいけど）

弾とか、走査中に要素を削除(末尾要素で上書き+pop_back())しても
構わないものなら、これは要らないです

867 ：名前は開発中のものです。：2007/11/27(火) 14:13:10 ID:WmLtqP1H

>>862
＞描画する時どうするの？

描画優先順位は、アルファブレンドなしにすればZバッファにまかせて
気にしないで済む手もあるし、描画優先順位が必要な場合でも
描画コマンドを送るバッファを描画優先順位別に用意すれば済むと
思うんだけど、そういう話じゃないの？
例えばD3Dなら敵用と弾用の頂点バッファを分けておくとかさ

敵vector走査
{
　敵(親)をUPDATE
　敵の頂点バッファに追加
　弾(子)vector走査
　{
　　弾(子)UPDATE
　　弾の頂点バッファに追加
　}
}
敵の頂点バッファをDrawPrimitive
弾(親無し)vector走査
{
　弾UPDATE
　弾の頂点バッファに追加
}
弾の頂点バッファをDrawPrimitive

実際はマテリアル別で分けたりするから
もうちょっと違うけど

868 ：名前は開発中のものです。：2007/11/27(火) 15:23:09 ID:sqxvoHfT

>>866
＞そりゃreserve()での設定数を超えればそうなっちゃうけど
＞普通はそうならないように使うもんじゃない？

お前が他の人から配列厨って言われた理由がよくわかった

869 ：名前は開発中のものです。：2007/11/27(火) 15:26:39 ID:WmLtqP1H

ちがいますよ。僕もタスクシステム厨です
仲間はずれにしないでください！

870 ：名前は開発中のものです。：2007/11/27(火) 16:18:17 ID:J17yjuyb

で、結局タスクシステムってなんなわけ？

871 ：名前は開発中のものです。：2007/11/27(火) 20:15:10 ID:eAgI6nxr

>>870
ネタにしつつ、おっさんたちが罵倒しあって遊ぶ、おとなのおもちゃ。

872 ：名前は開発中のものです。：2007/11/27(火) 22:30:26 ID:M9k+XAkU

タスクシステムとあんまり関係ないけど
STGの弾の描画順序は維持したほうがいいお( ^ω^)
高密度弾幕の描画順序は見栄えに影響するから

873 ：名前は開発中のものです。：2007/11/27(火) 22:38:46 ID:RJTn8bnA

>>872
たしかにZオーダーがかわるとちらつきまくるんだよね弾幕。

874 ：名前は開発中のものです。：2007/11/27(火) 22:39:37 ID:v3jlU6Mc

STGでタスクシステム使うときは敵の弾と自機は爆発エフェクトより後に描いてくれ。
多少は不自然になってもいいから。グラVとか自機が見えにくすぎる。

875 ：名前は開発中のものです。：2007/11/27(火) 23:01:57 ID:J17yjuyb

>>475 >>790
> enum TASK_PRIO { TASK_PRIO_PLAYER, TASK_PRIO_ENEMY, TASK_PRIO_MAX };
>
> struct ITask;
> typedef std::list<ITask*> TaskList;
> TaskList task_list[TASK_PRIO_MAX];
>
> void add(ITask* task, TASK_PRIO prio) { task_list[prio].push_back(task); }

こうやった場合、Enemyクラスにだけあるメソッドを使いたいときとかどうするん？

876 ：名前は開発中のものです。：2007/11/28(水) 00:04:38 ID:PoA8ANLC

分かるように書いてくれ

hoge->funcsion(Enemy)
なのか
enemy->function
なのかすらわからん

877 ：名前は開発中のものです。：2007/11/28(水) 00:24:47 ID:dzRprFna

>>876
「Enemyクラスにだけあるメソッド」を普通に解釈したら
> enemy->function
になるかと。

878 ：名前は開発中のものです。：2007/11/28(水) 00:33:00 ID:3lJuBHag

>>877ならダウンキャストだし>>876の前者ならVisitorパターンかな。
ダウンキャストはやりたくねーな。
そもそもそんな管理するなって話だけども

879 ：名前は開発中のものです。：2007/11/28(水) 00:37:14 ID:PoA8ANLC

Enemyクラスにだけ有るメソッドを～
じゃなくて
Enemyクラスにだけ（と）あるメソッドを～
と解釈してしまったｗ

>>878
別にダウンキャストはたいした問題ではないと思う
ダウンキャストの危険性は「正当であることが保証されない場所」で使う時だけの問題
保証されているのならコストすら（最適化で消えるから）まったくかからないわけで。

880 ：名前は開発中のものです。：2007/11/28(水) 00:46:30 ID:dzRprFna

>>879
なんでわざわざこんなことをするんだ？
>>535 >>592の発展系でいけば
ダウンキャストとか必要ないよ？

881 ：名前は開発中のものです。：2007/11/28(水) 00:47:22 ID:ZHOBkYqT

>>866-867
その配列の使い方(>>774)に名前があるのか俺は知らんのだが
3D用のパーティクル描画とかに向いてるんじゃないか？
「加算合成のみ」とか「半透明一切無し」のエフェクト限定だけど

882 ：名前は開発中のものです。：2007/11/28(水) 00:48:41 ID:3lJuBHag

>>879
ダウンキャスト前提の設計を平気でするのは
あんまり良くないと思うけれどねぇ。
せっかくの静的型付け言語の利点が…

883 ：名前は開発中のものです。：2007/11/28(水) 01:31:34 ID:vLgLgDKq

>>879
ダウンキャストによる実行時コストが最適化で消えることなんてあるの？
最初から（またはマクロ切り替えで） static_cast 使ってたときの話じゃない？

884 ：名前は開発中のものです。：2007/11/28(水) 06:57:46 ID:/8z2N8vB

>>875
そもそもITaskしかもってない人がどうやってEnemyと他を見分けるの？
ダウンキャストうんぬん以前に

885 ：名前は開発中のものです。：2007/11/28(水) 11:54:43 ID:pyYH3RO3

>>880
深い意味はないよ
「PRI_XXXのenumと追加削除するだけで、自動的にプライオリティーリストが伸び縮みしてくれるね」くらいの利点しかない。
型情報のほうが重要で、タスクリストを取得する際に
(こういうのを作ればの話だが↓)
(list< shared_ptr<CEnemy> >*)getTaskList(PRI_PLAYER);
とかやっちゃう馬鹿がプロジェクト内にいるのなら、名前でいちいち作っていったほうがいいと思う。
俺だったらそもそもTaskListをgetなんてできるようには作らないが。

>>882
だから、「絶対に保証されてる時」だけにするべきでしょ。
まぁ俺も「ダウンキャストしたくなる状況」が発生したことないんだけどな…。

>>875は「タスクリストを巡回呼び出ししているクラス」に、task()の呼び出し以外をさせようとしていることがおかしいわけで。
Enemyはそれ自身で、その「特別呼び出したいメソッド」をtask()内から自発的に呼び出すべき。

>>883
static_cast使った時だよ。
保証されてるのにdynamic_cast使うとかありえん

886 ：名前は開発中のものです。：2007/11/28(水) 15:20:07 ID:Sv8VcBqw

879 ：名前は開発中のものです。：2007/11/28(水) 00:37:14 ID:PoA8ANLC
　　別に糞食はたいした問題ではないと思う
　　糞食の危険性は「安全であることが保証されない場所」で食う時だけの問題
　　保証されているのなら食中毒リスクすら（熱処理で消えるから）まったくないわけで。

880 ：名前は開発中のものです。：2007/11/28(水) 00:46:30 ID:dzRprFna
　　>>879
　　なんでわざわざそんなことをするんだ？
　　>>535 >>592（カレー）の発展系（ウンコ味のカレー）でいけば
　　糞食とか必要ないよ？

882 ：名前は開発中のものです。：2007/11/28(水) 00:48:41 ID:3lJuBHag
　　>>882
　　糞食前提の食生活を平気でするのは
　　あんまり良くないと思うけれどねぇ。
　　せっかくの食物連鎖の頂点たるヒト科の利点が…

883 ：名前は開発中のものです。：2007/11/28(水) 01:31:34 ID:vLgLgDKq
　　>>879
　　糞食による食中毒リスクが熱処理で消えることなんてあるの？
　　最初から（またはサンプルすり替えで）カレーを使ってたときの話じゃない？

884 ：名前は開発中のものです。：2007/11/28(水) 06:57:46 ID:/8z2N8vB
>>875
そもそも鼻が詰まってる人がどうやってカレーとウンコを見分けるの？
糞食うんぬん以前に

887 ：名前は開発中のものです。：2007/11/28(水) 15:21:47 ID:Sv8VcBqw

885 ：名前は開発中のものです。：2007/11/28(水) 11:54:43 ID:pyYH3RO3
　　>>882
　　だから、「食っても絶対に安全と保証されてる時」だけにするべきでしょ。
　　まぁ俺も「ウンコを食いたくなる状況」が発生したことないんだけどな…。

　　>>883
　　カレーの話だよ。
　　（食ったら腹壊すのが）保証されてるのに本物を食うとかありえん

888 ：名前は開発中のものです。：2007/11/28(水) 15:38:59 ID:G8c5SPGF

またシャワートイレ板か

889 ：名前は開発中のものです。：2007/11/28(水) 20:41:43 ID:CdwaqKsV

>>885
> >>875は「タスクリストを巡回呼び出ししているクラス」に、task()の呼び出し以外をさせようとしていることがおかしいわけで。
シューティングゲームで、たとえばプレイヤーの弾と敵の当たり判定とか、どう実装する？

もしマネージャーにプレイヤー弾・敵を集約させてるなら、ベタに書くとこんな実装が
考えられるわけだが。プレイヤー弾・敵に固有のメソッド呼び出しが必要になるっしょ。

class Manager {
　IPlayer* m_player;
　std::list<IPlayerShot*> m_pl_shots;
　std::list<IEnemy*> m_enemies;

public:
　void update()
　{
　　m_player->update(this);
　　std::foreach(m_pl_shots.begin(), m_pl_shots.end(); boost::bind(&IPlayer::update, ::_1, this);
　　std::foreach(m_enemies.begin(), m_enemies.end(); boost::bind(&IPlayer::update, ::_1, this);
　　hit_check();
　}

　void hit_check()
　{
　　for (iterator i = m_pl_shots.begin(); i != m_pl_shots.end(); ++i)
　　　　for (iterator j = m_enemies.begin(), j != m_enemies.end(); ++j)
　　　　　　if (distance(i->getPos(), j->getPos()) <= PL_SHOT_RADIUS)
　　　　　　　　i->hit(), j->hit();
　}
};

890 ：名前は開発中のものです。：2007/11/28(水) 22:24:54 ID:3lJuBHag

>>885
人間が新しく作ったルールによって保障しているのが問題、
ということを言ってるんだけどなぁ。
そういうルールは少ないほうがいいですよ。

891 ：名前は開発中のものです。：2007/11/28(水) 22:55:42 ID:3lJuBHag

あと、あまり本質的な話じゃないんだけど、

> void add(ITask* task, TASK_PRIO prio) { task_list[prio].push_back(task); }

この仕組みでstatic_cast前提はまずいっすね。

void add( IEnemy* enemy ) { task_list[ENEMY_PRIO].push_back(enemy); }

で少しは良くなる。task_listが他から変な使い方されてなければ保障の確認が楽です。
前者の場合はバグった時がやばい。登録タイミングを列挙して確認しなきゃならんです。

敵を3段階くらいの優先度に分ける、っていうなら最悪これくらいはする。

void add( IEnemy* enemy, int prio )
{ assert( 0 <= prio && prio < 3 ); task_list[ENEMY_PRIO+prio].push_back(enemy); }

Enemyを適切でない優先度に登録する奴が悪い、っていうのは通用しません。
登録できるようにしてあること自体が悪です。
前者みたいなコードを書いて実際にバグ起こされて
クラス利用側のプログラマの責任にするような奴は考え方を改めなおしてほしい(# ^ω^)

892 ：名前は開発中のものです。：2007/11/28(水) 23:18:14 ID:zTThZTB6

スキーマでもいれとけｗ

893 ：名前は開発中のものです。：2007/11/28(水) 23:23:02 ID:G8c5SPGF

戦車の土台に
戦車の砲台に
空中戦艦の土台に
空中戦艦の土台に
ヘリの本体に
ヘリのローター
6段階で分けてる俺の勝ちだな！
重なったときこのリストの下から順にアクティブになるように組んでる。

ってここSTGスレじゃないじゃん・・・

894 ：名前は開発中のものです。：2007/11/28(水) 23:23:22 ID:Qw3YeApb

通常こういうエラーチェックはデバッグ版のみ組み込みで、利用側の責任で使用だろ。
と思うんだけど。

895 ：名前は開発中のものです。：2007/11/28(水) 23:31:07 ID:dzRprFna

>>894
やむを得ない場合はしょうがないけど、
他にたくさん方法があるのに、わざわざ余計なチェックが必要で
拡張性に劣る方法を選ぶのは賢いとはいえないと思う。

896 ：名前は開発中のものです。：2007/11/29(木) 00:04:16 ID:C4K4weZ1

誤ったダウンキャストは、デバッガがブレークしてくれるから心配ないだろ
addEnemy
addPlayer
addField
addMenu
addHoge
...
俺はやだなぁ

897 ：名前は開発中のものです。：2007/11/29(木) 00:07:59 ID:C4K4weZ1

>>891
あと、
＞Enemyを適切でない優先度に登録する奴が悪い、っていうのは通用しません。
こうは言うけど、そんなことやる部下って結局
constなのに中でconst_castして外したり
addEnemy((Enemy*)&player);とかやってくれたり
NULL突っ込んだり
純粋関数にしろっていってるのに実は外部参照したり
と何から何までやってくれる

いや、単なる実体験なんだけどね…次からプロジェクトに入れないようにしたけど

898 ：名前は開発中のものです。：2007/11/29(木) 00:24:05 ID:gMxLNkiz

メモリ効率だの線形リストだのオマエラの難しい話はよー分からんが
ピーク時のオブジェクト数でヌルヌルになるよう最初に確保しとけでいいじゃん

899 ：名前は開発中のものです。：2007/11/29(木) 00:28:16 ID:okaXHR4o

馬鹿はどんな防護策も破ってくれるっていうのはまぁそうなんだけど
それでも出来る限りの「誤用しにくく、正しく扱い易いインタフェース」を用意する努力をするのは必要でしょう

900 ：名前は開発中のものです。：2007/11/29(木) 00:28:27 ID:pyR553/m

だいたい拡張なんたらなんてそもそもいるのか？
俺はもうゲーム作りはじめて１０年ぐれーになるけど

タイプNで定義された敵を２つの方法で生成したことは生涯１度としてないといっておくｗ
addXXXとか生成まっしーんなんて作ってるけどどうせ１回なんでしょ？？

この辺真面目な話クラスで作らないほうがいいと思ってたりして・・・
面倒っちぃだけなんだよね

901 ：名前は開発中のものです。：2007/11/29(木) 00:28:36 ID:C4K4weZ1

Factoryパターン使ってるから、そもそもaddEnemyとか使えないや、俺のやつ。
まぁ、Taskクラス自体にgetPriority()const=0;のオーバーライドを強制して、登録機構にそこ参照させるのもいいかもね

902 ：名前は開発中のものです。：2007/11/29(木) 00:37:25 ID:pyR553/m

何を気にして可変長にして汎用性を持たせようとしてるのか気になる
すげー面倒な上に必要のねぇ作業ばっかり増えないか？
そのせいでおこるバグのが多そう・・・

903 ：名前は開発中のものです。：2007/11/29(木) 00:46:26 ID:C4K4weZ1

とりあえずそのあたりはほっといて、もっと実のある話しないか？
概ね
・複数のタスクリストは毎フレーム、プライオリティ順に巡回処理が行なわれる
・同じタスクリストの中にいるタスク同士は、参照しあわない
あたりでコンセンサスとれたんだし

904 ：名前は開発中のものです。：2007/11/29(木) 01:00:00 ID:SYEtwFXl

>>900
誤解があるとまずいのだけど、自分の指す「拡張性」というのはサイズを可変にすることではないよ。
>>875のやりかたを使うと、Enemyに独自のメソッドを使うたびにダウンキャストが必要になる。
たとえば、自機のホーミングが自機に一番近い敵を探すだけでも
ダウンキャストが必要になりそうな感じ。>>889もどうやるか知りたい。
拡張性といってもそんなに面倒なことにはならないよ。
マネージャを作って、敵オブジェクトは敵だけが入ったリストで管理するだけ。
それだけで、あたり判定も特定の条件の敵を見つけることも素直にできるようになる。
なぜそれをしないのかが自分には分からないんだよ。

905 ：名前は開発中のものです。：2007/11/29(木) 05:41:40 ID:ULxUnfQv

俺のITaskにはvirtual float GetPriority() = 0;てのがある

906 ：名前は開発中のものです。：2007/11/29(木) 07:02:05 ID:pyR553/m

>>904
だからすでにさ
クラスっていう機構そのものがゲーム作るのに邪魔になってるだけだろ？
だから型を誤魔化したりしてるのを汎用性とか表現しちゃうわけでよ

907 ：名前は開発中のものです。：2007/11/29(木) 07:12:02 ID:YiNA0Nmf

>>906
> クラスっていう機構そのものがゲーム作るのに邪魔になってるだけだろ？
>>889 では全然邪魔になってないけど。

908 ：名前は開発中のものです。：2007/11/29(木) 07:16:15 ID:YiNA0Nmf

>>896
> 誤ったダウンキャストは、デバッガがブレークしてくれるから心配ないだろ
static_cast だと、黙ってメモリ壊すだけだが。

dynamic_cast だと NULL が返ってくる（ポインタ）もしくは例外が飛んでくる
（参照）けど。

909 ：名前は開発中のものです。：2007/11/29(木) 21:16:20 ID:gMxLNkiz

TCBとストラテジーパターンでいいじゃん。
タスクリストも複数に分ければいいじゃん。
C++じゃなくてC/C++でいいじゃん。割り切ろうよ。

910 ：名前は開発中のものです。：2007/11/29(木) 21:37:21 ID:YiNA0Nmf

>>909
> TCBとストラテジーパターンでいいじゃん。
TCBなんているのか？　ふつーに new すれば良いだけの様な気がするんだが。

参考までにコードの雛形出してもらえるとうれしい。

911 ：名前は開発中のものです。：2007/11/29(木) 22:13:27 ID:gMxLNkiz

ん？アロケートを気にしないならおいらもnewでいいとおもうよ。

それはおいといて、
↓くらいのをピーク状態に合わせて調節してく感じ。
int priority;
int (*action) (void* tekitou);
/* int draw_priority */
int (*draw) (void* tekitou);
char work[1024];

シンプルすぎてレスに困るだろうが。

912 ：名前は開発中のものです。：2007/11/30(金) 00:16:33 ID:O51oYaM6

>>911
そのやり方はたしかにアロケートによる速度低下は避けられる。
（これでゲーム全体が何パーセント速くなるかは知らないけど）

問題は>>875と同じような問題が起こること。
例えば、あたり判定とか一番瀕死な敵を探し出すとかする場合、いったいどうするわけ？
それとも、Cだからキャスト前提でプログラミングをするということかな？

少なくとも自分は、アロケートを避けることよりも型安全の方が１００倍大事だと思う。
>>535のやり方でも、工夫すればかなりの程度アロケートは避けられるしね。

913 ：名前は開発中のものです。：2007/11/30(金) 00:27:58 ID:zbV4iUzK

>>912
＞少なくとも自分は、アロケートを避けることよりも型安全の方が１００倍大事だと思う。

結局、富豪的に書くべきか速度最優先かのテーマになっちゃうわけね。
このスレの永遠のテーマだな。

914 ：名前は開発中のものです。：2007/11/30(金) 01:00:05 ID:wOnw0/Ft

>>912
ん？おいらも書くのは>>535だよ。
裏方、プレイヤー、敵みたいなのはリストを分けちゃう。
分かりきった序列まで優先度で管理したくないし、
コードレベルでの再利用性もよいし。

915 ：名前は開発中のものです。：2007/11/30(金) 01:02:27 ID:v3wl0JHM

>>535の人気に嫉妬

916 ：名前は開発中のものです。：2007/11/30(金) 01:07:20 ID:bvzRKdG3

>>913
>富豪的に書くべきか速度最優先かのテーマ
基本的な事を聞くようだけど、速いのか？
例えば、一番瀕死な敵を探し出すとかする場合、>>535のやり方の方が速そうなんだが。

917 ：名前は開発中のものです。：2007/11/30(金) 01:14:13 ID:WGafRUWS

ていうか、マジでゲーム仕上げ用とするときに>>535の
箇所のルーチンってかなり複雑になるじゃん
これをプライオリティで管理するのってほぼ不可能だと思うんだけど

開発終盤になったら綺麗だとかなんだとか言ってらんないしね
if文とswitch文の嵐になる
こんなんにプライオリティつけてたらまちがいなく死ぬ・・・
だから>>535の箇所をタスク管理にするとバグる
よっぽど頭どうかしてる奴じゃないと管理しきれない

918 ：名前は開発中のものです。：2007/11/30(金) 01:16:17 ID:wOnw0/Ft

>>916（横レスになるかな？）
それ逐次アロケートと事前アロケートの問題とは無関係じゃないの？
正直質問の意図がわからなかったんだけど、普通にエネミーさんから探します。

919 ：名前は開発中のものです。：2007/11/30(金) 02:01:05 ID:bvzRKdG3

>>918
ごめん書き込む前にリロードしてなかった。
>>914見てなくて、型安全を犠牲にして>>875みたいに全部のタスクを纏めるか、>>535みたいに分けるかって事だと思った。

920 ：名前は開発中のものです。：2007/11/30(金) 05:49:41 ID:PbVPMUGI

>>911
メモリアロケート気にするなら pool しとくか、基底クラスで operator new 定義
してやれば良いだけだと思うが。

921 ：名前は開発中のものです。：2007/11/30(金) 11:24:50 ID:O51oYaM6

>>913
ところで速度は実測が基本なわけだけど、ゲーム速度を実際に計ったはことある？
計ったことがあるなら、newするときとしないときで何パーセント程度の違いがあった？
ゲームで時間がかかるのはもっぱら描画なんだから、アロケートの時間なんてほとんど誤差範囲だよ

>>914
「ん？」はこっちのセリフだｗ
>>912は>>911の内容に対してのレスなので、
>>913が実際にどんな手法を用いてゲームを作っているかなんて
聞いてもいないし話題にもなってないよ。

922 ：名前は開発中のものです。：2007/11/30(金) 13:06:25 ID:qeDMKNbV

>>921
＞ゲームで時間がかかるのはもっぱら描画なんだから、アロケートの時間なんてほとんど誤差範囲だよ

んなことねえ。
メモリのフラグメントが進んでくると実測しても誤差範囲じゃすまねえ。

923 ：名前は開発中のものです。：2007/11/30(金) 13:26:00 ID:O51oYaM6

>>922
何パーセント違ったの？

924 ：名前は開発中のものです。：2007/11/30(金) 13:44:02 ID:qeDMKNbV

>>923
質問ばっかりせずに
たまには自分で実測してみやがれ

925 ：名前は開発中のものです。：2007/11/30(金) 13:52:09 ID:O51oYaM6

>>924
なんじゃそりゃｗ

> メモリのフラグメントが進んでくると実測しても誤差範囲じゃすまねえ。
と言ってるから何パーセント違ったのか聞いただけだけど＾＾
だって実測したんでしょ？
実測した数字があるのに、なぜに新たに測らないといかんのさ。
もし実測してないなら、この文の根拠はいったい何なわけ？

926 ：名前は開発中のものです。：2007/11/30(金) 13:52:35 ID:oJ+rl31r

この話の流れだとqeDMKNbVが数値出さなきゃ意味がない気がするが
想定している状況によって結果は変わるんだから
O51oYaM6がやったら差はありませんでした、で終わるだけだろ

927 ：名前は開発中のものです。：2007/11/30(金) 13:59:12 ID:qeDMKNbV

>>925
なんじゃそりゃじゃねーよ阿呆。
お前の言うパーセントってのが何を表すパーセントなのかそもそもお前がはっきりさせてないから
こちらが明言できるわけもないだろうが。

しかも誤差範囲内だとお前が明言しているお前も当然実測しているんだろうなあ？

928 ：名前は開発中のものです。：2007/11/30(金) 14:09:39 ID:SmKEHf+f

誤差範囲ってのがまた曖昧な言葉だねぃ。
まあなんつーか、60FPSでおさまる分のアロケートなら誤差範囲ってことでいいのかもしらんけど、
実際例として、敵が増えてくると当たり判定だけでFPSが落ちてきかねないから、
対策立てないといけないってなことを考えると、
決して描画以外の処理は、描画とは時間オーダーが違うから、処理時間を無視できるってのは言えないと思う。アロケートもしかり。
おそらく、タスクが山のように増えてくると、アロケートだけでもFPSに影響が出てくることはそれほど想像にかたくはないね。

929 ：名前は開発中のものです。：2007/11/30(金) 14:43:12 ID:jMpOGHCy

　 /＼＿＿_／＼
／　／　　　ヽ ::: ＼
|　（●）,　、（●）、　| 　　／￣￣￣￣￣￣￣
|　　,,ノ(、_, )ヽ、,, 　 | 　＜　まーたはじまった
|　　　,;‐＝‐ヽ　 .:::::| 　　＼＿＿＿＿＿＿＿
＼　　｀ニニ´　 .:::／
／｀ー‐--‐‐―´´＼

930 ：名前は開発中のものです。：2007/11/30(金) 14:45:53 ID:O51oYaM6

>>927
パーセントは普通に考えると、１フレーム時間の比較じゃないか？　FPSでもいいけど。
ゲームの処理時間全体に対するアロケートの時間の割合を測りたいんだから、
newを使ったときとそれ以外の方法を使わなかったときの
１フレームの時間の割合を比較すればパーセンテージは普通にでるぞ。

まあゲームの種類によっても差が出る。これは認める。
それからここまで書いておいてなんだけど、自分も正確な実測はしたことがない。
ただ、シミュレーションのようなアップデートに異常に時間のかかるゲームでも無い限り
　・ゲーム時間の７～８割をしめるのが描画
　　（描画のみをしない場合はFPSが跳ね上がるし、人の話を聞く限りでも間違いない）
　・１割程度がサウンド
　・他、オブジェクトのアップデートやらなんやら
というのがだいたいのゲーム処理時間の内訳ではなかろうか。
この前提で、アロケートの手段を変えることで実時間に優位な差（だいたい５～１０％以上くらいか？）が
出ることはあり得ない（というかかなりゲームを選ぶ）と考えている。
少なくとも自分のゲームではそうだし、アロケートのやり方を変えてもFPSが変わることは無かった。
（boost::poolを使っても全く速くならないことにすごいショックを受けた）

問題は超絶弾幕シューティングやタスクが山のように出てくるゲームなんだろうけど、
例えば弾幕でもメモリの確保と解放を繰り返してるうちは
メモリフラグメンテーションというのはなりにくい。
弾が現れては消えることを繰り返すシューティングなんかではその点でも、
アロケートが速度低下の要因にはなりにくいと考える。

タスクがたくさん出てくるゲームというのは、ゲームによるとしか言いようがないが
もしアロケートのやり方でそんなに処理時間が変わるなら
その実例を見せて欲しいというのが正直な気持ち。

931 ：名前は開発中のものです。：2007/11/30(金) 14:53:23 ID:O51oYaM6

>>930
> （boost::poolを使っても全く速くならないことにすごいショックを受けた）
これは嘘だったかも。
ただ、ノーウェイト状態のFPS換算でたまに１～２ずれるくらいしか違わなかった。
６０FPSや３０FPSで律速すれば全く分からなくなる程度。

932 ：名前は開発中のものです。：2007/11/30(金) 19:22:00 ID:wOnw0/Ft

>>921
ん？なんでおいらのレスが>>913と関係あるんだ？

933 ：名前は開発中のものです。：2007/11/30(金) 20:49:53 ID:pJlEHrxF

>>167

ならクロスするドットは全部同時に光るだろ

934 ：名前は開発中のものです。：2007/11/30(金) 21:18:36 ID:O51oYaM6

>>932
ああ。それは>>914の間違い。>>914のやり方は聞いておらん。

> メモリのフラグメントが進んでくると実測しても誤差範囲じゃすまねえ。
ところで、このレスの根拠はいったい何なわけ？
正確じゃなくてもある程度、実測に近いことはしたんでしょ？
どのような状況でどの程度遅くなったか教えて欲しいのだけど。

935 ：名前は開発中のものです。：2007/11/30(金) 21:49:49 ID:wOnw0/Ft

>>934
> 問題は>>875と同じような問題が起こること。
が、起き得ない回答なんだけど、ちょっと文盲過ぎないかい？

936 ：名前は開発中のものです。：2007/11/30(金) 22:21:51 ID:O51oYaM6

>>935
残念ながら何を言いたいのか分からない。
>>911のやり方は確実にダウンキャストを引き起こすだろうし、
それが自分の指している「問題」なわけだけど。
それに、そんなことよりも>>934に答えて欲しい。

937 ：名前は開発中のものです。：2007/11/30(金) 22:22:55 ID:fM2BxYqw

>>930
メモリアロケータの自前実装はシステムの負荷をコントロールする上で有効。
ディスクアクセス等の比較的重い処理と、メモリ確保の処理を確実にかち合わないようにできる。
負荷分散について気をまわせるかどうかがキモなので、
メモリアロケータ単体だけで速度比較をしても意味が無い。

938 ：名前は開発中のものです。：2007/11/30(金) 22:35:15 ID:wOnw0/Ft

>>936
> >>911のやり方は確実にダウンキャストを引き起こすだろうし、
> それが自分の指している「問題」なわけだけど。
起きないし起き得ないとおいらは申してますが？
キミは>>535のソースすら読めないの？

あと>>922のレスはおいらのレスじゃないでしょ？
キミはいったい何と戦ってるの？

939 ：名前は開発中のものです。：2007/11/30(金) 22:45:23 ID:jMpOGHCy

文末にくっついてくる他人を罵る余計な一行を
消してから投稿すればいいだけなのに
どうしてそれができないのか
最後の一行選択範囲にしてDEL押すだけだよ

940 ：名前は開発中のものです。：2007/11/30(金) 22:48:27 ID:d5ZOv44s

>>939
何言ってんの？
この馬鹿は。

臭く、キモく、空気が読めない、現代の3Kのおっさんにとって、
他人を侮辱して優越感を得るのは決して外せない要素ッ！
侮辱しなければ投稿する意義そのものが消えるってもんよ。

分かったかこの糞坊主。
カス。クズ。ゴキブリ。ゴミ。

941 ：名前は開発中のものです。：2007/11/30(金) 22:55:52 ID:PbVPMUGI

>>940
うむ。頑張りは認める。

942 ：名前は開発中のものです。：2007/11/30(金) 23:02:49 ID:O51oYaM6

>>938
あれ？　>>911=>>914じゃないの？
>>912で>>911で問題を指摘したら、>>914で全くトンチンカンな回答が来たので意味が分からなかった。
それから、「問題が起きる」と言っているのは>>911のやり方についてだから、
少なくとも自分は>>535に関してはなにも言ってないよ。
もし、>>911と>>914が別人だったらスマソ。
あと ID:wOnw0/Ft Be:とID:qeDMKNbV Be:が同一人物に見えてしまったことは素直に謝る。

943 ：名前は開発中のものです。：2007/11/30(金) 23:10:33 ID:bvzRKdG3

>>942
>>911=>>914じゃないのか？
>裏方、プレイヤー、敵みたいなのはリストを分けちゃう。
って事だと思ったけど。

944 ：名前は開発中のものです。：2007/11/30(金) 23:14:04 ID:wOnw0/Ft

>>942
>>911と>>914は同じ人。
>>911を使っても>>535ならTCBをクラスに見立てた場合のダウンキャストは起きない。
enemyだのbulletだのの抽象クラスに変わるものは>>535には既にあるからね。
void* tekitouの部分がそれに見えたとしたなら、これは何でもいいという意味でしか書いていない。
workの参照をメンバに持つ構造体とでも読み替えればいい。

945 ：名前は開発中のものです。：2007/11/30(金) 23:35:19 ID:O51oYaM6

>>928
そのあたり、実際どうなんでしょうね。
自分にもnewをそのまま使えば、専用アロケーターより遅くなることは分かります。
ただ、それが実際どの程度ゲームに影響を及ぼすのか検討つかない部分があって、
実際にゲーム全体が遅くなったという結果があるならどの程度遅くなったのかが知りたいのです。

>>937
struct Task {
　int priority;
　int (*action) (void* tekitou);
　/* int draw_priority */
　int (*draw) (void* tekitou);
　char work[1024];
};
こんな風にしてプレイヤーや敵が同じTask構造体を使うということ？
でもこれで恒常的にキャストが発生しないように作るとなると、
それらをただ単に別に管理するだけでなくて、
struct Enemy {...} や struct Player {...} が必要になると思うのだけど、
もしかしてそういうこと？

946 ：945：2007/11/30(金) 23:37:49 ID:O51oYaM6

×>>937
○>>944

947 ：名前は開発中のものです。：2007/11/30(金) 23:42:12 ID:I886NHIO

速度よりもどっちかっつーと
メモリフラグメントによって大きな領域が割り当て不可能になるほうがずっと怖いなぁ

948 ：名前は開発中のものです。：2007/11/30(金) 23:53:48 ID:hz3mM0zw

>>945
前にSTG書いたときにオブジェクトをプールしてみたけど、最大で三倍くらい速くなった覚えがある
まともな評価をしたわけではないので当てにはならんけど

949 ：名前は開発中のものです。：2007/11/30(金) 23:57:46 ID:wOnw0/Ft

>>945
そう。work[1024]が既に構造体の場合もあってそれだけで完結することもある。
で、workをstruct Enemyに変換するのはダウンキャストではという疑問が湧いたとしたら、
そのTaskが何らかMobに始めて紐づく時にその型で初期化され、以後もその型で使える。
保障されてても型安全を問うなら、newのオーバーロードも似たようなもんですよと。

950 ：名前は開発中のものです。：2007/12/01(土) 00:12:55 ID:DRWaNadC

>>945
> こんな風にしてプレイヤーや敵が同じTask構造体を使うということ？
あ、これは自機が単独の場合（2DSTG）の場合は、おいらなら独立してるよ。
AIで動くかコントローラで動くかで分けるという括りのが実際的かな？

951 ：名前は開発中のものです。：2007/12/01(土) 01:42:57 ID:fKLLXVOB

>>948
一応、mallocだけの実測を行ってみたのですが、
６０FPSで１フレームごとに３００オブジェクトが生成されるようなすさまじいゲームでも
１秒間に必要な時間はmallocなら、
　・オブジェクトのサイズが1024byteで約30ms
　・オブジェクトのサイズが4096byteで約60ms
　・boost::poolではサイズ関係なくおおかた2ms
といったところでした。１秒間に60msも違えば、これは確かに相当な違いになります。
ただ、１フレーム３００オブジェクトというのは一般的なゲームではかなりあり得ない仮定ですし、
もし３０オブジェクトですむならmallocでも6msしかかかりません。
普通のゲームならばさらに差は縮まると思います。
体感で三倍というのは、相当オブジェクトの生成と解体を繰り返すゲームだったのでしょうか？

>>949
なーるほど。それならそのやり方の問題はEnemyやその他のオブジェクトに必要なサイズが
Taskを超えないことを保証できない点になるね。
例えば、Taskを使う新しい弾構造体を作った場合、それがTaskのサイズを超えない保証がどこにある？
常に適切なところでアサートなりなんなりする必要があるし、
もしそれを忘れてまずいことが起こってしまった場合でもキャストすれば
普通に動いてしまう（ように見える）よね。
一般的にこういうのは型安全とも保証とも言わないと思う（少なくとも自分なら言わない）。

952 ：名前は開発中のものです。：2007/12/01(土) 02:03:16 ID:my0CFAk6

オブジェクトの生成破棄のコストについてですが
アロケートと初期化のコストどっちが大きくなるんでしょうかね？
初期化のコストがおおきければアロケートについてのコストは殆ど問題
にならないと言うことになってしまいそうですが

953 ：名前は開発中のものです。：2007/12/01(土) 02:06:27 ID:DRWaNadC

>>951
超えない事を保障するのはworkの部分ね。union使えばいい。

954 ：名前は開発中のものです。：2007/12/01(土) 02:15:33 ID:qI4+0oAk

>>952
初期化のコストなんてたかが知れてる。

通常のヒープ割り当てなら相当に重い。
割り当てだけでなく開放も洒落にならない。

固定長ブロックみたいな単純なアルゴリズムならO(1)で済むけど、
大抵は汎用性かメモリ効率のどちらかが悪くなる。
例えば>>953の方法は多分こんな話なのかな。
union work { Enemy enemy; Player player; }
これだと固定長ブロックのタイプなので
高速に割り当てられるがメモリ効率は当然悪い。
(極端な話4バイトのタスクと1024バイトのタスクで割り当てられるサイズが同じになる)

955 ：名前は開発中のものです。：2007/12/01(土) 02:19:51 ID:h7ehhYV/

>>954
そりゃだってお前のマシンPen3のメモリ128Mだからじゃん

956 ：名前は開発中のものです。：2007/12/01(土) 02:26:47 ID:JLtAbSq2

いったいこの話はどこに着地すればいいんだ

957 ：名前は開発中のものです。：2007/12/01(土) 02:31:34 ID:fKLLXVOB

>>953
仮にunionでやったとしてもaction関数やdraw関数などのTask共通データ群を
確実に他のタスクの先頭に追加する必要もあります。
忘れた場合でも動いてしまうので、これでも安全とは言い難いです。
また、このやり方だと一つでもサイズの大きなオブジェクトがあった場合は
すべてのタスクがそれに合わせられることになります。

さらに言うなら、Task内部にunionを持たせるなら、Taskが他のすべての構造体の詳細を知っている必要があります。
Taskはほとんどすべてのソースから参照されていると思うので、
新たな敵の構造体やある敵に新たなフラグを追加するだけで
再コンパイルと同じようなことが必要になります。

これだけの困難を克服したとして、得られるものがプール配列の一本化と
アロケート時間の短縮だけだとしたら、あまりに意味がないと考えます。

958 ：名前は開発中のものです。：2007/12/01(土) 03:01:58 ID:fKLLXVOB

>>953
> 仮にunionでやったとしてもaction関数やdraw関数などのTask共通データ群を
> 確実に他のタスクの先頭に追加する必要もあります。
というのは間違いで、>>954が指すやり方かな？

struct Task {
　int priority;
　int (*action) (struct Task* tekitou);
　int (*draw) (struct Task* tekitou);

　/* 型別のワーク領域 */
　union work {Player player; Enemy enemy; };
};

使うときは obj.enemy.xxx とすると。
なんというか自分なら、どうせ別々に管理するんだからもっと素直にやればいいのにと思ってしまう。

959 ：名前は開発中のものです。：2007/12/01(土) 03:58:54 ID:qI4+0oAk

operator newを書き換えて固定幅ブロック返すのと何も変わらんな
vtableが埋め込みじゃないから関数呼び出しが多少早い程度。
publicもprivateもあったもんじゃないしさ

960 ：948：2007/12/01(土) 08:29:32 ID:NlUDPtwP

>>951
newそのままだと20fpsくらいだったのがプールに切り替えたら60fpsでたって感じだった。
実装がヘタレなだけかもしれんので気にしないでくれ

961 ：名前は開発中のものです。：2007/12/01(土) 09:23:54 ID:vkWQkVXN

>>958
C++ でふつーに書けば良いと思うんだが。action, draw の初期化ミスとか、union の使い分け
ミスって悲惨なバグに出くわすこともなくなるぞ。private, publicによるアクセス制御、constメンバ
関数なんかの恩恵も受けられるし。

でも、俺は実際にはほとんどのゲームオブジェクトは pimpl イディオムで書くけど。
ちょっとゲームオブジェクト追加しただけで、すぐフルビルドは嫌ん。

// あとでファクトリクラスとか作るときに MPL 使えるかもしれないので、TaskPrioValue 分けとく。
enum TASK_PRIO { TASK_PRIO_PLAYER, TASK_PRIO_ENEMY, TASK_PRIO_MAX };
template <typename T> struct TaskPrioValue;
struct ITask { virtual TASK_PRIO getPrio() const = 0; virtual void action() = 0; virtula void draw() = 0; };

template <typename T>
class TaskBase : public ITask
{
　static size_t TCB_SIZE = 4096;
　static size_t TCB_COUNT = 128;
　static char tcb[TCB_COUNT][TCB_SIZE];
public:
　// 固定長のメモリブロック TaskBase::tcb から切り出すように実装
　// 未使用tcb管理方法も適当に実装してくれ
　static void* operator new(size_t);
　virtual TASK_PRIO getPrio() const { return TaskPrioTag<T>::value; }
};

class Player : public TsakBase { ... };
template<> struct TaskPrioValue<Player> { static int const value = TASK_PRIO_PLAYER; }

class Enemy : public TsakBase { ... };
template<> struct TaskPrioValue<Enemy> { static int const value = TASK_PRIO_ENEMY; }

962 ：名前は開発中のものです。：2007/12/01(土) 09:37:31 ID:DRWaNadC

>>957
> このやり方だと一つでもサイズの大きなオブジェクトがあった場合は
前提がまずおかしいでしょ。何で行き成りそんなのが登場してんのさね。
>>913の言うところの富豪プログラムをしたいなら、素直に作ればいい。

> 再コンパイルと同じようなことが必要になります。
だから？としかいいようがないんだけど。
別においらはunion使わないけどね。workって最初はちょっと大きめに作るし。（1024もでかいじゃん）

> これだけの困難を克服したとして、得られるものがプール配列の一本化と
> アロケート時間の短縮だけだとしたら、あまりに意味がないと考えます。
キミのこのレスだけでも物凄く意味があるんだけど。
キミの使わない宣言はキミの自由だからそれでいいけどね。

感想レベルに落ち着いたようなのでおいらはここまで。（休日だしぃ）

963 ：名前は開発中のものです。：2007/12/01(土) 11:52:46 ID:yvTHCv1b

タスクシステムとはforeachの事らしい。
そりゃ無敵なわけだw

964 ：名前は開発中のものです。：2007/12/01(土) 13:07:04 ID:4ibPgTI7

まぁ今実装するならそうなるわな

965 ：名前は開発中のものです。：2007/12/01(土) 16:58:21 ID:qI4+0oAk

>>962
このレス面白いなあ

966 ：名前は開発中のものです。：2007/12/02(日) 00:50:25 ID:w6kaNHva

ここまで読んで

今時、こんなありふれた仕組みをわざわざタスクシステムとか呼ぶ必要なくね？
特に若い人間がさ。。。実際にこんな言葉を駆使してたら失笑される可能性大

未だにコピー機をゼロックスとか呼んでる化石人間を見たら、真似するかい？

967 ：名前は開発中のものです。：2007/12/02(日) 01:01:35 ID:97fpwlut

それは他に適切な名称が浸透してるから。
身内のみのローカルルールでもいいから定義して
それに名前を付けるのは、コミュニケーション上有効。

968 ：名前は開発中のものです。：2007/12/02(日) 01:09:02 ID:DIFJyPa0

デザインパターンみたいなもんだな

969 ：名前は開発中のものです。：2007/12/02(日) 01:19:30 ID:w6kaNHva

まぁ、身内のみのローカルルールっていう自覚があればいいんだけどね
実際このスレの人間見てると、そこんとこ勘違いしてる奴がちらほらいるでしょ

タスクシステム普及委員（タ普委）　：　このスレの中ではタスクシステムと呼びます。ローカルですよ。ローカル
　↓
（とりあえず皆が使う）
　↓
タ普委　　：　ほら！普及していますね！
　↓
一見さん　：　「タスクシステムってナニ？」
↓
タ普委　　：　そんなことも知らないんですか？常識ですよﾌﾟｯ

便所のラクガキといえど、仮にも技術系スレなんだから
オラが山の言葉を皆も使え、て言われてもしっくり来ないね

970 ：名前は開発中のものです。：2007/12/02(日) 15:55:35 ID:18YnXCnq

タスクシステムタスクシステム言っているけど
肝心のソースコードはどこで手に入るんだいハニー？

971 ：名前は開発中のものです。：2007/12/02(日) 17:10:56 ID:5bruwjoX

Logician Lordの記事を元に一度作ってみようかなと思ってる

972 ：名前は開発中のものです。：2007/12/02(日) 17:30:59 ID:YoiHVWjg

タスクシステムと掛けまして、初見のグラビアと解きます。

その心は、一度かけば醒める

973 ：名前は開発中のものです。：2007/12/02(日) 19:35:54 ID:diojMUPo

>>972
厨房は一度では醒めない。

974 ：名前は開発中のものです。：2007/12/02(日) 21:34:37 ID:Z0+0ddVz

君らは架空のタスクシステム厨を相手に何をしてるんだい。

975 ：名前は開発中のものです。：2007/12/02(日) 22:07:50 ID:sep9Dq5D

誠に残念なお知らせですが、僕がここに居座り続ける限り
タスクシステム厨を無かったことにしようとする試みは失敗します

976 ：名前は開発中のものです。：2007/12/03(月) 10:01:38 ID:x+N76yBh

過ぎれているものを中途はこれいかに？

977 ：名前は開発中のものです。：2007/12/03(月) 17:02:51 ID:hqsjjSWF

ネタなのか日本語が不自由なのか

978 ：名前は開発中のものです。：2007/12/03(月) 19:05:47 ID:yyMj+41M

このスレにはアンチタスクシステム厨しかいないと思うんだが。
タスクシステム厨ってもう絶滅間際なんじゃね。

979 ：名前は開発中のものです。：2007/12/03(月) 19:37:20 ID:wqCQySGa

このスレが立つ前は、この板でもちらほらと見かけたんだけどな
タスクシステム使わないと凝ったゲームは作れないと信じてた人達

980 ：名前は開発中のものです。：2007/12/03(月) 19:51:48 ID:tyrMCse6

だってゲームのソフトウェア設計に関する文献って少ないじゃない
そこにタスクシステムっていう日本語の情報が出てきたらそりゃこぞって飛びつくだろうさ

981 ：名前は開発中のものです。：2007/12/03(月) 20:07:30 ID:CkRuncl2

>>980
> だってゲームのソフトウェア設計に関する文献って少ないじゃない
そりゃ、ゲーム固有の設計手法なんて特にないから。ふつーにパッケージ製品作るのと
大して変わらん。

982 ：名前は開発中のものです。：2007/12/03(月) 20:13:11 ID:241Q4OIk

OOだのタスクシステムだの愚だ愚だ組み方議論するより
ベタでいけいけでマリオやドラクエ書きあげて大ヒットさせた人間が勝ち組ってこった

983 ：名前は開発中のものです。：2007/12/03(月) 20:24:34 ID:tyrMCse6

ベタで書いて途中でバグの嵐でにっちもさっちもいかなくなる僕にとっては組み方のノウハウは重要です(^^;
デザインパターンとか参考にして一段落付くたびにリファクタリングをしていけばいいんでしょうかね？

984 ：名前は開発中のものです。：2007/12/03(月) 20:34:20 ID:a1TCfwQx

むしろタスクシステムそのものが一種のデザインパターンなんだと思うよ。
「こうやって書けば早くてバグも減らね？」という経験知の一種。

985 ：名前は開発中のものです。：2007/12/03(月) 20:57:59 ID:CkRuncl2

>>982
規模が小さければ、設計しなくても破綻しないさ。まぁ、別の難しさはあるが。

986 ：名前は開発中のものです。：2007/12/03(月) 22:15:26 ID:10uWEAw2

タスクシステム的なものを作っているとしても「タスクシステム」の名前だけは絶対使わないよなあ。
恥ずかしい痛い人だと思われる。
タスクシステム脳（笑）

987 ：名前は開発中のものです。：2007/12/03(月) 23:02:28 ID:hqsjjSWF

スレのログ見ると、定期的に「タスクシステム＝デザインパターン」とか絶叫してる人がいるみたいだが
この人たちの言うタスクシステムってどのタスクシステムの話なんだろうね？

　【１．タスクシステム＝Logician Lordで紹介されているもののことだよ】
　　　　　　　　　　　ギャラクシアンとその直系に見られる特徴的な実装こそタスクシステムであり
　　　　　　　　　　　その要件を満たさない異形のコードは全て紛い物だ。タスクシステムとか名乗るな
　　　　　　　　　　　
　【２．タスクシステム＝リスト巡回UPDATE。ていうかforeachだよ。】
　　　　　　　　　　　ギャラクシアンのそれとは全く別物の、異形のコードであろうとも
　　　　　　　　　　　俺がタスクシステムって呼べばタスクシステムなんだいバーロー

988 ：名前は開発中のものです。：2007/12/04(火) 00:29:21 ID:y/T8AVHJ

タスクシステム厨は声がでかいだけで実際は少数だぞ
どうしてもバグの数が多くなるので現場では嫌われる
派遣でもう８社経験したけどつかってるのは２社ぐらい
普通の会社は>>535で地道に組む

989 ：名前は開発中のものです。：2007/12/04(火) 01:33:08 ID:4Z5Bmt4A

お仕事お疲れ様です。

990 ：名前は開発中のものです。：2007/12/04(火) 01:55:07 ID:SBXGmGIP

バグが多くなるってのがよく分らない。
何が問題？

991 ：名前は開発中のものです。：2007/12/04(火) 02:07:23 ID:8TNDV7US

単純に、エンティティ的なナニかを、実行アドレスの差し替えによる遷移と
固定ワークエリアによる多態で実装するのがタスクシステムだと思ってたけど。
どうやってリストをブン回すとか、依存関係の解決方法ってのはまた別の話なんじゃねーの？

992 ：名前は開発中のものです。：2007/12/04(火) 04:57:46 ID:bGSXJYb0

次スレ建てました

タスクシステム総合スレ part2
http://pc11.2ch.net/test/read.cgi/gamedev/1196711513/

993 ：名前は開発中のものです。：2007/12/04(火) 06:59:06 ID:y/T8AVHJ

>>990
このスレ全部読めば書いてある

994 ：名前は開発中のものです。：2007/12/04(火) 11:57:13 ID:j2vID05K

タスクシステムって名前から何をするプログラムか分からないのが問題だと思う

995 ：名前は開発中のものです。：2007/12/04(火) 21:02:23 ID:c1pcva3t

>>994
オブジェクト指向
構造化プログラミング

大御所のこのへんも、名前だけだと良く分からん気がする。

996 ：名前は開発中のものです。：2007/12/04(火) 21:19:37 ID:Za1HhvLA

本の一冊にでもforeachの説明でタスクシステムと書かれたら認めてやる

997 ：名前は開発中のものです。：2007/12/05(水) 01:31:27 ID:b2jbw32h

原理主義者同士の醜い争いの場

うめ

998 ：名前は開発中のものです。：2007/12/05(水) 02:16:25 ID:b2jbw32h

うめ

999 ：名前は開発中のものです。：2007/12/05(水) 02:17:42 ID:b2jbw32h

うめ

1000 ：名前は開発中のものです。：2007/12/05(水) 02:29:32 ID:yjewvbdc

うめ

1001 ：１００１：Over 1000 Thread

このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。