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

**名前は開発中のものです。** · 2009/12/13(日) 18:11:06

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

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

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

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

**名前は開発中のものです。** · 2010/02/14(日) 21:35:51

データ構造の連結リスト（双方向リスト）に関数アドレスやら優先順位やらをつけて
後に纏めて処理できるのがタスクシステムの基本的な部分でしょ。

と、これだけでもタスクシステムの構造的なメリットデメリットがわかる。
この構造的メリットが活きてくるケースは少なくないと思うけどなぁ。

タスクシステムに限らず、活かせないのなら使わないほうが良いですね。
ここでメリットを聞いてる人はそういう人でしょう。

**名前は開発中のものです。** · 2010/02/14(日) 21:36:12

>>778
>動的な実行順序変更以外に教えてくれ。
つ >>747

これで３回目ぐらい？
「おじいちゃんごはんはさっき食べたでしょ」って感じ・・・

**名前は開発中のものです。** · 2010/02/14(日) 21:50:02

いっとくが、タスクのリストってのは
仕事のリスト、処理のリスト、プログラムのリストってことで、
データのリスト、ゲームオブジェクトのリストではないぞ。
ゲームオブジェクトやデータを配列やリストで管理するなんてことは誰でもすることだ。

>>780
タスクシステムはいわばVMもどきなんだから、そりゃやろうと思えば何でも出来る。
だから>>747が出来るのは当たり前。でも使わなくても>>747は出来る。
あえて使うのは何故かと聞いているのだが。

>>779
データ構造に関数アドレスを付けるんですか、そうですか。
俺はデータ構造はデータ構造、制御構造は制御構造で別物で、
交ぜるのは泥沼化の入り口だと思うがなぁ。

>この構造的メリットが活きてくるケースは少なくないと思うけどなぁ。
具体的によろ。

**名前は開発中のものです。** · 2010/02/14(日) 21:58:56

>>781
>仕事のリスト、処理のリスト、プログラムのリストってことで、
>データのリスト、ゲームオブジェクトのリストではないぞ。
その俺俺タスクシステムの定義は何・・・？
>>2のタスクシステムはデータ、ゲームオブジェクトのリストという機能も普通に含んでるけど。
元々のタスクシステムからそれら機能を勝手に引いた時点で、君の言う”タスクシステム”
の話は君の脳内でしか意味の無い話になってるんですが。

**名前は開発中のものです。** · 2010/02/14(日) 22:03:42

具体性がなくなってきたから。

for(;;)/*メインループ*/
{
　　obj1.update();
　　for( size_t i=0; i<obj2_list.size(); ++i )
　　{
　　　　obj2_list[i]->update();
　　}
　　for( size_t i=0; i<obj3_list.size(); ++i )
　　{
　　　　obj3_list[i]->update( x, y );
　　}
　　for( size_t i=0; i<obj2_list.size(); ++i )
　　{
　　　　obj2_list[i]->update( u, v, w );
　　}
}

これじゃ駄目な理由はいったいなんだ？
引数だって自由に使えるし、こっちのが良いだろ。
ただ、動的な実行順序の変更だけは出来ないけどな。
お前らの欲しいのって、タスクシステムじゃなくてゲームオブジェクトDBなんじゃねぇの？

**名前は開発中のものです。** · 2010/02/14(日) 22:08:26

それ
"ゲームの流れを自然な形で表現"
することが出来ていると言えるの？

**名前は開発中のものです。** · 2010/02/14(日) 22:10:47

>>784
ゲームの流れ？はぁ？

**名前は開発中のものです。** · 2010/02/14(日) 22:11:30

>>783
んー・・・
>>782の時点で、君の言うタスクシステムは
君以外の人間にとっては無関係というか・・・

君の脳内タスクシステムを使うよりは>>783の方がいいと君が判断するなら
君にとってはそれが一番いいんじゃない？
としか言えんなぁ・・・

**名前は開発中のものです。** · 2010/02/14(日) 22:12:23

>>782
>>2のタスクシステムは便利と感じ、
俺の言う純粋な純粋なタスクシステムは要らないと感じるなら、
単純に引き算すればよい。
(>>2のタスクシステム)-(純粋なタスクシステム)=(ゲームオブジェクトDB)

for(;;)
{
　　container = db::select(型名);
　　for( itr=container.begin(); itr!=container.end(); ++itr )
　　{
　　　　itr->method();
　　}
}

