1乙
1おつ
前スレ
>>995 を実行しようとしたら、
「MSVCP60D.dllがみつかりません」って出て実行できんです。
同じく下記2ファイルがみつかりませんと出てきた MSVCP60D.DLL msvcrtd.dll
windows用の関数のスタブを用意したりして linuxにてコンパイルして動作確認はできた boost, boost build必須だけど…
boostはいらんな、 なんかCTextBuffer::Openで落ちるから色々調べてたときに使ってただけね パスやらファイル名の問題で*.mqoが開けなかったときにぬるぽが発生して落ちてただけね あとglutの初期化忘れとか タスクシステムと全然関係無いですねゴメソ
>>4 それVC6のデバッグ版のDLLだな
うちは入ってるから気づかなかったが
>>995 はリリース版でビルドしちゃれよ
ここで10年前に買ったVC6の恩恵を初めて受けることになるとは
>>7 ガッ!(AA略)
>linuxにてコンパイルして動作確認はできた
さすがゲーム板。いや、LinuxでブートCD配布とかできたらと思ってたので。
>前スレの人
・実行順制御よりオブジェクト相互の関係が重要
サンプルを組んでみて、そのあたりの解決が提示されているわけではなさそうですね。< タスクシステム
サンプルのなかで、プレーヤーオブジェクトをポインタで保持してたり、その弊害を
避けるためにフラグ立ててたりとけっしてスマートとはいいがたいような。
TCB+関数ポインタをクラスで置き換えるのは悪いとはいわないが、オブジェクトの
生成削除が頻繁に起こるゲームで、std::listで管理するのはどうかなと思いました。
手軽ではあるのだけど。
>前スレの人 >実行順制御・描画順制御 まだ慣れていないので評価しにくいですが、サンプルではシナリオの読み込みとか優先度を高くしてありますね。それなりに意味はあるのか? 描画順制御についていえば、OpenGL を使っていても半透明オブジェクトの重ねがき みたいに描画順をメンテする例もあるので、まあ、あれば使うかなと。 (爆発表現にちょっとつかってみた) 描画に関してはもっとちゃんとしたやり方があるように思いますが。
>>12 > オブジェクトの生成削除が頻繁に起こるゲーム
今時のマシンなら高がしれてるよ。エフェクトでパーティクル個別に new するとかだと、さすがに
氏ねと思うが。
>>14 >今時のマシンなら高がしれてるよ
CPU負荷や処理速度じゃなくて、サンプルの例だと、stl::list からオブジェクトを
削除する場合のトリッキーに見える処理がちょっといやらしいかなと思ったんですよ。
ただ、シーケンシャルな処理だと考えればそんなに問題もないのかな。
>>15 そういう話なら同意。というか、何でもかんでも一つのリストにつながなくても、ふつーに
std::list<Enemy> enemy_list;
std::list<Effect> effect_list;
と分けとけば良いのにね。
今時のマシンでもメモリ問題は意識すべきだよ。 少なくとも自分以外の人に遊んでもらえるゲームを作るつもりならね。 モジュールのライフスパンに応じて適切にヒープを分けるだけなんだから 最初からやれば手間はかからない。 今時はコンシューマゲーム機の開発者でさえもメモリ管理をおろそかにする未熟者が多い。 マスターアップ近くになってフラグメント化のためゲームがハング。 対策を練ろうにもグローバルでnew、deleteだったから全部書き直しするしかないという 実話もあるほど。
1GHz 512MB VRAM8MBで起動した 超絶スローで
>>17 CodeZine のサンプルはメモリ管理にこだわってたよね。
「タスクシステム」の要件にメモリ管理を加えるべきか、みたいな
話もあったけど。
>>18 >VRAM8M て、trio64とか?w
さすがにOpenGL のハードアクセラレーションないとちょっときついかと。
>>17 > 対策を練ろうにもグローバルでnew、deleteだったから全部書き直しするしかないという
なんでそうなるんだ?
「モジュールのライフスパンに応じて適切にヒープを分けるだけ」なんだろ?
後でもできるじゃん。
>>17 メモリの断片化が問題になるのは、極端にサイズが大きいものと小さいものを
同じヒープから確保する場合。
テクスチャ・モデル・モーション・サウンドなどのリソース類だけ分けておけば、
あとのゲーム制御用のインスタンスは気にせずグローバルなヒープから new,
delete で OK だよ。
そんなどんぶり勘定が許されるのは素人ゲーだけだよ 少なくともヒープ使用量の最大値は見積もれていないと 売り物にしてはいけないね。 フラグメント化対策の方法論なんて確立されているんだから それをおろそかにするのは単なる手抜き以外の何者でもない。
まったくだ。 「おそいかも」とか「フラグメンテーションが発生するかも」なんていう どんぶり勘定で面倒なメモリ管理コードなんて追加しちゃいけない。 「ここがおそいことがわかったから」「ここでフラグメントが問題になったから」と 言えるなら何か細工を入れてもいい。言えなきゃおとなしく new/delete 使っとけ。
問題になるまではGCやsmart_ptrを使っていてもおkと
いいよ 仕事でやってるやつはみんな何回も痛い目見てるから自然と神経質になる 問題が出ないうちから考えてもアタマでっかちになるだけ
>>23 > そんなどんぶり勘定が許されるのは素人ゲーだけだよ
気のせい。
newとdeleteはやたら使用メモリの全体量がわかりずらいな mallocからしてロクなもんじゃなかった気がするけど newとdeleteほどアフォ仕様じゃなかったよな オーバーロードするといちいちそのヘッダ呼ばないと newとかdeleteとか呼べないしで糞面倒くせぇ せめてデバッガで見えれば助かるんだけどそういう機能ってないの?
>>28 ふつー ::operator new() ではなく、クラス内の operator new をオーバーロードするから、
必然的にヘッダ読み込むことになると思うが。
メモリ使用量は、使ってるライブラリによるな。俺は自前で書いたのがあるから、それを
使ってるけど。
タスクシステムと分岐予測やパイプラインの関係を考察してるようなサイトありませんかね? ググッてもこのスレばかりヒットしますw
>>28 >mallocからしてロクなもんじゃなかった気がするけど
それ実装対象・OS・ライブラリの組み合わせに依存した話
例えばおまいらが大好きなx86系PCとWindowsとVisualStudioの組み合わせの場合
VS付属のmalloc、デフォルトのnew/delete、STLのデフォルトアロケータの中身を見れば
どれもHeapAllocに行き着く
暇だった頃にベンチマークテストして遊んだけどHeapAllocが他のアロケータ
(GNU libc malloc、BSD Malloc、etc)と比べてロクでもないという感想にはならなかったな。
HeapAllocはおそらくDoug Lea Mallocそのものかその親戚筋に相当する実装だろうと思う。
>>28 はdlmalloc系がロクなもんじゃないと言いたいの?それともヒープ使用量をモニターする
手段が見つからないからロクなもんじゃないと言いたいの?
>>22 >極端にサイズが大きいものと小さいものを
>同じヒープから確保する場合
「極端に生存期間が大きいものと小さいものを同じヒープから確保する場合」
も付け加えといとくれ
>>32 だけど
>>21 で既に生存期間の話出てるね。文盲だね
ネトゲのサーバプログラムとかだとオブジェクトの生存期間の差はかなり強烈なものになるから
例えばWindows系ならHeapCreateとかで適切にヒープ領域を分けといたりするけれど、PCゲーの
クライアントプログラム限定の話ならぶっちゃけこんなの要らん
数ステージを巡回するデモンストレーションモードで数日間ぶん回してメモリ確保に失敗し始めたり
タスクマネージャのグラフが愉快な絵を描いてるとかNtQuerySystemInformationでログ取り続けたら
驚きの結果が、とかならフラグメンテーション云々の可能性を考えてもいいかもだが
そういう場合はステージ毎にHeapCreate/HeapDestroyでドバっと確保・ドバっと開放でもしとけばいい。
これならステージ中のオブジェクトはみんなHeapAlloc系使ってもフラグメントの心配いらね
弾とかパーティクルみたいなサイズ・生存期間共に粒度極小のオブジェクトを大量にばら撒く
ゴジャースなゲームなら表示MAX分だけドバっと確保したboost::pool使うか配列で順序なしのリスト
みたいなことやっとけばいいよ
ところでタスクシステム?ハァ?って感じだな
>>31 俺はそんな難解な話してない
使ってるメモリの使用量がわからない・わかりにくいってただそんだけのこと
あと、メモリリークとかも全然わかんねぇ
IDEの問題になるけど分かる要素がないのがひでぇl
で、俺の知識だけだと自分でmallocをラップした関数を実装して
それに使用メモリの総量・使用メモリ状況やメモリリークなんかを
チェックできるようにしてるんだけど
この辺っていつまでたってもウンコじゃね?
とかそういうこと言ってる
(俺が知らないだけかもしれんが少なくともVCはウンコだと思う)
>>30 マジに最適化し出すと、関数の並び順とかまで見直す必要がある。PS2 のときには
キャッシュがマジ少なかったので、ライブラリチームは T15000 使って最適化してたけど、
今はそこまでやってないんじゃないかなぁ。
ゲームロジックはキャッシュミス起きまくりだが、そもそも大して CPU 使ってないので
気にしない。昔も今も。
>>33 パーティクルとかの小さなオブジェクトは STLport の node allocator 使ってた。メモリが
多少無駄になるけど、早いし断片化しないので。
>>37 こっちも確認するけど
それアフォがソース見てもわかる奴しかでない奴でしょ?
難しいリークだとアウトプットウィンドウに変なコードがずらずら出てもどこのコードが
リーク起こしてるかまったくわからない機能でしょ?
そんなの使えないよ
正直、その機能に頼るぐらいなら自分でmallocをラップしたほうがよっぽどいい
ちなみに使ってるのはこれ _CrtSetDbgFlag(_CRTDBG_ALLOC_MEM_DF|_CRTDBG_LEAK_CHECK_DF); なんでこれさ こんなアフォなんだろうね 俺のいる会社の新人だってこんなアフォな機能作らないと思うよ やっぱり俺の使い方間違ってる? ってかそれとももうちょっといい使い方あんの? さすがにこりゃねぇだろうと思った だって自分でやればどこのソースのどのコードが使ってるメモリなのか 余裕でわかるようにできるじゃん これまったくわかんねぇじゃん 動的(わからない法則がちょっとわかってないが)に確保したもんだとほぼお手上げじゃね?
飯くってた
>>36 node allocatorは良いものらしいね
>>38-39 把握した
WindowsだのVisual Studioなど言ったって、なんだよ結局はユーザープログラム固有の
モニタプログラム(システムモニタ(リソースモニタ)やジョブモニタ)を用意しなくちゃ
いけなくなるのかよバーローつー話だよな
通常、ゲーム開発用のフレームワークはデバッグ支援用のツール群とセットになってるけど
それに相当するサービスをVS標準機能に期待するのは難しいね
ま、同人ゲームとか、ここでタスクシステムすげぇすげぇ言ってる超小規模開発・個人開発なら
無用の機能だが
前
>>969 (前略)だからコンテキストスイッチは不要では。
>コンテキストスイッチは要らなくネ?
ゲームに要求される表現は多様化・高度化し続け、それに伴いゲーム内で処理されるジョブの粒度も多様化し
1イント内に処理すべきジョブ数も増大の一途をたどった。ジョブ(ゲームコード。例えばAI)を記述するスタッフも
増大し多様化した。時間ステップ毎に単純に数値積分していくだけのジョブばかりではなくなり、継続(continuation)
が必要なジョブが増えた。にも関わらずゲームの特性上個々のジョブはμsecオーダーで終了ないし中断することを
要求される。継続に必要な手続きをユーザープログラム側に丸投げする(ユーザープログラム側にリエントラントな
仕掛けを用意させる)原始的なFSMモデルのジョブ制御だけではお話にならなくなり、ファイバーやコルーチンのような
仕掛けも必要になった。これらのジョブの粒度はスレッドを使うには小さすぎ、また数も多すぎる
まぁ、同人ゲーやタスクシステムすげぇすげぇ言ってる超小規模開発・個人開発なら無用の機能ではあるが
スゲー参考になってありがたいけど同人シュー制作者の俺にはテラコンプレックスw
(訂正)
----------------------------------------------------------
>(前略)だからコンテキストスイッチは不要では。
>
>>コンテキストスイッチは要らなくネ?
↓
>(前略)だからコンテキストスイッチは不要では。
----------------------------------------------------------
>1イント内に
↓
時間ステップ毎に
----------------------------------------------------------
(補足)
一部素人がタスクシステム(以下
>>2 と呼ぶ場合アリ)とか呼ぶものの実態が
>>2 程度のものであるという前提に立つならば
これは70年代のハードに依拠する簡素なゲームにとっては無難なジョブ制御プログラムとかモニタプログラムの【断片】だね
しか言いようがない。もはや今となってはね。
これは非常に簡素でオーソドックスなFSMモデルのジョブ制御であり、大昔から科学計算で頻繁に使われ
大昔の計算機、現代でも組み込み用途の超貧弱なマイコン(安いものなら50円前後。RAM数KBとROM数百KBの
ワンチップのやつ。半ば使い捨て)のために用意される超原始的なモニタプログラムにも見られる。
継続に必要な仕掛け、つまりコンテキストスイッチに必要な記述は全部ユーザープログラム側に丸投げ。
何もしてくれない。誰が書いても同じようなものになるってくらい凡庸な、道端の雑草並みのありふれた仕掛けだ。
でも「タスクシステム」という呼び方は珍しい。かなりエキセントリックだ。これは特定の職場内の固有名詞
ローカル用語の粋を出ることはないだろうね
>>41 AIについてで実装できてるわけじゃないから強くは言えんけど
タスクシステムの構造を大きく変えるような手を入れなくてもできそうな気がする。
別スレッドで定期的にタスクを位置等のグループ毎に分割して、グループ内での状況を解析する。
そしてタスクに次に処理がきたときに、次にどう動かすか考えるの役立つ情報をセットする。
とかではだめですか。
>ゲームに要求される表現は多様化・高度化し続け で、そんなリソース大量消費型ゲームと小規模DSゲームの売り上げが変わんなくて 涙目、という話ですね。わかります。 とかそんなつまらんイヤミはおいとくとして、タスクシステムのサンプル打ち込んで おもしれーなとか言ってる俺には雲の上の話なんだけど、 >原始的なFSMモデルのジョブ制御だけではお話にならなくなり、 こういうところはなんとなく予想できるんだよ。ただ現実問題として >同人ゲーやタスクシステムすげぇすげぇ言ってる超小規模開発・個人開発 が、手軽に手をだせる、楽チン開発できてウハウハなフレームワークってあるの? どうせ勉強するんならそっちのほうがいいような気がすんだけど。
>>45 C++ でふつーにメインループ書いて、continuation っぽいこと必要な部分はスクリプト言語 + スタックレス VM で良いじゃん。lua とか。
Q.【
>>2 のようなプログラムを「タスクシステム」と呼ぶことに固執し広めようとする人間がしばしば笑い者になるのは何故?】
技術は進歩し続け、計算機は猛烈な勢いで処理速度を向上させ、現代のナウいハードに依拠するナウいゲームを
作るために『『不可欠』』となったナウいフレームワークだのゲームエンジンだのと比べるともはやミジンコ級であり
お世辞にもシステムとはとても呼べない玩具みたいな代物であることは否めない
>>2 のような小規模で簡素なFSMモデルのジョブ制御は、原始的なモニタプログラムといえるかもしれない。
しかし一般にOSを表す非プリエンプティブマルチタスクシステムとは明らかに異なる。共通項は非プリエンプティブ
という点だけでありコンテキストスイッチをサポートしていない(その責任をユーザープログラム側に丸投げ
してしまってる)時点でマルチタスクシステムとは明らかに異なる。マルチタスクという用語自体は1960年代半ば
オペレーティングシステムという用語と共に誕生した。UNIVACとかSystem/360のOSが出てきた時代の話。
エンジニアは用語の意味が輻輳を起こし意思疎通に齟齬が生じることを嫌う。OSが提供されないカスタムボードで
走るゲームプログラムの開発者なら兎も角、立派なOS下で走るゲームプログラムの開発者にとってタスクはプロセスだ。
>>2 は、過去に「とある開発チームで使われていた原始的なモニタプログラム」が固有名詞として「タスクシステム」と
呼ばれていたのかもしれないね、程度の理解でいいと思う。当時のゲームプログラムはOSが提供されないカスタムボードで
走るものであり、ゲーム開発者自前のモニタプログラムを用意しハードの全てを自分でコントロールした
#google2001の検索結果によると当時「タスクシステム」などと呼んでるページはほぼ皆無だったことが判明している
#ほんの一部でその単語を使ってたページは出典としてLogician Lordを紹介していた。ネットで徐々に伝播しCマガで
#松浦とかいう素人プログラマが出典を明記せずに紹介し急速に流布し広めた「タスクシステム」なる呼び方の出所は
#Logician Lordだろうと思われる。これがネット発の「タスクシステム」なるものの出自だ。都市伝説と呼ぶに相応しい
>>46 スタックレス + lua でググった。
なるほど、いまどきはタスクシステム(FSM)でカリカリやる、やれるくらいの規模の開発
なら、単純なメインループとスクリプト言語のほうが楽だしパフォーマンスも出る
ってこと?
難点はあのパスカルくささに耐えねばならんとこかなあ。ニントモカントモ。
>>48 状態遷移が複雑な部分、たとえばアクションゲームのプレイヤー制御とかは
C++ で書いといて、continuation あった方が楽な部分、たとえば「何秒後に
エフェクト発生」とかはスクリプトとかデータファイルで書くのがふつーじゃね?
>>42 必要ないものは取り入れる必要はない。コンプレックスは持つ必要ない。
俺も同人ゲーを作ったことあるが規模相応の簡素なコーディングで済ませてた。
いわゆるタスクシステムとか紹介されてるあのヘンテコな仕掛けも不要だった。プライオリティ?ハァ?って感じだ。
敵の配列が弾の配列があって。そんな感じだ。
タスクシステムを心の底から崇拝する人間が心の底から子バカにしている様子がたまに見受けられる
配列厨のコードそのものだ。
同人ゲームを悪く言うつもりで書いたわけではないのだが、もし
>>40-41 の「同人ゲーム〜」の部分が気に障るなら
そこは撤回する。すまなかった
>>49 luaはver4のころちょっとかじっただけなんだけど、スクリプト処理のために
組み込んでみようとは思ってたんで、考えてみるよ。ありがと。
>>44 多種多様な人間が多種多様なジョブ(ユーザープログラム)を記述することになると
「FSMモデルのみ」という拘束条件は必ず無理が生じる。これはやれば分かるという他ない
RAM数KBの組み込み用モジュールのモニタプログラムでもコンテキストスイッチをサポートしたがる。
FSMモデルでジョブを記述させると色々面倒くせーことになるから。説明するよりも組んでみたほうが
分かるという他ない
>別スレッドで〜
よく分からんがコンテキストスイッチをサポートしたくないがためだけに
何やら複雑怪奇な仕組みを導入する話のような気がしてならない
素直にLuaとか使ったほうがいいよ。というか眠いばいばい
>>50 >規模相応の簡素なコーディングで済ませてた
そこんとこがよくわからんのだよなあ。
単純な配列とループで組めて問題ないならぜんぜんOKでしょ。俺もそうする。
ただ、サンプルでも使ってる GLLib の人のサンプルソースは単純ループ
だけど、けっこうきつい印象を受けた。
俺も「タスクシステム」を採用するだけでバラ色の未来が開けるとは思わん
(まだかじっただけなんで実はすごい泥沼が待っているのかもしれない)けど、
そこそこ使いまわしが効いて、それなりに見通しがいいように思う。
要は適材適所じゃないかと思うんだが、用語を使うことすら非難するほどの
問題があるの?
>何やら複雑怪奇な仕組みを導入する話のような気がしてならない こういうのは、同意できるんだよね。 そこそこ便利そうだけど決してわかり易い仕組みとはいいにくいから、 なんか泥沼にはまりそうな気がする。 まあ、小学生の感想文ですまん。
タスクシステムが有効なのは小規模システムだな メモリの単位がkまでの環境 Mになると不要
>>55 キャッシュじゃねーかw<k
あー、PICのプログラムとかそれっぽい。
AVRは俺の嫁
i君はルサンチマンに満ち溢れてるなw
>>48 Luaの文法が嫌いならSquirrelもいいよ。
ム板でスレタイ検索してみてくださいな。
>>53 自分の書いた文章で古い設計方法に名前がついたことにより
予期せぬ形でもてはやされるようになってしまった。
そのことに対する責任感から現代的な知識を伝えると共に
言葉狩りを行っている。
彼の行動はこのように解釈することもできる。あくまで妄想だが。
タスクシステムを使ってるプログラムの メモリ・ポインタまわりのバグり具合はハンパじゃないな フツーに書けとあれほど言ってるのにやって ゲームと違うところでいっつも四苦八苦してるとなりのプロジェクト あんまりポインタ周りのバグが酷いからプロジェクトをまたいだ会議で 原因を指摘してやったのにまだごにょごにょ言ってる もう、お前(となりのプロジェクトのウンコリーダー)に逃げ場はねぇよ グローバル変数とタスクシステムとポインタの悪用は絶対に全部セットなんだよな タスクシステム使わないプロジェクトはグローバル変数も使わないしポインタの悪用もしない だからプログラムがメインから必ず終えるし 組み込むべき箇所もすぐにわかる 第三者がきてもすぐに全体が把握できるってのはでかいね もういい加減に信者も目を覚ますべき
メモリ、ポインタを怖がるってプロとしてどうなのw
馬鹿が触ったポインタほど怖いもんはねえぞ
確かにコンテキストスイッチがないとグローバル変数に頼らざるをえない。 コンテキストスイッチがあったところでスパゲティにする奴はするけどなw
nullポはいねぇがあ〜?
>>48 昔Delphi使ってたから、馴染みはあるんだけど、C/C++と併用すると間違うんだよね。
演算子とか。
>>60 あー、それは俺も気になった。
親クラスのメソッド呼んだら、内部で自分自身を削除してて戻ってきたところで落ちるとかw
俺がタコなだけなんだけど、基本的にポインタを多用するスタイルみたいだしな。
几帳面なやつ向きかも。実はちょっとびびってるw
それタスクシステムとかいうナニに限った話ではないと思うんだけどな 相互参照オブジェクト(インスタンス)の取り扱いについてのごく初歩的な あらゆるプログラムに通じる基本的なお作法の話だと思うんだ
ポインタなくてもタスクシステム組めるけど?
>>66 んー、いいわけがましくなるけど、俺の場合、インスタンスの廃棄は生成した側
が責任をもつというスタイルだったんで、インスタンス自身が自分を廃棄する
という形式に慣れてないんだと思ったけど。
>>67 でも悪用するだろ?
しかもグローバル変数は使わないと恩恵(笑)は受けられないだろ?
所詮、アフォが飛びつく糞なアイテムよ
>インスタンス自身が自分を廃棄 その廃棄っていうのは、自殺を決断したらメモリ開放まで一気に行ってるわけだよね? タスクシステムとかいうナニにおけるインスタンス(というかエンティティなんだろうね)の 自殺のプロセスというのは、常にそういうもの(自殺を決意したらメモリ開放まで一気に決行) と決まっているの?それとも君が読んだ何かしらの自称タスクシステムのサンプルコードの 実装がたまたまそうなっていたというだけなの?
>>70 補足
>(自殺を決意したらメモリ開放まで一気に決行)
なおかつ生みの親や己を参照するインスタンスに何ら通知する手段を提供しない。ね
>>68 >俺の場合、インスタンスの廃棄は生成した側
>が責任をもつというスタイルだったんで
これも同じく。自殺を決意したら生みの親に自分を殺してくれと依頼するような手続きは
タスクシステムと呼ばれるナニにおいては「存在しない」ということになってるのか、それとも
君が読んだ何かしらの自称タスクシステムのサンプルコードの実装がたまたまそういう
手続きを用意していなかっただけなのか
自称タスクシステムってどれもこれも俺俺システムで内容がバラッバラだよね
>>70 イテレータに矛盾が生じないような工夫はされてたけど、delete はdelete だったな。
まあ、それでも、たまたま、じゃないかと思うけど。入門用サンプルだし。
>>72 そうかー。もし良かったらそれのURLとか書籍名教えてくれないかな
いや、別に悪戯とかしないからさ
>いや、別に悪戯とかしないからさ 却ってこえーよw こっちは勉強させてもらってる立場だからあんまりなー。 このスレを調べりゃわかるよ。
あー、ここに載ってるならいいや >却ってこえーよw 何にもしねーよ。入門用を謳う自称タスクシステムがいっぱいあるから そのカオスを更に加速させて「タスクシステム」がどんどん 「口に出すだけで何とも居た堪れなくなるムードを醸し出すキーワード」 になっていく様はある意味で痛快だしな。
いっぱいあるから → 増殖するのは結構なことだ
ちょっと大げさかもしれないけど コンテンツ産業に理解ある総理の下で 国策としてコンテンツ産業に力を入れようとしているのに 裾野を支える初心者が混乱に陥ることを喜ぶのは 日本人として恥ずかしくない?
タスクシステムすごくね? いつも途中で破綻する俺でもゲーム作れた
>>77 そういう、いかれた自称上級者はいつの時代にもいた。
タスクシステムを使うようになってからというもの、周囲がボクを見る目が変わったね。 なんかこう一目置かれてるって感じ? 隠し切れない風格を醸してるせいかコミュニケーションにも微妙な距離が生まれるみたい。 こういう孤独も上級者ならではの悩みだよね
自由度が高い分だけめちゃめちゃ遅い点はあまりつっこまれない、なんで?
遅いって何が?
仮想関数まで否定することになるな
なぜタスクシステムを嫌うのですか?(上位5回答) 1.名前が気に入らない 2.名前を付けた人物が気に入らない 3.名前の「システム」の部分が気に入らない 4.自由度が高いのが気に入らない 5.隣のプロジェクトが気に入らない
86 :
名前は開発中のものです。 :2008/11/16(日) 03:11:11 ID:DYIhu6LD
「気に入らないから叩かれてるに過ぎない」として批判を過小評価したがってる様子が ひしひしと伝わってくるけど、そういうワンパターンなかわし方を続けるのってのもどうなんだろうね
カプの開発で大規模に作っちゃったもんが タスクシステム使いまくりでバグりまくりなので そもそもの構造からいってすでにまずいってことがわかると困る人がいるのです
>>86 いやいや、俺はタスク使わんし・・・
批判の仕方が感情的だっつってんの
タスク派も嫌タスク派も、なんで自分のやり方が一番いいと思えるんだ?
>>88 二つの方法ですでに開発したことがあって比較した上での結論
早いレスども タスクシステムという名称は新しいものらしいけれど、 それ自体はかなり古い手法だろ? 当時対比されるべき「もう一つのやり方」は アセンブリで非構造化の逐次プログラミングだったはず 当時のタスクの本質がコンポーネント指向にあったんだろうと考えれば 取り込む要素があると思いこそすれ、非難する気には全然ならないんだよね なんつーか、フラッシュ使いがハイパーカードを非難してるようなモヤモヤを感じる
ちなみに旧ナ○コ系の一部では ジョブコン(ジョブコントローラー)と呼ばれていたらしい 他にも派閥によって呼び名が・・・おっとだれか来たようだ
>>87 以前このスレでも話が出たMTなんとかのことですか?
>>90 > 取り込む要素があると思いこそすれ、非難する気には全然ならないんだよね
C++ で仮想関数として取り込み済み。
70年代の技術でオブジェクト指向を表現したのがタスクシステム
別にゲームに限らず、関数ポインタ+データブロックという構造はよく使われてたけどな。 UNIX のデバイスドライバとか UNIX V6 の頃から、こんな作りだ。
当時としてはすごい技術だったという話は ・いまタスク使ってるやつは擁護になってないからスルー ・アンチはそんなの知ったことじゃないから叩く 技術史が好きなヤツにしか意味のない話です
だからタスクシステムの要点は ・メモリ管理 ・タスク管理 だって言ったじゃん メモリフラグメントに対して固定長データという回答を出したのがタスクシステムの功績 そして扱うべきデータがどんなデータであれ管理レベルでは等価である事がタスクシステムか否かの分岐点だと思うね ちなみに継承+多態はメモリ管理、タスク管理のどちらから見ても最悪なばかりか速度まで低下して何のメリットもない プログラムも複雑化してタスクシステムより尚悪い あと余計な事かもしれないけど、このスレが迷走しやすいのは「何を解決するのか」を定義しないで話を進めるからだよ 例えば「ジャンルにとらわれない万能オブジェクト管理システム」なんていう途方もない事であっても目的があるとないのでは 議論の濃さが全然違う 最後に何度も言ってるけど、・・・タスクシステムを使うには現在のPCはオーバースペックすぎると思うよ HSPでよくみかける固定長配列での管理よりわかりやすく速度的にも有利なタスクシステムなんて見たことないし 有意な差が出るとも思えない
100 :
名前は開発中のものです。 :2008/11/18(火) 07:37:14 ID:P1O//Y8n
わけのわからんこと言い出すからレスが止まっちゃっただろ
>ちなみに継承+多態はメモリ管理、タスク管理のどちらから見ても最悪なばかりか速度まで低下して何のメリットもない >プログラムも複雑化してタスクシステムより尚悪い お前は継承も使わずにプログラムしてんのか?
Cには継承ないよ haskellには継承なんてないけどそれでも綺麗なコードの実用プログラムが沢山書かれてるよ
なんで唐突に Haskell が出てくるのかわからんが deriving とか知らないのか? で、必死になってメモリ管理とか叫んでるひととか、バカにしようと必死な人とかは スルーしたほうがいい気がする。
>>99 >タスクシステムっていうのは
> ・メモリ管理
> ・タスク管理
>の2種類から構成されている
前スレログ読みましたが、クラスを使うとフラグメントが発生どうのとかよく分からない話をして
数人から突っ込まれてたID:IuSgJyHuさんですか?たぶんそうだろうかと私は思うのですが。
ところであなたの言う「タスクシステム」とやらは具体的に何なのでしょう。これと思う実装例が
あるならそれを示してくれませんか。人によって定義が千差万別の俺俺システム「タスクシステム」
ですから、その言葉を発する人間が登場する度にこうやって確認せざるをえないわけで。
このように、確固たる出典がない、言い方を変えれば権威が不在というのは不便なものです。
技術用語としての存在価値が疑問視され、所詮はローカル用語といわれるのも頷けます
>メモリフラグメントに対して固定長データという回答を出したのがタスクシステムの功績
ん?70年代中期・末期において主記憶をページング方式で管理することに新規性があったと。
簡単のために操作対象を固定長に分割・管理する、つまり固定長レコード方式というものに
新規性があったと。そういうお考えで?
当時のソフトウェアエンジニアの通念というものが集計できるならば、あなたの考えは当時としても
非常に珍しい類のものだろうと思います。かなりエキセントリックだろうと思います
まぁ確かに、計算機についての基礎教養が欠乏、というかむしろ知的水準が絶望的に低い人間
にとっては世の中のあらゆる仕組みはあらゆる時代を通じて常に新規性に満ちた凄いテクノロジー
なのでしょうけど…
そういう知的弱者・情報弱者・底辺階級をターゲットにした功績話を絶叫するのはあなたの趣意ですか?
i君乙 あいかわらず厭味だねぇ
変わらぬ芸風も、また一興
>>101 今は継承を使わないのが流行り
おまえだってhasAにしてるんだろ?
特に深い継承はアンチパターンになりつつある
継承+多態の効率の悪さはいわずもがな
ゲームで使っちゃいけません
>>102 継承は基本的に汚いコードになると思うよ
設計書は綺麗になるけど
>>104 ギャラクシアン以外をタスクシステムと呼んでるのは某よっちゃんいかの人だけだよ
固定長レコードというCOBOL的なものをゲームに持ち込んだのは新規性がある
そもそも固定長レコードはフラグメント解消のものではなかった
バナナでクギを打った所に新規性があるんだよ
トンカチあるから必要ないよねっていうのは別の話
>>107 "is a" 関係でも継承使わないってこと?それだと無理なコードにならない?
効率が悪いというけど、そもそもゲームで CPU 処理時間がボトルネックになること
すら稀なのに、さらにそのうち継承+多態によるものは数%以下でしょ?
ヘビーなループ内では問題になることもあるだろうけど、はじめから使わない前提に
する必要は無いと思うよ。
>>107 > 今は継承を使わないのが流行り
実装継承とインターフェース継承を混同しとるな。
>>107 > 固定長レコードというCOBOL的なものをゲームに持ち込んだのは新規性がある
固定長レコードはそれよりずっと以前のパンチカード由来。例えば19世紀末のタビュレーティングマシン
そこから進化したユニットレコード装置とかPCS(パンチカードシステム)とか。(※)
この時点でパンチカードのレコード長は大抵【80カラム】。これが処理単位だった
それがそのままコンピュータの記憶装置に使われ、その後の記憶装置の仕様にも反映された
アセンブリ言語のプログラムは一行80カラム。データも同じく。メインフレームのRecord Oriented Filesystem
初期のFORTRAN、OSのジョブ制御言語、COBOLなどなど、あらゆる処理の単位としてこの【80カラム(バイト)】が
当然のごとく登場した
FORTRANが登場したのは1950年代の半ば
COBOLが登場したのは1950年代の末
(※)更に遡れば19世初頭のジャカール織機だとか18世紀末のオルゴールだとか色々あるかもだが
(訂正)
> アセンブリ言語のプログラムは一行80カラム。
↓
アセンブリ言語のプログラムは80カラム単位でロードされた。
----------------------------------------------------------
>>170 > そもそも固定長レコードはフラグメント解消のものではなかった
固定長レコードとか固定長データとかいう構造(要するに配列)が大昔から現在まで色んなところで
便利に使われてるのはその取り扱いが、実装が、極めて単純だから。
例えば
・データの所在(番地)が容易に算出できる
先頭番地+オフセット。このオフセットがレコード長*レコード番号で済む。
処理が単純化できるし回路も単純化できる。つまり真空管数(トランジスタ数)を抑えられる
占有面積も重量も放熱設備も電気料金も抑えられる。
・外部フラグメンテーションの制御が簡単
記憶領域を【容易に】再利用できる
最大長を決めてるからデータ書き換え時には旧データに新データを直接上書きできる
などなど。頻繁に書き換えるデータにはどれも重要な特性。
固定長なデータ構造はそのメリットの大きさゆえに、デメリット(レコード内の無駄。内部フラグメンテーション)
が許容されるケースは多い。COBOLも、COBOLが登場する以前の事務処理プログラムも可変長データの大半は
最大サイズを決めたうえで固定長レコード、それを収束した固定長ブロックで格納した。
今のRDBや簡素なDBMも基本的には同じ
>>170 > バナナでクギを打った所に新規性があるんだよ
> トンカチあるから必要ないよねっていうのは別の話
その例え何かおかしくないか。常温バナナで釘を打つのは確かに斬新な愚行だが
規模がまるで違うものを指してトンカチと冷凍バナナという話をしているのかなと前向きに解釈してみるか
大昔には科学者もエンジニアもシステム屋もみんな今とは比べ物にならないくらい貧弱なハードでやり繰りしてた。
FORTRANやCOBOLが登場する以前の計算機を駆使する人間は多かれ少なかれ今で言うところのハッカーじみた
技能やバッドノウハウを身に付けて自前のサブプログラム群をシコシコ作って自前ライブラリ用意したりした。
FORTRAN登場後も初期のFORTRANコンパイラの最適化は不十分で最内周ループ処理など頻繁に呼び出す処理の
アセンブリコードを自分で書く利得は大きかった。(※)
これらは日本のビデオゲーム業界が隆盛を誇るずっと以前の話
つまり、ド貧弱な装備でシコシコ戦うことを強いられ、セコくて貧乏くさい高速化テクやリソース節約テクを駆使してたのは
何もゲーム業界固有の境遇・逆境だったわけじゃない。もしゲーム業界固有だなどと思い込んでる人間がいるなら
そいつはルサンチマン君だ
(※)その後BLAS、LAPACK、MPIなどなど先人の開発した優れたライブラリが沢山登場し
FORTRANコンパイラの最適化機能もとても優秀なので自前でシコシコする必要なくなった
(訂正)
>>170 ↓
>>107 >規模がまるで違うものを指してトンカチと冷凍バナナ
↓
本来の用途がまるで違うものを指してトンカチと冷凍バナナ
>>108 俺も継承は使わないほうがいい派
実装とかインターフェイスとか関係無い
そのメソッドやメンバがどのクラスのものであるのかわからなくなるのが最大の害だと思う
しかもオーバーライト(?名前忘れた)されると今度は同じ名前のメソッドがあって
どれを呼んでるのか本格的にわからなくなる
どうしても使わなきゃならんのがMFCみたいな変態実装になってる場合
自分に内包してるモンを継承使って書き換えさせるウンコソース
これは仕方がない
でも、できるだけhas aの関係でまとめたほうがいいと思う
>114
ttp://www.bizlogic.co.jp/techinfo/reconsider/inherit.htm >新人プログラマほど継承を乱用します.特に新人が好むのは、
>コードの再利用のための継承です.(中略)
>新しいサブクラスが必要になって定義しようとしたら、親ク
>ラスに不整合があることを発見して修正.すでに定義済のサ
>ブクラス群に影響が出るためそれらを修正.その影響がクラ
>スのクライアントに出ることに気づかず、バグが連発.修正
>を繰り返すうちに設計し本人しか理解できないような継承階層が完成・・・
イイハナシダナー
耳の痛いことだが、とりあえずタスクシステムのせいじゃないと思うんだw
ギャラクシアン以外をタスクシステムとして認めない原理主義者が現れてスレ的には おめでいたいことだが、狭量すぎやしないか? とりあえずメモリ管理については ・当時はそもそも自前のメモリ管理以外存在しない。 ・メモリに制約のあるシステムならタスクシステムでなくても必要 だから、タスクシステムの絶対条件じゃないと思うんだが。
そもそも当時と今とでは 「メモリ管理」って言葉が指すものがだいぶ違うからな。 今のゲーム開発だと メモリ管理モジュールの綿密なアーキテクチャの設計と実装を主に指すけど、 当時のは「管理モジュール」なんて呼べないような極々シンプルなものだからな。
>>117 CUDAを調べてて思ったんだが、メモリ・ワークをどこにとるかでパフォーマンスが
大幅に違ったりするみたいだし、いまどきのゲームのメモリ管理ってそうなんだろうな
3スレ目になったが、今だに喧嘩腰じゃないと議論もできないのか・・・
ああいや、個人を指してるわけじゃなくて、 スレ全体の雰囲気のことを言ってる。
>>118 >
>>41 によれば「タスクシステム=FSM」だそうだから
>>41 では「タスクシステム=FSM」というような趣旨のコメントはしてない
>>41 までは「ここでタスクシステムと呼ばれてるものが何なのか知らんけど」という立ち位置でコメントしてる。ただ
そのままの状態でポエムを書き続けるのは難しいんで
>>43 以降はみんなのテンプレ(?)と思われる
>>2 を引っ張り出し
「タスクシステムとは
>>2 」という前提(or仮定)のもとでコメントした
そして
>>43 以降(ID:mdtDWXyh、ID:U55fYg17)でも「タスクシステム=FSM」という趣旨のコメントはしてない
【非常に簡素でオーソドックスなFSMモデルの】ジョブ制御、【小規模で簡素なFSMモデルの】ジョブ制御
というような書き方はしてたが。これ通じ難かったんかな。一応意味を補足するためにダラダラ書いたんだが。
与えられたCPU時間でジョブを細切れにして処理の継続(continuation)に必要な手続きをユーザーに丸投げする
原始的なジョブ制御な
「70年代のハードに依拠する簡素なゲームにとっては無難なジョブ制御プログラムとかモニタプログラムの【断片】だね」
とも書いてるが、「70年代のハード」をちょっと修正すると「70年代〜80年代初頭にかけて登場した典型的な実装対象(※1)と開発環境(※2)」
(※1)基本的には○MHzの8bitCPUに○KBのRAMに○KBのROMのマイコンボード
これにOBJ(とかBGとか★とか)の表示や(固定)サウンドの出力やコイン制御のための回路や各種スイッチ(のインターフェース)
あと必要なら大容量ROMのバンク切り替え回路、などなどを付加したカスタムボード。
(※2)ここでは、8or16bitPC(或はマイコンボードをカスタムしまくってデスクトップPC化したTK-80BS みたいなやつ)と
簡素なリモートデバッガ、エディタ、クロスアセンブラ(別にハンドアセンブルでもいいけど)で構成されるもの
(訂正) ○MHzの8bitCPU ↓ ○MHzの8or16bitCPU
>>123 そういう立ち位置なんだとすると余計にわからなくなるのよ。
>「ここでタスクシステムと呼ばれてるものが何なのか知らんけど」
という立ち位置の人間が、ゲーム開発者ローカルな用語である「タスクシステム」
という用語とそのスレッドで、
>タスクシステムすげぇすげぇ言ってる超小規模開発・個人開発なら
てな形で批判的な言説を繰り返す理由が。てっきり
>タスクシステムを心の底から崇拝する人間が心の底から子バカにしている様子がたまに見受けられる 配列厨のコードそのものだ。
という形で小ばかにされたことをこのスレにぶつけてるんだと思ったよw 俺の立場としては
>ゲームプログラムでは、複数の構造体変数を管理することにより、複数のキャラクタを
>管理できます。複数の構造体変数を管理するための方法は、構造体をリスト構造で管理
>する方法と構造体を配列で管理する方法の 2 種類あります。
ttp://msdn.microsoft.com/ja-jp/academic/cc998623.aspx の実装方式の一つだろうという前提で、そのメリットデメリットに興味があってここに参加しているのだけども。
ちなみに上記の例でいえば、マイクロソフトは配列厨だなw
>>120 ,122
タスクの話題に限ったことじゃないけど
賛成か反対かの単純な対立に流れることは多いね。
わかりやすいから盛り上がるけど白熱しすぎて喧嘩になったりする。
でもその対立構造が正しいとは限らなくて
良い意見が喧嘩に埋もれてしまったり。
ゲーム製作技術板なのに技術の話じゃなくてすまん。
>>126 確かにそうだ。俺も何が対立軸なのかよくわからなくなってるよw
俺は情報系の人間じゃないんで、ゲームのオブジェクトの相互の振る舞いは
FSMの一形態と見なせるみたいな発言を単純に面白いなと感心するんだけど。
配列で線形リストも組めない雑魚が配列をバカにしてるのを見ると悲しくなるし、 そもそもタスクシステム(特にこのスレで主流の複雑な実装)は速度的に不利なんだから 素直に配列さんごめんなさいって言えばいいと思う
この3連休でタスクシステムの仕様についてまとめるように、以上。
>>128 が、
>>123 だとして、わからん、お前のいうことはわからん!(大滝秀ry
>配列で線形リストも組めない
どこかで queue を配列で組む入門例があったけど、そんなものじゃないだろうし、
だとしてもその線形リストで、まさかタスクシステムをつくるわけじゃなかろうし、わからん。
>雑魚が配列をバカにしてるのを見ると悲しくなるし
どのレスを指しているのか、わからん!
>このスレで主流の複雑な実装
どれだよ!
>>43 なんか、
>誰が書いても同じようなものになるってくらい凡庸な、道端の雑草並みのありふれた仕掛け
とかいってるぞ。凡庸でありふれて複雑て、どっちなんだよ。
>速度的に不利
いや、ロジックの部分は大して食いませんてば。最近のゲームはそうでもないのか?
>素直に配列さんごめんなさい
君が配列ラブなのだけはなんとなくわかったよ。ごめんな。
>>129 いまどきのタスクシステムの仕様
1.クラス名、構造体名に「Task」を含む
2.描画物とそれ以外の処理を同列に扱える(ことがある)
これくらいじゃね
「ゲームプログラマになる前に覚えておきたい技術」 を読んだけどタスクシステムなんて使ってなかった 普通に配列使ってて、配列の上手な使い方がのってた やっぱプロは配列を使うんだね
>>133 2chでしかでかい声は聞かない(マジで)
>>133 はいはい、配列さんごめんなさい。
>>133 は、配列の利便性と構造体を使ったリストの有用性の違いがわかっていないようだ。
もう一度、データ構造を見直すことをお薦めする。
>>133 おま・・・リスト使うか配列使うかの話かよw
セガがリスト使わないなんてありえないから、安心して両方の使い方を覚えような
ついでに二分木やハッシュも覚えておくこと
配列 : 削除、追加時のコストが高い。検索が速い リスト : 削除、追加時のコストが安い。検索が遅い リストは単純に舐めるだけでも遅い ここで比べるべきなのはデータの検索(巡回)・追加・削除がゲーム中にどれだけ発生して それを処理するにはどんなアルゴリズムとデータ構造がベターであるかだ データの検索(巡回)よりも追加と削除のほうが多いゲームなどない だからリストより配列のほうがゲームに適している リストの有意点とはデータサイズの見積りをサボれるという一点に尽きる たしかに配列のリサイズはゲーム中にはとても不可能だからこれは魅力だ しかし、ゲームを製作する上で場面ごとに必要なメモリの見積もりなんてやって当たり前の話で その程度の理由でリストを使うなんておかしい 以上の理由からゲームでリストを使う事はない 弾幕STG等ひたすら衝突判定を繰り返す場合なら 検索アルゴリズムの都合で配列よりツリーがベターな場合もある (STG製作技術スレで話題になってたエリア別ツリー構造等。FPSでよく使われるが) だから配列がベストとは言わないが少なくともリストに劣ることは無い
いつからリスト対配列になったんだ? タスクシステムは固定長データが重要とか言い出した>99あたり? つか>126じゃないけどその対決って どうしても勝ち負けを決めないといけないようなことなの?
>>137 もっともらしくウソついてんじゃねーよ
わざと言ってんだろ。明らかに初学者に対して悪意のあるウソだな
>リストは単純に舐めるだけでも遅い
誤り。「単純に舐める」=シーケンシャルアクセスに有意差はない。
配列が有利なのはランダムアクセスの場合。
>データの検索(巡回)よりも追加と削除のほうが多いゲームなどない
比較方法の誤り。巡回回数と挿入回数を単純に比較しても意味はない。
コストの違いは以下のようにO記法で考えると分かりやすい。
・シーケンシャルアクセス(巡回)のコスト
配列はO(n):要素数が増えると処理時間が増える
リストもO(n):要素数が増えると処理時間が増える
・ランダムアクセス(インデクス値でアクセス)のコスト
配列はO(1):要素数が増えても処理時間は変わらない
リストはO(n):要素数が増えると処理時間が増える
・挿入、削除のコスト
配列はO(n):要素数が増えると処理時間が増える
リストはO(1):要素数が増えても処理時間は変わらない
O(1)はO(n)に対して非常に有利なので、
ランダムアクセスがありそうなら配列を、挿入がありそうならリストを選ぶのが一般的。
どちらもありそうなら実際に処理時間を計測してみるのが良い。
処理時間とは別に、メモリのフラグメントを嫌ってリストを避けたい場合は、
データ本体は配列構造に置き、管理はZソートされたリスト構造に、
というように両方を組み合わせる手法もある(C++オブジェクトをメモリプールするのと同じことだけどね)。
とにかく、初学者は「どっちが勝ち」みたいな議論に振り回されないこと。
ぶっちゃけ実際に動かしてみて問題がないなら、なんであれそのやり方は正しい。
ID:mdtDWXyh、ID:U55fYg17、Xvygn8lQ だが…。どうしたもんかね。とりあえず俺にレスした人から順番にレスするか…
> ID:K7xBu4Cw、ID:gOWsGtVr
>>123 の時点では↑この人の諸元と過去発言を把握できなかったがサンプル数が増えたおかげで大凡のところ見当が付いたわ。
まず俺の一連の書き込み( ID:mdtDWXyh、ID:U55fYg17、Xvygn8lQ )から「タスクシステム=FSM」という解釈に至るのは難しい(※)
@FSMの意味をよく理解していないA人の話をよく聞いてないかB意図的に歪曲して解釈しようと努めている、のどれかだろう。
@ならFSMや有限状態機械でググレとしか言えんしAならちゃんと読んでくださいとしか言えんしBなら正直相手にしたくない
奇遇にも過去にこの人物と同じ解釈「タスクシステム=FSM」を披露したのはルサンチマン君のID:SCRh4oL7ただ一人だ。
ID:K7xBu4Cw 、ID:gOWsGtVrがこれと同一人物なのか知る由も無いが、かなり似通った特徴的な思考・読解の持ち主だなとは思う。
さて、この人は更に
>>130 で「
>>128 が、
>>123 だとして」という謎めいた仮定を持ち出してるのだが、なんでこうなるんだろうね…
俺の過去発言と照らし合わせれば無理があると容易に分かるはずだよな
この人は
>>130 で自らそれを説明してみせているにも関わらず、その仮定が真であるという前提のコメントを書くだけで
その仮定が偽であるという(当然あってしかるべき、より可能性の高い)前提のコメントは結局書くことはなかった。妙だね
・ただ単にコミュニケーション能力の不足、悪意のない、無知、短気、舌足らずゆえにこういう尻切れトンボで終わった
・「
>>128 =
>>123 であってほしい。いやむしろそうあってくれ。頼む。これで終いにしよう」という願望の現われ
まぁ後者ならそのご期待には添えないとしか言えない
俺は配列に「さん」付けしてもらうことも、ましてや便所のラクガキにおいて初心者(?)に謝ってもらうことにも興味がない
(※)素直な思考の持ち主ならば、ゲームプログラムの中で【状態を保持し遷移する】ような要素、つまりFSMモデルを適用しやすいもの
としてまず初めに思い浮かぶものといえばシーン(オブジェクト)やエンティティだろう。そういったもの⊂FSMと解釈するならわかる
#
>>2 そのものをFSMとして説明することはできるが、これを言い出したらプログラムも電子計算機も社会基盤も自然環境も惑星も
#銀河も宇宙もFSMモデルで説明できるという話になる。ぬるま湯に溶かしたハナクソを構成する分子の振る舞いも、乾いて風化した
#ハナクソ粉体の振る舞いもFSMモデルで滔々と説明できるという話になる。こういう話は埒外であり、するつもりはない
話が難しすぎてついていけません><
>>140 が誰と何の話をしてるのか全然わからんけど
>>2 =「ジョブコン」=FSMという話は直感的で分かりやすいと思うぞ
てか名称「タスクシステム」は人によって定義が違うから使うな。議論が混乱する
ああ、
>>140 をフォローしたつもりが逆だったらしい
>>140 はFSMって言い方が抽象的すぎるっつってんのね?
了解。もう言わん
>>137 冗談だろって思って配列にしたら速くなった
たぶんキャッシュ周りも関係してる気もする
146 :
130 :2008/11/26(水) 23:22:37 ID:QqsnFsqJ
>>140 >@FSMの意味をよく理解していないA人の話をよく聞いてないかB意図的に歪曲して解釈しようと努めている、
どれもそれなりにあてはまるとは思うが、あえていうならAかなw
とりあえずBについてはそういう意図も一部あったんでそれは謝っとくよ。
ただ、前提として
>>40 ,
>>41 で繰り返された
>ここでタスクシステムすげぇすげぇ言ってる
というような傾向は無いとはいわんけど(タスクシステムスレだし)、実装で苦労してるみたいな話が中心で、
mdtDWXyhが挑発的な言辞を繰り返さなきゃいかんほどかね?と思うけどな。
147 :
130 :2008/11/26(水) 23:23:39 ID:QqsnFsqJ
>「タスクシステム=FSM」を披露したのはルサンチマン君のID:SCRh4oL7ただ一人だ。
これは順番が違う。同じレスを指してると思うんだけど、
(1)「タスクシステム=FSMだ」という発言があった。
(2) そのあとに
>>41 で「原始的なFSMモデルのジョブ制御」という発言があった
ので、同一人物か同じ立場の人間が批判的な意味で FSMという単語を使ってるのかな?と思ったんだよ。意味合いは違うようだけどFSMという用語を使うレス自体が少なかったからそこは勘弁。
その上で、ゲーム上のオブジェクトの振る舞いをFSMモデルで捉えることはできるだろうけど、それは配列で構成されたゲームについても言えることで、タスクシステム(実装)批判につなげるのはおかしいんじゃないの?と皮肉ったつもりだったのよ。
148 :
130 :2008/11/26(水) 23:28:25 ID:QqsnFsqJ
ただまあ、タスクシステム(ジョブコンでもいいや)の適用範囲とか実装上の問題点と か、そういう流れになってくれると嬉しいんで、「これで終わりにしてほしい」という のも正直なところ。だからピンダッシュに反応しすぎた俺も悪い。もうだまっとく。
>>139 と
>>137 のお話について横から首突っ込んで初学者向けにポエムを書いてみるか
実際の処理速度を語るとき、ランダムアクセスといったら、メモリアドレスを基準にしたランダムアクセスという話も当然絡んでくる
データ構造上の順番(連結リストなら繋がれた順番)を基準にしたらリニアアクセスだよ、といってもメモリアドレスを基準にしたら
ばっちりランダムアクセスになっていました、という状況も当然あり、この場合は処理する要素数と要素サイズと実装対象によっては
べらぼうなペナルティを受けたりする。ので
>>リストは単純に舐めるだけでも遅い
>誤り。「単純に舐める」=シーケンシャルアクセスに有意差はない。
これは状況ごとにプロファイラなりアナライザにかけて検証してみないと分からないというツマラナイ結論に帰結する
ので
>とにかく、初学者は「どっちが勝ち」みたいな議論に振り回されないこと。
>ぶっちゃけ実際に動かしてみて問題がないなら、なんであれそのやり方は正しい。
だよな
(続く)
(続き)
ただし、連結リストを
>>2 のように使う場合と、ジョブの種類別に配列でデータを固めてる場合(※)を比較すると、前者は不利な状況に追い込まれる
>>2 は何でもかんでもごった煮の連結リストでおまけに各要素は好き勝手にジョブを指定してくる。プライオリティ(?)とかいう変数を何に使うのか
知らないがこれでソートされてようが各要素で毎度毎度サブルーチンのアドレス(関数ポインタ)経由でジョブを実行させている
つまりハードウェアにとっては要素ごとに何のジョブを実行するのか予測が難しい。どのジョブが実行されるにせよ、その内容が大して代わり映え
のない超単純な数値積分であれば、分岐予測で速度を稼ぐハードウェアにとっては嫌がらせに近い仕掛けであり、ブチ切れる可能性が高い
○万のパーティクル(数千の通常弾に数千の煙に数千の閃光に数千のフラグメント)を撒き散らす物量ゲーとかなら、そういう要素には
>>2 ではなくジョブの種類別に配列でデータを固めて一括処理するほうが速度が出やすくなる。
趣味プログラマであれば、今様のゲーマー仕様PCで実験してみればすぐに確認できる
(※)この手の配列厨コードは、Zソートを回避するあるいはCPUによるZソートを回避する色んな工夫とセットになる。
単純な加算合成だけでなく、アルファブレンドなしアルファテストのみテクスチャに描いてグレア処理して合成とか色々
>要素ごとに何のジョブを実行するのか予測が難しい その辺は面白い、つか考えてなかったな。 以前、ビデオキャプチャしたYUY2をP4-2.4GHzでソフトRGB変換する、ってのをやってて、 30万ピクセルをfloat演算して1フレーム8msec.程度でで処理できてたから、いまさら数万の オーダーでがたがたいうなよって思ってたけど、言われてみれば配列のシーケンシャル 処理に近いんで、キャッシュの効かなそうな処理なら、どのくらいで処理してるのか確 認すべきだな。
>プライオリティ(?)とかいう変数を何に使うのか 知らないが これはメリットというより必要悪に近いんじゃないかな。ゲーム上のオブジェクトを 動的に生成するタイプのタスクシステムだと、処理順が不定になってしまうので、 プライオリティという形で処理順を明示できるようにしてある、みたいな。 そこまでして処理順を確定しないといけないような場面があるのかどうかは ちょっとわからん。初心者なもんで。
処理順は固定じゃないと駄目なんだよ 壁当たりの判定を保持するような物体の当たりチェックは 普通の物体のチェックより後にやらないと 簡単にすり抜けが発生してしまう 俺、当たりのチェックだけはタスクシステム使ってようが 直書きしたほうが安全な気がする
プライオリティについては
>>2 のWhite PaperとLogician Lordでは
リストに連結されたタスクの中身が何なのかを示すために使われてる。
例えばここだな。
http://web.archive.org/web/20041012012504/www.hh.iij4u.or.jp/~peto/Games/task_03.html >あらかじめ、優先度とタスクワークの構成を決めておきます。優先度は、例えば次のようになります。
> * 0x1000: ジョイスティックの入力解析
> * 0x2000: 自機の制御
> * 0x3000〜0x3fff: 敵の制御
> * 0x4000〜0x4fff: 背景の制御
> * 0x5000: キャラクタ表示
一つのリストに纏めようとするからプライオリティなんてものが必要になる。
必要悪どころかはっきり悪だと言ってあげるよ。
この仕様だとタスクを増やすたびに追加すべき位置をサーチしなければならない。
またタスクの中身を知るために優先度を確認していかなければならない。
enemyはenemyリストに、backgroundはbackgroundリストに入れりゃいいんだよ。
別に配列でもいいが。
ピンキーネット所属の藤松みこを最初の辞職に追い込んだは フリーで湯沢と言うビデオカメラマン(元アートハウスゴン社員)から陰部に指を挿入されたことが原因だ!。 当時現役だった彼女にはショックな出来事で事務所とメーカー巻き込んで大騒ぎ。 カメラマンは土下座しただけで金銭は請求されなかったのは何故か疑問だったが…。 (意外と優しい事務所だったりして…。) 普通は事務所から脅され賠償金を請求され業界追放に追いこまれるだろう! ちなみにセクハラ事件でカメラマンの追放まで追い込んだ領家ゆあの前事務所とは雲泥の差だ。 また普段から公私混同するカメラマンとして有名だし次回彼の標的になる10代のアイドルが気になるところだ。
156 :
名前は開発中のものです。 :2008/12/01(月) 13:32:33 ID:zCQmgzIM
ttp://www.page.sannet.ne.jp/hirasho/diary/diary0811.html#30 >タスクシステムについて触れられてない、とか書かれているのを見つけた。
>何それ?おいしいの?直感的でない、変に抽象化されてデバグしにくい、実行順がコードの形で書かれておらずメンテしにくい、
>等々、どう考えてもあれが有効な場面があるとは思えない。使っている人を問いつめたことがあるが、結局利点は出てこなかった。
>一つ考えられるとすれば、独立性をきちんと保って各タスクを書いていればマルチスレッド対応がしやすそう、ということくらいか。
>しかし、どうせ複数タスクから同一のクラスインスタンスを参照してたり、妙なシングルトンやらグローバル変数を見てたり、
>依存関係が不適切なためにスケジューリングが複雑化したりするに違いなく、本当にマルチスレッド実行していい状態にあることを保障するのは容易ではない。
>よほど訓練されたチームでなければそんなことをする気にはまるでならない。
だからタスクシステムなんて聞くのは2chだけだって ここの信者だけだよ威勢がいいのw だって現場で聞いたことないもんw
大手ならどこでも通じる
>>158 そしたら下請けに流れてきてもおかしくないじゃん
俺は自分からは使わんが、他社の2回くらい見たぞ?
もちろん
>>2 そのままじゃなかったが、ネットでよく聞くから増えてんじゃね
つーかさー、NDSのサンプルよく読んでみろよ・・・
現場で見たことないって騒いでるやつはDS開発やったことないのか?
サターンしかやったこtない
俺は、据え置き型ばっかり
>>163 いいなこの人
説明に難しい言葉を使わないようにしてるし
ちゃんと人に伝えようという文章に好感が持てる
たしかに タスクシステムとは可搬性と再利用性に優れた素晴らしいシステムなんです とか繰り返してた人たちの話よりよっぽど分かりやすい
ひらしょ氏の日記見て来ますたw つか、ヒープのフラグメント避けるためにサイズの違うデータでも固定長メモリ確保するとか 俺が学生時代にごくナチュラルに作ったものだが・・・。メモリプールという言葉の存在すら知らないまま。 まずさ、ゲームで使われている技術なんて、3Dやら除けば全然大したことがなくて 独自性などどこにもなということを認識するべきじゃなかろうか。とりわけ今となっては。 > だからタスクシステムなんて聞くのは2chだけだって 昔のアマゲ周辺でそれなりに聞いたかな。某よっしん氏等も使ってた記憶が。 ただ、言葉は聞くけど実体は人それぞれという類のものだよね。 オブジェクトをリストで繋げて更新ルーチンへのポインタ保持してるだけで 俺がガンダムだって言っても、言葉の定義なんかないんだから自由なわけだしさ。 実際、昔言ってたタスクシステムもその程度の代物でしかなかったと思うんだよ。 そうだな、それでも、C++がまだ使われていなかった頃はそれなりに画期的、というのもちげーな 「ああこうすればいいのか」と人を感心させられる程度のものではあったかもしれない。 ひとつのテクニックとして名前をつけて呼ぶ価値があったと思うよ。10年以上前の話。 でも、今となってはこんな普通にC++で書けば自然にできるようなことをシステムなんてとても呼べないし、 それでもタスクシステムという名前にこだわってる人は、もっと高度な何かを語ってると思うんだが 何それ?っていうか、要らんよねぶっちゃけというか、コード見せれ、というか 俺としては、C・アセンブラ時代に言ってたタスクシステムが、ものすごいタイムラグを経て、 一部のアマチュアに、おかしな形で伝わってしまっただけじゃね?と思っているのだが。 もしそうだとすれば、素人を混乱させる有害情報でしかないので火消しが必要なレベルだと思う。 そうでないなら、とにかくコード見せて。
そのスレ読んだ LGPLを含むEXEがLGPLに感染してるなんてライセンス文読めば一目瞭然のことを 何とか超解釈で否定しようとしてる子が定期的に出没していて その理屈は違くね?という人達が理詰めで外堀から確実に徐々に埋め立ててる そんな感じ? 物事をひん曲げて解釈したがる人を諭すには 駄目押し気味でもああいうのも有効かなとはおもた
>>167 あのスレのレスは三行でまとめて欲しい
>>168 あのスレごちゃごちゃしすぎてて、自分で何書いたかさえ忘れる
ところで、感染しないライセンスなんて無いよ。例えパブリックドメインであっても。
結合したら二次著作物なんだから。
>>169 二次利用に縛りをかけないライセンスは存在する。
ていうか、パブリックドメインとは、だれのものでもない存在だから、
二次著作物とかそういう縛りもない、はず。
>>170 うーん、有名どころで二次利用に縛りをかけないライセンスを見たことないけどな。
少なくとも「本ライセンス文書を同封しろ」と書いてある。
パブリックドメインに関しては著作権者が権利放棄してるから、利用に縛りはないだろうけど。
>>169-170 おまえらあっちのスレでやれ。
>>168 むしろ逆効果にしか見えないのだが、
前スレで釣り宣言してたからそれで狙い通りなのだろう。
三次利用以降に縛りをかけない事、という縛りをかけてるものはあるな
数年前のとある同人STGのメイン関数。趣味だから何も考えてないね。仕方ないね int _tmain(int argc, _TCHAR* argv[]){ boost::shared_ptr<GAMEENV> gameenv(new GAMEENV); //D3D,SOUND,INPUT,USERDATA,etc boost::scoped_ptr<SCENE> logo(new LOGO(gameenv)); //ロゴ画面 boost::scoped_ptr<SCENE> demo(new DEMO(gameenv)); //デモ画面 boost::scoped_ptr<SCENE> title(new TITLE(gameenv)); //タイトル画面 boost::scoped_ptr<SCENE> config(new CONFIG(gameenv)); //コンフィグ画面 boost::scoped_ptr<SCENE> stage1(new STAGE1(gameenv)); //ステージ1 (…中略…) boost::scoped_ptr<SCENE> stage8(new STAGE8(gameenv)); //ステージ8 boost::scoped_ptr<SCENE> ending(new ENDING(gameenv)); //エンディング logo->Run(); //ロゴ画面再生 try{ while(1){ demo->Run(); //デモ画面再生 switch(title->Run()){ //タイトル画面再生 case TITLEOPTIONTYPE_GAMESTART: //ゲームスタート try{ //STAGEEXCEPTIONTYPE_GAMEOVERという例外を投げるまでゲーム続行 stage1->Run();stage2->Run();stage3->Run();stage4->Run(); stage5->Run();stage6->Run();stage7->Run();stage8->Run(); ending->Run(); //エンディング画面再生 }catch(STAGEEXCEPTIONTYPE){;}break; //GAMEOVER例外投げてきた case TITLEOPTIONTYPE_CONFIG: //オプション画面再生 config->Run();break; } } } catch(GAMEEXCEPTIONTYPE){;}catch(...){return EXIT_FAILURE;}//糞ゲーだからやめるらしい return EXIT_SUCCESS; }
_tmainじゃなくて_tWinMainだったかな。よくおぼえてないや 各シーンはいわゆるベタベタの配列厨コード。元HSパーだから仕方ないね でもメモリもGPUリソースもジャブジャブ使いまくったおかげで 見た目はバリバリのイケイケになったよ。動作も軽快だったよ。自惚れだね
>>174 たのむ
なにが言いたいのか最後に書いてくれ
俺が気になるのは、メインループが本当に必要なのかどうかだな
タスクシステムも、それ以外のC++コードでも、なんでメインループ作るん?いらなくね?
普通に書けばいいじゃん(普通ってなによ)
stage1->Run()はstage1が終わるまで返ってこないんだろ。 いずれにせよゲームなんて毎フレームの同じ処理の繰り替えしなんだから どこぞかにループは存在するのが当たり前だと思うが。
あーすまん メインループはどんなプログラムにもあんね なんかさ、1フレームごとに回るループを作るやり方と 作らないやり方(あちこちでupdateする)について 急に気になって言ってみたんだが やっぱどっちでもいい気がしてきたからいいや
スレッド作るにしろなんにしろ どこかでスケジューラが回ってるがな
>>179 > 作らないやり方(あちこちでupdateする)について
> 急に気になって言ってみたんだが
それは使ってるフレームワークが裏でループ回してupdate()呼んでるんだろ。
あるいは割り込み駆動の可能性もあるが。
182 :
名前は開発中のものです。 :2008/12/04(木) 22:22:51 ID:wPvA+LuT
>>175 >見た目はバリバリのイケイケ
気になるな。
>>176 >たのむ
>なにが言いたいのか最後に書いてくれ
地域担当の教団勧誘員に
>>174 を見せると彼の顔はみるみる青ざめ、ついには目を背けてしまいました。
ただごとでない様子を感じ取った私は恐る恐るその訳を尋ねました。すると彼はおずおずと耳元で囁くのです。
「それはいけない。凶兆が見えます。そのようなものを作っていては遠からず仏罰が下るでしょう。南無妙法蓮華」
>>174 は彼らの"先生"の教義に反する、知性体として恥ずべきお猿さんコードなのだそうです。私は狼狽してみました。
幼少の砌よりツクラーにしてHSPerである私の深層に眠る劣等感の残滓の存在をESPで見抜いたのか、彼は目を細め
「安心なさい。今からでも間に合う。私共のように三宝( * )に帰依なさい。そうすれば必ず道は開けますよ」
と仏様のような微笑みを湛えながらビール券とこの案内状をくれたのです
そろそろタスクシステム総合スレじゃなくて
ゲームシステム総合スレに名前変えね?
>>2 を使ってる人は皆無なわけだし
いや、ここ隔離スレだから…
やね本はプレミア付く程のレア物
>>166 何がいいたいかわからん。動的インスタンスリスト巡回アップデートwの具体的なメリットデメリットを指摘すればいいんじゃないか?
ttp://www.issei.org/ そのひらしょ氏の本を手伝ったらしいPGさんのブログ。タスクシステムらしきソースがある。
問い詰めた知人てこのひとかな?
例えば
>>174 をタスクシステムで書いたとして、単純に比較すればそりゃ
>直感的でない、変に抽象化されてデバグしにくい、実行順がコードの形で書かれておらずメンテしにくい
コードだと思うんだよ。んで、それでも使いたいメリットあるのか?て話だよな。
俺は本職のゲーム屋さんじゃないんで失礼かもしれないが、わかりにくいところもあるけど、
結構融通が利いて便利かもと思ったよ。
ためしにプロトタイプを作ってて、「ここで一発エフェクトが欲しいな」と思ったところで、new してリストにつなぐだけで動くってのはちょっと感心した。
あと、メインループ周りを作ってしまえば、そこをいじらなくても別のゲームが作れるのは
なれれば安心感があるな。
ただ、万人にお勧めできるかつと、それはちょっと難しいかもとは思う。
>>189 >ためしにプロトタイプを作ってて、「ここで一発エフェクトが欲しいな」と思ったところで、new してリストにつなぐだけで動くってのはちょっと感心した。
これホントは動かないのが普通なんだよ
裏でグローバル変数でつながってるからnewするだけで動くように見えるだけ
可能でしょ?そういうの?
本来あるべき手続きを見た目見えなくするもんだから
後で「え?そんなところと関係あるの?」っていう部分がボロボロ出てくる
結果これ以上ないデスマになる
>>190 レス早すぎるだろw
>後で「え?そんなところと関係あるの?」っていう部分がボロボロ出てくる
そういう不安は、まあ、あるな。自分が把握していられる範囲ならともかく、
「3日前のコードは他人のコード」な人(俺だ)とか。
>裏でグローバル変数でつながってるから
これ、このスレでよく批判の対象になってるけど、俺が見た範囲では
それぞれ listはprivateにしたり一応保護する工夫をしているように見えるけど
「オブジェクト同士が相互参照できるならグローバルと同じで無意味」ってこと?
>>191 タスクシステム云々ってよりグローバル変数の駄目な理由そのものじゃん
193 :
issei :2008/12/06(土) 07:28:54 ID:wah4ZAkA
>>193 名前欄入れてらっしゃるけど、ご本人様で?
そのエントリによると、新人研修でタスクシステムのようなものを教えてる
ところは実在するわけですかね。
散々タスクシステムを崇拝してきた人間も ひらしょーさんの「なにそれ?」で完全に散ったなw
入門を脱したばかりの奴が入門記事を書く悪循環に、 ちょうどタスクシステムがはまっていた感はあったな。 CodeZineとか。
197 :
issei :2008/12/06(土) 19:18:28 ID:wah4ZAkA
>>193 私は新人研修に関わってないので、どういう文脈で紹介されたのかは不明です。
研修中の息抜きで、単なる昔話してたのかも。
198 :
189 :2008/12/06(土) 22:51:20 ID:AlgIGpgY
>>193 ありゃ?そのページをみて書いたんだけどw
釈迦に説法だと思うけど、一応、
・狭義のタスクシステム
>>193 のリンクで(ここにあるようなモノ)としているような古典的なもの
・広義のタスクシステム
古典システムをクラスとstd::listなどで実装しなおしたもの
というような定義がこのスレでは何度か上がってて、オブジェクトの種類ごとに
リストを分けるべき、てな議論もあるんで、
>>193 のサンプルや、ほかに公開している
ものはその範疇かな、と思った。
定義自体あいまいなところがあるので、タスクシステムと呼ばれたくない、
ということであれば申し訳ない。
毎フレームstd::listに繋がったメンバ関数を呼ぶだけのものに システムとか名前つけること自体が厨臭くてダメだろ。
GUIアプリのデザインパターンとしてなんらかの名前があると思うんだけどなぁ
>>199 命名自体は思考の道具として必須だよ。
りんごを「りんご」と呼べないならそれをどう頭の中で扱うのか?
ただ、付ける名前の好き嫌いと妥当性はあるだろう。
自分の子供に「悪魔」と名づけたら批判される。
まあその程度なんだが。
大袈裟過ぎるのは確かなんだが いまさらどうにもなんないよなぁ
>>202 タスクもシステムもOSを意識してしまう用語だからな。
言葉の意味的には
>>92 のいう ジョブコン(トローラ)の方がより厳密かなあ。
名前なんかどうでもいいじゃん、あほらしい
しかし、タスクシステムを崇拝してる奴等は 自分が学ぶ技術に名前や名称がほしかったんだろうな 理由はきっとそっちのほうがたしからしく見えるからかな? でもそれもひらしょーさんの「なにそれ?」で タスクシステムは世に通じない名称ということを実証するのに十分だったな な〜む〜w ひらしょーさんと同じことを説明してくれてる人はたくさんいたけど 名称の魔力があったから信者はまったく聞き入れなかったよね
内なる敵と戦っているんだよ。
>>208 まぁその記事の「タスク」は、MTフレームワークの用語としての「タスク」だと
思うが。
>>209 このスレで言ってるタスクシステムとなにが違うの?
「タスク」はプレーヤー、敵、カメラ(視点)、ライティングなどの同時多発的に発生する
ゲームを進行させる処理そのもののことを指す。
各タスクには、プレーヤータスクの更新処理、描画処理。
敵タスクの更新処理、描画処理といった形で「更新処理」、「描画処理」が存在する。
ただ、あんまりうまくいってねぇ気がするね だってそんなもん作ったわりにそれほど見応えのあるソフト連投してねぇし
ジョブコンがアンチパターンである理由 1.グローバル変数(または静的クラス変数)を多用しがち 2.抽象的すぎる(シーン、入力処理、衝突判定、描画物などを同じ抽象レベルでリスト化できてしまう) 3.2のためにプライオリティ変数のような順序制御機構が別途必要になる 4.3のために処理の流れがコードから読み取りずらくなる(このスレの「FSMが云々」のくだりはこれを指摘している?) 5.配列の方が速い(CPU最適化厨乙wいやマジでがんばれw) 6.ひらしょー先生が批判している(よく知らんけど・・・) 最近の流れだとこんな感じか? 個人的には4が致命的だと思うな ※2は、言い換えると「様々なコードの断片や描画物を、必要に応じて追加・削除できるオブジェクトとして 同じ抽象レベルで扱える」というメリット的な言い方も出来るかも知れん
214 :
名前は開発中のものです。 :2008/12/07(日) 20:56:55 ID:hSkKXTzZ
タスクシステム否定派 = 人の意見に盲従するヘタレ ということはわかった。
>1.グローバル変数(または静的クラス変数)を多用しがち 変数の参照範囲は必要なだけ広く、そして最小範囲 タスクシステムだからこれが出来ないという理由はない 少なくともリストや配列を使った非タスクシステム比べて 変数の参照範囲を広くとる必要などない >2.抽象的すぎる(シーン、入力処理、衝突判定、 >描画物などを同じ抽象レベルでリスト化できてしまう) 多態を使ったリスト巡回だと抽象レベルが一つ下がるけど その為に、例えば後から「エフェクトクラスを追加しよう!」と 思ったときにクラスをさかのぼって親クラスを修正しなければならず また、その親クラスから分岐した子クラスを編集する必要もある タスクシステムはクラスでいう型を撤廃して、それをデータに 落とし込んでいるがそのおかげでコード修正の影響範囲を 局所化することに成功している >3.2のためにプライオリティ変数のような順序制御機構が別途必要になる ZソートするのだってZ値必要じゃん 順番が必要ならH・・・じゃなかった、値が必要なのは当然 どうしてもプライオリティ変数が嫌ならタスク追加時にソートしとけ (プライオリティ変数使ってる人って毎フレームソートしてるの?バカなの?) >4.3のために処理の流れがコードから読み取りずらくなる >(このスレの「FSMが云々」のくだりはこれを指摘している?) 順序制御機構があるならコードは見やすいだろう 関数ポインタのせいで直感的ではないという指摘ならともかく
>5.配列の方が速い(CPU最適化厨乙wいやマジでがんばれw) 確かにタスク巡回(多目に見積もってもせいぜい数十万タスクだろう)を舐める速度が 数倍余計にかかっても今のCPUなら有意な差ではない 当たり判定やグラフィック描画との処理時間の割合が違いすぎる 確かにその通りだ ただ、実際にどういった処理が行われるのか想像して欲しい 1. 現在のタスクから次のタスクが存在するポインタを参照する 2. 次のタスクをメモリに読み込む 3. 読み込んだタスクからデータを参照する さて、データを参照したのは何回だろうか しかも「次のアドレス」ではなく「指定したアドレス」から読み込むことがどれだけ不利なことか・・・・ リストと配列の速度差に関しては、実際にベンチを取った人には説明するまでもないと思う たしかに実用上は大した差ではない しかし、CPU時間は余り気味の現代社会においてもメモリ帯域はPS3ですら不足している昨今 リストを使ったプログラミングは複雑さが増しているばかりではなくソースも見づらくなり その上速度まで低下していてはどうやって弁解する事ができるのか不可解である >6.ひらしょー先生が批判している(よく知らんけど・・・) おまえら本買ってないだろ? どうみてもタスクシステムです 本当にありがとうございました 最初は状態変数で分岐させてるけど、後半はタスクシステムじゃねーか
>順序制御機構があるならコードは見やすいだろう ソースコードの流れる順番に処理が行われていないから読みずらいっつってんの なんで見やすいって話になるんだよ あと関数ポインタ/仮想関数/無名関数をアンチパターンとするのには同意しかねる >おまえら本買ってないだろ? >どうみてもタスクシステムです ひらしょーは正直どうでもいいw
>>215 >変数の参照範囲は必要なだけ広く、そして最小範囲
>タスクシステムだからこれが出来ないという理由はない
>少なくともリストや配列を使った非タスクシステム比べて
>変数の参照範囲を広くとる必要などない
それってソースコード読む人にどうやって伝えるの?
>>215 > 少なくともリストや配列を使った非タスクシステム比べて
> 変数の参照範囲を広くとる必要などない
単一の型・固定長ブロックを使ったタスクシステムだと、依存関係を明示する
ために引数を使えないのが痛い。
Scene -> Map -> Character, Hit
たとえばクラス構造として Scene クラスが Map を包含し (メンバ変数名 Scene::map_)、
Map が Character (Map::character_) と Hit 判定処理 (Map::hit_) を包含してるとする。
これだと
Scene::exec() { map_.exec(*this); }
Map::exec(Scene& scene) {
for (int i = 0; i < character_.size(); ++i) { character_.exec(*this); }
hit_.hitCheck(*this);
}
こんな感じで、Scene <-> Map <-> Character, Hit の相互依存関係を明示できる。
Character から Hit にアクセスする場合は、いちど Hit::exec() から引数経由で
Map を呼び出して、それが Hit を呼び出す。
また、Scene から Map に公開するメンバ関数を制限したい場合には、Scene の
既定クラスとして純粋仮想関数だけ定義したクラスを用意し、それを Map::exec の
引数に渡せば OK。多少回りくどいが、メッセージのパスがシンプルになってコード
見れば一目瞭然になるので、バグは減るし追加処理を入れやすい。
単一型リストにしちゃうと引数型も当然単一になるから、引数で情報を渡すのが
不可能になって、結局グローバルな領域に情報を記録することになる。そうなると
いつ誰が読み書きするかわからないので、予期しないタイミングで予期しない処理を
されて泣くわけだ。
ゲームの場合は、プログラムの基本構造が「一定時間ごとに外から関数を呼ばれる 小さなオブジェクトの塊」になる。 このオブジェクトを単一リストに入れることで型システムや変数スコープの利点を捨るか、 あるいは複数のリストに入れることで仕様変更時のソースコードの変更範囲が大きくなる のを諦めるかというのがトレードオフなんだろうね。
なんかいきなりジョブコン叩きをはじめた奴がいるが。 ジョブコンの利点は、コルーチンが実現できることだ、ってのは把握してる?
叩いているようには見えないし そもそもコルーチンじゃないし 信者を装うにも無理がある
>>220 仕様変更が起こってもソースの変更範囲を小さくできるなんてメリットだとは思わないな。
それができるということは仕様とソースが乖離していること、乖離していくことを示している。
>>223 確かに仕様変更の中身に強く依存することなので
一般論としてしまうには無理があるな。
設計によって対応しやすい変更としにくい変更があるだろうから
それらを具体的に考えてみるのもいい。
>>223 > 仕様変更が起こってもソースの変更範囲を小さくできるなんてメリットだとは思わないな。
> それができるということは仕様とソースが乖離していること、乖離していくことを示している。
は?
仕様変更が起きた時に、ソースの変更範囲ができる限り小さくて済むように
(1つの仕様変更で変更すべき箇所が1箇所で済むように)実装するのは、
基本中の基本だぞ?
小さな仕様変更でソースのあちこちを変更しなければならないという状態のほうが、
仕様と乖離したソースだということになるはずだが?
226 :
223 :2008/12/08(月) 14:05:31 ID:+P2RkRte
>>225 ごめんよ。もちろん1つの仕様変更であちこち変更するのを基準に「小さく」って話を
してるわけじゃないんだ。
ある処理が依存する情報について変更があっても、グローバル変数を使っていれば
関数の引数には変更が現れなかったりする、そういう変更の小ささがメリットだとは思わない
って話。
>>226 同意
特にグローバル変数まで使って変更を強引に縮小することにメリットは全く無い
グローバル変数を使っていれば、明示的に引数などで渡す必要がない struct 使っていれば、わざわざ setter, getter を使う必要がない ……それが通じるのは、アドレス空間 64KB の世界までだよな。
タスクシステム ストラテジーパターン FSM 違いがわかりません
タスクシステムはC言語より前に生まれたのでは
>>230 キミはC言語の誕生をいつと思ってるのカネ?
230を好意的に解釈すると タスクシステムは(ゲーム開発に)C言語(が採用される)より前に生まれたのでは C言語使うようになったのなんて90年代になってからだね。
>>208 汎用。これはとても便利な言葉だ
これは何にでも使えるね、というポジティブな意味に使えるし
これは何にもできないね、というネガティブな意味にも使える
どちらに重みが置かれるかはケースバイケースだが
仮に後者の重み係数が大きくても角が立たないという魅力的な言葉だ
面接に来てくれた若者のソースコードを眺めて
「これは何にもできない処理単位だね」とぶっきらぼうに言い放つ人間もいれば
「これは汎用的なタスクだね」とやんわりと当たり障りの無い表現で煙に巻く人間もいる
前者はある意味で分かりやすい圧迫釜賭けだが、後者には注意を払う必要がある
コミュニケーション能力の一端を見るためにわざと当たり障りの無い意味不明瞭な表現を使い
その背後に隠された意図を相手がどう読み取ってくるのかをじっと観察する人間もいるからだ
いちいち駆け引きしなきゃ話もできんようなやつとは 仕事したくないなあ
90年代?自分の記憶がソースかよ
>システムはどうかしらないけど、ゲーム業界でタスクは一般的になってると思うよ。
ジョブとタスクを明確に使い分けてた職場とジョブとタスクを混同してた職場があったようだけどねー
ソースだけ(部分的に)パクれても設計のノウハウ(なぜこれはこういう設計になってるのか等)まで
パクれなかった下っ端が中堅・下請けに再就職しても断片的で不完全な情報しか伝達されない
情報は確実に劣化する
長期大規模開発用に構築されたフレームワークは巨大だからリードプログラマをつかまえてこないと
その全容を正しく理解するのは難しいね
たとえタスク制御とジョブ制御が分離されてるコードを見たとしても、それがどうして分離されてたのか
分からなかったかもしれない。だからコンテキストスイッチ不要とかという話になり、ユーザーに直接タスクを
記述させて泥沼に陥ったりする。
>>2 はその典型じゃね?
という談話を聞いてきたHSPerでした
>>237 訂正
>ユーザーに直接タスクを記述させて
ユーザーに直接、タスク(システム内部の処理単位)として振舞うようなジョブを記述させてる、だったかな
ジョブエントリの連結リストを走査して順次処理するだけの単純な仕掛けだから
スケジューリングがなってないしデッドラインに処理が完了するようマネージメントすることもできない
全てマニュアル操作。ユーザーに責任を押し付けてる。劣化ジョブコンとも
半年程うだうだやってようやくタスクシステム卒業できた気がする俺からのヒント。 これでこのスレからも卒業だ! 1. ハードに近い下のレイヤはイベントハンドラ使うけど、 上のレイヤではイベントハンドラは(自分からは)使わない。 上のレイヤではvoid enter_frame(void)、void display(void)のようなタイミング通知の意味しかない関数 (C++ならメソッド)を用意しておいて、イベントハンドラからはそれを呼ぶだけに留める。 データの受け渡しはあくまでも上主導で。 下主導で上へとアクションかけるのは処理実行タイミング通知(関数呼び出し)だけ。 入力データは下のレイヤでバッファリングしておいて上のレイヤが下に参照しに行く。相互参照を避けるため。 タイミング通知の関数のタスクシステムとの違いは、それらの関数がプログラム中にただ一つずつしか存在しないこと。 関数呼び出しされた側では、その関数内で1フレーム分の処理を手続き型言語丸出しで書いてOK。 例えばif文、switch文も関数呼び出しも他のインスタンスのメソッド呼び出しも自由自在だし、がんがん引数渡し可能。 ゲームオブジェクト種別ごとに別の配列用意したりとかも普通にできるようになる。 ウィンドウプログラムに入る前のC入門書のノリで普通にプログラム書ける。 (続く)
(続き) 2.ゲームプロジェクトとは別にライブラリプロジェクト作る。Visual C++ 2008 Express Editionでもライブラリ用のプロジェクト簡単に作れる。 1つのプロジェクトで既にきれいに分けれていると思っててもプロジェクト分けると切れてなかったことに気づく。結構重要。 ライブラリ化はよくある普通の部品化レベルでよい。 フレームワーク作りはまだ止めとけ。部品化だけで十分役立つ。というかタスクシステム卒業したら部品化できる範囲が急激に広がるのでそれだけで十分手一杯になれる。 ハード触る処理とゲーム処理をごちゃまぜに一つの方式で扱おうとしてるといつまでもタスクシステムから逃れられないと思う。 ハードは割り込みあるから本質的にイベント駆動だけど、 ゲーム処理までそれに合わせる必要はない。手続き型言語丸出しでバッチ処理的にべた書き(1フレーム刻みだけど)できるし、そうすべき。 楽。チョー楽。 プログラム入門したての頃の楽しい感覚が蘇ってくるよ、べた書き。すいすい進むし、出来ることの幅がすごく広がる。 #プログラム構造の文献はCで完結するような原始的な領域の本が分かりやすくていいよ。組み込みとかの。SESSAME WGのとか。
おまえらやっぱり1度Java経験しといたほうがいいと思った
>>239-240 タスクシステム大好きっ子を締め上げたりしてる俺だが流石にお前は可哀相に思う
>>2 なんざポーリング処理(全オブジェクトのちゃんこ鍋連結リストを巡回してディスパッチ)
するだけのヘッポコプログラムだから。イベント駆動云々なんてVSYNCトリガーにしてる以外は
関係ないから関係ないから。お前が言ってる事は
main(){
//ここで準備してね
while(1){
enter_frame();
display();
d3ddev->Present(VSYNC待ってから処理返してね);
}
//ここで後片付けしてね
}
enter_frame(){
//1フレーム分の処理を手続き型言語丸出しで書いてOK。
//例えばif文、switch文も関数呼び出しも他のインスタンスのメソッド呼び出しも自由自在だし、がんがん引数渡し可能。
//ゲームオブジェクト種別ごとに別の配列用意したりとかも普通にできるようになる。
//ウィンドウプログラムに入る前のC入門書のノリで普通にプログラム書ける。
//ゲーム処理までそれに合わせる必要はない。手続き型言語丸出しでバッチ処理的にべた書き(1フレーム刻みだけど)できるし、そうすべき。
//楽。チョー楽。
//プログラム入門したての頃の楽しい感覚が蘇ってくるよ、べた書き。すいすい進むし、出来ることの幅がすごく広がる。
}
display(){
//上に同じ
}
これこそサイコー!って言ってるだけ。
>>2 のmain関数だって同じように書けるし。アホかお前。氏ね
抑制したつもりだったけどやっぱり無理でした
タスクシステムって単なるオブジェクト指向プログラミングなんじゃねーの? 時代に乗り遅れた奴らが悶絶してるスレにしか見えないw
>>243 オブジェクト指向のキモは、クラスの洗い出しと、クラス間の関連を見極めること。
何でもかんでもグローバル変数に書いて共有するのはダメだろ。
タスクシステムとグローバル変数には何の関連性もないし タスクシステムがオブジェクト指向であるというのもそのとおり。 たんなる技術手法の1つでこれといった決まったルールが決まってない名称であるから 揚げ足取りがしやすいだけ。 デザパタより昔からあった手法だし、C++よりは古い。
クラスもなければプロトタイプでもない、CLOS のような多態のメカニズムもない。 どこがどうオブジェクト指向なんですかね。
248 :
名前は開発中のものです。 :2008/12/13(土) 00:25:41 ID:m0qW0f8x
このスレの異常に不憫な嫌タスク厨を見てて いつも思うことがあるんだが・・・ 「神は自らタスクるものをタスク」
>>242 WM_LBUTTONDOWNとかWM_MOVINGとかWM_DESTROYみたいなイベントも扱う。
それら入出力関係・アプリ生存期間の制御関係のものと、ゲーム処理をいっしょくたに
扱える標準的インタフェースなんて作るなというのが主旨。
もし作ろうとすると
1.イベントハンドラで統一
2.やっぱ使い勝手悪いのでゲーム処理はenter_frame(), display(), move()の3つだけに集約
→タスクシステムいっちょあがり
となる。
あとenterframe()とdisplay()で分けたけど、よく考えたらenterframe()1個で足りるかも。
ゲーム処理は1フレームに1回、1つの関数呼ぶだけで足りるし。
というかenter_frame()さえもいらないかも。
どこかで誰かが全入出力デバイスの面倒見る必要は結局あるもんね。
俺はなんか分けてたからああ書いたけど。その辺はごめん。
重要なのは「入出力デバイス処理とゲーム処理は別物」ということ。
そして別物なので、「ゲーム処理にまでイベントハンドラ適用しようとすんな」ということ。
タスクシステム=イベントハンドラ崩れorイベントハンドラの俺ゲーム最適化後というイメージを持ってる。
OSも昔とか組み込み系の貧弱な環境とかではユーザランドとOSの切り分け曖昧だったりOS無しで自前管理だったりするけど、
規模大きくなるとそれじゃ成立しなくなるのに似てるかも。
メインループとかの構造はそう、大体そんな感じでOKじゃね? あんまそこは興味ない。
main関数からじゃなくいきなりイベントハンドラから始まる環境とかあるし、正直動けばそれでいい。
一応俺はそのd3ddev->Present()をdevice.wait_frame()に置き換えてその中でDispatchMessage()ぐるぐる回しつつ1フレーム待ってるやり方。
>>249 それってホーミングミサイルがターゲッティングした相手とか
キャラと移動床、移動床と固定壁の相互判定の処理とかって
どこ飛んでいっちゃってんの?
なんかワンフレのオブジェクトの独立した動作しか見えてなくね?
上記のことをそのシステム使って解決しようとすると
もう関数の引数でやりとりできないからグローバル変数使って回避するしかないっしょ?
>WM_LBUTTONDOWNとかWM_MOVINGとかWM_DESTROYみたいなイベントも扱う。
>それら入出力関係・アプリ生存期間の制御関係のものと、ゲーム処理をいっしょくたに
>扱える標準的インタフェースなんて作るなというのが主旨
HSPerも基本的にそう思うよー
http://pc11.2ch.net/test/read.cgi/gamedev/1227748699/181n でも、これって
>>2 >>2 卒業とは関係無い話だと思うよ
GUIに特化したOSのイベントシステムというものは
OS提供のGUI関連機能を積極的に使わない限りは
「どんなアプリにとっても」どうでもいい存在なんだし
そういう場合、どんなアプリでも
最低限のイベントに対応する処理を脇のほうで適当にこなしてるだけ
>タスクシステム=イベントハンドラ崩れorイベントハンドラの俺ゲーム最適化後というイメージを持ってる。
>>2 にはイベントという概念はないしイベントディスパッチャもないよ
イベント駆動システムの体を成してないよ
>>2 はジョブの連結リストを走査して全ての要素(ジョブ)をディスパッチしてる
つまり単純な順次処理しかしてくれないよ
イベントがあるとすれば、それはユーザー自身がジョブの中で記述しなければならないよ
>>2 は何にもしてくれないよ
イベントというかメッセージだったかな HSPerは頭よくないから使い分けがよくわかんないの ケータイだからID違うのはしかたないね
>>242 不憫なやつだな、お前
なんかわかった気になっちゃってんだろうけど
21世紀の高スペックハードが前提ならModernC++Designあたりの設計の方が当然良いっつの
まーおまえは配列が最高だと思ってるかも知れないから、これも分からないかも知れないが・・・w
ジョブコンはハードべったりなコーディングのための実装(設計ではない)であって、
組み込みに近いハードで便利なんだよ
これを組み上げた故・深谷正一氏はナムコで神様って呼ばれてただろ
嫌タスク厨は、世の中に唯一の正しい答えがあるわけじゃないことを学んだ方がいいよ
様々な現場があり、また過去にあったことを理解しろ
多分20年後には、C++自体が百害あって一利なしと言われているだろうが、
その時でも俺はC++を擁護するね
仕事ではC#かECMAScriptあたりを使っていたとしてもね
だから俺は今、タスクを擁護する
かつて世界をリードした日本のゲーム最盛期の技術として、価値あるものだ
あ、でもタスクしか使えない老害はそろそろ消えてくださいw
もうバブルは終わったんだよ。過去にしがみつくなwww
モナドを使ったステートレスなタスクを考えてください
CPSでおk
久しぶりにのぞいたら例の本でふきあがってるのな まだ続いてる? いわゆるタスクシステム的な抽象度の高いオブジェクトがシステム最上層で一本だけのリストに なってる系の設計の問題だと思う点はタスクの描画順序を変えようとしてプライオリティを変えると その抽象度の高いクラスを継承するクラス全部リコンパイルするハメになるとこ そして最近は複数バッファを使う技術を実装する途上で描画順序を変えなくてはならなくなることが多い 同一のリソースに複数回描画を要請することもある
本当のタスクシステムはリストではなくリングバッファ リスト使うやつはまがい物
>>255 で、なんで急に「ジョブコン」の話を始めてるのかな?
俺は
>>2 の話をしたがお前はそれを「ジョブコン」の話だと思ってるのかな?
もしかしてお前、
>>2 =「ジョブコン」だとでもいいたいのかな?まさかね
故人の名を引っ張り出して嘘を吐くなんてバチ当たりなこと、するわけないよね?
人として
723 名前: 遠藤雅伸 ★ 投稿日: 02/01/04 11:43 ID:???
>>720-722 >>712 の言っている「タスク」というのは、80年代初頭に深谷正一
氏が完成させた、通称「ジョブコントローラー」とか「オブジェクトコン
トローラー」とか言われているものだと思います。
CRTのブランキングに同期して行われるインタラプト処理をトリガー
にして、60分の1秒単位で順次処理をマルチに行う構造ですね。
今では誰もが使っているというか、既に時代遅れなのですが、当
時はプログラマに読者層がある雑誌などで、プログラムを解析して
紹介したりしてました。
描画順序を内包するから問題になるのであってそれは外にだせばいいだけだな それでも複雑・特殊化した描画のシーケンスに対する柔軟性のなさは相変わらずだけど
業務用アプリでさえタスクシステムなのにお前らいつまでこんなネタを繰り広げてるんだよ
×タスクシステム ○イベント駆動
265 :
名前は開発中のものです。 :2008/12/14(日) 13:38:40 ID:zax2tb8N
タスクシステム = リアルタイム・ゲームにおける並列動作処理の基本アイデア 基本アイデアを否定するって、初心者掲示板においてどんだけ罰あたりなんだよ。
>>265 ゲームの基本アイデアは、
1. 定期的
2. 外部から駆動される
オブジェクトの集合でシステムを構成すること、だろう。固定長ブロックをポインタで
つないだ所謂タスクシステムは、その(特殊なケースに最適化された)例の一つ。
267 :
名前は開発中のものです。 :2008/12/14(日) 14:13:11 ID:zax2tb8N
「定期的」オブジェクト:
フレームワーク(タスクの生成/消滅/アクティブ化/非アクティブ化)
「外部から駆動される」オブジェクト:
上記のフレームワークに乗っかった個々のタスク
・・・ということ?
結局、
>>266 の実体はタスクシステムなんでは?
デザパタより昔からあった手法だし、C++よりは古い。
イベント駆動とメッセージングOOPの組合せ程度じゃ 単なるよくあるGUIプログラミングの定石じゃない
>>267 for (;;) {
player.exec(*this);
std::for_each(enemies.begin(), enemies.end(), boost::bind(&Enemy::exec, ::_1, boost::ref(*this)));
WaitVSync();
}
これだって VSync ごとに 1 回ずつ、各オブジェクトを呼び出してるわけで、
別に固定長ブロックをポインタでつないだ「タスクシステム」とやらに限った
話じゃない。
ポエマーだけど、人違いされたままなのは気に入らないので横合いからちょっかい出してみるのねー
>>255 ジョブ(プログラムとデータを関連付けたもの。要するにオブジェクト)の連結リストを巡回して実行するだけで
これこそが神の技だとかソロモンの指輪(どう見てもガチャガチャで入手した飴菓子のジュエルリングだが)だとかいって
ホルホルしてるウンコカルト教の信者のつまらないプライドをベキベキにへし折るためのちょっとしたアンチテーゼとして
「STGで弾とかパーティクルを大量に出すなら
>>2 より配列で素直に書いたほうがちょっぱやだけど何でそうしないの?」
みたいなこと書いたことあるけど、カルト教団からの脱会を決意をした子(
>>239-240 ,
>>249 )に向かって阿呆とか死ねとか
言ったりはしないよ。目出度いことなんだからお赤飯を炊いてあげたいくらいだねー
ところで
>>2 には深谷氏の流派に見られた特徴的な記述が微塵も感じられないけど、君はどうして混ぜこぜに語るの?
異質な点をあげればキリないけど、端的な例をあげれば
>>2 にはコンテキストの保存や切り替え機構がないよね。
>>2 書いた人はどいつもこいつもその必要性を微塵も感じてないんじゃないかな。ゆえに深谷氏の師事を受けた
人間ではないよ。まぁ優劣の話ではないのね。明らかに異質。完全に別物ってことなのね
>>257 それ、知らない人が読んでも意味がよく分からないと思うのねー
引用先で遠藤サンがおっしゃってる「順次処理」というのは、ジョブの処理内容のことだと思うのねー
別の言い方をすればジョブの内容はシーケンス制御ですよ、というお話だと思うのねー
これをマルチで行なう、というのは順次処理を行なうジョブ(複数個)、固定時間刻みで逐次処理することだと思うのねー
この逐次処理の処理単位は世間一般にはジョブステップとかタスクとか読ばれるのかもしれないのねー
luaのコルーチンと同じようにユーザーが挟み込んだ補助情報(yield文相当)で半自動的にジョブは分割されて
実行されるのねー。アセンブラでジョブを記述するにはとても使いやすかったのねー
×師事を受けた ○教えを授かった
△ジョブ(複数個)、固定時間刻みで ○ジョブ(複数個)を固定時間刻みで
一方で、
>>238 とか
>>253 の順次処理というのは連結リストに繋がれた順番の話だと思うのねー
繋がれた順番に実行するということ。つまり順次処理。バッチ処理だね
>>2 はジョブをバッチ処理する機能しか積んでないというのは本当だね。それを
>>2 では無理やり逐次処理に使う。
逐次処理するための足りない部分は誰が面倒みるの?ユーザーが面倒見るんだよ。全部ね
×
>>257 ○
>>261 酔っ払ってるとダメなのねー
これで
>>261 の引用元の遠藤サンが何で「タスク」という組み方を聞かれて「ジョブコン」のことだと推測したのか
が見えてくると思うのねー
可能性@ : 「タスク」という組み方が
>>2 程度のものだとは露ほども考えてなかった。想定外にお粗末な
>>2 可能性A : メインフレームの基礎知識がある人間は「タスク」と言われたら「ジョブステップ」かなと思う
言うまでもなく深谷氏を師事するものにとってジョブステップといえばアレである
ま、いずれにせよ。あの流派の人間に「ジョブコンとは
>>2 」なんて言い放ったら青筋立てて苦笑いすると思うのねー
>>271 > luaのコルーチンと同じようにユーザーが挟み込んだ補助情報(yield文相当)で半自動的にジョブは分割されて
> 実行されるのねー。アセンブラでジョブを記述するにはとても使いやすかったのねー
今でもコルーチンは便利だけど、その部分は C++ で書かずにスクリプト言語+スタックレスの VM 使うよな。
昔はスクリプト言語なんて贅沢は言ってられなかったわけだが。
277 :
名前は開発中のものです。 :2008/12/16(火) 07:45:28 ID:Xcw/e/us
スクリプトも無節操に使うとグローバル変数、関数とかわんない
タスクシステム>働いたら負けかなと思ってる
というか、ジョブコン(コルーチン)話はこのスレのスコープに入るわけ?
280 :
名前は開発中のものです。 :2008/12/16(火) 20:51:33 ID:JXrz6RNp
>>270 それってタスクシステムのアイデアを、そのままライブラリで厚化粧しただけじゃん
> ジョブコン(コルーチン) は?
>>277 一般的には、スクリプトは C++ の単一のインスタンスに張り付ける。
たとえば Enemy クラスのメンバ変数としてスクリプトを張り付けて、
スクリプトからは Enemy クラスのメンバ関数の一部だけ呼べるように
する。
何でもかんでもスクリプトから呼べると、そりゃ破綻するわな。
スクリプトのほうが利点があるなら最初から全部スクリプトで作ればいいじゃない?
>>283 適材適所。大半を全部スクリプトで作ったほうが良いのは、アドベンチャー
ゲームぐらいじゃないかなぁ。
>>281 ジョブコン=コルーチンって理解じゃ違うのか?
俺は
>>279 じゃないが
こういう結論になりそうな資料見たことある
内部の人間じゃないから分からんが・・・
なんか謎に包まれてんなあw
ジョブコンってコンテキストスイッチないじゃん ただのステートマシン
288 :
名前は開発中のものです。 :2008/12/18(木) 18:05:58 ID:iEg8pKUf
>>287 読んだ。
>スタックにプッシュしてあるリターンアドレスも含めた
>CPUコンテクストを復帰させて 各ジョブを呼び出す。
>ただし、リターンアドレスをポップする 形で呼び出すので、
> RTS で呼び出す訳ですが。
うは、なつかしいな。確かZ80で、RTS使うかわりに戻りアドレスをスタックに積んで
pop すると RTSよりマシンサイクルが少し速い、てな話だったような。
>>275 こういうの見ると、メインフレーム屋さんではなくて制御屋さんの発想な気がするけど。
マイコンのアセンブラだと、コンテキスト、というよりCPUのレジスタを保存する
とか普通の世界だったから、それを現代風にアレンジした「タスクシステム」で
考慮してないとしても卑下する必要はないと思うんだけどなあ。
かじっただけの俺がいうのもなんだが、あちこちのサイトで紹介されているタスク
システムの問題点は中途半端に汎用的で抽象化されているところじゃないかな。
ひとつのシステムで多用途に適用できるというのはPGの夢かもしれないけど、
ルーティンを嫌うアミューズメント用途にはちょっと無理があるような気がする。
やね本でこの手の技法を知った。 2年程実際に使ってて、今のところ大きな問題が出てないからまだ使ってる。 とはいえいろいろ小さな問題点や、 ハードのスペック故に浮き上がってきた問題も出てきた。 ただ、今は新しいやり方を覚えてソースを書き換える暇がないので、 じわじわと学びながら弄りながら変えていってるのが現状。 まあ不毛な喧嘩はともかく、 タスクシステムの問題点についてビシバシ突っ込んでくれるのは非常にありがたいので、 これからも話がズレない程度に熱く語ってくれ。
貴様に命令されるいわれはない
>>289 ありゃ、間違ってるな。てか、興味ない人はスルー願います。
>ただし、リターンアドレスをポップする
>形で呼び出すので、 RTS で呼び出す訳ですが。
z80でサブルーチンを CALL nn すると、現在の pc の次のアドレスを
スタックにプッシュして nn に飛ぶ。その先で rts すると、スタック
からアドレスを pc に読み込んで呼び出し元のアドレスの次の命令から
続くのが通常。上のはサブルーチン(タスク)を呼び出すのにその
逆をやってる。なんかの雑誌でみたことがあるな。
メリットは覚えてないやw
push でレジスタを退避させるのと一緒に使えて、速くて短い、とかかな。
>>292 は
>>287 を読んだだけで内容を理解できてないと思うから
ぐだぐだ書く前にちゃんと理解する努力をしろ。
>>293 まあ、そう突っかかんなよw
ではよく理解している293に教えて欲しいんだけど、
(1)「タスクシステム」いうだけで、なぜ271は
>ウンコカルト教の信者のつまらないプライドをベキベキにへし折るための
>ちょっとしたアンチテーゼ
みたいに口汚く否定しなければならないのか?
(2)「タスクシステム」がだめならジョブコンでどうかというと
>あの流派の人間に「ジョブコンとは
>>2 」なんて言い放ったら青筋立てて苦笑いする
みたいに必死に否定するのはなぜか?
(3) 青筋を立てているのは271ではないのか?
以上3点、ご教授いただければ幸いですw
なんつか、271はそれなりに知見のある人間にも見えるんだけどなぜ?って感じ。
定義ごっこウゼーからヤメロよ 名前なんて関係ねーよ ポインタ保持 グローバル変数関数使いまくり のソースは問答無用で糞コードなんだよ
>>290 にはたぶん向いているんだろう。俺にはちょっと使いづらいかなと思った。
あんまり頭よくないんで、全体を把握しにくいコードでポインタを使いまわす
のはおっかないと思ったよ。
いずれにせよ、コストと手間を考えて手段を選ぶだけなんだから、手法のメリット
デメリットを論じるならともかく、使うだけで罵ったり赤飯炊いたりしてくれるのは
まあ、本筋と違うと思うんだけどなあ。
>>295 new 厳禁, malloc問題外かあ、そりゃ難儀だな。
295 はよほどでかいスタック使ってるんだろうなあ。すばらしい。
>>297 ああ、やっぱり馬鹿なんだw
馬鹿だから横文字連発して誰でもできる名称の定義にこだわってんのバレバレ
あー恥ずかしいw
>>294 >>271 は撲殺天使気取りのカルシウム足りてない人だから。以上
というかタスクシステムってちゃんと使えばTCBにキャラクタ固有のデータを
おくはずで、グローバル変数は回避するのが正しい使い方だと思うのだけどな。
ID:oW76AwO4
ID:9M4acoh9
ID:1VWYpijd
>みたいに口汚く否定しなければならないのか?
↑(゚∀。)↓
>
>>271 は撲殺天使気取りのカルシウム足りてない人だから
ルサンチマン号…
>>299 自キャラクタのデータを TCB に置くのは当然として、タスク間の相互作用を
どう記述するかが問題。ヒット判定とかホーミング弾とか。
ここで、他タスクのポインタを持つと寿命管理でミスして dangling pointer 問題が
発生しがちだし、マネージャクラスみたいなものを作ろうとすると、グローバル変数
多用することになる気がするんだが、どう解決してるんだろ?
302 :
293 :2008/12/22(月) 23:56:55 ID:/r5SxkM/
>>294 俺は271じゃないから271の考えてることはわからんよ。
でも
>>2 は、
・
>>287 のリンク先のジョブコンでの重要な要素(PCとSPが保存される)が消えてる
・CodeZineの記事はメモリ管理がキモすぎる
・TCBとスタックポインタというRTOSで使われる用語を全く別の一般的じゃない意味で使ってる
ので、ああいうのが代表的な解説になってるんじゃヤバいと思うよ。
俺はゲーム自体の出来がよければシステムなんてなんでもいいんだけどさ。
>>289 やぁどうも
>マイコンのアセンブラだと、コンテキスト、というよりCPUのレジスタを保存する
>とか普通の世界だったから
マイコンでcontinuationすることが普通だったのか
80年代初頭においてそうした普通があったというのは寡聞にして知らんので
是非ともご教示いただきたいです。よろしくです
>それを現代風にアレンジした「タスクシステム」で考慮してないとしても
「アレ」を現代風にアレンジすると
>>2 になるのか。見聞の狭い俺にとっては初耳だ。
現代風にアレンジするとcontinuationは必要なくなるという話も新鮮な響きだ。
「アレ」に必要な処理量と得られる利得(ユーザビリティ、etc)を鑑みたうえで
continuationを積極的に「省く」メリットを探してみたのだが不肖の俺には
荷が勝ちすぎるようだ。この辺りについても是非ご教示いただきたい
重ね重ねよろしく頼むよ
えーと。 確かに継続で間違いないんだが、マルチタスクなOSの(リアルタイム、 非リアルタイムを問わず)コンテキストの保存と復帰、まとめてディスパッチと いう概念は、計算機の歴史としては割込みと同じくらい古い。確か マルチプログラミングと呼んでいてOSより古いはず。 (というか、割込みの前と後で戻る所を次々すげ替えていけば、マルチタスクに なる、よね) 現代的には、OSのスレッドサポートと、言語側の継続とかコルーチンとか、 という風に分かれちゃってるけど、マイコン時代にはアプリからモニタまで 全部ユーザが面倒を見るのが当然だったから、ジョブコンも別に大げさな 仕掛けにはならなかった、のだと思うわけだな。 > continuationを積極的に「省く」メリットを探してみたのだが不肖の俺には > 荷が勝ちすぎるようだ。 確かにこっちは無理だw
文章長すぎる奴自重しろ 中身もねぇのにだらだら無駄に長い ホントにプログラマーか?お前
>>302 > ・TCBとスタックポインタというRTOSで使われる用語を全く別の一般的じゃない意味で使ってる
> ので、ああいうのが代表的な解説になってるんじゃヤバいと思うよ。
TCBは痛いが、スタックポインタについては、メモリブロックのLIFOな管理技法に
使う用語として一般的なものだと思うが?
むしろアーキテクチャ用語のスタックしか思い浮かばないほうが視野が狭い。
KEIZOKU?
継続 = continuation
>>304 やぁありがとう。非同期的に呼び出される割り込みハンドラはコンテキストの保存と復帰をするよね。すまん。
ところで割込みの起源の話があったので、Donald.E.KnuthのThe Art of Computer Programmingを
めくってみたところDYSEACというコンピュータが最初だそうだ。ぐぐってみたところ面白いページ発見
History and Overview of Interrupts and Interrupt Systems -- Mark Smotherman
http://www.cs.clemson.edu/~mark/interrupts.html によると割り込みの始祖はUNIVAC1まで遡る。算術オーバーフローの例外処理。ソフトウェア割込み。
割り込みの一番おいしいところである外部割込み(ハードウェア割込み)はKnuthの言っていたDYSEACで
これは米商務省標準局データ処理システム部門電子計算機研究所が開発したもので、米陸軍の
移動式通信システム用として1954年から運用が始まったそうだ
米陸軍弾道研究所 報告書No.1115 国産電子計算機についての調査(第三回目)
http://ed-thelen.org/comp-hist/BRL61-d.html#DYSEAC >(3) an interruption property which enables the machine to handle unscheduled ,job assignments
> which originate externally without advance notice and must be executed as soon as possible
DYSEACはマルチプログラミング(例えばI/O処理に計算機を独占させない)を実現していたと思われる。
Mark SmothermanによるとDMAもこいつが最初かもだそうだ。おもしろいね
ふむ。撲殺天使の人か別の人かわからんが、興味深い情報をありがたう。 mobile computer と書いてあるからびっくりしたが (carried in two tractor trailers at 12 and 8 tons, respectively!) とすぐあとに書いてあった。 TRONチップとか、命令の実行に伴って起きる「例外・Exception」、外部入力 で起こされる「割込み・Interrupt」、OSの呼び出し等に使う「トラップ・Trap」と 使い分けてたりするね。 さて、いいかげんで昔のPC板行けと言われそうなので手短にポインタだけ 示すが、岩波講座情報科学1『情報科学の歩み』(高橋秀俊、1983)のp.48 によれば1959年にパラメトロンコンピュータPC-1に筆者らは割込み機能を 付けているが、「割込みという日本語も,英語の interrupt の訳ではなく, われわれのグループで使いはじめたことばである.」だそうだ。 『コンピュータへの道』(高橋秀俊、1979)のpp.148〜151にも割込みの話が 出ている。
まだなげぇ、すげーなげぇ 少しは相手の反応をみるとか ちょっとした気遣いは全くないのか? 誰も聞いてないことをベラベラベラベラよくしゃべるなぁ
スレチだが。面白かったよ俺には。 長いとか、よくしゃべるとか、批判の対象が違うだろ。 自分の興味のないこと=誰も聞いてない としか受け取れないのか? ただスレ違いなだけ
>>313 おお、じゃあ、適当なレス返してやれよw
で、俺が見たのはz80のアセンブラ本で、マルチタスクを実装するのに win3.1みたいに自分でジョブを明け渡す方法と、割り込みを利用して スイッチする方法がのってた。どっちにしてもなんらかの形で レジスタの保存と復帰はあたりまえだよね? んー、多分おれが的外れなことを言ってるんだろう。もう黙るわ。
黙るといっておきながらあれだが、
>>315 は1992ってなってるな。80年初頭とは違いすぎるね。
だけど、マイコンでみんなやったことってメインフレームの真似事だったんだけどなあ。遠藤さんのスレの例の肝は、リロケータブルなプログラムの組みにくいz80で、RTSを
利用して実現したことだと感心したんだがな。まあいいや。
continuation(継続)とは、要するにコンテキストのようなものだが、
かなり抽象的な概念で、コンテキストとはプログラムの実行中の
一瞬の状態のことだが、継続とはその先にある計算全部を
ひっくるんだもの。ある種の高水準言語(特にScheme)では
一般概念。OSや機械語のレベルで直接扱うことはまずない
(というか高水準の概念)。
Googleで「継続」を検索すると上位10ページの半分弱は
これの説明なのでざっと見てみるといいかも。
「マイコン マルチタスク」で検索するとインタフェースのバックナンバー
目次がひっかかった。1984年9月号の特集が「Cとマルチタスク・モニタ」
なので、そういう記事だろう。多分。
ttp://www.cqpub.co.jp/interface/contents/198xindex.html
319 :
名前は開発中のものです。 :2008/12/24(水) 21:21:45 ID:tzcrgEm1
また、長文垂れ流しか ホント無駄な奴等だな
>>318 おお、ありがと。1980年の
>12月号 特集◆リアルタイム制御用マルチ・タスク・モニタの研究
なんかもまんまだな。「非同期〜割り込みハンドラは」とか留保つけてるくらいだから
認めてもらえそうにもないが。いつのまにか
>continuationを積極的に「省く」
ことにされてるし。
このスレで continuation といえばマイクロスレッドとかファイバとかの話になるよね。
で、このスレでもおなじみのやねうらお氏がこんなのも用意してたりするわけだよ。
ttp://ml.tietew.jp/cppll/cppll/article/6196 でもさ、コンテキストスイッチングとかマイクロスレッドってc/c++標準の機能でもないし、実装にはそれなりに手間もかかるし、無いとまったくプログラムできないわけでもない。
そういうものをタスクシステムを紹介している
>>2 に包含してないからって駄目呼ばわりするのはどうなのよ。
黙るとかいいながらまた長文たれながしてるな。すまんね。
>>319
おっとあぶない。コンテキストスイッチを setjump()/longjumpで実装することも できるみたいだし、GNU pthを使ったコルーチンの例もあるから、c標準 で実現できないと書くとまた突っ込まれるな。もうぐだぐだだ。
馬鹿だろ 普通初見でプログラムみたらそういう状態が認識できるならそういう変数探すだろ 探してあればそれは読みやすいプログラム ところがそれを無くそうとするとかいかにやねうらおの程度が低いかわかるな あるべきところにあるソースのほうが俺はいいソースだと思うぜ やねうらおまわりってさ こういう普通の常識もわからない馬鹿ばっかりだから嫌いなんだよね 俺、俺が初心者のときから嫌な匂いしたわこいつら 俺ももう経験10年だけど こいつらってズレてんだよね 力入れる部分がさ
>>320 > そういうものをタスクシステムを紹介している
>>2 に包含してないからって駄目呼ばわりするのはどうなのよ。
じゃ、使うメリットが何もないじゃん。
>>322 このスレの流れと逆のこと言ってないか?
このスレの流れ的には、
ジョブコンにはコンテキストスイッチがあったのに、それの発展形を
事象するタスクシステムはそれを取っ払ってる。その結果、グローバル変数で
状態を持ってやったりしなきゃならない、バカじゃね?
ということになってるのに、なんで突然そのグローバル変数を賞賛するかね?
やねがズレてるのは俺も感じてるが、お前はもっとズレてる。
>>324 は?
グローバル変数を賞賛?
どこにそんなこと書いてあるの?
やねうらおまわりはあいかわらず馬鹿だな
> そういう状態が認識できるならそういう変数 って普通グローバル変数だろ。 グローバルじゃないにしてもstatic変数。実行させてみないと挙動が把握できない。 そういう変数じゃなくて、ブツ切りの挙動を上から下に並べて書けるのが、 継続とかコルーチンとかマイクロスレッドとかファイバを利用したテクニック。 それを頭からバカにしてるのがお前。
よくわからんが、FSMの状態変数のことを言っているんなら クラスのメンバあたりが妥当で、別にグローバルやstaticである 必要は無いんじゃないの
>>326 はぁ?
思い込み激しすぎ
どこにそんなこと書いてあるの?
ポエマーはクリスマスの家族サービスも終わって一休み、一休み あとは印刷屋に注文したブツが配送事故なく無事に現地に到着することを祈るだけだよ ∩∩ (・x・) 「パパは誰と戦ってるの?」 (@∀@)「パパはね、今フェードアウト2Dゾンビという怪人と戦ってるんだよ。 この世に未練タラタラの8bit悪霊に取り憑かれた若者達を正気に戻すために 作文を書いてるんだ。おやすみ」 ∩∩ (・x・) 「ふーん、まぁがんばってね」 娘に絵本を読んで寝付かせた後にネットブックでちょっかい出しに来たのね。勤労家だね
>>289 >こういうの見ると、メインフレーム屋さんではなくて制御屋さんの発想な気がするけど
私がまだ下っ端だったころ、電機メーカーでプラントのプロセス制御用のシステム開発に
携わってた人とか、光学機器メーカーで組み込みシステムに携わってた人がいたのね
彼らは今で言うところのリードプログラマに相当する存在だった。俺を含む当時の若手は
彼らから色々教わったのねー
メインフレーム屋(?)とか制御屋(?)とか、そういう分類はよく知らないけど
(基幹業務システムの人とか組み込みシステムの人とかそういう分類で言ってるんだとは思うが)
そういうのに関係なく、当時コンピュータに携わってた人間は多かれ少なかれリタラシーとして
メインフレームのことは知ってたのね。学生時代、お手本となる本格的なコンピュータシステムといえば
その代表格はメインフレームとその弟分たち(オフコン、ミニコンとか)だったのね。教科書には
当たり前のように登場したし、卒研のためにメインフレームを使わせてもらえる贅沢環境を体験した奴も
いたのね。研究室単位ではミニコンのほうが多かったけど、それらのモニタやOSもメインフレームなどの
大型コンピュータのそれを踏襲してたのね
【メインフレームの基礎知識】って言ったのはそういうことなのね。教科書レベルの知識のお話
>>294 >(1)
別にぽまえさんがクリティカルヒットしたわけじゃないでしょ?
他人事ならニヤニヤしてればいいと思うのよねー
まぁ何度も言ってることだが、当時の実装対象の特性なんてこれっぽっちも知らない人間が
64bitマルチコアCPU&9600GTクラスのビデオカード(DSPカード)搭載のモンスターPCを持ってたりする人間が
IDE付きの静的型付言語の開発環境(VS2008EEなど)+DirectXなどを使ってる人間が
ちゃんこ鍋循環リストにすべてを放り込んでバッチ処理するだけの(今となっては何とも珍妙でお粗末な)
仕掛け(
>>2 )をどうして神格化するのかおじさんは不思議で不思議で仕方が無いのよねー
「タスクシステム…いとしいしと…」と地底奥深くでひっそりと一人で、職場の中で囁くだけなら別にどうでもいいが
公衆の前で「
>>2 素晴らしい!神の業!すげーすげー!超参考になる!真似しないと!」と絶叫する奴は
相応の陵辱を受ける覚悟をしてもいいと思うのよねー
まぁこのスレを、公衆の前と思うかチラシの裏と思うかは人それぞれという気もする。
334 :
名前は開発中のものです。 :2008/12/26(金) 00:27:54 ID:mDOQ1BG2
>>331 ハァ?、て感じだな。
一体、何を問題にして、何を前提にしているんだ?
一体、何を問題にして、何を前提にしているんだ?
一体、何を問題にして、何を前提にしているんだ?
一体、何を問題にして、何を前提にしているんだ?
一体、何を問題にして、何を前提にしているんだ?
一体、何を問題にして、何を前提にしているんだ?
一体、何を問題にして、何を前提にしているんだ?
一体、何を問題にして、何を前提にしているんだ?
一体、何を問題にして、何を前提にしているんだ?
一体、何を問題にして、何を前提にしているんだ?
私は、何かの縁で最近就職希望の学生さんの就職説明会(なのかしら)に立ち会う機会があった。 どこもかしこもみんな多忙で、こんなオサンが出張ることになった。フェードアウト窓際のふりをして タラタラと講話をしていた。眠い話が終わると、ご質問ごじゃいますかーと進行のお兄さん(イケメン)が言う 想定どおり、痛くもかわいい質問が多くてにんまりうんじゃりしていたが、特にやべぇと思ったのが タスクシステムがどうのとかいうゲー専の子だった。本物のフェードアウト2Dオヤジの講師にナニを 吹き込まれたのか知らないが私はゲー専に行く子はちょっと可哀想だなとそのとき思った。 彼には直接個人指導してやりたかったがそういうお時間はいただけなかった。まぁどうでもいいや
×フェードアウト窓際のふりをして ○フェードアウト窓際としては久しぶりの仕事なので
>>334 主要部だけ抜き出すとここだな。
オブジェクト指向の恩恵をふんだんに受けられる環境で開発してながら、
ちゃんこ鍋循環リストにすべてを放り込んでバッチ処理するだけの
(今となっては何とも珍妙でお粗末な)仕掛けをどうして神格化するのか?
339 :
名前は開発中のものです。 :2008/12/26(金) 00:57:58 ID:mDOQ1BG2
>>337 悪いが俺には、
「オブジェクト指向の恩恵をふんだんに受けられる環境」で
タスクシステム指向を否定する理屈が理解できない。
>一体、何を問題にして、何を前提にしているんだ?
> ちゃんこ鍋循環リストにすべてを放り込んでバッチ処理するだけの > (今となっては何とも珍妙でお粗末な)仕掛け という評価を否定してみせろ>ID:mDOQ1BG2
>>339 >タスクシステム指向を否定する理屈が理解できない
頭おかしいんだw
Lisp?>ちゃんこ鍋循環リスト Lispは何でもリストで、データとプログラムが同等で、 プログラムを生成するプログラムは常套手段ですが、 今や再評価される一方のモテ言語でつよw
Lispのリストは単方向リストで、普通は関数的に使うもの。 (まぁ副作用バリバリで使うこともあるけどな) 「タスクシステム」のリストは、双方向リストで、デク(Double Ended Queue) と呼ばれるデータ構造。副作用バリバリで使うのが基本。 もうちょっと中身がわかるまで勉強してから出直してね。
あ、つまり、同じ「リスト」でもはっきり言って別物だよ、ってことね。
>>343 その説明だけだと、Lispがなぜ良いものでタスクシステムがなぜ
唾棄すきものかがさっぱり分からないのですが。
Lispと同一視して再評価すべきだ、みたいな話を持ち出したのはそっち。 俺はそれを否定しただけ。
静的型安全性が無い、コードがデータと同じで自己書き換えを行えてしまう、 といった動的性はLispにも当てはまることです。 Lispはconsセルをもとに、データ構造をどうとでも作れます。
>>346 タスクシステムを再評価すべきだとは「一言も」言っていませんよ。
そもそも
>>342 は半分以上ネタです。
が、「ちゃんこ鍋循環リスト」は、それで何かを貶したつもりになっているのなら
少々不適切なのでは?と愚考する次第です。
>>345 馬鹿じゃねぇの
話そらしてんじゃねぇよ
やねうらおの近くにいるとくだらない話術ばっかり達者になってくカスに成り下がるな 奴は所詮3Dも理解できないクズ 大きく複雑な仕組みを小さく単純な形に噛み砕くことはできない 本人すげー頑固で視野狭いしね 止まっちまう理由もわかる
確かに、一度は奴に傾倒しても、適度に距離を置いた奴は大成してるね。
>>349 プログラム全体を関数型で設計するなら、Lisp のリスト構造が適している。
ただゲームを組むのに関数型言語が合ってるとは思えんが。
>>352 そうだね
奴もすべてが駄目ってわけじゃないんだよね
でも結局、3Dができねぇってのは大きく複雑なものを小さく単純な形にできないってこと
これはプログラムの能力に直結する
小さいプログラムをこね回してる分にはどんな方法で何やったってなんでもできるんだよ
でも本当に複雑なものを管理するにはそれなりの力がいる
ごちゃごちゃいう前に3Dやってみろボケ
ってことだよね
まあ、ヤツにいえることはこういうことだよね
>>354 すげぇ理屈
もしかして昔奴の「クォータニオンどうこう」に騙されてたとかそんな理由?
357 :
名前は開発中のものです。 :2008/12/26(金) 22:38:40 ID:mDOQ1BG2
>>340 タスクシステムにケチ付けてるとも読み取れる中途半端な書き込みしやがって。
ヘタレっぽい書き込みだから無視してもかまわないんだが、
看過するのはやや気が咎める。
相手してやってんだから、もっと具体的な話してみろや。
ほれ、どうしたんだ。
>一体、何を問題にして、何を前提にしているんだ?
>一体、何を問題にして、何を前提にしているんだ?
>一体、何を問題にして、何を前提にしているんだ?
>一体、何を問題にして、何を前提にしているんだ?
>一体、何を問題にして、何を前提にしているんだ?
>一体、何を問題にして、何を前提にしているんだ?
>一体、何を問題にして、何を前提にしているんだ?
>一体、何を問題にして、何を前提にしているんだ?
>一体、何を問題にして、何を前提にしているんだ?
>一体、何を問題にして、何を前提にしているんだ?
ねーねー聞いていい?
この人がケチ付けられたと火病ってる「タスクシステム」ってナニ?
え、
>>2 なの?マジで
>>2 なの?すごくね?まじシステムって感じ
ひらしょーさんに「タスクシステム?なにそれ?」って言われた時点で こいつらはもう死んでる この単語がだれにも通用しないってことがわかっただけでもいいだろもうw
違うな ぼくのかんがえたぼくのたすくしすてむをばかにするやつはゆるさない ぼくのたすくしすてむはぼくがぼくであることのあかし、ぼくのあいでんててーそのもの ぼくのたすくしすてむにけちつけるやつはぼくをひていしようとするやつだ だ か ら っ ぜ っ た い っ ゆ る さ な い っ っ ということだと思うぞ タスクシステムという単語を使って突っ突くとどっかの誰かが癇癪を起こすのだ わくわくするだろ
362 :
名前は開発中のものです。 :2008/12/27(土) 00:13:18 ID:kUina8sT
ID:mDOQ1BG2だけど、 「嫌タスク厨」って気色の悪い連中が多いな。
364 :
名前は開発中のものです。 :2008/12/27(土) 00:39:49 ID:kUina8sT
「嫌タスク厨」の書き込みを見てて思うんだが、 >一体、何を問題にして、何を前提にしているんだ? これにつきるな。 恥ずかしい連中だな。 プ!! ワリィ、失笑しちまったぜ。
ポエマーは3D酔いの話をしたら眠くなりました
また、やねうらおに騙されたかわいそうな初心者が発狂したか
>>365 つーかあんたなんで初心者スレでは優しい人に変身してんだよ
キャラ変えすぎだろ女子高生的に考えて…
6年も前のMLのログを引っ張り出して何やってんだか
正直俺も嫌タスク厨はどうかと思う。
あれ、ID変わったかな?
371 :
名前は開発中のものです。 :2008/12/28(日) 00:08:38 ID:9bx8+r7b
>やねうらお >一体、何を問題にして、何を前提にしているんだ?
>>370 日本語としては「じっぽん」が正しいが、レッドブックの「とおほん」(×とうほん)も間違いではない
ただ朝鮮人や一部の関西人が良く使う「じゅっぽん」は明らかに間違い
これを使っていると日本人である事を疑われるので気を付けるように
10円20銭
374 :
名前は開発中のものです。 :2008/12/29(月) 07:51:23 ID:5ANW5Mxu
「嫌タスク厨」はロクに質問にも答えられないキチガイばっかだな。 常人の感性からすると気色悪くて目障りだからオンするなよ、なあ? 親切心から言ってやるが、 本人気利かせているつもりのチンケで鬱気味の幼稚表現も痛々しいぞ、自覚してるか? まあ、それがお前らの正気状態か。 せいぜい頑張れや。 プ!!
375 :
名前は開発中のものです。 :2008/12/29(月) 11:21:47 ID:Ah7A1aEB
ひらしょーさんになにそれ?だれきみ?ってあしらわれたショックで 気が狂ってしまったん?
自分の言葉で論破できなかった厨房が、お墨付きをもらって狂喜してるだけにしか見えない。
ま、そういうくだらない連中のノイズ成分くらい除去できないと駄目だと思うけどね
ひらしょーさんひらしょーさん言ってる子供達もどうせついこの間までは
たすくしすてむさいこー松浦先生大好き尊敬しちゃうとか言ってたはずなわけで
風見鶏を右へ左へ引きずり回すのは楽しいよね。そろそろ
>>2 擁護始めるか
その問題のやねうらおとやらは、お前たちの何倍ものプログラミング能力があって、 お前たちの何倍も稼いでいるようだけどな
やねうらおが何だのかんだのと喚いてるのはpmocky一名だろう
pmokyな。奴がこんなとこで粘着する性格とも思えないが。
本人乙。やねうらおと何があったのか知らんが あちこちのスレで発作的ESPでやね探知する度に私怨コピペ張るなよ マ板にスレ立てるなり民事調停するなり労基に駆け込めよ
と思ったらスレあんのかよ。あのオッサンの界隈は相変わらず賑やかだね
383 :
名前は開発中のものです。 :2008/12/30(火) 21:29:05 ID:kY5NjYxZ
松浦先生はエフェクトの人? やねうらおなんかと比べるのは失礼だろ(笑)
どう見てもそのやねうらおとやらののほうが格上だがな。 松浦先生の最新刊 ゲームアルゴリズムレシピ for JavaScript (単行本) 2008/11 発売。 Amazon.co.jp ランキング: 本で131,156位 一方、同時期に発売されたやねうらおとやらの ひなた先生が教えるデバッグが256倍速くなるテクニック 2008/11 発売。 Amazon.co.jp ランキング: 本で652位 私怨か何だか知らんがいい加減、見苦しいよ。
385 :
名前は開発中のものです。 :2008/12/30(火) 22:25:35 ID:kY5NjYxZ
本読んでみりゃわかるのに
大掃除も終わったし、一杯ひっかけながらちょっとポエムを書いてみるのねー
多数のジョブを並行、並列に処理する能力は科学計算、軍事、宇宙開発など様々な分野で必要とされた。
特にリアルタイムという要求は軍事や宇宙開発と絡むことが多かった
【2DSTGの礎を探る】
第2次大戦中、米海軍がMITに艦攻のフライトシミュレータの基礎研究を依頼した。
海軍は風洞試験の結果をリアルタイムで再現する航空機解析・空力数値計算を希望していた。
当初MITはアナログコンピュータでこれを試み、後に海軍の提案でデジタルコンピュータの
開発に注力しWhirlwind I を作る。しかしその頃には軍はコンピュータを航空機解析よりも
戦術情報処理や指揮統制業務の能力向上に役立てることに関心が移っていたという
おりしもソ連がファットマンをコピーしたと思われるプルトニウム爆弾の実験(RDS-1)を成功させ
米国内が大騒ぎしていた時期でもあり、Tu-4長距離爆撃機による米本土への核攻撃も可能(※)と
分析されていた。空軍はこれに備えるために地上要撃管制(GCI)の連結と自動化に取り組んでいた。
空力計算の数値積分結果を逐次・リアルタイムでベクタースキャン型CRTに投影し・可視化しようと
していたMITのシステムは空軍の要求に堪えるものと評価され、Whirlwind I は防空システム用
コンピュータのプロトタイプとなる。ニューイングランドのGCIのデータを電話回線経由でMITに転送し
Whirlwind1がこれをリアルタイム処理するというデモンストレーションが成功し、Whirlwind1をベースに
大規模化したコンピュータAN/FSQ-7として正式化され、IBMが主契約をゲットして量産した。
http://www.mitre.org/about/photo_archives/sage_photo.html
>>386 続き
多数の敵機を捕捉・追跡しながら迅速・適切に邀撃戦力を配当する(意思決定をサポートする)
SAGEシステムが50年代から本格運用された。これは後にICBMによる全面核戦争を想定した
防衛システムや海軍機動部隊の艦隊防空システムなどの礎となる。
SAGEコントロールルームのオペレータはベクタースキャン型CRTとライトペンの組み合わせによるGUIで
直感的な操作を行なうことができた。この技術はCADの礎となった。(アーケードのガンシューもこれ)
SAGEは逐次更新されF-102デルタダガー邀撃機のオートパイロットやCIM-10ボマーク長距離SAMの
中間指令誘導もできるようになった。こうしたリモートコントロールの技術は宇宙機やUAVの礎となる
(※)ソ連はそのころB-29の劣化コピーであるTu-4を配備していたがその航続距離はB-29よりも
劣っていたことが後に判明する。片道切符で欧州の主要都市を核攻撃する能力はあったが
米本土まで出張る能力はなかった。後にターボプロップ式の超長距離大型爆撃機(Tu-95:ベア)
の配備が始まってようやく片道切符であればモスクワ-ワシントンDC間を無給油で核爆弾を
お届け可能となった。
米国はTu-4の航続距離とTu-95の保有数を過剰に見積もり、戦術情報処理・指揮統制業務の
自動化や超音速でぶっ飛んでいく邀撃戦闘機や長距離SAMなどの研究開発に多額のお金を
投じることとなる
この防空システムで培われた技術はIBMやDECのメインフレームの礎にもなった。特に後者の
PDPシリーズにとってWhirlwind I は直系の親筋にあたる。MITの学生が作ったSpace War!などに
代表されるベクタースキャン型CRTのSTGはPDPシリーズで作られた
(終わり。寝る)
388 :
名前は開発中のものです。 :2008/12/31(水) 05:08:08 ID:vN1M20DF
キチガイだな 華麗にスルーして次の話題ドゾ
>>386-387 最後にSpaceWarにつながるのかw
あのソースってパブリックドメインなんだよね
ダウソして解析しようとしたことあるんだがPDPの
アセンブリコードの読み方が分からなくて投げた
WikipediaのSAGE半自動式防空管制組織のページを開いたら >50万行にも及ぶアセンブリ言語で書かれた ( д )゚ ゚ スポーン
・SFCでゲーム一本3万行を超えた記憶がない。ような気がする ・AN/FSQ-7の命令セットがどんなものか知らんのでアレだけど きっちりかっちり設計して50万行か。保守が大変だったろうね ・別の視点で見るとそれだけ巨大そうなシステムがアセンブリ言語で "たったの50万行"で動いてた、ということにちょっと驚いてみたーり ・昭和20年代でコンピュータが戦闘機を遠隔操作とかやばい。冷戦やばい ・MITやばい
PDP-11ならUnix V6関係で解説とかあるけどな。
ttp://www.tom-yam.or.jp/2238/asm.html これとか手がかりになるかな。
先日もサンタクロース追跡で大活躍したNORADのシステムの祖先の話やね。
トラックボールの発祥もそれだったから、ミサイルコマンドの源流もそこか。
こまかい所だがDECのはミニコンピュータね。それにしても何かの引き写しじゃなくて
自分で書いとるのかいオッサン? データプロセッシング分野と比べて
リアルタイムアプリケーションの話は文献が無いと思うのだが。
393 :
名前は開発中のものです。 :2008/12/31(水) 16:41:55 ID:vN1M20DF
スレ違いじゃないの?
ワイヤーフレームの図形描画に対応してたのか ゲームを作りたくなる気持ちが分かる気もするな
395 :
名前は開発中のものです。 :2009/01/01(木) 00:31:54 ID:ocRuaHu5
関係無いよね スレと
コンピューターが沢山の爆撃機(敵オブジェクト)の振る舞いを監視して 飛行データから未来位置や爆撃目標到達時刻を予測して人に教えて 迎撃機やミサイル(味方オブジェクト)に向かうべき座標を指示する・・・か まさにリアルDEFCONだな 写真にディスプレイの記号解説あるな 各オブジェクトが所有するステートが垣間見れて面白いな POINT OF ORIGIN ALTITUDE DIRECTION SPEED IDENTITY TRACK NUMBER FLIGHT PLAN NUMBER CORRELATION STATUS TYPE OF AIRCRAFT FLIGHT SIZE
CORRELATIONって辞書引くと相互関係、相関関係となるけど 自機僚機とか親子(発射母機とミサイル)とかそういうもの? んービル一棟分の真空管コンピューターでSTG作ってみたいわ
398 :
名前は開発中のものです。 :2009/01/01(木) 06:37:29 ID:ocRuaHu5
スレ違いやめろ
スレ違いどころか、板違いだな。 昔話用の板あるんだから、そっち行けよ。
>>397 なるほど・・・・・ちゃんとFSMしてるんだな
超プロプライエタリな世界だからソースは無論非公開だろうけど
仕様からおおよそのところが想像できておもろいな
sageずに書き込みしてる
>>374 ,375,383,385,388,393,395,398 が、
底抜けの馬鹿だと言うことはよくわかった
403 :
名前は開発中のものです。 :2009/01/01(木) 15:00:31 ID:ocRuaHu5
全然関係無い内容じゃん 引用するにしてもスレと内容の説明責任ぐらい果たしていけよ 垂れ流しが酷いし タスクシステムと関係無いじゃん 関連してると思ってるって自分だけの思い込みで強引に話を無駄に広げてるんだろうけど ちょっとオナニーが酷く生臭いよ
編隊飛行が表現できるなら木構造になるし ロックオンした目標が複数あればグラフ構造にもなるな
>>403 わかってないのお前ひとりだけじゃん。
お前が底抜けの馬鹿だからわからないだけで・・・
板違いスレ違いを続けるのはそろそろどうかと思うんだな。
407 :
名前は開発中のものです。 :2009/01/01(木) 16:53:23 ID:ocRuaHu5
全然関係無いよね なんか わからないんだ?プギャー(笑) 的な流れにして説明責任果たそうとしない流れにしがちだけど 現実、仕事となったらここが一番大事だしその後の理論がどんなに立派でも糞とカワンネ 仮に関連してたとしてもこれ関連性を説明するの滅茶苦茶大変だぜ
訂正。わかってないの、
>>406 ,407のお前ら二人だけだよ。
大馬鹿はお前ら二人。
触んないほうがいいんじゃない?
>>404 こういうのってHFSMみたいな記述になるのかしら
ツリーの各ノードがFSMっていうイメージでいいのかな>HFSM
HFSMは状態の木構造、状態の中にさらに状態がある みたいなものじゃなかったっけ(ちがったかな) 編隊のリーダーと部下みたいなFSM同士の主従関係とか 組織のヒエラルキーをあらわす木構造の場合は 単に木構造のコンテナにFSMが入ってればいいだけなので HFSMとは違うかもだ
412 :
名前は開発中のものです。 :2009/01/01(木) 19:05:56 ID:ocRuaHu5
>>408 そんなこと言って難しい部分は説明できないから逃げる気でしょ?
職場でもこんなわけのわからないもの採用させるなんていったら大変なのはそこだよ
逆に批判をかわすのもわけわかんないこと叫んでかわせばいいけど
そうゆうこと馴れると技術者として死ぬよ
批判する側に説明責任の押し付けゴッコ始めていつもかわすけど
そもそもなんの関連もないの明らかじゃん
>>412 何度でも言うがわかってないのお前ら馬鹿二人だけなんだよ。
なんなら周りのプログラマにこのスレ見せて聞いてみなよ。
414 :
名前は開発中のものです。 :2009/01/01(木) 19:29:46 ID:ocRuaHu5
説明責任放棄する奴は二言目には必ずそういう 関係無いから関連を説明しろっていってるだけじゃん
>>414 馬鹿すぎて周りに友達いねーのか。それは可哀想に。
>>386-387 すげぇな
飛行機や対空ミッソー飛ばしてもデッドライン(敵が目標上空に着く時間)までに
敵とご対面させてやらなきゃ全部パーだよな?
リアルタイムシステムだな。しかもかなりハードな
匿名でも記名でもi君の人を見下した態度は相変わらずだな
>>411 dクス。なるほど。状態に子あ孫があるのか
で、代替案はまだ出ないの?
420 :
名前は開発中のものです。 :2009/01/03(土) 23:49:19 ID:x7V4/J69
代替案? なんの? こんなもん使わなきゃいいだろ 普通に必要なだけ処理書いて引数で必要なもんだけ渡せよ
つまり420は配列派というわけですね?
アホか オブジェクト指向で普通に書けばいいだろヴォケ
423 :
名前は開発中のものです。 :2009/01/04(日) 10:01:35 ID:bsxJMCxA
配列はインスタンスの話だろ 多分
Taskをモナドにしよう
オブジェクト指向で普通に書いたらタスクシステムだけど?
オブジェクト指向プログラミングでは双方向リストをガチガチに手書きするのが 普通なんですかそうですか。 それってどこの世界のオブジェクト指向プログラミング?
リストかどうかって別に本質じゃないような。
>>2 を見る限りでは、個々のタスクはただ一つ、「実行しろ」というメッセージにしか
反応しないオブジェクトのように見えます。
よって、オブジェクト間の相互作用のための手段は非常に限られるので、
C風に「リストを舐めて構造体の中身を直接のぞく」コーディングが行われていたのでは
ないでしょうか。
それは「OO」じゃないですよね。人のものを勝手に見るのではなく、
人に頼む、尋ねるのがOOのスタイルです。
それとも、実際にはタスクは複数のメッセージを処理するためのディスパッチャ
や関数テーブルを持っていたのでしょうか?
それならば、貧弱な言語/環境であるがゆえに
自分で型タグやオブジェクトID、メソッドテーブルを実装しなければならなかった
というだけで、OOであると言っていいと思います。
そういう、Cでオブジェクト指向を実現するためのテクニック (有名どころではXtとかが使ってた)の真似事みたいなことは してるけど、オブジェクト指向とはどうにも認めがたい。 タスクとキューはis-a関係じゃないしな。 (オブジェクト指向をCで、的にはそういうことをしてる) 秀和の本でだいぶ古いけど、「C言語ゲームプログラミング」が それっぽいことをやっていたな。今見る価値がある本ではないが。
C++で普通に作ったらタスクシステムというものをわざわざ用意しなくてもいいのは事実。 単一のインスタンス構造に多数の関数ぶらさげてただけだし。
とんでもない神レベルの人ととんでもない馬鹿とが混在するのがこのスレの面白いところだな
>>429 あんまりその辺こだわってる奴ってもういないと思うぜ
オブジェクト指向云々とかあまり問題じゃない
たまに急に振る奴がいるけど別にクラスなんかあってもなくても同じ問題に直面する
ま、STGだったら自機、敵、弾とあってそれぞれをクラスっていうか
オブジェクトにして必要な分のインスタンスを用意する
ここまではみんないっしょだろうし別にC言語風味に構造体定義して
インスタンス作っても別に大して変わらない
問題はインスタンスの扱いだと思うんだよね
@void*で一括して配列用意して(リストでもいいけど)newで確保して型覚えておいてキャストして使うか
(これがタスクシステムっぽいやつ?)
A型ごとに配列定義して地道に作っていくか
(これが正統派?)
まあ、微妙な違いはあれどこの2つのどっちかになるだろね
前者だと必要なところどころで型キャストして戻さなきゃいけないけど一括して扱える
後者だと型ごとに同じ処理を何度も書かなきゃいけないけどキャストとかする必要がない
ただ、@の方法で組むと一括処理にばっかりこだわって引数とか省略して
グローバル変数使うようになってバグが増えるのはたしか
Aで組んだほうがソースもわかりやすい(と、俺は思う)
まあ、Aは面倒だけど正統派?そんなイメージ(ただ、面倒っていっても実装的に面倒って話だからねぇ・・・)
とまあ、オブジェクト指向云々関係ないでしょw
一括して扱える、同じコードで扱えるというのはCPUにとっては全くうれしくない
闇鍋循環リストに全てを放り込む
>>2 が何故詰んでいるかというと
弾も敵もパーティクルもひとつのリストにぶち込み同じコードでディスパッチするから。
分岐先はほぼ予測不可能。
>>2 はハードウェアに分岐先を絞り込むヒントを与えない。
サブルーチンアドレスはフラットなFSMの状態変数を兼ねているため種類は膨大。
CPU内蔵の分岐先バッファは役に立たない。ループする度に分岐先予測ミスが発生し
ペナルティを受ける。毎度毎度ご丁寧にサブルーチンアドレスを参照してディスパッチ
オブジェクトの種類順(弾、敵、プレイヤーなど)にソートしても根本的な解決には
ならない。なぜならオブジェクトの種類が同じであっても状態が違えばサブルーチン
アドレスは違うのだから
大昔に興味本位で測定した。AMDのAthlonXP(Bartonコア)で
>>2 を使うと速度は半分になった
大昔の、アドレッシングモードの貧相な(かなり特徴的な)8bitCPU、それにOBJやBGを
HSYNC毎にアナログ映像信号に変換してCRTに出力してくれるハードワイアードロジック回路
を搭載したカスタムボードを中途半端に意識して、当時の神の業などと詐称して喧伝してる時点で
クズの所業だが、実際に走らせるハードの特性を完全に無視してるのだから輪をかけてクズといえる
あ、クズの所業ってのは
>>2 の各URLの中の人のことじゃないからな
そこで解説されてる手法(?)を祀り上げてるカルト信者のことな
×HSYNC毎に ○ライン毎に
>>432 >大昔に興味本位で測定した。AMDのAthlonXP(Bartonコア)で
>>2 を使うと速度は半分になった
面白いですね。比較対象ってどんな組み方のものですか?
いまどきのオブジェクト指向のメッセージ処理で多用される間接ジャンプを、 現代のプロセッサでは性能が出ないとか扱き下ろしている人がいるのは このスレですか?
制御対象の計算粒度と数の特性ゆえに
>>2 は不利となる
パフォーマンスアナライザやプロファイラを使わず現実を見ずに先入観のみで
>>2 はきっと良いに違いないと盲信するならエンジニアではない
エセ科学信仰とかカルト信仰に溺れる知的弱者だ
>>431 @かAを採用するかは
ゲームによって臨機応変に対処すればいいんじゃないかな
どちらか絶対という事はないと思う
弾幕シューティングなどは明らかに後者が適していると思う
自分が最近作ったゲームはシーン(メニュー、コンフィグ、ゲームプレイなど)すら
オブジェクト化した@を採用してみた
>>437 > パフォーマンスアナライザやプロファイラを使わず現実を見ずに先入観のみで
>
>>2 はきっと良いに違いないと盲信するならエンジニアではない
> エセ科学信仰とかカルト信仰に溺れる知的弱者だ
あっそう。
> 制御対象の計算粒度と数の特性ゆえに
>>2 は不利となる
と断言する根拠を是非パフォーマンスアナライザやプロファイラで示してね。
性能「だけ」で何かを論じるのはおかしくね? 性能だけで論じるなら早い話がC++とか消えろって話だよね まあC++で書いてるなら ・擬似OOの実装を頑張らなくても、言語組み込み機能でタダで手に入る ・FSM作るのに関数ポインタのすげかえやマシンレベルの実行コード書き換えは 用いない ・何でもかんでも一個のリストに繋げない でしょうけれども
タスク同士で関連づけってどうやってる?
タスクシステムって1つのリスト限定なの? じゃあ俺のタスクシステムじゃなかったんだw
443 :
名前は開発中のものです。 :2009/01/05(月) 20:04:55 ID:iIypQ15B
>>438 そのごった煮状態ってなんかいいの?
ソース見る側としちゃ勘弁してほしい感じだけど
あけましておめでとうなのねー
>>387 IBMやDECのメインフレーム
↓
IBMのメインフレームやDECのミニコン
>>392 末尾のPDPミニコンの部分は記述ミス。ごめん
酩酊状態でタラタラ書いて校正せずにそのまま投げて寝ちゃった。
Whirlwind 1とSAGE防空システムに関しては英語文献が存在する
半世紀以上前の兵器システムの大凡の機能は教本に載っている。
どっかのmilドメインのサイトに幹部や技術系の中途採用試験(?)
対策用の参考資料が公開されている。詳細なパラメータは伏せてあるが
ぐぐればバシバシひっかかる
>>441 めっちゃくちゃ複雑じゃね?
そこまでなったらもうバグのオンパレード状態で収集つかない希ガス
>>438 マルチコアならAの方がいいと思う。
カプコンのMTフレームワークもそんな感じだったような。
>>443 ごった煮かもしれんが、並列処理ができるのがいいのよ
例えばタイトル画面表示中に、雪を降らせるなんてことも容易に実現できる
シーン式のゲームでもやろうと思えばできないことはないが面倒だろ
流石に全てのゲームジャンルでこの方法が適しているとは思わない
よくわからんが より抽象度の高い話をすれば 「全てのゲームオブジェクトについて、1フレーム内でiterativeに処理を行いたい」 あるいは 「全てのゲームオブジェクトに、同じメッセージをブロードキャストしたい」 ことがあるかどうか、という話じゃなかろーか あるのなら、それをリストに持っておくという実装もあるだろう ただ、抽象的には欲しいのは「リスト」ではなく「反復子」のはずなので、 実装はどうとでもできるように思える
>>448 ジョブエントリのリストをなめて順次処理(バッチ処理)するだけの
コードをもって、これは並列処理できるのだと豪語するか。これいかに
バッチ処理するしか能のない粗末なコードをポンと渡して
それをユーザーに無理矢理に逐次処理に使わせておいて
(逐次・並行処理に必要な仕組みは全てユーザーに丸投げておいて)
どうだ便利だろこのソロモンの指輪は、並列処理できるんだぜ、なんといういとしいしと・・・
と陶酔するのは技術屋としてどうなの
451 :
名前は開発中のものです。 :2009/01/06(火) 20:14:08 ID:dEvFXJdO
>>448 何を言ってるのか本気でわからない
Aで組んだことない?
仮にごった煮にしないでシーン?とゲームオブジェクトを別に管理したら
そっちのが扱いやすいだろ?
まとめるってことはアクセスするたびにそいつを判別するなんらかの仕組みが必要になるってことだし基本的には面倒が増えるよ
よほど一括で処理したいなにかがないとメリットはないと思うんだけど?
452 :
名前は開発中のものです。 :2009/01/06(火) 20:27:19 ID:a2y2pcid
結論: タスクシステム = カオスで美麗で斬新な60FPS紙芝居の夢を追及している奴専用
うおおおおお!
454 :
名前は開発中のものです。 :2009/01/06(火) 21:25:55 ID:c5JPjzC/
アクセスするたびに判別が必要ならそれはタスクシステムじゃないじゃん?C++あたりで組むなんちゃってタスクシステムだよ
タスクシステムが賛否両論なのはきっと分割の粒度・観点とかの違いですよ。ええ。 と思いついたので分類してみた。C++なんちゃってタスクシステムの話 1. マルチプロセス級:ゲームタスク、バッテリ残量監視タスク、... 2. マルチスレッド級:入力監視タスク、ゲーム処理タスク、描画処理タスク、鳴音タスク、... 3. 仮想関数インタフェース級:仮想update関数タスク、仮想move関数タスク、仮想draw関数タスク、仮想onkey関数タスク、... ・マルチプロセス級はほぼ関係無い処理だけど1台のPCにはともに入ってて欲しい位のとこで分割。.exe相当。 ・マルチスレッド級は決まりきったデータ通信が発生する程度に関係のある処理で分割。 通信を標準化するのもそう悪くないってとこで分けるのがミソかも(使ったこと無い俺)。 ・仮想関数インタフェース級は関係性とか概念の違いとか無視してたまたま関数インタフェースが似た感じっぽいところを探して 縦横無尽に共通化(抽象化)したもの。イベントハンドラの延長? 仮想関数インタフェース自体の仕様変更耐性とか再利用性が最悪。最悪。最悪。 それでいて性能も悪いかも。仮想関数ゆえにメモリキャッシュまわりとか? でも1画面ミニゲーム、画面エフェクト無し、凝ったギミック無しとかなら使い勝手良かったりする。 グローバル変数が通常サイズのクラス1個分に収まる程度までが利点を享受できる適正規模? 2と3の間にゲームオブジェクトとかシーンオブジェクトとかで分けた「クラス分け級」を入れようとしたけどなんか無理だった。 3番と同じ気がしてしっくりこなかった。
実際のゲームってどういう設計が使われてるんだ?
そもそも実際のゲームには何か共通した設計というものがあるのか?
その共通部分を抽出したものがタスクシステムだと思っていたんだが・・・
>>458 残念だがそのシナリオを選択する(orデカイ声で叫ぶ)のは遅すぎだな。というか無理がありすぎるな
>>2 (特にLogicianLord。拡散の元凶)と
>>2 を誤読したゲッベルス(松浦大先生。拡散させた偉大な男)
およびその忠実な部下(熱烈な読者)は、パンピー(neutralな人)たちに対して、奇妙なまでに一致した
偏った「とあるヘンテコリン実装」でもってタスクシステム(?)なるものを解説しネット・雑誌・書籍で
流布した。流布し尽くした。2009年現在、ネット上で
>>458 説を提唱するのは完全に手遅れといえる
タスクシステムという言葉は
>>2 に代表される、極めて特徴的な、奇異なまでに一致したヘンテコリン実装
「TCBがプライオリティをサブルーチンアドレスでディスパッチなのです><」
と完全に癒着している。もう引き剥がせない。OoOやマルチコアプロセッサの普及により
>>2 の実装が
obsoleteといえるならば、タスクシステムという呼称もまたこの味噌が付いた実装と共に成仏することになる
ところで次スレからは書籍もテンプレに入れようぜ、戦犯としてw Cマガ2004/12「ゲームのためのタスクシステム」松浦 単行本「シューティングゲームプログラミング」松浦 「Windowsプロフェッショナルゲームプログラミング2」やね これだけ?
>>459 じゃあ実際はどんなのが使われてるのか教えてください。
まったく違うものなんですか?
オブジェクトの種類ごとに持つデータが違うとか、
オブジェクトのデータのメモリ管理方法が違うとか、単一のリストじゃないとか、
そんなのは違いのうちに入らないと思うよ。
462 :
名前は開発中のものです。 :2009/01/07(水) 21:57:34 ID:dIlqsnyP
>>459 オイ、コラァ!
「ヘンテコリン」はお前とお前のキチガイじみた駄文だろーが
やたら人を見下した態度をとっているが、具体的論理展開は全く無し。
典型的なチキンだな。
>>457 シーン遷移とシーン管理。
あれはひとつクラス作って使い方を決めときゃどんなゲームでも鉄板では?
>>461 > じゃあ実際はどんなのが使われてるのか教えてください。
過去ログぐらい嫁
上で議論した気にってるやつはC++を使いこなせてない。 不必要に全部のオブジェクトを1個のリストに乗せる必要もない。 Cとは縁を切るところからはじめるんだ。
ただの倉庫ならどう作っても同じ 俺たちが作りたいのは電動車庫なんだ ボタンを押せば欲しいものが出てくる仕組み Javaではリスナー、Cではタスクシステム、C++ならコンテナ、DelphiならTList みんな完璧じゃないけど一工夫してある ただの線形リストとタスクシステムの違いはデータにメッセージを送ると能動的に処理が走ること プログラム側からデータを触ってやらないといけない線形リストだとデータがグローバル変数と 同じように扱われ保守性が落ちる タスクリストはただの線形リストではない
>>464 過去ログ読んでも同じような煽りしか無いじゃないかw
>>466 ただの線形リストでも要素がクラスインスタンスなら、その「タスクシステムの違い」ってのは
無くなるね。
469 :
名前は開発中のものです。 :2009/01/08(木) 07:36:03 ID:+JWwjlC0
>>466 何言ってるかわかんない
結局ありがちなごった煮リストなんだろ?
違いをもたせるなよ(笑)
>>469 おまえはまずデザパタとエフェクティブC++を読め。
ニートは金ないから本薦めるても無駄
デザパタは結城浩さんのがわかりやすくていいな
デザパタ自体俺の理論と合わない ああいうごちゃごちゃしたソース組んで悦に浸ってるのは下手っぴ
開発遅延中のAチーム(古参と愉快な仲間達)の応援要員としてマスターアップ直後の我々Bチームに 声がかかった。ババを引いたBチームのプログラマ2名(メインとサブ(私))はションボリしながら Aチームのサブプログラマから具体的な状況説明を受けている。開発の終盤になって再現性に乏しい メモリ破壊系のバグに悩まされてるのだという Aチームの仲良し古参二人組(ディレクターとメインプログラマ)は現在、開発の遅延に業を煮やした 営業部長に呼び出されて会議室でコッテリ絞られている Bメイン : 「全オブジェクトのヘッダにTCBとかいう管理領域があるな。前後ノードのアドレスに プライオリティに関数ポインタ、と…。呼び出される関数はreturnする前に管理領域の 関数ポインタを書き換えてるな。この関数群は人力で分割したジョブステップだな…すごい数だ」 私 .: 「ええ…」 そこへAチームの古参2名が戻ってきた Aメイン : 『使いたいか!テツオ(Bチームのメインプログラマ)!』 Bメイン : 「あ、どうも。使いたいも何も、もはやこれでいくしかないでしょう」 Aメイン : 『俺用に改良したタスクシステムだ、ピーキー過ぎてお前ら(Bチーム)には無理だよ!』 B全員: ('-`)。oO(こんなの使ってるほうが気が知れないよ) Bメイン : 「ところで、このオブジェクト群を呼び出してるモニタ側のソースも見せてもらえますか。」 Aメイン : 『ははっ!欲しけりゃな。お前もデカイのひとつ分捕りな!』 Bメイン : 「あ、いや、我々は社長の指示でこちらに来てます。休暇返上で急遽編入されました」 Aメイン : 『そんな話は聞いてないぞ!・・・くっ・・・しょうがない、これだよホレ!』 Bメイン : 「あの、僕のforeach一行じゃなくてその、モニタデバッガライブラリはどこですか。 つまりその、状況を監視・可視化してくれるツール群とかあるのでしょう?」 Aメイン : 『そんなもんねーよ!やっとモーターのコイルが暖まってきたところだぜ。デバッグ続けるぞお前等!』 Aスタッフ: 『オーッ!』『ダーッ!』 B全員: ('A`)。oO(・・・)
た
す
け
な
ん!?
>>471 読まずに役に立たないだと?
EffectiveC++が役に立たないというならおまえがC++をまったく
使えてないか完全に仕様を理解しているのどちらかでしかない。
C++を理解してデザパタイランというなら頭おかしい。
そのまま流用する必要は無いが、似たようなものを作ることになるのは目に見えてる。
>>483 >EffectiveC++が役に立たないというならおまえがC++をまったく
>C++を理解してデザパタイランというなら頭おかしい
これ好きな人ってだいたいセットで好きだよね
ただ、毎回「これ駄目っていう奴は馬鹿」みたいな雰囲気あるから言わなかったけど
正直、これ何がいいの?って思うようになった
俺もはじめの頃はC言語勉強してそのままC++に来て
仕事でC++で組んでるけど正直、クラスのメリットってよくわかんないんだよね
っていうかよくわからなくなった
ちなみにプログラム経験12〜13年
C言語とC++では仕事ではC++しか使ったことない
>C++を理解してデザパタイランというなら頭おかしい
そうか?
具体的に何がいいの?
俺は実際に使いたがる奴の行動見てたけど
なんでそんな無駄な構造にしたのか上司と衝突ばっかり起こしてて苦労が多そうな奴だなと思った
ダメなやつが使ってるからダメとかいったら何も残らないじゃない。 C言語ではダメなやつは苦労してないの? どう使えばよいか判らないといってると理解したけども、それでいいのかな? ユーザーがアクセスできない関数や変数を構造体にもてるだけでも十分メリットだと思うけど。 仕事で頼まれているモノはそうやって制限されてない? 使う側の工夫って使われる側には 見えないものなのよね。
あ、でもイラネって言ってるやつに無理に使ってもらう言語でもないな。 アセンブラに慣れてたら、Cを覚える必要ないわ。
>>485-486 なんの説明もしてないの自分でわかるよね?
他の奴等もだいたいこんな感じで逃げる
それかわけのわからんリンク貼って終了
書籍読んでもこれがこうよくなるって言ってもそのメリットがメリットに感じないし
C言語で書いたソースとC++で書いたソースを比べると
意外とC言語で書いたソースのほうがよく見えたりするよ
ていうかほとんどの場合、大して変わらない
それはどういう分野のソフトウェアを作ってるかによる。 例えばコールバックを多用するフレームワークを扱う場合はCでは面倒すぎる。 しかし昨今のコンシューマゲームでさえC++で開発が当たり前だ。 多分問題はオブジェクト指向原理主義的な野郎がいるってことだろう。
>>486 アクセス制限とデザパタとは関係ないような。
簡単に構造が説明できる(直感的に理解出来る)、非常に良く使われる構造である、統一的に機能を追加できる(またはそのようにする、そして楽)
のうち最低でもいずれかが実現できてることがデザパタの意義・・・かな?
逆に、これがどれも実現できてないのにデザパタ使いました、では
たとえパターンの構造通りになっていたり、また適切にアクセス制限がされていても本質からずれてる。
>>484 の>なんでそんな無駄な構造にしたのか上司と衝突ばっかり起こしてて苦労が多そうな奴だなと思った
ってのもなんか多そう。中途半端に理解したデザパタは一番の害悪。果たして他人にぱっと説明できるのかと。
と、中途半端にデザパタを読んだ自分が言ってみる。
デザパタか strategy? ああ、lambdaと高階関数に珍妙な名前つけた奴ね って奴にはまあ要らねーのかもな Cは面倒くさいだろ流石に と思うが、C++はC++で別の意味で面倒くさいんだよな 大して表現力ねーくせに無駄に複雑でな
>>466 流用性の無い足手まといイベントハンドラが増えただけにしか見えない。
あと戻り値はグローバル変数で渡すの?
//もともと必要な処理(ゲームオブジェクトクラス1個分)
class PlayerCharacter {
public:
bool init(const Chara_t *);
void update_frame(const Key_t *);
Point_t get_position(void);
CharaType_e get_charatype(void);
void release(void);
};
//以下タスクシステム用追加記述
typedef struct {
EventType_e type;
union {
Chara_t *init;
Key_t *update;
};
} Event_t;
typedef enum {
EVT_INIT,
EVT_UPDATE,
EVT_GETPOS,
EVT_GETCHARATYPE,
EVT_RELEASE,
} EventType_e;
自分はいわゆるタスクシステムがどんな構造なのかよくわからんので色々気になったので読んでみた。
>>2 のサイト先だと単なる動的配列(リスト構造)。別に『優先順位つきリスト構造』で説明が事足りる。
(全体長を固定する・またはノード自体をnewすることストを抑えたいならリスト構造2つ。事実上メモリ監視がついて回るのでこうなるが。)
で、色々読んでるといわゆるタスクシステムでは構造自体が重要なのではなく、メモリ使用の監視が主題ってのはなんとなくわかった。
だからメモリ監視にかかわる構造が必要でリスト構造に比べ多少複雑になってる、と。
つまりタスクシステムは
・ゲームを管理する構造△
・メモリの使用量など監視する構造○
タスクシステム自体の話は以上で完結するのよね。
タスク同士間の情報のやり取りやイベントハンドラ云々ってのはタスクシステム自体の話じゃなくて、
リスト構造で管理したときそれぞれのノード間のやりとりをどう管理するかって話でしょ?ふと思った。
仮にタスクシステムの主題がメモリ管理だとして、じゃあタスクシステムから主題じゃないはずのタスクの概念を取り除いたら後に残ったものは果たしてタスクシステム? メモリ管理システムでは? メモリ単位管理システムと処理単位管理システムがもともと癒着しているタスクシステムというものを選択した時点で、既にタスクとかノードという概念の使用を選択したことになっている。 ノードという概念の使用を強制されるならノード間のやりとりをどう管理するかの検討も必須の話かなぁとか。
>>493 もちろん。
ただ、どうもこのスレはタスクシステムのどこの仕様決まりきってて、決まりきってないどこを議論すべきなのかが混沌としてるから。
例えばこのスレでもずっとタスクシステムはリスト構造じゃねぇ、という意見が殆どを占めていて俺リスト乙。的な流れが多い。
確かにタスクシステムはリスト構造ではない、は正しいが、
ノード間のやり取りを議論しようとしたら、リスト構造を踏まえて、というかハードを意識しなければリスト構造なのでそこで語るのは正解。
つまりその手の話は俺リストの話をするべき。
>>494 「ノード間のやり取りを議論しようとするならその前にまずは俺リストの話をするべき。」
と受け取ったけど、ノードから見た通信インタフェースなんて
1.グローバル変数直接アクセス
2.メッセージングとかイベントハンドラ的な仕組み
3.move, update, drawなど数を絞った仮想関数インタフェース
の3つ位しか思いつかない。しかも2, 3は表現が違うだけでやってることは等価だと思うので実質1もしくは2・3の2種類のみ。
グローバル変数を使用禁止とするなら2・3の手法一択。
乱暴に言えば、タスクシステムの意義は2・3をゲームオブジェクト単位に導入することを強制する意義と等価だとして話を絞ってしまえば
どのようななんちゃって俺タスクシステム・俺リストを使っていようが全く関係無く話できると思う。っていうか話終わると思う。
もっとおおざっぱに行こうじぇ
だよなぁ・・・。 うちら2人だけじゃいまいち不安だが、タスクシステムに関することってそんな感じだよね。 ・タスクシステムはメモリ管理機能のある優先順位つきリスト構造 →メモリ管理およびリスト構造自体は決まりきった構造なので議論の余地なし。 →リスト構造のノード間のやり取りもメソッド等の使用であることは自明。 となるとかなりの部分はソースコードとして確定できそう。 で、まだでてきてない部分はこんなところか。 ・具体的なメソッドややり取りはどのように管理するべきか。 煮詰めりゃ最適解は出せそう。 ・タスクは別のタスクを追加しうる。生成したタスクはどうリスト構造に渡すか。 1、処理関数の戻り値として。追加の仕方はリスト構造自体を処理している誰かに委ねる。 2_A、リスト構造をタスク内でフィールドで保持。 2_B、処理関数がリスト構造自体を引数にとって内部で処理。 まぁ、2_Bが好きです、私は。 ・タスクは例えばどんな塊なのか、どんなインタフェースを持つべきなのか。 これは色々考えられそう。 シーン管理はリスト構造の外側でしてるとして、他は全部リスト構造内で処理していると思いたい。優先順位機能搭載してるわけだし。 こっちも煮詰めりゃある程度解がでそう。
いや、普通に C++ で仮想関数とコンテナ使って組めって。 もっと言うと、コンテナにする必要だって常にあるわけじゃない。 普通にメンバに持ってれば十分、っていうかそっちのほうがわかりやすいこともあるだろ。 そうでないなら、「タスクシステム」とやらで解決される問題を挙げてから話してくれないか?
>>496 俺はタスクシステムやめとけ派
タスク化をゲームオブジェクト単位に導入することを強制する意義は無いと思う。
メソッドの数を絞らなきゃいけないのがきつい。その最大最悪の制約の解消の目処も立ってないうちから
他の特徴を生かす方向を先に検討するとかは順序が違うと思う。
メモリ管理が重要じゃなくなったのならタスクシステムやめてそれ以前に戻るとか、
タスク化の適用対象をゲームオブジェクト以外にするとどうなるかとか考えて、まずは最大の制約を取り除くのが先じゃない?
ここがダメなら他の機能の利点なんて全部ふっとぶ凶悪な制約だと思うよ>通信の抽象化&全体共通化強制
例えばフレームワークの内部実装だけに適用する。
例えばもっとたくさん、座標管理(なんちゃって)タスクシステム、当たり判定管理(なんちゃって)タスクシステム、UI管理(なんちゃって)タスクシステム、...を作って組み合わせる。
例えばシーンと呼ばれる枠組みだけに適用してみるなどなど考えてくと、タスクシステムという形を残す必然性がなくなった。俺の場合。
というかC++はタスクシステムをさらに豪華にしたものだからC++を極めろ。
>>498 タスクを管理するクラスからの呼び出しだけ同じにしておけば、
別にメソッドの数を絞る必要はないと思うけど。
一番シンプルな形がいわゆるタスクシステムで、 それをそのまま使ってる人はいないんじゃないの?
>>498 ,501見たいな流れに持ってくから話題がループするんだろ
>>498 色々勘違いしてるし、いってる意味がわからん部分がある。
1、タスクシステムの是非についてまったく話していない。結局タスクシステムの定番の形がどんな形なのかというのが知りたい。まだ定番の形は決定できる部分があるだろう。
2、順序が違う周りは何がどう違うのかさっぱりわからない。少なくともoopの設計の仕方ならば、オブジェクトを先になんとなくまとめ、メッセージを決めていくのもありなのだが。
それともいきなりソースコードレベルでびしっと決めるつもりだろうか?
3、ゲームオブジェクトでは抽象的過ぎる。それに含まれる具体例が最低3つぐらいあげてほしい。この定義により恐ろしいほど処理の範疇が変わる。
4、メモリ管理周りの話。何度もいうように、リスト構造のやり取りについて語ってる。タスクシステムについて語っていないと思う。まぁこちらの言い方も悪かったか。
それはそうとして、最後の話の構造、あれ思ったより拡張性低くね?仕様変更に迫られたときに耐えられないべ。
本来プログラムの構造はマトリョーシカ状にして、設計の修正が必要な場合の修正項目を最小限に抑えるべきだと思うんだが、ありゃ管理クラスが色々やりすぎてる気がする。
>>500 よくやる。つまりnode.run()みたいに一枚はさんでから、具体的な処理構造を実行するってことか。
>>501 多分この意見もかなりこのスレの流れでループしてるんじゃ無かろうか。だからもう少し話を進めて確定したい。
ID:JZO5iyFx = ID:YXD0YS+N なのか?なんか至る所がおかしいな
>>492 >
>>2 のサイト先だと単なる動的配列(リスト構造)
どこが動的配列なのか分からない。インターフェースも実装も動的配列ではない。
>構造自体が重要なのではなく、メモリ使用の監視が主題ってのはなんとなくわかった。
>だからメモリ監視にかかわる構造が必要でリスト構造に比べ多少複雑になってる、と。
悪いが意味が分からない。何を読んでその結論に至ったのか、アンカーを全部列挙してくれ
>つまりタスクシステムは
>
>・ゲームを管理する構造△
>・メモリの使用量など監視する構造○
>
>タスクシステム自体の話は以上で完結するのよね。
ならばそれはただのメモリプールでありアロケータの一種であり、それ以上でもそれ以下でもなく
タスクシステムなどと名乗る理由は微塵もないわけだから、お前は速やかにタスクシステムという
呼称を使うのをやめたらどうなのか。なぜタスクシステムという何処の馬の骨かも分からない田舎侍の
ローカル用語に固執するのか理解できない
>>492 >タスク同士間の情報のやり取りやイベントハンドラ云々ってのはタスクシステム自体の話じゃなくて、
>リスト構造で管理したときそれぞれのノード間のやりとりをどう管理するかって話でしょ?ふと思った
悪いが何を言ってるのか全く意味が分からない。
マルチタスクシステムにおいてはタスクとはジョブステップでありシステム内部の処理単位だ。
「システム内部の処理単位」同士の通信手段が提供するのはマルチタスクシステムにおいては当然のこと。
にもかかわらずタスクシステムとかいうものにおいては
「それは関係ないから関係ないからタスクシステム自体の話じゃないから」という。全部ユーザーに丸投げか。
ならばなんなのそれは。ってことだな。ジョブエントリのリストをなめてディスパッチしていく。ただの順次処理、
バッチ処理するだけの仕組み。それだけ。後は全部ユーザーまかせ
【タスクシステム自体の話は以上で完結するのよね】
>>493 >ただ、どうもこのスレはタスクシステムのどこの仕様決まりきってて、決まりきってないどこを議論すべきなのかが混沌としてるから。
だから
>>2 だろ。書籍なら逆引き本だろ。現場を経験した人間が解説してる唯一の文献だ。
>例えばこのスレでもずっとタスクシステムはリスト構造じゃねぇ、という意見が殆どを占めていて
>確かにタスクシステムはリスト構造ではない、は正しいが、
どこをどう見ても
>>2 が使ってるのはintrusiveな(侵入式の、内部収納の)連結リストだが
リスト構造じゃねぇとかほざいてる知的障害のアンカー全部列挙してくれ
506 :
名前は開発中のものです。 :2009/01/12(月) 20:39:17 ID:t/KJWxMy
それでいいんじゃないの? そもそもタスクシステムが何のために出てきたのか、目的がなんなのかで話がぜんぜん異なる。
×
>>493 ○
>>494 >ノード間のやり取りを議論しようとしたら、リスト構造を踏まえて、というかハードを意識しなければリスト構造なのでそこで語るのは正解。
>つまりその手の話は俺リストの話をするべき。
ハードを意識するも糞も何も
>>2 も逆引き本も連結リスト使ってるだろ。
正解も何も連結リストでしか語ってねーよ。馬鹿みたいに何でもかんでも線形リスト。木もグラフもない。
連結リストを使ってないタスクシステムに関する資料、文献がどこにあるのか教えてくれ
>>496 >・タスクシステムはメモリ管理機能のある優先順位つきリスト構造
>→メモリ管理およびリスト構造自体は決まりきった構造なので議論の余地なし。
>→リスト構造のノード間のやり取りもメソッド等の使用であることは自明。
>
>となるとかなりの部分はソースコードとして確定できそう。
【メモリ管理機能のある優先順位つきリスト構造】
それが現代のビデオゲームの中核部として【自己主張する】に相応しいメカニズムだと思う?
そういうものにタスクシステムって名前は釣り合うと思う?名は体を成してると思う?
そもそも名前が致命的に腐ってると思わない?タスク-システムだよ?
仕事システム?システム内部の処理単位システム?ハァ?って感じだよな
マルチでもなければシングルでもない。何なのお前?何がしたいの?って感じしない?
ワークロードをモニターできないしデッドラインに間に合うようにスケジューリングする仕組みもない
ゴミだろ。
>>496 >・具体的なメソッドややり取りはどのように管理するべきか。
>煮詰めりゃ最適解は出せそう。
おそらく出ない。タスクシステムが常に敗北するのは、あらゆる粒度の処理に対して同じインターフェースどころか
同じ実装でもって全て解決してしまおうとする、極めて理想主義・原理主義的なアホ共の玩具に成り下がったことに
由来する。処理の粒度に応じて解は異なるということに気づかない限り、ハードを無視した机上の議論で終わる
例えば細粒度な処理をディスパッチするためにタスク厨はなぜかサブルーチンアドレス経由で処理を呼ぶ。
現代においてはちょっと珍しい発想だ。本来ならステートメントを使うべきでありこれはif文やswitch-case文。
タスク厨が完全に時代に乗り遅れたフェードアウトオヤジ状態であることが完全確実に決定的なのは
関数アドレス経由の関数呼び出しが常に最高に速いと思い込んでることだ
一事が万事、それ以外のことも8bitマイコン時代の常識を現代に適用とするはず
ところでOO厨とタスク厨の親和性が極めて高いというのも面白いよね。静的型付け言語のセオリーをまっこうから
否定する
>>2 を、OO厨は「斬新だ」と感じるらしい。理解できない世界だよね
>>504 こっちも話の進め方が悪かったけど、まったくといっていいほどこっちのいいたい事、主題にしたいことが伝わってないことはわかる。
俺説明下手かなぁ・・・。
とりあえず技術的な部分だけ。
・動的配列は、要素数が自由に変更できる配列である。リスト構造は動的配列とみなせる。と思ってるが。
・メモリ云々に関して。
>>2 の4番目のサイトとか?つまり当時クラスを使用しない実装において、ワークエリア固定は、ただの副産物だったのか。ということ。
他は、まぁ読み返してこっちがいいたかったことを察してくれ、多分それで解決する。めんどい。
>>509 そこに誰もがうすうす感じてるから進まないんだろう、話が。
あらゆる処理、をかなり狭めることで最適解というか妥協解は示せると思うよ。
>>510 動的配列を実装する選択肢のひとつは連結リストを使うこと
だが、
>>2 のインターフェースは動的配列ではない。
リストだが動的配列ではない
タスクシステムという言葉を使い続ける限り、そいつの背後には
>>2 に代表される
時代錯誤的なヘッポコプログラムの影が常に付きまとう。これはもはや不可避だ
このレッテル貼りを早い段階から否定しなかった「タスクシステム大好き人間」の
落ち度だ。(おそらく彼らは
>>2 が現実と乖離してるということに気づいていなかった)
>>2 から脱却した議論がしたいならタスクシステムという言葉を使うのをやめ
このスレを使うのをやめるべきだ。構造スレなら俺も別人になれる
>>512 補足
実装においても、当時のハードウェア構成から固定長メモリプールが多用された
ゆえに実装レベルでも動的配列とはいえない。ヒープという概念がないRAMちょびっとの
ハードで動的配列を提供することに意味はないし、
>>2 もやってない
>>496 >まぁ、2_Bが好きです、私は。
それは構わない。
が、システムと銘打ってるにも関わらず、ユーザーにシステム側の実装を周知しなければならない。
つまりユーザーは、自分が記述したジョブをシステム内部の処理単位であるタスクなるものに分割し
それが格納されるシステム内部のコンテナが連結リストであることを知る必要があり、更にそれを
直接に操作することを強要される
2_Bなら、システムが提供するのはintrusiveな連結リストのコンテナだけであり、後の全ては
ユーザーの創意工夫で構築される。「俺はシステムだ!」と主張させるには無理がある
>>500 絞る必要は無いんだけど、結果的に意図せずとも数絞っちゃうというか。
メソッド変更の度に全タスク修正するの面倒になってそのうち必要最小限でいいやとか思い始める。
「update(), draw()だけあればいいや。おっなんか洗練された感じ?」とか。で1〜3つ位に絞られる。
>>516 非常に的を射ているような気がする
無理になんでもかんでも共用し一般化しようとする結果、肉も骨も削る人間がいる。
直行性だの何だのは結構なのだが、それを過剰に追求するからおかしくなる。
肉も骨も削って何がなんだか分からなくなったものを作り上げた人間は
>>2 にシンパシーを感じ、これを愛するのではないか
「俺は間違ってない!過去のナ○コの偉大なプログラマーも俺と同じことやってる!」
いいえ、それは違います。ということは今更指摘するまでもないよな
それはクラスに型があるが故の制限だろ? タスクシステムに責任を押し付ける筋合いの物じゃないと思うが……。 クラスでやるにしてもEventListener interface風に実装する等回避策はある。 (タスクシステムはクラスと違って記憶領域と関数が1対1で対応する必要もないし) どうも副次的な制限ばかりでタスクシステムの本題に入らないな。 行き当たりばったりに実装してみて行き詰ったら「タスクシステムが悪い」となっている風に見える。 タスクシステムは何をするべきか、何をさせるべきか。 それをキッチリ決めてからじゃないと 実装してから利点を探すような真似は生産的じゃないと思うんだぜ? タスク管理の実装に必要なものは ・ ・ ・ だから〜という実装は有効 みたいにしようぜ 必要は発明の母っていうし新タスクシステム開発できたら素敵やん?
ところでDOOMやQUAKE等一線級のゲームソースがオープンソースとして公開されているけど タスク管理はどのような実装になっているんだぜ?
>>518 2009年現在、ネット上ではタスクシステムというキーワードは
>>2 に代表される
珍妙実装と絡み合ってる。実装ありきだ。これを今更否定するのは至難だと思うよ
彼らは何故か2DSTGで、通常弾も敵も何もかも全部同じリストにぶち込んで舐める。
否定するならば、Cマガジンで松浦大先生(タスクシステムエヴァンジェリスト)が
下々の民草に対して「プロのゲームプログラマはこうやってるのぜ!」と絶叫した
(2001年だっけ?)時点で、大々的に反抗作戦を展開するべきだったな
>>520 当時は「なんだこいつ馬鹿じゃね? こんなの誰も信じねーよ」と思ってて
こんなに厨が拡大再生産されるとは微塵も思ってなかったんだ…
>>502 1.タスクシステムの是非 = タスク化をゲームオブジェクト単位に導入することを強制することの是非
ちょっと分かりにくいか。
タスクシステムの是非 = 既定のメソッド2〜3個だけしかゲームオブジェクトに使用できない呪いを自らに課す是非
でも可。1クラス決まった型のメソッド3個までしか使えないんだよ?極悪すぐる。この1点を問題ないと言い切れるならもう習うより慣れろかもね。
後付けだけど条件。グローバル変数は無し。引数で全変数一気渡しも無し。
2.見た目がどんなにおいしいそうなものでも、腐ってたら食べないでしょ?
その腐ってる点を指摘したつもり。どれだけあなたがおいしいところの話をしようよといっても腐ってると分かってる人はそんな気になれない。
どうせ食べたら腹壊すって分かってて無駄だから。ふぐの毒に置き換えてもいい。
それでもそのおいしそうなものについて議論したいならまずは腐ってるとこを取り除く努力をして安全性をアピールするのが先。おいしいとこ議論はその後、の順の方が人が集まりやすい。
>少なくともoopの設計の仕方ならば、オブジェクトを先になんとなくまとめ、メッセージを決めていくのもありなのだが。
タスク、リスト構造のやり取り等を先になんとなく以上の熱意で明確化しようとしている矛盾
3.STGで言えば自機、敵機、自機弾、敵機弾、ボス、背景オブジェクト、...
ミニゲーム1つでいいから作ってみると、なるほど使ってみたくなる言葉
4.
>>504 さんの言う通り
>本来プログラムの構造はマトリョーシカ状にして、
外から3番目の人形と8番目、あっ違った、今は9番目の人形同士で情報やりとりしたいんだ。
ってデザイナーに言われたらどうするの? 4-8番目の人形に専用のメソッド用意して穴あけるの? グローバル変数で空間ワープするの? いや、この設計では無理って言うの?
ライブラリラッパー関数までだよ、それは。俺はシーンクラスに色々やらせる方がかっこいいと思う。ダサかっこいい。昔ながらのKISS.
説明下手は少しあるけどまぁ伝わる。それよりも聞き下手。
察した上でそれを主題にすべきでないと理由付きで伝えてくれてる親切な人だらけだよ。今日は。人多いっしょ? 俺もびっくりだこれ。
多分それ気づかないと解決しない。
>>516 えーと、俺が言いたいのは、管理クラスから呼ばれるメソッドさえ共通にしておけば、
それぞれのクラス毎に、それぞれのクラス特有のメソッドを追加しても問題ないってことなんだけど。
1つのクラスに修正が生じたからといって、全てのクラスを修正する必要はないよ。
524 :
名前は開発中のものです。 :2009/01/12(月) 23:24:44 ID:QJH1xa2h
現状は
>>498 が言うことがすべてだよなぁ
折角わかりやすいのに
>>502 の的外れな指摘がなーんか嫌な感じだよ
意味がわからない
お前の言ってることのが意味分からないよ
ほぼ共通してる認識をわざとはぐらかしてる
525 :
名前は開発中のものです。 :2009/01/12(月) 23:28:36 ID:QJH1xa2h
>>523 ごった煮状態のインスタンスの型をどうやって判別する気?
ダウンキャストか型タグでしょ
×ダウンキャスト ○dynamic_cast<> ね、すまん
>>512 ,514
把握。でもリスト長は変わってるから動的配列と呼べなくも無いと思うが・・・まぁどうでもいいや。重要ではない。
ところでa2k+/ICzよ、自分でいってるじゃないか。
>>513 で。当時制限があった、ゆえにメモリ管理が必要だった。それがタスクシステムだ。時代錯誤だ。
だから『タスクシステムの主題がメモリ管理』は外れちゃいないと思う。
>>515 で。タスクシステムからメモリ管理を取り除いたら、リスト構造しか残らない。タスクシステム特有の部分は議論する余地がない。
だから俺リストについて語るべきなんじゃん。
>>520 で。結局タスクシステムって言葉を使い続ける限り、メモリ管理+リスト構造しないとだめなんだよ。
だからその片割れであるリスト構造について語ろうっていってるわけだよ。
(まー自分がゲーム作る場合、メモリ管理とかいらんからほんとにリスト構造だけだけど。利用できそうな方向に話を持っていきたいだけ。)
ごめんなさい、結論としては具体的なノードのやり取りとか、どんな処理がノードとなるのか、とかそんな話がしたかっただけです。
>>525 最初から、必要とするクラスのメンバ変数にしておけばいい。
一旦抽象化してリストに入れたものを取り出して型を判別する必要はないと思う。
まあ、管理クラスに探してもらってdynamic_castでもいいけど。
というかa2k+/ICzの言うタスク厨ってここにいるの? いないもの相手に頑張っても意味ないよ
495と498もつながってるから466からじゃね? 9uopTdxyとT/lMy2Wwは俺
533 :
497 :2009/01/13(火) 00:21:26 ID:R/Mlk7FJ
いわんこっちゃない。 大事なことだからもっかい言うぜ。 「タスクシステム」とやらで解決される問題を挙げてから話してくれないか?
534 :
名前は開発中のものです。 :2009/01/13(火) 00:25:10 ID:rWb6fNii
>>529 リストでも配列でもいいけど
それが何か判別できなきゃ処理できないじゃん
535 :
名前は開発中のものです。 :2009/01/13(火) 00:32:09 ID:rWb6fNii
>>533 何もないな
updateとかdrawをまとめて呼びたいとかその程度のくだらない仕組み
解決される問題はupdateとかdrawをゲームオブジェクトごとに書かなくて済むただそれだけ
>>534 何が言いたいのか分からない。
管理クラスはupdate関数を呼ぶだけだし、呼ばれたほうは自分自身が何者かを知ってる。
何もないわけないだろう。ないならこんなに大騒ぎするはずないじゃん
かつての制限ありまくりのハードではっての前提ならなんかいいことあるんじゃないの?
539 :
名前は開発中のものです。 :2009/01/13(火) 01:01:17 ID:rWb6fNii
>>534 は?
ごった煮リストから判別して特有の処理を呼び出す話をしてるんだよ
なんで共通のupdateの話をするの?
540 :
名前は開発中のものです。 :2009/01/13(火) 01:05:48 ID:rWb6fNii
>>537 ー538
あると思うならそれをいうべきだろ
ただ、あるんじゃないの?って認識の人が書き込む場面ではないだろ
>>539 必要な分はリストに入れる前にあらかじめメンバ変数として持っておくんだよ。
わざわざリストから取り出す必要はないし、型を改めて判別する必要もない。
リストから取り出すならdynamic_castだとも書いてある。
同じこと書かせないでくれ。分からない部分があるならそこをピンポイントで聞いてくれよ。
>>540 いやおれは
>>497 と同意見なだけだが
何をするためのものか整理してから話したら?ってこと
>>530 タスク厨を定義するにはタスクシステムを定義しなければならないのだが
>2にしても書籍にしてもゆらぎが大きく、絶対的な権威も不在、
且つ個々の理解もばらばらでコンセンサスがとれないのが現状。
>520は松浦大先生を権威として祭上げたいみたいだけど
その話題に触れているのは今のところ>521だけ。
>>530 いるいる。たーくさんいる。ここ5〜6年内はゲー専新卒の子だけじゃなくて
四大工学系新卒の子が説明会や集団面接で
>>2 を熱く語ったりする。臆面もなく。
他の子が目を白黒させてる。
沢山 : oO(え、ナニそれ?何?それ知ってないとヤヴァイ?あとでググろっと)
少数 : oO(プギャー)
など、様々な表情が観察できて面白い
まぁ最終段階で残る子はこんなもんこれっぽっちも知らなかったりするし
知ってても「だからナニ?」みたいな子ばっかだから
新人研修の段階で更生させる手間はゼロだしどうでもいいんだけどね
>>543 松浦御大の功績は認めるべきだよ。Cマガにおける特集記事とその後の連載記事
そして禿パブから出版された数々の書籍、これらによってタスクシステムという
呼称をその実装と共に伝道し、素人プログラマの間で爆発的に普及させた
それ以前にタスクシステムなんて単語を駆使する学生や子供は稀有だった。
X68界隈の草の根BBSみたいな閉じた狭いコミュニティでヲタ同士でコソコソ
やってただけ
松浦御大の教えに染まった子が増えたことで2DSTGを作る子も増えた。まぁ全てが悪いわけじゃない
>>544 の前半
ニュースの映像でさえ本物かどうか疑わないといけない時代に
唐突にそんな逸話だけ出されてもねえ。
前にオカルトとかエセ科学とか言ってる人がいたからじゃないけど
検証可能性を担保できる話をしようよ。
546 :
名前は開発中のものです。 :2009/01/13(火) 07:57:07 ID:rWb6fNii
>>541 わかんねぇ奴だな
たとえばクラスAとBがあったときクラスBだけがもつmoveBメソッドを呼びたかったと
したらまずごった煮リストの取り出した要素がクラスAかBか判断する必要があんだろが
じゃねーとBにしかないメソッドなんだから呼べないだろ
>>546 dynamic_cast の意味しらべるのオススメ
まあ、ゲーム開発だと RTTI はたいてい切ってるんだけどね
ちょっと訂正。 ゲーム開発 → コンソールでのゲーム開発 360, PS3 世代ならもういいかも。
タスクシステムなコードを昔見たとき char data[256]; DataA *p = (Data A *)data; こんな感じで領域確保してキャストして利用してたのは C++から入った自分としてはへーと思ったな
頭悪い子のほうの撲殺天使の人暇だったんだな
>>539 >ごった煮リストから判別して特有の処理を呼び出す話をしてるんだよ
>なんで共通のupdateの話をするの?
>>546 >したらまずごった煮リストの取り出した要素がクラスAかBか
>判断する必要があんだろが
>じゃねーとBにしかないメソッドなんだから呼べないだろ
リストの個々のオブジェクトはupdateメソッドを保有している
で、そのupdateメソッドは自分が何者か知っているわけで
わざわざ型の判別をする必要はないだろ
オブジェクト間の相互作用の話をしているんだと思うよ 相手が自明ならキャストは普通は要らない 敵の中で〜なもの、といった風に条件付でスキャンしたいのなら 型の判別とキャストがいるだろう 代数データ型が使える言語ならもっと型安全にヴァリアントな型を 扱えるが、C++なら結局はキャストするしかない で、「ごった煮リスト」とは言うが、実際には例えばTaskだのGameObjectだの というインタフェースを継承したクラス群になるわけだろうから 型を判別する方法なんぞいくらでもある 言語組み込み機能なら、何度も言われているようにdynamic_cast そうでなければ、例えば自分が誰かを示すメソッド等を、統一したインタフェース として持たせればいいだけだ なんも難しい話じゃないはずだが
>>546 こっちの話はすぐわかるからいける。多分
>>551 はリストのノード自体が多態性してる。
ゲームオブジェクトをupdateのみを持つ別のクラスで包むか、
ゲームオブジェクト自体がupdateをもち、オーバーライドしてupdate内で自分のメンバを呼んでいるんだろう。
ところで、タスクですべきことがゲームオブジェクトのupdate、positionの取得、など個々の場合
>>491 みたいなEventTaskでやるべきことを判別する必要がある・・・で合ってる?
オブジェクトのグループ/階層がはっきりしているのなら 少なくともリストよりはツリーがいいように思う 全体も走査できるし 特定のグループに限定したいのなら、サブツリーを走査すればいい フラットなリストでmap/filterを毎度やるよりは効率的だろう 多態とダウンキャストは、C++でOOやるなら宿命みたいなもんだから、 そこを突っ込んでみても仕方がない
555 :
名前は開発中のものです。 :2009/01/13(火) 12:52:30 ID:rWb6fNii
型の判別が必要ってのはいいかい? 全く同じメソッドもってたって型を判別する必要あるな 自機、敵、自弾、敵弾の内、敵と敵弾だけに絞りたい場合なんかも型を判別する必要あるよな こんときやらなきゃいけないのは一斉検索だろ? んで処理をするもんとしないもんといちいち判別しながら処理しないといけないわけよ 何が言いたいかってーと ごった煮である利点は少ないよねってことよ ツリーも惜しいけどそれでもやはり意味がない 続く
>>555 「どうやって型を判別するんだよ」とか言ってるから
型なんか簡単に判別できるだろ、とだけ言っただけで
別にタスクシステムとやらを褒め称えてるわけじゃないんだけどね
ツリーも、少なくともフラットなリストよりはマシだろうってだけね
>ごった煮である利点は少ないよねってことよ それはゲームによるでしょ 過去に作った横スクロールアクション、RPGでごった煮採用だが、全然困らん 逆にオブジェクトごとにリスト用意するのはメンドイ ま、弾幕シューティングしか作らないような御仁は分けた方がいいのかもしれないな
なんとなくすれちがいポイントがみえてきた ・入り口のメソッドだけあわせておけばあとはオブジェクトが自発的に処理すりゃいいだろ派 ・オブジェクトの相互作用はまとめてかいたほうがいいだろJK。 そうすると個別のオブジェクトの区別が必要だから1つに束ねると効率悪いだろ。 こんなかんじ? まあ、両者ごもっとも。 俺なら今ならふつうに富豪的アプローチだな。 一連の処理を行う構造と、検索・相互作用用の構造は別の形でもったほうがいい。 ・大枠は前者的思想でつくってメインループを回す。 イベント処理>状態変更>画面更新 とかそういう単位 ・親に、自分以外のオブジェクトの検索をしやすいような辞書的構造を 別途整備する。オブジェクトはこれを参照して自分の動作を決める ・複雑な処理は親の専用のロジックで辞書を直接総なめするような操作を 作って、これ自体を処理オブジェクトとして一連の処理に投入するようにする こんなかんじ?
>>546 なんで答えてることを無視して同じ質問するの?
C++を知らないのかな? もう一回だけ説明するよ。
これでわからなければC++の入門サイトでも見てくれ。
リストから取り出す必要があるなら、何度も言うようにdynamic_castな。
void update(TaskManager &tm) {
ClassB *b = dynamic_cast<ClassB *>(tm.getTask("ClassB"));
if(b) b->moveB();
}
>たとえばクラスAとBがあったときクラスBだけがもつmoveBメソッドを呼びたかったと
で、こういう場合、クラスBとそれを使うクラスの間には何らかの関係があるわけだから、
クラスB(へのポインタ)を、『タスクリストに追加する前に』、それを必要とするクラスのメンバ変数にするんだよ。
class Hoge : public Task {
private:
ClassB *b;
protected:
void update(TaskManager &tm) {
if(!b) {
b = new ClassB();
tm.addTask(b);
}
b->moveB();
}
};
bの初期化のタイミング(Hogeのコンストラクタか、updateを最初に呼ばれたときか、
別にinit関数を作るか……)は好きにしてくれ。
以降のレスは呼んでる暇がないので、既にフォローされてたらごめん。
>>559 型判定の方法は論点じゃないから dynamic_cast の話は放置しておk
561 :
名前は開発中のものです。 :2009/01/13(火) 20:22:42 ID:rWb6fNii
まともな人がいて助かる 型の判別方法は問題じゃ無い 続き 結局、型は判別しなきゃいけないんだよ だったら別にまとめることなくね? まとめた処理がしたかったらそんときだけ必要なもんだけ入れたポインタリストでも作ればいいんじゃないの? わざわざごった煮にする意味がわかんないね 次の行動にターゲットが必要になった時点で共通仕様の縛りのせいでかなり悩まなきゃいけないじゃん グローバル変数使ったり、生きてるか死んでるか不明のポインタをゲームオブジェクトが保持るとかいう かなりアフォな構造になるじゃん
もうさ、タスクシステム勉強会を開いてそこで議論したほうがよくね?
ごった煮にしなければいけないなんて決まりはない。 リスト、ツリーに色々種類があるのと同じ。 使いやすいように各自工夫すればいい。
>>563 結局、タスクシステムって何? どこまで「工夫」したら、タスクシステムじゃなくなるの?
単なる名称だからタスクシステムでもなんでもいいんだよね。 最近はフレームワークとか言ってる。
引数なくしてグローバル変数やシングルトンでやり取りされるのが一番困る バグったら最後 誰もバグとれないくせに使い続けるんだもんなぁ・・・
567 :
名前は開発中のものです。 :2009/01/14(水) 00:48:21 ID:uviUrAzN
上位階層の改修を前提にするのは賛成しかねる
568 :
523とか :2009/01/14(水) 01:11:41 ID:j8O4TfZ6
判別方法は関係ない?
>>525 ,534,539,546
俺には、一貫して型の判別方法を聞かれているようにしか読めなかったんだが。
じゃあ、俺は一体何について聞かれていたんだ?
ポリモーフィズムのポの字も知らない馬鹿はスルーしろってことじゃねえの
>>525 ,534,539,546
特有の処理についてもっとkwsk
>>566 >引数なくしてグローバル変数やシングルトンでやり取りされるのが一番困る
何をやり取りされるのが困るかkwsk
>>568 うーん・・・たぶん。こういうことだろう。
>>561 は、たとえば衝突判定とかするときに、結局型判定(というか属性判定)するじゃない。
たとえば自機と敵機が同じリスト構造内にいても、自機⇔敵機衝突判定するときに、
リスト構造内を検索、その際にゲームオブジェクトが自機なのか敵機なのか属性判定する事は避けられない。
といいたいんだと思う。
だから多態性とか継承とかとはまったく別の問題だよーってことじゃね。
>>558 見てわかった。
>・入り口のメソッドだけあわせておけばあとはオブジェクトが自発的に処理すりゃいいだろ派
これが俺や
>>568 が言ってたこと。
>・オブジェクトの相互作用はまとめてかいたほうがいいだろJK。
そうすると個別のオブジェクトの区別が必要だから1つに束ねると効率悪いだろ。
これが
>>561 がいってたこと。
たぶん。
・敵リスト
・自機リスト
・背景リスト
みたく属性ごとにリストを分ければ、衝突判定等の記述がシンプルにかける。全部ごった煮にするとかけねーよってことか。
なんだか同じことの繰り返しで対話にならないっぽいので、
他の人から何もなければひとまずこれで引くわ。
>>555 >自機、敵、自弾、敵弾の内、敵と敵弾だけに絞りたい場合なんかも型を判別する必要あるよな
最初から敵を管理するクラス、敵弾を管理するクラスを用意すればいい。
「タスク」レベルまで抽象化したものをわざわざ判別して取り出す必要はない。
使用頻度が低いとか、必要かどうか前もって分からないとかだったら、
後から取り出しても別に構わないとは思うけど。
>>561 >まとめた処理がしたかったらそんときだけ必要なもんだけ入れたポインタリストでも作ればいいんじゃないの?
これはそのとおり。タスクリストは「毎フレーム(優先度順に)処理関数を呼ぶ」
「親子関係を持ち、親が死ぬと子も死ぬ」処理を行うためのもの。
(メモリ管理云々は、個人的にはタスク処理とは別の話だと思う)
積極的に他の目的のために使おうとするからおかしなことになる。
>>561 の後半は何が言いたいのかまったく分からん。
「次の行動にターゲットが必要にな」るってのはどういうこと?
生きてるか死んでるか不明のポインタって、まだ必要なポインタが
解放されてるかもってこと? それは構造関係なくただのバグじゃん。
ああ、念の為書いとくけど、別にタスクシステムを(他の方法より)
優れた方法だと言うつもりもないし、ましてや薦める意図はまったくないよ。
既に他の方法を確立しているならそれを使えばいいし、初心者なら
テクニックに走らず、ゲームの構造をそのままクラスにしたほうがいいと思う。
ただ、自分で制限つけたり、他の目的に使おうとしたりして、
「使いにくい」「利点がない」ってのはどうかと思っただけ。
>>571 >>525 がそういう意味だとは思えないし、もしそうだったとしても、それについては
「それを必要とするクラスのメンバ変数として持てば、判別の必要はない」と何度も答えてる。
もちろん、「敵の種類」とかの判別は必要になるだろうけど、
それは「ごった煮リストからの判別」とはまったく別の話だよね。
つか、「個別のオブジェクトの区別が必要だから1つに束ねると効率悪い」はそもそも順番が逆で、
同じように扱いたいから1つに束ねたのに、個別のオブジェクトに戻そうとするから効率が悪くなる。
それに、オブジェクトが自発的に(見えるように)updateするのと、そのupdate関数内で
関連するオブジェクトを(個別のオブジェクトとして)利用するのは、別に背反することじゃない。
>>572-573 長w
駄目だよ
レス自体誰も前提にもってない話が勝手に常識のように入ってるし
自分の妄想だけで話進めて俺と会話するつもりもない感じ
いいたいことまとめないとレスつけないよ
だいたい判別する必要あるじゃん 何がねぇんだよ オブジェクト内に別オブジェクトの型なんかごちゃまぜにアクセスできたら そもそもカプセル化も糞もねーじゃん 自機クラス内で敵クラスにも弾クラスにもアクセスできる時点でオブジェクト指向破綻してんじゃん もう言ってることおかしい
>>575 コンポジットというものがあってな
もうしょうがなからぺにっぺにっでにっしんさせるね
OOスタイルで構文解析機を書けば「ごった煮」なASTになるわけだが…… DOMぐらい知らんのか? まあ、dynamic_castすら知らないぐらいだから仕方がないね
ごめん俺DOMナメてたわ リックドム。なんちて
dynamic_cast未サポートのコンパイラが普通にあることすら知らないぐらいだから話合わないのも仕方がないね
dynamic_castが使えないのなら、型タグに相当するものを実装すればいいだけだよ Cのunionならいつもやることだろうに、アホか
え? そんなコンパイラをお使いで? 相当のマゾでつね D どんなもんだい O オレは M マゾっ気100%だぜ
>>580 union使ったら型システムに穴が空くジャン
できることなら使わずきれいに済ませたいジャン
>>581 それはさすがに釣る気みなぎりすぎwww
583 :
名前は開発中のものです。 :2009/01/14(水) 20:15:23 ID:HVlDjb3P
また、全然関係無いレスばっかりつける ちょっと前も型の判別方法なんて問題じゃないってのに キャストキャスト連呼してる恥ずかしい奴がいたけどにたようなのしかいないのか?
>>583 いや、それは
>>525 が「型の判別方法わからん」とか言ってるから
何人かが教えてやってただけだろ……
>>582 Cなら仕方ないだろ
unionの類を使わずにLispインタプリタでも組んでみたらどうだ?
C++にしても、代数データ型はないのだし、ポリモーフィズムの手段が
継承なのだから、ダウンキャストはある程度宿命であり必要悪だ
無論、それを最低限に抑えることが望ましいがな
586 :
名前は開発中のものです。 :2009/01/14(水) 20:58:47 ID:HVlDjb3P
>>585 はぁ?なんのための必要悪なの?
そもそもベタ書きでゲーム作ったことあるのかすら怪しいね
だってゲーム作って複雑になるところとキャスト云々って全然関係無いもん
>>583 ごめんよ
以前dynamic_castが使えない環境でゲームプログラム書くことがあったから動的キャスト必須は移植性を考えるとありえないという頭があった。
あとunionは宗教上の理由で滅多に使えないので型タグ相当も小資源で作ることができない。これは俺のポリシー。
ライブラリ内なら使うかも。
そういう条件下だと性能の良し悪しとか概念の洗練度なんて議論とは全く別次元で、簡単に一意に解答が定まってしまう。
「オブジェクト群を1つに束ねることは不可能」
って。
そういう立場の人もいるかもと頭の片隅にでも置いとくと怒りが安らぐかもしれない。
union使える宗教の人とかdynamic_cast使える環境が大前提の人にとっては有用な議論なんだろうなぁ、きっと。
>>584 それは
>>523 が特有のメソッドを追加しても問題ないっていうから
特有のメソッドを読んだら型判定が必要になって
ごった煮リストにしておくメリットねーぞって話のつもりだった
が、読み返してみるとたしかに型判定知らないアフォみたいだなwスマンコw
でも問題はそこじゃないんだ
>>572 > これはそのとおり。タスクリストは「毎フレーム(優先度順に)処理関数を呼ぶ」
> 「親子関係を持ち、親が死ぬと子も死ぬ」処理を行うためのもの。
それって、単に子インスタンスをメンバ変数で持つだけで良いんじゃね?
class Enemy;
class Player;
class Scene {
Player player_;
std::list<Enemy> enemies_;
public:
void exec() { PlayerExec(); EnemyExec(); HitCheck(); ... }
};
タスクって何?
>>587 なんだか俺がdynamic_cast云々の発端っぽいので一応言っておくけど。
dynamic_castは「型の判別方法」を聞かれたから答えただけで、
必要なものは元の型のままメンバ変数として持てば、
通常、dynamic_castが必要になる場面はないよ。
>>589 それでいいよ。
別にそういう書き方を否定してないよね。
>>590 >589 で十分だと言いながら、 >572 を読む限りあんたは何かの目的を持って
ごった煮リストにつなぐ(ことがある)んだろ?
しかもそれが初心者にはおすすめできない「テクニック」であると言うじゃないか。
それは何のためなのか、どんなメリットがあるのか、あるいはどんな問題が解決されるのか
ってのがこのスレ的には主題だと思うんだ。
592 :
名前は開発中のものです。 :2009/01/15(木) 20:17:43 ID:M6pRbS27
まず、タスクシステムによって解決する問題をはっきりさせるほうが先じゃね?
裏山で出土した石器を明日の仕事でどうやって使うか話し合うスレはここですか?
>>594 いいえ。そういう話し合いを望んでいる人間で、現状で生存確認が取れてるのは数人だけ。
筆頭は確定君。「確定」で検索しなさい。
村人達がとっくの昔に遺棄し朽ち果て忘れ去られたはずの山道、というか舗装もされてない獣道。
ある日ハーメルンの笛吹き男が現れこの獣道の入り口だけをお色直しして純真向くな都会の若者達を
招き入れるようになりました。
「さぁおいで。夢の国へ続く道だよ。通行料代わりに私の本を買ってきなさいピーヒャララ♪」
その獣道は先に進めば進むほど細く険しくなる茨の道。落石や崩落で寸断され死人も出た危険な道。
今では村には国道や高速道路や鉄道が整備されトンネルで一直線に隣村や町に行けるようになり
その危険な獣道を使う村人はもういません。沢山の若者達が嬉しそうに入っていく様子を村人達は
とても不思議そうに眺めていました。「都会の若者が考えるこたわがんねなぁ」
ある村人は興味本位でその疑問を入山する若者に問いかけました。すると若者は快活に答えました
「え、知らないんですか。可搬性と拡張性に優れた素晴らしい世界へ続く道ですよ。これ確定です」
村人は意味がよくわかりませんでしたが、戻ってきたら旅の感想を聞かせてくれると若者が約束
してくれたので楽しみに待つことにしました。しかし待てど待てどその純真無垢な若者が帰ってくる
ことはありませんでした
597 :
名前は開発中のものです。 :2009/01/16(金) 00:30:47 ID:J+ghoaMj
タスクシステムって名前じゃなけりゃ こんなにまで議論の対象にならなかったと思うんだけどなぁ 名前を初めて聞いたときどんなすごいシステムなんだろうと思ったが、 詳細見てしょぼさ加減に思わず吹いたよwww タスクと聞くとOSをイメージしてしまうし、 システムとかたいそうな名前付けてる割には パターンやイディオムレベルの構造だしな
>>597 そういうことなんだけど、それを理解できずに荒らす人がいるんだよね。
だからそういう人をこのスレに閉じ込めてるんでしょ。
タスク信者を荒らし認定すんなカス
600 :
名前は開発中のものです。 :2009/01/16(金) 01:07:52 ID:Fyhxl6Le
タスク信者乙
601 :
名前は開発中のものです。 :2009/01/16(金) 07:37:53 ID:V+6xOIyR
タスク信者は プログラム言語に型なんかないほうが扱いやすいって言ってるのと同じだよね 実際、タスクシステム使って組むと思いっきり型邪魔だしね
タスク信者はあいかわらずソースを出さないので相手にしない
603 :
名前は開発中のものです。 :2009/01/16(金) 09:33:58 ID:u7vFuzDx
タスクシステムに似た仰々しい名前を教えるね 「コントロールブレイク」 ミンナニハナイショダヨ
>>596 >今では村には国道や高速道路や鉄道が整備されトンネルで一直線に隣村や町に行けるようになり
詳しく
1ヵ月ぐらい住み着いてる抽象的な話で煙に巻く君だ。 放置推奨。
托鉢癖の乞食には酷く癇に障るものらしいよ
??? ???
型安全なタスクシステムってC++のtemplateとか使えばできるかな? 無理?
>>609 templateはあくまでコンパイル時の・静的なポリモーフィズムが実現できるだけでしょ
>>609 >>2 じゃなくて(ごった煮にはしないで)素直に組む場合
型別で管理クラスを作るのにテンプレートは便利
レスThanks. 利点ありそうなので書いてみた。 でもtemplate自体さっき調べながら書いたのでコンパイル通るかすら怪しい。そこは注意。 あとタスク化の対象をオブジェクトではなく関係性にしてみた。「自機」、「自機弾」でなく、「自機弾生成」のくくり。動詞? typedef struct { std::list<CPlayer *> *m_player; std::list<CEnemy *> *m_enemy1; } PlayerEnemy1_t; std::list<CPlayer *> m_player; std::list<CEnemy1 *> m_enemy1; std::list<CBulletPlayer1 *> m_bullet_player1; std::list<CBulletEnemy1 *> m_bullet_enemy1; PlayerEnemy_t m_player_enemy; Task<PlayerEnemy_t, (*collisionPlayerEnemy)(PlayerEnemy_t *)> m_task_collision_player_enemy; Task<PlayerPBullet1_t, (*generatePlayerBullet)(PlayerPBullet1_t *)> m_task_generate_playerbullet; template<class Tdata, class Talgorithm> class Task : public ITask { private: Tdata *m_data; Talgorithm *m_algorithm; public: void set(Tdata *data, Talgorithm *algorithm) { m_data = data; m_algorithm = algorithm; } virtual void update(void) { m_algorithm(m_data); } };
>>613 通りすがりだけど、そのlistが持っているCPlayer*とかは誰が解体するの?
普通のタスクシステムなら、タスクシステムが解体を保証するだろうし、
さもなくば、auto_ptrなりshared_ptrなりを使うのが普通だと思うのだが。
解体責任を明確にする上でもタスクシステムは有効なのだが、
そのことは理解してる?
あと、C++なんだから、structをtypedefするのやめようよ。
それとtemplateの部分、何がしたいのかわからない。
615 :
名前は開発中のものです。 :2009/01/17(土) 16:06:08 ID:WEwgflmD
吹きそうにやるからタスクシステムって言うのやめてくれwww
>>613 ちょっとまて
それが何を目的としたどんな問題を解消するのか
それを宣言してから先へ進んでくれ
>>615 話が進まなくなる。
なにか名前がないと会話できないだろ。
フレームワークだけ先に浸透しちゃったから、それぞれが勝手に名前付けてるんだよ。
>>2の人たちは、できるだけ統一したいから、多数派っぽいタスクシステムって名前を使ってるだけじゃないかな。
>>613 ESPを使ったところ、処理単位の粒度を粗くしようとしているのかな。と読み取ってみた
>>614 まぁ
>>613 のコードがスマポ使ったほうがよさげというのは同意だけど
俺のESPによるとそれは枝葉末節の話のような気がする
ところでその枝葉末節について思うこと
>普通のタスクシステムなら、タスクシステムが解体を保証するだろうし
>(中略)解体責任を明確にする上でもタスクシステムは有効
@キミのタスクシステムというのが何なのか知らんので
⇒
>>2 みたいにひとつの循環リストに全オブジェクトをぶち込んでると仮定
A解体というのが具体的に何(ゲーム上の生死なのかリソース開放なのか)か知らんので
⇒リソース(メモリ、OSから発行されたデバイス等のインターフェース、etc)の開放と仮定
B
>>2 の循環リストが何でソートされてんのか知らんので
⇒差分処理の順序(
>>2 のプライオリティ?)でソートされてると仮定
以上の仮定のもとでレスを書くと、キミは
「全部入りの循環リストを舐めれば全リソースを開放できるから
>>2 は解体を保証してるのだ」と言ってるのね。
ところで
>>2 の循環リストは第一義にはゲームの処理の手続き、差分処理の順序を表わすものなんだよね?
単に全部入りのコンテナだからという理由でリソース開放用にこれを流用するの?
>>614 常々思うのは、何で
>>2 は(
>>2 を擁護する人は)ひとつの循環リストを特別にユーザーオブジェクトに侵入させ
ごった煮の全部入りとし、更にはこれにいろんな責任を与えようとするのかってこと。そこに合理的理由はあるのかな。
単なる貧乏性なんじゃないのかと思うんだよね
順序と集合が共通だから、ということで複数の責任・役目を与えるのはまぁいいよ
でも
>>614 みたいに第一義にはゲーム更新処理用のコンテナをリソース管理の責任も与えようとするなら
集合は共通してるけど順序は違うんだよね。ソートしなおすんだろうね
あと別件で、以前に
>>2 は親が死ねば子も死ぬという死の連鎖を表現できるという人がいたけど
これを直接に表現するのは
>>2 の侵入式の循環リストではなく、ユーザー側で用意する親子関係を表わすツリーだよね。
で、必要ならそのツリーをトラバースした順序をもとに
>>2 の侵入式循環リストの当該箇所をソートしなおすんでしょう?
>>2 は親子の死の連鎖とかぶっちゃけ関係ないよね。ユーザー側に丸投げしてるでしょ
何で普通の(つまり外部収納の)コンテナを役割毎に持たないの?リソース管理用ならリソース管理用
更新手続き用なら更新手続き用、親子関係なら親子関係用、機能を明確に分離できずに無闇に
癒着させるってのは、硬直して首が回らなくなる危険を犯すってことだよ。経験に裏打ちされたものがない人に
こういう貧乏j根性主導のコンテナ共同利用はオススメできないよ
わけわかんなくなるから想像や仮定を前提にして話を進めようとするのはやめてくれ。 わからないことは素直に聞けよ。答えが返ってこなければそこまでの話だ。
> @キミのタスクシステムというのが何なのか知らんので
> ⇒
>>2 みたいにひとつの循環リストに全オブジェクトをぶち込んでると仮定
> A解体というのが具体的に何(ゲーム上の生死なのかリソース開放なのか)か知らんので
> ⇒リソース(メモリ、OSから発行されたデバイス等のインターフェース、etc)の開放と仮定
> B
>>2 の循環リストが何でソートされてんのか知らんので
> ⇒差分処理の順序(
>>2 のプライオリティ?)でソートされてると仮定
とはいえこれは妥当な仮定だわな
解体はゲーム上のオブジェクトの死ではなくリソース開放だろ
>>2 のプライオリティの使い方は処理順だ
これも一致してる
ま、仮定するまでもなく的中だろう
なんで妥当なの? オブジェクトごとのリスト、優先度なし、ソートなし。 これはタスクシステムと言ってはいけない?
>>622 普通は優先度ありはデフォっぽい気がするけどねぇ
じゃないと全てを入れるリスト構造がまともに動くとは思えないし。
全部まとめるから優先順位が必要になるんだよなぁ・・・
>>622 で?なんなのその聳え立つ一本糞コレクションは。
それでナニすんのおめぇ?食うの?食えんのか?え、食うの?
もう今となってはさ、タスクシステムとか言ってる奴って
こういうカスばっかなんだな。認めざるを得ないわ
>>621 いやいや >613 が >2 を理解しているとは限らないだろ。
少なくとも >613 からはそれは読み取れん。
むしろ >613 が >2 を理解している信者であるという仮定は >613 のコードからすると大胆すぎる。
そもそもこれまでの流れを見る限り信者もアンチもこのスレの住人が >2 を理解してるとは思えん。
俺もよくわからん。書いてることバラバラじゃねえか。
待てなんだこの図は どこにこんなんあるんだw
>>614 for (i = m_player.begin(); i != m_player.end(); i++) {
if (i->is_need_delete()) {
delete(*i);
i = m_player.remove(i); //うろ覚え
}
}
こんな感じで呼び出し側が解体を保証することとする。責任は明確。
スマートポインタは.exeの終了時にdeleteし忘れてるのを勝手にやってくれるという程度のイメージしかない。
そんなのOSにまかせとけばいいと思う俺は趣味ゲームプログラマ。
templateの部分はTaskクラスをvirtualでなくtemplateで書いてみたというもの。
ゲームオブジェクトとタスクの癒着を引き剥がすことが出来てる感じがしないかと。
やりたいことはタスク化の焦点をオブジェクトだけでなく、関係性にも拡張したかった、んだと思う。
俺フィーリングで動いてるから自分でも明確な理由分からないww
ITaskはおまけ。無くてもいいのかも。
C++なんちゃってタスクシステムのを残しただけ。class ITask {public:virtual update(void)=0;};
>>623 言葉が悪かった。
オブジェクトの種類ごとにリストを分けるだけで、単純なものなら優先度が不要になる。
シューティングの弾だったらほとんど生成順に描画で問題ないでしょ。
>>618 > ところで
>>2 の循環リストは第一義にはゲームの処理の手続き、差分処理の順序を表わすものなんだよね?
> 単に全部入りのコンテナだからという理由でリソース開放用にこれを流用するの?
解体責任が分散すると解体忘れにつながるからC/C++で書くなら
(auto_ptrやshared_ptrを使わずに愚直に書くなら)全部入りのコンテナか、
あるいは、その周辺が解体責任を担うように設計するのは普通だと思うんだが。
>>619 は一理あるので否定はしない。
ただ、(俺が作ってきた)タスクシステムは、タスクの生成/解体まで
タスクシステムがその権限/責任を持っていて、タスクデバッガのようなものを
attachさせて、実行時に走っているタスクをwatchしたり、実行時にbreakを
かけて特定のタスクを生成を指示したりすることが出来る。
まあ、これは「タスクシステム」ではなく、「タスクに関するフレームワーク」と
呼ぶべきかも知れない。ともかく、これが使い回しが利いてとても便利なんだ。
特定のタスクがイレギュラーな構造になっているとこのフレームワークの
恩恵を受けられない。それが嫌なんだな。
まあいいや。たぶんこのスレの趣旨とは違うんだろうから、おとなしくROMっとくよ。
>>629 >for (i = m_player.begin(); i != m_player.end(); i++) {
> if (i->is_need_delete()) {
> delete(*i);
> i = m_player.remove(i); //うろ覚え
> }
>}
>こんな感じで呼び出し側が解体を保証することとする。責任は明確。
1. そのコード、呼び出し側に持つとゲームを作るごとに
コピペなりなんなりで書かないといけないんじゃ?
2. 親タスクが子タスクのstd::list<Child*>のようなものを持っていると、
親が死んだ子に対してアクセスしてしまう。これをどうやって防ぐの?
>>616 説明書き無くてスマソ。
Taskクラスをvirtualでなくtemplateで書いてみたらこうなったというもの。
目的ありきではなく、まず作っちゃったんだけど何かに使えないかなこれという感じ。
C++なんちゃってタスクシステムの欠点を解消できないかなと。
>>618 ESPどうも。そうっすね。処理単位の粒度関係で影響ありそう。
generatePlayerBullet()なんて本当に出来たらかっこいいと思いません?(というかもうやってる?) 多分内容はこう。
typedef struct {
std::list<CPlayer *> *player;
std::list<CBulletPlayer1 *> *bullet_player1;
} PlayerPBullet1_t;
void generatePlayerBullet(PlayerPBullet1_t *data)
{
for (i = data->player->begin(); i != data->player->end(); i++) {
if (i->need_generate_bullet1()) {
data->bullet_player1->push_back(new CBulletPlayer1(i->get_pos(), i->get_target_dir()));
}
}
}
void 1フレーム分の処理(void)
{
//Task<...>のsetは前もってどっかでやっとく
//ここで入力関係update
...
m_task_collision_player_enemy.update();
m_task_generate_playerbullet.update();
...
//ここで描画、サウンド関係update。(例)m_task_draw_player.update();
}
※update群はC++なんちゃってタスクシステム(ITask)でまとめるも良し。そのままでも良し。
>>628 私の趣味の画像でございます
お気にさわるようでしたら削除いたします
>>631 ごめん。相手を見誤ってた。俺は
>>618 で
ID:8YYLBgEpの言うタスクシステム=
>>2 と仮定してたんだけどこれ間違いだね。
ID:8YYLBgEpの言うタスクシステムはゲームオブジェクトのモニタでもあるんだね。
(というかモニタ機能がむしろメインだろうと思う)
>解体責任が分散すると解体忘れにつながるからC/C++で書くなら
>(auto_ptrやshared_ptrを使わずに愚直に書くなら)全部入りのコンテナか、
>あるいは、その周辺が解体責任を担うように設計するのは普通だと思うんだが。
これは同意。上記の仮定間違いに伴うすれ違いだった。具体的には
>>2 の場合、ユーザーは(ゲームオブジェクトのジョブを書く奴は)TCBにかなり自由に頻繁に触るので
TCBのパラメータが全く信用ならない⇒解体には別の、外部収納のコンテナが欲しい
(デバッグ用モニタとしては別のアドレス空間に欲しい)という趣旨で書いたんだ
>ただ、(俺が作ってきた)タスクシステムは、(後略)
全くもって同意。異論を挟む余地がない
以下蛇足
モニタ機能の記述が完全に欠如したタスクシステム解説のWEBページや書籍があまりに多いので、俺は
「世間ではこういうものがタスクシステムと呼ばれるようになったのか。じゃあタスクシステムという言葉を
職場内で使うのも止めよう。」ということでタスクシステムという呼称を使うのやめちゃった
タスクシステム信者にお伺いしたいことがございますが class A; class B { A *obj; }; が理解できますか?
モニタ機能って、なんか、わざわざ発生させた問題に対策を用意して 対策を売り込むとか、マッチポンプじゃないの? 普通に組んで、普通にデバッガ使うのと何が違うの?
>>635 了解しました。あなたとは同業者っぽいね。
>>636 コンポジションがどうかしたの?
まぁタスクシステム(
>>2 )信者じゃないから反応する理由はないんだけど
>>2 とは全く異なる、自社製のマイクロカーネルがタスクシステムと呼ばれてたもんでね
まぁ、どうでもいい田舎モンのローカル用語だから実態が違うのは当然だし
世間様の前で「これがタスクシステムだ!」なんて絶叫したりしないから俺は心配ない。はず
>>640 いや、なに
一流と呼ばれている方が私のコンポジションだらけのソースを
わけわからんとおっしゃいまして
彼はタスクシステムを理解できていたようで
疑問に思っていた次第であります
>>638 GoFのデザパタに関する知識は後付け・付け焼刃のハンパなもんだけど
揚げ足をとられてる実感が全くないので詳しく頼むわ
>>642 >呼称を使うのやめちゃった
最後まで読んでおりませんでした
私の論理的ミスです
申し訳ございません
実際、
>>619 はタスクシステムで組んでるとぶち当たる問題を的確に表現してるな
これを問題と意識せずに華麗にスルーしてしまうとタスクシステムを使い続けるようになるんだろう
まずいものはまずいとちゃんと認識したほうがいい
>>632 1. Yes. コピペ上等の精神で乗り切る、はダメ?
まぁ呼び出し側にdelete書く利点も探せば結構あるかと。もし欠点以上に利点探せたならラッキー。
例えば、
・こっちのがクラスの単体テストしやすそう
・deleteを一気に1フレームでやらずに残り時間に応じて分散させたい場合に
ゲームオブジェクト内のステートだけではタイミングを判断できないかもしれない。
でも呼び出し側でなら制御できるかも。
・複数行の見栄えが嫌なら関数化してお勧め処理として一緒に付けとけば軽減可能
2. 子タスクは無しの方向で。全部同列、同位の存在にする。
タスクという概念上はどれも全部「処理」。親子の概念なし。
処理順序はupdate()の記述順序で指定。
親子タスクは無いけれど親子データとか親子オブジェクトは欲しい。
それは単なるオブジェクト間の通信に帰着可能だと思うので
下のupdate()群のように等価に置き換えできないでしょか。
void 1フレーム分の処理(void)
{
...
m_task_update_player.update();
m_task_follow_player_option.update(); // player->isdead()ならoption->set_state(PLAYER_DEAD);したり
m_task_follow_player_lasershot.update()
m_task_delete_player.update();
m_task_delete_option.update(); //need_delete()ならdeleteしたり
m_task_delete_lasershot.update();
...
m_task_draw_option.update(); //もしくは死亡アニメーション終わったらdeleteしたり
...
}
>>645 > 1. Yes. コピペ上等の精神で乗り切る、はダメ?
・類似コードなのに再利用できない
・同じ処理内容のコードが複数の箇所に現われる
のは、プログラムの書き方がおかしいからだということを
もっと意識しておいたほうがいいと思うよ。
> ・deleteを一気に1フレームでやらずに残り時間に応じて分散させたい場合に
> ゲームオブジェクト内のステートだけではタイミングを判断できないかもしれない。
それは、まったく逆だと思う。deleteしているのが一カ所に集中していれば、1フレームでN回以上は
deleteしないという処理を書くのはたやすいけど、deleteしている部分が分散していたら
そんな処理を書くのはとても面倒。
> 親子タスクは無いけれど親子データとか親子オブジェクトは欲しい。
> それは単なるオブジェクト間の通信に帰着可能だと思うので
> 下のupdate()群のように等価に置き換えできないでしょか。
そのコードのどこにオブジェクト間の通信のコードがあるのかわからない。
あと、その1フレーム分の処理、updateを書き忘れたり、新たに動かすものが増えるごとに
新たにその関数のなかにupdateを呼び出すコードを追加しなくてはならない。
これだといわゆる従来のタスクシステム(
>>2 )と比べても大幅に劣っている。
そういえば
>>613 でゲームオブジェクトとからタスクを分離させた着想の元は
>>553 のレスの
>ゲームオブジェクトをupdateのみを持つ別のクラスで包む
だったかも。
それと「template使ったら何かがきれいに書けるかも!」という思い付きがなぜか混ざった。
昨晩は酔っ払っておりました。
>>646 >・類似コードなのに再利用できない
>・同じ処理内容のコードが複数の箇所に現われる
・類似コードは単に似てるだけ。同一のコードではないので再利用できないのは当然。
・同じ処理内容のコードは関数化するべき。これはその通りです。そうするべきです。
関数化した後、その関数の呼び出し記述がゲーム毎に存在するのはOKですよね?
> それは、まったく逆だと思う。deleteしているのが一カ所に集中していれば、1フレームでN回以上は
> deleteしないという処理を書くのはたやすいけど、deleteしている部分が分散していたら
> そんな処理を書くのはとても面倒。
呼び出し側に様々なオブジェクトのdeleteがまとまって延々と記述されているのに対し、
複数のゲームオブジェクト内にdeleteが記述されるためにdeleteが分散しているしていると認識することも可能。
分散しているのはどっちかという認識が私と違っているようです。
> そのコードのどこにオブジェクト間の通信のコードがあるのかわからない。
m_task_follow_player_option.update(); // player->isdead()ならoption->set_state(PLAYER_DEAD);したり
m_task_follow_player_lasershot.update()
> あと、その1フレーム分の処理、updateを書き忘れたり、新たに動かすものが増えるごとに
> 新たにその関数のなかにupdateを呼び出すコードを追加しなくてはならない。
update書き忘れはnew TaskA()の書き忘れと同等のものです。バグです。数が増えたことを問題視している?
・update呼び出しコードを挿入
・tskmgr->add(new TaskA(), PRIORITY_A)というコードを挿入
コードの追加はどちらも必須。しかしPRIORITY_Aという優先度の定義が数値だとして既に
#define PRIORITY_CHARA 123
#define PRIORITY_BG 124
と定義されていた場合、
#define PRIORITY_A 123.5
はできないのでは? 運用でカバー?
>>648 は何が言いたいのかよくわかんないのでもう帰ることにするよ。最後まで相手できなくてごめんね。
2chを久々に見にきて、たまたま面白そうな話題だったからちょっと首つっこんでみただけなんだ。
しかし2chって面白いね。ID:1fr/EvSg みたいなベテランプログラマと、 ID:OfSsMU0e みたいな
ド素人(気を悪くしたらごめんね)とがひとつのスレで議論してたりするんだね。新鮮だった。
俺は大手ゲーム会社でかれこれ15年ぐらいプログラム書いてきてるんだけど、従来のタスクシステム(
>>2 )は
出発点としては意味があると思うね。それをフレームワークとしてどう発展させていくかという問題はあるけどね。
>>649 整理して言えずごめんなさいね
ド素人には気は悪くしましたがタスクデバッガのようなものとか私作れないのでまぁ仕方ない。
何年も実業務に携わってる人にケチつける気は毛頭ないです。
生存タスクを列挙したりとか、生成・解放のログを取ったりとかは普通にやるよね。 それ以上のことは普通のデバッガで十分じゃない?
>>609 デザインパターンのオブザーバーとかをスマートポインタあたりでくるんで使うと
だいたい良い感じにそうなると思うよ。
C++の機能を使えばタスクシステムとやらを作っても危険性はまったくなくなるのだが
どうもC言語から離れたくない人が多いみたいだ。
>>652 >C++の機能を使えばタスクシステムとやらを作っても危険性はまったくなくなるのだが
危険性じゃなくて意味がないってほうが言いたいけどな
ほとんどROMってるだけだけど、たまには俺も口を出そう。 何でも同等に扱うごった煮的アプローチが批判されてばかりいるけど、 昔のゲームみたいに敵/味方とはっきり分かれているのは別として 最近の自由度が高いゲームだと元々システム的にあらゆるオブジェクトが ほとんど対等な扱いだったりするから、そういう状況で使うのは有りだと思う。 PCのゲームだとデータ改竄で普段なら有りえない現象を見たりできるけど、 実装がごった煮っぽい現象はたまに見るよ。
>>654 はぁ?そりゃゲームの仕様の話だろ?
なにいってんだよ
お前、いままでで一番ピントがズレてんだよ
たまに口挟むなんてやらないほうがいいぞ
ここで煽りあって議論してる奴等もピントはずしたらどうなるか
一応わかってレスつけてるからレスを返せるんだぞ
えらそうw
>>655 でもゲームの仕様、つまり実装目標を無視して構造を考えるって、極めて無意味っぽくね?
手段と目的が完全に逆転してる希ガス
>>657 は?仕様がごった煮だからごった煮でいいって?
アフォでしょ?相手にもしたくない驚愕すべきレベルだな
ここでタスクシステムの議論してる人らってそのタスクシステムをなにに使おうとしてるの? 何が便利になるの?
>>653 どっちにしろ出来上がったものはタスクを処理するシステムになる。意味がないもくそも
タスクシステムって名称を貶めたいだけだろうアホめ。
デザインパターンの本を読めばどう便利なのか書いてある
>>662 デザインパターン自体なにも利点のないものが入ってるし疑わしい
そもそもそれがゲームに適用できるのかどうかって検証も必要になると余計ややこしい
やっぱりたとえ話じゃなんの説明にもならないんだよ
説明する内容が複雑でその構造を説明するときにたとえ話はいいかも知れないけどね
この場合デザインパターンの例は役に立たないと思う
デザインパターンの使い方が判らんのか?
665 :
名前は開発中のものです。 :2009/01/20(火) 06:01:22 ID:KNFisALs
正確にはデザインパターンのゲームプログラムへの適用が適切がどうかわからない デザインパターンはゲームの本じゃないからね 使ってる奴が間違った適用をしてたら意味ないし
なんでこのスレの人は抽象的な話しばっかするんだろう
ゲームプログラムとプログラムが違うと思ってる時点でへんな先入観を持っている。 デザインパターンのオブザーバーとストラテジーはまんまタスクシステムだよ。
668 :
名前は開発中のものです。 :2009/01/20(火) 23:06:24 ID:KNFisALs
オブザーバーとストラテジー? 両方とも目的と適用可能性の説明がゲームオブジェクトとかけ離れていて全く理解不能 どこがわからないとかじゃなくて共通箇所が欠片もみあたらない パターン間違ってない?
いろんなオブジェクトにメッセージなげて処理してもらって 状況に応じてそれぞれのオブジェクトの中身が変わるんだろ?
>>667 デザパタを理解してないヤシは出てくんな。
671 :
名前は開発中のものです。 :2009/01/21(水) 00:55:30 ID:HcSl8u5v
オブザーバっていわゆるコールバックなんだぜ こいつらがいっているタスクシステムにコールバックなんて単語でてきたか?
>>2 はVSYNC信号をトリガーに循環リストの全要素・全ゲームオブジェクトを総ナメしてupdate() 関数を呼び出す
ここで注意が必要なのは「システム」を自称する
>>2 は何故か一本糞の循環リストしか持ってないっつーこと。
そしてVSYNC信号が発生する度に、相手の都合なんてお構いなしに、呼び出される必要があろうが無かろうが関係なく
【問答無用でとりあえず全てのゲームオブジェクトを叩き起こす】
「ねーVSYNC信号発生したよ?起きなさいよ。やることない?やることない?あるならやれよ早く。無いなら処理返せよ早くホラ」
これポーリング処理。一本糞リストしか持たない
>>2 がオブザーバ・パターンだとか言ってる時点で何かがおかしい
chain of responsibilityがタスクシステム(に使われている)と言うなら
まだほんの少しはわかるが、
>>667 はただの馬鹿にしか見えない。
675 :
名前は開発中のものです。 :2009/01/21(水) 07:32:47 ID:8MTRCkQM
どうやらデザパタはただのノイズだったようで
677 :
名前は開発中のものです。 :2009/01/21(水) 12:44:37 ID:8MTRCkQM
引用して何がいいたいのかわからない 見えるなんて表現してる人の言葉使わずにデザパタからきっちり説明したまえ 第一そのリンク先の人の言葉なんて誰が保証してくれんの?
678 :
名前は開発中のものです。 :2009/01/21(水) 12:54:55 ID:8MTRCkQM
ちなみに別にデザパタを説明してほしいわけじゃなくて なぜそのパターンがタスクシステムだと考えたのか?ってとこな ま、それが説明できてもそのパターンの効果をみるとそれがタスクシステムの利点とイコールか? って言われると全く見当違いな気がすんだけどな 俺の勘だけど
680 :
名前は開発中のものです。 :2009/01/21(水) 19:35:20 ID:8MTRCkQM
>>679 俺はアンチタスク派なんだけど
あえていうとごった煮で引数の同じ関数を一気に実行できるとこじゃね?
利点ていうと違うな
俺はこんなことしちゃいけない派
681 :
名前は開発中のものです。 :2009/01/21(水) 19:44:20 ID:8MTRCkQM
そうすると基底クラス関数よんじゃだめなの?とか言われそうだが そうじゃなくて 本当は引数で渡すべき処理をグローバル変数やシングルトン使ってやりとりするのが駄目
ID:f259EVPA
ID:KNFisALs
ID:8MTRCkQM
・・・。ずーっと観察してるがやっぱグダグダだなお前
もう少しよく長考してから書き込めよ
>デザインパターン自体なにも利点のないものが入ってるし疑わしい
ほう。kwsk。(どうせシングルトンのこと言ってるんだろう)
>正確にはデザインパターンのゲームプログラムへの適用が適切がどうかわからない
素直に「デザパタ分かりませんので噛み砕いて説明してくださいお願いします」
って頭下げればいいんじゃないのお前
>両方とも目的と適用可能性の説明がゲームオブジェクトとかけ離れていて全く理解不能
>どこがわからないとかじゃなくて共通箇所が欠片もみあたらない
んー。イベントドリブンな仕組みを作るとオブザーバのようなものになるわけだが
>>2 は搭載してないけどな。(ユーザーに丸投げてる)
まぁ、
>>2 におけるイベントといえるものはVSYNCくらいだな。これだけ。
ゲームオブジェクトにとっては全く足りない。
ゲームの基本プログラムはメッセージ駆動システムの体をなすことが多い。
衝突・タイマー・etcetc。システム側で提供することが望ましいものは沢山ある
>>2 はなにひとつ提供しない。ユーザー側で実装することになる
ある時間に覚醒するジョブがあるとすると、ユーザーは毎フレーム呼び出される度に
自らグローバルタイマをチェックするか、自前のカウンタをデクリメントして時間が到来したか
チェックする。
684 :
名前は開発中のものです。 :2009/01/22(木) 00:13:19 ID:CJkxnn0x
むしろ、デザパタはお前
>>682 のが理解してないよ
だってオブザーバーの目的って
あるオブジェクトが状態を変えたときに、それに依存するすべてのオブジェクトに自動的にそのことが知らされ略
って奴だぜ
目的は本当にそれでいいの?
仕組みとコードだけ拾ってテキトーに適用したでしょ?違う?
そうでもないとこの適用はありえないよね?
>>684 >>2 が一切サポートしない機能の話しになるからアレだが
指揮システムが必要なゲームはこんな感じになるよ。結果的にな
・中隊本部の信号弾(赤)を合図に状況開始
・班長の拳に注目セヨ。拳を振ったら停止・全周警戒
AIで動く敵軍にチート情報を与えるようなエンティティをマップに配置することもある ゾーンアラームなど。プレイヤーが指定された範囲内に侵入すると 登録された敵分隊に警報が発令され、指定された戦術行動を取らせる そのエリアのパトロールに向かわせる、など
威勢はいいが反応が悪いな。 上ではかなりジャンルが偏った例をあげたが似たような仕掛けは いろんなゲームで登場する。特に後者のAI補助用のエンティティ。 まぁ、なんだ。【ありえない】とか簡単に言い切る前に長考しろってこと
689 :
名前は開発中のものです。 :2009/01/22(木) 07:34:35 ID:CJkxnn0x
>>686 特殊な例あげて正当化しやがって(笑)
そもそもそれじゃそいうことしないオブジェクトに対しては全く意味ないってことでいいの?
いちいちageんなクズ共
691 :
名前は開発中のものです。 :2009/01/22(木) 12:35:12 ID:CJkxnn0x
携帯からだとsageっていれんの面倒なんだよもん
sの時点でsageが候補に出るおれの携帯って・・・
>>689 マップ上にセンサーを配置するのが特殊とな?
ゲームバランスをコントロールするために、あるいは演出のために
空間内にセンサーを配置する、という選択肢をレベルデザイナーに
与えるのは特殊とな?
んー、興味深いな。
キミはいつもどういう人数構成でどんなゲームを作ってるんだい?
694 :
名前は開発中のものです。 :2009/01/22(木) 20:55:51 ID:CJkxnn0x
マップの話なんかしてないよ どうつながったのかしらないけど 頭おかしいんと違う?
> 『目的は本当にそれでいいの?』 > 『仕組みとコードだけ拾ってテキトーに適用したでしょ?違う?』 > 『そうでもないとこの適用はありえないよね?』 簡単にありえないとか言い切るってすごいね 視野狭窄で自己中で思考停止。病気じゃないの?
だけどデザパタのObserverの動機を読むと ソースの記述だけ似てたから適用してみた感は強いな デザパタの説明だとあくまでオブジェクト間の依存関係について説明してるのに 目的や動機を全く読まずに形だけ自分のソースに適用してしまった感はぬぐえない これはデザパタをよく読んでみればわかる
うん。デザパタについての理解不足は当然あるだろうね
俺はデザパタ用語は自発的には使わない。専らヒアリング専門なんだ。
デザパタ用語を駆使する人とのコミュニケーションを成立させるための
リテラシーとして頭の片隅に置いてる程度。至らぬところは素直に
ごめんなさいする用意はある
さて、詳しそうな人が出てきたので質問してみますよ
>>696 お、そう見えますか…
前記したとおり、まぁ結果的に後付でオブザーバーなんじゃないのと感じただけで
GoFのデザパタありきで仕事するほどの大した者じゃあございません。
手元にデザパタ本があるので念のため再読しておりますが
動機も含めて符号していると理解しているのでもう少し具体的に説明しますよ
センサー(Subject)は、登録されてるゲームオブジェクト(Observer)に
【俺の縄張りに何かが入ってきた】を通知するだけの存在です
そのイベントに対する具体的な行動(処理)は登録されている
各ゲームオブジェクトに委ねられております
Observerが地雷原のコントローラであれば、これが起爆のトリガーになります。
野鳥の群れ(のリーダー)であれば、驚いて飛び立ちます。
前記した歩兵部隊の分隊であれば、分隊長(Observer)が各班長に具体的な
行動を指示します。
このようにリスナーは多様です
ん、肝心の質問文が抜けてた
>>696 で、「目的や動機を全く読まずに形だけ自分のソースに適用してしまった感」
を感じた原因、これがObserverパターンであると説明するには問題がある理由
について宜しければご教示ください。真摯に受け止めます
>>698 ん?書いたつもりだけど?
>デザパタの説明だとあくまでオブジェクト間の依存関係について説明してるのに
これこれObserverの作者はオブジェクト間の依存関係を薄くしかったんだ
>>699 >オブジェクト間の依存関係を薄くしかったんだ
これは俺があげた例においても目的のひとつでありました。
センサーは自分が情報を通知する相手が何者なのか
その情報を何に使うのか、可能な限り知る必要がないことが
求められておりました
マップに配置する汎用のセンサーに対してそのような
要求が出るのは珍しいことでしょうか
以上の説明でObserverの提案者の目的との不整合は
ありますでしょうか
× 目的のひとつでありました。 ○ 要求のひとつでありました。
>>700 それじゃ君の意見としては
タスクシステムの目的=オブジェクト間の依存関係を薄くしたい
ということでいいのかな?
>>703 依存関係、全然関係ないじゃんw
やっぱりてめーテキトーに適用しやがったな
折角本買ったんだろうしちゃんと読めよ
なんだかド偉い勘違いされてるようだが
>>704 >テキトーに適用しやがったな
はて?俺はタスクシステム(
>>2 )なんて使わない人間なんだが
なんか根本的におかしな思い込みしてね?
>>705 それとお前がデザパタ全然理解してないことはまた別だろ?w
>>706 ん?はっきり言って
>>704 のいみがわかんねーんだが?
どうして理解してないっつー話になるんだい?具体的によろしく頼むよ
>>707 >どうして理解してないっつー話になるんだい?
だってお前、自分の目的と全然違うパターン適用して喜んでるアフォじゃん
>>708 どうぞ具体的に。どこで?どこで?引用してくんね?
>>709 タスクシステムは
>>672 みたいなものだと言ってるくせに
タスクシステムの目的=オブジェクトの依存関係を薄くしたい
って言ってるんでしょ?
ID:FRn83395 この子は頭がおかしいんじゃないかなとおもた デザパタヲタってこういうボーダー君多いよね
>>710 >タスクシステムの目的=オブジェクトの依存関係を薄くしたい
え?どこで?
>>711 ん?ちなみに俺はデザパタ使えない派だけど?
俺は他のアフォと違ってちゃんとよく読んだ上で使えないって言ってるので
ちょっとは話相手になると思ってるぞ
>>712 それがObserverの目的であって
タスクシステムがobserverってことは
タスクシステムの解決する問題も当然オブジェクトの依存関係を薄くするってことになるよね?
だけどお前は全然違う目的でobserverを適用してしまっているわけだ
>>713 いや、明らかにキチガイ系デザパタヲタだよ
否定しても無駄だってwwww
ずっとROMってたけどお前の突っ込み全部的外れジャンwww
カスだな
>>714 >それがObserverの目的であって
>タスクシステムがobserverってことは
>タスクシステムの解決する問題も当然オブジェクトの依存関係を薄くするってことになるよね?
あー、お前まさか、
>>2 はObserverパターンだとか言ってた人?
ねー、聞いていい?
>>2 の目的は何なの?依存関係を薄くするために
>>2 なの?
>だけどお前は全然違う目的でobserverを適用してしまっているわけだ
だからどこで?具体的に頼むよ。な?な?
>>715 的外れ?
どこが?
少なくとも目的と違うパターンを適用するほどは的外れじゃないと思ってるんだけどな
>>715 全部だよwwwww
おまけにタスク厨だろ?デザパタヲタでタスク厨とか超大物じゃん
おまえコテ名乗れよ。おもしれーwwwww
あー、腹がよじれるwwwww
草はやしすぎてアンカー間違えちゃったぜ。
>>717 な
怖いよ
すげぇアフォだな。大バカだよwwwwタスクシステムを愛して
これはObserver Pattern DA!バカにすんな!とか言ってんだったら
辛抱たまらんwwwwwwwwたまんねーwwww
>>720 あ、わりぃなwwwww邪魔しちまってよ
だってよwwwwギャハハハハwwww
何となく暇だったから200程たまったレスを読んでたらこんな時間だよ! >513 タスクシステムという言葉が死滅するまで終わりのないモグラ叩きを続けるぐらいなら、 適切な構造をこのスレででも担ぎ上げて、新生タスクシステムとして過去の遺物を駆逐しようとした方が、健康的じゃない? まあスレで意見がまとまるとも思えないし、万が一まとまっても、 このスレの検索順位からして影響力はまるで皆無な気もするけど。
新生タスクシステムとして過去の遺物を駆逐することを目的に作られた構造なんか 技術的にはまるで役に立たないに決まってるだろ。 具体的な目的に沿ってコードを書け、で FA
ID:FRn83395 は、デザパタヲタどころか、プログラムを1行も書けない なんちゃってプログラマなんじゃね? いくらなんでもひどすぎる。
デザパタかじっただけで半分近く読んでない自分が通りますよ、と。 とりあえずオブザーバーの所軽く読んだけど、・・・これ便利だな。 じゃなくて。 なんか一連の流れ、どっかで中の人入れ替わってない?
>>721 もうwの連発しかできなくなったか・・・
よっぽどショックだったんだな
悪いけどお前、プログラマの初心者にアリガチな
説明をよく読まずに当てはまりそうなキーワードを
テキトーに当てはめて問題を解決しちゃおう俺には特別な力がある(多分)症候群にかかってることから
初心者だろ?(俺も昔なったぞ 治るのに時間かかった)
もしくは一度も壁にぶち当たったことのないPGか
たしかにはじめに覚えなきゃいけない知識の量が多いから
そうなっちゃう理由もわからんでもないけど
徐々に克服していかないと会社にでたとき困るぞ
うわ。。。鏡どぞ
728 :
名前は開発中のものです。 :2009/01/23(金) 12:47:51 ID:7wK4EC9/
タスクシステム=オブザーバーは痛すぎた
なんか
>>726 読んでると道端の酔っ払ったプータローさんの説法を
傍で聞いてるような滑稽な気分になるのは何故なんだろうな
きっと
>>726 ののたまう戒めの御言葉がむしろID:FRn83395自身に
現在進行形で適用されるべきものだからなんだろうね
その症候群になるやつは根本的にこの仕事向いてないよ 単純な話、視野は絶対的に足りてない
ID:3jTewWuY(ID:FRn83395)
なんつーか、、こういうオッサンっているよな。。。。
お説教が大好きなんだろうね。日頃の行ないが伴ってないから説得力ゼロだけどお説教したい。
そしてもちろん相手を見下したい。でも理詰めでそいつをノックダウンする知恵がない。悲惨だね。
で、焦れて発狂。
>>704 以降はもう前後不覚。最悪のパターン
結局
>>726 が言いたかったことなんだろうけど過程がズタボロだから哀愁ばかりが漂うと
>>718 ,719,721
このw連発の発言は全く擁護できんな
洋画なんか必要ないだろ ただの荒らしだ
擁護ね。。。
FRn83395はちゃんと受け答えしてただろ w連発して荒らし始めた奴は技術者向いてない
お取り込み中申し訳ないんだが
>>726 草ボーボーの馬鹿の相手なんかして人生語る暇があるなら
俺の質問に答えてくれないかな。ずっと待ってるんだよな
帰宅と同時にもう睡魔到来中だから早急じゃなくていいから。な。
>>732-736 あれれ申し訳ない。ボクは大変な勘違いしてたみたい。。。。
>>726 ってID:2rWIRnW3に対するお説教だと思ってたけど
茶々を入れてる雑草君へのアドバイスだったんだね
早とちりしちゃった。テヘッ
>ID:FRn83395
眠い。とりあえず>>696-からもう一度読んでくれ。俺とお前の争点ここなのよ
お前、俺とのやり取りで
>>700 の質問に至った段階で回答渋っただろ。
で、
>>702 で論点をスライドさせたよな。まず
>>700 の質問に答えてくれ。な。
>>732 、
>>733 、
>>735 、
>>736 、
>>737 何これひどい言われようwwwwwwwwwww
俺涙目wwwwwwwwww
ごめんなさい
「俺は他のアフォと違ってちゃんと」(←キーワード検索)協調性と
自愛に溢れてるから顔真っ赤のオッサンの水準に合わせてあげただけなんだ
もうしない。ごめんなさい
>>726 は?みたいな
悪いけどオッサンあんたさー散々論理的にイカレた発言を連発しまくっといて
よくそんなえらっそうこと思い込みエスパーレスができるよねー
恥ずかしくない?自分と同類のクズ相手なら饒舌になれるの?小さいね!
というか
>>726 の内容すごいね。受け売り?いつも散々言われてるの?
それを復唱しただけなの?もっと身の丈にあったセリフを吐こうね!
あと何度も言うよ?なんでタスクシステムがObserver Patternなの?BAKA?
>>738 横から突っ込むけど
タスクシステムの議論をしてるのに俺システムの目的を語るのはおかしい
オブザーバーの発言に矛盾がでないようにした苦肉の議論にしかみえない
>>740 それはちょっと筋違いなツッコミとおも
もう少し遡るといいんじゃないかな
ID:f259EVPA
ID:KNFisALs
> デザインパターンのゲームプログラムへの適用が適切がどうかわからない
> オブザーバーとストラテジー?
> 両方とも目的と適用可能性の説明がゲームオブジェクトとかけ離れていて全く理解不能
この人物が話をゲームプログラムに拡大してる
>>741 だからゲームプログラムのタスクシステムの話だろ
743 :
名前は開発中のものです。 :2009/01/24(土) 12:09:57 ID:SVdZHBka
ゲームプログラムと言えばタスクシステムのことになるタスク脳
逆だろ
タスクシステムアンチは見かけるけど タスクシステム信者は見たことない。 どこ行けば見れますか?
>>745 既知外アンチによればこのスレにうじゃうじゃいるらしいw
747 :
名前は開発中のものです。 :2009/01/25(日) 12:42:11 ID:GMpY8msp
そんなムキになって自分の黒歴史をなかったことにしようと頑張らなくてもいいんだよ 過去から現在までのスレログもウェブにSNSその他至るところのタスク日記や記事はアーカイブや魚拓でいつでも見れるんだからさ 甘酸っぱい記憶は楽しまなくちゃ
どうでもいいけど、つまりここにはいないんだな?
既知外アンチが、読点を打てなくなるくらい必死だということはわかった。
このスレは、基本的にタスクシステムってなに?どんなんなの?って言う人間と、 タスクシステムなんてただの線形リストだろ、しかも使えねー。と思ってる人で構成されています。
751 :
名前は開発中のものです。 :2009/01/26(月) 10:44:34 ID:Mjs4eHQi
仕事だりぃ
哀れな奴らだ。タスクシステムは素晴らしい。夢と希望に溢れている 新清士によるとひらしょーには夢も希望もないそうだ。それはそうだ タスクシステム(神つまりゴッド)を否定する者に夢や希望が語れる はずがない
タスクシステムとはストラテジーパターンのことだというが順序が違う ストラテジーパターンがタスクシステムの理念の劣化パクったのだ StrategyPattern = ConstrainedTaskSystem 即ちタスクシステムとはオーバーストラテジーなのさ ピーキーすぎてお前らには無理だよ
夢と希望以外なにも語れてないようですが
上のほうで書かれてたAグループのメインPGの方ですね分かります
>>753 ちがそーw
デザパタさw
パターンを拡大解釈するととんでもねー見当違いになりがちだからさw
もうちょっと適切かどうか考えるか
パターン名を出したら目的文を自分でどう解釈してそういう結論にいたったのか
説明してくんねー?w
なんという了見の狭い頭コチコチのデザパタオヤジ。デザパタ用語というのは このように原典に縛られた了見の狭い気持ち悪いマニアの玩具となっているのだ パンピー : 「これは○パターンといえると思うのです」 マニア : 『それは○パターンではない。適用した理由を言ってみろ』 パンピー : 「△△だから○パターンと思ったのですがどうでしょう」 マニア : 『テキトーに適用しやがったな』 パンピー : 「というと?」 マニア : 『デザパタ全然理解してないアフォめ』 パンピー : 「どのあたりですか?」 マニア : 『目的と全然違うパターン適用して喜んでるアフォめ』 パンピー : 「どうぞ具体的に」 マニア : 『俺は他のアフォと違うから!ちゃんとよく読んでるから!』 大川いそうに。なんという知能障害。これがデザパタ用語に取り憑く原典オヤジだ
えーと、横から割り込むようで悪いが
俺の獲物は
>>756 ,
>>758 でいいのかな
いつまでコソコソ逃げるのかなー
ずっと待ってるんだよな。頼むわ。な。
なにを?
つ
>>736 ,
>>738 ま、威勢はいいんだが、頭の回転が鈍いのか即レスを要求すると
論理展開がボロボロになる傾向があるんだよな。このプロ気取り。
で、長考時間を与えてやったら今度は痴呆症でド忘れかい?
やれやれだね
そいつらと関係ないけど、その流れ結局どうなってんの。たぶん直接の起点は
>>667 の一言からだろう
>>667 問題の一言
>>668-678 はそれに対する反応と多少のノイズ。
>>682 が埋まりかけてた話題を掘り起こす。
>>685 がなぜかきわめて局所的な話をしだす。ここまでは『タスクシステム』自体はどういった『デザインパターン』なのかという流れだったのに。
>>695 が屁理屈。ノイズ。しかしここから話が派生。
>>685 と
>>696 のズレが埋まらないままレスが続く。
>>703 で
>>685 が(
>>696 にとって)意味のわからないレスをする。
(
>>696 、3jTewWuY =
>>706 FRn83395はそれまでのレスが、タスクシステムとオブザーバーについてだと思っていた。)
(
>>685 =
>>707 はそもそもタスクシステムの話をしていないつもりだった。)以下ズレの埋まらない無意味なのレス応答が続く。
>>711 /oVs2I+7が発生。だれだこいつ?このグダグダから先の話をまとめてくれよ。ってかむしろ掘り返した
>>761 =
>>707 がまとめてくれ。
本文多すぎでレス削ってたらよくわからないレスになっちまった。
要するに、
>>716 あたりから先の話を
>>761 にまとめてほしい。
なんつーか自分がまとめた場所までの時点でかなり無意味なレス応答感が否めないが。
>>762-763 >>741 とかが指摘してるけど、反タスク派で、たまに
OOP/デザパタ/ポリモーフィズム否定にまで勇み足をする(ように見える)
のがいるので、話が発散してるんじゃないのかな
前にもごった煮にしたら型の判定ができないとか言ってたのがいたし
765 :
名前は開発中のものです。 :2009/01/27(火) 12:46:47 ID:Df6y9ZuD
今度はストラテジーかよ笑 それって場面によってバブルソート使うかクイックソート使うかマージソート使うか選べる奴だろ? 適用したデザパタの目的と動機は自分の最終目的と一致してるか?
タスクシステムがstrategyとか言ってる奴、本当にプログラム1行でも書けるの? ただの基地外にしか見えん・・・
ID:Df6y9ZuD ↑(・∀・)↑
たまに湧くデザパタ厨はデザパタわかってないみたいだけど 職場でもこんな人いるよ 明らかに目的と外れたパターンを適用してみんなにボコボコにされる
>>768 だな。
デザパタって、抽象度そんなに高い話じゃないんだよな。
デザパタを拡大解釈し、抽象度をあまりにも上げて、どんな事例にでもパターンが適用できたら、
その概念自体、あまり意味をなさない。
狭い範囲に対して適用できるからこそ意味が明確で概念として有効なんだ。
770 :
名前は開発中のものです。 :2009/01/28(水) 14:09:01 ID:xO7fEt0t
ひょっとしてタスクシステムってファクトリーパヤーンじゃね?
パヤンに悪意と釣り針が見える
>>762 >ここまでは『タスクシステム』自体はどういった『デザインパターン』なのかという流れだったのに。
そんな流れとは知らなかった。つかそんなのウンコパターンとかでいいんじゃないか
>>741 や
>>764 も指摘しているみたいだが、ID:KNFisALsが流れに支流を作っており
俺はその支流に乗っかったってだけ。迷惑ならウンコパターン話を続ければいいよ
> 3jTewWuY =
>>706 FRn83395はそれまでのレスが、タスクシステムとオブザーバーについてだと思っていた
スレ読まずに書き込む間抜けでなければそれはあり得ない
それに俺は初っ端の
>>672 において既に、
>>2 をオブザーバーというのは何かがおかしい、と書いてる
(※理由は
>>672 で書いたとおり、
>>2 では全ゲームオブジェクトは誕生した瞬間に唯一の
循環リストに強制登録される。選択肢は全くない。生きてる限り、【必要の有無を問わず】
VSYNC信号発生の度に呼び出しを食らう。この時点でObserverとSubjectの関係と明らかに異なる)
>>762 (
>>772 続き)
スレ読まずに書き込む間抜けってのは勿論ID:3jTewWuY,ID:FRn83395のことな
んで、更に
>>682 以降で「オブザーバーのようなものになる具体例」として書き始めた内容が
>>2 にはないものであるということも最初に
>>682 で念押しもしている
反応した
>>864 ,
>>689 ,
>>694 はどうやら自分が作り出した支流の話であると理解していたようだ
>>696 ,
>>699 はどうかな。もし君の言うとおりなら「流れ読まずに書き込んだ間抜け」ということになるが
その仮説が正しいかどうかは本人に聞いてみないとなー
>
>>685 がなぜかきわめて局所的な話をしだす
これはゲームプログラムにおけるオブザーバーの存在を疑問視している人間に対しては
具体例を書いたほうがいいだろうと判断したから。一般化・抽象化するとオブザーバーの
ようなものになる必然性が見えてこないし、
>>2 では無駄が多すぎるということも見えて
こないだろう
マップに配置するセンサー類の設置数は比較的多くなる可能性が高く
総処理時間の上限枠は既に定められているが優先順位は低く削られる可能性も高い
処理内容はさほどタイムクリティカルなものではない(応答速度が数百msでも許容される)
時間刻みがVSYNC固定というのは苦しい。背後に空間領域分割や階層型スケジューラが
必要になる。特に後者のスケジューリング機構はゲームプログラムのかなり低レベルの
層で実装されることが望ましく、スケジューリング機構を持たない
>>2 はゴミとなる
>>762 (
>>773 続き)
なお
>>685 の軍事っぽいジャンルについては完全にでっちあげの架空
実際にはファンタジーものしか作らせてもらえない。しかたないね
>
>>703 で
>>685 が(
>>696 にとって)意味のわからないレスをする
タスクシステム(
>>2 )の目的とは
>>672 である。極めて簡潔な答えだ
もし彼にその意味が伝わらなかったのなら彼の脳内フィルターが
異常をきたしており、何かおかしなバイアスをかけているからだろう
>>704 以降の反応で、ID:3jTewWuY の思い込み・先入観の強さが確認された
ごちゃごちゃ長いけど要約すると全部 デザパタ理解してなかった言い訳にしか見えないね
出た出た。いつも監視してんのか。すげぇ暇人だな。助かるよ
>デザパタ理解してなかった
で、早く理解してない部分、とっとと抜粋して晒してくれないかな
ずっと待ってるんだよな。頼むわ。
あと
>>738 のほうもよろしく頼むわ。な。
>>776 だっせ
あまりにも惨めだな
明らかに理解してないのになんで頑張るの?
>明らかに理解してない どこが?
>>778 このスレでオブザーバーとか出てきちゃうあたりw
そもそもデザパタの本もってるのかなぁ・・・ ちゃんと目的と動機の欄読んでるのかあやしい お馬鹿なサイト丸写ししてわかった気になっちゃったんだね
781 :
名前は開発中のものです。 :2009/01/29(木) 21:24:08 ID:tPxukM8x
>>652 以降を読んで思ったこと
ID:f259EVPA ID:KNFisALs ID:8MTRCkQM ID:CJkxnn0x
= ID:3jTewWuY じゃないの?
『デザインパターンのゲームプログラムへの適用が適切かどうかわからない』(
>>665 )
『strategyとobserverは目的と適用可能性の説明がゲームオブジェクトとかけ離れていて全く理解不能』(
>>668 )
『ゲームプログラムでobserverパターンはあり得ない』(
>>684 )
ここまで断言&強弁するのはかなりの勇者だとおもうよ
自宅が全焼して髪チリチリになっても勝利宣言してる感じ
お年寄りってプライド傷付けられると狂ったように怒るよね
可哀相
>>781 IDまで取り出してきてずいぶん熱心だねw
専用ブラウザの抽出だけならわかるけどw
デザパタ読んでないのにソースの形だけみて適用するからそういう
赤っ恥かくことになるんだよwニヤニヤw
これから成長するのにいい薬になるからもっと言っておいてあげるよ あーだっせw すげー恥ずかしいw 馬鹿が目的も見ないでパターンとか知った気になっちゃってるの? 説明書読まないでゲーム始めんなよw 中学生か?お前?w
ID:/s4Iqftx ID:/PUT5suM はい、どうぞ。引用して俺の発言との矛盾点、指摘してくださいな
>>784 その必要はもうないだろw
デザパタ読んで目的と動機の項目読めばアフォでもわかる
恥ずかしい奴だなお前
で?お前誰?
俺、お前にも興味ないしID抽出とかやんないからお前知らないんだけど?
草はやしてる奴は何故に顔真っ赤なのか?
だいたい
>>781 にレスつけたのに何別の奴が返してんだよ
788 :
名前は開発中のものです。 :2009/01/29(木) 21:50:09 ID:tPxukM8x
ごめん
スレの流れ読まずに書き込んじゃった
ID:/PUT5suMがご本人だったのかな
タイミング悪かったみたい
>>782-783 それにしてもすごい剣幕だね
血圧に注意してね
>>788 これだけたくさんIDを集めてきた君が
人の血圧気にするなんてよっぽど顔真っ赤にしてるのがわかるよw
>787 オレに噛み付くなよ。めんどくせー奴だなキミは
>>785 >その必要はもうないだろw
>デザパタ読んで目的と動機の項目読めばアフォでもわかる
>恥ずかしい奴だなお前
頼むからさ、逃げないで答えてくれないか?
>で?お前誰?
それはないだろ。ちゃんと過去IDコテまで入れてるんだからさ
どうか落ち着いてほしい。な。
792 :
名前は開発中のものです。 :2009/01/29(木) 22:13:41 ID:tPxukM8x
>>789 スレの流れが分からないから追うしかないんすけど。。。
ちゃんとコテ名乗ってくれればID追う必要ないんすけど。。。。
私の推測がハズレならそう言ってくれればいいのに。。。。。。
なんでこの人はこんなに反応するの?むしろこの人誰?
ご本人じゃないなら無視すればいいのに。。。よくわかんない人でつ
>792 そいつは御本人様で確定だろ女子高生的に考えて
>>790 誰?レスつけてないじゃん
>>791 は?誰?何聞いてるの?
オブザーバーはタスクシステムじゃないってw
まだ納得してないの?
>>792 >ご本人じゃないなら無視すればいいのに。。。よくわかんない人でつ
お前もレスつけなきゃいいのにねw
一番熱心にIDかき集めてきたの君だけどw
すげぇチキンだなコイツ
なんでオレに話しかけてくんだこのニワトリ 世話役の奴ちゃんと面倒見ろよ
おまえにまかせた
800 :
名前は開発中のものです。 :2009/01/29(木) 23:20:53 ID:tPxukM8x
イタタタ
>>800 おw
また頑張ってID集めてくんのか?w
自分のがナチュラルに痛いくせに人のこというのか?
お前等、何度もいうけどデザパタよく読まないで書き込むからこういうことになるんだぞ 次はパターンも目的ぐらいは自分が適用した理由に添えられるように努力しろよ いまのままじゃ恥ずかしいぞお前等
イベントドリブンなプログラムでobserverは基本中の基本だろ…… コールバックをOOPスタイルに抽象化したのがobserverだぞ 発言が面白すぎるので愛でさせてもらってるけどな
>>794 >は?誰?何聞いてるの?
いや、だから過去IDでコテ名乗ってるんだが
そうやって自分の都合の悪いときだけ痴呆症を発症されても困るんだわ
まず
>>700 。これは
>>738 でも催促しているよな。頼むわ。な。
>オブザーバーはタスクシステムじゃないってw
今度はなんの話だい?初っ端の
>>672 で既に回答は出してるよな
>>772 でもそれは指摘してるよな。何度書いてもすぐ忘れるんだな
805 :
762 :2009/01/29(木) 23:48:20 ID:e5MgZbFT
だーもーお前ら整理してって言った自分が悪いのもわかってるけど、もうどうでもいいよw
自分はデザパタ本のオブザーバー読む機会が出来たから、ほー程度に思ってたが。
結局現在の論点は>>685-
>>686 な状況を考えたとき、オブザーバーパターンが適用できるか。でしょ?
だれかあってるかどうか理由もつけていってよ。俺?今読んでる無理。
>>804 だからお前誰なんだよw
>>805 はぁ?冒頭の目的読むだけでこりゃちげーってわかるべw
>>805 >結局現在の論点は>>685-
>>686 な状況を考えたとき、オブザーバーパターンが適用できるか。でしょ?
全然違うじゃん
そもそも
>>686 なんてタスクシステムと関係ないじゃん
完全にスレ違いな上に言ってることも間違ってる
808 :
名前は開発中のものです。 :2009/01/30(金) 00:14:45 ID:5R1NkGJS
>>805 普通に可だとおも
監視者(人とか)に対して監視対象(センサーとか)の数が多くて
その状態変化が滅多に起きないなら監視者が監視対象の状態を
毎回毎回全走査するよりもイベント駆動にするよ
それがobserverパターンになっていても何も不思議じゃないし
>>806 いや、冒頭の目的なら問題ないだろ。
いくら読んでもイベントと相違がみえねぇ。
強いてあげるなら、イベントを発生させる要因が、イベントを受け取るやつらから来る(≒相互参照)、という特殊な状況な事くらいか??
でもこれは本で挙げた例がそうなってるだけで、ここは重要ではないな。
>>807 いや・・・だから・・・タスクシステムは直接関係ない話題が延々と続いてるって事実がホントわかってないのがいるのか・・・
何度も俺や他のやつらが言ってるじゃん・・・何で人のレス読まないかなー
>>772 よ、つまり
>>807 見たいのがいるんだよ。
>>806 >だからお前誰なんだよw
俺の名前欄を見ろって。それでCTRL+Fでスレ検索しろよ。頼むよ。な。
>>807 >そもそも
>>686 なんてタスクシステムと関係ないじゃん
>完全にスレ違いな上に
それは
>>685 で断ってる
【
>>2 が一切サポートしない機能の話しになるからアレだが】
スレ違いだと思うならグダグダ食ってかかる前に「スレ違いだろ氏ねカス」って開口一番に喚いとけって
>言ってることも間違ってる
確認するが、
>>2 と関係ない話という前提でも間違ってるって言ってるのか?正気か?
お前…「スレ違いだろ氏ねカス!」、俺…「この文盲野郎!バーカバーカ!」で決着させてもいいんだぞ?
いいのか?続けるぞ?
ではどうぞ。間違ってるところはどこ、説明してくれ、と延々再三催促してるからな。頼むわ。な。
あと俺もう寝るから。まぁ頑張って長考してくれ。な。
次に反応するのはたぶん数日後とかになるから別に焦らなくていい
続けたくなくなったら「スレ違いだろ氏ねカス!」ってちゃんと書くように
>>809 おw
やっと冒頭の目的を読んだ奴が出現
そうかそうかやっと読んだかw
まあ、読んだならわかると思うけど
どうみてもオブザーバー=タスクシステムですw
ありがとうございましたw
不思議だよね 明らかにタスクシステムなのにこの点を指摘する人がでてこないの
えーと聞いていいかな
タスクシステム=オブザーバー・パターンという場合、そのタスクシステムはどういうもので
サブジェクトとオブザーバーはどこにあって、それはどういう振る舞いをするの?
タスクシステムって
>>2 を見る限りはリストひとつになんでもかんでも放り込んでごった煮にして
一定の時間間隔で定期的に巡回UPDATEする仕掛けを提供するだけで後はおまえらで勝手にやってね
というようなものにしか見えないんだけど、どこにオブザーバー・パターンがあるの?
>>816 リストひとつになんでも放り込んで
→VSYNCイベントを受け取りたいオブザーバを登録して
一定の時間間隔で定期的に巡回UPDATE
→VSYNCイベントをオブザーバにnotify
ほら同じだ
>>814 はびっくり発言連発するからほっとくとして。
>>817 それってまさにデザインパターンを強引に適用した、あるいは強引にそうみなそうとした、じゃね?
果たしてフレームの更新をsubjectの状態の変化と捉えるか普通? いや、捉えられないって言ってるわけじゃないけど。
また、パターン全般は再利用性があることが前提になる。もちろんクラスライブラリにしても意味のないパターンもあるが、
イベントなんてJavaやC#ならデフォがいる。そのくらいクラスライブラリ化が簡単に出来るものだ。
となると。オブザーバーパターンは、最低限のメソッドに提供することが前提で(可能な限り自由性を持たせる)、
クラスのある言語ならクラスライブラリとして構築できなきゃビミョーなんじゃないの?
でそう考えると。
>>553 に類似する構造が前提になりそうなんだが。
さてさてこのスレで散々語られてたタスクシステムはどうでしょうか。
>>818 そうかなぁ
オブザーバってのは割り込みハンドラやシグナル、
イベントディスパッチャ/コールバックのようなものを
OOのデザパタとして記述したものでしょ
Document/Viewみたいなのにも使われるから、適用範囲はもっと広いけど
>>2 はアセンブラかせいぜいCで記述されたものだろうから、そりゃ表面的には
違うだろうさ、だが本質的には別に大した違いじゃないように見えるけどな
VSYNCをイベントとして「捉えない」ほうが、俺には意味が分からないけど
何となく論点の違いが分かった タスクシステムとオブザーバは=ではないでしょ、そりゃ タスクは昔のゲーム設計の一手法に過ぎないから、OOのデザパタほど 抽象化も汎化もしていない(し、その必要も無い) 別に誰もそんなことは主張してないと思うよ(少なくとも俺は)
デザパタは過去の技法をパターンとして集めただけだぞ? 抽象化されていなからデザパタより格下という論法がわからん
ゆーき先生の本がわかりやすいよね
>>817 >→VSYNCイベントを受け取りたいオブザーバを登録して
タスクシステム=
>>2 では全ゲームオブジェクト(タスク)は必ずただひとつのリスト(タスクリスト)に
登録されることが義務付けられているぞ。ゲームオブジェクトに選択の自由なんて全然無いからな
どんな性質のゲームオブジェクトだろうと必ずVSYNC発生毎に通知を受けなければならないんだよ
タスクシステムというのは、ゲームオブジェクトとはVSYNCに依存して当然、依存しないなんてあり得ない
VSYNC発生の度に通知を受けることを全ゲームオブジェクトが望んでいるに決まっている、という仕組み
CodeZineのコードはゲームオブジェクト生成と同時に暗黙のうちに唯一のリスト(タスクリスト)に登録する
たとえばゲーム開始時点で生まれて一定時間経過後に何らかの行動を始めるゲームオブジェクトがあるとする
タスクシステムではこういう性質のゲームオブジェクトも生まれると同時にタスクリストに登録する
VSYNC発生の度に通知を送り続ける。このゲームオブジェクトは通知を受けるたびに行動開始の時間かどうかを
自分でチェックしなければならない。まだ行動開始の時刻でなければ何もせずに処理を返す。時間がくるまで
そういうことを延々繰り返す
このゲームオブジェクトが本来受け取りたいイベントというのは行動開始時間で、VSYNCイベントとの依存関係は
本来はない。でもタスクシステムではVSYNC(一定周期の)通知機能しか提供しないから仕方なくこれを代用して
自分でポーリングを行なっている
タスクシステムでは依存関係があろうがなかろうが通知を全員に送る。オブザーバー・パターンの目的とは違う
デザインパターンで安全にタスクシステムを構築できるということについて 具体的に否定できるヤツは一人もいないなw ファビョって否定してるやつが数人いるようにみえるがID変えてるだけのアホが一人なんだろうな。
>>823 んーちょっとよくわかんない
> このゲームオブジェクトが本来受け取りたいイベントというのは行動開始時間で、
> VSYNCイベントとの依存関係は本来はない。
より高い抽象度では、「時刻Xになったら行動開始」だけども、
実装レベルでは、結局のところVSYNC割り込み単位でのフレーム更新という
「必要」が先立ってるんでしょ?
コルーチンや継続のようなものが使えるのなら、VSYNC単位で微分せずに
もっと自然に書けるだろうけども、
「その設計では」VSYNCイベント通知が「必要」だから、そう作ってあるのでは?
設計の良し悪しとか、無駄が多いとかはいくらでも言えると思うんだけど、
「オブザーバとは違う」ということにこだわることにそんなに意味があるようには
俺には見えないけどねえ
オブザーバは単なるパターンだから、
オブザーブする対象は別にVSYNCイベントだろうがタイマだろうが構わないわけでしょ
>>824 安全には無理でしょ
明示的な引数がない時点でプログラムの作法云々なんてもう
気にしない組み方だと思うけどね
update();
で動くのと
update(jiki,teki,tama,unko);
で動くのとじゃ
プログラムとしては絶対に下のがいい
上は結局、その関数で何が必要なのか要素がまったくわからない
アクセスしているものを知るには中身のプログラムを読むしかないし
趣味プログラマにはワケワカメw ごった煮リスト+メッセージプロシージャでこれからも頑張っていきます( ^ω^;)ゞ
>>826 > プログラムとしては絶対に下のがいい
あんた、どんだけ素人なんだ…。
本当にプログラムが1行でも書けるのか。
素人目にも、上( update(); )のほうがよさそうに見えるのだが、俺はおかしいのか。
いや、やはり下の方がいいね。 下手にクラス変数に他のオブジェクトへのポインタを持たせたり、グローバル変数(シングルトン含む)を使ってしまうと、 オブジェクト間の関連が複雑になって、わけがわからなくなる。 各メソッドに処理に必要な情報(メディエータとか)渡すようにすると、 末端のオブジェクトは実にシンプルになる。 JavaのAWT/Swingでよく使うpaint(Graphics g)みたいにね。
>>828-829 素人もいいところだな
じゃ、上(update();)でアクセスしてるデータは何と何?
update関数の中をすべてみないとわからないでしょ?
これがグローバル変数の最大の害
下(update(jiki,teki,tama,unko);)ならjiki,teki,tama,unkoインスタンスにアクセスしていて
仮にソースでグローバル変数を使わないという決まりをきちんと守っていた場合
update関数によってこれら以外のインスタンスが変更されることは絶対にないという
ソースを読む側の確信がもてる
これはバグを追う場面でも強力に働く
これがキチンと守られているかどうかで
開発期間やプロジェクトで出る総バグ数がまるで違う結果になる(俺の経験)
だからタスクシステムはバグが増える
ヘッダファイルにしても同じ
必要なヘッダを必要な分だけインクルードしてるソースなら影響するクラスがわかりやすい
が、タスクシステムはごった煮ソースになるので
ほぼ全クラスを一括インクルードしなければ動かないとかかなり糞
これではバグがいつまでたっても減りませんわw
安全性ってのは2つの観点があるんじゃね? ・メモリ上のオブジェクト寿命の保証 ・データ確定性の保証 データ確定性というのは「今このデータ更新中だからアクセスしないでね」っていう期間に ちゃんと排他制御出来てること(更新してるやつ以外はアクセスしないで待ってること)。 上(update();)はスマートポインタ使うから安全って言いたいのかもしれないけど、 スマートポインタが解決できるのはメモリ上のオブジェクト寿命の保証のみ。 データ確定性の保証は別途対策が必要。 それに比べて下はオブジェクト間の関係性が単純化できているから データ確定性の保証もしやすい。 だから下が良い。
>>831 >>ほぼ全クラスを一括インクルードしなければ動かないとかかなり糞
お前タスクシステムで組んだこと一度もねーだろ
>>833 あるし、ちゃんとタスクシステムでゲームを3本ぐらいコサエタよ
どれも途中参加だったけどかなり苦痛だったな
>>834 じゃあソースの分け方が下手なだけだ、タスクシステムだからって理由でそんなことには絶対ならない
>>835 ふーん、じゃそれでいいよ
ただ、そうしないとごった煮判別のところでやりにくいだけだと思うけどね
どうせわからないんだから一括でインクルードしちゃえばいいじゃん
って俺は思ったけどね(タスクシステムプロジェクトに参加してるときは)
グローバル変数も当然のように使いまくりになるしいまさらそんなところ争っても
大した違いにならないのでこの話(ヘッダの話)はここで終わりにしてくれ頼む
>>830 > JavaのAWT/Swingでよく使うpaint(Graphics g)みたいにね。
Graphicsのような汎用contextを引数として渡すのは構わない。
826はupdate(jiki,teki,tama,unko);のようにそのゲーム専用でかつそのタスク専用のcontextを渡しているわけで、
そんなものを渡すとその部分を抽象化できなくなる。
>>831 > じゃ、上(update();)でアクセスしてるデータは何と何?
> これがグローバル変数の最大の害
グローバル変数を使うだなんて一言も言ってないし、実際updateメソッドのなかでは
グローバル変数なんかにはアクセスしない。
> update関数によってこれら以外のインスタンスが変更されることは絶対にないという
> ソースを読む側の確信がもてる
そんなことは全く保証されないし確信が持てるわけではない。
updateメソッドでは自由に他のインスタンスにアクセスできる。
>>836 そうやって一括でインクルードするからわからなくなるって自分で言ってんじゃないの?矛盾してるよ、
ソースがしっかり分かれていればupdateの引き数で判断しなくても何がインクルードされてるかで判断できるよ。
>>832 > 上(update();)はスマートポインタ使うから安全って言いたいのかもしれないけど、
そんなことは俺は言っていない。
updateの引数として、汎用性のないcontextを渡すと呼び出し部分も呼び出される部分も抽象化できない。
それが最大の弊害であり、やるべきではない理由である。
>>833 実際831はド素人。「タスクシステムはごった煮ソースになる」の時点でド素人。
template<class Context> class Task
{
virtual void update(Context context);
};
こう抽象化しておいて、std::list<Context> tasksに対してforeachでupdateを呼び出すだけ。
「ほぼ全クラスを一括インクルードしなければ動かない」なんでド素人もいいところ。
>>836 > ただ、そうしないとごった煮判別のところでやりにくいだけだと思うけどね
「ごった煮判別」ってなんだ?
> グローバル変数も当然のように使いまくりになるしいまさらそんなところ争っても
タスクシステムを使ってようが、グローバル変数なんてひとつも使わないぞ。
あんたみたいなド素人、仕事に参加されると迷惑きわまりない。
俺が教えてやるから、何がしたいのか詳しく書いてみな。俺がお手本を見せてやんよ。
一括インクルードとかグローバル変数使いまくりとか、 単にそのチームが酷かっただけのように思えるが。
ID:rIovvj90は途中参加って言ってるし。
ゼロからタスクシステムを組んでみたら、どういうものか分かると思う。
そうすればグローバル変数とか関係ないことがわかる。
>>841 そういう理由があっても、それがすべてと思って批判するのはどうかと思う。
いや発言のレベルが流石に低すぎるから ただの釣りか、BASICやHSPぐらいしか知らないド素人なんでしょ OOPを知らないのは確実だけど、Cでもちょっと抽象化したコードを 読み書きしたことはなさげ
>>839 だからそれってソースをみたときに何が渡されてるのか確定できんの?
単純に
>>826 の問題は解決してないように見えるけど?
>>832 何故そこでスマートポインタが出てくるのか意味不明なんだが、
updateで引数がないということは次のようになっていると俺は想定している。
template <class Context>
class Task
{
public:
Task(const Context& context_) : context(context_) {}
virual void update();
private:
Context context;
};
それぞれのタスクはこのTaskクラスから派生させる。
updateメソッドでは、this.context に対してアクセスするので、スマートポインタなんか使う必要はないし
グローバル変数も使わない。
>>846 >、this.context に対してアクセスするので、
これが何か知らないんだけど説明してくれない?
>>844 > だからそれってソースをみたときに何が渡されてるのか確定できんの?
何が言いたいのかよくわからん。
「何が渡されてるか」って、updateの引数がないのだから、何も渡されていない。
C++でメソッド呼び出しなら、thisが渡されている。
と確定できるが?
>>848 仮に呼び出し側で
>>862 のような違いを
見つけたいソース(=引数を明示的にしたい)を書きたい場合にはどうするの?
>>847 >>、this.context に対してアクセスするので、
> これが何か知らないんだけど説明してくれない?
templateになっていて、ゲームを作りたいなら、そのゲームでタスクにとって必要なcontextを入れるんだ。
例えば、シューティングゲームで敵の弾だけ列挙したくて、それをタスクリストからdynamic_castなどで型判別するのが
嫌なら、このcontextに
std::list<Task*> enemy_shot_tasks;
というstd::listを持たせておく。そうすれば、敵の弾に対してforeachしたりできる。
描画するのにGraphicsクラスが必要なら、それもこのcontextに持たせておく。
>>849 > 仮に呼び出し側で
>>826 のような違いを見つけたいソース
> (=引数を明示的にしたい)を書きたい場合にはどうするの?
呼び出し側は、単に、一定のタイミングごとにupdateを呼び出すだけの存在であって、
呼び出し側に違いが現われるのは論理的におかしく、設計がまずい。
だから、呼び出し側にそのような違いを見いだそうとすること自体がおかしい。
>>849 詳細で個別的なメソッド呼び出しが必要で適している状況ではそうすればいいし、
そうするだけだよ
上のupdate()のような例では、呼び出し側は、オブジェクト間の差異を
意識したくない、統一的に扱いたいから、より抽象度が高い方法でやるだけさ
差異を選択的に無視して、問題をそれに適した/適切な抽象度で
扱えるようにすることが「設計」でしょ
車の運転をしているときに、エンジンに使われているネジのことなんぞ
いちいち気にしたくはないわけだ
>>842 俺もそう思うよ。
批判すべきはチームの設計・開発体制であって、タスクシステム自体の是非はまた別の問題。
ID:rIovvj90はそのへんの問題点の切り分けが出来てないんだな。
坊主憎けりゃ袈裟までってやつか。
途中参加した3本が全部別々のチームなんだったら、流石にその不運には同情するが。
俺には 826 で何がしたいのかいまひとつわからないのだが、タスクシステムから
callbackがかかるタイミング(ビデオゲームならV_SYNCごととでも思っとくれ)
以外のタイミングで、他のタスクの更新メソッドを呼び出してやる必要がある場合を
考えてみる。
普通、ゲームでそういうコードが必要になることは稀ではあるが、そのとき、
updateメソッドのなかで他のupdateを呼び出す、
> update(jiki,teki,tama,unko);
のようなことがしたい、というなら動機はわからなくはない。
この場合、jiki,teki,tama,unkoの4つのオブジェクトが生きていることを
保証してやる必要がある。
C#やJavaのような言語であれば、オブジェクトが生きていることは
保証されるのでDisposeされていないかをチェックする。
C++なら、オブジェクトが生きていること自体が保証されないので例えば、
Task chainに対して、
tasks.isContain(jiki)
のような判定が必要である。
std::listに対してこれをやると結構のオーバーヘッドになり得るので、
特定の型のstd::listを用意するか、もっと高速に判定できるコンテナ
(std::mapなど)をContext(
>>846 )に持たせておきこれをチェックするのが普通。
>>846 そのContextとやらでポインタ使うことになるっしょ。
そこでスマートポインタ使うから安全って言うのかと思った。
そうでなければどういう意味で安全といったの?
std::list< Task<Enemyとか> *> m_bullets;
init(*jiki,*teki,*tama,*unko){ ←こことか、
m_bullets.push_back(new Task<Enemyとか>(jiki,teki,tama,unko)); ←ここで外部データへのポインタ使ってる。安全じゃない
}
enterFrame(){
foreach bullet (m_bullets) {
bullet.update(); ←ここで渡すのを初期化時に移しただけ。状況はむしろ悪化してる
}
}
#template分かんねえwww
#newまわり恐らく書き方違うだろうけど意図は大体通じるよね?
>>856 > そこでスマートポインタ使うから安全って言うのかと思った。
> そうでなければどういう意味で安全といったの?
すまんが、俺は「安全」という言葉は一言も言ってない。
「安全」と言ったのは俺じゃない。
俺は、オーバーヘッドがあるから、スマートポインタを使わなくて済むところでは
使わないし、この手のタスクをコントロールするのにスマートポインタは持ち出さない。
またオブジェクトが生きているかどうかの判定については
>>855 で書いた。
ただ、
> Contextとやらでポインタ使うことになるっしょ。
については、このContextが保持しているstd::listなりstd::mapなりは、
Taskの解体の時に自動的にここから該当タスクのポインタをremoveするので
このstd::listなりstd::mapなりにあるオブジェクトが実在して、かつ生きている
ことだけは保証される。だから
>>855 の方法で問題ない。
いま読み返してみたら、855の書き方が悪かったので以下補足&修正とお詫び。 > Task chainに対して、 > tasks.isContain(jiki) > のような判定が必要である。 だけど、tasksから一度removeされて、同じメモリがオブジェクトに割り当てられる ことがあるので、このjikiというのは、オブジェクトのアドレスやポインタではなく incremental ID(いわゆるhandle)だ。 誤解を生じさせる書き方をして済まない。
contextって俺は長命オブジェクトをイメージしてるんかと 思ったけど、違うの? マネージャなりメディエータなり よくある子に親への参照を持たせているようなケースは、 親が先に死なないデザインなら安全 オブジェクト間の相互参照グラフが無軌道に複雑化する場合は、 確かにGCなしでは酷いことになるだろうし IDルックアップを毎回やるのは遅そうだな
>>852 その状態でなんで
>>826 ,830-832の内容を否定するの?
俺が書いたのは
>>831 のみだけど
その状態をダメだって言ってるのが
>>826 ,830-832の内容なわけ
ソースの記述で引数を明示的に表現しなければならないって話なのよ?
タスクシステム使うと完全に
>>826 ,830-832の問題をどうにもできないでしょ?
ソースの記述で引数を明示的に表現できる?
(ま、別にする必要がないって主張をもってるからタスクシステム派なんだろうけどさw)
>>859 > contextって俺は長命オブジェクトをイメージしてるんかと
> 思ったけど、違うの?
もちろん、Contextオブジェクトの寿命はあらゆるTaskよりは
長いことは保証しなければならないし、保証されると仮定してプログラムする。
でもタスクフレームワークとして見たとき本質的なのはそこじゃなくて、
そのアプリ固有のcontextをTaskから切り離してTaskの呼び出しを抽象化するのに
ここをtemplate classにする必要があるということ。
> よくある子に親への参照を持たせているようなケースは、
> 親が先に死なないデザインなら安全
>>858 のようにhandleを持たせるのが嫌なら、boost::shared_ptrを用いて
std::list<boost::shared_ptr> tasks;
としておくというのは一理あるんだな…でも、
> オブジェクト間の相互参照グラフが無軌道に複雑化する場合は、
循環参照するようなケースはshared_ptrではどうにもならないし
GCがある言語で書いたほうがスマートではあるな。
> IDルックアップを毎回やるのは遅そうだな
実際はオブジェクト数の上限は決まっていると仮定して良くて、
hash tableを使って実装するので、その部分は実はそんなに遅くはないよ。
たいていはhash値を計算してメモリを一度lookupするだけで済むので。
だから、ID lookupで実装するのがスマートだと思うな。
>>860 > ソースの記述で引数を明示的に表現しなければならないって話なのよ?
何故そんな必要があるのか、そのメリットがどこにあるのか俺には全く理解不能だ。
なんとなく論点のズレが分かった ID:rIovvj90 は、タスクマネージャからのupdate()呼び出し 以外の関数呼び出しは一切存在しない(あらゆるオブジェクト間の相互作用を それで解決する)プログラムを仮定しているように見える 他の人は(ID:9d5EHsE6)は、誰もそのようなものは仮定していない 普通に引数を使うところでは勿論使うわけで、 あくまでジェネリックなupdate()を書く時の作法として どっちが適切かという話をしていただけでしょ
>>863 違うってなんで曲解するんだ?
update関数の中でアクセスするインスタンスがソースの記述から
わからないのがダメだって言ってるんだ(もちろんダメだと思わなければそれまでだがw)
>>826 ,830-832で言ってることがすべてだって
これがわからないって経験値が低いぜ
わかってやってるってのも俺的にはちょっと考えにくいんだけどね
>>865 > update関数の中でアクセスするインスタンスがソースの記述から
> わからない
???
C++だからthisポインタ越しに、オブジェクト参照をたどるだけでしょ
参照はメンバ変数に持っているのだし
何が「わからない」のかが分からない
>>865 > update関数の中でアクセスするインスタンスがソースの記述から
> わからないのがダメだって言ってるんだ
何度でも言うが、そんなものはわかる必要がないんだ。
Javaのupdate(Graphics g)メソッドひとつにしても
updateメソッドのなかでGraphics以外のオブジェクトにアクセス
することは当然あるし、それを禁じる方法はないし、
update(Graphics g)というシグネチャを見てGraphicsにしかアクセス
しないと判断することは出来ないし、
実際そんなコーディングスタイルで書く必要もないし、
そんなコーディングスタイルを強要されるとまともにプログラムを書けない。
すべてのタスクファイルのヘッダをincludeして それが普通だと思っているID:rIovvj90みたいなド素人と 話していても時間の無駄なので俺は、ID:8CtHI7i5と勝手に話を続ける。
■ ID lookupの周辺。 typedef TaskHandle unsigned int; struct HashEntry { TaskHandle handle; Task* task_ptr; }; typedef HashTable HashEntry[max_of_hash_entry]; Taskクラスのコンストラクタでは、TaskHandleとしてincremental IDを付与して HashTableに登録するコードを書く。Taskクラスのデストラクタでは、HashTable からremoveするコードを書く。 TaskHandleから具体的な型に変換するのは template<class TaskClass> TaskClass* TaskHandleToPtr(TaskHandle h) { Task* p = HashTableからhのTaskを取得(); if (typeid(p)!=typeid(TaskClassのインスタンス)) return null; return (TaskClass*)p; // このcastは安全 } こうなるな。
>>869 の続き。
TaskHandle enemy1;
TaskHandle enemy2;
に対して
EnemyTask* enemyTask1 = TashHandleToPtr<EnemyTask>(enemy1);
EnemyTask* enemyTask2 = TashHandleToPtr<EnemyTask>(enemy2);
if (enemyTask1!=null && enemyTask2!=null)
{
// これらのタスクは生存している
update_something(enemyTask1,enemyTask2);
}
という生存チェックが必要になるな。仕方ないと言えば仕方ないが、
使う前に必ず必要なのがちょっとうざい気はする。
>>869 まあ概ね想定どおりっすね
俺の考えを言うと、
・C/C++なら、そもそもオブジェクトの相互参照グラフを整理する
のがベスト
・問題が不可避な場合にはGC, スマポ, ID管理などの解決方法があるが、
スマポは良く知られているように巡回参照には無力(そもそもグラフが
複雑化したから欲しくなったはずなのだから、それでは意味が無い)
ID管理が一番シンプルでポータブル、仮に全てが利用できると
仮定した場合、性能や特失に関しては研究の余地あり(ただ、ゲームでは
いずれにせよGCは利用しにくいでしょうね)
ってとこかしら
>>871 >(ただ、ゲームではいずれにせよGCは利用しにくいでしょうね)
これは何故?俺は、C#で商用ゲームプログラムを書いたけど
別にGCがあるので困るということはなかったのだが。
どんなことが問題だと思ってるの?
>>872 優秀な世代別GCで、決してワールドがストップしないと
確信できるケースでは、問題ないかもしれません
その確信が持てないなら、ゲームでは難しいかもしれません
ということです
>>873 > 優秀な世代別GCで、決してワールドがストップしないと
> 確信できるケースでは、問題ないかもしれません
それが確信できないとそもそもXNAでプログラミングなんて出来ないわけで…。
あ、もちろん、大きなリソースを解放するときは要注意なのでそのタイミングは
なるべくコントロールしてやる必要があるけども。それはC++でも一緒なわけで…。
>>870 の続き。
結局、TaskHandleという汎用型があまりよくない気がするな。
TaskHandle<T>にして、operator T*() を用意して暗黙で変換できる
ようにしたほうがいいかもね。
これなら
TaskHandle<Enemy> enemy1;
TaskHandle<Enemy> enemy2;
に対して
try {
// これらのタスクが生存していなければ暗黙の変換のときに例外が飛ぶ
update_something(enemyTask1,enemyTask2);
// update_somethingのシグネチャは、update_something(Enemy*,Enemy*)
} catch {}
とか。こっちのほうが少しシンプルかも。これは、どう? > ID:8CtHI7i5
>>874 いやその、「C#でゲームプログラミングは不可能である」という主張ではないので
誤解無きよう
そういう意味では、「GCはゲームではありえない」と読み取れるので、
強い主張すぎたかな、訂正します
>>876 いやまあ、C#で弾幕シューティング作ったら、やっぱり
GCが変なタイミングで動いてときどきカクカクなるから
object poolingするコードをtemplateで書きまくったとか
そういうことは日常茶飯事なので、GCに対して世間の目が
冷たいのはよくわかってるつもり。
このスレの趣旨に見合う形で話を戻すと、GCつきのほうが
タスクのinteractionは楽に書けることは書けるけども、
それでもC++でも
>>875 のように書けるなら、さほど手間は
変わらないと思う。
>>866 それは別クラスのポインタの保持をするってこと?
まあ、ようは関数読んだときにアクセスしてるクラスがわからないようなのはダメってことよ
当然そういうメンバに別クラスのインスタンスのポインタを保持させるようなのも禁止だよ
>>867 それができるんだよ
グローバル変数・関数の使用禁止(当然スタティックとかも禁止)とか徹底して
メンバに別クラスのインスタンスの保持禁止にするのをちゃんと徹底すれば
後、可能性があるのは引数とメンバ変数ぐらいだろ?
こうするとバグが比較にならないほど減るぞ
自分で一度この方式でプログラム組んでみてほしいね
決して面倒臭くない
むしろ開発が進むにつれこっちのが作りやすいとわかるはず
しかも読む人間もソースを追いやすいからバグの発見も早い
>>878 > メンバに別クラスのインスタンスの保持禁止にするのをちゃんと徹底すれば
> 後、可能性があるのは引数とメンバ変数ぐらいだろ?
別クラスのインスタンスの保持をすると何故いけないと思うんだ?
親オブジェクトが子オブジェクトのstd::listなんかを持っているのは普通であり、
当たり前だろ?これを禁止するなら、どのオブジェクトがある親オブジェクトに
対する子オブジェクトを持っていると言うんだ?具体的にソース書いて見せてくれ。
>>857 了解しました。スマートポインタは無かったことに。
あと「メモリ上のオブジェクト寿命の保証」が対策済みで問題ないのは了解しました。
それはそれとしてゲームオブジェクト間の「データ確定性の保証」
もしくはオブジェクト間関係の見える化の推進度合いの観点では
依然として「引数を明示的に表現する」ほうがupdate(void)よりも分かりやすい
と考えてるんですが、その点どうお考えですか?
update(void)メソッド呼び出しの中で他のupdateを呼び出す場合に
update(jiki,teki,tama,unko);と書くこと自体はその是非はともかく存在は想定されてますよね。
以下のように
Scene::update(void);
Player::update(void);
Enemy::update(void);
Bullet::update(void);
と全てをタスク化するのではなく、タスクの数はもっと減らして
Scene::update(void) { ←タスクはこいつだけ
player.update(jiki,teki,tama,unko);
enemy.update(jiki,teki,tama,unko);
bullet.update(jiki,teki,tama,unko);
}
としてやればだれがいつjiki, teki等を使っているのかが見やすくなる。
また、playerはTaskを継承しなくて良くなるのでPlayerクラスだけを抜き出して
test_player_class.cppとかいうコードを作ってPC上でクラスの単体テストすることもかなりやりやすくなる。
思うにTask導入しちゃうとタスクフレームワーク使わなければ単体テストすら満足にできなくなってるんじゃないかと。
update(void)を自動的に定期的に呼び出すのは要らないと言っているのではなく、
それを使った上でさらにそのメソッド内でupdate(jiki,teki,tama,unko)を導入することの利点について考えたこと有りますか?
きちんと比較したことありますか?という辺り
>>878 ひょっとして
> メンバに別クラスのインスタンスの保持禁止にする
の「インスタンス」には「std::list<EnemyTask*>」のようなものは
含まれないのか?これも立派な「インスタンス」だと思うんだが。
何かコンピュータ用語以前に、ID:rIovvj90は日本語が不自由で
何が言いたいのかよくわからない。
そもそも俺にしても
>>875 のようなスタイルで書いているわけで
別のTaskのインスタンスなど(compositionでの)保持はしない。
しかしHandleは保持する。それは、参照するのに必要だからである。
>>880 あなたの想定しているように、ゲーム画面ではプレイヤと弾と敵が
存在するが、タイトル画面ではそんなものは存在しないという場合、
タイトル画面を構築に不要なものを排除して、タスク間のinteractionを
なるべく簡素で見える形にしたいという動機は当然ありえる。
それでも
> Scene::update(void) {
> player.update(jiki,teki,tama,unko);
> enemy.update(jiki,teki,tama,unko);
> bullet.update(jiki,teki,tama,unko);
>}
は良くない。この書き方はド素人くさい。
>>882 >は良くない。この書き方はド素人くさい。
良くない理由はなんで?
>>882 そう、結局そこに帰結する。
>この書き方はド素人くさい。
この1点の是非
メンバもグローバルも駄目なら、 update(jiki,teki,tama,unko)を呼ぶ側のクラスは jiki,teki,tama,unkoをどこに持ってるんだ? main関数のローカルに持って、延々と渡していくのか? まあ、そんなことより、 ID:9d5EHsE6のタスク周りの実装をもう少し聞きたいな。 新しいContextを追加すると、Taskのリストがひとつ増えるんだよね? そのリストは誰がどういうふうに持つの?
>>882 そういう動機なら
class SceneXXXContext
{
GameGlobalContext* globalContext;
Jiki jiki;
Teki teki;
Tama tama;
Unko unko;
}
こう書いて、
public SceneXXX<GameGlobalContext> : public Task<GameGlobalContext>
{
virtual void update(const GameGlobalContext& globalContext)
{
this->grobalContext = globalContext;
my_task.update(this.context);
}
TaskList<SceneXXXContext> my_task;
SceneXXXContext context;
};
こう書くべきだろう。
>>886 の続き。さらに抽象化して、
template <class GlobalContext,class SceneContext>
public Scene : public Task<GameGlobalContext>
{
virtual void update(const GameGlobalContext& globalContext)
{
this->grobalContext = globalContext;
my_task.update(this.context);
}
TaskList<SceneContext> my_task;
SceneContext context;
}
こうとか。
ID:rIovvj90,ID:8N26Dxd2 の設計と上の設計との大きな違いは、このクラスが
使い回せるし、他の具体的などのTaskクラスにも依存していないということだ。
>>885 > ID:9d5EHsE6のタスク周りの実装をもう少し聞きたいな。
> 新しいContextを追加すると、Taskのリストがひとつ増えるんだよね?
増えない。Contextはタスク階層ごとに必要となるだけ。cf.
>>886
>>880 > オブジェクト間関係の見える化の推進度合い
詳細を「隠したい」場合と「見たい」場合があるはずなので、
その場合はどっちですか、という話になるだけでは。
ネジ一本のツクリまで気にしなければ運転できないような車は設計の欠陥で、
「見える」ことが常に良いことである、という発想は誤りです。
OOPのカプセル化やポリモーフィズムの意味を理解してください。
>>885 直接のインスタンス参照ではなく、事実上参照代わりに使えるハンドル(ID)を
持っていると書いてあったと思うけど。
勿論それは寿命が微妙な短命オブジェクトの話で、
寿命管理が明確な長命オブジェクトは直接参照でしょう。
>>889 ネジ一本のツクリまで気にして設計してある車でなければ運転したくないです。
運転手の話したいの?
設計者の話でしょ?
>>890 クラスAを作るとき、クラスAを利用する人間は、クラスAのユーザになる。
どちらも同じ人間かもしれないが、クラスはユーザに対しては詳細を
隠蔽するように働き、汚い泥仕事はその中に閉じ込め、問題の局所性を
高める。
本当にネジを気にしなければならないコードを局所化するわけだ。
OOPどころか、構造化プログラミングの基本中の基本ですので、
一から勉強しなおして下さい。
>>891 > 問題の局所性を高める。
そのためには、あるオブジェクトが実装のために利用するオブジェクトの
種類について
>>882 のように制約をかけたいという欲求はあるのでは。
だからこそ俺は、template <class Context>とContextを用いて、
こいつにしかupdateメソッドのなかではアクセスしないという制約
のかけ方を示し
>>886 、さらにそれを抽象化して
>>887 、
何故、update(jiki,teki,tama,unko);と書くのが良くないのかに答えた。
意味論的にupdate()をどう捉えるかでしょう update()の抽象的意味が、「VSYNCを通知する」ということであれば (というか多分そうだと思うのですが) jikiだのtekiだのtamaだのunkoだのといった情報は抽象的意味とは無関係な 代物、ということになります。 引数jiki, teki, tama, unkoを取るupdate()の「意味」は何でしょうか?
>>888 Task<GameGlobalContext> のリストは TaskList<GameGlobalContext> で、
Task<SceneXXXContext> のリストは TaskList<SceneXXXContext> なわけでしょ?
Contextが増えたらTaskListが増えてるじゃん。
Contextの種類数=リストの種類数ってことなんじゃないの?
>>893 > update()の抽象的意味が、「VSYNCを通知する」ということであれば
> jikiだのtekiだのtamaだのunkoだのといった情報は抽象的意味とは無関係
ああ、それは正しいね。通知するだけなら、引数は必要ないね。
ただ、世の中のイベントハンドラがすべてそうであるように、
そのハンドラのなかで使いたいであろうもの(マウスイベントならばマウスの状態、
キーボードイベントなら押されたキーの情報)を引数として渡すのは常識的なことなので
今回のケースも、updateなら何らかのContext(それは描画のためのものであったり、
そのSceneで使うものであったり)が付随していてもそれはおかしくはないと思うけど。
>>895 ええ、そうですね
Cならば、コールバックの第一引数として、いずれにせよthisポインタ代わりのもの
を使うのが普通ですし
ところで、違う目的のものに同じ"Context"という用語を用いているのは
混乱の元のように見えます
引数渡しをする場合には、テンポラリな情報のジェネリックラッパーを仮定していて
依存性をオブジェクト生成時に注入している場合には、長命オブジェクトへの
参照を仮定しているのではありませんか?
>>885 メンバはダメじゃないだろ
ただ、別クラスのインスタンスのポインタの保持が禁止なだけ
それとupdateの例ではなにやらゲームのオブジェクトのクラスに
同じゲームオブジェクトのjiki,teki,tama,unkoを突っ込んでるようなソースに
なってしまっているがこれも間違いでありえない
仮にシーンクラスなんてのがあったらそこのメンバとして
jiki,teki,tama,unkoをもつ
ちなみに俺が最初に書いたソースのupdateはゲームオブジェクトの更新処理のつもりの
updateだったが引数でゲームオブジェクトを入れてるのは間違い
必要な情報だけ入れる
まあ、この場で話す分にはあんまり気にしなくておk
>>894 俺は、
>>888 では
>>885 の
「新しいContextを追加すると、Taskのリストがひとつ増えるんだよね?」
の「リスト」を何故かstd::listのようなものではなく、表のようなものを
指しているのかと勘違いしてトンチンカンなことを書いてしまった。
これについては、謹んでお詫びしたい。
なるべくならこういうときは「std::listのようなもの」と書いてもらえるとありがたい。
ただ、
> Contextが増えたらTaskListが増えてるじゃん。
Contextに対応したTaskListが必要とは限らない。
class TitleSceneContext : GlobalContext {};
class GameSceneContext : GlobalContext {};
class PlayerSelectSceneContext : GlobalContext {};
このように(あとで拡張できるように各Sceneに対応するContextのclass
だけ生成しておいて)、実際は
TaskList<GlobalContext> taskList;
こう書くかも知れない。こう書くメリットは、TaskListの種類を減らして
生成されるコードを縮めることにある。
>>896 > ところで、違う目的のものに同じ"Context"という用語を用いているのは
> 混乱の元のように見えます
どれとどれが違う目的?
また、どう呼ぶべきだと思う?
ここで言うContextはtemplate class名なのでtemplate <class T>のTみたいなもので
それほど厳密な意味や名前は必要ないと思うのだけど。
(あったほうが理解したり、読みやすかったりするんだろうけど)
また、updateメソッドはContextとメンバ変数の状態のみによって、
次のContextの状態を作り出すことが出来るので、DFAと見なせる。
だもんで、CFTG(context-free tree grammar)とかの "context" という用語を
ここに持ってくるのはおかしくないと思ったんだけどな。
>>900 番号はずれてない。
>>886 の「そういう動機」の「そう」が指すのは、
>>882 の 「あなた」から「したいという」まで。
わかりにくくてすまん。
>>898 その場合、呼ばれる側はdynamic_castか何かで必要なContextの型に変換するんだよね。
呼ぶ側がどのContextを渡すかはどうやって判断するの?
俺、実は主婦なので、いまから買い物にいかなきゃならん。 そんなわけで、明日まで、返答できない。
半額セールがはじまる時間なんだ…。
>>902 > その場合、呼ばれる側はdynamic_castか何かで必要なContextの型に変換するんだよね。
この場合は、しない。
place holder的に、Contextの派生型だけ宣言しておく(
>>898 )という使い方がありうると言いたかっただけ。
902を混乱させたようで悪かった。些末な問題なので、忘れてもらって構わない。
>>899 > (あったほうが理解したり、読みやすかったりするんだろうけど)
無論、議論の参加者にとってはそのほうが良いわけですから、
その点の指摘に過ぎませんよ。
> また、updateメソッドはContextとメンバ変数の状態のみによって、
> 次のContextの状態を作り出すことが出来るので、DFAと見なせる。
updateメソッドの引数としてのcontextという名前が非常に典型的であるのは
その通り(特にその中身がopaqueで、その意味内容をその場で論じたくない場合)
ですが、一方クラスメンバの名前としては、「context」は適切で意味が
明快な名前であるとは言いがたいでしょう。
タスクシステム信者いたんだ?w
なんかタスクシステムがヤバクなるとスレを流しにかかるよねw
>>826 ,
>>830-832 からの一連のレスは面白いから次のスレにも貼ろうw
>>901 Thanks!
なぜド素人くさいと言ったか分かった。あなたはSceneについてのみ話している。
私はゲームオブジェクトについてのみ話している。そこがまず違う。
まずupdate()という名前のメソッド群があったらそれらを抽象化してまとめて扱いたくなるのは当然。
でもupdate()に引数付けただけの段階ではまだ途中なんだよ。その次の段階に進むことでうまみが出る。
次の段階というのはupdate()を複数のメソッドに分割できるようになること。
つまり
update(jiki, teki, tama, unko);
は下のように分割できる。
Jiki::hit_check();
Jiki::set_hp();
Jiki::get_hp();
Teki::get_hit_area();
Teki::get_attack_point();
Tama::get_hit_area();
Tama::get_attack_point();
...
それらをこうやって使う。
foreach t (teki) {
if (jiki.hit_check(t.get_hit_area())) {
jiki.set_hp(jiki.get_hp() - t.get_attack_point());
}
}
(続く)
(続き)
最後にSceneと統合すると
SceneXXX::update(void) { ←タスクはシーンだけ
foreach t (teki) {
if (jiki.hit_check(t.get_hit_area())) {
jiki.set_hp(jiki.get_hp() - t.get_attack_point());
}
}
foreach t (teki_tama) {
if (jiki.hit_check(t.get_hit_area())) {
jiki.set_hp(jiki.get_hp() - t.get_attack_point());
}
}
...
}
こうなる。
Scene::update(void) は
>>886 >>887 みたいなやり方で実装するのはアリ。
というかむしろそうしないと確かに「ド素人くさい」。ただそれはSceneにおいての話。
ゲームオブジェクトはSceneとは別枠で扱うべき。つまりゲームオブジェクトはタスクにすべきでない。
理由はゲームオブジェクト間は通信が多いので引数渡しを使用可能としたいため。
タスクでは引数渡しができないのが嫌。
私がupdate()で引数扱えるようにした方がいいって思ってるのはゲームオブジェクトについての話。
ただ、update()という名前で引数を扱うのはタスクシステムを脱出する過程で現れる過渡的、一時的な姿。
複数のメソッドに分割された後はupdate()なんて名前は消えてなくなる(たまたま別の意味付けで残ることはありえるけど)。
Sceneはタスクで良いのでupdate(void)で構わないが、
ゲームオブジェクトはタスクにすべきではないので(過渡的な姿という意味で)update(jiki,teki,tama,unko); が良い。
買い物から戻ってきた。
>>905 > ですが、一方クラスメンバの名前としては、「context」は適切で意味が
> 明快な名前であるとは言いがたいでしょう。
俺の書いた、
>>886 では、そのメンバ変数の宣言は、
SceneXXXContext context;
となっているけど、
A) SceneXXXContextのメンバ名がcontextとなっているのが適切ではない
と言いたいのか、
B) SceneXXXContextという名前が十分わかりやすいものではない
と言いたいのか、どちら?
俺としては、SceneXXXContextの変数名がcontextなのは、
大きなクラスでない限りはそれくらいの省略は許されるべきだと
思うんだが。また、SceneXXXContextは、SceneXXXを構築するのに必要な
文脈という意味で、意味明瞭だと思うのだが。
>>909 ああ、申し訳ないっす。後のほうの話を念頭に置いてなかった。
そっち見りゃ、少なくとも「なんのつもりか」は分かるでしょうね。
>907-909
> 理由はゲームオブジェクト間は通信が多いので引数渡しを使用可能としたいため。
> タスクでは引数渡しができないのが嫌。
タスクでは引数渡しがなんで出来ないの?
template <class Context>
void update(const Context& context);
このcontextって引数渡しでない?
それとも、これはいわゆるタスクではないの?
「オブジェクト間の通信」って何がしたいのかよくわかんないのだけど、
Handle経由で参照すれば(
>>875 )いいじゃん。
どうせ、ゲームオブジェクトにしてもそのオブジェクトの
生存の確認は必要なんだろうし、
>>875 のコードと何ら変わらないんじゃ?
>>912 実質グローバル変数渡ししかできないから。
foreach t (teki) {
if (jiki.hit_check(t.get_hit_area())) {
jiki.set_hp(jiki.get_hp() - t.get_attack_point());
}
}
これならそもそも生存してるやつ同士しか参照が発生しないから生存確認必要ないかと
>>912 明示的なって意味じゃねぇの?
だいたいそんな十把一絡な引数あってもしょうがねぇし
引数はソースコードに明示的にわかるようなものでないと俺は意味がないと思ってる
グローバルにしてテキトーに渡したほうが速いじゃん
>>913 > 実質グローバル変数渡ししかできないから。
何故、そう思ったのかは知らないが、俺の書いたソース(
>>869-870 ,875 )では
グローバル変数なんか経由していないし使ってもいないし、使うつもりもないのだが。
だから俺には、何が言いたいのかさっぱりわからない。
そもそも
>>908 の「ゲームオブジェクト」が何を指すのかがわからない。
「タスク」とどう違うのか。
そもそも、俺の「タスク」(
>>846 )とは「タスク」そのものが違うような気がする。
>>914 > 明示的なって意味じゃねぇの?
> だいたいそんな十把一絡な引数あってもしょうがねぇし
templateは実体化して使うだから
compile-timeには型が確定するし十分明示的じゃん。
templateが「十把一絡な引数」だと思うなら、お前はstd名前空間使用禁止な!
> グローバルにしてテキトーに渡したほうが速いじゃん
グローバル変数なんか使わないっちゅーの。
本当、ID:rIovvj90は、タスクシステム以前にプログラミング自体、ド素人なんだな。
そもそもまずいのはグローバル変数・関数じゃなくて グローバル・スタティックの変数・関数、別クラスのインスタンスのポインタの保持、 シングルトン、アドレスジャンプ等を使用することによって 明示的な関連が全く見えなくなることだけどね 別にそこにこだわってないならいいんじゃないの? どう組んでもw
>>915 > EnemyTask* enemyTask1 = TashHandleToPtr<EnemyTask>(enemy1);
これが実質グローバル変数。
これがダメ。
これをやめるべき。
これがグローバル変数とほぼ等価だと認識できないの?
俺の「ゲームオブジェクト」は
「自機と敵機の座標が重なっていたら自機にダメージ与える」という処理において言えば
「自機」と「敵機」がそれぞれゲームオブジェクト。
俺の「タスク」は
class Task {
public:
virtual void update(void)=0;
}
的なやつを実装したもの。update(Context?)=0;でもいいけど。
>>918 >> EnemyTask* enemyTask1 = TaskHandleToPtr<EnemyTask>(enemy1);
> これが実質グローバル変数。
> これがグローバル変数とほぼ等価だと認識できないの?
出来ないね。
それがグローバル変数に見えるならあんたの目が腐ってるとしか言いようがない。
ID:rIovvj90 と ID:8N26Dxd2 はいつも時間的に連続して出てきて、
二人とも極端にレベルの低いド素人プログラマなんだが、これは
同一人物なのか?
それとも、こんなド素人が二人も都合良くこのスレに出没してるのか?
>>918 >「自機と敵機の座標が重なっていたら自機にダメージ与える」という処理に
> おいて言えば「自機」と「敵機」がそれぞれゲームオブジェクト。
タスクとの違いがわからない。
> 俺の「タスク」は
> class Task {
> public:
> virtual void update(void)=0;
> }
> 的なやつを実装したもの。update(Context?)=0;でもいいけど。
「ゲームオブジェクト」とやらも、そのTask派生クラスでいいじゃん。
何がまずいの?
>>919 違うっつの
しかも、グローバル変数が問題じゃなくて
明示的な関連(アクセスかな?)が見えないのがまずいって言ってるだろ
関数の実行に必要なもんをソースみてわかるようにしろ
簡単だろ?
何もむずかしいこといってやしねぇだろ?
>>921 の書き込みが ID:rIovvj90 でされているんだが、ID:8N26Dxd2 のほうでログインしなくて
良かったのかい?
まあ、それはいいとして、ひょっとしたら、ID:8N26Dxd2 は、
static std::map<TaskHandle,Task*> taskHandleToPtr;
static Task* TaskHandleToPtr(TaskHandle h)
{
return taskHandleToPtr[h];
}
こういうソースを想定して、taskHandleToPtrがglobal変数で
この変数を経由してTaskHandleとTask*が結びついているから
enemy1がglobal変数だと主張しているのかも知れないが、
よほどのド素人でもない限り、上のような馬鹿なソースは書かない。
実際は、
> EnemyTask* enemyTask1 = TaskHandleToPtr<EnemyTask>(enemy1);
このように実装できるように書くなら、Task基底クラスに
TaskHandleToPtrメソッドを持たせてTask派生クラスの初期化のときに、
HashTable (
>>869 ) のポインタを渡す。
だから「実質グローバル変数」ではない。
>>921 > 関数の実行に必要なもんをソースみてわかるようにしろ
についてだが、
> EnemyTask* enemyTask1 = TaskHandleToPtr<EnemyTask>(enemy1);
の「関数の実行(コンパイル?)に必要なもん」は、EnemyTask*で、
これはEnemyTaskクラスの定義してあるheaderが必要だ。
これは「みてわかる」と思うんだが、何をそんなに問題にしているのか
それがわからない。
いま気になったので、ID:rIovvj90 と ID:8N26Dxd2 の書き込みを 全部読み返したのだが、この二人(一人?)は極端に日本語が不自由だな。 この二人は専門用語の使い方もかなり間違いだらけで、 何が言いたいのか理解に苦しむ。 本当にこれで社会人なのか…。 というのはさておき、わかってないのはこの二人(一人?)だけみたいなので IDも変わったことだし、俺はもう寝る。
>>924 文体が全然違うのに病気だろそれはw
ちなみに俺はID:rIovvj90ね
君たち、タスクシステムの話をしなさい。 素人だとかプロだとか、技術と関係ない感想は取り除いて話しなさい。
ID:8N26Dxd2 です
>>919 グローバル変数の嫌なとこは
プログラムのどこかで変数の内容が変更される可能性があるのにそれが把握できないことでしょ
「ポインタを全タスクにばらまいてどこからでも全データ参照できる機構」の嫌なとこは
プログラムのどこかで変数の内容が変更される可能性があるのにそれが把握できないことでしょ
俺には両者はほぼ等価でどちらも忌むべきものにしか思えないが
もし「グローバル変数」と呼称するのが受け付けられないだけなら呼び方はどうでもいいけど
技術者として設計に不吉なにおいを感じないか?
>同一人物なのか?
違うっつの
>>920 >タスクとの違いがわからない。
object: 物体, もの, 実物; 対象
task: コンピュータが処理する仕事の最小単位
*goo辞書より
>何がまずいの?
タスク間の通信は実質グローバル変数渡しでしかできないのにゲームオブジェクト間は通信たくさん必要でミスマッチなとこがまずい
#話全く関係ないけどgoogleびびったw
>>919 > 同一人物なのか?
人を陥れるために真似る奴もいるぜ
あまり単純に考えない方がいい
つか>826にあるコードの断片だけを見て
どっちがいいか判断できるなんてエスパーとしか思えん。
>>826 引数でどうしても縛りたいならupdate()のなかでupdate(jiki,teki,tama,unko)呼べば解決じゃねーのか。
何が問題になるんだ。
>>830 本題とは関係ないかもしれないが、
JavaのCanvas#paint(Graphics g)で、
g以外に何にもアクセスしないで何を描画するつもりなんだ?
Canvasインスタンスが持ってる他のオブジェクトへのリファレンスを経由して
他のオブジェクトにアクセスするからpaint(g)でうまくいくのであって、
決してgにしかアクセスしないわけじゃない。
826の下がいいと言うなら、
paint(Graphics g)だとCanvasが何をpaintするかわからないので、paintメソッドは
paint(Graphics g, jiki, teki, tama, unko)にしなければいけなくなる。
だからpaint(g)を例に出すのは間違ってる。
>>927 > 「ポインタを全タスクにばらまいてどこからでも全データ参照できる機構」の
> 嫌なとこはプログラムのどこかで変数の内容が変更される可能性があるのに
> それが把握できないことでしょ
std::list<Task*> tasks;
に対してforeachでupdateを呼び出していくだけで、
この呼び出し側しかtasksにはさわれないのに、
何故「ポインタを全タスクにばらまいて」いることになって、
「どこからでも全データ参照できる」んだ?
各Taskは、このtasksはいじれないんだぜ?
根本的に何か勘違いしてないか?
> タスク間の通信は実質グローバル変数渡しでしかできないのに
何度でも言うが、俺のソース(
>>875 )はグローバル変数を経由している
わけでもなく、グローバル変数を使っているわけでもなく、大きなオーバーヘッドも
なく、他のタスクオブジェクトのメソッドを呼び出せているが?
>>875 の書き方が気にいらなければ、
std::list<boost::shared_ptr<Task> > task;
というタスクリストに対して
boost::weak_ptr<Enemy> enemy;
こうなってると考えてもらっても良いが。
いずれにせよ、グローバル変数は使ってないし、
「どこからでも全データ参照できる機構」もないし、大きなオーバーヘッドもないが?
932 :
929 :2009/02/01(日) 02:06:31 ID:7YDjPQ+X
省略しすぎた > EnemyTask* enemyTask1 = TaskHandleToPtr<EnemyTask>(enemy1); 上のやつで引数はとってくるって意味ね4つだから Jiki* jiki = TaskHandleToPtr<Jiki>(jiki1); Teki* teki = TaskHandleToPtr<Teki>(teki1); Tama* tama = TaskHandleToPtr<Tama>(tama1); Unko* unko = TaskHandleToPtr<Unko>(unko1); this->update(jiki,teki,tama,unko);
>>922 俺が実質グローバル変数と言う判断基準は
「グローバル変数そのものではなくとも、
グローバル変数のように動き、グローバル変数のように扱えるのならそれはグローバル変数だ」
これ。
だから実装方法はとくに想定していないし、する必要も無い。
まぁグローバル変数という呼び方がだめならその呼び方はやめるよ。
問題点は
>初期化のときに、HashTable (
>>869 ) のポインタを渡す。
こんな感じでポインタをプログラム中にばらまくと
プログラムのどこかで変数の内容が変更される可能性があるのにそれが把握できなくなること。
「メモリ上のオブジェクト寿命の保証」は対策できてるから問題ないとして、
「データ確定性の保証」の観点から見た場合はどうなの?ってこと。
もしかしたら
>>886 の
> Jiki jiki;
> Teki teki;
> Tama tama;
> Unko unko;
を扱う記述例はどんな感じになる? と聞いた方が手っ取り早いのかもしれないが
>>924 >極端に日本語が不自由だな。
うん
ねもいにょ。俺ももう寝るにょ
>>933 >> Jiki jiki;
>> Teki teki;
>> Tama tama;
>> Unko unko;
> を扱う記述例はどんな感じになる? と聞いた方が手っ取り早いのかもしれないが
class SceneTask : protected Task
{
protected:
Jiki jiki;
Teki teki;
Tama tama;
Unko unko;
public:
SceneTask();
virtual ~SceneTask();
virtual void update();
};
何かこれで不満でも?
>>933 936の補足。
Jiki,Teki,Tama,UnkoがTask派生クラスとは限らないなら、そのへんはケースバイケース。
場合によっては
>>886 のように書いたりもする。
Jiki,Teki,Tama,UnkoがTask派生クラスであるなら、
boost::weak_ptrを用いるか、TaskHandle(
>>869 ) を用いるか、
>>886 のようにContextに持たせるか。
方法はいろいろある。
>>929 >>932 それ良いと思う。
>>934 >>908 の
>Sceneはタスクで良いのでupdate(void)で構わないが、
>ゲームオブジェクトはタスクにすべきではないので(過渡的な姿という意味で)update(jiki,teki,tama,unko); が良い。
は、つまり、
>>929 >>932 と同じようなこと言ってる。
急いで付け加えるとあくまで過渡的な姿に限定して言えばの話なので、その後
update(jiki,teki,tama,unko);
は
> foreach t (teki) {
> if (jiki.hit_check(t.get_hit_area())) {
> jiki.set_hp(jiki.get_hp() - t.get_attack_point());
> }
> }
> foreach t (teki_tama) {
> if (jiki.hit_check(t.get_hit_area())) {
> jiki.set_hp(jiki.get_hp() - t.get_attack_point());
> }
> }
> ...
みたいに変化すべきと思うけども
意味というか、論点がわかんねぇ……
>>938 その引用部分は、何のつもりだかはある程度は想像はつくが、
update(jiki, teki, tama, unko)
はどこでも呼んでいない
「update(jiki, teki, tama, unko)が欲しい」という主張じゃなかったの?
その引用部分のコードを、(引数のない)「update()」の中に
記述できない理由は何?
>>938 > ゲームオブジェクトはタスクにすべきではない
俺には、この根拠がいまだにわからない。
V-SYNCに応じてupdateを呼び出されたり、描画のために呼び出されたりするのだから、
少なくともTask派生クラスであるべきだと思うのだが。
それとも、その自機、弾、敵は描画には関係ないのか?
それとも、描画に関係あって、Task派生クラスではあるが、foreachでぶん回したいから
std::list<敵*> のようなものがいると言っているのか?
>>936-937 ども。不満は着目点がずれたまま議論してることです。
Jiki,Teki,Tama,UnkoがTask派生クラスじゃないという前提で私しゃべってます。
まず
void SceneTaskSTG::update() {
update(jiki, teki, tama, unko);
}
こういう書き方が良い。急いで付け加えると、なぜなら
void SceneTaskSTG::update() {
foreach t (teki) {
if (jiki.hit_check(t.get_hit_area())) {
jiki.set_hp(jiki.get_hp() - t.get_attack_point());
}
}
foreach t (teki_tama) {
if (jiki.hit_check(t.get_hit_area())) {
jiki.set_hp(jiki.get_hp() - t.get_attack_point());
}
}
...
}
こう進化させていけるから。
ド素人くさいとか泥臭い書き方が嫌という場合は劣化と受け取るかもですが。
あーそうか ゲームオブジェクトのステートは 相互に依存していることが往々にしてあって、独立しているとは限らないから おのおのについて「自分のステートを更新しろ」という号令を発する モデルが常に適切とはいえない、という主張か もう少しランクが上のクラスで(相互に関連した)ゲームオブジェクトのの ステート更新をまとめて行う設計であれば、その配下のオブジェクトが 号令(VSYNC通知)を受け取る必要は無いし、むしろそれは無駄だと そういう意味だと俺は解釈した
>>941 Task派生クラスではないならタスクではないのだから、好きなように書けばいいじゃないか。
それらは、いま議論しているタスクシステム(タスクフレームワーク?)とは何ら関係ないのだから、
タスクシステムの書き方に準拠する必要はないだろう。
しかし、どう見ても自機、敵、弾は描画の必要がありそうなのにTask派生クラスじゃないが
わけわかんないし、俺のタスクの書き方をどうして、タスクと関係のないプログラムの書き方を
持って否定されなきゃならんのか、まったくわけがわかんない。
>>940 >それとも、その自機、弾、敵は描画には関係ないのか?
関係ないっすね
Task派生クラスでも無いです
foreachでぶん回したいのはあります。
std::list<敵*> のようなものは要ります。
>>942 それは、俺も理解しているし、たぶんみんな理解している。
本人はそれをうまく説明する言葉を持ち合わせていなかったようではあるが…。
しかも、もしその理解が正しければ、ID:wxGi2uACの反論は誰に対する反論にもなっていない。
>>944 >> それとも、その自機、弾、敵は描画には関係ないのか?
> 関係ないっすね
なにー!それなら、いかにもシューティングみたいで、いかにも、描画します、みたいなものを例に
持ってくるのがわけわかんない。しかも接触判定とか、もろに描画考慮しているように見えるじゃん。
それなら最初から、
「主人公の体力」「主人公の生命力」「主人公の知力」(それぞれ描画は不要)
とか、そのくらいの説明は欲しいよ。
長々とつきあって損した。
>>943 >Task派生クラスではないならタスクではないのだから、好きなように書けばいいじゃないか。
Yes. 全くその通りです。
>それらは、いま議論しているタスクシステム(タスクフレームワーク?)とは何ら関係ないのだから、
>タスクシステムの書き方に準拠する必要はないだろう。
ここだったんですね、すれ違いの原因。
このスレではタスクシステムを使う=自機、弾、敵はTask派生クラスに絶対すべき、それこそがタスクシステム
という人が多かったのであなたもそういう考えの人だと誤解してました。でもそうではなかった。
この勘違いは私の落ち度です。ごめんなさい。思えばそういうそぶりは節々に出ていた。
あと、描画は別途foreach作ります。
void SceneTaskSTG::update(context) {
...
context.dev3dg->draw_model(jiki_gazou, jiki.x, jiki.y); ← 描画
foreach t (teki) {
context.dev3dg->draw_model(teki_gazou, t.x, t.y); ← 描画
}
...
}
> 俺のタスクの書き方をどうして、タスクと関係のないプログラムの書き方を
> 持って否定されなきゃならんのか、まったくわけがわかんない。
タスクの書き方というより自機、弾、敵をTask派生クラスにすることを否定したいと思ってました。
そのためにタスク使わなくても自機、弾、敵を扱えることを示していたつもり。
でもあなたはそもそもそこを重要視してなかったようです。ここにすれ違いの原因がありました。
SceneをTask派生クラスとするのは問題ないと思います。
夜遅くなっちゃいました。そろそろほんとに寝ます。
>>945 >たぶんみんな理解している。
それは・・・
そういうスレになったらうれしいですね
>>947 話はわかった…。お疲れさま&おやすみ。
話がさっぱりわからないけど ゲームオブジェクトまたはその他もろもろのごった煮リストとは 違うタスクの話を始めたの?
眠れねー。 どうでもいいけどforeachでヒットチェックしてるとこ、べた書きはないだろ。 判定対象は同士は同じメソッド持ってんだし。
×判定対象は同士 ○判定対象同士
ちなみに俺 ID:rIovvj90ね
俺的には
>>936 もいいとは言えないね
jiki,teki,tama,unkoと同じ問題が今度はシーンにうつるだけだ
シーンをタスクにいれて何のごった煮になるのか知らないけど
仮にタイトルシーン、シューティングシーン、リザルトシーン、・・・という種類のあるものなら
当然それに必要なupdateの引数も異なる
だからダメだね
まったく汎用性のない糞クラスだ
954 :
名前は開発中のものです。 :2009/02/01(日) 04:20:37 ID:3I9VPm/8
ID:rIovvj90=ID:rVEgp4cMって本当にプログラム書いてんのか? どう見ても役に立ちそうにないんだけど。 俺の現場にこんな奴来たら、即クビにしちゃうけどな。 いま本当に仕事やってんの?ニートとかじゃなく?
シーンなんて最も抽象化しやすいものの1つだと思うんだが……。
>>951 自機も敵も弾も全て同じ当たり判定してるなら同じメソッドでしょうから
1つのforeachにまとめてもいいかもしれませんね。
ただ、自機、敵、弾のリストを当たり判定リストとして統合した1フレーム限りの寿命のリストを作るのが良いかどうかという問題が発生しますが。
オブジェクト毎に異なる当たり判定処理を導入しやすいという利点を得た代わりにどんくさい見た目になってると考えればまぁ許容範囲かと。
あと、この手法が真価を発揮するのはひとくくりに抽象化できないもの同士の情報やり取りが楽になることです。
つまり当たり判定という「処理」部分の中に閉じた話ではなく、
「入力」、「処理」、「描画」を簡単に接続できるとこに真価を発揮します。
例1:自機を動かす
・InputDevice(イベントハンドラとかで1フレーム分キー入力とかをバッファリングするオブジェクト)
・jiki
・OutputDevice
というオブジェクトがあった場合に
・InputDevice・jiki間はswitch (InputDevice->popKey()) 〜
・jiki・OutputDevice間はcontext.dev3dg->draw_model(jiki_gazou, jiki.x, jiki.y);
と書ける。
例2:メニュー画面を操作する
・InputDevice
・menu(キー情報を入力として保持カーソル位置情報を変更)
・menu_draw_model(menuを入力として1フレーム分の描画内容を決定)
・OutputDevice
この場合もオブジェクト間で発生するデータのやりとり処理が素直に思いつきますよね。
オブジェクト間にまたがるデータ通信は無理やりどこかのオブジェクトに押し込めるのではなく、
Sceneクラスが受け持つ。そしてC入門書よろしく関数呼び出しを延々と書いていく。構造化プログラミングに逆戻りです。
利点はオブジェクト間の通信処理がC初心者でも書ける位に簡単化されることです。
(私はゲームオブジェクトにタスク導入反対派なので、こう記述すればタスク使うより楽にプログラミングできますよねという意図で書いてます)
そういえば > ・InputDevice・jiki間はswitch (InputDevice->popKey()) 〜 > ・jiki・OutputDevice間はcontext.dev3dg->draw_model(jiki_gazou, jiki.x, jiki.y); これらをそれぞれタスク化するのはありかも。 処理だし
なんだこの損した感は
960 :
名前は開発中のものです。 :2009/02/01(日) 20:36:02 ID:3I9VPm/8
ID:rVEgp4cMには
>>954 の返答がもらえないみたいなんだが
無視して
>>958 みたいに次スレ立ててるところを見ると本当にニートなのか
それは悪いことを聞いたな・・
前スレ、前前スレから、ひとりだけ異様にレベルの低いことを言う、
プログラムが少しも出来そうにもない、日本語の読み書きが不自由そうな
タスクシステム否定派が混じってると思っていたんだが、
それがID:rVEgp4cMだったのか・・・
>>960 一応、本職のPGですわ
ってなんでお前にそんなこと言わなきゃいけないのか?
内容でレス返せなくなったから人格攻撃に移ろうと思ったの?
育ちが悪いなぁ
962 :
名前は開発中のものです。 :2009/02/01(日) 21:29:27 ID:3I9VPm/8
>>961 あんたの書いた
>>831 とか
>タスクシステムはごった煮ソースになるので
>ほぼ全クラスを一括インクルードしなければ動かないとかかなり糞
この一文を見ただけであんたがとんでもない大馬鹿野郎で相手するだけ無駄な
三下プログラマだと誰が見てもわかるんだが。
なんでそこまで自覚無いのか知らないが、このスレであんた一人だけレベルが
異様に低いんだよ。
こんな場末のスレだってまともな人がたまに遊びに来て、
有意義なことを言ってくれるのに、あんたみたいな
クズが居たら議論の妨げにしかならない。ほんと、いい迷惑。
自分が三下ではないと思うのならぜひ
>>497 の問いかけに答えてみて欲しい。
いつのまにかタスクシステムありきで話が始まるんだから恐ろしい。
>>962 全然主旨と違うところに噛み付いてるけど
ソースに明示的に引数を書いて関数に必要なインスタンスをわかるようにしろ
ってのがメインなんだけどね
ここをあんまりずらしてほしくないな
あと、インクルードだってできるできないは別にしてもインクルードしてるんでしょ?
だって折角引数なくしてごった煮にしたのにそんなところに制限あっても
邪魔なだけもんねぇw
それとタスクシステムで組むなら俺はインクルードしちゃうべきだと思うよ
制限があることにもはやなんの意味もないわけだし
あえて言えばタスクシステムにしたのが運の尽きでしょw
プログラムの組み方(主に引数)によるクラスや関数の関連・アクセスの限定が
できないわけだしもうなんでもやっちゃったらいいよw
>>953 > jiki,teki,tama,unkoと同じ問題が今度はシーンにうつるだけだ
まあね。
> まったく汎用性のない糞クラスだ
ほどほどに汎用性のないちょっとだけダーティクラスだ
程度の言い方の方が良いのでは?
いつまでも通用する完全に汎用的なライブラリとして整備するかどうかは別として
似たようなゲーム量産する時にこういうクラスを作っとくのは実用上アリと考えても良いかと。
シーン間にまたがった画面遷移させたいというような要求が出て「やっぱシーン間も引数渡ししたいね」
となってから使うのやめたとしても、ゲームオブジェクトを脱タスク化する仕事量と比べたら傷は無いに等しい。
だから導入する人の直近の実用上に問題無いなら問題無いか、という姿勢で自分はOKと思った。
>>953 > 俺的には
>>936 もいいとは言えないね
(snip)
> まったく汎用性のない糞クラスだ
あんた、本当に頭がおかしいんじゃないの?
936は、具体的なシーンを構築するためのクラスであって再利用するわけでもなく、
汎用性なんか必要ないんだが。
何故理解していないものを批判できると思うのか。 Taskはより抽象的なクラス。こちらは汎用的である必要がある。 SceneTaskはより具象的なクラス。こちらは汎用的である必要はない。
>>968 したらどうして継承して〜Taskクラスである必要があるのん?w(俺はないと思うんだけどw)
ばっかじゃねぇんw
まさかの第2ラウンドwww 遅刻の予感www
名前の話か? それは単にサンプルだからだろ。 実際にはSceneTaskなんて何も表してない名前は使わないだろう。 Scene全体のスーパークラスとしてはあり得るかもしれんが。
俺はID:rVEgp4cM(スレ主)と議論するのは時間の無駄だと思うので よそのスレでやりたいわ。 あるいは、ID:rVEgp4cMを無視して話を続けてもいいだろうが。
973 :
名前は開発中のものです。 :2009/02/02(月) 01:38:35 ID:lhNqT94l
いいスレなのに、スレ主がいるだけ邪魔というのが惜しいな
>>972 アレアレ?
敗北宣言?w
まあ、いいけどダメな組み方なのわかってて
それを人に押し付けるのやめてね
その先に進歩ないからw
975 :
名前は開発中のものです。 :2009/02/02(月) 06:49:09 ID:lhNqT94l
>>974 お前が一人でスレのレベルを下げてるのな
せっかく、いいスレなのにな・・
976 :
名前は開発中のものです。 :2009/02/02(月) 07:40:15 ID:P5kryGXr
タスク信者、反論できなくなっちゃったかw ていうか、タスク信者っていたんだ?
俺はこのスレでは「タスクシステムの是非」あるいは 「安全性の高いタスクシステムの設計」について論じたいのだが、 前者については「理解できないから全否定」というスタンスの 奴がいる限り、まともな議論は望めそうにないな。 後者に関して、もう少しID:9d5EHsE6の話を聞きたかったが、 こうもノイズが多すぎては……。
タスクシステムではタスクがどうのこうのという割に、 実際にはタスク=オブジェクト みたいな図式ができあがってて、 それ、劣化オブジェクト指向だよねって突っ込まれる事例が増えていると。 ゲームを設計する上でゲームオブジェクトみたいな概念を持ち出すようでは、 タスクシステムを設計するのに向いてない。 BASIC時代のように、自機は自機関連サブルーチンが処理して、敵Aは敵A関連サブルーチンが処理をする。 これらのサブルーチン群をうまくスケジューリングするために、タスクシステムを設計するのが本道である。 データ中心指向と機能中心指向の対決がこのスレにつまっているのだよ。 えっへん。 とか言ってみるテスト。
>>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 の初心者ですわ。
(当時タスクシステムが何いいたいかよく分からんかった。ので、自機、敵機のリストで多態性して組んだ。
ってかこの本のやつは別にごった煮リストじゃナカタヨ。普通に自機系、敵機系と分けてるよ。)
>>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 とりあえず追いついたー。
>>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 ではユーザー自身がジョブを分割し周期タスク用のユーザープログラムを書く
992 :
電車から訂正 :2009/02/03(火) 09:04:55 ID:Xqi0Cwaa
>>990 朝一番は寒くて知能が一層働かない
罵詈雑言、ばりぞうごん、だよ
馬耳東風とこんがらがっちったよ
アンチ完全勝利か もうタスク信者も終わりだな ひらしょの一撃で弱り切ってたところでこの大敗退 決定的だな
>>994 最近の流れはまともにプログラムを書けない基地外アンチが馬鹿にされてるだけじゃんw
ひらしょーの奇襲攻撃が強すぎだろ セガの技術者に知らないなんていわれたら 求心力なんてなくなっちゃうだろ
最近、タスクシステムを過小評価している、と噂される某企業の経験者の名が散見されるが、 ひとこと言わせてもらおう。 ○ガねぇ〜。 そう言えば自分が本当に好きだ!と言えるゲームの中には・・・。!!! へぇ〜、タスクシステム知らないんだ!! ふ〜ん!!!
998 :
名前は開発中のものです。 :2009/02/03(火) 21:36:16 ID:8pOsGvCV
ちんこ
999 :
名前は開発中のものです。 :2009/02/03(火) 21:56:12 ID:j8kWE6ld
999!
1001 :
1001 :
Over 1000 Thread このスレッドは1000を超えました。 もう書けないので、新しいスレッドを立ててくださいです。。。