- 1 名前：名前は開発中のものです。 mailto:sage [2008/11/09(日) 11:51:40 ID:+pjnJyQQ]
- タスクシステムについての議論、相談、質問、雑談などのスレです
part2 pc11.2ch.net/test/read.cgi/gamedev/1196711513/
part1 pc11.2ch.net/test/read.cgi/gamedev/1173708588/
- 32 名前：名前は開発中のものです。 mailto:sage [2008/11/13(木) 19:34:18 ID:rnZd7PxY]
- >>22
＞極端にサイズが大きいものと小さいものを
＞同じヒープから確保する場合
「極端に生存期間が大きいものと小さいものを同じヒープから確保する場合」
も付け加えといとくれ
- 33 名前：名前は開発中のものです。 mailto:sage [2008/11/13(木) 20:38:35 ID:rnZd7PxY]
- >>32だけど>>21で既に生存期間の話出てるね。文盲だね
ネトゲのサーバプログラムとかだとオブジェクトの生存期間の差はかなり強烈なものになるから
例えばWindows系ならHeapCreateとかで適切にヒープ領域を分けといたりするけれど、PCゲーの
クライアントプログラム限定の話ならぶっちゃけこんなの要らん
数ステージを巡回するデモンストレーションモードで数日間ぶん回してメモリ確保に失敗し始めたり
タスクマネージャのグラフが愉快な絵を描いてるとかNtQuerySystemInformationでログ取り続けたら
驚きの結果が、とかならフラグメンテーション云々の可能性を考えてもいいかもだが
そういう場合はステージ毎にHeapCreate/HeapDestroyでドバっと確保・ドバっと開放でもしとけばいい。
これならステージ中のオブジェクトはみんなHeapAlloc系使ってもフラグメントの心配いらね
弾とかパーティクルみたいなサイズ・生存期間共に粒度極小のオブジェクトを大量にばら撒く
ゴジャースなゲームなら表示MAX分だけドバっと確保したboost::pool使うか配列で順序なしのリスト
みたいなことやっとけばいいよ
ところでタスクシステム？ﾊｧ？って感じだな
- 34 名前：名前は開発中のものです。 mailto:sage [2008/11/13(木) 21:32:18 ID:4jJZotVw]
- >>31
俺はそんな難解な話してない
使ってるメモリの使用量がわからない・わかりにくいってただそんだけのこと
あと、メモリリークとかも全然わかんねぇ
IDEの問題になるけど分かる要素がないのがひでぇｌ
で、俺の知識だけだと自分でmallocをラップした関数を実装して
それに使用メモリの総量・使用メモリ状況やメモリリークなんかを
チェックできるようにしてるんだけど
この辺っていつまでたってもウンコじゃね？
とかそういうこと言ってる
（俺が知らないだけかもしれんが少なくともVCはウンコだと思う）
- 35 名前：名前は開発中のものです。 mailto:sage [2008/11/13(木) 21:49:37 ID:bFvJK9Je]
- >>30
マジに最適化し出すと、関数の並び順とかまで見直す必要がある。PS2 のときには
キャッシュがマジ少なかったので、ライブラリチームは T15000 使って最適化してたけど、
今はそこまでやってないんじゃないかなぁ。
ゲームロジックはキャッシュミス起きまくりだが、そもそも大して CPU 使ってないので
気にしない。昔も今も。
- 36 名前：名前は開発中のものです。 mailto:sage [2008/11/13(木) 21:51:07 ID:bFvJK9Je]
- >>33
パーティクルとかの小さなオブジェクトは STLport の node allocator 使ってた。メモリが
多少無駄になるけど、早いし断片化しないので。
- 37 名前：名前は開発中のものです。 mailto:sage [2008/11/13(木) 21:56:23 ID:rnZd7PxY]
- >>34
確認するが、CRTデバッグヒープくらいは使ってるという前提でいいよな？
msdn.microsoft.com/ja-jp/library/974tc9t1(VS.80).aspx
その上で不満ということならもう少し詳しくお話をしてほしい
もし使ってないってんなら幾らなんでもネタだろう…（´-`）
- 38 名前：名前は開発中のものです。 mailto:sage [2008/11/13(木) 22:13:53 ID:4jJZotVw]
- >>37
こっちも確認するけど
それアフォがソース見てもわかる奴しかでない奴でしょ？
難しいリークだとアウトプットウィンドウに変なコードがずらずら出てもどこのコードが
リーク起こしてるかまったくわからない機能でしょ？
そんなの使えないよ
正直、その機能に頼るぐらいなら自分でmallocをラップしたほうがよっぽどいい
- 39 名前：名前は開発中のものです。 mailto:sage [2008/11/13(木) 22:21:07 ID:4jJZotVw]
- ちなみに使ってるのはこれ
_CrtSetDbgFlag(_CRTDBG_ALLOC_MEM_DF|_CRTDBG_LEAK_CHECK_DF);
なんでこれさ
こんなアフォなんだろうね
俺のいる会社の新人だってこんなアフォな機能作らないと思うよ
やっぱり俺の使い方間違ってる？
ってかそれとももうちょっといい使い方あんの？
さすがにこりゃねぇだろうと思った
だって自分でやればどこのソースのどのコードが使ってるメモリなのか
余裕でわかるようにできるじゃん
これまったくわかんねぇじゃん
動的（わからない法則がちょっとわかってないが）に確保したもんだとほぼお手上げじゃね？
- 40 名前：名前は開発中のものです。 mailto:sage [2008/11/13(木) 22:53:24 ID:rnZd7PxY]
- 飯くってた
>>36
node allocatorは良いものらしいね
>>38-39
把握した
WindowsだのVisual Studioなど言ったって、なんだよ結局はユーザープログラム固有の
モニタプログラム（システムモニタ（リソースモニタ）やジョブモニタ）を用意しなくちゃ
いけなくなるのかよバーローつー話だよな
通常、ゲーム開発用のフレームワークはデバッグ支援用のツール群とセットになってるけど
それに相当するサービスをVS標準機能に期待するのは難しいね
ま、同人ゲームとか、ここでタスクシステムすげぇすげぇ言ってる超小規模開発・個人開発なら
無用の機能だが
- 41 名前：名前は開発中のものです。 mailto:sage [2008/11/13(木) 23:55:15 ID:rnZd7PxY]
- 前>>969
（前略）だからコンテキストスイッチは不要では。
＞コンテキストスイッチは要らなくネ？
ゲームに要求される表現は多様化・高度化し続け、それに伴いゲーム内で処理されるジョブの粒度も多様化し
１イント内に処理すべきジョブ数も増大の一途をたどった。ジョブ（ゲームコード。例えばAI）を記述するスタッフも
増大し多様化した。時間ステップ毎に単純に数値積分していくだけのジョブばかりではなくなり、継続（continuation）
が必要なジョブが増えた。にも関わらずゲームの特性上個々のジョブはμsecオーダーで終了ないし中断することを
要求される。継続に必要な手続きをユーザープログラム側に丸投げする（ユーザープログラム側にリエントラントな
仕掛けを用意させる）原始的なFSMモデルのジョブ制御だけではお話にならなくなり、ファイバーやコルーチンのような
仕掛けも必要になった。これらのジョブの粒度はスレッドを使うには小さすぎ、また数も多すぎる
まぁ、同人ゲーやタスクシステムすげぇすげぇ言ってる超小規模開発・個人開発なら無用の機能ではあるが
- 42 名前：名前は開発中のものです。 mailto:sage [2008/11/14(金) 00:06:03 ID:DNME6QAR]
- ｽｹﾞｰ参考になってありがたいけど同人シュー制作者の俺にはテラコンプレックスｗ
- 43 名前：名前は開発中のものです。 mailto:sage [2008/11/14(金) 01:05:26 ID:mdtDWXyh]
- （訂正）
----------------------------------------------------------
＞（前略）だからコンテキストスイッチは不要では。
＞
＞＞コンテキストスイッチは要らなくネ？
↓
＞（前略）だからコンテキストスイッチは不要では。
----------------------------------------------------------
＞１イント内に
↓
時間ステップ毎に
----------------------------------------------------------
（補足）
一部素人がタスクシステム（以下>>2と呼ぶ場合アリ）とか呼ぶものの実態が>>2程度のものであるという前提に立つならば
これは70年代のハードに依拠する簡素なゲームにとっては無難なジョブ制御プログラムとかモニタプログラムの【断片】だね
しか言いようがない。もはや今となってはね。
これは非常に簡素でオーソドックスなFSMモデルのジョブ制御であり、大昔から科学計算で頻繁に使われ
大昔の計算機、現代でも組み込み用途の超貧弱なマイコン（安いものなら50円前後。RAM数KBとROM数百KBの
ワンチップのやつ。半ば使い捨て）のために用意される超原始的なモニタプログラムにも見られる。
継続に必要な仕掛け、つまりコンテキストスイッチに必要な記述は全部ユーザープログラム側に丸投げ。
何もしてくれない。誰が書いても同じようなものになるってくらい凡庸な、道端の雑草並みのありふれた仕掛けだ。
でも「タスクシステム」という呼び方は珍しい。かなりエキセントリックだ。これは特定の職場内の固有名詞
ローカル用語の粋を出ることはないだろうね
- 44 名前：名前は開発中のものです。 mailto:sage [2008/11/14(金) 01:22:07 ID:0noAZqI/]
- >>41
ＡＩについてで実装できてるわけじゃないから強くは言えんけど
タスクシステムの構造を大きく変えるような手を入れなくてもできそうな気がする。
別スレッドで定期的にタスクを位置等のグループ毎に分割して、グループ内での状況を解析する。
そしてタスクに次に処理がきたときに、次にどう動かすか考えるの役立つ情報をセットする。
とかではだめですか。
- 45 名前：名前は開発中のものです。 mailto:sage [2008/11/14(金) 01:24:09 ID:SCRh4oL7]
- >ゲームに要求される表現は多様化・高度化し続け
で、そんなリソース大量消費型ゲームと小規模DSゲームの売り上げが変わんなくて
涙目、という話ですね。わかります。
とかそんなつまらんイヤミはおいとくとして、タスクシステムのサンプル打ち込んで
おもしれーなとか言ってる俺には雲の上の話なんだけど、
>原始的なFSMモデルのジョブ制御だけではお話にならなくなり、
こういうところはなんとなく予想できるんだよ。ただ現実問題として
>同人ゲーやタスクシステムすげぇすげぇ言ってる超小規模開発・個人開発
が、手軽に手をだせる、楽チン開発できてウハウハなフレームワークってあるの？
どうせ勉強するんならそっちのほうがいいような気がすんだけど。
- 46 名前：名前は開発中のものです。 mailto:sage [2008/11/14(金) 01:26:10 ID:1UgkwBET]
- >>45
C++ でふつーにメインループ書いて、continuation っぽいこと必要な部分はスクリプト言語 + スタックレス VM で良いじゃん。lua とか。
- 47 名前：名前は開発中のものです。 mailto:sage [2008/11/14(金) 01:32:05 ID:mdtDWXyh]
- Ｑ．【>>2のようなプログラムを「タスクシステム」と呼ぶことに固執し広めようとする人間がしばしば笑い者になるのは何故？】
技術は進歩し続け、計算機は猛烈な勢いで処理速度を向上させ、現代のナウいハードに依拠するナウいゲームを
作るために『『不可欠』』となったナウいフレームワークだのゲームエンジンだのと比べるともはやミジンコ級であり
お世辞にもシステムとはとても呼べない玩具みたいな代物であることは否めない
>>2のような小規模で簡素なFSMモデルのジョブ制御は、原始的なモニタプログラムといえるかもしれない。
しかし一般にOSを表す非プリエンプティブマルチタスクシステムとは明らかに異なる。共通項は非プリエンプティブ
という点だけでありコンテキストスイッチをサポートしていない（その責任をユーザープログラム側に丸投げ
してしまってる）時点でマルチタスクシステムとは明らかに異なる。マルチタスクという用語自体は1960年代半ば
オペレーティングシステムという用語と共に誕生した。UNIVACとかSystem/360のOSが出てきた時代の話。
エンジニアは用語の意味が輻輳を起こし意思疎通に齟齬が生じることを嫌う。OSが提供されないカスタムボードで
走るゲームプログラムの開発者なら兎も角、立派なOS下で走るゲームプログラムの開発者にとってタスクはプロセスだ。
>>2は、過去に「とある開発チームで使われていた原始的なモニタプログラム」が固有名詞として「タスクシステム」と
呼ばれていたのかもしれないね、程度の理解でいいと思う。当時のゲームプログラムはOSが提供されないカスタムボードで
走るものであり、ゲーム開発者自前のモニタプログラムを用意しハードの全てを自分でコントロールした
＃google2001の検索結果によると当時「タスクシステム」などと呼んでるページはほぼ皆無だったことが判明している
＃ほんの一部でその単語を使ってたページは出典としてLogician Lordを紹介していた。ネットで徐々に伝播しCマガで
＃松浦とかいう素人プログラマが出典を明記せずに紹介し急速に流布し広めた「タスクシステム」なる呼び方の出所は
＃Logician Lordだろうと思われる。これがネット発の「タスクシステム」なるものの出自だ。都市伝説と呼ぶに相応しい
- 48 名前：名前は開発中のものです。 mailto:sage [2008/11/14(金) 01:55:22 ID:SCRh4oL7]
- >>46
スタックレス + lua でググった。
なるほど、いまどきはタスクシステム(FSM)でｶﾘｶﾘやる、やれるくらいの規模の開発
なら、単純なメインループとスクリプト言語のほうが楽だしパフォーマンスも出る
ってこと？
難点はあのパスカルくささに耐えねばならんとこかなあ。ﾆﾝﾄﾓｶﾝﾄﾓ。
- 49 名前：名前は開発中のものです。 mailto:sage [2008/11/14(金) 01:57:27 ID:1UgkwBET]
- >>48
状態遷移が複雑な部分、たとえばアクションゲームのプレイヤー制御とかは
C++ で書いといて、continuation あった方が楽な部分、たとえば「何秒後に
エフェクト発生」とかはスクリプトとかデータファイルで書くのがふつーじゃね？
- 50 名前：名前は開発中のものです。 mailto:sage [2008/11/14(金) 02:05:40 ID:mdtDWXyh]
- >>42
必要ないものは取り入れる必要はない。コンプレックスは持つ必要ない。
俺も同人ゲーを作ったことあるが規模相応の簡素なコーディングで済ませてた。
いわゆるタスクシステムとか紹介されてるあのヘンテコな仕掛けも不要だった。プライオリティ？ハァ？って感じだ。
敵の配列が弾の配列があって。そんな感じだ。
タスクシステムを心の底から崇拝する人間が心の底から子バカにしている様子がたまに見受けられる
配列厨のコードそのものだ。
同人ゲームを悪く言うつもりで書いたわけではないのだが、もし>>40-41の「同人ゲーム～」の部分が気に障るなら
そこは撤回する。すまなかった
- 51 名前：名前は開発中のものです。 mailto:sage [2008/11/14(金) 02:05:58 ID:SCRh4oL7]
- >>49
luaはver4のころちょっとかじっただけなんだけど、スクリプト処理のために
組み込んでみようとは思ってたんで、考えてみるよ。ありがと。
- 52 名前：名前は開発中のものです。 mailto:sage [2008/11/14(金) 02:22:54 ID:mdtDWXyh]
- >>44
多種多様な人間が多種多様なジョブ（ユーザープログラム）を記述することになると
「FSMモデルのみ」という拘束条件は必ず無理が生じる。これはやれば分かるという他ない
RAM数KBの組み込み用モジュールのモニタプログラムでもコンテキストスイッチをサポートしたがる。
FSMモデルでジョブを記述させると色々面倒くせーことになるから。説明するよりも組んでみたほうが
分かるという他ない
＞別スレッドで～
よく分からんがコンテキストスイッチをサポートしたくないがためだけに
何やら複雑怪奇な仕組みを導入する話のような気がしてならない
素直にLuaとか使ったほうがいいよ。というか眠いばいばい
- 53 名前：名前は開発中のものです。 mailto:sage [2008/11/14(金) 02:29:54 ID:SCRh4oL7]
- >>50
＞規模相応の簡素なコーディングで済ませてた
そこんとこがよくわからんのだよなあ。
単純な配列とループで組めて問題ないならぜんぜんOKでしょ。俺もそうする。
ただ、サンプルでも使ってる GLLib の人のサンプルソースは単純ループ
だけど、けっこうきつい印象を受けた。
俺も「タスクシステム」を採用するだけでバラ色の未来が開けるとは思わん
(まだかじっただけなんで実はすごい泥沼が待っているのかもしれない)けど、
そこそこ使いまわしが効いて、それなりに見通しがいいように思う。
要は適材適所じゃないかと思うんだが、用語を使うことすら非難するほどの
問題があるの？
- 54 名前：名前は開発中のものです。 mailto:sage [2008/11/14(金) 02:37:14 ID:SCRh4oL7]
- ＞何やら複雑怪奇な仕組みを導入する話のような気がしてならない
こういうのは、同意できるんだよね。
そこそこ便利そうだけど決してわかり易い仕組みとはいいにくいから、
なんか泥沼にはまりそうな気がする。
まあ、小学生の感想文ですまん。
- 55 名前：名前は開発中のものです。 mailto:sage [2008/11/14(金) 02:38:50 ID:s5clZUFB]
- タスクシステムが有効なのは小規模システムだな
メモリの単位がkまでの環境
Mになると不要
- 56 名前：名前は開発中のものです。 mailto:sage [2008/11/14(金) 02:46:45 ID:SCRh4oL7]
- >>55
キャッシュじゃねーかw<k
あー、PICのプログラムとかそれっぽい。
- 57 名前：名前は開発中のものです。 mailto:sage [2008/11/14(金) 02:49:24 ID:s5clZUFB]
- AVRは俺の嫁
- 58 名前：名前は開発中のものです。 mailto:sage [2008/11/14(金) 07:52:52 ID:EfjKu0FE]
- i君はルサンチマンに満ち溢れてるなｗ
- 59 名前：名前は開発中のものです。 mailto:sage [2008/11/14(金) 16:00:01 ID:gWloFQ1j]
- >>48
Luaの文法が嫌いならSquirrelもいいよ。
ム板でスレタイ検索してみてくださいな。
>>53
自分の書いた文章で古い設計方法に名前がついたことにより
予期せぬ形でもてはやされるようになってしまった。
そのことに対する責任感から現代的な知識を伝えると共に
言葉狩りを行っている。
彼の行動はこのように解釈することもできる。あくまで妄想だが。
- 60 名前：名前は開発中のものです。 mailto:sage [2008/11/14(金) 19:49:55 ID:Z+hETYkY]
- タスクシステムを使ってるプログラムの
メモリ・ポインタまわりのバグり具合はハンパじゃないな
フツーに書けとあれほど言ってるのにやって
ゲームと違うところでいっつも四苦八苦してるとなりのプロジェクト
あんまりポインタ周りのバグが酷いからプロジェクトをまたいだ会議で
原因を指摘してやったのにまだごにょごにょ言ってる
もう、お前（となりのプロジェクトのウンコリーダー）に逃げ場はねぇよ
グローバル変数とタスクシステムとポインタの悪用は絶対に全部セットなんだよな
タスクシステム使わないプロジェクトはグローバル変数も使わないしポインタの悪用もしない
だからプログラムがメインから必ず終えるし
組み込むべき箇所もすぐにわかる
第三者がきてもすぐに全体が把握できるってのはでかいね
もういい加減に信者も目を覚ますべき
- 61 名前：名前は開発中のものです。 mailto:sage [2008/11/14(金) 20:17:38 ID:gp/PSntR]
- メモリ、ポインタを怖がるってプロとしてどうなのｗ
- 62 名前：名前は開発中のものです。 mailto:sage [2008/11/14(金) 21:58:54 ID:EfjKu0FE]
- 馬鹿が触ったポインタほど怖いもんはねえぞ
- 63 名前：名前は開発中のものです。 mailto:sage [2008/11/14(金) 22:21:45 ID:pFqWgrsK]
- 確かにコンテキストスイッチがないとグローバル変数に頼らざるをえない。
コンテキストスイッチがあったところでスパゲティにする奴はするけどなw
- 64 名前：名前は開発中のものです。 mailto:sage [2008/11/14(金) 22:34:07 ID:mbBbhYbw]
- nullポはいねぇがあ～？
- 65 名前：名前は開発中のものです。 mailto:sage [2008/11/15(土) 00:05:57 ID:Kosjr/Zu]
- >>48
昔Delphi使ってたから、馴染みはあるんだけど、C/C++と併用すると間違うんだよね。
演算子とか。
>>60
あー、それは俺も気になった。
親クラスのメソッド呼んだら、内部で自分自身を削除してて戻ってきたところで落ちるとかw
俺がタコなだけなんだけど、基本的にポインタを多用するスタイルみたいだしな。
几帳面なやつ向きかも。実はちょっとびびってるw
- 66 名前：名前は開発中のものです。 mailto:sage [2008/11/15(土) 00:27:43 ID:GEMDjn92]
- それタスクシステムとかいうナニに限った話ではないと思うんだけどな
相互参照オブジェクト（インスタンス）の取り扱いについてのごく初歩的な
あらゆるプログラムに通じる基本的なお作法の話だと思うんだ
- 67 名前：名前は開発中のものです。 mailto:sage [2008/11/15(土) 00:34:05 ID:EtW+xZ5p]
- ポインタなくてもタスクシステム組めるけど？
- 68 名前：名前は開発中のものです。 mailto:sage [2008/11/15(土) 00:46:53 ID:Kosjr/Zu]
- >>66
んー、いいわけがましくなるけど、俺の場合、インスタンスの廃棄は生成した側
が責任をもつというスタイルだったんで、インスタンス自身が自分を廃棄する
という形式に慣れてないんだと思ったけど。
- 69 名前：名前は開発中のものです。 mailto:sage [2008/11/15(土) 00:55:46 ID:Qgt9Tm09]
- >>67
でも悪用するだろ？
しかもグローバル変数は使わないと恩恵（笑）は受けられないだろ？
所詮、アフォが飛びつく糞なアイテムよ
- 70 名前：名前は開発中のものです。 mailto:sage [2008/11/15(土) 01:00:16 ID:GEMDjn92]
- ＞インスタンス自身が自分を廃棄
その廃棄っていうのは、自殺を決断したらメモリ開放まで一気に行ってるわけだよね？
タスクシステムとかいうナニにおけるインスタンス（というかエンティティなんだろうね）の
自殺のプロセスというのは、常にそういうもの（自殺を決意したらメモリ開放まで一気に決行）
と決まっているの？それとも君が読んだ何かしらの自称タスクシステムのサンプルコードの
実装がたまたまそうなっていたというだけなの？
- 71 名前：名前は開発中のものです。 mailto:sage [2008/11/15(土) 01:06:54 ID:GEMDjn92]
- >>70補足
＞（自殺を決意したらメモリ開放まで一気に決行）
なおかつ生みの親や己を参照するインスタンスに何ら通知する手段を提供しない。ね
>>68
＞俺の場合、インスタンスの廃棄は生成した側
＞が責任をもつというスタイルだったんで
これも同じく。自殺を決意したら生みの親に自分を殺してくれと依頼するような手続きは
タスクシステムと呼ばれるナニにおいては「存在しない」ということになってるのか、それとも
君が読んだ何かしらの自称タスクシステムのサンプルコードの実装がたまたまそういう
手続きを用意していなかっただけなのか
自称タスクシステムってどれもこれも俺俺システムで内容がバラッバラだよね
- 72 名前：名前は開発中のものです。 mailto:sage [2008/11/15(土) 01:23:55 ID:Kosjr/Zu]
- >>70
イテレータに矛盾が生じないような工夫はされてたけど、delete はdelete だったな。
まあ、それでも、たまたま、じゃないかと思うけど。入門用サンプルだし。
- 73 名前：名前は開発中のものです。 mailto:sage [2008/11/15(土) 01:34:51 ID:GEMDjn92]
- >>72
そうかー。もし良かったらそれのURLとか書籍名教えてくれないかな
いや、別に悪戯とかしないからさ
- 74 名前：名前は開発中のものです。 mailto:sage [2008/11/15(土) 01:53:28 ID:Kosjr/Zu]
- >いや、別に悪戯とかしないからさ
却ってこえーよw
こっちは勉強させてもらってる立場だからあんまりなー。
このスレを調べりゃわかるよ。
- 75 名前：名前は開発中のものです。 mailto:sage [2008/11/15(土) 02:00:05 ID:GEMDjn92]
- あー、ここに載ってるならいいや
＞却ってこえーよw
何にもしねーよ。入門用を謳う自称タスクシステムがいっぱいあるから
そのカオスを更に加速させて「タスクシステム」がどんどん
「口に出すだけで何とも居た堪れなくなるムードを醸し出すキーワード」
になっていく様はある意味で痛快だしな。
- 76 名前：名前は開発中のものです。 mailto:sage [2008/11/15(土) 02:02:37 ID:GEMDjn92]
- いっぱいあるから → 増殖するのは結構なことだ
- 77 名前：名前は開発中のものです。 mailto:sage [2008/11/15(土) 02:45:06 ID:ic2SgE5A]
- ちょっと大げさかもしれないけど
コンテンツ産業に理解ある総理の下で
国策としてコンテンツ産業に力を入れようとしているのに
裾野を支える初心者が混乱に陥ることを喜ぶのは
日本人として恥ずかしくない?
- 78 名前：名前は開発中のものです。 mailto:sage [2008/11/15(土) 08:16:42 ID:hO/9YF4P]
- タスクシステムすごくね？
いつも途中で破綻する俺でもゲーム作れた
- 79 名前：名前は開発中のものです。 mailto:sage [2008/11/15(土) 13:25:03 ID:s+TTPkcj]
- >>77
そういう、いかれた自称上級者はいつの時代にもいた。
- 80 名前：名前は開発中のものです。 mailto:sage [2008/11/15(土) 14:12:48 ID:Mi8wwxRa]
- タスクシステムを使うようになってからというもの、周囲がボクを見る目が変わったね。
なんかこう一目置かれてるって感じ？
隠し切れない風格を醸してるせいかコミュニケーションにも微妙な距離が生まれるみたい。
こういう孤独も上級者ならではの悩みだよね
- 81 名前：名前は開発中のものです。 mailto:sage [2008/11/15(土) 14:30:50 ID:bk64Ra9f]
- 自由度が高い分だけめちゃめちゃ遅い点はあまりつっこまれない、なんで？
- 82 名前：名前は開発中のものです。 mailto:sage [2008/11/15(土) 16:47:53 ID:ooF5RpWW]
- 遅いって何が？
- 83 名前：名前は開発中のものです。 mailto:sage [2008/11/15(土) 18:45:10 ID:saotQS84]
- たぶんこの辺の話
pc11.2ch.net/test/read.cgi/tech/1217813098/985
- 84 名前：名前は開発中のものです。 mailto:sage [2008/11/15(土) 19:01:12 ID:Bp8RkerR]
- 仮想関数まで否定することになるな
- 85 名前：名前は開発中のものです。 mailto:sage [2008/11/16(日) 02:36:48 ID:SVunqIhe]
- なぜタスクシステムを嫌うのですか？（上位５回答）
１．名前が気に入らない
２．名前を付けた人物が気に入らない
３．名前の「システム」の部分が気に入らない
４．自由度が高いのが気に入らない
５．隣のプロジェクトが気に入らない
- 86 名前：名前は開発中のものです。 [2008/11/16(日) 03:11:11 ID:DYIhu6LD]
- 「気に入らないから叩かれてるに過ぎない」として批判を過小評価したがってる様子が
ひしひしと伝わってくるけど、そういうワンパターンなかわし方を続けるのってのもどうなんだろうね
- 87 名前：名前は開発中のものです。 mailto:sage [2008/11/16(日) 06:15:12 ID:SBJGjbor]
- カプの開発で大規模に作っちゃったもんが
タスクシステム使いまくりでバグりまくりなので
そもそもの構造からいってすでにまずいってことがわかると困る人がいるのです
- 88 名前：名前は開発中のものです。 mailto:sage [2008/11/16(日) 07:03:30 ID:SVunqIhe]
- >>86
いやいや、俺はタスク使わんし・・・
批判の仕方が感情的だっつってんの
タスク派も嫌タスク派も、なんで自分のやり方が一番いいと思えるんだ？
- 89 名前：名前は開発中のものです。 mailto:sage [2008/11/16(日) 07:44:51 ID:SBJGjbor]
- >>88
二つの方法ですでに開発したことがあって比較した上での結論
- 90 名前：名前は開発中のものです。 mailto:sage [2008/11/16(日) 08:44:31 ID:SVunqIhe]
- 早いレスども
タスクシステムという名称は新しいものらしいけれど、
それ自体はかなり古い手法だろ？
当時対比されるべき「もう一つのやり方」は
アセンブリで非構造化の逐次プログラミングだったはず
当時のタスクの本質がコンポーネント指向にあったんだろうと考えれば
取り込む要素があると思いこそすれ、非難する気には全然ならないんだよね
なんつーか、フラッシュ使いがハイパーカードを非難してるようなモヤモヤを感じる
- 91 名前：名前は開発中のものです。 mailto:sage [2008/11/16(日) 08:50:18 ID:fOiOPCuz]
- ギャラクシアン - Wikipedia
ja.wikipedia.org/wiki/%E3%82%AE%E3%83%A3%E3%83%A9%E3%82%AF%E3%82%B7%E3%82%A2%E3%83%B3
タスクシステムの初出は１９７０年代
- 92 名前：名前は開発中のものです。 mailto:sage [2008/11/16(日) 08:56:45 ID:SVunqIhe]
- ちなみに旧ナ○コ系の一部では
ジョブコン（ジョブコントローラー）と呼ばれていたらしい
他にも派閥によって呼び名が・・・おっとだれか来たようだ
- 93 名前：名前は開発中のものです。 mailto:sage [2008/11/16(日) 14:53:09 ID:ekn4SUba]
- >>87
以前このスレでも話が出たMTなんとかのことですか？
- 94 名前：名前は開発中のものです。 mailto:sage [2008/11/16(日) 22:47:39 ID:JDXMEp1E]
- >>90
> 取り込む要素があると思いこそすれ、非難する気には全然ならないんだよね
C++ で仮想関数として取り込み済み。
- 95 名前：名前は開発中のものです。 mailto:sage [2008/11/16(日) 23:43:18 ID:fOiOPCuz]
- 70年代の技術でオブジェクト指向を表現したのがタスクシステム
- 96 名前：名前は開発中のものです。 mailto:sage [2008/11/17(月) 00:52:54 ID:d4ix+Z90]
- 別にゲームに限らず、関数ポインタ＋データブロックという構造はよく使われてたけどな。
UNIX のデバイスドライバとか UNIX V6 の頃から、こんな作りだ。
- 97 名前：名前は開発中のものです。 mailto:sage [2008/11/18(火) 00:07:12 ID:jVsaZ2Nt]
- >>92
だっせー
- 98 名前：名前は開発中のものです。 mailto:sage [2008/11/18(火) 01:47:54 ID:2bcqSLD5]
- 当時としてはすごい技術だったという話は
・いまタスク使ってるやつは擁護になってないからスルー
・アンチはそんなの知ったことじゃないから叩く
技術史が好きなヤツにしか意味のない話です
- 99 名前：名前は開発中のものです。 mailto:sage [2008/11/18(火) 02:15:13 ID:0/4z+Eh4]
- だからタスクシステムの要点は
・メモリ管理
・タスク管理
だって言ったじゃん
メモリフラグメントに対して固定長データという回答を出したのがタスクシステムの功績
そして扱うべきデータがどんなデータであれ管理レベルでは等価である事がタスクシステムか否かの分岐点だと思うね
ちなみに継承＋多態はメモリ管理、タスク管理のどちらから見ても最悪なばかりか速度まで低下して何のメリットもない
プログラムも複雑化してタスクシステムより尚悪い
あと余計な事かもしれないけど、このスレが迷走しやすいのは「何を解決するのか」を定義しないで話を進めるからだよ
例えば「ジャンルにとらわれない万能オブジェクト管理システム」なんていう途方もない事であっても目的があるとないのでは
議論の濃さが全然違う
最後に何度も言ってるけど、・・・タスクシステムを使うには現在のPCはオーバースペックすぎると思うよ
HSPでよくみかける固定長配列での管理よりわかりやすく速度的にも有利なタスクシステムなんて見たことないし
有意な差が出るとも思えない
- 100 名前：名前は開発中のものです。 [2008/11/18(火) 07:37:14 ID:P1O//Y8n]
- わけのわからんこと言い出すからレスが止まっちゃっただろ
- 101 名前：名前は開発中のものです。 mailto:sage [2008/11/18(火) 08:29:07 ID:RCT5hNLc]
- >ちなみに継承＋多態はメモリ管理、タスク管理のどちらから見ても最悪なばかりか速度まで低下して何のメリットもない
>プログラムも複雑化してタスクシステムより尚悪い
お前は継承も使わずにプログラムしてんのか？
- 102 名前：名前は開発中のものです。 mailto:sage [2008/11/18(火) 09:07:44 ID:HHT2Kui7]
- Cには継承ないよ
haskellには継承なんてないけどそれでも綺麗なコードの実用プログラムが沢山書かれてるよ
- 103 名前：名前は開発中のものです。 mailto:sage [2008/11/18(火) 12:59:38 ID:k/xr4HgC]
- なんで唐突に Haskell が出てくるのかわからんが
deriving とか知らないのか？
で、必死になってメモリ管理とか叫んでるひととか、バカにしようと必死な人とかは
スルーしたほうがいい気がする。
- 104 名前：名前は開発中のものです。 mailto:sage [2008/11/18(火) 16:11:47 ID:jVsaZ2Nt]
- >>99
＞タスクシステムっていうのは
＞ ・メモリ管理
＞ ・タスク管理
＞の2種類から構成されている
前スレログ読みましたが、クラスを使うとフラグメントが発生どうのとかよく分からない話をして
数人から突っ込まれてたID:IuSgJyHuさんですか？たぶんそうだろうかと私は思うのですが。
ところであなたの言う「タスクシステム」とやらは具体的に何なのでしょう。これと思う実装例が
あるならそれを示してくれませんか。人によって定義が千差万別の俺俺システム「タスクシステム」
ですから、その言葉を発する人間が登場する度にこうやって確認せざるをえないわけで。
このように、確固たる出典がない、言い方を変えれば権威が不在というのは不便なものです。
技術用語としての存在価値が疑問視され、所詮はローカル用語といわれるのも頷けます
＞メモリフラグメントに対して固定長データという回答を出したのがタスクシステムの功績
ん？70年代中期・末期において主記憶をページング方式で管理することに新規性があったと。
簡単のために操作対象を固定長に分割・管理する、つまり固定長レコード方式というものに
新規性があったと。そういうお考えで？
当時のソフトウェアエンジニアの通念というものが集計できるならば、あなたの考えは当時としても
非常に珍しい類のものだろうと思います。かなりエキセントリックだろうと思います
まぁ確かに、計算機についての基礎教養が欠乏、というかむしろ知的水準が絶望的に低い人間
にとっては世の中のあらゆる仕組みはあらゆる時代を通じて常に新規性に満ちた凄いテクノロジー
なのでしょうけど…
そういう知的弱者・情報弱者・底辺階級をターゲットにした功績話を絶叫するのはあなたの趣意ですか？
- 105 名前：名前は開発中のものです。 mailto:sage [2008/11/18(火) 16:24:48 ID:vNWKmyux]
- i君乙
あいかわらず厭味だねぇ
- 106 名前：名前は開発中のものです。 mailto:sage [2008/11/18(火) 22:15:12 ID:7msrEyPM]
- 変わらぬ芸風も、また一興
- 107 名前：名前は開発中のものです。 mailto:sage [2008/11/19(水) 02:14:42 ID:QielmcSv]
- >>101
今は継承を使わないのが流行り
おまえだってhasAにしてるんだろ？
特に深い継承はアンチパターンになりつつある
継承＋多態の効率の悪さはいわずもがな
ゲームで使っちゃいけません
>>102
継承は基本的に汚いコードになると思うよ
設計書は綺麗になるけど
>>104
ギャラクシアン以外をタスクシステムと呼んでるのは某よっちゃんいかの人だけだよ
固定長レコードというCOBOL的なものをゲームに持ち込んだのは新規性がある
そもそも固定長レコードはフラグメント解消のものではなかった
バナナでクギを打った所に新規性があるんだよ
トンカチあるから必要ないよねっていうのは別の話
- 108 名前：名前は開発中のものです。 mailto:sage [2008/11/19(水) 03:31:19 ID:FID+LaPo]
- >>107
"is a" 関係でも継承使わないってこと？それだと無理なコードにならない？
効率が悪いというけど、そもそもゲームで CPU 処理時間がボトルネックになること
すら稀なのに、さらにそのうち継承＋多態によるものは数％以下でしょ？
ヘビーなループ内では問題になることもあるだろうけど、はじめから使わない前提に
する必要は無いと思うよ。
- 109 名前：名前は開発中のものです。 mailto:sage [2008/11/19(水) 08:36:26 ID:yTZjB9bO]
- >>107
> 今は継承を使わないのが流行り
実装継承とインターフェース継承を混同しとるな。
- 110 名前：名前は開発中のものです。 mailto:sage [2008/11/19(水) 19:07:46 ID:U55fYg17]
- >>107
> 固定長レコードというCOBOL的なものをゲームに持ち込んだのは新規性がある
固定長レコードはそれよりずっと以前のパンチカード由来。例えば19世紀末のタビュレーティングマシン
そこから進化したユニットレコード装置とかPCS（パンチカードシステム）とか。（※）
この時点でパンチカードのレコード長は大抵【80カラム】。これが処理単位だった
それがそのままコンピュータの記憶装置に使われ、その後の記憶装置の仕様にも反映された
アセンブリ言語のプログラムは一行80カラム。データも同じく。メインフレームのRecord Oriented Filesystem
初期のFORTRAN、OSのジョブ制御言語、COBOLなどなど、あらゆる処理の単位としてこの【80カラム（バイト）】が
当然のごとく登場した
FORTRANが登場したのは1950年代の半ば
COBOLが登場したのは1950年代の末
（※）更に遡れば19世初頭のジャカール織機だとか18世紀末のオルゴールだとか色々あるかもだが
- 111 名前：名前は開発中のものです。 mailto:sage [2008/11/19(水) 19:37:40 ID:U55fYg17]
- （訂正）
> アセンブリ言語のプログラムは一行80カラム。
↓
アセンブリ言語のプログラムは80カラム単位でロードされた。
----------------------------------------------------------
>>170
> そもそも固定長レコードはフラグメント解消のものではなかった
固定長レコードとか固定長データとかいう構造（要するに配列）が大昔から現在まで色んなところで
便利に使われてるのはその取り扱いが、実装が、極めて単純だから。
例えば
・データの所在（番地）が容易に算出できる
先頭番地+オフセット。このオフセットがレコード長*レコード番号で済む。
処理が単純化できるし回路も単純化できる。つまり真空管数（トランジスタ数）を抑えられる
占有面積も重量も放熱設備も電気料金も抑えられる。
・外部フラグメンテーションの制御が簡単
記憶領域を【容易に】再利用できる
最大長を決めてるからデータ書き換え時には旧データに新データを直接上書きできる
などなど。頻繁に書き換えるデータにはどれも重要な特性。
固定長なデータ構造はそのメリットの大きさゆえに、デメリット（レコード内の無駄。内部フラグメンテーション）
が許容されるケースは多い。COBOLも、COBOLが登場する以前の事務処理プログラムも可変長データの大半は
最大サイズを決めたうえで固定長レコード、それを収束した固定長ブロックで格納した。
今のRDBや簡素なDBMも基本的には同じ
- 112 名前：名前は開発中のものです。 mailto:sage [2008/11/19(水) 20:12:26 ID:U55fYg17]
- >>170
> バナナでクギを打った所に新規性があるんだよ
> トンカチあるから必要ないよねっていうのは別の話
その例え何かおかしくないか。常温バナナで釘を打つのは確かに斬新な愚行だが
規模がまるで違うものを指してトンカチと冷凍バナナという話をしているのかなと前向きに解釈してみるか
大昔には科学者もエンジニアもシステム屋もみんな今とは比べ物にならないくらい貧弱なハードでやり繰りしてた。
FORTRANやCOBOLが登場する以前の計算機を駆使する人間は多かれ少なかれ今で言うところのハッカーじみた
技能やバッドノウハウを身に付けて自前のサブプログラム群をシコシコ作って自前ライブラリ用意したりした。
FORTRAN登場後も初期のFORTRANコンパイラの最適化は不十分で最内周ループ処理など頻繁に呼び出す処理の
アセンブリコードを自分で書く利得は大きかった。（※）
これらは日本のビデオゲーム業界が隆盛を誇るずっと以前の話
つまり、ド貧弱な装備でシコシコ戦うことを強いられ、セコくて貧乏くさい高速化テクやリソース節約テクを駆使してたのは
何もゲーム業界固有の境遇・逆境だったわけじゃない。もしゲーム業界固有だなどと思い込んでる人間がいるなら
そいつはルサンチマン君だ
（※）その後BLAS、LAPACK、MPIなどなど先人の開発した優れたライブラリが沢山登場し
FORTRANコンパイラの最適化機能もとても優秀なので自前でシコシコする必要なくなった
- 113 名前：名前は開発中のものです。 mailto:sage [2008/11/19(水) 20:14:33 ID:U55fYg17]
- （訂正）
>>170
↓
>>107
＞規模がまるで違うものを指してトンカチと冷凍バナナ
↓
本来の用途がまるで違うものを指してトンカチと冷凍バナナ
- 114 名前：名前は開発中のものです。 mailto:sage [2008/11/19(水) 22:25:30 ID:1obj959Z]
- >>108
俺も継承は使わないほうがいい派
実装とかインターフェイスとか関係無い
そのメソッドやメンバがどのクラスのものであるのかわからなくなるのが最大の害だと思う
しかもオーバーライト（？名前忘れた）されると今度は同じ名前のメソッドがあって
どれを呼んでるのか本格的にわからなくなる
どうしても使わなきゃならんのがMFCみたいな変態実装になってる場合
自分に内包してるモンを継承使って書き換えさせるウンコソース
これは仕方がない
でも、できるだけhas aの関係でまとめたほうがいいと思う
- 115 名前：名前は開発中のものです。 mailto:sage [2008/11/19(水) 23:52:57 ID:GeiIfEUV]
- >114
ttp://www.bizlogic.co.jp/techinfo/reconsider/inherit.htm
>新人プログラマほど継承を乱用します．特に新人が好むのは、
>コードの再利用のための継承です．（中略）
>新しいサブクラスが必要になって定義しようとしたら、親ク
>ラスに不整合があることを発見して修正．すでに定義済のサ
>ブクラス群に影響が出るためそれらを修正．その影響がクラ
>スのクライアントに出ることに気づかず、バグが連発．修正
>を繰り返すうちに設計し本人しか理解できないような継承階層が完成･･･
ｲｲﾊﾅｼﾀﾞﾅｰ
耳の痛いことだが、とりあえずタスクシステムのせいじゃないと思うんだw
- 116 名前：名前は開発中のものです。 mailto:sage [2008/11/19(水) 23:59:13 ID:GeiIfEUV]
- ギャラクシアン以外をタスクシステムとして認めない原理主義者が現れてスレ的には
おめでいたいことだが、狭量すぎやしないか？
とりあえずメモリ管理については
・当時はそもそも自前のメモリ管理以外存在しない。
・メモリに制約のあるシステムならタスクシステムでなくても必要
だから、タスクシステムの絶対条件じゃないと思うんだが。
- 117 名前：名前は開発中のものです。 mailto:sage [2008/11/20(木) 00:34:43 ID:9Z88vxLa]
- そもそも当時と今とでは
「メモリ管理」って言葉が指すものがだいぶ違うからな。
今のゲーム開発だと
メモリ管理モジュールの綿密なアーキテクチャの設計と実装を主に指すけど、
当時のは「管理モジュール」なんて呼べないような極々シンプルなものだからな。
- 118 名前：名前は開発中のものです。 mailto:sage [2008/11/20(木) 00:39:08 ID:K7xBu4Cw]
- 連投ｽﾏﾇ ちと古いが、>>44
ttp://www.t-pot.com/program/140_GameAISeminar4/index.html
Haro2のAIは階層型FSMとやらで実現されているそうだ。
>>41によれば「タスクシステム=FSM」だそうだから、タスクシステムでできそうな
気がするというのもあながち的外れではないかもよ。
もっとも、50がいう配列厨もFSMの一実装じゃねーのと思うので
タスクシステム=FSM=配列厨となって自己矛盾じゃないのかとか思ったり。
なんかFSMの解釈間違ってる？
- 119 名前：名前は開発中のものです。 mailto:sage [2008/11/20(木) 00:52:20 ID:K7xBu4Cw]
- >>117
CUDAを調べてて思ったんだが、メモリ・ワークをどこにとるかでパフォーマンスが
大幅に違ったりするみたいだし、いまどきのゲームのメモリ管理ってそうなんだろうな
- 120 名前：名前は開発中のものです。 mailto:sage [2008/11/20(木) 01:35:27 ID:sLhTakp+]
- ３スレ目になったが、今だに喧嘩腰じゃないと議論もできないのか・・・
- 121 名前：名前は開発中のものです。 mailto:sage [2008/11/20(木) 01:41:10 ID:K7xBu4Cw]
- >>120
喧嘩腰に見える？そりゃすまん。
- 122 名前：名前は開発中のものです。 mailto:sage [2008/11/20(木) 03:32:51 ID:sLhTakp+]
- ああいや、個人を指してるわけじゃなくて、
スレ全体の雰囲気のことを言ってる。
- 123 名前：名前は開発中のものです。 mailto:sage [2008/11/20(木) 23:36:18 ID:Xvygn8lQ]
- >>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 みたいなやつ）と
簡素なリモートデバッガ、エディタ、クロスアセンブラ（別にハンドアセンブルでもいいけど）で構成されるもの
- 124 名前：名前は開発中のものです。 mailto:sage [2008/11/20(木) 23:39:52 ID:Xvygn8lQ]
- （訂正）
○MHzの8bitCPU
↓
○MHzの8or16bitCPU
- 125 名前：名前は開発中のものです。 mailto:sage [2008/11/21(金) 01:39:25 ID:gOWsGtVr]
- >>123
そういう立ち位置なんだとすると余計にわからなくなるのよ。
>「ここでタスクシステムと呼ばれてるものが何なのか知らんけど」
という立ち位置の人間が、ゲーム開発者ローカルな用語である「タスクシステム」
という用語とそのスレッドで、
>タスクシステムすげぇすげぇ言ってる超小規模開発・個人開発なら
てな形で批判的な言説を繰り返す理由が。てっきり
>タスクシステムを心の底から崇拝する人間が心の底から子バカにしている様子がたまに見受けられる 配列厨のコードそのものだ。
という形で小ばかにされたことをこのスレにぶつけてるんだと思ったよw 俺の立場としては
>ゲームプログラムでは、複数の構造体変数を管理することにより、複数のキャラクタを
>管理できます。複数の構造体変数を管理するための方法は、構造体をリスト構造で管理
>する方法と構造体を配列で管理する方法の 2 種類あります。
ttp://msdn.microsoft.com/ja-jp/academic/cc998623.aspx
の実装方式の一つだろうという前提で、そのメリットデメリットに興味があってここに参加しているのだけども。
ちなみに上記の例でいえば、マイクロソフトは配列厨だなw
- 126 名前：名前は開発中のものです。 mailto:sage [2008/11/21(金) 01:41:47 ID:Ch23O/ls]
- >>120,122
タスクの話題に限ったことじゃないけど
賛成か反対かの単純な対立に流れることは多いね。
わかりやすいから盛り上がるけど白熱しすぎて喧嘩になったりする。
でもその対立構造が正しいとは限らなくて
良い意見が喧嘩に埋もれてしまったり。
ゲーム製作技術板なのに技術の話じゃなくてすまん。
- 127 名前：名前は開発中のものです。 mailto:sage [2008/11/21(金) 02:31:22 ID:gOWsGtVr]
- >>126
確かにそうだ。俺も何が対立軸なのかよくわからなくなってるよw
俺は情報系の人間じゃないんで、ゲームのオブジェクトの相互の振る舞いは
FSMの一形態と見なせるみたいな発言を単純に面白いなと感心するんだけど。
- 128 名前：名前は開発中のものです。 mailto:sage [2008/11/21(金) 02:35:33 ID:EpPTVUTk]
- 配列で線形リストも組めない雑魚が配列をバカにしてるのを見ると悲しくなるし、
そもそもタスクシステム（特にこのスレで主流の複雑な実装）は速度的に不利なんだから
素直に配列さんごめんなさいって言えばいいと思う
- 129 名前：名前は開発中のものです。 mailto:sage [2008/11/21(金) 21:53:14 ID:HLQRvhCb]
- この3連休でタスクシステムの仕様についてまとめるように、以上。
- 130 名前：名前は開発中のものです。 mailto:sage [2008/11/21(金) 23:55:06 ID:gOWsGtVr]
- >>128 が、>>123だとして、わからん、お前のいうことはわからん！（大滝秀ry
>配列で線形リストも組めない
どこかで queue を配列で組む入門例があったけど、そんなものじゃないだろうし、
だとしてもその線形リストで、まさかタスクシステムをつくるわけじゃなかろうし、わからん。
>雑魚が配列をバカにしてるのを見ると悲しくなるし
どのレスを指しているのか、わからん！
>このスレで主流の複雑な実装
どれだよ！>>43なんか、
>誰が書いても同じようなものになるってくらい凡庸な、道端の雑草並みのありふれた仕掛け
とかいってるぞ。凡庸でありふれて複雑て、どっちなんだよ。
>速度的に不利
いや、ロジックの部分は大して食いませんてば。最近のゲームはそうでもないのか？
>素直に配列さんごめんなさい
君が配列ラブなのだけはなんとなくわかったよ。ごめんな。
- 131 名前：名前は開発中のものです。 mailto:sage [2008/11/22(土) 06:09:06 ID:gy1lHoyD]
- >>128は書いてる内容から明らかに雑魚だなｗ
- 132 名前：名前は開発中のものです。 mailto:sage [2008/11/24(月) 11:26:55 ID:bZE/I6Oe]
- >>129
いまどきのタスクシステムの仕様
１．クラス名、構造体名に「Task」を含む
２．描画物とそれ以外の処理を同列に扱える（ことがある）
これくらいじゃね
- 133 名前：名前は開発中のものです。 mailto:sage [2008/11/24(月) 23:39:25 ID:0qULllkp]
- 「ゲームプログラマになる前に覚えておきたい技術」
を読んだけどタスクシステムなんて使ってなかった
普通に配列使ってて、配列の上手な使い方がのってた
やっぱプロは配列を使うんだね
- 134 名前：名前は開発中のものです。 mailto:sage [2008/11/24(月) 23:42:11 ID:L4g5tFOs]
- >>133
２ｃｈでしかでかい声は聞かない（マジで）
- 135 名前：名前は開発中のものです。 mailto:sage [2008/11/24(月) 23:58:55 ID:c7RL3I32]
- >>133
はいはい、配列さんごめんなさい。
>>133は、配列の利便性と構造体を使ったリストの有用性の違いがわかっていないようだ。
もう一度、データ構造を見直すことをお薦めする。
- 136 名前：名前は開発中のものです。 mailto:sage [2008/11/25(火) 00:45:31 ID:iVVKZxJp]
- >>133
おま・・・リスト使うか配列使うかの話かよｗ
セガがリスト使わないなんてありえないから、安心して両方の使い方を覚えような
ついでに二分木やハッシュも覚えておくこと
- 137 名前：名前は開発中のものです。 mailto:sage [2008/11/25(火) 00:58:47 ID:nYppp7MY]
- 配列 ： 削除、追加時のコストが高い。検索が速い
リスト ： 削除、追加時のコストが安い。検索が遅い
リストは単純に舐めるだけでも遅い
ここで比べるべきなのはデータの検索（巡回）・追加・削除がゲーム中にどれだけ発生して
それを処理するにはどんなアルゴリズムとデータ構造がベターであるかだ
データの検索（巡回）よりも追加と削除のほうが多いゲームなどない
だからリストより配列のほうがゲームに適している
リストの有意点とはデータサイズの見積りをサボれるという一点に尽きる
たしかに配列のリサイズはゲーム中にはとても不可能だからこれは魅力だ
しかし、ゲームを製作する上で場面ごとに必要なメモリの見積もりなんてやって当たり前の話で
その程度の理由でリストを使うなんておかしい
以上の理由からゲームでリストを使う事はない
弾幕STG等ひたすら衝突判定を繰り返す場合なら
検索アルゴリズムの都合で配列よりツリーがベターな場合もある
（STG製作技術スレで話題になってたエリア別ツリー構造等。FPSでよく使われるが）
だから配列がベストとは言わないが少なくともリストに劣ることは無い
- 138 名前：名前は開発中のものです。 mailto:sage [2008/11/25(火) 02:46:59 ID:WElvD00o]
- いつからリスト対配列になったんだ?
タスクシステムは固定長データが重要とか言い出した>99あたり?
つか>126じゃないけどその対決って
どうしても勝ち負けを決めないといけないようなことなの?
- 139 名前：名前は開発中のものです。 mailto:sage [2008/11/25(火) 13:07:00 ID:iVVKZxJp]
- >>137
もっともらしくウソついてんじゃねーよ
わざと言ってんだろ。明らかに初学者に対して悪意のあるウソだな
>リストは単純に舐めるだけでも遅い
誤り。「単純に舐める」＝シーケンシャルアクセスに有意差はない。
配列が有利なのはランダムアクセスの場合。
>データの検索（巡回）よりも追加と削除のほうが多いゲームなどない
比較方法の誤り。巡回回数と挿入回数を単純に比較しても意味はない。
コストの違いは以下のようにO記法で考えると分かりやすい。
・シーケンシャルアクセス（巡回）のコスト
配列はO(n)：要素数が増えると処理時間が増える
リストもO(n)：要素数が増えると処理時間が増える
・ランダムアクセス（インデクス値でアクセス）のコスト
配列はO(1)：要素数が増えても処理時間は変わらない
リストはO(n)：要素数が増えると処理時間が増える
・挿入、削除のコスト
配列はO(n)：要素数が増えると処理時間が増える
リストはO(1)：要素数が増えても処理時間は変わらない
O(1)はO(n)に対して非常に有利なので、
ランダムアクセスがありそうなら配列を、挿入がありそうならリストを選ぶのが一般的。
どちらもありそうなら実際に処理時間を計測してみるのが良い。
処理時間とは別に、メモリのフラグメントを嫌ってリストを避けたい場合は、
データ本体は配列構造に置き、管理はＺソートされたリスト構造に、
というように両方を組み合わせる手法もある（C++オブジェクトをメモリプールするのと同じことだけどね）。
とにかく、初学者は「どっちが勝ち」みたいな議論に振り回されないこと。
ぶっちゃけ実際に動かしてみて問題がないなら、なんであれそのやり方は正しい。
- 140 名前：名前は開発中のものです。 mailto:sage [2008/11/26(水) 00:21:42 ID:wcFZ5Gxi]
- ID:mdtDWXyh、ID:U55fYg17、Xvygn8lQ だが…。どうしたもんかね。とりあえず俺にレスした人から順番にレスするか…
> ID:K7xBu4Cw、ID:gOWsGtVr
>>123の時点では↑この人の諸元と過去発言を把握できなかったがサンプル数が増えたおかげで大凡のところ見当が付いたわ。
まず俺の一連の書き込み（ ID:mdtDWXyh、ID:U55fYg17、Xvygn8lQ ）から「タスクシステム＝FSM」という解釈に至るのは難しい（※）
①FSMの意味をよく理解していない②人の話をよく聞いてないか③意図的に歪曲して解釈しようと努めている、のどれかだろう。
①ならFSMや有限状態機械でググレとしか言えんし②ならちゃんと読んでくださいとしか言えんし③なら正直相手にしたくない
奇遇にも過去にこの人物と同じ解釈「タスクシステム＝FSM」を披露したのはルサンチマン君のID:SCRh4oL7ただ一人だ。
ID:K7xBu4Cw 、ID:gOWsGtVrがこれと同一人物なのか知る由も無いが、かなり似通った特徴的な思考・読解の持ち主だなとは思う。
さて、この人は更に>>130で「>>128 が、>>123だとして」という謎めいた仮定を持ち出してるのだが、なんでこうなるんだろうね…
俺の過去発言と照らし合わせれば無理があると容易に分かるはずだよな
この人は>>130で自らそれを説明してみせているにも関わらず、その仮定が真であるという前提のコメントを書くだけで
その仮定が偽であるという（当然あってしかるべき、より可能性の高い）前提のコメントは結局書くことはなかった。妙だね
・ただ単にコミュニケーション能力の不足、悪意のない、無知、短気、舌足らずゆえにこういう尻切れトンボで終わった
・「>>128 ＝>>123であってほしい。いやむしろそうあってくれ。頼む。これで終いにしよう」という願望の現われ
まぁ後者ならそのご期待には添えないとしか言えない
俺は配列に「さん」付けしてもらうことも、ましてや便所のラクガキにおいて初心者（？）に謝ってもらうことにも興味がない
- 141 名前：名前は開発中のものです。 mailto:sage [2008/11/26(水) 00:23:32 ID:wcFZ5Gxi]
- （※）素直な思考の持ち主ならば、ゲームプログラムの中で【状態を保持し遷移する】ような要素、つまりFSMモデルを適用しやすいもの
としてまず初めに思い浮かぶものといえばシーン（オブジェクト）やエンティティだろう。そういったもの⊂FSMと解釈するならわかる
＃>>2そのものをFSMとして説明することはできるが、これを言い出したらプログラムも電子計算機も社会基盤も自然環境も惑星も
＃銀河も宇宙もFSMモデルで説明できるという話になる。ぬるま湯に溶かしたハナクソを構成する分子の振る舞いも、乾いて風化した
＃ハナクソ粉体の振る舞いもFSMモデルで滔々と説明できるという話になる。こういう話は埒外であり、するつもりはない
- 142 名前：名前は開発中のものです。 mailto:sage [2008/11/26(水) 01:14:00 ID:bxsuU9Ti]
- 話が難しすぎてついていけません＞＜
- 143 名前：名前は開発中のものです。 mailto:sage [2008/11/26(水) 02:19:03 ID:RbP/LZbz]
- >>140が誰と何の話をしてるのか全然わからんけど
>>2＝「ジョブコン」＝ＦＳＭという話は直感的で分かりやすいと思うぞ
てか名称「タスクシステム」は人によって定義が違うから使うな。議論が混乱する
- 144 名前：名前は開発中のものです。 mailto:sage [2008/11/26(水) 02:34:19 ID:RbP/LZbz]
- ああ、>>140をフォローしたつもりが逆だったらしい
>>140はＦＳＭって言い方が抽象的すぎるっつってんのね？
了解。もう言わん
- 145 名前：名前は開発中のものです。 mailto:sage [2008/11/26(水) 08:30:23 ID:P2jaFZy4]
- >>137
冗談だろって思って配列にしたら速くなった
たぶんキャッシュ周りも関係してる気もする
- 146 名前：130 mailto:sage [2008/11/26(水) 23:22:37 ID:QqsnFsqJ]
- >>140
>①FSMの意味をよく理解していない②人の話をよく聞いてないか③意図的に歪曲して解釈しようと努めている、
どれもそれなりにあてはまるとは思うが、あえていうなら②かなw
とりあえず③についてはそういう意図も一部あったんでそれは謝っとくよ。
ただ、前提として >>40,>>41で繰り返された
>ここでタスクシステムすげぇすげぇ言ってる
というような傾向は無いとはいわんけど（タスクシステムスレだし）、実装で苦労してるみたいな話が中心で、
mdtDWXyhが挑発的な言辞を繰り返さなきゃいかんほどかね？と思うけどな。
- 147 名前：130 mailto:sage [2008/11/26(水) 23:23:39 ID:QqsnFsqJ]
- >「タスクシステム＝FSM」を披露したのはルサンチマン君のID:SCRh4oL7ただ一人だ。
これは順番が違う。同じレスを指してると思うんだけど、
(1)「タスクシステム＝FSMだ」という発言があった。
(2) そのあとに >>41で「原始的なFSMモデルのジョブ制御」という発言があった
ので、同一人物か同じ立場の人間が批判的な意味で FSMという単語を使ってるのかな？と思ったんだよ。意味合いは違うようだけどFSMという用語を使うレス自体が少なかったからそこは勘弁。
その上で、ゲーム上のオブジェクトの振る舞いをFSMモデルで捉えることはできるだろうけど、それは配列で構成されたゲームについても言えることで、タスクシステム（実装）批判につなげるのはおかしいんじゃないの？と皮肉ったつもりだったのよ。
- 148 名前：130 mailto:sage [2008/11/26(水) 23:28:25 ID:QqsnFsqJ]
- ただまあ、タスクシステム（ジョブコンでもいいや）の適用範囲とか実装上の問題点と
か、そういう流れになってくれると嬉しいんで、「これで終わりにしてほしい」という
のも正直なところ。だからピンダッシュに反応しすぎた俺も悪い。もうだまっとく。
- 149 名前：名前は開発中のものです。 mailto:sage [2008/11/26(水) 23:53:44 ID:wcFZ5Gxi]
- >>139と>>137のお話について横から首突っ込んで初学者向けにポエムを書いてみるか
実際の処理速度を語るとき、ランダムアクセスといったら、メモリアドレスを基準にしたランダムアクセスという話も当然絡んでくる
データ構造上の順番（連結リストなら繋がれた順番）を基準にしたらリニアアクセスだよ、といってもメモリアドレスを基準にしたら
ばっちりランダムアクセスになっていました、という状況も当然あり、この場合は処理する要素数と要素サイズと実装対象によっては
べらぼうなペナルティを受けたりする。ので
>>リストは単純に舐めるだけでも遅い
>誤り。「単純に舐める」＝シーケンシャルアクセスに有意差はない。
これは状況ごとにプロファイラなりアナライザにかけて検証してみないと分からないというツマラナイ結論に帰結する
ので
>とにかく、初学者は「どっちが勝ち」みたいな議論に振り回されないこと。
>ぶっちゃけ実際に動かしてみて問題がないなら、なんであれそのやり方は正しい。
だよな
（続く）
- 150 名前：名前は開発中のものです。 mailto:sage [2008/11/26(水) 23:55:50 ID:wcFZ5Gxi]
- （続き）
ただし、連結リストを>>2のように使う場合と、ジョブの種類別に配列でデータを固めてる場合（※）を比較すると、前者は不利な状況に追い込まれる
>>2は何でもかんでもごった煮の連結リストでおまけに各要素は好き勝手にジョブを指定してくる。プライオリティ（？）とかいう変数を何に使うのか
知らないがこれでソートされてようが各要素で毎度毎度サブルーチンのアドレス（関数ポインタ）経由でジョブを実行させている
つまりハードウェアにとっては要素ごとに何のジョブを実行するのか予測が難しい。どのジョブが実行されるにせよ、その内容が大して代わり映え
のない超単純な数値積分であれば、分岐予測で速度を稼ぐハードウェアにとっては嫌がらせに近い仕掛けであり、ブチ切れる可能性が高い
○万のパーティクル（数千の通常弾に数千の煙に数千の閃光に数千のフラグメント）を撒き散らす物量ゲーとかなら、そういう要素には
>>2ではなくジョブの種類別に配列でデータを固めて一括処理するほうが速度が出やすくなる。
趣味プログラマであれば、今様のゲーマー仕様PCで実験してみればすぐに確認できる
（※）この手の配列厨コードは、Zソートを回避するあるいはCPUによるZソートを回避する色んな工夫とセットになる。
単純な加算合成だけでなく、アルファブレンドなしアルファテストのみテクスチャに描いてグレア処理して合成とか色々
- 151 名前：名前は開発中のものです。 mailto:sage [2008/11/27(木) 00:37:08 ID:q61URdTy]
- >要素ごとに何のジョブを実行するのか予測が難しい
その辺は面白い、つか考えてなかったな。
以前、ビデオキャプチャしたYUY2をP4-2.4GHzでソフトRGB変換する、ってのをやってて、
30万ピクセルをfloat演算して1フレーム8msec.程度でで処理できてたから、いまさら数万の
オーダーでがたがたいうなよって思ってたけど、言われてみれば配列のシーケンシャル
処理に近いんで、キャッシュの効かなそうな処理なら、どのくらいで処理してるのか確
認すべきだな。
- 152 名前：名前は開発中のものです。 mailto:sage [2008/11/27(木) 00:57:00 ID:q61URdTy]
- >プライオリティ（？）とかいう変数を何に使うのか 知らないが
これはメリットというより必要悪に近いんじゃないかな。ゲーム上のオブジェクトを
動的に生成するタイプのタスクシステムだと、処理順が不定になってしまうので、
プライオリティという形で処理順を明示できるようにしてある、みたいな。
そこまでして処理順を確定しないといけないような場面があるのかどうかは
ちょっとわからん。初心者なもんで。
- 153 名前：名前は開発中のものです。 mailto:sage [2008/11/27(木) 05:33:57 ID:d1RPtk1Q]
- 処理順は固定じゃないと駄目なんだよ
壁当たりの判定を保持するような物体の当たりチェックは
普通の物体のチェックより後にやらないと
簡単にすり抜けが発生してしまう
俺、当たりのチェックだけはタスクシステム使ってようが
直書きしたほうが安全な気がする
- 154 名前：名前は開発中のものです。 mailto:sage [2008/11/27(木) 06:07:57 ID:qLIfWPBB]
- プライオリティについては>>2のWhite PaperとLogician Lordでは
リストに連結されたタスクの中身が何なのかを示すために使われてる。
例えばここだな。
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リストに入れりゃいいんだよ。
別に配列でもいいが。
- 155 名前：名前は開発中のものです。 mailto:sage [2008/12/01(月) 12:21:06 ID:+Gl5Bh4T]
- ピンキーネット所属の藤松みこを最初の辞職に追い込んだは
フリーで湯沢と言うビデオカメラマン（元アートハウスゴン社員）から陰部に指を挿入されたことが原因だ！。
当時現役だった彼女にはショックな出来事で事務所とメーカー巻き込んで大騒ぎ。
カメラマンは土下座しただけで金銭は請求されなかったのは何故か疑問だったが…。
（意外と優しい事務所だったりして…。）
普通は事務所から脅され賠償金を請求され業界追放に追いこまれるだろう！
ちなみにセクハラ事件でカメラマンの追放まで追い込んだ領家ゆあの前事務所とは雲泥の差だ。
また普段から公私混同するカメラマンとして有名だし次回彼の標的になる10代のアイドルが気になるところだ。
- 156 名前：名前は開発中のものです。 [2008/12/01(月) 13:32:33 ID:zCQmgzIM]
- ttp://www.page.sannet.ne.jp/hirasho/diary/diary0811.html#30
>タスクシステムについて触れられてない、とか書かれているのを見つけた。
>何それ？おいしいの？直感的でない、変に抽象化されてデバグしにくい、実行順がコードの形で書かれておらずメンテしにくい、
>等々、どう考えてもあれが有効な場面があるとは思えない。使っている人を問いつめたことがあるが、結局利点は出てこなかった。
>一つ考えられるとすれば、独立性をきちんと保って各タスクを書いていればマルチスレッド対応がしやすそう、ということくらいか。
>しかし、どうせ複数タスクから同一のクラスインスタンスを参照してたり、妙なシングルトンやらグローバル変数を見てたり、
>依存関係が不適切なためにスケジューリングが複雑化したりするに違いなく、本当にマルチスレッド実行していい状態にあることを保障するのは容易ではない。
>よほど訓練されたチームでなければそんなことをする気にはまるでならない。
- 157 名前：名前は開発中のものです。 mailto:sage [2008/12/01(月) 19:17:54 ID:JLnsfkv1]
- だからタスクシステムなんて聞くのは２ｃｈだけだって
ここの信者だけだよ威勢がいいのｗ
だって現場で聞いたことないもんｗ
- 158 名前：名前は開発中のものです。 mailto:sage [2008/12/01(月) 21:32:13 ID:igKS/Zf4]
- 大手ならどこでも通じる
- 159 名前：名前は開発中のものです。 mailto:sage [2008/12/01(月) 22:17:35 ID:JLnsfkv1]
- >>158
そしたら下請けに流れてきてもおかしくないじゃん
- 160 名前：名前は開発中のものです。 mailto:sage [2008/12/01(月) 23:06:38 ID:/JTH9VCP]
- 俺は自分からは使わんが、他社の２回くらい見たぞ？
もちろん>>2そのままじゃなかったが、ネットでよく聞くから増えてんじゃね
つーかさー、NDSのサンプルよく読んでみろよ・・・
現場で見たことないって騒いでるやつはDS開発やったことないのか？
- 161 名前：名前は開発中のものです。 mailto:sage [2008/12/02(火) 01:05:14 ID:68pyN8gN]
- ｻﾀｰﾝしかやったこｔない
- 162 名前：名前は開発中のものです。 mailto:sage [2008/12/02(火) 08:48:36 ID:2eboyQhG]
- 俺は、据え置き型ばっかり
- 163 名前：名前は開発中のものです。 mailto:sage [2008/12/02(火) 17:21:35 ID:2m2wCEKn]
- ttp://www.page.sannet.ne.jp/hirasho/diary/diary0812.html#2
ひらしょ氏、今日の日記でも検討してるな。
いずれにしても銀の弾丸じゃないのは当然として、鉛の弾丸かどうかは微妙なところか。
否定派のつもりはないけどね俺。
- 164 名前：名前は開発中のものです。 mailto:sage [2008/12/02(火) 19:37:52 ID:RctAWrR8]
- >>163
いいなこの人
説明に難しい言葉を使わないようにしてるし
ちゃんと人に伝えようという文章に好感が持てる
- 165 名前：名前は開発中のものです。 mailto:sage [2008/12/02(火) 20:12:02 ID:VDtsWa1y]
- たしかに
タスクシステムとは可搬性と再利用性に優れた素晴らしいシステムなんです
とか繰り返してた人たちの話よりよっぽど分かりやすい
- 166 名前：名前は開発中のものです。 mailto:sage [2008/12/03(水) 02:05:13 ID:lPaxGufd]
- ひらしょ氏の日記見て来ますたｗ
つか、ヒープのフラグメント避けるためにサイズの違うデータでも固定長メモリ確保するとか
俺が学生時代にごくナチュラルに作ったものだが・・・。メモリプールという言葉の存在すら知らないまま。
まずさ、ゲームで使われている技術なんて、3Dやら除けば全然大したことがなくて
独自性などどこにもなということを認識するべきじゃなかろうか。とりわけ今となっては。
> だからタスクシステムなんて聞くのは２ｃｈだけだって
昔のアマゲ周辺でそれなりに聞いたかな。某よっしん氏等も使ってた記憶が。
ただ、言葉は聞くけど実体は人それぞれという類のものだよね。
オブジェクトをリストで繋げて更新ルーチンへのポインタ保持してるだけで
俺がガンダムだって言っても、言葉の定義なんかないんだから自由なわけだしさ。
実際、昔言ってたタスクシステムもその程度の代物でしかなかったと思うんだよ。
そうだな、それでも、C++がまだ使われていなかった頃はそれなりに画期的、というのもちげーな
「ああこうすればいいのか」と人を感心させられる程度のものではあったかもしれない。
ひとつのテクニックとして名前をつけて呼ぶ価値があったと思うよ。10年以上前の話。
でも、今となってはこんな普通にC++で書けば自然にできるようなことをシステムなんてとても呼べないし、
それでもタスクシステムという名前にこだわってる人は、もっと高度な何かを語ってると思うんだが
何それ？っていうか、要らんよねぶっちゃけというか、コード見せれ、というか
俺としては、C・アセンブラ時代に言ってたタスクシステムが、ものすごいタイムラグを経て、
一部のアマチュアに、おかしな形で伝わってしまっただけじゃね？と思っているのだが。
もしそうだとすれば、素人を混乱させる有害情報でしかないので火消しが必要なレベルだと思う。
そうでないなら、とにかくコード見せて。
- 167 名前：名前は開発中のものです。 mailto:sage [2008/12/03(水) 02:14:33 ID:Smp60beT]
- >164は>165を指してるんだよね。
pc11.2ch.net/test/read.cgi/gamedev/1036512390/860-862
- 168 名前：名前は開発中のものです。 mailto:sage [2008/12/03(水) 03:28:15 ID:uVk3FrZq]
- そのスレ読んだ
LGPLを含むEXEがLGPLに感染してるなんてライセンス文読めば一目瞭然のことを
何とか超解釈で否定しようとしてる子が定期的に出没していて
その理屈は違くね？という人達が理詰めで外堀から確実に徐々に埋め立ててる
そんな感じ？
物事をひん曲げて解釈したがる人を諭すには
駄目押し気味でもああいうのも有効かなとはおもた
- 169 名前：名前は開発中のものです。 mailto:sage [2008/12/03(水) 11:42:42 ID:YzqEx1FO]
- >>167
あのスレのレスは三行でまとめて欲しい
>>168
あのスレごちゃごちゃしすぎてて、自分で何書いたかさえ忘れる
ところで、感染しないライセンスなんて無いよ。例えパブリックドメインであっても。
結合したら二次著作物なんだから。
- 170 名前：名前は開発中のものです。 mailto:sage [2008/12/03(水) 12:08:41 ID:1jatayxx]
- >>169
二次利用に縛りをかけないライセンスは存在する。
ていうか、パブリックドメインとは、だれのものでもない存在だから、
二次著作物とかそういう縛りもない、はず。
- 171 名前：名前は開発中のものです。 mailto:sage [2008/12/03(水) 12:59:17 ID:YzqEx1FO]
- >>170
うーん、有名どころで二次利用に縛りをかけないライセンスを見たことないけどな。
少なくとも「本ライセンス文書を同封しろ」と書いてある。
パブリックドメインに関しては著作権者が権利放棄してるから、利用に縛りはないだろうけど。
- 172 名前：名前は開発中のものです。 mailto:sage [2008/12/03(水) 13:23:37 ID:6uS+aRN8]
- >>169-170
おまえらあっちのスレでやれ。
>>168
むしろ逆効果にしか見えないのだが、
前スレで釣り宣言してたからそれで狙い通りなのだろう。
- 173 名前：名前は開発中のものです。 mailto:sage [2008/12/03(水) 13:25:50 ID:ls+0FiDV]
- 三次利用以降に縛りをかけない事、という縛りをかけてるものはあるな
- 174 名前：名前は開発中のものです。 mailto:sage [2008/12/04(木) 00:21:20 ID:J8DrEDup]
- 数年前のとある同人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;
}
- 175 名前：名前は開発中のものです。 mailto:sage [2008/12/04(木) 00:28:18 ID:J8DrEDup]
- _tmainじゃなくて_tWinMainだったかな。よくおぼえてないや
各シーンはいわゆるベタベタの配列厨コード。元HSパーだから仕方ないね
でもメモリもGPUリソースもジャブジャブ使いまくったおかげで
見た目はバリバリのイケイケになったよ。動作も軽快だったよ。自惚れだね
- 176 名前：名前は開発中のものです。 mailto:sage [2008/12/04(木) 02:00:33 ID:yi3zavJ4]
- >>174
たのむ
なにが言いたいのか最後に書いてくれ
俺が気になるのは、メインループが本当に必要なのかどうかだな
タスクシステムも、それ以外のＣ＋＋コードでも、なんでメインループ作るん？いらなくね？
普通に書けばいいじゃん（普通ってなによ）
- 177 名前：名前は開発中のものです。 mailto:sage [2008/12/04(木) 02:16:23 ID:vVwN1TZ0]
- stage1->Run()はstage1が終わるまで返ってこないんだろ。
いずれにせよゲームなんて毎フレームの同じ処理の繰り替えしなんだから
どこぞかにループは存在するのが当たり前だと思うが。
- 178 名前：名前は開発中のものです。 mailto:sage [2008/12/04(木) 02:16:58 ID:iyneYGG1]
- >>176が言う普通ってどんなコードなんだろうね
- 179 名前：名前は開発中のものです。 mailto:sage [2008/12/04(木) 03:27:17 ID:yi3zavJ4]
- あーすまん
メインループはどんなプログラムにもあんね
なんかさ、１フレームごとに回るループを作るやり方と
作らないやり方（あちこちでupdateする）について
急に気になって言ってみたんだが
やっぱどっちでもいい気がしてきたからいいや
- 180 名前：名前は開発中のものです。 mailto:sage [2008/12/04(木) 04:04:02 ID:BYcsjOha]
- スレッド作るにしろなんにしろ
どこかでスケジューラが回ってるがな
- 181 名前：名前は開発中のものです。 mailto:sage [2008/12/04(木) 10:56:55 ID:vVwN1TZ0]
- >>179
> 作らないやり方（あちこちでupdateする）について
> 急に気になって言ってみたんだが
それは使ってるフレームワークが裏でループ回してupdate()呼んでるんだろ。
あるいは割り込み駆動の可能性もあるが。
- 182 名前：名前は開発中のものです。 [2008/12/04(木) 22:22:51 ID:wPvA+LuT]
- >>175
＞見た目はバリバリのイケイケ
気になるな。
- 183 名前：名前は開発中のものです。 mailto:sage [2008/12/05(金) 00:50:08 ID:Vt/x/8eI]
- >>176
>たのむ
>なにが言いたいのか最後に書いてくれ
地域担当の教団勧誘員に>>174を見せると彼の顔はみるみる青ざめ、ついには目を背けてしまいました。
ただごとでない様子を感じ取った私は恐る恐るその訳を尋ねました。すると彼はおずおずと耳元で囁くのです。
「それはいけない。凶兆が見えます。そのようなものを作っていては遠からず仏罰が下るでしょう。南無妙法蓮華」
>>174は彼らの"先生"の教義に反する、知性体として恥ずべきお猿さんコードなのだそうです。私は狼狽してみました。
幼少の砌よりﾂｸﾗｰにしてHSPerである私の深層に眠る劣等感の残滓の存在をESPで見抜いたのか、彼は目を細め
「安心なさい。今からでも間に合う。私共のように三宝( * )に帰依なさい。そうすれば必ず道は開けますよ」
と仏様のような微笑みを湛えながらビール券とこの案内状をくれたのです
- 184 名前：名前は開発中のものです。 mailto:sage [2008/12/05(金) 00:51:18 ID:Vt/x/8eI]
- >>183続き
(∀・ *)【三宝】…■松浦本■やね本■逆引き本
┌──────────────────────────────────────────┐
│ 【集会のご案内】 │
│ タスクシステム（>>2）こそ失われた聖杯、伝説の神器、至高のオーパーツ、現代のエクスカリバー |
│ 私どもの教団では、身も心も何もかも唯一無二のリンクリストに捧げることで驚きのTCBがプライ ｜
｜ オリティすることをお約束します。奮ってご参加ください ｜
│ タスクシステム総合スレ part3 ｜
│ pc11.2ch.net/test/read.cgi/gamedev/1226199100/l50 │
｜ ｜
｜ 【社説】反動分子の煽動記事に惑わされてはならない ｜
｜ diary.imou.to/~AoiMoe/2008.12/early.html#2008.12.02 ｜
｜ d.hatena.ne.jp/naoya2k/20081201 ｜
｜ qo.sakuratan.com/2008/07/24/タスクシステムのこと。/ ｜
｜ 万物を支配するは唯一無二のﾘﾝｸﾘｽﾄをおいて他に無く､秩序をもたらすはTCBのﾌﾟﾗｲｵﾘﾃｲのみ。｜
｜ この崇高なる輪廻転生の法を冒涜し踏み躙る邪教徒共はママの愛情が足りなかったに違いない。 .|
｜ 敬虔なる信徒諸君は彼らの妄言に惑わされることなく修行に励みたまえ。そして最終解脱者となっ.｜
～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～
ビール券に弱い僕は誘われるままホイホイとこのスレにやって来たんだね
- 185 名前：名前は開発中のものです。 mailto:sage [2008/12/05(金) 03:20:55 ID:JyB7wu71]
- そろそろタスクシステム総合スレじゃなくて
ゲームシステム総合スレに名前変えね？
>>2を使ってる人は皆無なわけだし
- 186 名前：名前は開発中のものです。 mailto:sage [2008/12/05(金) 04:47:21 ID:U4VbVISL]
- いや、ここ隔離スレだから…
- 187 名前：名前は開発中のものです。 mailto:sage [2008/12/05(金) 05:37:33 ID:lg/+bi94]
- >>185
あー、ゲームシステム総合とか間抜けたスレタイいちいち考えなくていいから
既存スレちゃんとあるんで。こっちでは撲殺天使の人もあっちでは普通だから
ゲームにおけるデータ構造・クラス設計・パターン2
pc11.2ch.net/test/read.cgi/gamedev/1211544659/l50
既存スレからタスクシステムを隔離するためにこのスレは作られたんで
このスレが誘蛾灯として機能するにはこのスレタイは好都合この上ないんで
悪いけどお前が思ってる以上にそこそこ需要あるんだわ
＞>>2を使ってる人は皆無なわけだし
は？お前が憤死しても代わりは幾らでも湧いてくるから心配しなくていいって
- 188 名前：名前は開発中のものです。 mailto:sage [2008/12/05(金) 09:54:30 ID:bKzmksBZ]
- やね本はプレミア付く程のレア物
- 189 名前：名前は開発中のものです。 mailto:sage [2008/12/06(土) 00:08:37 ID:AlgIGpgY]
- >>166
何がいいたいかわからん。動的インスタンスリスト巡回アップデートwの具体的なメリットデメリットを指摘すればいいんじゃないか？
ttp://www.issei.org/
そのひらしょ氏の本を手伝ったらしいPGさんのブログ。タスクシステムらしきソースがある。
問い詰めた知人てこのひとかな？
例えば>>174をタスクシステムで書いたとして、単純に比較すればそりゃ
>直感的でない、変に抽象化されてデバグしにくい、実行順がコードの形で書かれておらずメンテしにくい
コードだと思うんだよ。んで、それでも使いたいメリットあるのか？て話だよな。
俺は本職のゲーム屋さんじゃないんで失礼かもしれないが、わかりにくいところもあるけど、
結構融通が利いて便利かもと思ったよ。
ためしにプロトタイプを作ってて、「ここで一発エフェクトが欲しいな」と思ったところで、new してリストにつなぐだけで動くってのはちょっと感心した。
あと、メインループ周りを作ってしまえば、そこをいじらなくても別のゲームが作れるのは
なれれば安心感があるな。
ただ、万人にお勧めできるかつと、それはちょっと難しいかもとは思う。
- 190 名前：名前は開発中のものです。 mailto:sage [2008/12/06(土) 00:15:03 ID:+2mVCqZ1]
- >>189
>ためしにプロトタイプを作ってて、「ここで一発エフェクトが欲しいな」と思ったところで、new してリストにつなぐだけで動くってのはちょっと感心した。
これホントは動かないのが普通なんだよ
裏でグローバル変数でつながってるからnewするだけで動くように見えるだけ
可能でしょ？そういうの？
本来あるべき手続きを見た目見えなくするもんだから
後で「え？そんなところと関係あるの？」っていう部分がボロボロ出てくる
結果これ以上ないデスマになる
- 191 名前：名前は開発中のものです。 mailto:sage [2008/12/06(土) 00:28:23 ID:AlgIGpgY]
- >>190
レス早すぎるだろw
>後で「え？そんなところと関係あるの？」っていう部分がボロボロ出てくる
そういう不安は、まあ、あるな。自分が把握していられる範囲ならともかく、
「3日前のコードは他人のコード」な人（俺だ）とか。
＞裏でグローバル変数でつながってるから
これ、このスレでよく批判の対象になってるけど、俺が見た範囲では
それぞれ listはprivateにしたり一応保護する工夫をしているように見えるけど
「オブジェクト同士が相互参照できるならグローバルと同じで無意味」ってこと？
- 192 名前：名前は開発中のものです。 mailto:sage [2008/12/06(土) 03:37:13 ID:+2mVCqZ1]
- >>191
タスクシステム云々ってよりグローバル変数の駄目な理由そのものじゃん
- 193 名前：issei mailto:sage [2008/12/06(土) 07:28:54 ID:wah4ZAkA]
- >>189
> タスクシステムらしきソースがある。
どこに？
私は、いまどきのハードウェアならタスクシステムは捨てて、役割ごとに std::list<> なり
配列なり作った方が良いと思ってる。
www.issei.org/blog/archives/000225.html
- 194 名前：名前は開発中のものです。 mailto:sage [2008/12/06(土) 11:22:47 ID:r2noZKmJ]
- >>193
名前欄入れてらっしゃるけど、ご本人様で？
そのエントリによると、新人研修でタスクシステムのようなものを教えてる
ところは実在するわけですかね。
- 195 名前：名前は開発中のものです。 mailto:sage [2008/12/06(土) 12:02:44 ID:+2mVCqZ1]
- 散々タスクシステムを崇拝してきた人間も
ひらしょーさんの「なにそれ？」で完全に散ったなｗ
- 196 名前：名前は開発中のものです。 mailto:sage [2008/12/06(土) 12:40:25 ID:r2noZKmJ]
- 入門を脱したばかりの奴が入門記事を書く悪循環に、
ちょうどタスクシステムがはまっていた感はあったな。
CodeZineとか。
|
 |