これが出来りゃ満足なんだろ。

**名前は開発中のものです。** · 2010/02/14(日) 22:19:54

>>787
>これが出来りゃ満足なんだろ。
君はいったい何と戦ってるの？

「純粋な純粋なタスクシステム」とやらを勝手に脳内で妄想して
「（俺の考えた）タスクシステムは使えない！」って・・・誰に向かって叫んでるの？鏡？

まさに一人相撲。

**名前は開発中のものです。** · 2010/02/14(日) 22:29:41

>>786
残念ながら、俺の言ってるタスクシステムの方が、
>>2よりも「まだ」まともなんだよ。
>>2は制御構造とデータ構造をごった煮にしてる時点で、
純粋なタスクシステムよりも寄りいっそうたちが悪いんだよ。
タスク(処理)とゲームオブジェクトが密接に結びついてるなんておかしいだろ。別のものなのに。
複数のオブジェクト間にまたがる処理は何処に書くんだって話になる。
ゲームオブジェクトとゲームオブジェクトの間をとりもつのが「処理(タスク)」の重要な機能でもあるのに、
それがゲームオブジェクトにくっついてるって変だよね。

>>788
ここまで提示されても、自分の陥ってる状況が分からないって重症だぞ。
純粋なタスクシステムってのは>>2にも含まれてる。
>>2からアロケーターやらtype値検索機能やらを取り除いて
名前どおり、タスクの処理をする部分のみを抽出したのが「純粋なタスクシステム」だ。
それが本当に必要なのかどうかって話だ。
必要ないなら、>>2からタスクの処理をする部分だけを取っ払えばよい。
すると残るものはゲームオブジェクトDBだ。

**名前は開発中のものです。** · 2010/02/14(日) 22:32:50

結局、タスクシステムなんていっても内容はグローバルアクセスできる
ごった煮ウンコリストだからなぁ・・・設計とか完全無視の本当のウンコなのに
よくこんなもん使おうとするもんだよ
の割りには設計云々語ろうとするアフォばっかりだな

**名前は開発中のものです。** · 2010/02/14(日) 22:33:18

チンカスアンチ共は情けないな。目の前に最高のエサがそこに転がってるのに…
珍しくタスクシステム信者が現れているんだから反転攻勢のチャンスよ？
火力をID:eAxvOj2xに集中したまえよ。いくらなんでもこの程度は倒せるだろ…

**名前は開発中のものです。** · 2010/02/14(日) 22:42:41

>>789
>残念ながら、俺の言ってるタスクシステムの方が、
> >>2よりも「まだ」まともなんだよ。
すまんが、いきなり
「俺の妄想の方が一般に言われてるタスクシステムよりまともなんだ」
と言い出して

>ここまで提示されても、自分の陥ってる状況が分からないって重症だぞ。
とか言われても・・・
「そうか、重症なんだな。かわいそうに。」と思うだけというか。

君の脳内では何か「純粋なタスクリスト」について考えがあるみたいだけど
それこそ >>2 みたいに図解つきで説明してくれないかな。
いきなり君の妄想を暴露されても君以外の人間にはチンプンカンプン・・・

**名前は開発中のものです。** · 2010/02/14(日) 22:58:37

お前以外は皆分かってんだよ。
ゲームオブジェクトとタスクの結びつきが無いタスクシステムが
純粋なタスクシステムだ。
各タスクはコンテキストを持つだろうけど、
そこはゲームオブジェクトを入れるための領域ではない。
局所的なFSMの状態変数やゲームオブジェクトへのポインタなどを入れるWork領域。
そこに何を間違ったかゲームオブジェクトそのものを突っ込んで腐った物が>>2。
お前は>>2のtypeが好きらしいが、あれは最も下劣で目も当てられない代物。
ゲームオブジェクトの管理がしたいなら、DB的なものを作ればよいし(データ構造視点)、
実行順序の動的変更や、CellのSPEに仕事投げたいなら、純粋なタスクシステムを作ればよい(制御構造視点)。
>>2の出る幕は無い。

**名前は開発中のものです。** · 2010/02/14(日) 22:58:55

>>790
ブログに書かれてることを引用しておきながら
人のことをアホ呼ばわりして
設計云々語るとは君はすごいな

**名前は開発中のものです。** · 2010/02/14(日) 23:05:41

