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

×判定対象は同士
○判定対象同士

ちなみに俺 ID:rIovvj90ね
俺的には>>936もいいとは言えないね
jiki,teki,tama,unkoと同じ問題が今度はシーンにうつるだけだ
シーンをタスクにいれて何のごった煮になるのか知らないけど
仮にタイトルシーン、シューティングシーン、リザルトシーン、・・・という種類のあるものなら
当然それに必要なupdateの引数も異なる
だからダメだね
まったく汎用性のない糞クラスだ

ID:rIovvj90=ID:rVEgp4cMって本当にプログラム書いてんのか？
どう見ても役に立ちそうにないんだけど。

俺の現場にこんな奴来たら、即クビにしちゃうけどな。
いま本当に仕事やってんの？ニートとかじゃなく？

シーンなんて最も抽象化しやすいものの１つだと思うんだが……。

>>951
自機も敵も弾も全て同じ当たり判定してるなら同じメソッドでしょうから
1つのforeachにまとめてもいいかもしれませんね。
ただ、自機、敵、弾のリストを当たり判定リストとして統合した１フレーム限りの寿命のリストを作るのが良いかどうかという問題が発生しますが。
オブジェクト毎に異なる当たり判定処理を導入しやすいという利点を得た代わりにどんくさい見た目になってると考えればまぁ許容範囲かと。

あと、この手法が真価を発揮するのはひとくくりに抽象化できないもの同士の情報やり取りが楽になることです。
つまり当たり判定という「処理」部分の中に閉じた話ではなく、
「入力」、「処理」、「描画」を簡単に接続できるとこに真価を発揮します。

例１：自機を動かす
　・InputDevice（イベントハンドラとかで１フレーム分キー入力とかをバッファリングするオブジェクト）
　・jiki
　・OutputDevice
というオブジェクトがあった場合に
　・InputDevice・jiki間はswitch (InputDevice->popKey()) 〜
　・jiki・OutputDevice間はcontext.dev3dg->draw_model(jiki_gazou, jiki.x, jiki.y);
と書ける。

例２：メニュー画面を操作する
　・InputDevice
　・menu（キー情報を入力として保持カーソル位置情報を変更）
　・menu_draw_model（menuを入力として１フレーム分の描画内容を決定）
　・OutputDevice
この場合もオブジェクト間で発生するデータのやりとり処理が素直に思いつきますよね。

オブジェクト間にまたがるデータ通信は無理やりどこかのオブジェクトに押し込めるのではなく、
Sceneクラスが受け持つ。そしてC入門書よろしく関数呼び出しを延々と書いていく。構造化プログラミングに逆戻りです。
利点はオブジェクト間の通信処理がC初心者でも書ける位に簡単化されることです。
（私はゲームオブジェクトにタスク導入反対派なので、こう記述すればタスク使うより楽にプログラミングできますよねという意図で書いてます）

そういえば
>　・InputDevice・jiki間はswitch (InputDevice->popKey()) 〜
>　・jiki・OutputDevice間はcontext.dev3dg->draw_model(jiki_gazou, jiki.x, jiki.y);
これらをそれぞれタスク化するのはありかも。
処理だし

タスクシステム総合スレ part4
http://pc11.2ch.net/test/read.cgi/gamedev/1233459490/

なんだこの損した感は

ID:rVEgp4cMには>>954の返答がもらえないみたいなんだが
無視して>>958みたいに次スレ立ててるところを見ると本当にニートなのか

それは悪いことを聞いたな・・

前スレ、前前スレから、ひとりだけ異様にレベルの低いことを言う、
プログラムが少しも出来そうにもない、日本語の読み書きが不自由そうな
タスクシステム否定派が混じってると思っていたんだが、
それがID:rVEgp4cMだったのか・・・

>>960
一応、本職のＰＧですわ
ってなんでお前にそんなこと言わなきゃいけないのか？
内容でレス返せなくなったから人格攻撃に移ろうと思ったの？
育ちが悪いなぁ

>>961
あんたの書いた>>831とか