>>793
>お前以外は皆分かってんだよ。
そーかぁ・・・
>>2のリンク先ページ書いた人はみんな分かってなかったみたいだけど
「僕の考えてることは皆も同じように考えてる」と疑いなく考えちゃう人なのかな・・・

>タスク(処理)とゲームオブジェクトが密接に結びついてるなんておかしいだろ。別のものなのに。
これ、純粋にOOPのデータと振る舞いの隠蔽によるカプセル化を否定してる考えみたいに見えるけど
クラスがメンバーとメソッド持つのもごった煮と考える人なのかしら？

**名前は開発中のものです。** · 2010/02/14(日) 23:23:24

>>792
＞君以外の人間にはチンプンカンプン・・・

いや申し訳ないけどそらねーわ
タスク = OBJ、 1タスク = 1OBJ とか、こういう勝手な固定観念に縛られたCodezine状態の
自称システムが古典です古典タスクシステムなんですーとか言われてもピンと来ないなぁ

あーいうお粗末な自作連結リストにオブジェクト格納しましたーみたいなものを
タスクシステムでーすとか喧伝してる人は10年くらい前からちょくちょく見るように
なったのは確かだけどね

ま、ローカル用語、バズワードですから、何をどう呼ぼうが好き好きだし、知ったこっちゃないけど
古典タスクシステムというくらいだから古典があるんだろうね？どれ？Codezineの記事か？ｗ

**名前は開発中のものです。** · 2010/02/14(日) 23:27:35

>>795
>　>>2のリンク先ページ書いた人はみんな分かってなかったみたいだけど
タスクシステムの擁護派でも、>>2を擁護できる奴は居ない。お前ぐらいだ。

>　>タスク(処理)とゲームオブジェクトが密接に結びついてるなんておかしいだろ。別のものなのに。
>　これ、純粋にOOPのデータと振る舞いの隠蔽によるカプセル化を否定してる考えみたいに見えるけど
これはちょっと表記がまずかったな。
「全てのタスク(処理)とゲームオブジェクトが密接に結びついてるなんておかしいだろ」
と変えとく。

**名前は開発中のものです。** · 2010/02/14(日) 23:36:22

>>794
引用？どこどこ？

**名前は開発中のものです。** · 2010/02/14(日) 23:37:10

>>795
＞>>2のリンク先ページ書いた人はみんな分かってなかったみたいだけど

んなこたーない。>>2の中ではlogician lordを書いた人間はタスクとOBJの区別を
つけている。松○さんとかいう素人の方は理解できなかったみたいだけど
Cマガで特集記事書いたり禿出版で何冊もタスクシステム本を出したりして
アマチュアの学生相手に布教・普及させようと頑張ってたね。その残滓が君か？

**名前は開発中のものです。** · 2010/02/14(日) 23:40:06

>>797
>タスクシステムの擁護派でも、>>2を擁護できる奴は居ない。お前ぐらいだ。
やっぱり「僕の考えてることは皆も同じように考えてる」と疑いなく考えちゃう人っぽいなぁ。

>「全てのタスク(処理)とゲームオブジェクトが密接に結びついてるなんておかしいだろ」
とりあえず>>2のタスクシステムのどこにも
「全てのタスク(処理)とゲームオブジェクトが密接に結びつく」
という前提は見つからないのだが・・・
全てのタスク云々はどこから生まれた話なんだろう？これも俺俺タスクシステムの脳内定義？

**名前は開発中のものです。** · 2010/02/14(日) 23:43:27

で、結局メリットはどうなったの？ｗ

**名前は開発中のものです。** · 2010/02/14(日) 23:45:16

>>798
>505のリンク先

**名前は開発中のものです。** · 2010/02/14(日) 23:46:01

>>802
はぁ？どこ引用したか？って聞いてるんだよ
さっさと出せよボケ

**名前は開発中のものです。** · 2010/02/14(日) 23:48:42

引用がばれたら逆ギレかｗ
これは恥ずかしいｗｗ

**名前は開発中のものです。** · 2010/02/14(日) 23:53:48

だれかー、俺の替わりにID:eAxvOj2xの相手してー。
特にタスクシステム擁護派に相手して欲しい。
お前らの残党だろ。引き取って面倒みろよ。