>タスクシステムはごった煮ソースになるので
>ほぼ全クラスを一括インクルードしなければ動かないとかかなり糞

この一文を見ただけであんたがとんでもない大馬鹿野郎で相手するだけ無駄な
三下プログラマだと誰が見てもわかるんだが。

なんでそこまで自覚無いのか知らないが、このスレであんた一人だけレベルが
異様に低いんだよ。

こんな場末のスレだってまともな人がたまに遊びに来て、
有意義なことを言ってくれるのに、あんたみたいな
クズが居たら議論の妨げにしかならない。ほんと、いい迷惑。

自分が三下ではないと思うのならぜひ >>497 の問いかけに答えてみて欲しい。

いつのまにかタスクシステムありきで話が始まるんだから恐ろしい。

>>962
全然主旨と違うところに噛み付いてるけど
ソースに明示的に引数を書いて関数に必要なインスタンスをわかるようにしろ
ってのがメインなんだけどね
ここをあんまりずらしてほしくないな

あと、インクルードだってできるできないは別にしてもインクルードしてるんでしょ？
だって折角引数なくしてごった煮にしたのにそんなところに制限あっても
邪魔なだけもんねぇｗ
それとタスクシステムで組むなら俺はインクルードしちゃうべきだと思うよ
制限があることにもはやなんの意味もないわけだし
あえて言えばタスクシステムにしたのが運の尽きでしょｗ
プログラムの組み方（主に引数）によるクラスや関数の関連・アクセスの限定が
できないわけだしもうなんでもやっちゃったらいいよｗ

>>953
> jiki,teki,tama,unkoと同じ問題が今度はシーンにうつるだけだ
まあね。

> まったく汎用性のない糞クラスだ
ほどほどに汎用性のないちょっとだけダーティクラスだ
程度の言い方の方が良いのでは？

いつまでも通用する完全に汎用的なライブラリとして整備するかどうかは別として
似たようなゲーム量産する時にこういうクラスを作っとくのは実用上アリと考えても良いかと。

シーン間にまたがった画面遷移させたいというような要求が出て「やっぱシーン間も引数渡ししたいね」
となってから使うのやめたとしても、ゲームオブジェクトを脱タスク化する仕事量と比べたら傷は無いに等しい。
だから導入する人の直近の実用上に問題無いなら問題無いか、という姿勢で自分はＯＫと思った。

>>953
> 俺的には>>936もいいとは言えないね
(snip)
> まったく汎用性のない糞クラスだ

あんた、本当に頭がおかしいんじゃないの？

936は、具体的なシーンを構築するためのクラスであって再利用するわけでもなく、
汎用性なんか必要ないんだが。

>>966
だったらなぜにTask？ｗ

何故理解していないものを批判できると思うのか。
Taskはより抽象的なクラス。こちらは汎用的である必要がある。
SceneTaskはより具象的なクラス。こちらは汎用的である必要はない。

>>968
したらどうして継承して〜Taskクラスである必要があるのん？ｗ（俺はないと思うんだけどｗ）
ばっかじゃねぇんｗ

まさかの第２ラウンドｗｗｗ
遅刻の予感ｗｗｗ

名前の話か？　それは単にサンプルだからだろ。
実際にはSceneTaskなんて何も表してない名前は使わないだろう。
Scene全体のスーパークラスとしてはあり得るかもしれんが。

俺はID:rVEgp4cM(スレ主)と議論するのは時間の無駄だと思うので
よそのスレでやりたいわ。

あるいは、ID:rVEgp4cMを無視して話を続けてもいいだろうが。

いいスレなのに、スレ主がいるだけ邪魔というのが惜しいな

>>972
アレアレ？
敗北宣言？ｗ

まあ、いいけどダメな組み方なのわかってて
それを人に押し付けるのやめてね
その先に進歩ないからｗ

>>974
お前が一人でスレのレベルを下げてるのな
せっかく、いいスレなのにな・・

タスク信者、反論できなくなっちゃったかｗ
ていうか、タスク信者っていたんだ？