>とりあえず>>2のタスクシステムのどこにも
>「全てのタスク(処理)とゲームオブジェクトが密接に結びつく」
>という前提は見つからないのだが・・・

http://codezine.jp/a/article.aspx?aid=297
>シューティングゲームを作る場合は「自機」「敵」「敵出現制御」「得点管理」「タイトル画面」など、
>ゲームを構成する全ての要素をタスクとします。

**名前は開発中のものです。** · 2010/02/14(日) 23:57:26

>>804
引用場所を貼ったら終りだけど？
俺がいつ引用なんて貼った？

**名前は開発中のものです。** · 2010/02/14(日) 23:58:14

今日一日でずいぶんスレ伸びたな。

今日のアンチは押され気味というか自爆が多いなｗｗｗ
陰湿なID:eAxvOj2xと煽られて顔真っ赤なID:OC4y/061の戦い
まぁまぁ楽しめたぞｗｗｗ

**名前は開発中のものです。** · 2010/02/14(日) 23:59:15

>>801
タスクシステムという言葉のメリットか？これの響きは厨二魂を心地よく擽る。
ID:eAxvOj2x みたいな右も左も分からない子を幻惑して遊ぶことができる。

「よくわかんないけどタスクシステムはすごいに違いない！」
「タスクシステムありがたやナンミョホーレンゲー」

こういう信者状態に至るまで育てたらアンチの檻に放り込んで彼らとの相互作用
（化学反応・拒絶反応）を観察する。アンチとの触れ合いの末に信者が強烈な
アンチにジョブチェンジする場合がある。レアポケモンだ。ハード君ともいう

タスクシステムを信じて就活したら大手全部落ちたのではないだろうか。
アンチはゲームプログラマに対する逆恨みの仕方がとにかく半端ない。面白い

**名前は開発中のものです。** · 2010/02/14(日) 23:59:45

>>747
あと、こんな話にならない嘘を書いちゃってる人とかなんも感じないわけ？
結局、挙げてもメリットとして説明できないでしょ？
なんでテキトーに感覚だけで主張しちゃうの？
それで何度も会社で失敗とかしてない？

**名前は開発中のものです。** · 2010/02/15(月) 00:00:23

引用しておいて白々しいｗ

**名前は開発中のものです。** · 2010/02/15(月) 00:05:34

ぶっちゃけ>>747も同じメンタリティでしょ？
多分、これがメリットになるんじゃないかな？とか検証もしないで
テキトーに主張したんでしょ？
そんなことばっかりやってるよね？
嘘吐きだよね君たち

**名前は開発中のものです。** · 2010/02/15(月) 00:08:46

定義のはっきりしないものを感覚以外の基準で判断しようとしても
みんなバラバラのこと言い出すだけで結論なんて出ないだろ。

結局、感覚で判断する >>679 とか >>747 程度の答えしか出ないよ。

**ID:OC4y/061 日付変わったね** · 2010/02/15(月) 00:10:13

>>808
そこまで妄想しないと自分を保てなくなってるんなら、
お前こそジョブチェンジの頃合かと。気に病むことは無い。
若気の至りみたいなのは誰にでもあるよ。

**名前は開発中のものです。** · 2010/02/15(月) 00:13:32

ID:OC4y/061 ってもしかしてハード君なの？

**名前は開発中のものです。** · 2010/02/15(月) 00:21:00

>>814
>>720

**名前は開発中のものです。** · 2010/02/15(月) 00:27:38

そうか、ハード君はタスクシステムに対する旺盛な好奇心が目を引くね。
君はタスクシステムの大ファンだよ。これからも幻惑され続けてほしい

**名前は開発中のものです。** · 2010/02/15(月) 00:41:11

>>781
データ構造はデータ構造、制御構造は制御構造で別物って当たり前でしょ？

**名前は開発中のものです。** · 2010/02/15(月) 00:50:24

タスクシステムなんてTCBの実行と描画を同時に行っていた時代の遺物
もしも、オブジェクトの移動、当たり判定、描画etc.を別の処理単位に分けるなら
TCBで全てを済ませるタスクシステムとは相性が悪い

何で、タスクシステムは実行順番を動的に変更できる必要があったのかというと
TCBの実行時に描画も行うから、TCB自体を実行前にZソートしておく必要があったため
実行順とは別の順序で描画できるようなフレームワークなら必要ない

結局、タスクシステムを使ったのはコード量を節約したかったからじゃないだろうか
TCBの最大数が分かってるにもかかわらずtask1();task2();task3()...としなかったのは
双方向リストとイテレータの方がコード量が少なくてすんだのかもしれない
（俺はハード屋じゃないから実際のは分からないけれど）

**名前は開発中のものです。** · 2010/02/15(月) 01:28:57

>>816
まかせとけ。
俺の理想のタスクシステムはこれ。
まずもって、タスクは「処理」だから、書くべき場所は関数の中。まーこりゃ大前提だわな。
void function()
{
　　task1
　　{
　　　　//処理1をここに書く
　　}
　　task2
　　{
　　　　//処理2をここに書く
　　}
}
もちろん書いた順に実行されることも保障される。
ところで、taskのくだりは無くても支障ないから、取っ払う。
void function()
{
　　//処理1をここに書く
　　//処理2をここに書く
}
そうすると普通のプログラムとなり、同時に俺の追及する理想のタスクシステムも完成する。
だから俺は、タスクシステムのアンチであり、同時に信者でもある。

**名前は開発中のものです。** · 2010/02/15(月) 02:10:20

>>819
class TamaHoge : public Hoge{
　public void shori{
　　//　弾の処理
　}
}
Class TekiHoge : public Hoge{
　public void shori{
　　//　敵の処理
　}
}
とかやっといて、オブジェクトを適当に作って適当に順次shori()を呼び出す
のがタスクシステムの原型になるんじゃないの？
あと、書いた順に実行されることは必須じゃないんじゃない？

**名前は開発中のものです。** · 2010/02/15(月) 02:30:21

>>820
それは仮想関数を使った多態をコンテナと組み合わせたものだね。

仮想関数は便利だ。派生クラスで好きにデータを追加しながらクラスごとに動作を
記述することができるからね。

コンテナは便利だ。オブジェクトが増えたり減ったりするのを実に素直に書き表す
ことができるからね。

で、これを原型として何を加えると「タスクシステム」になるの？
何か加える必要があるの？

**名前は開発中のものです。** · 2010/02/15(月) 02:42:38

>>821
何を足すかは知らん。これで全部かもしれん。

つか、うちはほとんどこれっぽいのでやってるので
これをタスクシステムというなら、確かに便利です。

**名前は開発中のものです。** · 2010/02/15(月) 02:44:17

つーか、これだとシステムってんじゃなくてスタイルだよな。様式？

**名前は開発中のものです。** · 2010/02/15(月) 03:18:22

>>819 >>820
これがタスクシステムというならああそうなのって思うが
そう説明してる「タスクシステム」って少なくとも>>2じゃないな。

**名前は開発中のものです。** · 2010/02/15(月) 03:41:44

難しく考えなくていいんじゃ？

いろんな処理をタスクという単位にして
リストで繋いで処理する事にタスクシステムって名前が付いてるだけ。
>>2のWhite Paper - Programming に「処理関数へのポインタ付きワーク構造体の連結リスト」って書いてあるし、
細かく決まりがあるわけじゃないでしょ。

「処理関数へのポインタ付きワーク構造体の連結リスト」な機能があるなら、タスクシステムって言えちゃうんだろう。

OC4y/061とかe+nQn9Mgみたいな人って相手にすると疲れるよね。。。。

**名前は開発中のものです。** · 2010/02/15(月) 07:02:37

引数っての何渡すんだろ
引数なしで統一した方が扱いやすいと思うのだが
それに一々毎回毎回引数渡すのやだな

**名前は開発中のものです。** · 2010/02/15(月) 08:33:19

＞「処理関数へのポインタ付きワーク構造体の連結リスト」
これがいらないっていわれてるんだが

**名前は開発中のものです。** · 2010/02/15(月) 09:14:04

>>827
C++なら不要だよね
Cでの話じゃない？

**名前は開発中のものです。** · 2010/02/15(月) 09:29:03

C/C++関係なく＜連結リスト＞はなくても動的変更なければ必要ない。
＜リスト＞ならC/C++ともにないと困難。
配列や呼び出しコード列挙もリストといえばリスト。

**名前は開発中のものです。** · 2010/02/15(月) 13:54:09

だからオールアセンブラ時代のテクだっつーの

タスクシステム使うとメモリ使用量も把握しやすいし、複数人で開発もできる
オールアセンブラでそれをやるのは大変