俺はこのスレでは「タスクシステムの是非」あるいは
「安全性の高いタスクシステムの設計」について論じたいのだが、
前者については「理解できないから全否定」というスタンスの
奴がいる限り、まともな議論は望めそうにないな。
後者に関して、もう少しID:9d5EHsE6の話を聞きたかったが、
こうもノイズが多すぎては……。

タスクシステムではタスクがどうのこうのという割に、
実際にはタスク＝オブジェクト みたいな図式ができあがってて、
それ、劣化オブジェクト指向だよねって突っ込まれる事例が増えていると。

ゲームを設計する上でゲームオブジェクトみたいな概念を持ち出すようでは、
タスクシステムを設計するのに向いてない。

BASIC時代のように、自機は自機関連サブルーチンが処理して、敵Aは敵A関連サブルーチンが処理をする。
これらのサブルーチン群をうまくスケジューリングするために、タスクシステムを設計するのが本道である。

データ中心指向と機能中心指向の対決がこのスレにつまっているのだよ。
えっへん。

とか言ってみるテスト。

こんな基地外(>>976)、死ねばいいのに…

>>978
なるほどなー
なんか自分がすごいことを考えてるような気がしてきた

BASIC時代ってあんま知らないけど、
BASICの「サブルーチン」ってCでいう引数がvoidの関数だよね？

タスクだけで組もうとしてタスクシステムに行き着き、
結果、タスク間にまたがるデータのやりとりがおろそかになった。

一方データだけで組もうとして最初期のオブジェクト指向、つまり
オブジェクトとメッセージングのみが存在するシステムに行き着き、
結果、データ間にまたがる処理の記述がおろそかになった。

こんな感じかな？

そこでさらに、タスクのつもりで実はオブジェクト作ってたとか、
オブジェクトのつもりで実はタスク作ってたとかいうことが発生して
それはもう大混乱←今ここ
って感じ？
（はてなばっかりだ俺）

初心者向けを適当にピックアップ。
というよりぱっと見て自分が理解できる情報。用語力のなさと前提条件がわからないのが致命的。

>>114,115
>>331,334,337,339,340
>>427,429,431
>>459
>>492-498,>>503,508,509,>>522,>>528
>>498,500,516,523
>>529,534,553,571,573,588

とりあえず休憩。

>>460,>>544
そういや松浦さんってシューティングゲームプログラミング書いてた人なのね。
あれは結構初心者の自分としては色々参考にはなったんだけどなぁ。まさに>>544の初心者ですわ。
(当時タスクシステムが何いいたいかよく分からんかった。ので、自機、敵機のリストで多態性して組んだ。
ってかこの本のやつは別にごった煮リストじゃナカタヨ。普通に自機系、敵機系と分けてるよ。)

>>684-686,>>762,803,762,>>805,807-811
>>816-819,>>823

>>826
上、開発中とか思案中に良くある。下、クラスライブラリとして整理して切り出した後。
うん、クラスライブラリ化できると下っぽくはなる気がする。

>>876,>>877
C#のGC自体はどんな間隔でやってるか知らないけど、実行中にタスクマネージャのメモリを見ると結構こまめにやってそうな気がする。

ここら辺から先、斜め読みできなくて困る。

>>932,938
俺、個人的には配列とかリストみたいなコレクションの変数名は、sをつける派です。jikisとかenemysとかunkosとか。
文法的に間違ってそうだけどたまに配列の配列とか、jikisesとかやりだします。こりゃ流石に自分しか分からんが。
これ、jikiとかtekiとかunkoとかが同じ汎化クラス持てると、super　superses[][]とかできまっせー。
こんな洗練されてなかったけど、>>982の本読んでたころの最終系は確かそんな感じにSTGSceneを構築してた。
(もちろんシーンはタスクじゃなかった。線形リストでもない、ただのスイッチで分岐したやつだった)
シーン管理については↓に解説があったよ。
ゲームにおけるデータ構造・クラス設計・パターン2
http://pc11.2ch.net/test/read.cgi/gamedev/1211544659/l50