今あえてこのシステムを使う必要はないだろ

**名前は開発中のものです。** · 2010/02/15(月) 17:58:56

シーン管理もタスクシステムも同じっしょ

**名前は開発中のものです。** · 2010/02/15(月) 18:03:04

>>831
シーン管理？

**名前は開発中のものです。** · 2010/02/15(月) 22:34:52

>>818
> タスクシステムなんてTCBの実行と描画を同時に行っていた時代の遺物

どういう話なのか知らんけど
昔のBGとOBJを表示するハードのことなら、あれラインバッファだから
V-BLANK期間内は描画処理というのはやんないよ。パターンテーブル
(VRAM)の書き換えは毎フレームゴリゴリやるような話じゃないし

> もしも、オブジェクトの移動、当たり判定、描画etc.を別の処理単位に分けるなら
> TCBで全てを済ませるタスクシステムとは相性が悪い

んなこたない。ひとつのオブジェの1フレーム分の差分処理を1タスクで
ドベーっと一気にやる必要はない。むしろそうしないことのが多い
logician lordの記事でも移動と当たり判定のタスクは分けてるでしょ

**名前は開発中のものです。** · 2010/02/15(月) 22:45:23

logician lordの記事ってなんですか

**名前は開発中のものです。** · 2010/02/15(月) 22:55:19

>>834
>>2の記事あん♥

**名前は開発中のものです。** · 2010/02/15(月) 23:18:11

>>819
相変わらず進歩ないな。昨夏から同じこと叫んでるだろ君
プログラマの責任の下でそんなふうに性的に列挙、記述できることばかりなら
それでやってりゃいいんだけどよ、おめーみたいなお気楽な庶民と違って
王様は気苦労が多いんだよ。おわかりになって？

**名前は開発中のものです。** · 2010/02/16(火) 08:25:29

なんかタスクシステム許すまじ！って感じの人がちらほらいるけど
トラウマかなんかかな？
高級言語メインの現在でもアセンブラだって知ってる方がおいしいし
古い知識でも無いよりあったほうが飯の食いやすい業界だと思うんだけどな
そりゃ新しい技術の勉強だけで手一杯ってのは分かるけどもさ

**名前は開発中のものです。** · 2010/02/16(火) 08:30:08

おまえはレスも読めないのか

**名前は開発中のものです。** · 2010/02/16(火) 08:36:11

翼システム

**名前は開発中のものです。** · 2010/02/16(火) 09:36:42

Google 検索 "タスクシステム" 1 年以内日付順
http://www.google.co.jp/search?tbo=1&tbs=qdr:y,sbd:1&q=%22%E3%82%BF%E3%82%B9%E3%82%AF%E3%82%B7%E3%82%B9%E3%83%86%E3%83%A0%22

**名前は開発中のものです。** · 2010/02/16(火) 11:54:02

もう十分議論したわけだから先に進まないと

**名前は開発中のものです。** · 2010/02/17(水) 01:53:19

>>837
彼らは裸の王様とか言ってるから自分には何も理解できないと言ってるんでしょ。

つまり、トラウマというより何も無いということにしないと
自分が馬鹿ということになって自我が崩壊しちゃうから
必死になってる、と。

普通のプログラマなら>>2見ても古いやり方だねぇ、程度で終わって
今さら特にこだわることも無いんだけど。
あれを見て何一つ理解できない人たちにとっては、自分は馬鹿という強迫と
見えないゆえに何かすごい秘密でも隠されてるように感じるのかね。

裸の王様ってのはいいたとえだね。逆説的に彼らの馬鹿さを証明してるｗｗｗ

**名前は開発中のものです。** · 2010/02/17(水) 01:55:58

>>842
裸の王様読んだことなさそうだなｗ君ｗ

**名前は開発中のものです。** · 2010/02/17(水) 02:09:26

>>840
まだちらほらと新しく「タスクシステム」と名のつくコードが生まれているけども、
全体的に数はあんまりなくて、ゆっくりと絶滅に向かっているようで安心した。

**名前は開発中のものです。** · 2010/02/17(水) 02:09:49

>>842はちょっと馬鹿にしすぎで意地悪に見えたけど
>>843みたいに皮肉られてるのすら気づかないレベルではしょうがないのか・・・

**名前は開発中のものです。** · 2010/02/17(水) 02:12:15

だって>>842の文章って裸の王様のストーリー知ってたらおかしいだろ明らかに
突っ込んでほしいの？ｗ

**名前は開発中のものです。** · 2010/02/17(水) 02:27:19

サンタクロースを信じてる幼稚園児並みに純粋なんだね・・・
それぐらい純粋な人じゃないとタスクシステムのアンチなんて奇特なことは出来ないんだろうね・・・

**名前は開発中のものです。** · 2010/02/17(水) 09:09:37

また煽りあいか。技術的な話しろ。

**名前は開発中のものです。** · 2010/02/17(水) 17:34:42

タスクシステム否定派が定期的に湧くから荒れる
先人の遺した技術を今更否定した所で誰が得すんだよｗ

次スレがあるなら
・タスクシステム(>>2)での実装を強要するものではありません
・アンチな話題は専用スレを立ててください
ってテンプレに入れといたら荒れなくなるかも知れんなｗ
一々明文化せんといけんのがかなりアホ臭いが

**名前は開発中のものです。** · 2010/02/17(水) 18:22:34

アホ臭いのはタスクシステ（ｒｙ

**名前は開発中のものです。** · 2010/02/17(水) 18:38:01

アンチがいなくてスレが盛り上がるのか？

**名前は開発中のものです。** · 2010/02/17(水) 18:41:00

基地外アンチと基地外信者が他のスレに迷惑をかけないように隔離するのが
このスレの存在意義だろう？

**名前は開発中のものです。** · 2010/02/17(水) 19:32:25

アンチはどのようなクラス設計をしているか教えて欲しい。

**名前は開発中のものです。** · 2010/02/17(水) 19:48:07

>>853
フツーだよ
君らはフツーよりメリットがあるからタスクシステムを使うんだから
もちろんフツーがどんなのかなんて説明の必要すらないよね？
ね！

**名前は開発中のものです。** · 2010/02/17(水) 20:06:56

俺は普通にオブジェクトのリストを

**名前は開発中のものです。** · 2010/02/17(水) 20:51:30

>>854
ふつうってなんだよ
ゲームによって変えるのかね

**名前は開発中のものです。** · 2010/02/17(水) 21:38:46

作り方かえるって言われてもなぁ。
描画エンジンと物理エンジンと当たり判定ライブラリと
サウンドエンジンとメモリアロケータとその他もろもろ集めてきて、
ゲームロジック部と繋ぎ合わせるだけだしなぁ。

**名前は開発中のものです。** · 2010/02/17(水) 21:51:29

ゲームによって変えるのは当たり前というか。
だって、仕様が違うんだからしかたない。
仕事の奴はそれが仕事だし、趣味の奴は、それが趣味なわけで。
それしないってんなら、仕事がなくなるというか、作る意味が無いというか。
何も一から作れって言ってるんじゃないぞ。
各種ライブラリはそりゃ利用するんだが、
ライブラリごとにインターフェイスがバラバラだから、
そこの整合性を取ってやる仕事は普遍的に残るだろう、という。
ライブラリの面子が毎回変わるんだから、
まとめ方が毎回変わるのは当たり前というか。
でも、仕事ってそう言うものだろ。じゃないと職失う。

**名前は開発中のものです。** · 2010/02/17(水) 22:13:35

>>858
なにか言っちゃあ二言目には「ゲームによって変えるのは当たり前」って
聞き飽きたんだよね

**名前は開発中のものです。** · 2010/02/17(水) 22:37:00

もう意味がわかんない。
1)ゲーム作るよ。仕様ありますよ。プラットフォームも決まってますよ。
2)必要な機能も決まりますよ。使用するライブラリも決まりますよ。調達しますよ。
3)集めてきた材料を繋ぎ合わせますよ。
最後の繋ぎ合わせる部分は自分たちでやらなきゃ仕方が無いじゃん。
そこやらないなら、仕事して無いっていうか。
集めきてはい終わりじゃ素材集じゃん。ライブラリ集じゃん。ゲームじゃ無いじゃん。
ゲーム作るんだから、ゲームの形にするところは自分たちでやるもんだろー。

しかも俺は2)にタスクシステムも分類してあると思ってて、
素材としてタスクシステムは必要かどうか？って話が本筋と思うんだが。
>>856はなんか変なこと言ってるけど、
タスクシステムを使わない人は、「ゲームによって変えるのかね」じゃなくて、使わないの。
料理作るのにニンジンが必要無いって人に、「ニンジンは毎回変えるの？」って返すのはそりゃおかしいだろ。
使わないんだって言ってるのに。