とりあえず追いついたー。

>>983になぜか>>762が2つあるね。明らかなミスです。

>>978
＞タスクシステムではタスクがどうのこうのという割に、
＞実際にはタスク＝オブジェクト みたいな図式ができあがってて、
＞それ、劣化オブジェクト指向だよねって突っ込まれる事例が増えていると。

このスレには色んな村の人々が入り乱れていてそれぞれの村独特の言葉を駆使するから
議論が途中でヘロヘロになるんだろう

例えばタスクという言葉、ようなハードウェアにかなり近い位置で動く、つまりOSやモニタといった
プログラムにおいては古くから使われてる、わりと由緒正しい、計算機用語だ
50〜60年代のメインフレーム用マルチタスクOSの誕生時よりタスクとはジョブステップであり
ユーザー定義のジョブを逐次処理・並行処理するために（システムが内部で）それを分割し
CPUに割り当てる（ディスパッチする）ときの単位だ。タスクは基本的に

　　�@計算機の内部状態（コンテキスト。これはレジスタセット等）の全て、ないし必要な部分
　　�Aジョブ（プログラムとデータの参照）

で構成される。�@は例えばマルチタスクOSのプロセスのようにレジスタセットの大半を保存し
アドレス空間まで切り替えてしまう大掛かりなものから、超簡素な組み込みシステムの軽量な
スレッドのようにPCとSP（と一部の汎用レジスタ）のみを保存して切り替えるものまで多様

だが>>2のタスクの説明では揃いもそろって可視で移動するキャラクタ（OBJ）でしか解説しないし
コンテキストの切り替えというのは一切してくれない。ユーザープログラム側で解決すべきこととしている
この辺がOS用語のタスクと明らかに異なるところでありひとつめの誤解を作り出し、「なんぞこれ
逐次処理してくれるんじゃなくてジョブを周期的にバッチ処理してるだけじゃねーか」という突っ込みが来る。
また小規模な組み込みシステムみたいにハードとユーザーが接近してる環境を除けば
タスクというのはユーザープログラムの知る由もない内部の処理単位のはずなのだが
>>2ではユーザー自身がジョブを分割し周期タスク用のユーザープログラムを書かせる
普通のWindowsやLinuxのようなOSのタスクを念頭に考える人にとってこれも混乱のひとつに
なるだろう。あとTCBという言葉の意味もかなり変わってる

こうした特殊な意味づけは個々の商品・製品・システムの中のローカル用語なのだから
こういう場でポーンと無造作に使えば混乱するのは仕方ない

このスレには様々なセカイの人々が入り乱れてる

　�@-a　厨房タスクシステムのセカイ
　　ネットで発生。主成分は純真無垢な中二。一部2Dオヤジ、レトロ765信者。>>2とか松浦本がバイブルだ
　　知的水準としては松浦先生のタスク解説に感銘を受けCodeZineの記事は参考になるという程度
　　彼らがタスクというとき、それは画面に表示されるキャラの構造体やクラスのインスタンスのことらしい
　　それは自称TCBなる管理領域の変数を侵入・癒着させており、連結リストに繋がれてるようだ
　　彼らはOS用語を変質させ特殊な意味を与えてしゃべる。予め>>2や松浦本を読んどかないと理解不能だ
　　若年層は純真無垢な中二なのでタスクシステム＝負け組のかっこ悪いコードという印象操作に弱い
　　最近はひらしょー本でアンチタスクに鞍替えし�A-aになった者が多いように見受けられる
　　
　�@-b　幻想タスクシステムのセカイ
　　ネットで発生。�@-aの末期症状。主成分はファンタジー、若気の至り。原理主義。教条主義。OOで再解釈
　　彼らは全ての処理を唯一のリストに放り込み1/60[s]周期で逐次処理することこそ美しいと確信する
　　あらゆる粒度の処理を唯一のリスト巡回＆関数アドレス経由で実行することこそ真のタスクシステムと信じる
　　シーンも敵も味方も通常弾も誘導弾もアイテムもパーティクルも何もかも皆同じリストに入れなきゃ異端
　　可視属性も不可視属性も関係なく全ては1/60[s]固定時間刻みで周期的に実行されるものであるとする
　　OOで再解釈するとこれはGoFのobserver patternだったのだ（←な、なんだってー！？）strategy pattern
　　だったのだ（←な、なんだってー！？）といったかなり無理矢理な話をはじめたりする。狂気に見えるが
　　どうも本気らしい

　�@-c　中小零細タスクシステム使いのセカイ
　　亜種多数。逆引き本もその内のひとつ。現在でも中小零細ソフトハウスのモバゲ・DSの現場でたまに見られる
　　あと7号の現場にも見られる。プロっつってもピンキリ。キリはモバゲに多く、ピンは7号に多い傾向にある
　　�@-a �@-bとは異なり現場で使い込んできた人間であるため無茶苦茶なことはいわない。欠点も承知している
　　タスクシステムというのが身内でしか通じないイナカッペの方言・ローカル用語であることも承知しており
　　お天道様の下でタスクシステム万歳と声高に叫ぶ者は稀
　
　�@-d　昔はタスクシステム使いだった人のセカイ
　　自称タスクシステムといっても千差万別であり、�@-a,b,cとは似ても似つかないようなお化けが存在した
　　SSのAに近い統合開発環境だったりしたけど、こういうものは現在ではミドルウェアだのゲームエンジンだの
　　フレームワークだのと呼んでいるよ

　【アンチ】

　�A-a　アンチタスク厨
　　ひらしょーのおかげで我に返った�@-aや夢破れた�@-bがアンチタスクに鞍替えした。が、所詮は厨房。
　　タスクシステムの問題点を上手に説明できないので�@-c �@-d �A-cに諭されたり、同水準の�@-a �@-b に
　　馬事雑言を浴びせられる
　　アンチタスク気取るには経験による裏打ちと理論武装が不可欠ということを知らしめる存在である

　�A-b　プロアンチタスク
　　タスクシステムを使い込んだ�@-c �@-dがタスクシステムの急所を正確に狙い撃ちしています

　�A-c　アンチ[厨房タスクシステム]、アンチ[幻想タスクシステム]、アンチ[厨房アンチタスク]
　　アンチタスクではない。タスクシステムの名を貶める厨的でファンタジーなタスクシステムがお嫌いな人々。
　　�@-a �@-b �A-a �A-bが発信する欺瞞情報に突っ込みを入れる�@-c �@-dである

　�A-d　アンチ[タスク厨]
　　アンチタスクではない。タスク厨がお嫌いな人

>>986

×　ようなハードウェア
○　これはハードウェア

>>987
×　>>2ではユーザー自身がジョブを分割し周期タスク用のユーザープログラムを書かせる
○　>>2ではユーザー自身がジョブを分割し周期タスク用のユーザープログラムを書く

>>990
朝一番は寒くて知能が一層働かない
罵詈雑言、ばりぞうごん、だよ
馬耳東風とこんがらがっちったよ

>>986-992
正直言ってキモイ
次スレにこれを持ち込むなよ

アンチ完全勝利か
もうタスク信者も終わりだな
ひらしょの一撃で弱り切ってたところでこの大敗退
決定的だな

>>994
最近の流れはまともにプログラムを書けない基地外アンチが馬鹿にされてるだけじゃんｗ

ひらしょーの奇襲攻撃が強すぎだろ
セガの技術者に知らないなんていわれたら
求心力なんてなくなっちゃうだろ

最近、タスクシステムを過小評価している、と噂される某企業の経験者の名が散見されるが、



ひとこと言わせてもらおう。





○ガねぇ〜。
そう言えば自分が本当に好きだ！と言えるゲームの中には・・・。！！！
へぇ〜、タスクシステム知らないんだ！！
ふ〜ん！！！

ちんこ

999!

1000なら>>1が死亡

このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。