**名前は開発中のものです。** · 2010/02/17(水) 22:53:38

訂正)
料理作るのにニンジンが必要無いって人に、「ニンジンは毎回変えるの？」って返すのはそりゃおかしいだろ。
↓
料理作るのにニンジンが必要無いって人に、「レシピは毎回変えるの？」って返すのはそりゃおかしいだろ。

**名前は開発中のものです。** · 2010/02/17(水) 23:10:48

また煽りあいか。技術的な話しろ。

**名前は開発中のものです。** · 2010/02/18(木) 01:37:08

敵が弾をプレイヤーに向けて発射する処理を
タスクシステムを使わないで書くとどんな感じ？

**名前は開発中のものです。** · 2010/02/18(木) 01:46:32

for( size_t i=0; i<enemies.size(); ++i )
{
　　if( hoge )
　　{
　　　　shots.push_back( new shot( player.x, player.y, enemies[i].x, enemies[i].y ) );
　　}
}

**名前は開発中のものです。** · 2010/02/18(木) 01:56:16

敵が弾をプレイヤーに向けて発射する処理を
タスクシステムを使って書くとどんな感じ？

**名前は開発中のものです。** · 2010/02/18(木) 02:00:15

おまえの環境はメモリが自由でいいな

**名前は開発中のものです。** · 2010/02/18(木) 02:04:52

アロケーターとカスタムコンテナぐらい自分で書けば？
my_container.push( new( my_alloc<shot> ) shot(...) );
こうすりゃ文句無いわけ？よくわからん。
どっちにしろタスクシステムと関係ない。

**名前は開発中のものです。** · 2010/02/18(木) 02:08:27

あ、やべ。
my_container.push( new( my_alloc<shot>() ) shot(...) );

**名前は開発中のものです。** · 2010/02/18(木) 02:12:20

どうかくのかが問題なんだが。その自由な枠組みで。

**名前は開発中のものです。** · 2010/02/18(木) 02:15:50

処理したい順番に書いてけば？

**名前は開発中のものです。** · 2010/02/18(木) 02:16:30

ここら辺の処理はあんま変わんないね

**名前は開発中のものです。** · 2010/02/18(木) 22:24:04

えっ

あんま違わないってことは違いがあるんだよな？
で、敵が弾をﾌﾟﾚｲﾔｰに向けて発射する処理を
おまえのﾀｽｸｼｽﾃﾑを使って書くとどうなるんだ？
これとても重要な質問なの

**名前は開発中のものです。** · 2010/02/18(木) 22:43:35

つーかDSPSPでこんなコード書いてたら完成しないぞ

**名前は開発中のものです。** · 2010/02/19(金) 01:13:58

>>873
>864 のコードに由来して特定の環境で受け入れられないオーバーヘッドが発生するとは
思わないんだけど、具体的に何の制限が問題になるの？

まともな C++ コンパイラが使えない（ operator new やアロケータのカスタマイズができない）
とかいう事情ならまぁ納得なんだけど、そういうこと？

**名前は開発中のものです。** · 2010/02/19(金) 01:26:26

newを自由に呼べるシステムは分断化の回避が難しい。
回避方法は対処療法的なものも含めいろいろあるが
普通考慮するようならあまり自由にnewを呼ばない。

**名前は開発中のものです。** · 2010/02/19(金) 01:46:46

>>875
それってつまり、メモリの断片化に対して operator new のカスタマイズでは不可能な、
より適切な対処があるってことだよね？具体的にどうするの？

最終的に使う領域が固定の配列から切られるとしても、記述としては new (...) shot(...) で
いけるようにしといたほうがいろいろ（可読性とかメンテナンス性とかの面で）有利じゃない？

・・・質問ばっかりで悪いとは思うけど、たまには技術的な話を掘り下げさせてもらえると
有意義かなぁと思ったり。

**名前は開発中のものです。** · 2010/02/19(金) 01:58:29

>>876
newを使わなければいいんじゃね？

**名前は開発中のものです。** · 2010/02/19(金) 02:15:34

どうせ弾の上限は決まってるんだろうから、shotsは固定の配列でいいんじゃね