5ちゃんねる ★スマホ版★ ■掲示板に戻る■ 全部 1- 最新50  

■ このスレッドは過去ログ倉庫に格納されています

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

1 :名前は開発中のものです。:2008/11/09(日) 11:51:40 ID:+pjnJyQQ
タスクシステムについての議論、相談、質問、雑談などのスレです

part2 http://pc11.2ch.net/test/read.cgi/gamedev/1196711513/
part1 http://pc11.2ch.net/test/read.cgi/gamedev/1173708588/

2 :名前は開発中のものです。:2008/11/09(日) 11:56:00 ID:+pjnJyQQ
White Paper - Programming
http://homepage3.nifty.com/moha/programming.html

タスクシステム
http://www5f.biglobe.ne.jp/~kenmo/program/task/task.html

CodeZine:本格的なシューティングゲームを実現するタスクシステム(タスクシステム,シューティング,ゲーム)
http://codezine.jp/a/article.aspx?aid=297

Logician Lord … 【コンピュータゲームのからくり】
※ウェブアーカイブのキャッシュ
http://web.archive.org/web/20041009222313/www.hh.iij4u.or.jp/~peto/Games/games_top.html

3 :名前は開発中のものです。:2008/11/09(日) 12:19:21 ID:Jr7+0IfN
1乙

4 :名前は開発中のものです。:2008/11/09(日) 13:02:33 ID:Pg+PR9ol
1おつ


前スレ>>995を実行しようとしたら、
「MSVCP60D.dllがみつかりません」って出て実行できんです。



5 :名前は開発中のものです。:2008/11/09(日) 13:37:28 ID:95rhOgJ5
同じく下記2ファイルがみつかりませんと出てきた

  MSVCP60D.DLL
  msvcrtd.dll

6 :名前は開発中のものです。:2008/11/09(日) 15:05:15 ID:clryvbVu
windows用の関数のスタブを用意したりして
linuxにてコンパイルして動作確認はできた
boost, boost build必須だけど…

7 :名前は開発中のものです。:2008/11/09(日) 15:15:38 ID:clryvbVu
boostはいらんな、
なんかCTextBuffer::Openで落ちるから色々調べてたときに使ってただけね
パスやらファイル名の問題で*.mqoが開けなかったときにぬるぽが発生して落ちてただけね
あとglutの初期化忘れとか

タスクシステムと全然関係無いですねゴメソ

8 :名前は開発中のものです。:2008/11/09(日) 21:43:46 ID:+pjnJyQQ
>>4
それVC6のデバッグ版のDLLだな
うちは入ってるから気づかなかったが

>>995はリリース版でビルドしちゃれよ

9 :名前は開発中のものです。:2008/11/09(日) 22:46:40 ID:G/ueWH6s
>>8
もしくは CRT をスタティックリンク。

10 :名前は開発中のものです。:2008/11/09(日) 23:28:18 ID:zHkW8xfN
ここで10年前に買ったVC6の恩恵を初めて受けることになるとは

11 :名前は開発中のものです。:2008/11/10(月) 22:26:56 ID:nDrMpAC2
>MSVCP60D.dllがみつかりません

だっせー!>俺
すびばせんでした。再うpしました。

http://uproda11.2ch-library.com/src/11133655.zip.shtml

DLキー task

修正項目
・実行ファイルを Release ビルド
・背景スクロールを実装してみた。
・データローダの別スレッド動作のテストなど


12 :名前は開発中のものです。:2008/11/10(月) 22:36:07 ID:nDrMpAC2
>>7
ガッ!(AA略)

>linuxにてコンパイルして動作確認はできた
さすがゲーム板。いや、LinuxでブートCD配布とかできたらと思ってたので。

>前スレの人
・実行順制御よりオブジェクト相互の関係が重要

サンプルを組んでみて、そのあたりの解決が提示されているわけではなさそうですね。< タスクシステム

サンプルのなかで、プレーヤーオブジェクトをポインタで保持してたり、その弊害を
避けるためにフラグ立ててたりとけっしてスマートとはいいがたいような。

TCB+関数ポインタをクラスで置き換えるのは悪いとはいわないが、オブジェクトの
生成削除が頻繁に起こるゲームで、std::listで管理するのはどうかなと思いました。
手軽ではあるのだけど。


13 :名前は開発中のものです。:2008/11/10(月) 22:42:17 ID:nDrMpAC2
>前スレの人
>実行順制御・描画順制御
まだ慣れていないので評価しにくいですが、サンプルではシナリオの読み込みとか優先度を高くしてありますね。それなりに意味はあるのか?

描画順制御についていえば、OpenGL を使っていても半透明オブジェクトの重ねがき
みたいに描画順をメンテする例もあるので、まあ、あれば使うかなと。
(爆発表現にちょっとつかってみた)

描画に関してはもっとちゃんとしたやり方があるように思いますが。


14 :名前は開発中のものです。:2008/11/11(火) 22:13:14 ID:BOKiifWA
>>12
> オブジェクトの生成削除が頻繁に起こるゲーム
今時のマシンなら高がしれてるよ。エフェクトでパーティクル個別に new するとかだと、さすがに
氏ねと思うが。

15 :名前は開発中のものです。:2008/11/11(火) 23:33:37 ID:YONi9ugo
>>14
>今時のマシンなら高がしれてるよ

CPU負荷や処理速度じゃなくて、サンプルの例だと、stl::list からオブジェクトを
削除する場合のトリッキーに見える処理がちょっといやらしいかなと思ったんですよ。

ただ、シーケンシャルな処理だと考えればそんなに問題もないのかな。


16 :名前は開発中のものです。:2008/11/11(火) 23:45:14 ID:BOKiifWA
>>15
そういう話なら同意。というか、何でもかんでも一つのリストにつながなくても、ふつーに
std::list<Enemy> enemy_list;
std::list<Effect> effect_list;
と分けとけば良いのにね。


17 :名前は開発中のものです。:2008/11/11(火) 23:45:44 ID:bfqrEb/4
今時のマシンでもメモリ問題は意識すべきだよ。
少なくとも自分以外の人に遊んでもらえるゲームを作るつもりならね。
モジュールのライフスパンに応じて適切にヒープを分けるだけなんだから
最初からやれば手間はかからない。

今時はコンシューマゲーム機の開発者でさえもメモリ管理をおろそかにする未熟者が多い。
マスターアップ近くになってフラグメント化のためゲームがハング。
対策を練ろうにもグローバルでnew、deleteだったから全部書き直しするしかないという
実話もあるほど。

18 :名前は開発中のものです。:2008/11/12(水) 00:46:23 ID:N/n8r37l
1GHz 512MB VRAM8MBで起動した
超絶スローで

19 :名前は開発中のものです。:2008/11/12(水) 01:05:05 ID:sxpmqDHH
>>17
CodeZine のサンプルはメモリ管理にこだわってたよね。
「タスクシステム」の要件にメモリ管理を加えるべきか、みたいな
話もあったけど。

20 :名前は開発中のものです。:2008/11/12(水) 01:07:38 ID:sxpmqDHH
>>18
>VRAM8M て、trio64とか?w
さすがにOpenGL のハードアクセラレーションないとちょっときついかと。

21 :名前は開発中のものです。:2008/11/12(水) 06:58:36 ID:3e5+3Sl/
>>17
> 対策を練ろうにもグローバルでnew、deleteだったから全部書き直しするしかないという

なんでそうなるんだ?
「モジュールのライフスパンに応じて適切にヒープを分けるだけ」なんだろ?
後でもできるじゃん。

22 :名前は開発中のものです。:2008/11/12(水) 08:16:49 ID:qQkBoxEr
>>17
メモリの断片化が問題になるのは、極端にサイズが大きいものと小さいものを
同じヒープから確保する場合。

テクスチャ・モデル・モーション・サウンドなどのリソース類だけ分けておけば、
あとのゲーム制御用のインスタンスは気にせずグローバルなヒープから new,
delete で OK だよ。

23 :名前は開発中のものです。:2008/11/12(水) 12:09:14 ID:eqQiBZB/
そんなどんぶり勘定が許されるのは素人ゲーだけだよ
少なくともヒープ使用量の最大値は見積もれていないと
売り物にしてはいけないね。
フラグメント化対策の方法論なんて確立されているんだから
それをおろそかにするのは単なる手抜き以外の何者でもない。

24 :名前は開発中のものです。:2008/11/12(水) 12:25:51 ID:3e5+3Sl/
まったくだ。

「おそいかも」とか「フラグメンテーションが発生するかも」なんていう
どんぶり勘定で面倒なメモリ管理コードなんて追加しちゃいけない。

「ここがおそいことがわかったから」「ここでフラグメントが問題になったから」と
言えるなら何か細工を入れてもいい。言えなきゃおとなしく new/delete 使っとけ。

25 :名前は開発中のものです。:2008/11/12(水) 12:41:37 ID:beD99wJ7
問題になるまではGCやsmart_ptrを使っていてもおkと

26 :名前は開発中のものです。:2008/11/12(水) 13:08:03 ID:IOwBN/Qz
いいよ
仕事でやってるやつはみんな何回も痛い目見てるから自然と神経質になる
問題が出ないうちから考えてもアタマでっかちになるだけ

27 :名前は開発中のものです。:2008/11/12(水) 23:22:51 ID:qQkBoxEr
>>23
> そんなどんぶり勘定が許されるのは素人ゲーだけだよ
気のせい。

28 :名前は開発中のものです。:2008/11/13(木) 05:53:34 ID:4jJZotVw
newとdeleteはやたら使用メモリの全体量がわかりずらいな
mallocからしてロクなもんじゃなかった気がするけど
newとdeleteほどアフォ仕様じゃなかったよな
オーバーロードするといちいちそのヘッダ呼ばないと
newとかdeleteとか呼べないしで糞面倒くせぇ

せめてデバッガで見えれば助かるんだけどそういう機能ってないの?

29 :名前は開発中のものです。:2008/11/13(木) 07:37:37 ID:bFvJK9Je
>>28
ふつー ::operator new() ではなく、クラス内の operator new をオーバーロードするから、
必然的にヘッダ読み込むことになると思うが。

メモリ使用量は、使ってるライブラリによるな。俺は自前で書いたのがあるから、それを
使ってるけど。

30 :名前は開発中のものです。:2008/11/13(木) 16:57:10 ID:YYgyTJOh
タスクシステムと分岐予測やパイプラインの関係を考察してるようなサイトありませんかね?
ググッてもこのスレばかりヒットしますw

31 :名前は開発中のものです。:2008/11/13(木) 19:06:42 ID:rnZd7PxY
>>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系がロクなもんじゃないと言いたいの?それともヒープ使用量をモニターする
手段が見つからないからロクなもんじゃないと言いたいの?

32 :名前は開発中のものです。:2008/11/13(木) 19:34:18 ID:rnZd7PxY
>>22
>極端にサイズが大きいものと小さいものを
>同じヒープから確保する場合

「極端に生存期間が大きいものと小さいものを同じヒープから確保する場合」
も付け加えといとくれ

33 :名前は開発中のものです。:2008/11/13(木) 20:38:35 ID:rnZd7PxY
>>32だけど>>21で既に生存期間の話出てるね。文盲だね

ネトゲのサーバプログラムとかだとオブジェクトの生存期間の差はかなり強烈なものになるから
例えばWindows系ならHeapCreateとかで適切にヒープ領域を分けといたりするけれど、PCゲーの
クライアントプログラム限定の話ならぶっちゃけこんなの要らん

数ステージを巡回するデモンストレーションモードで数日間ぶん回してメモリ確保に失敗し始めたり
タスクマネージャのグラフが愉快な絵を描いてるとかNtQuerySystemInformationでログ取り続けたら
驚きの結果が、とかならフラグメンテーション云々の可能性を考えてもいいかもだが

そういう場合はステージ毎にHeapCreate/HeapDestroyでドバっと確保・ドバっと開放でもしとけばいい。
これならステージ中のオブジェクトはみんなHeapAlloc系使ってもフラグメントの心配いらね
弾とかパーティクルみたいなサイズ・生存期間共に粒度極小のオブジェクトを大量にばら撒く
ゴジャースなゲームなら表示MAX分だけドバっと確保したboost::pool使うか配列で順序なしのリスト
みたいなことやっとけばいいよ

ところでタスクシステム?ハァ?って感じだな

34 :名前は開発中のものです。:2008/11/13(木) 21:32:18 ID:4jJZotVw
>>31
俺はそんな難解な話してない
使ってるメモリの使用量がわからない・わかりにくいってただそんだけのこと
あと、メモリリークとかも全然わかんねぇ
IDEの問題になるけど分かる要素がないのがひでぇl

で、俺の知識だけだと自分でmallocをラップした関数を実装して
それに使用メモリの総量・使用メモリ状況やメモリリークなんかを
チェックできるようにしてるんだけど

この辺っていつまでたってもウンコじゃね?
とかそういうこと言ってる

(俺が知らないだけかもしれんが少なくともVCはウンコだと思う)

35 :名前は開発中のものです。:2008/11/13(木) 21:49:37 ID:bFvJK9Je
>>30
マジに最適化し出すと、関数の並び順とかまで見直す必要がある。PS2 のときには
キャッシュがマジ少なかったので、ライブラリチームは T15000 使って最適化してたけど、
今はそこまでやってないんじゃないかなぁ。

ゲームロジックはキャッシュミス起きまくりだが、そもそも大して CPU 使ってないので
気にしない。昔も今も。

36 :名前は開発中のものです。:2008/11/13(木) 21:51:07 ID:bFvJK9Je
>>33
パーティクルとかの小さなオブジェクトは STLport の node allocator 使ってた。メモリが
多少無駄になるけど、早いし断片化しないので。

37 :名前は開発中のものです。:2008/11/13(木) 21:56:23 ID:rnZd7PxY
>>34
確認するが、CRTデバッグヒープくらいは使ってるという前提でいいよな?
http://msdn.microsoft.com/ja-jp/library/974tc9t1(VS.80).aspx
その上で不満ということならもう少し詳しくお話をしてほしい

もし使ってないってんなら幾らなんでもネタだろう…(´-`)


38 :名前は開発中のものです。:2008/11/13(木) 22:13:53 ID:4jJZotVw
>>37
こっちも確認するけど
それアフォがソース見てもわかる奴しかでない奴でしょ?
難しいリークだとアウトプットウィンドウに変なコードがずらずら出てもどこのコードが
リーク起こしてるかまったくわからない機能でしょ?
そんなの使えないよ

正直、その機能に頼るぐらいなら自分でmallocをラップしたほうがよっぽどいい

39 :名前は開発中のものです。:2008/11/13(木) 22:21:07 ID:4jJZotVw
ちなみに使ってるのはこれ

_CrtSetDbgFlag(_CRTDBG_ALLOC_MEM_DF|_CRTDBG_LEAK_CHECK_DF);

なんでこれさ
こんなアフォなんだろうね
俺のいる会社の新人だってこんなアフォな機能作らないと思うよ
やっぱり俺の使い方間違ってる?
ってかそれとももうちょっといい使い方あんの?

さすがにこりゃねぇだろうと思った
だって自分でやればどこのソースのどのコードが使ってるメモリなのか
余裕でわかるようにできるじゃん
これまったくわかんねぇじゃん
動的(わからない法則がちょっとわかってないが)に確保したもんだとほぼお手上げじゃね?

40 :名前は開発中のものです。:2008/11/13(木) 22:53:24 ID:rnZd7PxY
飯くってた
>>36
node allocatorは良いものらしいね

>>38-39
把握した

WindowsだのVisual Studioなど言ったって、なんだよ結局はユーザープログラム固有の
モニタプログラム(システムモニタ(リソースモニタ)やジョブモニタ)を用意しなくちゃ
いけなくなるのかよバーローつー話だよな

通常、ゲーム開発用のフレームワークはデバッグ支援用のツール群とセットになってるけど
それに相当するサービスをVS標準機能に期待するのは難しいね

ま、同人ゲームとか、ここでタスクシステムすげぇすげぇ言ってる超小規模開発・個人開発なら
無用の機能だが

41 :名前は開発中のものです。:2008/11/13(木) 23:55:15 ID:rnZd7PxY
>>969
(前略)だからコンテキストスイッチは不要では。

>コンテキストスイッチは要らなくネ?

ゲームに要求される表現は多様化・高度化し続け、それに伴いゲーム内で処理されるジョブの粒度も多様化し
1イント内に処理すべきジョブ数も増大の一途をたどった。ジョブ(ゲームコード。例えばAI)を記述するスタッフも
増大し多様化した。時間ステップ毎に単純に数値積分していくだけのジョブばかりではなくなり、継続(continuation)
が必要なジョブが増えた。にも関わらずゲームの特性上個々のジョブはμsecオーダーで終了ないし中断することを
要求される。継続に必要な手続きをユーザープログラム側に丸投げする(ユーザープログラム側にリエントラントな
仕掛けを用意させる)原始的なFSMモデルのジョブ制御だけではお話にならなくなり、ファイバーやコルーチンのような
仕掛けも必要になった。これらのジョブの粒度はスレッドを使うには小さすぎ、また数も多すぎる

まぁ、同人ゲーやタスクシステムすげぇすげぇ言ってる超小規模開発・個人開発なら無用の機能ではあるが

42 :名前は開発中のものです。:2008/11/14(金) 00:06:03 ID:DNME6QAR
スゲー参考になってありがたいけど同人シュー制作者の俺にはテラコンプレックスw

43 :名前は開発中のものです。:2008/11/14(金) 01:05:26 ID:mdtDWXyh
(訂正)
----------------------------------------------------------
>(前略)だからコンテキストスイッチは不要では。

>>コンテキストスイッチは要らなくネ?

>(前略)だからコンテキストスイッチは不要では。
----------------------------------------------------------
>1イント内に

時間ステップ毎に
----------------------------------------------------------
(補足)
一部素人がタスクシステム(以下>>2と呼ぶ場合アリ)とか呼ぶものの実態が>>2程度のものであるという前提に立つならば
これは70年代のハードに依拠する簡素なゲームにとっては無難なジョブ制御プログラムとかモニタプログラムの【断片】だね
しか言いようがない。もはや今となってはね。
これは非常に簡素でオーソドックスなFSMモデルのジョブ制御であり、大昔から科学計算で頻繁に使われ
大昔の計算機、現代でも組み込み用途の超貧弱なマイコン(安いものなら50円前後。RAM数KBとROM数百KBの
ワンチップのやつ。半ば使い捨て)のために用意される超原始的なモニタプログラムにも見られる。
継続に必要な仕掛け、つまりコンテキストスイッチに必要な記述は全部ユーザープログラム側に丸投げ。
何もしてくれない。誰が書いても同じようなものになるってくらい凡庸な、道端の雑草並みのありふれた仕掛けだ。
でも「タスクシステム」という呼び方は珍しい。かなりエキセントリックだ。これは特定の職場内の固有名詞
ローカル用語の粋を出ることはないだろうね

44 :名前は開発中のものです。:2008/11/14(金) 01:22:07 ID:0noAZqI/
>>41
AIについてで実装できてるわけじゃないから強くは言えんけど
タスクシステムの構造を大きく変えるような手を入れなくてもできそうな気がする。

別スレッドで定期的にタスクを位置等のグループ毎に分割して、グループ内での状況を解析する。
そしてタスクに次に処理がきたときに、次にどう動かすか考えるの役立つ情報をセットする。
とかではだめですか。

45 :名前は開発中のものです。:2008/11/14(金) 01:24:09 ID:SCRh4oL7
>ゲームに要求される表現は多様化・高度化し続け

で、そんなリソース大量消費型ゲームと小規模DSゲームの売り上げが変わんなくて
涙目、という話ですね。わかります。

とかそんなつまらんイヤミはおいとくとして、タスクシステムのサンプル打ち込んで
おもしれーなとか言ってる俺には雲の上の話なんだけど、

>原始的なFSMモデルのジョブ制御だけではお話にならなくなり、

こういうところはなんとなく予想できるんだよ。ただ現実問題として

>同人ゲーやタスクシステムすげぇすげぇ言ってる超小規模開発・個人開発

が、手軽に手をだせる、楽チン開発できてウハウハなフレームワークってあるの?
どうせ勉強するんならそっちのほうがいいような気がすんだけど。


46 :名前は開発中のものです。:2008/11/14(金) 01:26:10 ID:1UgkwBET
>>45
C++ でふつーにメインループ書いて、continuation っぽいこと必要な部分はスクリプト言語 + スタックレス VM で良いじゃん。lua とか。

47 :名前は開発中のものです。:2008/11/14(金) 01:32:05 ID:mdtDWXyh
Q.【>>2のようなプログラムを「タスクシステム」と呼ぶことに固執し広めようとする人間がしばしば笑い者になるのは何故?】

技術は進歩し続け、計算機は猛烈な勢いで処理速度を向上させ、現代のナウいハードに依拠するナウいゲームを
作るために『『不可欠』』となったナウいフレームワークだのゲームエンジンだのと比べるともはやミジンコ級であり
お世辞にもシステムとはとても呼べない玩具みたいな代物であることは否めない
>>2のような小規模で簡素なFSMモデルのジョブ制御は、原始的なモニタプログラムといえるかもしれない。
しかし一般にOSを表す非プリエンプティブマルチタスクシステムとは明らかに異なる。共通項は非プリエンプティブ
という点だけでありコンテキストスイッチをサポートしていない(その責任をユーザープログラム側に丸投げ
してしまってる)時点でマルチタスクシステムとは明らかに異なる。マルチタスクという用語自体は1960年代半ば
オペレーティングシステムという用語と共に誕生した。UNIVACとかSystem/360のOSが出てきた時代の話。
エンジニアは用語の意味が輻輳を起こし意思疎通に齟齬が生じることを嫌う。OSが提供されないカスタムボードで
走るゲームプログラムの開発者なら兎も角、立派なOS下で走るゲームプログラムの開発者にとってタスクはプロセスだ。

>>2は、過去に「とある開発チームで使われていた原始的なモニタプログラム」が固有名詞として「タスクシステム」と
呼ばれていたのかもしれないね、程度の理解でいいと思う。当時のゲームプログラムはOSが提供されないカスタムボードで
走るものであり、ゲーム開発者自前のモニタプログラムを用意しハードの全てを自分でコントロールした

#google2001の検索結果によると当時「タスクシステム」などと呼んでるページはほぼ皆無だったことが判明している
#ほんの一部でその単語を使ってたページは出典としてLogician Lordを紹介していた。ネットで徐々に伝播しCマガで
#松浦とかいう素人プログラマが出典を明記せずに紹介し急速に流布し広めた「タスクシステム」なる呼び方の出所は
#Logician Lordだろうと思われる。これがネット発の「タスクシステム」なるものの出自だ。都市伝説と呼ぶに相応しい

48 :名前は開発中のものです。:2008/11/14(金) 01:55:22 ID:SCRh4oL7
>>46
スタックレス + lua でググった。
なるほど、いまどきはタスクシステム(FSM)でカリカリやる、やれるくらいの規模の開発
なら、単純なメインループとスクリプト言語のほうが楽だしパフォーマンスも出る
ってこと?

難点はあのパスカルくささに耐えねばならんとこかなあ。ニントモカントモ。


49 :名前は開発中のものです。:2008/11/14(金) 01:57:27 ID:1UgkwBET
>>48
状態遷移が複雑な部分、たとえばアクションゲームのプレイヤー制御とかは
C++ で書いといて、continuation あった方が楽な部分、たとえば「何秒後に
エフェクト発生」とかはスクリプトとかデータファイルで書くのがふつーじゃね?

50 :名前は開発中のものです。:2008/11/14(金) 02:05:40 ID:mdtDWXyh
>>42
必要ないものは取り入れる必要はない。コンプレックスは持つ必要ない。
俺も同人ゲーを作ったことあるが規模相応の簡素なコーディングで済ませてた。
いわゆるタスクシステムとか紹介されてるあのヘンテコな仕掛けも不要だった。プライオリティ?ハァ?って感じだ。
敵の配列が弾の配列があって。そんな感じだ。
タスクシステムを心の底から崇拝する人間が心の底から子バカにしている様子がたまに見受けられる
配列厨のコードそのものだ。

同人ゲームを悪く言うつもりで書いたわけではないのだが、もし>>40-41の「同人ゲーム〜」の部分が気に障るなら
そこは撤回する。すまなかった

51 :名前は開発中のものです。:2008/11/14(金) 02:05:58 ID:SCRh4oL7
>>49
luaはver4のころちょっとかじっただけなんだけど、スクリプト処理のために
組み込んでみようとは思ってたんで、考えてみるよ。ありがと。


52 :名前は開発中のものです。:2008/11/14(金) 02:22:54 ID:mdtDWXyh
>>44
多種多様な人間が多種多様なジョブ(ユーザープログラム)を記述することになると
「FSMモデルのみ」という拘束条件は必ず無理が生じる。これはやれば分かるという他ない
RAM数KBの組み込み用モジュールのモニタプログラムでもコンテキストスイッチをサポートしたがる。
FSMモデルでジョブを記述させると色々面倒くせーことになるから。説明するよりも組んでみたほうが
分かるという他ない

>別スレッドで〜

よく分からんがコンテキストスイッチをサポートしたくないがためだけに
何やら複雑怪奇な仕組みを導入する話のような気がしてならない
素直にLuaとか使ったほうがいいよ。というか眠いばいばい

53 :名前は開発中のものです。:2008/11/14(金) 02:29:54 ID:SCRh4oL7
>>50
>規模相応の簡素なコーディングで済ませてた
そこんとこがよくわからんのだよなあ。
単純な配列とループで組めて問題ないならぜんぜんOKでしょ。俺もそうする。

ただ、サンプルでも使ってる GLLib の人のサンプルソースは単純ループ
だけど、けっこうきつい印象を受けた。

俺も「タスクシステム」を採用するだけでバラ色の未来が開けるとは思わん
(まだかじっただけなんで実はすごい泥沼が待っているのかもしれない)けど、
そこそこ使いまわしが効いて、それなりに見通しがいいように思う。

要は適材適所じゃないかと思うんだが、用語を使うことすら非難するほどの
問題があるの?


54 :名前は開発中のものです。:2008/11/14(金) 02:37:14 ID:SCRh4oL7
>何やら複雑怪奇な仕組みを導入する話のような気がしてならない

こういうのは、同意できるんだよね。
そこそこ便利そうだけど決してわかり易い仕組みとはいいにくいから、
なんか泥沼にはまりそうな気がする。

まあ、小学生の感想文ですまん。


55 :名前は開発中のものです。:2008/11/14(金) 02:38:50 ID:s5clZUFB
タスクシステムが有効なのは小規模システムだな
メモリの単位がkまでの環境
Mになると不要

56 :名前は開発中のものです。:2008/11/14(金) 02:46:45 ID:SCRh4oL7
>>55
キャッシュじゃねーかw<k
あー、PICのプログラムとかそれっぽい。

57 :名前は開発中のものです。:2008/11/14(金) 02:49:24 ID:s5clZUFB
AVRは俺の嫁

58 :名前は開発中のものです。:2008/11/14(金) 07:52:52 ID:EfjKu0FE
i君はルサンチマンに満ち溢れてるなw

59 :名前は開発中のものです。:2008/11/14(金) 16:00:01 ID:gWloFQ1j
>>48
Luaの文法が嫌いならSquirrelもいいよ。
ム板でスレタイ検索してみてくださいな。

>>53
自分の書いた文章で古い設計方法に名前がついたことにより
予期せぬ形でもてはやされるようになってしまった。
そのことに対する責任感から現代的な知識を伝えると共に
言葉狩りを行っている。

彼の行動はこのように解釈することもできる。あくまで妄想だが。

60 :名前は開発中のものです。:2008/11/14(金) 19:49:55 ID:Z+hETYkY
タスクシステムを使ってるプログラムの
メモリ・ポインタまわりのバグり具合はハンパじゃないな
フツーに書けとあれほど言ってるのにやって
ゲームと違うところでいっつも四苦八苦してるとなりのプロジェクト

あんまりポインタ周りのバグが酷いからプロジェクトをまたいだ会議で
原因を指摘してやったのにまだごにょごにょ言ってる
もう、お前(となりのプロジェクトのウンコリーダー)に逃げ場はねぇよ

グローバル変数とタスクシステムとポインタの悪用は絶対に全部セットなんだよな
タスクシステム使わないプロジェクトはグローバル変数も使わないしポインタの悪用もしない
だからプログラムがメインから必ず終えるし
組み込むべき箇所もすぐにわかる
第三者がきてもすぐに全体が把握できるってのはでかいね

もういい加減に信者も目を覚ますべき

61 :名前は開発中のものです。:2008/11/14(金) 20:17:38 ID:gp/PSntR
メモリ、ポインタを怖がるってプロとしてどうなのw

62 :名前は開発中のものです。:2008/11/14(金) 21:58:54 ID:EfjKu0FE
馬鹿が触ったポインタほど怖いもんはねえぞ

63 :名前は開発中のものです。:2008/11/14(金) 22:21:45 ID:pFqWgrsK
確かにコンテキストスイッチがないとグローバル変数に頼らざるをえない。

コンテキストスイッチがあったところでスパゲティにする奴はするけどなw

64 :名前は開発中のものです。:2008/11/14(金) 22:34:07 ID:mbBbhYbw
nullポはいねぇがあ〜?

65 :名前は開発中のものです。:2008/11/15(土) 00:05:57 ID:Kosjr/Zu
>>48
昔Delphi使ってたから、馴染みはあるんだけど、C/C++と併用すると間違うんだよね。
演算子とか。

>>60
あー、それは俺も気になった。
親クラスのメソッド呼んだら、内部で自分自身を削除してて戻ってきたところで落ちるとかw
俺がタコなだけなんだけど、基本的にポインタを多用するスタイルみたいだしな。
几帳面なやつ向きかも。実はちょっとびびってるw


66 :名前は開発中のものです。:2008/11/15(土) 00:27:43 ID:GEMDjn92
それタスクシステムとかいうナニに限った話ではないと思うんだけどな
相互参照オブジェクト(インスタンス)の取り扱いについてのごく初歩的な
あらゆるプログラムに通じる基本的なお作法の話だと思うんだ

67 :名前は開発中のものです。:2008/11/15(土) 00:34:05 ID:EtW+xZ5p
ポインタなくてもタスクシステム組めるけど?

68 :名前は開発中のものです。:2008/11/15(土) 00:46:53 ID:Kosjr/Zu
>>66
んー、いいわけがましくなるけど、俺の場合、インスタンスの廃棄は生成した側
が責任をもつというスタイルだったんで、インスタンス自身が自分を廃棄する
という形式に慣れてないんだと思ったけど。



69 :名前は開発中のものです。:2008/11/15(土) 00:55:46 ID:Qgt9Tm09
>>67
でも悪用するだろ?
しかもグローバル変数は使わないと恩恵(笑)は受けられないだろ?

所詮、アフォが飛びつく糞なアイテムよ

70 :名前は開発中のものです。:2008/11/15(土) 01:00:16 ID:GEMDjn92
>インスタンス自身が自分を廃棄

その廃棄っていうのは、自殺を決断したらメモリ開放まで一気に行ってるわけだよね?
タスクシステムとかいうナニにおけるインスタンス(というかエンティティなんだろうね)の
自殺のプロセスというのは、常にそういうもの(自殺を決意したらメモリ開放まで一気に決行)
と決まっているの?それとも君が読んだ何かしらの自称タスクシステムのサンプルコードの
実装がたまたまそうなっていたというだけなの?

71 :名前は開発中のものです。:2008/11/15(土) 01:06:54 ID:GEMDjn92
>>70補足
>(自殺を決意したらメモリ開放まで一気に決行)

なおかつ生みの親や己を参照するインスタンスに何ら通知する手段を提供しない。ね

>>68
>俺の場合、インスタンスの廃棄は生成した側
>が責任をもつというスタイルだったんで

これも同じく。自殺を決意したら生みの親に自分を殺してくれと依頼するような手続きは
タスクシステムと呼ばれるナニにおいては「存在しない」ということになってるのか、それとも
君が読んだ何かしらの自称タスクシステムのサンプルコードの実装がたまたまそういう
手続きを用意していなかっただけなのか

自称タスクシステムってどれもこれも俺俺システムで内容がバラッバラだよね

72 :名前は開発中のものです。:2008/11/15(土) 01:23:55 ID:Kosjr/Zu
>>70
イテレータに矛盾が生じないような工夫はされてたけど、delete はdelete だったな。
まあ、それでも、たまたま、じゃないかと思うけど。入門用サンプルだし。


73 :名前は開発中のものです。:2008/11/15(土) 01:34:51 ID:GEMDjn92
>>72
そうかー。もし良かったらそれのURLとか書籍名教えてくれないかな
いや、別に悪戯とかしないからさ

74 :名前は開発中のものです。:2008/11/15(土) 01:53:28 ID:Kosjr/Zu
>いや、別に悪戯とかしないからさ
却ってこえーよw
こっちは勉強させてもらってる立場だからあんまりなー。
このスレを調べりゃわかるよ。

75 :名前は開発中のものです。:2008/11/15(土) 02:00:05 ID:GEMDjn92
あー、ここに載ってるならいいや

>却ってこえーよw

何にもしねーよ。入門用を謳う自称タスクシステムがいっぱいあるから
そのカオスを更に加速させて「タスクシステム」がどんどん
「口に出すだけで何とも居た堪れなくなるムードを醸し出すキーワード」
になっていく様はある意味で痛快だしな。

76 :名前は開発中のものです。:2008/11/15(土) 02:02:37 ID:GEMDjn92
いっぱいあるから → 増殖するのは結構なことだ

77 :名前は開発中のものです。:2008/11/15(土) 02:45:06 ID:ic2SgE5A
ちょっと大げさかもしれないけど
コンテンツ産業に理解ある総理の下で
国策としてコンテンツ産業に力を入れようとしているのに
裾野を支える初心者が混乱に陥ることを喜ぶのは
日本人として恥ずかしくない?

78 :名前は開発中のものです。:2008/11/15(土) 08:16:42 ID:hO/9YF4P
タスクシステムすごくね?
いつも途中で破綻する俺でもゲーム作れた

79 :名前は開発中のものです。:2008/11/15(土) 13:25:03 ID:s+TTPkcj
>>77
そういう、いかれた自称上級者はいつの時代にもいた。

80 :名前は開発中のものです。:2008/11/15(土) 14:12:48 ID:Mi8wwxRa
タスクシステムを使うようになってからというもの、周囲がボクを見る目が変わったね。

なんかこう一目置かれてるって感じ?

隠し切れない風格を醸してるせいかコミュニケーションにも微妙な距離が生まれるみたい。
こういう孤独も上級者ならではの悩みだよね

81 :名前は開発中のものです。:2008/11/15(土) 14:30:50 ID:bk64Ra9f
自由度が高い分だけめちゃめちゃ遅い点はあまりつっこまれない、なんで?

82 :名前は開発中のものです。:2008/11/15(土) 16:47:53 ID:ooF5RpWW
遅いって何が?

83 :名前は開発中のものです。:2008/11/15(土) 18:45:10 ID:saotQS84
たぶんこの辺の話
http://pc11.2ch.net/test/read.cgi/tech/1217813098/985

84 :名前は開発中のものです。:2008/11/15(土) 19:01:12 ID:Bp8RkerR
仮想関数まで否定することになるな

85 :名前は開発中のものです。:2008/11/16(日) 02:36:48 ID:SVunqIhe
なぜタスクシステムを嫌うのですか?(上位5回答)

1.名前が気に入らない
2.名前を付けた人物が気に入らない
3.名前の「システム」の部分が気に入らない
4.自由度が高いのが気に入らない
5.隣のプロジェクトが気に入らない

86 :名前は開発中のものです。:2008/11/16(日) 03:11:11 ID:DYIhu6LD
「気に入らないから叩かれてるに過ぎない」として批判を過小評価したがってる様子が
ひしひしと伝わってくるけど、そういうワンパターンなかわし方を続けるのってのもどうなんだろうね

87 :名前は開発中のものです。:2008/11/16(日) 06:15:12 ID:SBJGjbor
カプの開発で大規模に作っちゃったもんが
タスクシステム使いまくりでバグりまくりなので
そもそもの構造からいってすでにまずいってことがわかると困る人がいるのです

88 :名前は開発中のものです。:2008/11/16(日) 07:03:30 ID:SVunqIhe
>>86
いやいや、俺はタスク使わんし・・・
批判の仕方が感情的だっつってんの

タスク派も嫌タスク派も、なんで自分のやり方が一番いいと思えるんだ?

89 :名前は開発中のものです。:2008/11/16(日) 07:44:51 ID:SBJGjbor
>>88
二つの方法ですでに開発したことがあって比較した上での結論

90 :名前は開発中のものです。:2008/11/16(日) 08:44:31 ID:SVunqIhe
早いレスども

タスクシステムという名称は新しいものらしいけれど、
それ自体はかなり古い手法だろ?
当時対比されるべき「もう一つのやり方」は
アセンブリで非構造化の逐次プログラミングだったはず
当時のタスクの本質がコンポーネント指向にあったんだろうと考えれば
取り込む要素があると思いこそすれ、非難する気には全然ならないんだよね

なんつーか、フラッシュ使いがハイパーカードを非難してるようなモヤモヤを感じる

91 :名前は開発中のものです。:2008/11/16(日) 08:50:18 ID:fOiOPCuz
ギャラクシアン - Wikipedia
http://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

タスクシステムの初出は1970年代

92 :名前は開発中のものです。:2008/11/16(日) 08:56:45 ID:SVunqIhe
ちなみに旧ナ○コ系の一部では
ジョブコン(ジョブコントローラー)と呼ばれていたらしい
他にも派閥によって呼び名が・・・おっとだれか来たようだ

93 :名前は開発中のものです。:2008/11/16(日) 14:53:09 ID:ekn4SUba
>>87
以前このスレでも話が出たMTなんとかのことですか?

94 :名前は開発中のものです。:2008/11/16(日) 22:47:39 ID:JDXMEp1E
>>90
> 取り込む要素があると思いこそすれ、非難する気には全然ならないんだよね
C++ で仮想関数として取り込み済み。

95 :名前は開発中のものです。:2008/11/16(日) 23:43:18 ID:fOiOPCuz
70年代の技術でオブジェクト指向を表現したのがタスクシステム

96 :名前は開発中のものです。:2008/11/17(月) 00:52:54 ID:d4ix+Z90
別にゲームに限らず、関数ポインタ+データブロックという構造はよく使われてたけどな。
UNIX のデバイスドライバとか UNIX V6 の頃から、こんな作りだ。

97 :名前は開発中のものです。:2008/11/18(火) 00:07:12 ID:jVsaZ2Nt
>>92
だっせー

98 :名前は開発中のものです。:2008/11/18(火) 01:47:54 ID:2bcqSLD5
当時としてはすごい技術だったという話は

・いまタスク使ってるやつは擁護になってないからスルー
・アンチはそんなの知ったことじゃないから叩く

技術史が好きなヤツにしか意味のない話です

99 :名前は開発中のものです。:2008/11/18(火) 02:15:13 ID:0/4z+Eh4
だからタスクシステムの要点は
  ・メモリ管理
  ・タスク管理
だって言ったじゃん

メモリフラグメントに対して固定長データという回答を出したのがタスクシステムの功績
そして扱うべきデータがどんなデータであれ管理レベルでは等価である事がタスクシステムか否かの分岐点だと思うね

ちなみに継承+多態はメモリ管理、タスク管理のどちらから見ても最悪なばかりか速度まで低下して何のメリットもない
プログラムも複雑化してタスクシステムより尚悪い

あと余計な事かもしれないけど、このスレが迷走しやすいのは「何を解決するのか」を定義しないで話を進めるからだよ
例えば「ジャンルにとらわれない万能オブジェクト管理システム」なんていう途方もない事であっても目的があるとないのでは
議論の濃さが全然違う

最後に何度も言ってるけど、・・・タスクシステムを使うには現在のPCはオーバースペックすぎると思うよ
HSPでよくみかける固定長配列での管理よりわかりやすく速度的にも有利なタスクシステムなんて見たことないし
有意な差が出るとも思えない

100 :名前は開発中のものです。:2008/11/18(火) 07:37:14 ID:P1O//Y8n
わけのわからんこと言い出すからレスが止まっちゃっただろ

101 :名前は開発中のものです。:2008/11/18(火) 08:29:07 ID:RCT5hNLc
>ちなみに継承+多態はメモリ管理、タスク管理のどちらから見ても最悪なばかりか速度まで低下して何のメリットもない
>プログラムも複雑化してタスクシステムより尚悪い
お前は継承も使わずにプログラムしてんのか?

102 :名前は開発中のものです。:2008/11/18(火) 09:07:44 ID:HHT2Kui7
Cには継承ないよ
haskellには継承なんてないけどそれでも綺麗なコードの実用プログラムが沢山書かれてるよ


103 :名前は開発中のものです。:2008/11/18(火) 12:59:38 ID:k/xr4HgC
なんで唐突に Haskell が出てくるのかわからんが
deriving とか知らないのか?

で、必死になってメモリ管理とか叫んでるひととか、バカにしようと必死な人とかは
スルーしたほうがいい気がする。

104 :名前は開発中のものです。:2008/11/18(火) 16:11:47 ID:jVsaZ2Nt
>>99
>タスクシステムっていうのは
>  ・メモリ管理
>  ・タスク管理
>の2種類から構成されている

前スレログ読みましたが、クラスを使うとフラグメントが発生どうのとかよく分からない話をして
数人から突っ込まれてたID:IuSgJyHuさんですか?たぶんそうだろうかと私は思うのですが。
ところであなたの言う「タスクシステム」とやらは具体的に何なのでしょう。これと思う実装例が
あるならそれを示してくれませんか。人によって定義が千差万別の俺俺システム「タスクシステム」
ですから、その言葉を発する人間が登場する度にこうやって確認せざるをえないわけで。
このように、確固たる出典がない、言い方を変えれば権威が不在というのは不便なものです。
技術用語としての存在価値が疑問視され、所詮はローカル用語といわれるのも頷けます

>メモリフラグメントに対して固定長データという回答を出したのがタスクシステムの功績

ん?70年代中期・末期において主記憶をページング方式で管理することに新規性があったと。
簡単のために操作対象を固定長に分割・管理する、つまり固定長レコード方式というものに
新規性があったと。そういうお考えで?
当時のソフトウェアエンジニアの通念というものが集計できるならば、あなたの考えは当時としても
非常に珍しい類のものだろうと思います。かなりエキセントリックだろうと思います

まぁ確かに、計算機についての基礎教養が欠乏、というかむしろ知的水準が絶望的に低い人間
にとっては世の中のあらゆる仕組みはあらゆる時代を通じて常に新規性に満ちた凄いテクノロジー
なのでしょうけど…
そういう知的弱者・情報弱者・底辺階級をターゲットにした功績話を絶叫するのはあなたの趣意ですか?

105 :名前は開発中のものです。:2008/11/18(火) 16:24:48 ID:vNWKmyux
i君乙
あいかわらず厭味だねぇ

106 :名前は開発中のものです。:2008/11/18(火) 22:15:12 ID:7msrEyPM
変わらぬ芸風も、また一興

107 :名前は開発中のものです。:2008/11/19(水) 02:14:42 ID:QielmcSv
>>101
今は継承を使わないのが流行り
おまえだってhasAにしてるんだろ?
特に深い継承はアンチパターンになりつつある
継承+多態の効率の悪さはいわずもがな
ゲームで使っちゃいけません

>>102
継承は基本的に汚いコードになると思うよ
設計書は綺麗になるけど

>>104
ギャラクシアン以外をタスクシステムと呼んでるのは某よっちゃんいかの人だけだよ
固定長レコードというCOBOL的なものをゲームに持ち込んだのは新規性がある
そもそも固定長レコードはフラグメント解消のものではなかった
バナナでクギを打った所に新規性があるんだよ
トンカチあるから必要ないよねっていうのは別の話

108 :名前は開発中のものです。:2008/11/19(水) 03:31:19 ID:FID+LaPo
>>107
"is a" 関係でも継承使わないってこと?それだと無理なコードにならない?

効率が悪いというけど、そもそもゲームで CPU 処理時間がボトルネックになること
すら稀なのに、さらにそのうち継承+多態によるものは数%以下でしょ?
ヘビーなループ内では問題になることもあるだろうけど、はじめから使わない前提に
する必要は無いと思うよ。

109 :名前は開発中のものです。:2008/11/19(水) 08:36:26 ID:yTZjB9bO
>>107
> 今は継承を使わないのが流行り
実装継承とインターフェース継承を混同しとるな。

110 :名前は開発中のものです。: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 :名前は開発中のものです。:2008/11/19(水) 19:37:40 ID:U55fYg17
(訂正)
> アセンブリ言語のプログラムは一行80カラム。
 ↓
アセンブリ言語のプログラムは80カラム単位でロードされた。
----------------------------------------------------------

>>170
> そもそも固定長レコードはフラグメント解消のものではなかった

固定長レコードとか固定長データとかいう構造(要するに配列)が大昔から現在まで色んなところで
便利に使われてるのはその取り扱いが、実装が、極めて単純だから。
例えば
・データの所在(番地)が容易に算出できる
  先頭番地+オフセット。このオフセットがレコード長*レコード番号で済む。
  処理が単純化できるし回路も単純化できる。つまり真空管数(トランジスタ数)を抑えられる
  占有面積も重量も放熱設備も電気料金も抑えられる。
・外部フラグメンテーションの制御が簡単
  記憶領域を【容易に】再利用できる
  最大長を決めてるからデータ書き換え時には旧データに新データを直接上書きできる
などなど。頻繁に書き換えるデータにはどれも重要な特性。

固定長なデータ構造はそのメリットの大きさゆえに、デメリット(レコード内の無駄。内部フラグメンテーション)
が許容されるケースは多い。COBOLも、COBOLが登場する以前の事務処理プログラムも可変長データの大半は
最大サイズを決めたうえで固定長レコード、それを収束した固定長ブロックで格納した。
今のRDBや簡素なDBMも基本的には同じ

112 :名前は開発中のものです。:2008/11/19(水) 20:12:26 ID:U55fYg17
>>170
> バナナでクギを打った所に新規性があるんだよ
> トンカチあるから必要ないよねっていうのは別の話

その例え何かおかしくないか。常温バナナで釘を打つのは確かに斬新な愚行だが

規模がまるで違うものを指してトンカチと冷凍バナナという話をしているのかなと前向きに解釈してみるか

大昔には科学者もエンジニアもシステム屋もみんな今とは比べ物にならないくらい貧弱なハードでやり繰りしてた。
FORTRANやCOBOLが登場する以前の計算機を駆使する人間は多かれ少なかれ今で言うところのハッカーじみた
技能やバッドノウハウを身に付けて自前のサブプログラム群をシコシコ作って自前ライブラリ用意したりした。
FORTRAN登場後も初期のFORTRANコンパイラの最適化は不十分で最内周ループ処理など頻繁に呼び出す処理の
アセンブリコードを自分で書く利得は大きかった。(※)

これらは日本のビデオゲーム業界が隆盛を誇るずっと以前の話

つまり、ド貧弱な装備でシコシコ戦うことを強いられ、セコくて貧乏くさい高速化テクやリソース節約テクを駆使してたのは
何もゲーム業界固有の境遇・逆境だったわけじゃない。もしゲーム業界固有だなどと思い込んでる人間がいるなら
そいつはルサンチマン君だ

(※)その後BLAS、LAPACK、MPIなどなど先人の開発した優れたライブラリが沢山登場し
   FORTRANコンパイラの最適化機能もとても優秀なので自前でシコシコする必要なくなった

113 :名前は開発中のものです。:2008/11/19(水) 20:14:33 ID:U55fYg17
(訂正)
>>170

>>107

>規模がまるで違うものを指してトンカチと冷凍バナナ

本来の用途がまるで違うものを指してトンカチと冷凍バナナ

114 :名前は開発中のものです。:2008/11/19(水) 22:25:30 ID:1obj959Z
>>108
俺も継承は使わないほうがいい派
実装とかインターフェイスとか関係無い
そのメソッドやメンバがどのクラスのものであるのかわからなくなるのが最大の害だと思う
しかもオーバーライト(?名前忘れた)されると今度は同じ名前のメソッドがあって
どれを呼んでるのか本格的にわからなくなる

どうしても使わなきゃならんのがMFCみたいな変態実装になってる場合
自分に内包してるモンを継承使って書き換えさせるウンコソース
これは仕方がない

でも、できるだけhas aの関係でまとめたほうがいいと思う

115 :名前は開発中のものです。:2008/11/19(水) 23:52:57 ID:GeiIfEUV
>114
ttp://www.bizlogic.co.jp/techinfo/reconsider/inherit.htm

>新人プログラマほど継承を乱用します.特に新人が好むのは、
>コードの再利用のための継承です.(中略)
>新しいサブクラスが必要になって定義しようとしたら、親ク
>ラスに不整合があることを発見して修正.すでに定義済のサ
>ブクラス群に影響が出るためそれらを修正.その影響がクラ
>スのクライアントに出ることに気づかず、バグが連発.修正
>を繰り返すうちに設計し本人しか理解できないような継承階層が完成・・・

イイハナシダナー

耳の痛いことだが、とりあえずタスクシステムのせいじゃないと思うんだw


116 :名前は開発中のものです。:2008/11/19(水) 23:59:13 ID:GeiIfEUV
ギャラクシアン以外をタスクシステムとして認めない原理主義者が現れてスレ的には
おめでいたいことだが、狭量すぎやしないか?
とりあえずメモリ管理については
・当時はそもそも自前のメモリ管理以外存在しない。
・メモリに制約のあるシステムならタスクシステムでなくても必要
だから、タスクシステムの絶対条件じゃないと思うんだが。

117 :名前は開発中のものです。:2008/11/20(木) 00:34:43 ID:9Z88vxLa
そもそも当時と今とでは
「メモリ管理」って言葉が指すものがだいぶ違うからな。

今のゲーム開発だと
メモリ管理モジュールの綿密なアーキテクチャの設計と実装を主に指すけど、
当時のは「管理モジュール」なんて呼べないような極々シンプルなものだからな。

118 :名前は開発中のものです。: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 :名前は開発中のものです。:2008/11/20(木) 00:52:20 ID:K7xBu4Cw
>>117
CUDAを調べてて思ったんだが、メモリ・ワークをどこにとるかでパフォーマンスが
大幅に違ったりするみたいだし、いまどきのゲームのメモリ管理ってそうなんだろうな


120 :名前は開発中のものです。:2008/11/20(木) 01:35:27 ID:sLhTakp+
3スレ目になったが、今だに喧嘩腰じゃないと議論もできないのか・・・

121 :名前は開発中のものです。:2008/11/20(木) 01:41:10 ID:K7xBu4Cw
>>120
喧嘩腰に見える?そりゃすまん。

122 :名前は開発中のものです。:2008/11/20(木) 03:32:51 ID:sLhTakp+
ああいや、個人を指してるわけじゃなくて、
スレ全体の雰囲気のことを言ってる。

123 :名前は開発中のものです。: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 :名前は開発中のものです。:2008/11/20(木) 23:39:52 ID:Xvygn8lQ
(訂正)
○MHzの8bitCPU

○MHzの8or16bitCPU

125 :名前は開発中のものです。:2008/11/21(金) 01:39:25 ID:gOWsGtVr
>>123
そういう立ち位置なんだとすると余計にわからなくなるのよ。

>「ここでタスクシステムと呼ばれてるものが何なのか知らんけど」

という立ち位置の人間が、ゲーム開発者ローカルな用語である「タスクシステム」
という用語とそのスレッドで、

>タスクシステムすげぇすげぇ言ってる超小規模開発・個人開発なら

てな形で批判的な言説を繰り返す理由が。てっきり

>タスクシステムを心の底から崇拝する人間が心の底から子バカにしている様子がたまに見受けられる 配列厨のコードそのものだ。

という形で小ばかにされたことをこのスレにぶつけてるんだと思ったよw 俺の立場としては

>ゲームプログラムでは、複数の構造体変数を管理することにより、複数のキャラクタを
>管理できます。複数の構造体変数を管理するための方法は、構造体をリスト構造で管理
>する方法と構造体を配列で管理する方法の 2 種類あります。
ttp://msdn.microsoft.com/ja-jp/academic/cc998623.aspx
の実装方式の一つだろうという前提で、そのメリットデメリットに興味があってここに参加しているのだけども。
ちなみに上記の例でいえば、マイクロソフトは配列厨だなw


126 :名前は開発中のものです。:2008/11/21(金) 01:41:47 ID:Ch23O/ls
>>120,122
タスクの話題に限ったことじゃないけど
賛成か反対かの単純な対立に流れることは多いね。
わかりやすいから盛り上がるけど白熱しすぎて喧嘩になったりする。
でもその対立構造が正しいとは限らなくて
良い意見が喧嘩に埋もれてしまったり。

ゲーム製作技術板なのに技術の話じゃなくてすまん。

127 :名前は開発中のものです。:2008/11/21(金) 02:31:22 ID:gOWsGtVr
>>126
確かにそうだ。俺も何が対立軸なのかよくわからなくなってるよw
俺は情報系の人間じゃないんで、ゲームのオブジェクトの相互の振る舞いは
FSMの一形態と見なせるみたいな発言を単純に面白いなと感心するんだけど。


128 :名前は開発中のものです。:2008/11/21(金) 02:35:33 ID:EpPTVUTk
配列で線形リストも組めない雑魚が配列をバカにしてるのを見ると悲しくなるし、
そもそもタスクシステム(特にこのスレで主流の複雑な実装)は速度的に不利なんだから
素直に配列さんごめんなさいって言えばいいと思う

129 :名前は開発中のものです。:2008/11/21(金) 21:53:14 ID:HLQRvhCb
この3連休でタスクシステムの仕様についてまとめるように、以上。

130 :名前は開発中のものです。:2008/11/21(金) 23:55:06 ID:gOWsGtVr
>>128 が、>>123だとして、わからん、お前のいうことはわからん!(大滝秀ry

>配列で線形リストも組めない
どこかで queue を配列で組む入門例があったけど、そんなものじゃないだろうし、
だとしてもその線形リストで、まさかタスクシステムをつくるわけじゃなかろうし、わからん。

>雑魚が配列をバカにしてるのを見ると悲しくなるし
どのレスを指しているのか、わからん!

>このスレで主流の複雑な実装
どれだよ!>>43なんか、
>誰が書いても同じようなものになるってくらい凡庸な、道端の雑草並みのありふれた仕掛け
とかいってるぞ。凡庸でありふれて複雑て、どっちなんだよ。

>速度的に不利
いや、ロジックの部分は大して食いませんてば。最近のゲームはそうでもないのか?

>素直に配列さんごめんなさい
君が配列ラブなのだけはなんとなくわかったよ。ごめんな。


131 :名前は開発中のものです。:2008/11/22(土) 06:09:06 ID:gy1lHoyD
>>128は書いてる内容から明らかに雑魚だなw

132 :名前は開発中のものです。:2008/11/24(月) 11:26:55 ID:bZE/I6Oe
>>129
いまどきのタスクシステムの仕様
1.クラス名、構造体名に「Task」を含む
2.描画物とそれ以外の処理を同列に扱える(ことがある)

これくらいじゃね

133 :名前は開発中のものです。:2008/11/24(月) 23:39:25 ID:0qULllkp
「ゲームプログラマになる前に覚えておきたい技術」
を読んだけどタスクシステムなんて使ってなかった
普通に配列使ってて、配列の上手な使い方がのってた

やっぱプロは配列を使うんだね

134 :名前は開発中のものです。:2008/11/24(月) 23:42:11 ID:L4g5tFOs
>>133
2chでしかでかい声は聞かない(マジで)

135 :名前は開発中のものです。:2008/11/24(月) 23:58:55 ID:c7RL3I32
>>133
はいはい、配列さんごめんなさい。

>>133は、配列の利便性と構造体を使ったリストの有用性の違いがわかっていないようだ。
もう一度、データ構造を見直すことをお薦めする。

136 :名前は開発中のものです。:2008/11/25(火) 00:45:31 ID:iVVKZxJp
>>133
おま・・・リスト使うか配列使うかの話かよw
セガがリスト使わないなんてありえないから、安心して両方の使い方を覚えような
ついでに二分木やハッシュも覚えておくこと

137 :名前は開発中のものです。:2008/11/25(火) 00:58:47 ID:nYppp7MY
配列 : 削除、追加時のコストが高い。検索が速い
リスト : 削除、追加時のコストが安い。検索が遅い

リストは単純に舐めるだけでも遅い
ここで比べるべきなのはデータの検索(巡回)・追加・削除がゲーム中にどれだけ発生して
それを処理するにはどんなアルゴリズムとデータ構造がベターであるかだ

データの検索(巡回)よりも追加と削除のほうが多いゲームなどない
だからリストより配列のほうがゲームに適している

リストの有意点とはデータサイズの見積りをサボれるという一点に尽きる
たしかに配列のリサイズはゲーム中にはとても不可能だからこれは魅力だ
しかし、ゲームを製作する上で場面ごとに必要なメモリの見積もりなんてやって当たり前の話で
その程度の理由でリストを使うなんておかしい

以上の理由からゲームでリストを使う事はない


弾幕STG等ひたすら衝突判定を繰り返す場合なら
検索アルゴリズムの都合で配列よりツリーがベターな場合もある
(STG製作技術スレで話題になってたエリア別ツリー構造等。FPSでよく使われるが)
だから配列がベストとは言わないが少なくともリストに劣ることは無い

138 :名前は開発中のものです。:2008/11/25(火) 02:46:59 ID:WElvD00o
いつからリスト対配列になったんだ?
タスクシステムは固定長データが重要とか言い出した>99あたり?

つか>126じゃないけどその対決って
どうしても勝ち負けを決めないといけないようなことなの?

139 :名前は開発中のものです。: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)に対して非常に有利なので、
ランダムアクセスがありそうなら配列を、挿入がありそうならリストを選ぶのが一般的。
どちらもありそうなら実際に処理時間を計測してみるのが良い。
処理時間とは別に、メモリのフラグメントを嫌ってリストを避けたい場合は、
データ本体は配列構造に置き、管理はZソートされたリスト構造に、
というように両方を組み合わせる手法もある(C++オブジェクトをメモリプールするのと同じことだけどね)。

とにかく、初学者は「どっちが勝ち」みたいな議論に振り回されないこと。
ぶっちゃけ実際に動かしてみて問題がないなら、なんであれそのやり方は正しい。

140 :名前は開発中のものです。: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の意味をよく理解していないA人の話をよく聞いてないかB意図的に歪曲して解釈しようと努めている、のどれかだろう。
@ならFSMや有限状態機械でググレとしか言えんしAならちゃんと読んでくださいとしか言えんしBなら正直相手にしたくない

奇遇にも過去にこの人物と同じ解釈「タスクシステム=FSM」を披露したのはルサンチマン君のID:SCRh4oL7ただ一人だ。
ID:K7xBu4Cw 、ID:gOWsGtVrがこれと同一人物なのか知る由も無いが、かなり似通った特徴的な思考・読解の持ち主だなとは思う。

さて、この人は更に>>130で「>>128 が、>>123だとして」という謎めいた仮定を持ち出してるのだが、なんでこうなるんだろうね…
俺の過去発言と照らし合わせれば無理があると容易に分かるはずだよな
この人は>>130で自らそれを説明してみせているにも関わらず、その仮定が真であるという前提のコメントを書くだけで
その仮定が偽であるという(当然あってしかるべき、より可能性の高い)前提のコメントは結局書くことはなかった。妙だね

 ・ただ単にコミュニケーション能力の不足、悪意のない、無知、短気、舌足らずゆえにこういう尻切れトンボで終わった
 ・「>>128>>123であってほしい。いやむしろそうあってくれ。頼む。これで終いにしよう」という願望の現われ

まぁ後者ならそのご期待には添えないとしか言えない
俺は配列に「さん」付けしてもらうことも、ましてや便所のラクガキにおいて初心者(?)に謝ってもらうことにも興味がない

141 :名前は開発中のものです。:2008/11/26(水) 00:23:32 ID:wcFZ5Gxi
(※)素直な思考の持ち主ならば、ゲームプログラムの中で【状態を保持し遷移する】ような要素、つまりFSMモデルを適用しやすいもの
としてまず初めに思い浮かぶものといえばシーン(オブジェクト)やエンティティだろう。そういったもの⊂FSMと解釈するならわかる

>>2そのものをFSMとして説明することはできるが、これを言い出したらプログラムも電子計算機も社会基盤も自然環境も惑星も
#銀河も宇宙もFSMモデルで説明できるという話になる。ぬるま湯に溶かしたハナクソを構成する分子の振る舞いも、乾いて風化した
#ハナクソ粉体の振る舞いもFSMモデルで滔々と説明できるという話になる。こういう話は埒外であり、するつもりはない

142 :名前は開発中のものです。:2008/11/26(水) 01:14:00 ID:bxsuU9Ti
話が難しすぎてついていけません><

143 :名前は開発中のものです。:2008/11/26(水) 02:19:03 ID:RbP/LZbz
>>140が誰と何の話をしてるのか全然わからんけど
>>2=「ジョブコン」=FSMという話は直感的で分かりやすいと思うぞ

てか名称「タスクシステム」は人によって定義が違うから使うな。議論が混乱する

144 :名前は開発中のものです。:2008/11/26(水) 02:34:19 ID:RbP/LZbz
ああ、>>140をフォローしたつもりが逆だったらしい
>>140はFSMって言い方が抽象的すぎるっつってんのね?
了解。もう言わん

145 :名前は開発中のものです。:2008/11/26(水) 08:30:23 ID:P2jaFZy4
>>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
ただまあ、タスクシステム(ジョブコンでもいいや)の適用範囲とか実装上の問題点と
か、そういう流れになってくれると嬉しいんで、「これで終わりにしてほしい」という
のも正直なところ。だからピンダッシュに反応しすぎた俺も悪い。もうだまっとく。


149 :名前は開発中のものです。:2008/11/26(水) 23:53:44 ID:wcFZ5Gxi
>>139>>137のお話について横から首突っ込んで初学者向けにポエムを書いてみるか

実際の処理速度を語るとき、ランダムアクセスといったら、メモリアドレスを基準にしたランダムアクセスという話も当然絡んでくる
データ構造上の順番(連結リストなら繋がれた順番)を基準にしたらリニアアクセスだよ、といってもメモリアドレスを基準にしたら
ばっちりランダムアクセスになっていました、という状況も当然あり、この場合は処理する要素数と要素サイズと実装対象によっては
べらぼうなペナルティを受けたりする。ので

>>リストは単純に舐めるだけでも遅い
>誤り。「単純に舐める」=シーケンシャルアクセスに有意差はない。

これは状況ごとにプロファイラなりアナライザにかけて検証してみないと分からないというツマラナイ結論に帰結する
ので

>とにかく、初学者は「どっちが勝ち」みたいな議論に振り回されないこと。
>ぶっちゃけ実際に動かしてみて問題がないなら、なんであれそのやり方は正しい。

だよな

(続く)

150 :名前は開発中のものです。:2008/11/26(水) 23:55:50 ID:wcFZ5Gxi
(続き)
ただし、連結リストを>>2のように使う場合と、ジョブの種類別に配列でデータを固めてる場合(※)を比較すると、前者は不利な状況に追い込まれる
>>2は何でもかんでもごった煮の連結リストでおまけに各要素は好き勝手にジョブを指定してくる。プライオリティ(?)とかいう変数を何に使うのか
知らないがこれでソートされてようが各要素で毎度毎度サブルーチンのアドレス(関数ポインタ)経由でジョブを実行させている
つまりハードウェアにとっては要素ごとに何のジョブを実行するのか予測が難しい。どのジョブが実行されるにせよ、その内容が大して代わり映え
のない超単純な数値積分であれば、分岐予測で速度を稼ぐハードウェアにとっては嫌がらせに近い仕掛けであり、ブチ切れる可能性が高い

○万のパーティクル(数千の通常弾に数千の煙に数千の閃光に数千のフラグメント)を撒き散らす物量ゲーとかなら、そういう要素には
>>2ではなくジョブの種類別に配列でデータを固めて一括処理するほうが速度が出やすくなる。
趣味プログラマであれば、今様のゲーマー仕様PCで実験してみればすぐに確認できる

(※)この手の配列厨コードは、Zソートを回避するあるいはCPUによるZソートを回避する色んな工夫とセットになる。
単純な加算合成だけでなく、アルファブレンドなしアルファテストのみテクスチャに描いてグレア処理して合成とか色々

151 :名前は開発中のものです。:2008/11/27(木) 00:37:08 ID:q61URdTy
>要素ごとに何のジョブを実行するのか予測が難しい

その辺は面白い、つか考えてなかったな。
以前、ビデオキャプチャしたYUY2をP4-2.4GHzでソフトRGB変換する、ってのをやってて、
30万ピクセルをfloat演算して1フレーム8msec.程度でで処理できてたから、いまさら数万の
オーダーでがたがたいうなよって思ってたけど、言われてみれば配列のシーケンシャル
処理に近いんで、キャッシュの効かなそうな処理なら、どのくらいで処理してるのか確
認すべきだな。


152 :名前は開発中のものです。:2008/11/27(木) 00:57:00 ID:q61URdTy
>プライオリティ(?)とかいう変数を何に使うのか 知らないが

これはメリットというより必要悪に近いんじゃないかな。ゲーム上のオブジェクトを
動的に生成するタイプのタスクシステムだと、処理順が不定になってしまうので、
プライオリティという形で処理順を明示できるようにしてある、みたいな。
そこまでして処理順を確定しないといけないような場面があるのかどうかは
ちょっとわからん。初心者なもんで。


153 :名前は開発中のものです。:2008/11/27(木) 05:33:57 ID:d1RPtk1Q
処理順は固定じゃないと駄目なんだよ
壁当たりの判定を保持するような物体の当たりチェックは
普通の物体のチェックより後にやらないと
簡単にすり抜けが発生してしまう

俺、当たりのチェックだけはタスクシステム使ってようが
直書きしたほうが安全な気がする

154 :名前は開発中のものです。:2008/11/27(木) 06:07:57 ID:qLIfWPBB
プライオリティについては>>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リストに入れりゃいいんだよ。
別に配列でもいいが。

155 :名前は開発中のものです。: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 :名前は開発中のものです。:2008/12/01(月) 19:17:54 ID:JLnsfkv1
だからタスクシステムなんて聞くのは2chだけだって
ここの信者だけだよ威勢がいいのw
だって現場で聞いたことないもんw

158 :名前は開発中のものです。:2008/12/01(月) 21:32:13 ID:igKS/Zf4
大手ならどこでも通じる

159 :名前は開発中のものです。:2008/12/01(月) 22:17:35 ID:JLnsfkv1
>>158
そしたら下請けに流れてきてもおかしくないじゃん

160 :名前は開発中のものです。:2008/12/01(月) 23:06:38 ID:/JTH9VCP
俺は自分からは使わんが、他社の2回くらい見たぞ?
もちろん>>2そのままじゃなかったが、ネットでよく聞くから増えてんじゃね

つーかさー、NDSのサンプルよく読んでみろよ・・・
現場で見たことないって騒いでるやつはDS開発やったことないのか?

161 :名前は開発中のものです。:2008/12/02(火) 01:05:14 ID:68pyN8gN
サターンしかやったこtない

162 :名前は開発中のものです。:2008/12/02(火) 08:48:36 ID:2eboyQhG
俺は、据え置き型ばっかり


163 :名前は開発中のものです。:2008/12/02(火) 17:21:35 ID:2m2wCEKn
ttp://www.page.sannet.ne.jp/hirasho/diary/diary0812.html#2
ひらしょ氏、今日の日記でも検討してるな。

いずれにしても銀の弾丸じゃないのは当然として、鉛の弾丸かどうかは微妙なところか。
否定派のつもりはないけどね俺。

164 :名前は開発中のものです。:2008/12/02(火) 19:37:52 ID:RctAWrR8
>>163
いいなこの人
説明に難しい言葉を使わないようにしてるし
ちゃんと人に伝えようという文章に好感が持てる

165 :名前は開発中のものです。:2008/12/02(火) 20:12:02 ID:VDtsWa1y
たしかに
タスクシステムとは可搬性と再利用性に優れた素晴らしいシステムなんです
とか繰り返してた人たちの話よりよっぽど分かりやすい

166 :名前は開発中のものです。:2008/12/03(水) 02:05:13 ID:lPaxGufd
ひらしょ氏の日記見て来ますたw

つか、ヒープのフラグメント避けるためにサイズの違うデータでも固定長メモリ確保するとか
俺が学生時代にごくナチュラルに作ったものだが・・・。メモリプールという言葉の存在すら知らないまま。
まずさ、ゲームで使われている技術なんて、3Dやら除けば全然大したことがなくて
独自性などどこにもなということを認識するべきじゃなかろうか。とりわけ今となっては。

> だからタスクシステムなんて聞くのは2chだけだって

昔のアマゲ周辺でそれなりに聞いたかな。某よっしん氏等も使ってた記憶が。
ただ、言葉は聞くけど実体は人それぞれという類のものだよね。
オブジェクトをリストで繋げて更新ルーチンへのポインタ保持してるだけで
俺がガンダムだって言っても、言葉の定義なんかないんだから自由なわけだしさ。
実際、昔言ってたタスクシステムもその程度の代物でしかなかったと思うんだよ。

そうだな、それでも、C++がまだ使われていなかった頃はそれなりに画期的、というのもちげーな
「ああこうすればいいのか」と人を感心させられる程度のものではあったかもしれない。
ひとつのテクニックとして名前をつけて呼ぶ価値があったと思うよ。10年以上前の話。

でも、今となってはこんな普通にC++で書けば自然にできるようなことをシステムなんてとても呼べないし、
それでもタスクシステムという名前にこだわってる人は、もっと高度な何かを語ってると思うんだが

何それ?っていうか、要らんよねぶっちゃけというか、コード見せれ、というか

俺としては、C・アセンブラ時代に言ってたタスクシステムが、ものすごいタイムラグを経て、
一部のアマチュアに、おかしな形で伝わってしまっただけじゃね?と思っているのだが。
もしそうだとすれば、素人を混乱させる有害情報でしかないので火消しが必要なレベルだと思う。

そうでないなら、とにかくコード見せて。

167 :名前は開発中のものです。:2008/12/03(水) 02:14:33 ID:Smp60beT
>164は>165を指してるんだよね。
http://pc11.2ch.net/test/read.cgi/gamedev/1036512390/860-862

168 :名前は開発中のものです。:2008/12/03(水) 03:28:15 ID:uVk3FrZq
そのスレ読んだ
LGPLを含むEXEがLGPLに感染してるなんてライセンス文読めば一目瞭然のことを
何とか超解釈で否定しようとしてる子が定期的に出没していて
その理屈は違くね?という人達が理詰めで外堀から確実に徐々に埋め立ててる
そんな感じ?

物事をひん曲げて解釈したがる人を諭すには
駄目押し気味でもああいうのも有効かなとはおもた

169 :名前は開発中のものです。:2008/12/03(水) 11:42:42 ID:YzqEx1FO
>>167
あのスレのレスは三行でまとめて欲しい

>>168
あのスレごちゃごちゃしすぎてて、自分で何書いたかさえ忘れる

ところで、感染しないライセンスなんて無いよ。例えパブリックドメインであっても。
結合したら二次著作物なんだから。

170 :名前は開発中のものです。:2008/12/03(水) 12:08:41 ID:1jatayxx
>>169
二次利用に縛りをかけないライセンスは存在する。

ていうか、パブリックドメインとは、だれのものでもない存在だから、
二次著作物とかそういう縛りもない、はず。

171 :名前は開発中のものです。:2008/12/03(水) 12:59:17 ID:YzqEx1FO
>>170
うーん、有名どころで二次利用に縛りをかけないライセンスを見たことないけどな。
少なくとも「本ライセンス文書を同封しろ」と書いてある。

パブリックドメインに関しては著作権者が権利放棄してるから、利用に縛りはないだろうけど。

172 :名前は開発中のものです。:2008/12/03(水) 13:23:37 ID:6uS+aRN8
>>169-170
おまえらあっちのスレでやれ。
>>168
むしろ逆効果にしか見えないのだが、
前スレで釣り宣言してたからそれで狙い通りなのだろう。

173 :名前は開発中のものです。:2008/12/03(水) 13:25:50 ID:ls+0FiDV
三次利用以降に縛りをかけない事、という縛りをかけてるものはあるな

174 :名前は開発中のものです。: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 :名前は開発中のものです。:2008/12/04(木) 00:28:18 ID:J8DrEDup
_tmainじゃなくて_tWinMainだったかな。よくおぼえてないや
各シーンはいわゆるベタベタの配列厨コード。元HSパーだから仕方ないね
でもメモリもGPUリソースもジャブジャブ使いまくったおかげで
見た目はバリバリのイケイケになったよ。動作も軽快だったよ。自惚れだね

176 :名前は開発中のものです。:2008/12/04(木) 02:00:33 ID:yi3zavJ4
>>174
たのむ
なにが言いたいのか最後に書いてくれ

俺が気になるのは、メインループが本当に必要なのかどうかだな
タスクシステムも、それ以外のC++コードでも、なんでメインループ作るん?いらなくね?
普通に書けばいいじゃん(普通ってなによ)

177 :名前は開発中のものです。:2008/12/04(木) 02:16:23 ID:vVwN1TZ0
stage1->Run()はstage1が終わるまで返ってこないんだろ。
いずれにせよゲームなんて毎フレームの同じ処理の繰り替えしなんだから
どこぞかにループは存在するのが当たり前だと思うが。

178 :名前は開発中のものです。:2008/12/04(木) 02:16:58 ID:iyneYGG1
>>176が言う普通ってどんなコードなんだろうね

179 :名前は開発中のものです。:2008/12/04(木) 03:27:17 ID:yi3zavJ4
あーすまん
メインループはどんなプログラムにもあんね

なんかさ、1フレームごとに回るループを作るやり方と
作らないやり方(あちこちでupdateする)について
急に気になって言ってみたんだが
やっぱどっちでもいい気がしてきたからいいや

180 :名前は開発中のものです。:2008/12/04(木) 04:04:02 ID:BYcsjOha
スレッド作るにしろなんにしろ
どこかでスケジューラが回ってるがな

181 :名前は開発中のものです。:2008/12/04(木) 10:56:55 ID:vVwN1TZ0
>>179
> 作らないやり方(あちこちでupdateする)について
> 急に気になって言ってみたんだが

それは使ってるフレームワークが裏でループ回してupdate()呼んでるんだろ。
あるいは割り込み駆動の可能性もあるが。


182 :名前は開発中のものです。:2008/12/04(木) 22:22:51 ID:wPvA+LuT
>>175
>見た目はバリバリのイケイケ
気になるな。

183 :名前は開発中のものです。:2008/12/05(金) 00:50:08 ID:Vt/x/8eI
>>176
>たのむ
>なにが言いたいのか最後に書いてくれ

地域担当の教団勧誘員に>>174を見せると彼の顔はみるみる青ざめ、ついには目を背けてしまいました。
ただごとでない様子を感じ取った私は恐る恐るその訳を尋ねました。すると彼はおずおずと耳元で囁くのです。
「それはいけない。凶兆が見えます。そのようなものを作っていては遠からず仏罰が下るでしょう。南無妙法蓮華」
>>174は彼らの"先生"の教義に反する、知性体として恥ずべきお猿さんコードなのだそうです。私は狼狽してみました。
幼少の砌よりツクラーにしてHSPerである私の深層に眠る劣等感の残滓の存在をESPで見抜いたのか、彼は目を細め
「安心なさい。今からでも間に合う。私共のように三宝(  *  )に帰依なさい。そうすれば必ず道は開けますよ」
と仏様のような微笑みを湛えながらビール券とこの案内状をくれたのです

184 :名前は開発中のものです。:2008/12/05(金) 00:51:18 ID:Vt/x/8eI
>>183続き
(∀・ *)【三宝】…■松浦本■やね本■逆引き本
┌──────────────────────────────────────────┐
│ 【集会のご案内】                                                       │
│   タスクシステム(>>2)こそ失われた聖杯、伝説の神器、至高のオーパーツ、現代のエクスカリバー  |
│   私どもの教団では、身も心も何もかも唯一無二のリンクリストに捧げることで驚きのTCBがプライ  |
|  オリティすることをお約束します。奮ってご参加ください                                |
│  タスクシステム総合スレ part3                                              |
│  http://pc11.2ch.net/test/read.cgi/gamedev/1226199100/l50                           │
|                                                                  |
| 【社説】反動分子の煽動記事に惑わされてはならない                                  |
|  http://diary.imou.to/~AoiMoe/2008.12/early.html#2008.12.02                         |
|  http://d.hatena.ne.jp/naoya2k/20081201                                     |
|  http://qo.sakuratan.com/2008/07/24/タスクシステムのこと。/                        |
|  万物を支配するは唯一無二のリンクリストをおいて他に無く、秩序をもたらすはTCBのプライオリテイのみ。|
|   この崇高なる輪廻転生の法を冒涜し踏み躙る邪教徒共はママの愛情が足りなかったに違いない。 .|
|  敬虔なる信徒諸君は彼らの妄言に惑わされることなく修行に励みたまえ。そして最終解脱者となっ.|
〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜

ビール券に弱い僕は誘われるままホイホイとこのスレにやって来たんだね

185 :名前は開発中のものです。:2008/12/05(金) 03:20:55 ID:JyB7wu71
そろそろタスクシステム総合スレじゃなくて
ゲームシステム総合スレに名前変えね?
>>2を使ってる人は皆無なわけだし

186 :名前は開発中のものです。:2008/12/05(金) 04:47:21 ID:U4VbVISL
いや、ここ隔離スレだから…

187 :名前は開発中のものです。:2008/12/05(金) 05:37:33 ID:lg/+bi94
>>185
あー、ゲームシステム総合とか間抜けたスレタイいちいち考えなくていいから
既存スレちゃんとあるんで。こっちでは撲殺天使の人もあっちでは普通だから

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

既存スレからタスクシステムを隔離するためにこのスレは作られたんで
このスレが誘蛾灯として機能するにはこのスレタイは好都合この上ないんで
悪いけどお前が思ってる以上にそこそこ需要あるんだわ

>>2を使ってる人は皆無なわけだし

は?お前が憤死しても代わりは幾らでも湧いてくるから心配しなくていいって


188 :名前は開発中のものです。:2008/12/05(金) 09:54:30 ID:bKzmksBZ
やね本はプレミア付く程のレア物

189 :名前は開発中のものです。:2008/12/06(土) 00:08:37 ID:AlgIGpgY
>>166
何がいいたいかわからん。動的インスタンスリスト巡回アップデートwの具体的なメリットデメリットを指摘すればいいんじゃないか?
ttp://www.issei.org/
そのひらしょ氏の本を手伝ったらしいPGさんのブログ。タスクシステムらしきソースがある。
問い詰めた知人てこのひとかな?
例えば>>174をタスクシステムで書いたとして、単純に比較すればそりゃ
>直感的でない、変に抽象化されてデバグしにくい、実行順がコードの形で書かれておらずメンテしにくい
コードだと思うんだよ。んで、それでも使いたいメリットあるのか?て話だよな。

俺は本職のゲーム屋さんじゃないんで失礼かもしれないが、わかりにくいところもあるけど、
結構融通が利いて便利かもと思ったよ。
ためしにプロトタイプを作ってて、「ここで一発エフェクトが欲しいな」と思ったところで、new してリストにつなぐだけで動くってのはちょっと感心した。

あと、メインループ周りを作ってしまえば、そこをいじらなくても別のゲームが作れるのは
なれれば安心感があるな。
ただ、万人にお勧めできるかつと、それはちょっと難しいかもとは思う。


190 :名前は開発中のものです。:2008/12/06(土) 00:15:03 ID:+2mVCqZ1
>>189
>ためしにプロトタイプを作ってて、「ここで一発エフェクトが欲しいな」と思ったところで、new してリストにつなぐだけで動くってのはちょっと感心した。
これホントは動かないのが普通なんだよ
裏でグローバル変数でつながってるからnewするだけで動くように見えるだけ
可能でしょ?そういうの?
本来あるべき手続きを見た目見えなくするもんだから
後で「え?そんなところと関係あるの?」っていう部分がボロボロ出てくる

結果これ以上ないデスマになる

191 :名前は開発中のものです。:2008/12/06(土) 00:28:23 ID:AlgIGpgY
>>190
レス早すぎるだろw
>後で「え?そんなところと関係あるの?」っていう部分がボロボロ出てくる

そういう不安は、まあ、あるな。自分が把握していられる範囲ならともかく、
「3日前のコードは他人のコード」な人(俺だ)とか。

>裏でグローバル変数でつながってるから
これ、このスレでよく批判の対象になってるけど、俺が見た範囲では
それぞれ listはprivateにしたり一応保護する工夫をしているように見えるけど
「オブジェクト同士が相互参照できるならグローバルと同じで無意味」ってこと?


192 :名前は開発中のものです。:2008/12/06(土) 03:37:13 ID:+2mVCqZ1
>>191
タスクシステム云々ってよりグローバル変数の駄目な理由そのものじゃん

193 :issei:2008/12/06(土) 07:28:54 ID:wah4ZAkA
>>189
> タスクシステムらしきソースがある。
どこに?

私は、いまどきのハードウェアならタスクシステムは捨てて、役割ごとに std::list<> なり
配列なり作った方が良いと思ってる。

http://www.issei.org/blog/archives/000225.html

194 :名前は開発中のものです。:2008/12/06(土) 11:22:47 ID:r2noZKmJ
>>193
名前欄入れてらっしゃるけど、ご本人様で?

そのエントリによると、新人研修でタスクシステムのようなものを教えてる
ところは実在するわけですかね。

195 :名前は開発中のものです。:2008/12/06(土) 12:02:44 ID:+2mVCqZ1
散々タスクシステムを崇拝してきた人間も
ひらしょーさんの「なにそれ?」で完全に散ったなw

196 :名前は開発中のものです。:2008/12/06(土) 12:40:25 ID:r2noZKmJ
入門を脱したばかりの奴が入門記事を書く悪循環に、
ちょうどタスクシステムがはまっていた感はあったな。
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のサンプルや、ほかに公開している
ものはその範疇かな、と思った。
 定義自体あいまいなところがあるので、タスクシステムと呼ばれたくない、
ということであれば申し訳ない。


199 :名前は開発中のものです。:2008/12/06(土) 23:09:38 ID:vtDZydvR
毎フレームstd::listに繋がったメンバ関数を呼ぶだけのものに
システムとか名前つけること自体が厨臭くてダメだろ。

200 :名前は開発中のものです。:2008/12/06(土) 23:25:08 ID:Z3cf8eY8
GUIアプリのデザインパターンとしてなんらかの名前があると思うんだけどなぁ

201 :名前は開発中のものです。:2008/12/06(土) 23:49:37 ID:gO9ddo5C
>>199
命名自体は思考の道具として必須だよ。
りんごを「りんご」と呼べないならそれをどう頭の中で扱うのか?

ただ、付ける名前の好き嫌いと妥当性はあるだろう。
自分の子供に「悪魔」と名づけたら批判される。
まあその程度なんだが。

202 :名前は開発中のものです。:2008/12/07(日) 01:28:33 ID:DJqT4ev1
大袈裟過ぎるのは確かなんだが
いまさらどうにもなんないよなぁ

203 :名前は開発中のものです。:2008/12/07(日) 02:16:59 ID:ubrMdVl3
>>202
タスクもシステムもOSを意識してしまう用語だからな。
言葉の意味的には >>92 のいう ジョブコン(トローラ)の方がより厳密かなあ。

204 :名前は開発中のものです。:2008/12/07(日) 02:54:06 ID:0juovOZI
名前なんかどうでもいいじゃん、あほらしい

205 :名前は開発中のものです。:2008/12/07(日) 03:37:41 ID:mATZsXLl
しかし、タスクシステムを崇拝してる奴等は
自分が学ぶ技術に名前や名称がほしかったんだろうな
理由はきっとそっちのほうがたしからしく見えるからかな?

でもそれもひらしょーさんの「なにそれ?」で
タスクシステムは世に通じない名称ということを実証するのに十分だったな
な〜む〜w

ひらしょーさんと同じことを説明してくれてる人はたくさんいたけど
名称の魔力があったから信者はまったく聞き入れなかったよね

206 :名前は開発中のものです。:2008/12/07(日) 11:05:38 ID:DJqT4ev1
>>205
信者決め付け脳はウザい。

207 :名前は開発中のものです。:2008/12/07(日) 13:20:37 ID:kyRfBfLD
内なる敵と戦っているんだよ。

208 :名前は開発中のものです。:2008/12/07(日) 14:00:36 ID:So4hgvTQ
http://game.watch.impress.co.jp/docs/20070131/3dlp.htm
システムはどうかしらないけど、ゲーム業界でタスクは一般的になってると思うよ。
俺が書いたコードをソフトメーカーの人に見せたら、汎用タスクだねって言ってた。

209 :名前は開発中のものです。:2008/12/07(日) 14:40:22 ID:DJqT4ev1
>>208
まぁその記事の「タスク」は、MTフレームワークの用語としての「タスク」だと
思うが。

210 :名前は開発中のものです。:2008/12/07(日) 16:34:44 ID:So4hgvTQ
>>209
このスレで言ってるタスクシステムとなにが違うの?

「タスク」はプレーヤー、敵、カメラ(視点)、ライティングなどの同時多発的に発生する
ゲームを進行させる処理そのもののことを指す。
各タスクには、プレーヤータスクの更新処理、描画処理。
敵タスクの更新処理、描画処理といった形で「更新処理」、「描画処理」が存在する。

211 :名前は開発中のものです。:2008/12/07(日) 17:02:09 ID:mATZsXLl
>>210
まあ、似たようなもんだろ

212 :名前は開発中のものです。:2008/12/07(日) 17:12:29 ID:mATZsXLl
ただ、あんまりうまくいってねぇ気がするね
だってそんなもん作ったわりにそれほど見応えのあるソフト連投してねぇし

213 :名前は開発中のものです。:2008/12/07(日) 20:03:21 ID:4pqMat4a
ジョブコンがアンチパターンである理由

1.グローバル変数(または静的クラス変数)を多用しがち
2.抽象的すぎる(シーン、入力処理、衝突判定、描画物などを同じ抽象レベルでリスト化できてしまう)
3.2のためにプライオリティ変数のような順序制御機構が別途必要になる
4.3のために処理の流れがコードから読み取りずらくなる(このスレの「FSMが云々」のくだりはこれを指摘している?)
5.配列の方が速い(CPU最適化厨乙wいやマジでがんばれw)
6.ひらしょー先生が批判している(よく知らんけど・・・)

最近の流れだとこんな感じか?
個人的には4が致命的だと思うな

※2は、言い換えると「様々なコードの断片や描画物を、必要に応じて追加・削除できるオブジェクトとして
 同じ抽象レベルで扱える」というメリット的な言い方も出来るかも知れん

214 :名前は開発中のものです。:2008/12/07(日) 20:56:55 ID:hSkKXTzZ
タスクシステム否定派 = 人の意見に盲従するヘタレ

ということはわかった。

215 :名前は開発中のものです。:2008/12/07(日) 23:20:58 ID:YTdxZCAS
>1.グローバル変数(または静的クラス変数)を多用しがち
変数の参照範囲は必要なだけ広く、そして最小範囲
タスクシステムだからこれが出来ないという理由はない
少なくともリストや配列を使った非タスクシステム比べて
変数の参照範囲を広くとる必要などない

>2.抽象的すぎる(シーン、入力処理、衝突判定、
>描画物などを同じ抽象レベルでリスト化できてしまう)
多態を使ったリスト巡回だと抽象レベルが一つ下がるけど
その為に、例えば後から「エフェクトクラスを追加しよう!」と
思ったときにクラスをさかのぼって親クラスを修正しなければならず
また、その親クラスから分岐した子クラスを編集する必要もある
タスクシステムはクラスでいう型を撤廃して、それをデータに
落とし込んでいるがそのおかげでコード修正の影響範囲を
局所化することに成功している

>3.2のためにプライオリティ変数のような順序制御機構が別途必要になる
ZソートするのだってZ値必要じゃん
順番が必要ならH・・・じゃなかった、値が必要なのは当然
どうしてもプライオリティ変数が嫌ならタスク追加時にソートしとけ
(プライオリティ変数使ってる人って毎フレームソートしてるの?バカなの?)

>4.3のために処理の流れがコードから読み取りずらくなる
>(このスレの「FSMが云々」のくだりはこれを指摘している?)
順序制御機構があるならコードは見やすいだろう
関数ポインタのせいで直感的ではないという指摘ならともかく

216 :名前は開発中のものです。:2008/12/07(日) 23:21:29 ID:YTdxZCAS
>5.配列の方が速い(CPU最適化厨乙wいやマジでがんばれw)
確かにタスク巡回(多目に見積もってもせいぜい数十万タスクだろう)を舐める速度が
数倍余計にかかっても今のCPUなら有意な差ではない
当たり判定やグラフィック描画との処理時間の割合が違いすぎる
確かにその通りだ
ただ、実際にどういった処理が行われるのか想像して欲しい
1. 現在のタスクから次のタスクが存在するポインタを参照する
2. 次のタスクをメモリに読み込む
3. 読み込んだタスクからデータを参照する
さて、データを参照したのは何回だろうか
しかも「次のアドレス」ではなく「指定したアドレス」から読み込むことがどれだけ不利なことか・・・・
リストと配列の速度差に関しては、実際にベンチを取った人には説明するまでもないと思う
たしかに実用上は大した差ではない
しかし、CPU時間は余り気味の現代社会においてもメモリ帯域はPS3ですら不足している昨今
リストを使ったプログラミングは複雑さが増しているばかりではなくソースも見づらくなり
その上速度まで低下していてはどうやって弁解する事ができるのか不可解である

>6.ひらしょー先生が批判している(よく知らんけど・・・)
おまえら本買ってないだろ?
どうみてもタスクシステムです
本当にありがとうございました

最初は状態変数で分岐させてるけど、後半はタスクシステムじゃねーか

217 :名前は開発中のものです。:2008/12/08(月) 00:01:48 ID:62ubqb8M
>順序制御機構があるならコードは見やすいだろう

ソースコードの流れる順番に処理が行われていないから読みずらいっつってんの
なんで見やすいって話になるんだよ
あと関数ポインタ/仮想関数/無名関数をアンチパターンとするのには同意しかねる


>おまえら本買ってないだろ?
>どうみてもタスクシステムです

ひらしょーは正直どうでもいいw

218 :名前は開発中のものです。:2008/12/08(月) 00:11:25 ID:nrC30ZCa
>>215
>変数の参照範囲は必要なだけ広く、そして最小範囲
>タスクシステムだからこれが出来ないという理由はない
>少なくともリストや配列を使った非タスクシステム比べて
>変数の参照範囲を広くとる必要などない
それってソースコード読む人にどうやって伝えるの?

219 :名前は開発中のものです。:2008/12/08(月) 08:47:20 ID:3OfRiy2M
>>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 :名前は開発中のものです。:2008/12/08(月) 08:52:11 ID:3OfRiy2M
ゲームの場合は、プログラムの基本構造が「一定時間ごとに外から関数を呼ばれる
小さなオブジェクトの塊」になる。

このオブジェクトを単一リストに入れることで型システムや変数スコープの利点を捨るか、
あるいは複数のリストに入れることで仕様変更時のソースコードの変更範囲が大きくなる
のを諦めるかというのがトレードオフなんだろうね。

221 :名前は開発中のものです。:2008/12/08(月) 12:05:50 ID:aJ+u6Y4C
なんかいきなりジョブコン叩きをはじめた奴がいるが。

ジョブコンの利点は、コルーチンが実現できることだ、ってのは把握してる?

222 :名前は開発中のものです。:2008/12/08(月) 12:28:19 ID:rbhhFL67
叩いているようには見えないし
そもそもコルーチンじゃないし
信者を装うにも無理がある

223 :名前は開発中のものです。:2008/12/08(月) 12:56:45 ID:+P2RkRte
>>220
仕様変更が起こってもソースの変更範囲を小さくできるなんてメリットだとは思わないな。
それができるということは仕様とソースが乖離していること、乖離していくことを示している。

224 :名前は開発中のものです。:2008/12/08(月) 13:24:53 ID:HU7PRYqb
>>223
確かに仕様変更の中身に強く依存することなので
一般論としてしまうには無理があるな。
設計によって対応しやすい変更としにくい変更があるだろうから
それらを具体的に考えてみるのもいい。

225 :名前は開発中のものです。:2008/12/08(月) 13:40:00 ID:96cnGhTJ
>>223
> 仕様変更が起こってもソースの変更範囲を小さくできるなんてメリットだとは思わないな。
> それができるということは仕様とソースが乖離していること、乖離していくことを示している。

は?
仕様変更が起きた時に、ソースの変更範囲ができる限り小さくて済むように
(1つの仕様変更で変更すべき箇所が1箇所で済むように)実装するのは、
基本中の基本だぞ?

小さな仕様変更でソースのあちこちを変更しなければならないという状態のほうが、
仕様と乖離したソースだということになるはずだが?

226 :223:2008/12/08(月) 14:05:31 ID:+P2RkRte
>>225
ごめんよ。もちろん1つの仕様変更であちこち変更するのを基準に「小さく」って話を
してるわけじゃないんだ。

ある処理が依存する情報について変更があっても、グローバル変数を使っていれば
関数の引数には変更が現れなかったりする、そういう変更の小ささがメリットだとは思わない
って話。

227 :名前は開発中のものです。:2008/12/08(月) 19:17:09 ID:nrC30ZCa
>>226
同意
特にグローバル変数まで使って変更を強引に縮小することにメリットは全く無い

228 :名前は開発中のものです。:2008/12/08(月) 21:47:43 ID:3OfRiy2M
グローバル変数を使っていれば、明示的に引数などで渡す必要がない
struct 使っていれば、わざわざ setter, getter を使う必要がない

……それが通じるのは、アドレス空間 64KB の世界までだよな。

229 :名前は開発中のものです。:2008/12/09(火) 21:57:26 ID:Cm1hssKy
タスクシステム
ストラテジーパターン
FSM

違いがわかりません


230 :名前は開発中のものです。:2008/12/09(火) 23:12:27 ID:kSxszrcc
タスクシステムはC言語より前に生まれたのでは

231 :名前は開発中のものです。:2008/12/09(火) 23:57:46 ID:4ucfkUBf
>>230
キミはC言語の誕生をいつと思ってるのカネ?

232 :名前は開発中のものです。:2008/12/10(水) 00:41:20 ID:zML+BZeA
UNIX用に作られたくらいだった気がするので30年前くらい?

http://www.ijinden.com/_c_12/Ken_Thompson/Pears_UNIX.html
1973年だな。

インベーダーは78年で、PONが72年か。
http://loderun.blog.so-net.ne.jp/2008-04-03-1

ゲーム上でのタスクは後になるのか。タスクの元になるものが更にあるかは知らないw

233 :名前は開発中のものです。:2008/12/10(水) 01:56:38 ID:vj+7d+7Z
230を好意的に解釈すると

タスクシステムは(ゲーム開発に)C言語(が採用される)より前に生まれたのでは

C言語使うようになったのなんて90年代になってからだね。

234 :名前は開発中のものです。:2008/12/11(木) 00:44:32 ID:RMSlUpht
>>208
汎用。これはとても便利な言葉だ
これは何にでも使えるね、というポジティブな意味に使えるし
これは何にもできないね、というネガティブな意味にも使える
どちらに重みが置かれるかはケースバイケースだが
仮に後者の重み係数が大きくても角が立たないという魅力的な言葉だ

面接に来てくれた若者のソースコードを眺めて
「これは何にもできない処理単位だね」とぶっきらぼうに言い放つ人間もいれば
「これは汎用的なタスクだね」とやんわりと当たり障りの無い表現で煙に巻く人間もいる
前者はある意味で分かりやすい圧迫釜賭けだが、後者には注意を払う必要がある

コミュニケーション能力の一端を見るためにわざと当たり障りの無い意味不明瞭な表現を使い
その背後に隠された意図を相手がどう読み取ってくるのかをじっと観察する人間もいるからだ



235 :名前は開発中のものです。:2008/12/11(木) 01:28:26 ID:U09K2ObF
いちいち駆け引きしなきゃ話もできんようなやつとは
仕事したくないなあ

236 :名前は開発中のものです。:2008/12/11(木) 10:19:51 ID:tNsh0a9k
90年代?自分の記憶がソースかよ

237 :名前は開発中のものです。:2008/12/11(木) 22:05:22 ID:IWquCMNP
>システムはどうかしらないけど、ゲーム業界でタスクは一般的になってると思うよ。

ジョブとタスクを明確に使い分けてた職場とジョブとタスクを混同してた職場があったようだけどねー
ソースだけ(部分的に)パクれても設計のノウハウ(なぜこれはこういう設計になってるのか等)まで
パクれなかった下っ端が中堅・下請けに再就職しても断片的で不完全な情報しか伝達されない
情報は確実に劣化する

長期大規模開発用に構築されたフレームワークは巨大だからリードプログラマをつかまえてこないと
その全容を正しく理解するのは難しいね
たとえタスク制御とジョブ制御が分離されてるコードを見たとしても、それがどうして分離されてたのか
分からなかったかもしれない。だからコンテキストスイッチ不要とかという話になり、ユーザーに直接タスクを
記述させて泥沼に陥ったりする。>>2はその典型じゃね?


という談話を聞いてきたHSPerでした

238 :名前は開発中のものです。:2008/12/11(木) 22:17:27 ID:IWquCMNP
>>237訂正
>ユーザーに直接タスクを記述させて

ユーザーに直接、タスク(システム内部の処理単位)として振舞うようなジョブを記述させてる、だったかな

ジョブエントリの連結リストを走査して順次処理するだけの単純な仕掛けだから
スケジューリングがなってないしデッドラインに処理が完了するようマネージメントすることもできない
全てマニュアル操作。ユーザーに責任を押し付けてる。劣化ジョブコンとも

239 :名前は開発中のものです。:2008/12/12(金) 01:51:42 ID:EK0D+T+v
半年程うだうだやってようやくタスクシステム卒業できた気がする俺からのヒント。
これでこのスレからも卒業だ!

1. ハードに近い下のレイヤはイベントハンドラ使うけど、
 上のレイヤではイベントハンドラは(自分からは)使わない。

 上のレイヤではvoid enter_frame(void)、void display(void)のようなタイミング通知の意味しかない関数
 (C++ならメソッド)を用意しておいて、イベントハンドラからはそれを呼ぶだけに留める。
 データの受け渡しはあくまでも上主導で。
 下主導で上へとアクションかけるのは処理実行タイミング通知(関数呼び出し)だけ。
 入力データは下のレイヤでバッファリングしておいて上のレイヤが下に参照しに行く。相互参照を避けるため。
 タイミング通知の関数のタスクシステムとの違いは、それらの関数がプログラム中にただ一つずつしか存在しないこと。
 関数呼び出しされた側では、その関数内で1フレーム分の処理を手続き型言語丸出しで書いてOK。
 例えばif文、switch文も関数呼び出しも他のインスタンスのメソッド呼び出しも自由自在だし、がんがん引数渡し可能。
 ゲームオブジェクト種別ごとに別の配列用意したりとかも普通にできるようになる。
 ウィンドウプログラムに入る前のC入門書のノリで普通にプログラム書ける。
(続く)

240 :名前は開発中のものです。:2008/12/12(金) 01:52:20 ID:EK0D+T+v
(続き)
2.ゲームプロジェクトとは別にライブラリプロジェクト作る。Visual C++ 2008 Express Editionでもライブラリ用のプロジェクト簡単に作れる。
 1つのプロジェクトで既にきれいに分けれていると思っててもプロジェクト分けると切れてなかったことに気づく。結構重要。
 ライブラリ化はよくある普通の部品化レベルでよい。
 フレームワーク作りはまだ止めとけ。部品化だけで十分役立つ。というかタスクシステム卒業したら部品化できる範囲が急激に広がるのでそれだけで十分手一杯になれる。


ハード触る処理とゲーム処理をごちゃまぜに一つの方式で扱おうとしてるといつまでもタスクシステムから逃れられないと思う。
ハードは割り込みあるから本質的にイベント駆動だけど、
ゲーム処理までそれに合わせる必要はない。手続き型言語丸出しでバッチ処理的にべた書き(1フレーム刻みだけど)できるし、そうすべき。
楽。チョー楽。
プログラム入門したての頃の楽しい感覚が蘇ってくるよ、べた書き。すいすい進むし、出来ることの幅がすごく広がる。

#プログラム構造の文献はCで完結するような原始的な領域の本が分かりやすくていいよ。組み込みとかの。SESSAME WGのとか。


241 :名前は開発中のものです。:2008/12/12(金) 02:04:21 ID:NGRnTHCb
おまえらやっぱり1度Java経験しといたほうがいいと思った

242 :名前は開発中のものです。:2008/12/12(金) 05:20:00 ID:J9pDnhIw
>>239-240
タスクシステム大好きっ子を締め上げたりしてる俺だが流石にお前は可哀相に思う

>>2なんざポーリング処理(全オブジェクトのちゃんこ鍋連結リストを巡回してディスパッチ)
するだけのヘッポコプログラムだから。イベント駆動云々なんてVSYNCトリガーにしてる以外は
関係ないから関係ないから。お前が言ってる事は

main(){
  //ここで準備してね
  while(1){
    enter_frame();
    display();    
    d3ddev->Present(VSYNC待ってから処理返してね);
  }
  //ここで後片付けしてね
}
enter_frame(){
  //1フレーム分の処理を手続き型言語丸出しで書いてOK。
  //例えばif文、switch文も関数呼び出しも他のインスタンスのメソッド呼び出しも自由自在だし、がんがん引数渡し可能。
  //ゲームオブジェクト種別ごとに別の配列用意したりとかも普通にできるようになる。
  //ウィンドウプログラムに入る前のC入門書のノリで普通にプログラム書ける。
  //ゲーム処理までそれに合わせる必要はない。手続き型言語丸出しでバッチ処理的にべた書き(1フレーム刻みだけど)できるし、そうすべき。
  //楽。チョー楽。
  //プログラム入門したての頃の楽しい感覚が蘇ってくるよ、べた書き。すいすい進むし、出来ることの幅がすごく広がる。
}
display(){
  //上に同じ
}

これこそサイコー!って言ってるだけ。>>2のmain関数だって同じように書けるし。アホかお前。氏ね
抑制したつもりだったけどやっぱり無理でした

243 :名前は開発中のものです。:2008/12/12(金) 07:57:45 ID:uOw1miUt
タスクシステムって単なるオブジェクト指向プログラミングなんじゃねーの?
時代に乗り遅れた奴らが悶絶してるスレにしか見えないw

244 :名前は開発中のものです。:2008/12/12(金) 08:56:23 ID:6q9RSuqq
>>243
オブジェクト指向のキモは、クラスの洗い出しと、クラス間の関連を見極めること。
何でもかんでもグローバル変数に書いて共有するのはダメだろ。

245 :名前は開発中のものです。:2008/12/12(金) 13:54:57 ID:6fpFqUQy
タスクシステムとグローバル変数には何の関連性もないし
タスクシステムがオブジェクト指向であるというのもそのとおり。

たんなる技術手法の1つでこれといった決まったルールが決まってない名称であるから
揚げ足取りがしやすいだけ。

デザパタより昔からあった手法だし、C++よりは古い。

246 :名前は開発中のものです。:2008/12/12(金) 22:29:53 ID:vHZmpFnT
クラスもなければプロトタイプでもない、CLOS のような多態のメカニズムもない。
どこがどうオブジェクト指向なんですかね。

247 :名前は開発中のものです。:2008/12/12(金) 22:35:04 ID:EK0D+T+v
>>243
1口にオブジェクト指向といってもメッセージングとオブジェクト主体の動的なものと、
構造体主体の静的なものとかがある。前者はスクリプト言語とか。C/C++は主に後者。

参考: http://d.hatena.ne.jp/sumim/20040525/p1

248 :名前は開発中のものです。:2008/12/13(土) 00:25:41 ID:m0qW0f8x
このスレの異常に不憫な嫌タスク厨を見てて
いつも思うことがあるんだが・・・




「神は自らタスクるものをタスク」

249 :名前は開発中のものです。:2008/12/13(土) 00:26:53 ID:de3lQl9T
>>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フレーム待ってるやり方。

250 :名前は開発中のものです。:2008/12/13(土) 01:06:41 ID:1u8g2R1V
>>249
それってホーミングミサイルがターゲッティングした相手とか
キャラと移動床、移動床と固定壁の相互判定の処理とかって
どこ飛んでいっちゃってんの?

なんかワンフレのオブジェクトの独立した動作しか見えてなくね?

上記のことをそのシステム使って解決しようとすると
もう関数の引数でやりとりできないからグローバル変数使って回避するしかないっしょ?

251 :名前は開発中のものです。:2008/12/13(土) 01:16:46 ID:gfZ50szk
>WM_LBUTTONDOWNとかWM_MOVINGとかWM_DESTROYみたいなイベントも扱う。
>それら入出力関係・アプリ生存期間の制御関係のものと、ゲーム処理をいっしょくたに
>扱える標準的インタフェースなんて作るなというのが主旨

HSPerも基本的にそう思うよー
http://pc11.2ch.net/test/read.cgi/gamedev/1227748699/181n

でも、これって>>2>>2卒業とは関係無い話だと思うよ
GUIに特化したOSのイベントシステムというものは
OS提供のGUI関連機能を積極的に使わない限りは
「どんなアプリにとっても」どうでもいい存在なんだし

そういう場合、どんなアプリでも
最低限のイベントに対応する処理を脇のほうで適当にこなしてるだけ



252 :名前は開発中のものです。:2008/12/13(土) 01:38:03 ID:1u8g2R1V
>>250はレス先間違えたw

253 :名前は開発中のものです。:2008/12/13(土) 02:16:57 ID:gfZ50szk
>タスクシステム=イベントハンドラ崩れorイベントハンドラの俺ゲーム最適化後というイメージを持ってる。

>>2にはイベントという概念はないしイベントディスパッチャもないよ
イベント駆動システムの体を成してないよ
>>2はジョブの連結リストを走査して全ての要素(ジョブ)をディスパッチしてる
つまり単純な順次処理しかしてくれないよ
イベントがあるとすれば、それはユーザー自身がジョブの中で記述しなければならないよ
>>2は何にもしてくれないよ

254 :名前は開発中のものです。:2008/12/13(土) 09:18:22 ID:HlSyOfLl
イベントというかメッセージだったかな
HSPerは頭よくないから使い分けがよくわかんないの

ケータイだからID違うのはしかたないね

255 :名前は開発中のものです。:2008/12/13(土) 15:00:33 ID:qrT1CCoR
>>242
不憫なやつだな、お前
なんかわかった気になっちゃってんだろうけど

21世紀の高スペックハードが前提ならModernC++Designあたりの設計の方が当然良いっつの
まーおまえは配列が最高だと思ってるかも知れないから、これも分からないかも知れないが・・・w
ジョブコンはハードべったりなコーディングのための実装(設計ではない)であって、
組み込みに近いハードで便利なんだよ
これを組み上げた故・深谷正一氏はナムコで神様って呼ばれてただろ

嫌タスク厨は、世の中に唯一の正しい答えがあるわけじゃないことを学んだ方がいいよ
様々な現場があり、また過去にあったことを理解しろ
多分20年後には、C++自体が百害あって一利なしと言われているだろうが、
その時でも俺はC++を擁護するね
仕事ではC#かECMAScriptあたりを使っていたとしてもね
だから俺は今、タスクを擁護する
かつて世界をリードした日本のゲーム最盛期の技術として、価値あるものだ

あ、でもタスクしか使えない老害はそろそろ消えてくださいw
もうバブルは終わったんだよ。過去にしがみつくなwww

256 :名前は開発中のものです。:2008/12/13(土) 15:49:54 ID:nTnjQTuE
モナドを使ったステートレスなタスクを考えてください

257 :名前は開発中のものです。:2008/12/13(土) 16:20:05 ID:Q1lPMEoI
CPSでおk

258 :名前は開発中のものです。:2008/12/13(土) 21:30:40 ID:rCULSb4p
久しぶりにのぞいたら例の本でふきあがってるのな
まだ続いてる?
いわゆるタスクシステム的な抽象度の高いオブジェクトがシステム最上層で一本だけのリストに
なってる系の設計の問題だと思う点はタスクの描画順序を変えようとしてプライオリティを変えると
その抽象度の高いクラスを継承するクラス全部リコンパイルするハメになるとこ
そして最近は複数バッファを使う技術を実装する途上で描画順序を変えなくてはならなくなることが多い
同一のリソースに複数回描画を要請することもある

259 :名前は開発中のものです。:2008/12/13(土) 23:19:03 ID:ngcrwCO9
本当のタスクシステムはリストではなくリングバッファ
リスト使うやつはまがい物

260 :名前は開発中のものです。:2008/12/14(日) 02:07:26 ID:JyTBiW8D
>>255
で、なんで急に「ジョブコン」の話を始めてるのかな?
俺は>>2の話をしたがお前はそれを「ジョブコン」の話だと思ってるのかな?
もしかしてお前、>>2=「ジョブコン」だとでもいいたいのかな?まさかね

故人の名を引っ張り出して嘘を吐くなんてバチ当たりなこと、するわけないよね?

人として

261 :名前は開発中のものです。:2008/12/14(日) 04:35:12 ID:BTfnwu0u
723 名前: 遠藤雅伸 ★ 投稿日: 02/01/04 11:43 ID:???
>>720-722
 >>712の言っている「タスク」というのは、80年代初頭に深谷正一
氏が完成させた、通称「ジョブコントローラー」とか「オブジェクトコン
トローラー」とか言われているものだと思います。
 CRTのブランキングに同期して行われるインタラプト処理をトリガー
にして、60分の1秒単位で順次処理をマルチに行う構造ですね。

 今では誰もが使っているというか、既に時代遅れなのですが、当
時はプログラマに読者層がある雑誌などで、プログラムを解析して
紹介したりしてました。

262 :名前は開発中のものです。:2008/12/14(日) 06:36:31 ID:lnd0cLcc
描画順序を内包するから問題になるのであってそれは外にだせばいいだけだな
それでも複雑・特殊化した描画のシーケンスに対する柔軟性のなさは相変わらずだけど

263 :名前は開発中のものです。:2008/12/14(日) 08:13:40 ID:zCveThyG
業務用アプリでさえタスクシステムなのにお前らいつまでこんなネタを繰り広げてるんだよ

264 :名前は開発中のものです。:2008/12/14(日) 10:46:26 ID:hPd7IYfR
×タスクシステム
○イベント駆動

265 :名前は開発中のものです。:2008/12/14(日) 13:38:40 ID:zax2tb8N
タスクシステム = リアルタイム・ゲームにおける並列動作処理の基本アイデア

基本アイデアを否定するって、初心者掲示板においてどんだけ罰あたりなんだよ。

266 :名前は開発中のものです。:2008/12/14(日) 13:55:05 ID:J0IK5eg8
>>265
ゲームの基本アイデアは、

1. 定期的
2. 外部から駆動される

オブジェクトの集合でシステムを構成すること、だろう。固定長ブロックをポインタで
つないだ所謂タスクシステムは、その(特殊なケースに最適化された)例の一つ。


267 :名前は開発中のものです。:2008/12/14(日) 14:13:11 ID:zax2tb8N
「定期的」オブジェクト:
 フレームワーク(タスクの生成/消滅/アクティブ化/非アクティブ化)

「外部から駆動される」オブジェクト:
 上記のフレームワークに乗っかった個々のタスク

・・・ということ?

結局、>>266の実体はタスクシステムなんでは?

268 :名前は開発中のものです。:2008/12/14(日) 20:09:25 ID:kt8hWnnq
デザパタより昔からあった手法だし、C++よりは古い。

269 :名前は開発中のものです。:2008/12/14(日) 23:37:27 ID:hPd7IYfR
イベント駆動とメッセージングOOPの組合せ程度じゃ
単なるよくあるGUIプログラミングの定石じゃない

270 :名前は開発中のものです。:2008/12/15(月) 07:22:29 ID:OmEWjIQA
>>267
for (;;) {
 player.exec(*this);
 std::for_each(enemies.begin(), enemies.end(), boost::bind(&Enemy::exec, ::_1, boost::ref(*this)));
 WaitVSync();
}

これだって VSync ごとに 1 回ずつ、各オブジェクトを呼び出してるわけで、
別に固定長ブロックをポインタでつないだ「タスクシステム」とやらに限った
話じゃない。


271 :名前は開発中のものです。:2008/12/15(月) 22:10:39 ID:Y+es7eZl
ポエマーだけど、人違いされたままなのは気に入らないので横合いからちょっかい出してみるのねー

>>255
ジョブ(プログラムとデータを関連付けたもの。要するにオブジェクト)の連結リストを巡回して実行するだけで
これこそが神の技だとかソロモンの指輪(どう見てもガチャガチャで入手した飴菓子のジュエルリングだが)だとかいって
ホルホルしてるウンコカルト教の信者のつまらないプライドをベキベキにへし折るためのちょっとしたアンチテーゼとして
「STGで弾とかパーティクルを大量に出すなら>>2より配列で素直に書いたほうがちょっぱやだけど何でそうしないの?」
みたいなこと書いたことあるけど、カルト教団からの脱会を決意をした子(>>239-240,>>249)に向かって阿呆とか死ねとか
言ったりはしないよ。目出度いことなんだからお赤飯を炊いてあげたいくらいだねー

ところで>>2には深谷氏の流派に見られた特徴的な記述が微塵も感じられないけど、君はどうして混ぜこぜに語るの?
異質な点をあげればキリないけど、端的な例をあげれば>>2にはコンテキストの保存や切り替え機構がないよね。
>>2書いた人はどいつもこいつもその必要性を微塵も感じてないんじゃないかな。ゆえに深谷氏の師事を受けた
人間ではないよ。まぁ優劣の話ではないのね。明らかに異質。完全に別物ってことなのね

>>257
それ、知らない人が読んでも意味がよく分からないと思うのねー
引用先で遠藤サンがおっしゃってる「順次処理」というのは、ジョブの処理内容のことだと思うのねー
別の言い方をすればジョブの内容はシーケンス制御ですよ、というお話だと思うのねー

これをマルチで行なう、というのは順次処理を行なうジョブ(複数個)、固定時間刻みで逐次処理することだと思うのねー
この逐次処理の処理単位は世間一般にはジョブステップとかタスクとか読ばれるのかもしれないのねー
luaのコルーチンと同じようにユーザーが挟み込んだ補助情報(yield文相当)で半自動的にジョブは分割されて
実行されるのねー。アセンブラでジョブを記述するにはとても使いやすかったのねー

272 :名前は開発中のものです。:2008/12/15(月) 22:12:34 ID:Y+es7eZl
×師事を受けた
○教えを授かった

273 :名前は開発中のものです。:2008/12/15(月) 22:14:32 ID:Y+es7eZl
△ジョブ(複数個)、固定時間刻みで
○ジョブ(複数個)を固定時間刻みで

274 :名前は開発中のものです。:2008/12/15(月) 22:22:24 ID:Y+es7eZl
一方で、>>238とか>>253の順次処理というのは連結リストに繋がれた順番の話だと思うのねー
繋がれた順番に実行するということ。つまり順次処理。バッチ処理だね

>>2はジョブをバッチ処理する機能しか積んでないというのは本当だね。それを>>2では無理やり逐次処理に使う。
逐次処理するための足りない部分は誰が面倒みるの?ユーザーが面倒見るんだよ。全部ね


275 :名前は開発中のものです。:2008/12/15(月) 23:09:23 ID:Y+es7eZl
×>>257
>>261

酔っ払ってるとダメなのねー

これで>>261の引用元の遠藤サンが何で「タスク」という組み方を聞かれて「ジョブコン」のことだと推測したのか
が見えてくると思うのねー

可能性@ : 「タスク」という組み方が>>2程度のものだとは露ほども考えてなかった。想定外にお粗末な>>2
可能性A : メインフレームの基礎知識がある人間は「タスク」と言われたら「ジョブステップ」かなと思う
         言うまでもなく深谷氏を師事するものにとってジョブステップといえばアレである

ま、いずれにせよ。あの流派の人間に「ジョブコンとは>>2」なんて言い放ったら青筋立てて苦笑いすると思うのねー

276 :名前は開発中のものです。:2008/12/15(月) 23:57:34 ID:OmEWjIQA
>>271
> luaのコルーチンと同じようにユーザーが挟み込んだ補助情報(yield文相当)で半自動的にジョブは分割されて
> 実行されるのねー。アセンブラでジョブを記述するにはとても使いやすかったのねー
今でもコルーチンは便利だけど、その部分は C++ で書かずにスクリプト言語+スタックレスの VM 使うよな。
昔はスクリプト言語なんて贅沢は言ってられなかったわけだが。

277 :名前は開発中のものです。:2008/12/16(火) 07:45:28 ID:Xcw/e/us
スクリプトも無節操に使うとグローバル変数、関数とかわんない

278 :名前は開発中のものです。:2008/12/16(火) 10:06:25 ID:4E6YhtY0
タスクシステム>働いたら負けかなと思ってる

279 :名前は開発中のものです。:2008/12/16(火) 11:17:10 ID:j7LoR4yM
というか、ジョブコン(コルーチン)話はこのスレのスコープに入るわけ?

280 :名前は開発中のものです。:2008/12/16(火) 20:51:33 ID:JXrz6RNp
>>270
それってタスクシステムのアイデアを、そのままライブラリで厚化粧しただけじゃん

281 :名前は開発中のものです。:2008/12/16(火) 22:19:38 ID:Trm7DCXt
> ジョブコン(コルーチン)
は?

282 :名前は開発中のものです。:2008/12/16(火) 23:25:50 ID:DQ0ASKX3
>>277
一般的には、スクリプトは C++ の単一のインスタンスに張り付ける。

たとえば Enemy クラスのメンバ変数としてスクリプトを張り付けて、
スクリプトからは Enemy クラスのメンバ関数の一部だけ呼べるように
する。

何でもかんでもスクリプトから呼べると、そりゃ破綻するわな。

283 :名前は開発中のものです。:2008/12/17(水) 01:53:45 ID:oN66mV3A
スクリプトのほうが利点があるなら最初から全部スクリプトで作ればいいじゃない?

284 :名前は開発中のものです。:2008/12/17(水) 02:06:46 ID:FLaStTdI
>>283
適材適所。大半を全部スクリプトで作ったほうが良いのは、アドベンチャー
ゲームぐらいじゃないかなぁ。



285 :名前は開発中のものです。:2008/12/17(水) 02:40:55 ID:ahEDXJzw
>>281
ジョブコン=コルーチンって理解じゃ違うのか?

俺は>>279じゃないが
こういう結論になりそうな資料見たことある
内部の人間じゃないから分からんが・・・
なんか謎に包まれてんなあw

286 :名前は開発中のものです。:2008/12/17(水) 10:18:44 ID:52EN4/sP
ジョブコンってコンテキストスイッチないじゃん
ただのステートマシン

287 :名前は開発中のものです。:2008/12/17(水) 11:41:46 ID:bRfj9ttj
>>286
http://game.2ch.net/gamedev/kako/1006/10061/1006184421.html の 810 を
100 回読んでこい。

288 :名前は開発中のものです。:2008/12/18(木) 18:05:58 ID:iEg8pKUf
あった
http://jp.youtube.com/watch?v=3JWl1IikUBE&feature=related

289 :名前は開発中のものです。:2008/12/20(土) 00:01:42 ID:oW76AwO4
>>287 読んだ。
>スタックにプッシュしてあるリターンアドレスも含めた
>CPUコンテクストを復帰させて 各ジョブを呼び出す。
>ただし、リターンアドレスをポップする 形で呼び出すので、
> RTS で呼び出す訳ですが。

うは、なつかしいな。確かZ80で、RTS使うかわりに戻りアドレスをスタックに積んで
pop すると RTSよりマシンサイクルが少し速い、てな話だったような。

>>275
こういうの見ると、メインフレーム屋さんではなくて制御屋さんの発想な気がするけど。
マイコンのアセンブラだと、コンテキスト、というよりCPUのレジスタを保存する
とか普通の世界だったから、それを現代風にアレンジした「タスクシステム」で
考慮してないとしても卑下する必要はないと思うんだけどなあ。

かじっただけの俺がいうのもなんだが、あちこちのサイトで紹介されているタスク
システムの問題点は中途半端に汎用的で抽象化されているところじゃないかな。
ひとつのシステムで多用途に適用できるというのはPGの夢かもしれないけど、
ルーティンを嫌うアミューズメント用途にはちょっと無理があるような気がする。


290 :名前は開発中のものです。:2008/12/20(土) 15:39:24 ID:4NXZi7BF
やね本でこの手の技法を知った。
2年程実際に使ってて、今のところ大きな問題が出てないからまだ使ってる。
とはいえいろいろ小さな問題点や、
ハードのスペック故に浮き上がってきた問題も出てきた。
ただ、今は新しいやり方を覚えてソースを書き換える暇がないので、
じわじわと学びながら弄りながら変えていってるのが現状。
まあ不毛な喧嘩はともかく、
タスクシステムの問題点についてビシバシ突っ込んでくれるのは非常にありがたいので、
これからも話がズレない程度に熱く語ってくれ。

291 :名前は開発中のものです。:2008/12/20(土) 16:29:07 ID:dWaY9Ulk
貴様に命令されるいわれはない

292 :名前は開発中のものです。:2008/12/20(土) 23:01:46 ID:oW76AwO4
>>289
ありゃ、間違ってるな。てか、興味ない人はスルー願います。
>ただし、リターンアドレスをポップする
>形で呼び出すので、 RTS で呼び出す訳ですが。

z80でサブルーチンを CALL nn すると、現在の pc の次のアドレスを
スタックにプッシュして nn に飛ぶ。その先で rts すると、スタック
からアドレスを pc に読み込んで呼び出し元のアドレスの次の命令から
続くのが通常。上のはサブルーチン(タスク)を呼び出すのにその
逆をやってる。なんかの雑誌でみたことがあるな。
 メリットは覚えてないやw
 push でレジスタを退避させるのと一緒に使えて、速くて短い、とかかな。


293 :名前は開発中のものです。:2008/12/21(日) 01:37:52 ID:lXu3AnzO
>>292>>287を読んだだけで内容を理解できてないと思うから
ぐだぐだ書く前にちゃんと理解する努力をしろ。

294 :名前は開発中のものです。:2008/12/21(日) 20:27:14 ID:9M4acoh9
>>293
まあ、そう突っかかんなよw
ではよく理解している293に教えて欲しいんだけど、

(1)「タスクシステム」いうだけで、なぜ271は
>ウンコカルト教の信者のつまらないプライドをベキベキにへし折るための
>ちょっとしたアンチテーゼ
みたいに口汚く否定しなければならないのか?

(2)「タスクシステム」がだめならジョブコンでどうかというと
>あの流派の人間に「ジョブコンとは>>2」なんて言い放ったら青筋立てて苦笑いする
みたいに必死に否定するのはなぜか?

(3) 青筋を立てているのは271ではないのか?

以上3点、ご教授いただければ幸いですw

なんつか、271はそれなりに知見のある人間にも見えるんだけどなぜ?って感じ。


295 :名前は開発中のものです。:2008/12/21(日) 20:30:02 ID:cG9gZch1
定義ごっこウゼーからヤメロよ
名前なんて関係ねーよ

ポインタ保持
グローバル変数関数使いまくり

のソースは問答無用で糞コードなんだよ

296 :名前は開発中のものです。:2008/12/21(日) 20:38:47 ID:9M4acoh9
>>290にはたぶん向いているんだろう。俺にはちょっと使いづらいかなと思った。
あんまり頭よくないんで、全体を把握しにくいコードでポインタを使いまわす
のはおっかないと思ったよ。

いずれにせよ、コストと手間を考えて手段を選ぶだけなんだから、手法のメリット
デメリットを論じるならともかく、使うだけで罵ったり赤飯炊いたりしてくれるのは
まあ、本筋と違うと思うんだけどなあ。


297 :名前は開発中のものです。:2008/12/21(日) 21:37:18 ID:9M4acoh9
>>295
new 厳禁, malloc問題外かあ、そりゃ難儀だな。
295 はよほどでかいスタック使ってるんだろうなあ。すばらしい。



298 :名前は開発中のものです。:2008/12/21(日) 23:03:28 ID:cG9gZch1
>>297
ああ、やっぱり馬鹿なんだw
馬鹿だから横文字連発して誰でもできる名称の定義にこだわってんのバレバレ
あー恥ずかしいw

299 :名前は開発中のものです。:2008/12/22(月) 10:25:16 ID:1VWYpijd
>>294
>>271 は撲殺天使気取りのカルシウム足りてない人だから。以上

というかタスクシステムってちゃんと使えばTCBにキャラクタ固有のデータを
おくはずで、グローバル変数は回避するのが正しい使い方だと思うのだけどな。

300 :名前は開発中のものです。:2008/12/22(月) 18:52:48 ID:f8SxWgbT
ID:oW76AwO4
ID:9M4acoh9
ID:1VWYpijd
>みたいに口汚く否定しなければならないのか?

↑(゚∀。)↓

>>271 は撲殺天使気取りのカルシウム足りてない人だから




ルサンチマン号…

301 :名前は開発中のものです。:2008/12/22(月) 23:23:50 ID:sVVTu1LL
>>299
自キャラクタのデータを TCB に置くのは当然として、タスク間の相互作用を
どう記述するかが問題。ヒット判定とかホーミング弾とか。

ここで、他タスクのポインタを持つと寿命管理でミスして dangling pointer 問題が
発生しがちだし、マネージャクラスみたいなものを作ろうとすると、グローバル変数
多用することになる気がするんだが、どう解決してるんだろ?

302 :293:2008/12/22(月) 23:56:55 ID:/r5SxkM/
>>294
俺は271じゃないから271の考えてることはわからんよ。

でも>>2は、
>>287のリンク先のジョブコンでの重要な要素(PCとSPが保存される)が消えてる
・CodeZineの記事はメモリ管理がキモすぎる
・TCBとスタックポインタというRTOSで使われる用語を全く別の一般的じゃない意味で使ってる
ので、ああいうのが代表的な解説になってるんじゃヤバいと思うよ。

俺はゲーム自体の出来がよければシステムなんてなんでもいいんだけどさ。

303 :名前は開発中のものです。:2008/12/22(月) 23:59:47 ID:2ecmM+o8
>>289
やぁどうも

>マイコンのアセンブラだと、コンテキスト、というよりCPUのレジスタを保存する
>とか普通の世界だったから

マイコンでcontinuationすることが普通だったのか
80年代初頭においてそうした普通があったというのは寡聞にして知らんので
是非ともご教示いただきたいです。よろしくです

>それを現代風にアレンジした「タスクシステム」で考慮してないとしても

「アレ」を現代風にアレンジすると>>2になるのか。見聞の狭い俺にとっては初耳だ。
現代風にアレンジするとcontinuationは必要なくなるという話も新鮮な響きだ。
「アレ」に必要な処理量と得られる利得(ユーザビリティ、etc)を鑑みたうえで
continuationを積極的に「省く」メリットを探してみたのだが不肖の俺には
荷が勝ちすぎるようだ。この辺りについても是非ご教示いただきたい
重ね重ねよろしく頼むよ

304 :名前は開発中のものです。:2008/12/23(火) 12:44:20 ID:0dKfKv7t
えーと。

確かに継続で間違いないんだが、マルチタスクなOSの(リアルタイム、
非リアルタイムを問わず)コンテキストの保存と復帰、まとめてディスパッチと
いう概念は、計算機の歴史としては割込みと同じくらい古い。確か
マルチプログラミングと呼んでいてOSより古いはず。
(というか、割込みの前と後で戻る所を次々すげ替えていけば、マルチタスクに
なる、よね)
現代的には、OSのスレッドサポートと、言語側の継続とかコルーチンとか、
という風に分かれちゃってるけど、マイコン時代にはアプリからモニタまで
全部ユーザが面倒を見るのが当然だったから、ジョブコンも別に大げさな
仕掛けにはならなかった、のだと思うわけだな。

> continuationを積極的に「省く」メリットを探してみたのだが不肖の俺には
> 荷が勝ちすぎるようだ。

確かにこっちは無理だw

305 :名前は開発中のものです。:2008/12/23(火) 12:52:38 ID:KMGtlw/w
文章長すぎる奴自重しろ
中身もねぇのにだらだら無駄に長い
ホントにプログラマーか?お前

306 :名前は開発中のものです。:2008/12/23(火) 12:53:09 ID:0dKfKv7t
>>302
> ・TCBとスタックポインタというRTOSで使われる用語を全く別の一般的じゃない意味で使ってる
> ので、ああいうのが代表的な解説になってるんじゃヤバいと思うよ。

TCBは痛いが、スタックポインタについては、メモリブロックのLIFOな管理技法に
使う用語として一般的なものだと思うが?
むしろアーキテクチャ用語のスタックしか思い浮かばないほうが視野が狭い。

307 :名前は開発中のものです。:2008/12/23(火) 12:54:05 ID:0dKfKv7t
>>305
継続を一言で説明できるのかお前は?

308 :名前は開発中のものです。:2008/12/23(火) 15:09:59 ID:SQBujvLn
KEIZOKU?

309 :名前は開発中のものです。:2008/12/23(火) 15:41:23 ID:EIXJgmbC
継続 = continuation

310 :名前は開発中のものです。:2008/12/23(火) 22:57:43 ID:oH6JwYTC
>>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もこいつが最初かもだそうだ。おもしろいね

311 :名前は開発中のものです。:2008/12/23(火) 23:35:30 ID:EIXJgmbC
ふむ。撲殺天使の人か別の人かわからんが、興味深い情報をありがたう。
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にも割込みの話が
出ている。

312 :名前は開発中のものです。:2008/12/23(火) 23:44:27 ID:KMGtlw/w
まだなげぇ、すげーなげぇ
少しは相手の反応をみるとか
ちょっとした気遣いは全くないのか?

誰も聞いてないことをベラベラベラベラよくしゃべるなぁ

313 :名前は開発中のものです。:2008/12/23(火) 23:50:13 ID:8VQIcbtp
スレチだが。面白かったよ俺には。
長いとか、よくしゃべるとか、批判の対象が違うだろ。
自分の興味のないこと=誰も聞いてない としか受け取れないのか?
ただスレ違いなだけ

314 :名前は開発中のものです。:2008/12/24(水) 00:03:00 ID:RyEm5AoF
>>313
おお、じゃあ、適当なレス返してやれよw

315 :名前は開発中のものです。:2008/12/24(水) 01:12:03 ID:jdZgu35M
>>289
悪い、出張してた。
うーん、おれが本来のジョブコンを理解できてないから変なこといってるのかもしれないけど、、
z80にしても6809にしても当時のマイコンのアセンブラ本とかみて、
マイコンでマルチタスクを実装する方法とかざらに載ってたと思うんだけど。
continuationという用語で説明されたかは覚えてない。
比較的あたらしいのはこんなのか?
http://www.ertl.jp/ITRON/Newsletter-J/itronnews19.html
これが雑誌に載ってたのを見た記憶がある。中身がぜんぜん違うならごめん。

316 :名前は開発中のものです。:2008/12/24(水) 01:20:11 ID:jdZgu35M
で、俺が見たのはz80のアセンブラ本で、マルチタスクを実装するのに
win3.1みたいに自分でジョブを明け渡す方法と、割り込みを利用して
スイッチする方法がのってた。どっちにしてもなんらかの形で
レジスタの保存と復帰はあたりまえだよね?
んー、多分おれが的外れなことを言ってるんだろう。もう黙るわ。

317 :名前は開発中のものです。:2008/12/24(水) 02:57:11 ID:jdZgu35M
黙るといっておきながらあれだが、
>>315は1992ってなってるな。80年初頭とは違いすぎるね。
だけど、マイコンでみんなやったことってメインフレームの真似事だったんだけどなあ。遠藤さんのスレの例の肝は、リロケータブルなプログラムの組みにくいz80で、RTSを
利用して実現したことだと感心したんだがな。まあいいや。


318 :名前は開発中のものです。:2008/12/24(水) 11:05:25 ID:pWFbRnFD
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
また、長文垂れ流しか
ホント無駄な奴等だな

320 :名前は開発中のものです。:2008/12/24(水) 23:02:53 ID:jdZgu35M
>>318 おお、ありがと。1980年の
>12月号 特集◆リアルタイム制御用マルチ・タスク・モニタの研究

なんかもまんまだな。「非同期〜割り込みハンドラは」とか留保つけてるくらいだから
認めてもらえそうにもないが。いつのまにか
>continuationを積極的に「省く」
ことにされてるし。
このスレで continuation といえばマイクロスレッドとかファイバとかの話になるよね。
で、このスレでもおなじみのやねうらお氏がこんなのも用意してたりするわけだよ。
ttp://ml.tietew.jp/cppll/cppll/article/6196

でもさ、コンテキストスイッチングとかマイクロスレッドってc/c++標準の機能でもないし、実装にはそれなりに手間もかかるし、無いとまったくプログラムできないわけでもない。
そういうものをタスクシステムを紹介している>>2に包含してないからって駄目呼ばわりするのはどうなのよ。

黙るとかいいながらまた長文たれながしてるな。すまんね。>>319


321 :名前は開発中のものです。:2008/12/24(水) 23:11:27 ID:jdZgu35M
おっとあぶない。コンテキストスイッチを setjump()/longjumpで実装することも
できるみたいだし、GNU pthを使ったコルーチンの例もあるから、c標準
で実現できないと書くとまた突っ込まれるな。もうぐだぐだだ。


322 :名前は開発中のものです。:2008/12/24(水) 23:30:35 ID:RyEm5AoF
馬鹿だろ
普通初見でプログラムみたらそういう状態が認識できるならそういう変数探すだろ
探してあればそれは読みやすいプログラム
ところがそれを無くそうとするとかいかにやねうらおの程度が低いかわかるな
あるべきところにあるソースのほうが俺はいいソースだと思うぜ

やねうらおまわりってさ
こういう普通の常識もわからない馬鹿ばっかりだから嫌いなんだよね
俺、俺が初心者のときから嫌な匂いしたわこいつら
俺ももう経験10年だけど
こいつらってズレてんだよね
力入れる部分がさ

323 :名前は開発中のものです。:2008/12/25(木) 00:21:23 ID:a/8vcZsU
>>320
> そういうものをタスクシステムを紹介している>>2に包含してないからって駄目呼ばわりするのはどうなのよ。
じゃ、使うメリットが何もないじゃん。

324 :名前は開発中のものです。:2008/12/25(木) 17:45:17 ID:5Ans8N0b
>>322
このスレの流れと逆のこと言ってないか?

このスレの流れ的には、
ジョブコンにはコンテキストスイッチがあったのに、それの発展形を
事象するタスクシステムはそれを取っ払ってる。その結果、グローバル変数で
状態を持ってやったりしなきゃならない、バカじゃね?
ということになってるのに、なんで突然そのグローバル変数を賞賛するかね?

やねがズレてるのは俺も感じてるが、お前はもっとズレてる。

325 :名前は開発中のものです。:2008/12/25(木) 17:54:00 ID:DGaHaIHQ
>>324
は?
グローバル変数を賞賛?
どこにそんなこと書いてあるの?
やねうらおまわりはあいかわらず馬鹿だな

326 :名前は開発中のものです。:2008/12/25(木) 19:54:19 ID:5Ans8N0b
> そういう状態が認識できるならそういう変数

って普通グローバル変数だろ。
グローバルじゃないにしてもstatic変数。実行させてみないと挙動が把握できない。

そういう変数じゃなくて、ブツ切りの挙動を上から下に並べて書けるのが、
継続とかコルーチンとかマイクロスレッドとかファイバを利用したテクニック。
それを頭からバカにしてるのがお前。

327 :名前は開発中のものです。:2008/12/25(木) 20:17:48 ID:cbF0jNVH
よくわからんが、FSMの状態変数のことを言っているんなら
クラスのメンバあたりが妥当で、別にグローバルやstaticである
必要は無いんじゃないの

328 :名前は開発中のものです。:2008/12/25(木) 20:39:58 ID:DGaHaIHQ
>>326
はぁ?
思い込み激しすぎ
どこにそんなこと書いてあるの?

329 :名前は開発中のものです。:2008/12/25(木) 22:26:40 ID:IlrfutNd
ポエマーはクリスマスの家族サービスも終わって一休み、一休み
あとは印刷屋に注文したブツが配送事故なく無事に現地に到着することを祈るだけだよ

∩∩
(・x・)   「パパは誰と戦ってるの?」

(@∀@)「パパはね、今フェードアウト2Dゾンビという怪人と戦ってるんだよ。
     この世に未練タラタラの8bit悪霊に取り憑かれた若者達を正気に戻すために
     作文を書いてるんだ。おやすみ」
∩∩
(・x・)   「ふーん、まぁがんばってね」


娘に絵本を読んで寝付かせた後にネットブックでちょっかい出しに来たのね。勤労家だね

330 :名前は開発中のものです。:2008/12/25(木) 23:14:09 ID:IlrfutNd
>>289
>こういうの見ると、メインフレーム屋さんではなくて制御屋さんの発想な気がするけど

私がまだ下っ端だったころ、電機メーカーでプラントのプロセス制御用のシステム開発に
携わってた人とか、光学機器メーカーで組み込みシステムに携わってた人がいたのね
彼らは今で言うところのリードプログラマに相当する存在だった。俺を含む当時の若手は
彼らから色々教わったのねー

メインフレーム屋(?)とか制御屋(?)とか、そういう分類はよく知らないけど
(基幹業務システムの人とか組み込みシステムの人とかそういう分類で言ってるんだとは思うが)
そういうのに関係なく、当時コンピュータに携わってた人間は多かれ少なかれリタラシーとして
メインフレームのことは知ってたのね。学生時代、お手本となる本格的なコンピュータシステムといえば
その代表格はメインフレームとその弟分たち(オフコン、ミニコンとか)だったのね。教科書には
当たり前のように登場したし、卒研のためにメインフレームを使わせてもらえる贅沢環境を体験した奴も
いたのね。研究室単位ではミニコンのほうが多かったけど、それらのモニタやOSもメインフレームなどの
大型コンピュータのそれを踏襲してたのね

【メインフレームの基礎知識】って言ったのはそういうことなのね。教科書レベルの知識のお話

331 :名前は開発中のものです。:2008/12/26(金) 00:03:56 ID:nQQPnA5J
>>294
>(1)
別にぽまえさんがクリティカルヒットしたわけじゃないでしょ?
他人事ならニヤニヤしてればいいと思うのよねー

まぁ何度も言ってることだが、当時の実装対象の特性なんてこれっぽっちも知らない人間が
64bitマルチコアCPU&9600GTクラスのビデオカード(DSPカード)搭載のモンスターPCを持ってたりする人間が
IDE付きの静的型付言語の開発環境(VS2008EEなど)+DirectXなどを使ってる人間が
ちゃんこ鍋循環リストにすべてを放り込んでバッチ処理するだけの(今となっては何とも珍妙でお粗末な)
仕掛け(>>2)をどうして神格化するのかおじさんは不思議で不思議で仕方が無いのよねー
「タスクシステム…いとしいしと…」と地底奥深くでひっそりと一人で、職場の中で囁くだけなら別にどうでもいいが
公衆の前で「>>2素晴らしい!神の業!すげーすげー!超参考になる!真似しないと!」と絶叫する奴は
相応の陵辱を受ける覚悟をしてもいいと思うのよねー

332 :名前は開発中のものです。:2008/12/26(金) 00:05:55 ID:tFa9iljv
>>331
お前、なかなかわかってるなw

333 :名前は開発中のものです。:2008/12/26(金) 00:24:31 ID:aORXdj9D
まぁこのスレを、公衆の前と思うかチラシの裏と思うかは人それぞれという気もする。

334 :名前は開発中のものです。:2008/12/26(金) 00:27:54 ID:mDOQ1BG2
>>331
ハァ?、て感じだな。

一体、何を問題にして、何を前提にしているんだ?
一体、何を問題にして、何を前提にしているんだ?
一体、何を問題にして、何を前提にしているんだ?
一体、何を問題にして、何を前提にしているんだ?
一体、何を問題にして、何を前提にしているんだ?
一体、何を問題にして、何を前提にしているんだ?
一体、何を問題にして、何を前提にしているんだ?
一体、何を問題にして、何を前提にしているんだ?
一体、何を問題にして、何を前提にしているんだ?
一体、何を問題にして、何を前提にしているんだ?

335 :名前は開発中のものです。:2008/12/26(金) 00:30:21 ID:nQQPnA5J
私は、何かの縁で最近就職希望の学生さんの就職説明会(なのかしら)に立ち会う機会があった。
どこもかしこもみんな多忙で、こんなオサンが出張ることになった。フェードアウト窓際のふりをして
タラタラと講話をしていた。眠い話が終わると、ご質問ごじゃいますかーと進行のお兄さん(イケメン)が言う

想定どおり、痛くもかわいい質問が多くてにんまりうんじゃりしていたが、特にやべぇと思ったのが
タスクシステムがどうのとかいうゲー専の子だった。本物のフェードアウト2Dオヤジの講師にナニを
吹き込まれたのか知らないが私はゲー専に行く子はちょっと可哀想だなとそのとき思った。
彼には直接個人指導してやりたかったがそういうお時間はいただけなかった。まぁどうでもいいや


336 :名前は開発中のものです。:2008/12/26(金) 00:35:22 ID:nQQPnA5J
×フェードアウト窓際のふりをして
○フェードアウト窓際としては久しぶりの仕事なので

337 :名前は開発中のものです。:2008/12/26(金) 00:43:37 ID:aORXdj9D
>>334 主要部だけ抜き出すとここだな。

オブジェクト指向の恩恵をふんだんに受けられる環境で開発してながら、
ちゃんこ鍋循環リストにすべてを放り込んでバッチ処理するだけの
(今となっては何とも珍妙でお粗末な)仕掛けをどうして神格化するのか?

338 :名前は開発中のものです。:2008/12/26(金) 00:52:58 ID:tFa9iljv
>>335
やべw
ファンになりそうw

339 :名前は開発中のものです。:2008/12/26(金) 00:57:58 ID:mDOQ1BG2
>>337
悪いが俺には、
「オブジェクト指向の恩恵をふんだんに受けられる環境」で
タスクシステム指向を否定する理屈が理解できない。

>一体、何を問題にして、何を前提にしているんだ?

340 :名前は開発中のものです。:2008/12/26(金) 01:09:03 ID:aORXdj9D
> ちゃんこ鍋循環リストにすべてを放り込んでバッチ処理するだけの
> (今となっては何とも珍妙でお粗末な)仕掛け

という評価を否定してみせろ>ID:mDOQ1BG2

341 :名前は開発中のものです。:2008/12/26(金) 01:12:51 ID:tFa9iljv
>>339
>タスクシステム指向を否定する理屈が理解できない
頭おかしいんだw

342 :名前は開発中のものです。:2008/12/26(金) 01:54:38 ID:IU47ZxI2
Lisp?>ちゃんこ鍋循環リスト

Lispは何でもリストで、データとプログラムが同等で、
プログラムを生成するプログラムは常套手段ですが、
今や再評価される一方のモテ言語でつよw

343 :名前は開発中のものです。:2008/12/26(金) 02:04:03 ID:aORXdj9D
Lispのリストは単方向リストで、普通は関数的に使うもの。
(まぁ副作用バリバリで使うこともあるけどな)

「タスクシステム」のリストは、双方向リストで、デク(Double Ended Queue)
と呼ばれるデータ構造。副作用バリバリで使うのが基本。

もうちょっと中身がわかるまで勉強してから出直してね。

344 :名前は開発中のものです。:2008/12/26(金) 02:07:13 ID:aORXdj9D
あ、つまり、同じ「リスト」でもはっきり言って別物だよ、ってことね。

345 :名前は開発中のものです。:2008/12/26(金) 02:12:01 ID:IU47ZxI2
>>343
その説明だけだと、Lispがなぜ良いものでタスクシステムがなぜ
唾棄すきものかがさっぱり分からないのですが。

346 :名前は開発中のものです。:2008/12/26(金) 02:13:18 ID:aORXdj9D
Lispと同一視して再評価すべきだ、みたいな話を持ち出したのはそっち。
俺はそれを否定しただけ。

347 :名前は開発中のものです。:2008/12/26(金) 02:13:38 ID:IU47ZxI2
静的型安全性が無い、コードがデータと同じで自己書き換えを行えてしまう、
といった動的性はLispにも当てはまることです。
Lispはconsセルをもとに、データ構造をどうとでも作れます。

348 :名前は開発中のものです。:2008/12/26(金) 02:15:28 ID:IU47ZxI2
>>346
タスクシステムを再評価すべきだとは「一言も」言っていませんよ。
そもそも>>342は半分以上ネタです。

が、「ちゃんこ鍋循環リスト」は、それで何かを貶したつもりになっているのなら
少々不適切なのでは?と愚考する次第です。

349 :名前は開発中のものです。:2008/12/26(金) 02:15:35 ID:tFa9iljv
>>345
馬鹿じゃねぇの
話そらしてんじゃねぇよ

350 :名前は開発中のものです。:2008/12/26(金) 02:17:35 ID:IU47ZxI2
>>349
は?何から?

351 :名前は開発中のものです。:2008/12/26(金) 02:20:40 ID:tFa9iljv
やねうらおの近くにいるとくだらない話術ばっかり達者になってくカスに成り下がるな
奴は所詮3Dも理解できないクズ
大きく複雑な仕組みを小さく単純な形に噛み砕くことはできない

本人すげー頑固で視野狭いしね
止まっちまう理由もわかる

352 :名前は開発中のものです。:2008/12/26(金) 03:15:07 ID:aORXdj9D
確かに、一度は奴に傾倒しても、適度に距離を置いた奴は大成してるね。

353 :名前は開発中のものです。:2008/12/26(金) 06:18:00 ID:pIz4GYzN
>>349
プログラム全体を関数型で設計するなら、Lisp のリスト構造が適している。
ただゲームを組むのに関数型言語が合ってるとは思えんが。

354 :名前は開発中のものです。:2008/12/26(金) 08:28:43 ID:tFa9iljv
>>352
そうだね
奴もすべてが駄目ってわけじゃないんだよね
でも結局、3Dができねぇってのは大きく複雑なものを小さく単純な形にできないってこと
これはプログラムの能力に直結する

小さいプログラムをこね回してる分にはどんな方法で何やったってなんでもできるんだよ
でも本当に複雑なものを管理するにはそれなりの力がいる

ごちゃごちゃいう前に3Dやってみろボケ
ってことだよね
まあ、ヤツにいえることはこういうことだよね

355 :名前は開発中のものです。:2008/12/26(金) 10:34:25 ID:aORXdj9D
>>354
すげぇ理屈

もしかして昔奴の「クォータニオンどうこう」に騙されてたとかそんな理由?

356 :名前は開発中のものです。:2008/12/26(金) 13:39:13 ID:tFa9iljv
>>355
いや、そんなの知らんけどw

357 :名前は開発中のものです。:2008/12/26(金) 22:38:40 ID:mDOQ1BG2
>>340
タスクシステムにケチ付けてるとも読み取れる中途半端な書き込みしやがって。
ヘタレっぽい書き込みだから無視してもかまわないんだが、
看過するのはやや気が咎める。
相手してやってんだから、もっと具体的な話してみろや。
ほれ、どうしたんだ。

>一体、何を問題にして、何を前提にしているんだ?
>一体、何を問題にして、何を前提にしているんだ?
>一体、何を問題にして、何を前提にしているんだ?
>一体、何を問題にして、何を前提にしているんだ?
>一体、何を問題にして、何を前提にしているんだ?
>一体、何を問題にして、何を前提にしているんだ?
>一体、何を問題にして、何を前提にしているんだ?
>一体、何を問題にして、何を前提にしているんだ?
>一体、何を問題にして、何を前提にしているんだ?
>一体、何を問題にして、何を前提にしているんだ?

358 :名前は開発中のものです。:2008/12/26(金) 23:26:14 ID:/2aOAzbG
ねーねー聞いていい?
この人がケチ付けられたと火病ってる「タスクシステム」ってナニ?
え、>>2なの?マジで>>2なの?すごくね?まじシステムって感じ

359 :名前は開発中のものです。:2008/12/26(金) 23:34:18 ID:tFa9iljv
ひらしょーさんに「タスクシステム?なにそれ?」って言われた時点で
こいつらはもう死んでる
この単語がだれにも通用しないってことがわかっただけでもいいだろもうw

360 :名前は開発中のものです。:2008/12/26(金) 23:42:45 ID:mrzJIk+i
違うな

ぼくのかんがえたぼくのたすくしすてむをばかにするやつはゆるさない
ぼくのたすくしすてむはぼくがぼくであることのあかし、ぼくのあいでんててーそのもの
ぼくのたすくしすてむにけちつけるやつはぼくをひていしようとするやつだ

      だ か ら っ ぜ っ た い っ ゆ  る  さ  な  い  っ っ 

ということだと思うぞ
タスクシステムという単語を使って突っ突くとどっかの誰かが癇癪を起こすのだ
わくわくするだろ

361 :名前は開発中のものです。:2008/12/26(金) 23:44:12 ID:mrzJIk+i
おまえら横入りでレスすんな。>>360>>358あてなんだからね
ひらしょーはしごとしろ

362 :名前は開発中のものです。:2008/12/27(土) 00:13:18 ID:kUina8sT
ID:mDOQ1BG2だけど、
「嫌タスク厨」って気色の悪い連中が多いな。

363 :名前は開発中のものです。:2008/12/27(土) 00:19:47 ID:1Y+r92ib
>>362
なんで泣いてんだよw

364 :名前は開発中のものです。:2008/12/27(土) 00:39:49 ID:kUina8sT
「嫌タスク厨」の書き込みを見てて思うんだが、

>一体、何を問題にして、何を前提にしているんだ?

これにつきるな。

恥ずかしい連中だな。
プ!!
ワリィ、失笑しちまったぜ。

365 :名前は開発中のものです。:2008/12/27(土) 00:44:02 ID:quq8i6DN
ポエマーは3D酔いの話をしたら眠くなりました

366 :名前は開発中のものです。:2008/12/27(土) 00:56:24 ID:1Y+r92ib
また、やねうらおに騙されたかわいそうな初心者が発狂したか

367 :名前は開発中のものです。:2008/12/27(土) 01:27:14 ID:Yea5ohhj
>>365
つーかあんたなんで初心者スレでは優しい人に変身してんだよ
キャラ変えすぎだろ女子高生的に考えて…

368 :名前は開発中のものです。:2008/12/27(土) 11:33:58 ID:fiVf7uJ8
6年も前のMLのログを引っ張り出して何やってんだか

369 :名前は開発中のものです。:2008/12/27(土) 15:45:45 ID:UXiflr2J
正直俺も嫌タスク厨はどうかと思う。

370 :名前は開発中のものです。:2008/12/27(土) 15:49:11 ID:PX4qd4CE
あれ、ID変わったかな?

371 :名前は開発中のものです。:2008/12/28(日) 00:08:38 ID:9bx8+r7b
>やねうらお

>一体、何を問題にして、何を前提にしているんだ?

372 :名前は開発中のものです。:2008/12/28(日) 09:54:21 ID:kNsvEJS4
>>370
日本語としては「じっぽん」が正しいが、レッドブックの「とおほん」(×とうほん)も間違いではない
ただ朝鮮人や一部の関西人が良く使う「じゅっぽん」は明らかに間違い
これを使っていると日本人である事を疑われるので気を付けるように

373 :名前は開発中のものです。:2008/12/28(日) 10:00:52 ID:l5BdqN5n
10円20銭

374 :名前は開発中のものです。:2008/12/29(月) 07:51:23 ID:5ANW5Mxu
「嫌タスク厨」はロクに質問にも答えられないキチガイばっかだな。
常人の感性からすると気色悪くて目障りだからオンするなよ、なあ?

親切心から言ってやるが、
本人気利かせているつもりのチンケで鬱気味の幼稚表現も痛々しいぞ、自覚してるか?
まあ、それがお前らの正気状態か。
せいぜい頑張れや。
プ!!

375 :名前は開発中のものです。:2008/12/29(月) 11:21:47 ID:Ah7A1aEB
ひらしょーさんになにそれ?だれきみ?ってあしらわれたショックで
気が狂ってしまったん?

376 :名前は開発中のものです。:2008/12/29(月) 13:33:00 ID:Af+lgojS
自分の言葉で論破できなかった厨房が、お墨付きをもらって狂喜してるだけにしか見えない。

377 :名前は開発中のものです。:2008/12/29(月) 18:17:39 ID:2WLNxkwH
ま、そういうくだらない連中のノイズ成分くらい除去できないと駄目だと思うけどね
ひらしょーさんひらしょーさん言ってる子供達もどうせついこの間までは
たすくしすてむさいこー松浦先生大好き尊敬しちゃうとか言ってたはずなわけで

風見鶏を右へ左へ引きずり回すのは楽しいよね。そろそろ>>2擁護始めるか


378 :名前は開発中のものです。:2008/12/29(月) 20:02:06 ID:s7jYkUya
その問題のやねうらおとやらは、お前たちの何倍ものプログラミング能力があって、
お前たちの何倍も稼いでいるようだけどな

379 :名前は開発中のものです。:2008/12/29(月) 20:29:38 ID:2WLNxkwH
やねうらおが何だのかんだのと喚いてるのはpmocky一名だろう

380 :名前は開発中のものです。:2008/12/30(火) 10:15:13 ID:Ak2RXwcs
pmokyな。奴がこんなとこで粘着する性格とも思えないが。

381 :名前は開発中のものです。:2008/12/30(火) 20:27:11 ID:e9u2cYzi
本人乙。やねうらおと何があったのか知らんが
あちこちのスレで発作的ESPでやね探知する度に私怨コピペ張るなよ
マ板にスレ立てるなり民事調停するなり労基に駆け込めよ

382 :名前は開発中のものです。:2008/12/30(火) 20:29:06 ID:e9u2cYzi
と思ったらスレあんのかよ。あのオッサンの界隈は相変わらず賑やかだね

383 :名前は開発中のものです。:2008/12/30(火) 21:29:05 ID:kY5NjYxZ
松浦先生はエフェクトの人?
やねうらおなんかと比べるのは失礼だろ(笑)

384 :名前は開発中のものです。:2008/12/30(火) 22:17:02 ID:XRQQzBHj
どう見てもそのやねうらおとやらののほうが格上だがな。

松浦先生の最新刊
ゲームアルゴリズムレシピ 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
本読んでみりゃわかるのに

386 :名前は開発中のものです。:2008/12/31(水) 01:04:00 ID:K//GK7EM
大掃除も終わったし、一杯ひっかけながらちょっとポエムを書いてみるのねー

多数のジョブを並行、並列に処理する能力は科学計算、軍事、宇宙開発など様々な分野で必要とされた。
特にリアルタイムという要求は軍事や宇宙開発と絡むことが多かった

【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

387 :名前は開発中のものです。:2008/12/31(水) 01:05:23 ID:K//GK7EM
>>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
キチガイだな
華麗にスルーして次の話題ドゾ

389 :名前は開発中のものです。:2008/12/31(水) 05:30:43 ID:MGGyGm5U
>>386-387
最後にSpaceWarにつながるのかw
あのソースってパブリックドメインなんだよね
ダウソして解析しようとしたことあるんだがPDPの
アセンブリコードの読み方が分からなくて投げた

390 :名前は開発中のものです。:2008/12/31(水) 07:04:20 ID:hWK9IXCu
WikipediaのSAGE半自動式防空管制組織のページを開いたら

>50万行にも及ぶアセンブリ言語で書かれた

( д )゚ ゚ スポーン

391 :名前は開発中のものです。:2008/12/31(水) 08:38:28 ID:c+tqC+cg
・SFCでゲーム一本3万行を超えた記憶がない。ような気がする

・AN/FSQ-7の命令セットがどんなものか知らんのでアレだけど
 きっちりかっちり設計して50万行か。保守が大変だったろうね

・別の視点で見るとそれだけ巨大そうなシステムがアセンブリ言語で
 "たったの50万行"で動いてた、ということにちょっと驚いてみたーり

・昭和20年代でコンピュータが戦闘機を遠隔操作とかやばい。冷戦やばい

・MITやばい


392 :名前は開発中のものです。:2008/12/31(水) 11:25:14 ID:WRynoJXH
PDP-11ならUnix V6関係で解説とかあるけどな。
ttp://www.tom-yam.or.jp/2238/asm.html
これとか手がかりになるかな。

先日もサンタクロース追跡で大活躍したNORADのシステムの祖先の話やね。
トラックボールの発祥もそれだったから、ミサイルコマンドの源流もそこか。
こまかい所だがDECのはミニコンピュータね。それにしても何かの引き写しじゃなくて
自分で書いとるのかいオッサン? データプロセッシング分野と比べて
リアルタイムアプリケーションの話は文献が無いと思うのだが。

393 :名前は開発中のものです。:2008/12/31(水) 16:41:55 ID:vN1M20DF
スレ違いじゃないの?

394 :名前は開発中のものです。:2008/12/31(水) 23:47:47 ID:94mB5cNv
ワイヤーフレームの図形描画に対応してたのか
ゲームを作りたくなる気持ちが分かる気もするな

395 :名前は開発中のものです。:2009/01/01(木) 00:31:54 ID:ocRuaHu5
関係無いよね
スレと

396 :名前は開発中のものです。:2009/01/01(木) 03:03:58 ID:+Dm90zaN
コンピューターが沢山の爆撃機(敵オブジェクト)の振る舞いを監視して
飛行データから未来位置や爆撃目標到達時刻を予測して人に教えて
迎撃機やミサイル(味方オブジェクト)に向かうべき座標を指示する・・・か

まさにリアルDEFCONだな

写真にディスプレイの記号解説あるな
各オブジェクトが所有するステートが垣間見れて面白いな

POINT OF ORIGIN
ALTITUDE
DIRECTION
SPEED
IDENTITY
TRACK NUMBER
FLIGHT PLAN NUMBER
CORRELATION STATUS
TYPE OF AIRCRAFT
FLIGHT SIZE

397 :名前は開発中のものです。:2009/01/01(木) 05:10:15 ID:PQkpygmM
CORRELATIONって辞書引くと相互関係、相関関係となるけど
自機僚機とか親子(発射母機とミサイル)とかそういうもの?

んービル一棟分の真空管コンピューターでSTG作ってみたいわ

398 :名前は開発中のものです。:2009/01/01(木) 06:37:29 ID:ocRuaHu5
スレ違いやめろ

399 :名前は開発中のものです。:2009/01/01(木) 10:33:14 ID:DySRAuVd
スレ違いどころか、板違いだな。
昔話用の板あるんだから、そっち行けよ。

400 :名前は開発中のものです。:2009/01/01(木) 13:58:54 ID:fTWypGoF
>>397
なるほど・・・・・ちゃんとFSMしてるんだな
超プロプライエタリな世界だからソースは無論非公開だろうけど
仕様からおおよそのところが想像できておもろいな

401 :名前は開発中のものです。:2009/01/01(木) 14:00:21 ID:fTWypGoF
>>396>>396-397

402 :名前は開発中のものです。:2009/01/01(木) 14:16:34 ID:kIedBn3k
sageずに書き込みしてる>>374,375,383,385,388,393,395,398 が、
底抜けの馬鹿だと言うことはよくわかった

403 :名前は開発中のものです。:2009/01/01(木) 15:00:31 ID:ocRuaHu5
全然関係無い内容じゃん
引用するにしてもスレと内容の説明責任ぐらい果たしていけよ
垂れ流しが酷いし
タスクシステムと関係無いじゃん
関連してると思ってるって自分だけの思い込みで強引に話を無駄に広げてるんだろうけど
ちょっとオナニーが酷く生臭いよ

404 :名前は開発中のものです。:2009/01/01(木) 15:12:29 ID:AYpKL28G
編隊飛行が表現できるなら木構造になるし
ロックオンした目標が複数あればグラフ構造にもなるな

405 :名前は開発中のものです。:2009/01/01(木) 15:18:57 ID:kIedBn3k
>>403
わかってないのお前ひとりだけじゃん。
お前が底抜けの馬鹿だからわからないだけで・・・

406 :名前は開発中のものです。:2009/01/01(木) 16:17:14 ID:bLjGdube
板違いスレ違いを続けるのはそろそろどうかと思うんだな。

407 :名前は開発中のものです。:2009/01/01(木) 16:53:23 ID:ocRuaHu5
全然関係無いよね
なんか
わからないんだ?プギャー(笑)
的な流れにして説明責任果たそうとしない流れにしがちだけど
現実、仕事となったらここが一番大事だしその後の理論がどんなに立派でも糞とカワンネ
仮に関連してたとしてもこれ関連性を説明するの滅茶苦茶大変だぜ

408 :名前は開発中のものです。:2009/01/01(木) 16:58:11 ID:kIedBn3k
訂正。わかってないの、>>406,407のお前ら二人だけだよ。

大馬鹿はお前ら二人。

409 :名前は開発中のものです。:2009/01/01(木) 17:27:22 ID:AYpKL28G
触んないほうがいいんじゃない?

410 :名前は開発中のものです。:2009/01/01(木) 18:05:53 ID:DH9ba0yV
>>404
こういうのってHFSMみたいな記述になるのかしら

ツリーの各ノードがFSMっていうイメージでいいのかな>HFSM

411 :名前は開発中のものです。:2009/01/01(木) 18:30:10 ID:AYpKL28G
HFSMは状態の木構造、状態の中にさらに状態がある
みたいなものじゃなかったっけ(ちがったかな)
編隊のリーダーと部下みたいなFSM同士の主従関係とか
組織のヒエラルキーをあらわす木構造の場合は
単に木構造のコンテナにFSMが入ってればいいだけなので
HFSMとは違うかもだ

412 :名前は開発中のものです。:2009/01/01(木) 19:05:56 ID:ocRuaHu5
>>408
そんなこと言って難しい部分は説明できないから逃げる気でしょ?
職場でもこんなわけのわからないもの採用させるなんていったら大変なのはそこだよ
逆に批判をかわすのもわけわかんないこと叫んでかわせばいいけど
そうゆうこと馴れると技術者として死ぬよ
批判する側に説明責任の押し付けゴッコ始めていつもかわすけど
そもそもなんの関連もないの明らかじゃん

413 :名前は開発中のものです。:2009/01/01(木) 19:19:14 ID:kIedBn3k
>>412
何度でも言うがわかってないのお前ら馬鹿二人だけなんだよ。

なんなら周りのプログラマにこのスレ見せて聞いてみなよ。

414 :名前は開発中のものです。:2009/01/01(木) 19:29:46 ID:ocRuaHu5
説明責任放棄する奴は二言目には必ずそういう
関係無いから関連を説明しろっていってるだけじゃん

415 :名前は開発中のものです。:2009/01/01(木) 19:44:34 ID:kIedBn3k
>>414
馬鹿すぎて周りに友達いねーのか。それは可哀想に。

416 :名前は開発中のものです。:2009/01/02(金) 07:00:34 ID:sLC5p+39
>>386-387
すげぇな
飛行機や対空ミッソー飛ばしてもデッドライン(敵が目標上空に着く時間)までに
敵とご対面させてやらなきゃ全部パーだよな?

リアルタイムシステムだな。しかもかなりハードな

417 :名前は開発中のものです。:2009/01/02(金) 16:48:56 ID:btxOwAnq
匿名でも記名でもi君の人を見下した態度は相変わらずだな

418 :名前は開発中のものです。:2009/01/02(金) 20:57:49 ID:+c5nb6jC
>>411
dクス。なるほど。状態に子あ孫があるのか

419 :名前は開発中のものです。:2009/01/03(土) 19:21:39 ID:ejAsMA5Y
で、代替案はまだ出ないの?

420 :名前は開発中のものです。:2009/01/03(土) 23:49:19 ID:x7V4/J69
代替案?
なんの?
こんなもん使わなきゃいいだろ
普通に必要なだけ処理書いて引数で必要なもんだけ渡せよ

421 :名前は開発中のものです。:2009/01/04(日) 09:29:42 ID:9lklfsu+
つまり420は配列派というわけですね?

422 :名前は開発中のものです。:2009/01/04(日) 09:42:16 ID:OS7DnqUy
アホか

オブジェクト指向で普通に書けばいいだろヴォケ

423 :名前は開発中のものです。:2009/01/04(日) 10:01:35 ID:bsxJMCxA
配列はインスタンスの話だろ
多分

424 :名前は開発中のものです。:2009/01/04(日) 11:18:31 ID:d8gMrFGB
Taskをモナドにしよう

425 :名前は開発中のものです。:2009/01/04(日) 15:08:16 ID:9lklfsu+
オブジェクト指向で普通に書いたらタスクシステムだけど?

426 :名前は開発中のものです。:2009/01/04(日) 16:24:39 ID:OS7DnqUy
オブジェクト指向プログラミングでは双方向リストをガチガチに手書きするのが
普通なんですかそうですか。

それってどこの世界のオブジェクト指向プログラミング?

427 :名前は開発中のものです。:2009/01/04(日) 16:48:53 ID:Do3+Cssh
リストかどうかって別に本質じゃないような。

>>2を見る限りでは、個々のタスクはただ一つ、「実行しろ」というメッセージにしか
反応しないオブジェクトのように見えます。

よって、オブジェクト間の相互作用のための手段は非常に限られるので、
C風に「リストを舐めて構造体の中身を直接のぞく」コーディングが行われていたのでは
ないでしょうか。
それは「OO」じゃないですよね。人のものを勝手に見るのではなく、
人に頼む、尋ねるのがOOのスタイルです。

それとも、実際にはタスクは複数のメッセージを処理するためのディスパッチャ
や関数テーブルを持っていたのでしょうか?
それならば、貧弱な言語/環境であるがゆえに
自分で型タグやオブジェクトID、メソッドテーブルを実装しなければならなかった
というだけで、OOであると言っていいと思います。

428 :名前は開発中のものです。:2009/01/04(日) 19:15:52 ID:OPWOLTuA
そういう、Cでオブジェクト指向を実現するためのテクニック
(有名どころではXtとかが使ってた)の真似事みたいなことは
してるけど、オブジェクト指向とはどうにも認めがたい。

タスクとキューはis-a関係じゃないしな。
(オブジェクト指向をCで、的にはそういうことをしてる)

秀和の本でだいぶ古いけど、「C言語ゲームプログラミング」が
それっぽいことをやっていたな。今見る価値がある本ではないが。

429 :名前は開発中のものです。:2009/01/04(日) 22:14:00 ID:JA/ZQlx8
C++で普通に作ったらタスクシステムというものをわざわざ用意しなくてもいいのは事実。
単一のインスタンス構造に多数の関数ぶらさげてただけだし。

430 :名前は開発中のものです。:2009/01/04(日) 23:50:15 ID:ZM4TPJrr
とんでもない神レベルの人ととんでもない馬鹿とが混在するのがこのスレの面白いところだな

431 :名前は開発中のものです。:2009/01/05(月) 01:24:39 ID:NWIfeL18
>>429
あんまりその辺こだわってる奴ってもういないと思うぜ
オブジェクト指向云々とかあまり問題じゃない
たまに急に振る奴がいるけど別にクラスなんかあってもなくても同じ問題に直面する

ま、STGだったら自機、敵、弾とあってそれぞれをクラスっていうか
オブジェクトにして必要な分のインスタンスを用意する

ここまではみんないっしょだろうし別にC言語風味に構造体定義して
インスタンス作っても別に大して変わらない

問題はインスタンスの扱いだと思うんだよね
@void*で一括して配列用意して(リストでもいいけど)newで確保して型覚えておいてキャストして使うか
(これがタスクシステムっぽいやつ?)
A型ごとに配列定義して地道に作っていくか
(これが正統派?)

まあ、微妙な違いはあれどこの2つのどっちかになるだろね
前者だと必要なところどころで型キャストして戻さなきゃいけないけど一括して扱える
後者だと型ごとに同じ処理を何度も書かなきゃいけないけどキャストとかする必要がない

ただ、@の方法で組むと一括処理にばっかりこだわって引数とか省略して
グローバル変数使うようになってバグが増えるのはたしか
Aで組んだほうがソースもわかりやすい(と、俺は思う)
まあ、Aは面倒だけど正統派?そんなイメージ(ただ、面倒っていっても実装的に面倒って話だからねぇ・・・)

とまあ、オブジェクト指向云々関係ないでしょw

432 :名前は開発中のものです。:2009/01/05(月) 02:50:49 ID:yvKzI2YZ
一括して扱える、同じコードで扱えるというのはCPUにとっては全くうれしくない

闇鍋循環リストに全てを放り込む>>2が何故詰んでいるかというと
弾も敵もパーティクルもひとつのリストにぶち込み同じコードでディスパッチするから。
分岐先はほぼ予測不可能。>>2はハードウェアに分岐先を絞り込むヒントを与えない。
サブルーチンアドレスはフラットなFSMの状態変数を兼ねているため種類は膨大。
CPU内蔵の分岐先バッファは役に立たない。ループする度に分岐先予測ミスが発生し
ペナルティを受ける。毎度毎度ご丁寧にサブルーチンアドレスを参照してディスパッチ
オブジェクトの種類順(弾、敵、プレイヤーなど)にソートしても根本的な解決には
ならない。なぜならオブジェクトの種類が同じであっても状態が違えばサブルーチン
アドレスは違うのだから

大昔に興味本位で測定した。AMDのAthlonXP(Bartonコア)で>>2を使うと速度は半分になった

大昔の、アドレッシングモードの貧相な(かなり特徴的な)8bitCPU、それにOBJやBGを
HSYNC毎にアナログ映像信号に変換してCRTに出力してくれるハードワイアードロジック回路
を搭載したカスタムボードを中途半端に意識して、当時の神の業などと詐称して喧伝してる時点で
クズの所業だが、実際に走らせるハードの特性を完全に無視してるのだから輪をかけてクズといえる

433 :名前は開発中のものです。:2009/01/05(月) 03:19:03 ID:yvKzI2YZ
あ、クズの所業ってのは>>2の各URLの中の人のことじゃないからな
そこで解説されてる手法(?)を祀り上げてるカルト信者のことな

434 :名前は開発中のものです。:2009/01/05(月) 07:07:50 ID:s3/QcMtY
×HSYNC毎に
○ライン毎に

435 :名前は開発中のものです。:2009/01/05(月) 08:26:50 ID:tyiIafJA
>>432
>大昔に興味本位で測定した。AMDのAthlonXP(Bartonコア)で>>2を使うと速度は半分になった
面白いですね。比較対象ってどんな組み方のものですか?

436 :名前は開発中のものです。:2009/01/05(月) 09:23:56 ID:294GFQWC
いまどきのオブジェクト指向のメッセージ処理で多用される間接ジャンプを、
現代のプロセッサでは性能が出ないとか扱き下ろしている人がいるのは
このスレですか?

437 :名前は開発中のものです。:2009/01/05(月) 10:41:47 ID:s3/QcMtY
制御対象の計算粒度と数の特性ゆえに>>2は不利となる
パフォーマンスアナライザやプロファイラを使わず現実を見ずに先入観のみで
>>2はきっと良いに違いないと盲信するならエンジニアではない
エセ科学信仰とかカルト信仰に溺れる知的弱者だ

438 :名前は開発中のものです。:2009/01/05(月) 10:51:52 ID:T3/gLJL6
>>431
@かAを採用するかは
ゲームによって臨機応変に対処すればいいんじゃないかな
どちらか絶対という事はないと思う
弾幕シューティングなどは明らかに後者が適していると思う
自分が最近作ったゲームはシーン(メニュー、コンフィグ、ゲームプレイなど)すら
オブジェクト化した@を採用してみた

439 :名前は開発中のものです。:2009/01/05(月) 13:00:39 ID:294GFQWC
>>437
> パフォーマンスアナライザやプロファイラを使わず現実を見ずに先入観のみで
> >>2はきっと良いに違いないと盲信するならエンジニアではない
> エセ科学信仰とかカルト信仰に溺れる知的弱者だ

あっそう。

> 制御対象の計算粒度と数の特性ゆえに>>2は不利となる

と断言する根拠を是非パフォーマンスアナライザやプロファイラで示してね。

440 :名前は開発中のものです。:2009/01/05(月) 13:07:36 ID:F56Xf+vn
性能「だけ」で何かを論じるのはおかしくね?
性能だけで論じるなら早い話がC++とか消えろって話だよね

まあC++で書いてるなら
・擬似OOの実装を頑張らなくても、言語組み込み機能でタダで手に入る
・FSM作るのに関数ポインタのすげかえやマシンレベルの実行コード書き換えは
 用いない
・何でもかんでも一個のリストに繋げない
でしょうけれども

441 :名前は開発中のものです。:2009/01/05(月) 13:24:38 ID:DMExbRge
タスク同士で関連づけってどうやってる?


442 :名前は開発中のものです。:2009/01/05(月) 19:58:30 ID:whWAu0ni
タスクシステムって1つのリスト限定なの?
じゃあ俺のタスクシステムじゃなかったんだw

443 :名前は開発中のものです。:2009/01/05(月) 20:04:55 ID:iIypQ15B
>>438
そのごった煮状態ってなんかいいの?
ソース見る側としちゃ勘弁してほしい感じだけど

444 :名前は開発中のものです。:2009/01/05(月) 23:51:57 ID:fCMc2sX5
あけましておめでとうなのねー

>>387
IBMやDECのメインフレーム

IBMのメインフレームやDECのミニコン

>>392
末尾のPDPミニコンの部分は記述ミス。ごめん
酩酊状態でタラタラ書いて校正せずにそのまま投げて寝ちゃった。
Whirlwind 1とSAGE防空システムに関しては英語文献が存在する
半世紀以上前の兵器システムの大凡の機能は教本に載っている。
どっかのmilドメインのサイトに幹部や技術系の中途採用試験(?)
対策用の参考資料が公開されている。詳細なパラメータは伏せてあるが
ぐぐればバシバシひっかかる

445 :名前は開発中のものです。:2009/01/06(火) 00:05:24 ID:d8k/H0vb
>>432
半分はないと思うよJK

446 :名前は開発中のものです。:2009/01/06(火) 00:16:06 ID:uRByKfho
>>441
めっちゃくちゃ複雑じゃね?
そこまでなったらもうバグのオンパレード状態で収集つかない希ガス

447 :名前は開発中のものです。:2009/01/06(火) 12:42:23 ID:Eo7dUke5
>>438
マルチコアならAの方がいいと思う。
カプコンのMTフレームワークもそんな感じだったような。

448 :名前は開発中のものです。:2009/01/06(火) 14:37:10 ID:z4Dce+Vd
>>443
ごった煮かもしれんが、並列処理ができるのがいいのよ
例えばタイトル画面表示中に、雪を降らせるなんてことも容易に実現できる
シーン式のゲームでもやろうと思えばできないことはないが面倒だろ
流石に全てのゲームジャンルでこの方法が適しているとは思わない

449 :名前は開発中のものです。:2009/01/06(火) 15:13:06 ID:8Exk+ciZ
よくわからんが
より抽象度の高い話をすれば
「全てのゲームオブジェクトについて、1フレーム内でiterativeに処理を行いたい」
あるいは
「全てのゲームオブジェクトに、同じメッセージをブロードキャストしたい」
ことがあるかどうか、という話じゃなかろーか
あるのなら、それをリストに持っておくという実装もあるだろう

ただ、抽象的には欲しいのは「リスト」ではなく「反復子」のはずなので、
実装はどうとでもできるように思える


450 :名前は開発中のものです。:2009/01/06(火) 17:34:45 ID:AVnom9hs
>>448
ジョブエントリのリストをなめて順次処理(バッチ処理)するだけの
コードをもって、これは並列処理できるのだと豪語するか。これいかに

バッチ処理するしか能のない粗末なコードをポンと渡して
それをユーザーに無理矢理に逐次処理に使わせておいて
(逐次・並行処理に必要な仕組みは全てユーザーに丸投げておいて)
どうだ便利だろこのソロモンの指輪は、並列処理できるんだぜ、なんといういとしいしと・・・
と陶酔するのは技術屋としてどうなの

451 :名前は開発中のものです。:2009/01/06(火) 20:14:08 ID:dEvFXJdO
>>448
何を言ってるのか本気でわからない
Aで組んだことない?
仮にごった煮にしないでシーン?とゲームオブジェクトを別に管理したら
そっちのが扱いやすいだろ?
まとめるってことはアクセスするたびにそいつを判別するなんらかの仕組みが必要になるってことだし基本的には面倒が増えるよ
よほど一括で処理したいなにかがないとメリットはないと思うんだけど?

452 :名前は開発中のものです。:2009/01/06(火) 20:27:19 ID:a2y2pcid
結論:

タスクシステム = カオスで美麗で斬新な60FPS紙芝居の夢を追及している奴専用

453 :名前は開発中のものです。:2009/01/06(火) 20:36:30 ID:SJLak1z6
うおおおおお!

454 :名前は開発中のものです。:2009/01/06(火) 21:25:55 ID:c5JPjzC/
アクセスするたびに判別が必要ならそれはタスクシステムじゃないじゃん?C++あたりで組むなんちゃってタスクシステムだよ

455 :名前は開発中のものです。:2009/01/06(火) 22:20:13 ID:IveoX0Qe
タスクシステムが賛否両論なのはきっと分割の粒度・観点とかの違いですよ。ええ。
と思いついたので分類してみた。C++なんちゃってタスクシステムの話

 1. マルチプロセス級:ゲームタスク、バッテリ残量監視タスク、...
 2. マルチスレッド級:入力監視タスク、ゲーム処理タスク、描画処理タスク、鳴音タスク、...
 3. 仮想関数インタフェース級:仮想update関数タスク、仮想move関数タスク、仮想draw関数タスク、仮想onkey関数タスク、...

・マルチプロセス級はほぼ関係無い処理だけど1台のPCにはともに入ってて欲しい位のとこで分割。.exe相当。
・マルチスレッド級は決まりきったデータ通信が発生する程度に関係のある処理で分割。
 通信を標準化するのもそう悪くないってとこで分けるのがミソかも(使ったこと無い俺)。
・仮想関数インタフェース級は関係性とか概念の違いとか無視してたまたま関数インタフェースが似た感じっぽいところを探して
 縦横無尽に共通化(抽象化)したもの。イベントハンドラの延長?
 仮想関数インタフェース自体の仕様変更耐性とか再利用性が最悪。最悪。最悪。
 それでいて性能も悪いかも。仮想関数ゆえにメモリキャッシュまわりとか?
 でも1画面ミニゲーム、画面エフェクト無し、凝ったギミック無しとかなら使い勝手良かったりする。
 グローバル変数が通常サイズのクラス1個分に収まる程度までが利点を享受できる適正規模?

2と3の間にゲームオブジェクトとかシーンオブジェクトとかで分けた「クラス分け級」を入れようとしたけどなんか無理だった。
3番と同じ気がしてしっくりこなかった。

456 :名前は開発中のものです。:2009/01/06(火) 23:16:50 ID:8QL2ssG/
実際のゲームってどういう設計が使われてるんだ?

457 :名前は開発中のものです。:2009/01/06(火) 23:22:37 ID:UozvWyya
そもそも実際のゲームには何か共通した設計というものがあるのか?

458 :名前は開発中のものです。:2009/01/07(水) 00:21:50 ID:ioSES1so
その共通部分を抽出したものがタスクシステムだと思っていたんだが・・・

459 :名前は開発中のものです。:2009/01/07(水) 02:21:29 ID:02Pyli+B
>>458
残念だがそのシナリオを選択する(orデカイ声で叫ぶ)のは遅すぎだな。というか無理がありすぎるな

>>2(特にLogicianLord。拡散の元凶)と>>2を誤読したゲッベルス(松浦大先生。拡散させた偉大な男)
およびその忠実な部下(熱烈な読者)は、パンピー(neutralな人)たちに対して、奇妙なまでに一致した
偏った「とあるヘンテコリン実装」でもってタスクシステム(?)なるものを解説しネット・雑誌・書籍で
流布した。流布し尽くした。2009年現在、ネット上で>>458説を提唱するのは完全に手遅れといえる

タスクシステムという言葉は>>2に代表される、極めて特徴的な、奇異なまでに一致したヘンテコリン実装

       「TCBがプライオリティをサブルーチンアドレスでディスパッチなのです><」

と完全に癒着している。もう引き剥がせない。OoOやマルチコアプロセッサの普及により>>2の実装が
obsoleteといえるならば、タスクシステムという呼称もまたこの味噌が付いた実装と共に成仏することになる

460 :名前は開発中のものです。:2009/01/07(水) 08:38:38 ID:A93Nxs/X
ところで次スレからは書籍もテンプレに入れようぜ、戦犯としてw
Cマガ2004/12「ゲームのためのタスクシステム」松浦
単行本「シューティングゲームプログラミング」松浦
「Windowsプロフェッショナルゲームプログラミング2」やね

これだけ?

461 :名前は開発中のものです。:2009/01/07(水) 20:53:38 ID:axJ9jn6k
>>459
じゃあ実際はどんなのが使われてるのか教えてください。
まったく違うものなんですか?
オブジェクトの種類ごとに持つデータが違うとか、
オブジェクトのデータのメモリ管理方法が違うとか、単一のリストじゃないとか、
そんなのは違いのうちに入らないと思うよ。

462 :名前は開発中のものです。:2009/01/07(水) 21:57:34 ID:dIlqsnyP
>>459
オイ、コラァ!
「ヘンテコリン」はお前とお前のキチガイじみた駄文だろーが
やたら人を見下した態度をとっているが、具体的論理展開は全く無し。
典型的なチキンだな。

463 :名前は開発中のものです。:2009/01/07(水) 22:12:07 ID:rBsXmGd8
>>457
シーン遷移とシーン管理。
あれはひとつクラス作って使い方を決めときゃどんなゲームでも鉄板では?

464 :名前は開発中のものです。:2009/01/08(木) 00:12:58 ID:pmCaa13A
>>461
> じゃあ実際はどんなのが使われてるのか教えてください。
過去ログぐらい嫁

465 :名前は開発中のものです。:2009/01/08(木) 00:19:01 ID:XxumHwJp
上で議論した気にってるやつはC++を使いこなせてない。
不必要に全部のオブジェクトを1個のリストに乗せる必要もない。

Cとは縁を切るところからはじめるんだ。

466 :名前は開発中のものです。:2009/01/08(木) 00:46:34 ID:4sBQ+VSz
ただの倉庫ならどう作っても同じ
俺たちが作りたいのは電動車庫なんだ

ボタンを押せば欲しいものが出てくる仕組み
Javaではリスナー、Cではタスクシステム、C++ならコンテナ、DelphiならTList
みんな完璧じゃないけど一工夫してある

ただの線形リストとタスクシステムの違いはデータにメッセージを送ると能動的に処理が走ること
プログラム側からデータを触ってやらないといけない線形リストだとデータがグローバル変数と
同じように扱われ保守性が落ちる

タスクリストはただの線形リストではない

467 :名前は開発中のものです。:2009/01/08(木) 02:59:34 ID:B6I28cqd
>>464
過去ログ読んでも同じような煽りしか無いじゃないかw

468 :名前は開発中のものです。:2009/01/08(木) 05:04:27 ID:VWBWdLMf
>>466
ただの線形リストでも要素がクラスインスタンスなら、その「タスクシステムの違い」ってのは
無くなるね。

469 :名前は開発中のものです。:2009/01/08(木) 07:36:03 ID:+JWwjlC0
>>466
何言ってるかわかんない
結局ありがちなごった煮リストなんだろ?
違いをもたせるなよ(笑)

470 :名前は開発中のものです。:2009/01/08(木) 22:56:20 ID:XxumHwJp
>>469
おまえはまずデザパタとエフェクティブC++を読め。

471 :名前は開発中のものです。:2009/01/08(木) 22:58:05 ID:7CpFpz4u
>>470
やだよ
そんなの役に立たないもん

472 :名前は開発中のものです。:2009/01/08(木) 23:00:27 ID:8VoEuW6w
ニートは金ないから本薦めるても無駄

473 :名前は開発中のものです。:2009/01/08(木) 23:03:23 ID:4sBQ+VSz
デザパタは結城浩さんのがわかりやすくていいな

474 :名前は開発中のものです。:2009/01/08(木) 23:10:47 ID:7CpFpz4u
デザパタ自体俺の理論と合わない
ああいうごちゃごちゃしたソース組んで悦に浸ってるのは下手っぴ

475 :名前は開発中のものです。:2009/01/08(木) 23:57:46 ID:LE+aMQpC
開発遅延中の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(・・・)

476 :名前は開発中のものです。:2009/01/09(金) 00:37:39 ID:C9mB370D
>>475←こいつNG余裕でした

477 :名前は開発中のものです。:2009/01/09(金) 09:13:46 ID:u9nYazWS
>>466
コードで語ってくれ

478 :名前は開発中のものです。:2009/01/10(土) 02:10:09 ID:Jush8tf+


479 :名前は開発中のものです。:2009/01/10(土) 03:01:45 ID:1Stepbtb


480 :名前は開発中のものです。:2009/01/10(土) 07:10:36 ID:jT7iIe5T


481 :名前は開発中のものです。:2009/01/10(土) 19:24:56 ID:qAPK1zVY


482 :名前は開発中のものです。:2009/01/10(土) 22:56:42 ID:s6hcDJwE
ん!?

483 :名前は開発中のものです。:2009/01/10(土) 23:27:35 ID:GXwf3cbn
>>471
読まずに役に立たないだと?

EffectiveC++が役に立たないというならおまえがC++をまったく
使えてないか完全に仕様を理解しているのどちらかでしかない。

C++を理解してデザパタイランというなら頭おかしい。
そのまま流用する必要は無いが、似たようなものを作ることになるのは目に見えてる。

484 :名前は開発中のものです。:2009/01/10(土) 23:41:41 ID:s6hcDJwE
>>483
>EffectiveC++が役に立たないというならおまえがC++をまったく
>C++を理解してデザパタイランというなら頭おかしい
これ好きな人ってだいたいセットで好きだよね

ただ、毎回「これ駄目っていう奴は馬鹿」みたいな雰囲気あるから言わなかったけど
正直、これ何がいいの?って思うようになった

俺もはじめの頃はC言語勉強してそのままC++に来て
仕事でC++で組んでるけど正直、クラスのメリットってよくわかんないんだよね

っていうかよくわからなくなった
ちなみにプログラム経験12〜13年
C言語とC++では仕事ではC++しか使ったことない

>C++を理解してデザパタイランというなら頭おかしい
そうか?
具体的に何がいいの?
俺は実際に使いたがる奴の行動見てたけど
なんでそんな無駄な構造にしたのか上司と衝突ばっかり起こしてて苦労が多そうな奴だなと思った

485 :名前は開発中のものです。:2009/01/10(土) 23:58:22 ID:GXwf3cbn
ダメなやつが使ってるからダメとかいったら何も残らないじゃない。
C言語ではダメなやつは苦労してないの?

どう使えばよいか判らないといってると理解したけども、それでいいのかな?

ユーザーがアクセスできない関数や変数を構造体にもてるだけでも十分メリットだと思うけど。
仕事で頼まれているモノはそうやって制限されてない? 使う側の工夫って使われる側には
見えないものなのよね。

486 :名前は開発中のものです。:2009/01/11(日) 00:05:02 ID:ais0z/HY
あ、でもイラネって言ってるやつに無理に使ってもらう言語でもないな。
アセンブラに慣れてたら、Cを覚える必要ないわ。

487 :名前は開発中のものです。:2009/01/11(日) 00:30:04 ID:jCALDk/l
>>485-486
なんの説明もしてないの自分でわかるよね?
他の奴等もだいたいこんな感じで逃げる
それかわけのわからんリンク貼って終了

書籍読んでもこれがこうよくなるって言ってもそのメリットがメリットに感じないし
C言語で書いたソースとC++で書いたソースを比べると
意外とC言語で書いたソースのほうがよく見えたりするよ
ていうかほとんどの場合、大して変わらない

488 :名前は開発中のものです。:2009/01/11(日) 00:49:50 ID:5Rm3xSEN
それはどういう分野のソフトウェアを作ってるかによる。
例えばコールバックを多用するフレームワークを扱う場合はCでは面倒すぎる。
しかし昨今のコンシューマゲームでさえC++で開発が当たり前だ。
多分問題はオブジェクト指向原理主義的な野郎がいるってことだろう。

489 :名前は開発中のものです。:2009/01/11(日) 01:30:49 ID:dWwzUAmX
>>486
アクセス制限とデザパタとは関係ないような。
簡単に構造が説明できる(直感的に理解出来る)、非常に良く使われる構造である、統一的に機能を追加できる(またはそのようにする、そして楽)
のうち最低でもいずれかが実現できてることがデザパタの意義・・・かな?
逆に、これがどれも実現できてないのにデザパタ使いました、では
たとえパターンの構造通りになっていたり、また適切にアクセス制限がされていても本質からずれてる。

>>484の>なんでそんな無駄な構造にしたのか上司と衝突ばっかり起こしてて苦労が多そうな奴だなと思った
ってのもなんか多そう。中途半端に理解したデザパタは一番の害悪。果たして他人にぱっと説明できるのかと。

と、中途半端にデザパタを読んだ自分が言ってみる。




490 :名前は開発中のものです。:2009/01/11(日) 01:49:21 ID:WvjcdK6D
デザパタか
strategy? ああ、lambdaと高階関数に珍妙な名前つけた奴ね
って奴にはまあ要らねーのかもな

Cは面倒くさいだろ流石に
と思うが、C++はC++で別の意味で面倒くさいんだよな
大して表現力ねーくせに無駄に複雑でな


491 :名前は開発中のものです。:2009/01/11(日) 09:05:10 ID:9uopTdxy
>>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;


492 :名前は開発中のものです。:2009/01/11(日) 14:05:48 ID:JZO5iyFx
自分はいわゆるタスクシステムがどんな構造なのかよくわからんので色々気になったので読んでみた。
>>2のサイト先だと単なる動的配列(リスト構造)。別に『優先順位つきリスト構造』で説明が事足りる。
(全体長を固定する・またはノード自体をnewすることストを抑えたいならリスト構造2つ。事実上メモリ監視がついて回るのでこうなるが。)
で、色々読んでるといわゆるタスクシステムでは構造自体が重要なのではなく、メモリ使用の監視が主題ってのはなんとなくわかった。
だからメモリ監視にかかわる構造が必要でリスト構造に比べ多少複雑になってる、と。

つまりタスクシステムは

・ゲームを管理する構造△
・メモリの使用量など監視する構造○

タスクシステム自体の話は以上で完結するのよね。

タスク同士間の情報のやり取りやイベントハンドラ云々ってのはタスクシステム自体の話じゃなくて、
リスト構造で管理したときそれぞれのノード間のやりとりをどう管理するかって話でしょ?ふと思った。

493 :名前は開発中のものです。:2009/01/11(日) 17:12:30 ID:9uopTdxy
仮にタスクシステムの主題がメモリ管理だとして、じゃあタスクシステムから主題じゃないはずのタスクの概念を取り除いたら後に残ったものは果たしてタスクシステム?
メモリ管理システムでは?

メモリ単位管理システムと処理単位管理システムがもともと癒着しているタスクシステムというものを選択した時点で、既にタスクとかノードという概念の使用を選択したことになっている。
ノードという概念の使用を強制されるならノード間のやりとりをどう管理するかの検討も必須の話かなぁとか。

494 :名前は開発中のものです。:2009/01/11(日) 18:57:05 ID:JZO5iyFx
>>493
もちろん。
ただ、どうもこのスレはタスクシステムのどこの仕様決まりきってて、決まりきってないどこを議論すべきなのかが混沌としてるから。

例えばこのスレでもずっとタスクシステムはリスト構造じゃねぇ、という意見が殆どを占めていて俺リスト乙。的な流れが多い。
確かにタスクシステムはリスト構造ではない、は正しいが、
ノード間のやり取りを議論しようとしたら、リスト構造を踏まえて、というかハードを意識しなければリスト構造なのでそこで語るのは正解。
つまりその手の話は俺リストの話をするべき。




495 :名前は開発中のものです。:2009/01/11(日) 22:14:53 ID:9uopTdxy
>>494
「ノード間のやり取りを議論しようとするならその前にまずは俺リストの話をするべき。」
と受け取ったけど、ノードから見た通信インタフェースなんて
  1.グローバル変数直接アクセス
  2.メッセージングとかイベントハンドラ的な仕組み
  3.move, update, drawなど数を絞った仮想関数インタフェース
の3つ位しか思いつかない。しかも2, 3は表現が違うだけでやってることは等価だと思うので実質1もしくは2・3の2種類のみ。
グローバル変数を使用禁止とするなら2・3の手法一択。

乱暴に言えば、タスクシステムの意義は2・3をゲームオブジェクト単位に導入することを強制する意義と等価だとして話を絞ってしまえば
どのようななんちゃって俺タスクシステム・俺リストを使っていようが全く関係無く話できると思う。っていうか話終わると思う。
もっとおおざっぱに行こうじぇ

496 :名前は開発中のものです。:2009/01/11(日) 23:18:26 ID:JZO5iyFx
だよなぁ・・・。
うちら2人だけじゃいまいち不安だが、タスクシステムに関することってそんな感じだよね。

・タスクシステムはメモリ管理機能のある優先順位つきリスト構造
→メモリ管理およびリスト構造自体は決まりきった構造なので議論の余地なし。
→リスト構造のノード間のやり取りもメソッド等の使用であることは自明。

となるとかなりの部分はソースコードとして確定できそう。


で、まだでてきてない部分はこんなところか。
・具体的なメソッドややり取りはどのように管理するべきか。
煮詰めりゃ最適解は出せそう。

・タスクは別のタスクを追加しうる。生成したタスクはどうリスト構造に渡すか。
1、処理関数の戻り値として。追加の仕方はリスト構造自体を処理している誰かに委ねる。
2_A、リスト構造をタスク内でフィールドで保持。
2_B、処理関数がリスト構造自体を引数にとって内部で処理。
まぁ、2_Bが好きです、私は。

・タスクは例えばどんな塊なのか、どんなインタフェースを持つべきなのか。
これは色々考えられそう。
シーン管理はリスト構造の外側でしてるとして、他は全部リスト構造内で処理していると思いたい。優先順位機能搭載してるわけだし。
こっちも煮詰めりゃある程度解がでそう。

497 :名前は開発中のものです。:2009/01/11(日) 23:41:44 ID:KHFLxZhg
いや、普通に C++ で仮想関数とコンテナ使って組めって。
もっと言うと、コンテナにする必要だって常にあるわけじゃない。
普通にメンバに持ってれば十分、っていうかそっちのほうがわかりやすいこともあるだろ。

そうでないなら、「タスクシステム」とやらで解決される問題を挙げてから話してくれないか?

498 :名前は開発中のものです。:2009/01/12(月) 00:34:41 ID:T/lMy2Ww
>>496
俺はタスクシステムやめとけ派
タスク化をゲームオブジェクト単位に導入することを強制する意義は無いと思う。
メソッドの数を絞らなきゃいけないのがきつい。その最大最悪の制約の解消の目処も立ってないうちから
他の特徴を生かす方向を先に検討するとかは順序が違うと思う。

メモリ管理が重要じゃなくなったのならタスクシステムやめてそれ以前に戻るとか、
タスク化の適用対象をゲームオブジェクト以外にするとどうなるかとか考えて、まずは最大の制約を取り除くのが先じゃない?
ここがダメなら他の機能の利点なんて全部ふっとぶ凶悪な制約だと思うよ>通信の抽象化&全体共通化強制

例えばフレームワークの内部実装だけに適用する。
例えばもっとたくさん、座標管理(なんちゃって)タスクシステム、当たり判定管理(なんちゃって)タスクシステム、UI管理(なんちゃって)タスクシステム、...を作って組み合わせる。
例えばシーンと呼ばれる枠組みだけに適用してみるなどなど考えてくと、タスクシステムという形を残す必然性がなくなった。俺の場合。

499 :名前は開発中のものです。:2009/01/12(月) 02:16:26 ID:P3+dQgwK
というかC++はタスクシステムをさらに豪華にしたものだからC++を極めろ。

500 :名前は開発中のものです。:2009/01/12(月) 03:55:30 ID:xzGcGgfT
>>498
タスクを管理するクラスからの呼び出しだけ同じにしておけば、
別にメソッドの数を絞る必要はないと思うけど。

501 :名前は開発中のものです。:2009/01/12(月) 06:10:14 ID:koxxWPGt
一番シンプルな形がいわゆるタスクシステムで、
それをそのまま使ってる人はいないんじゃないの?

502 :名前は開発中のものです。:2009/01/12(月) 12:58:51 ID:YXD0YS+N
>>498,501見たいな流れに持ってくから話題がループするんだろ

>>498
色々勘違いしてるし、いってる意味がわからん部分がある。
1、タスクシステムの是非についてまったく話していない。結局タスクシステムの定番の形がどんな形なのかというのが知りたい。まだ定番の形は決定できる部分があるだろう。
2、順序が違う周りは何がどう違うのかさっぱりわからない。少なくともoopの設計の仕方ならば、オブジェクトを先になんとなくまとめ、メッセージを決めていくのもありなのだが。
それともいきなりソースコードレベルでびしっと決めるつもりだろうか?
3、ゲームオブジェクトでは抽象的過ぎる。それに含まれる具体例が最低3つぐらいあげてほしい。この定義により恐ろしいほど処理の範疇が変わる。
4、メモリ管理周りの話。何度もいうように、リスト構造のやり取りについて語ってる。タスクシステムについて語っていないと思う。まぁこちらの言い方も悪かったか。

それはそうとして、最後の話の構造、あれ思ったより拡張性低くね?仕様変更に迫られたときに耐えられないべ。
本来プログラムの構造はマトリョーシカ状にして、設計の修正が必要な場合の修正項目を最小限に抑えるべきだと思うんだが、ありゃ管理クラスが色々やりすぎてる気がする。

>>500
よくやる。つまりnode.run()みたいに一枚はさんでから、具体的な処理構造を実行するってことか。

>>501
多分この意見もかなりこのスレの流れでループしてるんじゃ無かろうか。だからもう少し話を進めて確定したい。






503 :名前は開発中のものです。:2009/01/12(月) 20:03:59 ID:a2k+/ICz
ID:JZO5iyFx = ID:YXD0YS+N  なのか?なんか至る所がおかしいな

>>492
>>2のサイト先だと単なる動的配列(リスト構造)

どこが動的配列なのか分からない。インターフェースも実装も動的配列ではない。

>構造自体が重要なのではなく、メモリ使用の監視が主題ってのはなんとなくわかった。
>だからメモリ監視にかかわる構造が必要でリスト構造に比べ多少複雑になってる、と。

悪いが意味が分からない。何を読んでその結論に至ったのか、アンカーを全部列挙してくれ

>つまりタスクシステムは

>・ゲームを管理する構造△
>・メモリの使用量など監視する構造○

>タスクシステム自体の話は以上で完結するのよね。

ならばそれはただのメモリプールでありアロケータの一種であり、それ以上でもそれ以下でもなく
タスクシステムなどと名乗る理由は微塵もないわけだから、お前は速やかにタスクシステムという
呼称を使うのをやめたらどうなのか。なぜタスクシステムという何処の馬の骨かも分からない田舎侍の
ローカル用語に固執するのか理解できない


504 :名前は開発中のものです。:2009/01/12(月) 20:27:55 ID:a2k+/ICz
>>492
>タスク同士間の情報のやり取りやイベントハンドラ云々ってのはタスクシステム自体の話じゃなくて、
>リスト構造で管理したときそれぞれのノード間のやりとりをどう管理するかって話でしょ?ふと思った

悪いが何を言ってるのか全く意味が分からない。

マルチタスクシステムにおいてはタスクとはジョブステップでありシステム内部の処理単位だ。
「システム内部の処理単位」同士の通信手段が提供するのはマルチタスクシステムにおいては当然のこと。

にもかかわらずタスクシステムとかいうものにおいては
「それは関係ないから関係ないからタスクシステム自体の話じゃないから」という。全部ユーザーに丸投げか。
ならばなんなのそれは。ってことだな。ジョブエントリのリストをなめてディスパッチしていく。ただの順次処理、
バッチ処理するだけの仕組み。それだけ。後は全部ユーザーまかせ

   【タスクシステム自体の話は以上で完結するのよね】

505 :名前は開発中のものです。:2009/01/12(月) 20:37:00 ID:a2k+/ICz
>>493
>ただ、どうもこのスレはタスクシステムのどこの仕様決まりきってて、決まりきってないどこを議論すべきなのかが混沌としてるから。

だから>>2だろ。書籍なら逆引き本だろ。現場を経験した人間が解説してる唯一の文献だ。

>例えばこのスレでもずっとタスクシステムはリスト構造じゃねぇ、という意見が殆どを占めていて
>確かにタスクシステムはリスト構造ではない、は正しいが、

どこをどう見ても>>2が使ってるのはintrusiveな(侵入式の、内部収納の)連結リストだが
リスト構造じゃねぇとかほざいてる知的障害のアンカー全部列挙してくれ

506 :名前は開発中のものです。:2009/01/12(月) 20:39:17 ID:t/KJWxMy
それでいいんじゃないの?
そもそもタスクシステムが何のために出てきたのか、目的がなんなのかで話がぜんぜん異なる。

507 :名前は開発中のものです。:2009/01/12(月) 20:47:23 ID:a2k+/ICz
×>>493
>>494

>ノード間のやり取りを議論しようとしたら、リスト構造を踏まえて、というかハードを意識しなければリスト構造なのでそこで語るのは正解。
>つまりその手の話は俺リストの話をするべき。

ハードを意識するも糞も何も>>2も逆引き本も連結リスト使ってるだろ。
正解も何も連結リストでしか語ってねーよ。馬鹿みたいに何でもかんでも線形リスト。木もグラフもない。
連結リストを使ってないタスクシステムに関する資料、文献がどこにあるのか教えてくれ



508 :名前は開発中のものです。:2009/01/12(月) 21:00:12 ID:a2k+/ICz
>>496
>・タスクシステムはメモリ管理機能のある優先順位つきリスト構造
>→メモリ管理およびリスト構造自体は決まりきった構造なので議論の余地なし。
>→リスト構造のノード間のやり取りもメソッド等の使用であることは自明。

>となるとかなりの部分はソースコードとして確定できそう。

【メモリ管理機能のある優先順位つきリスト構造】

それが現代のビデオゲームの中核部として【自己主張する】に相応しいメカニズムだと思う?
そういうものにタスクシステムって名前は釣り合うと思う?名は体を成してると思う?
そもそも名前が致命的に腐ってると思わない?タスク-システムだよ?
仕事システム?システム内部の処理単位システム?ハァ?って感じだよな
マルチでもなければシングルでもない。何なのお前?何がしたいの?って感じしない?



ワークロードをモニターできないしデッドラインに間に合うようにスケジューリングする仕組みもない
ゴミだろ。




509 :名前は開発中のものです。:2009/01/12(月) 21:32:14 ID:a2k+/ICz
>>496
>・具体的なメソッドややり取りはどのように管理するべきか。
>煮詰めりゃ最適解は出せそう。

おそらく出ない。タスクシステムが常に敗北するのは、あらゆる粒度の処理に対して同じインターフェースどころか
同じ実装でもって全て解決してしまおうとする、極めて理想主義・原理主義的なアホ共の玩具に成り下がったことに
由来する。処理の粒度に応じて解は異なるということに気づかない限り、ハードを無視した机上の議論で終わる

例えば細粒度な処理をディスパッチするためにタスク厨はなぜかサブルーチンアドレス経由で処理を呼ぶ。
現代においてはちょっと珍しい発想だ。本来ならステートメントを使うべきでありこれはif文やswitch-case文。
タスク厨が完全に時代に乗り遅れたフェードアウトオヤジ状態であることが完全確実に決定的なのは
関数アドレス経由の関数呼び出しが常に最高に速いと思い込んでることだ

一事が万事、それ以外のことも8bitマイコン時代の常識を現代に適用とするはず

ところでOO厨とタスク厨の親和性が極めて高いというのも面白いよね。静的型付け言語のセオリーをまっこうから
否定する>>2を、OO厨は「斬新だ」と感じるらしい。理解できない世界だよね


510 :名前は開発中のものです。:2009/01/12(月) 21:41:05 ID:YXD0YS+N
>>504
こっちも話の進め方が悪かったけど、まったくといっていいほどこっちのいいたい事、主題にしたいことが伝わってないことはわかる。
俺説明下手かなぁ・・・。

とりあえず技術的な部分だけ。

・動的配列は、要素数が自由に変更できる配列である。リスト構造は動的配列とみなせる。と思ってるが。
・メモリ云々に関して。>>2の4番目のサイトとか?つまり当時クラスを使用しない実装において、ワークエリア固定は、ただの副産物だったのか。ということ。


他は、まぁ読み返してこっちがいいたかったことを察してくれ、多分それで解決する。めんどい。



511 :名前は開発中のものです。:2009/01/12(月) 21:55:48 ID:YXD0YS+N
>>509
そこに誰もがうすうす感じてるから進まないんだろう、話が。
あらゆる処理、をかなり狭めることで最適解というか妥協解は示せると思うよ。

512 :名前は開発中のものです。:2009/01/12(月) 22:02:46 ID:a2k+/ICz
>>510
動的配列を実装する選択肢のひとつは連結リストを使うこと
だが、>>2のインターフェースは動的配列ではない。

リストだが動的配列ではない

513 :名前は開発中のものです。:2009/01/12(月) 22:09:05 ID:a2k+/ICz
タスクシステムという言葉を使い続ける限り、そいつの背後には>>2に代表される
時代錯誤的なヘッポコプログラムの影が常に付きまとう。これはもはや不可避だ
このレッテル貼りを早い段階から否定しなかった「タスクシステム大好き人間」の
落ち度だ。(おそらく彼らは>>2が現実と乖離してるということに気づいていなかった)

>>2から脱却した議論がしたいならタスクシステムという言葉を使うのをやめ
このスレを使うのをやめるべきだ。構造スレなら俺も別人になれる

514 :名前は開発中のものです。:2009/01/12(月) 22:15:32 ID:a2k+/ICz
>>512補足
実装においても、当時のハードウェア構成から固定長メモリプールが多用された
ゆえに実装レベルでも動的配列とはいえない。ヒープという概念がないRAMちょびっとの
ハードで動的配列を提供することに意味はないし、>>2もやってない

515 :名前は開発中のものです。:2009/01/12(月) 22:26:42 ID:a2k+/ICz
>>496
>まぁ、2_Bが好きです、私は。

それは構わない。
が、システムと銘打ってるにも関わらず、ユーザーにシステム側の実装を周知しなければならない。
つまりユーザーは、自分が記述したジョブをシステム内部の処理単位であるタスクなるものに分割し
それが格納されるシステム内部のコンテナが連結リストであることを知る必要があり、更にそれを
直接に操作することを強要される

2_Bなら、システムが提供するのはintrusiveな連結リストのコンテナだけであり、後の全ては
ユーザーの創意工夫で構築される。「俺はシステムだ!」と主張させるには無理がある



516 :名前は開発中のものです。:2009/01/12(月) 22:27:30 ID:T/lMy2Ww
>>500
絞る必要は無いんだけど、結果的に意図せずとも数絞っちゃうというか。
メソッド変更の度に全タスク修正するの面倒になってそのうち必要最小限でいいやとか思い始める。
「update(), draw()だけあればいいや。おっなんか洗練された感じ?」とか。で1〜3つ位に絞られる。

517 :名前は開発中のものです。:2009/01/12(月) 22:42:32 ID:a2k+/ICz
>>516
非常に的を射ているような気がする

無理になんでもかんでも共用し一般化しようとする結果、肉も骨も削る人間がいる。
直行性だの何だのは結構なのだが、それを過剰に追求するからおかしくなる。
肉も骨も削って何がなんだか分からなくなったものを作り上げた人間は
>>2にシンパシーを感じ、これを愛するのではないか

「俺は間違ってない!過去のナ○コの偉大なプログラマーも俺と同じことやってる!」


いいえ、それは違います。ということは今更指摘するまでもないよな


518 :名前は開発中のものです。:2009/01/12(月) 22:44:57 ID:pK6rJs4f
それはクラスに型があるが故の制限だろ?
タスクシステムに責任を押し付ける筋合いの物じゃないと思うが……。
クラスでやるにしてもEventListener interface風に実装する等回避策はある。
(タスクシステムはクラスと違って記憶領域と関数が1対1で対応する必要もないし)

どうも副次的な制限ばかりでタスクシステムの本題に入らないな。
行き当たりばったりに実装してみて行き詰ったら「タスクシステムが悪い」となっている風に見える。

タスクシステムは何をするべきか、何をさせるべきか。
それをキッチリ決めてからじゃないと
実装してから利点を探すような真似は生産的じゃないと思うんだぜ?

タスク管理の実装に必要なものは



だから〜という実装は有効

みたいにしようぜ
必要は発明の母っていうし新タスクシステム開発できたら素敵やん?

519 :名前は開発中のものです。:2009/01/12(月) 22:46:17 ID:pK6rJs4f
ところでDOOMやQUAKE等一線級のゲームソースがオープンソースとして公開されているけど
タスク管理はどのような実装になっているんだぜ?

520 :名前は開発中のものです。:2009/01/12(月) 22:56:18 ID:a2k+/ICz
>>518
2009年現在、ネット上ではタスクシステムというキーワードは>>2に代表される
珍妙実装と絡み合ってる。実装ありきだ。これを今更否定するのは至難だと思うよ

彼らは何故か2DSTGで、通常弾も敵も何もかも全部同じリストにぶち込んで舐める。

否定するならば、Cマガジンで松浦大先生(タスクシステムエヴァンジェリスト)が
下々の民草に対して「プロのゲームプログラマはこうやってるのぜ!」と絶叫した
(2001年だっけ?)時点で、大々的に反抗作戦を展開するべきだったな

521 :名前は開発中のものです。:2009/01/12(月) 23:10:15 ID:7ba28WIc
>>520
当時は「なんだこいつ馬鹿じゃね? こんなの誰も信じねーよ」と思ってて
こんなに厨が拡大再生産されるとは微塵も思ってなかったんだ…

522 :名前は開発中のものです。:2009/01/12(月) 23:11:20 ID:T/lMy2Ww
>>502
1.タスクシステムの是非 = タスク化をゲームオブジェクト単位に導入することを強制することの是非
 ちょっと分かりにくいか。
 タスクシステムの是非 = 既定のメソッド2〜3個だけしかゲームオブジェクトに使用できない呪いを自らに課す是非
 でも可。1クラス決まった型のメソッド3個までしか使えないんだよ?極悪すぐる。この1点を問題ないと言い切れるならもう習うより慣れろかもね。
 後付けだけど条件。グローバル変数は無し。引数で全変数一気渡しも無し。
2.見た目がどんなにおいしいそうなものでも、腐ってたら食べないでしょ?
 その腐ってる点を指摘したつもり。どれだけあなたがおいしいところの話をしようよといっても腐ってると分かってる人はそんな気になれない。
 どうせ食べたら腹壊すって分かってて無駄だから。ふぐの毒に置き換えてもいい。
 それでもそのおいしそうなものについて議論したいならまずは腐ってるとこを取り除く努力をして安全性をアピールするのが先。おいしいとこ議論はその後、の順の方が人が集まりやすい。
 >少なくともoopの設計の仕方ならば、オブジェクトを先になんとなくまとめ、メッセージを決めていくのもありなのだが。
 タスク、リスト構造のやり取り等を先になんとなく以上の熱意で明確化しようとしている矛盾
3.STGで言えば自機、敵機、自機弾、敵機弾、ボス、背景オブジェクト、...
 ミニゲーム1つでいいから作ってみると、なるほど使ってみたくなる言葉
4. >>504 さんの言う通り

>本来プログラムの構造はマトリョーシカ状にして、
外から3番目の人形と8番目、あっ違った、今は9番目の人形同士で情報やりとりしたいんだ。
ってデザイナーに言われたらどうするの? 4-8番目の人形に専用のメソッド用意して穴あけるの? グローバル変数で空間ワープするの? いや、この設計では無理って言うの?
ライブラリラッパー関数までだよ、それは。俺はシーンクラスに色々やらせる方がかっこいいと思う。ダサかっこいい。昔ながらのKISS.

説明下手は少しあるけどまぁ伝わる。それよりも聞き下手。
察した上でそれを主題にすべきでないと理由付きで伝えてくれてる親切な人だらけだよ。今日は。人多いっしょ? 俺もびっくりだこれ。
多分それ気づかないと解決しない。

523 :名前は開発中のものです。:2009/01/12(月) 23:19:32 ID:xzGcGgfT
>>516
えーと、俺が言いたいのは、管理クラスから呼ばれるメソッドさえ共通にしておけば、
それぞれのクラス毎に、それぞれのクラス特有のメソッドを追加しても問題ないってことなんだけど。
1つのクラスに修正が生じたからといって、全てのクラスを修正する必要はないよ。

524 :名前は開発中のものです。:2009/01/12(月) 23:24:44 ID:QJH1xa2h
現状は>>498が言うことがすべてだよなぁ
折角わかりやすいのに>>502の的外れな指摘がなーんか嫌な感じだよ
意味がわからない
お前の言ってることのが意味分からないよ
ほぼ共通してる認識をわざとはぐらかしてる

525 :名前は開発中のものです。:2009/01/12(月) 23:28:36 ID:QJH1xa2h
>>523
ごった煮状態のインスタンスの型をどうやって判別する気?

526 :名前は開発中のものです。:2009/01/12(月) 23:42:16 ID:mQRiv/2E
ダウンキャストか型タグでしょ

527 :名前は開発中のものです。:2009/01/12(月) 23:43:05 ID:mQRiv/2E
×ダウンキャスト
○dynamic_cast<>
ね、すまん

528 :名前は開発中のものです。:2009/01/12(月) 23:43:27 ID:YXD0YS+N
>>512,514
把握。でもリスト長は変わってるから動的配列と呼べなくも無いと思うが・・・まぁどうでもいいや。重要ではない。

ところでa2k+/ICzよ、自分でいってるじゃないか。

>>513で。当時制限があった、ゆえにメモリ管理が必要だった。それがタスクシステムだ。時代錯誤だ。
だから『タスクシステムの主題がメモリ管理』は外れちゃいないと思う。

>>515で。タスクシステムからメモリ管理を取り除いたら、リスト構造しか残らない。タスクシステム特有の部分は議論する余地がない。
だから俺リストについて語るべきなんじゃん。

>>520で。結局タスクシステムって言葉を使い続ける限り、メモリ管理+リスト構造しないとだめなんだよ。
だからその片割れであるリスト構造について語ろうっていってるわけだよ。
(まー自分がゲーム作る場合、メモリ管理とかいらんからほんとにリスト構造だけだけど。利用できそうな方向に話を持っていきたいだけ。)

ごめんなさい、結論としては具体的なノードのやり取りとか、どんな処理がノードとなるのか、とかそんな話がしたかっただけです。



529 :名前は開発中のものです。:2009/01/12(月) 23:49:34 ID:xzGcGgfT
>>525
最初から、必要とするクラスのメンバ変数にしておけばいい。
一旦抽象化してリストに入れたものを取り出して型を判別する必要はないと思う。
まあ、管理クラスに探してもらってdynamic_castでもいいけど。

530 :名前は開発中のものです。:2009/01/12(月) 23:49:39 ID:j7EcMyl2
というかa2k+/ICzの言うタスク厨ってここにいるの?
いないもの相手に頑張っても意味ないよ

531 :名前は開発中のものです。:2009/01/13(火) 00:01:05 ID:BJ2f3Qgk
読むのが追いつかん・・・
>>522
>聞き下手。あぁ理解。>>524のその通り。ごめんなさい。今度から何度かちゃんと読み直します。
となると、話の流れは>>498から>>523とつながってるのか。

532 :名前は開発中のものです。:2009/01/13(火) 00:08:34 ID:cTPRSXgj
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をゲームオブジェクトごとに書かなくて済むただそれだけ

536 :名前は開発中のものです。:2009/01/13(火) 00:49:41 ID:IILw8mY9
>>534
何が言いたいのか分からない。
管理クラスはupdate関数を呼ぶだけだし、呼ばれたほうは自分自身が何者かを知ってる。


537 :名前は開発中のものです。:2009/01/13(火) 00:50:45 ID:e/Buzpeu
何もないわけないだろう。ないならこんなに大騒ぎするはずないじゃん

538 :名前は開発中のものです。:2009/01/13(火) 00:53:10 ID:e/Buzpeu
かつての制限ありまくりのハードではっての前提ならなんかいいことあるんじゃないの?

539 :名前は開発中のものです。:2009/01/13(火) 01:01:17 ID:rWb6fNii
>>534
は?
ごった煮リストから判別して特有の処理を呼び出す話をしてるんだよ
なんで共通のupdateの話をするの?

540 :名前は開発中のものです。:2009/01/13(火) 01:05:48 ID:rWb6fNii
>>537ー538
あると思うならそれをいうべきだろ
ただ、あるんじゃないの?って認識の人が書き込む場面ではないだろ

541 :名前は開発中のものです。:2009/01/13(火) 01:13:01 ID:IILw8mY9
>>539
必要な分はリストに入れる前にあらかじめメンバ変数として持っておくんだよ。
わざわざリストから取り出す必要はないし、型を改めて判別する必要もない。
リストから取り出すならdynamic_castだとも書いてある。
同じこと書かせないでくれ。分からない部分があるならそこをピンポイントで聞いてくれよ。

542 :名前は開発中のものです。:2009/01/13(火) 01:35:34 ID:e/Buzpeu
>>540
いやおれは>>497と同意見なだけだが

何をするためのものか整理してから話したら?ってこと

543 :名前は開発中のものです。:2009/01/13(火) 01:44:29 ID:O7y/5maD
>>530
タスク厨を定義するにはタスクシステムを定義しなければならないのだが
>2にしても書籍にしてもゆらぎが大きく、絶対的な権威も不在、
且つ個々の理解もばらばらでコンセンサスがとれないのが現状。
>520は松浦大先生を権威として祭上げたいみたいだけど
その話題に触れているのは今のところ>521だけ。

544 :名前は開発中のものです。:2009/01/13(火) 02:33:11 ID:Y5x2FIH6
>>530
いるいる。たーくさんいる。ここ5〜6年内はゲー専新卒の子だけじゃなくて
四大工学系新卒の子が説明会や集団面接で>>2を熱く語ったりする。臆面もなく。
他の子が目を白黒させてる。

沢山 : oO(え、ナニそれ?何?それ知ってないとヤヴァイ?あとでググろっと)
少数 : oO(プギャー)

など、様々な表情が観察できて面白い

まぁ最終段階で残る子はこんなもんこれっぽっちも知らなかったりするし
知ってても「だからナニ?」みたいな子ばっかだから
新人研修の段階で更生させる手間はゼロだしどうでもいいんだけどね

>>543
松浦御大の功績は認めるべきだよ。Cマガにおける特集記事とその後の連載記事
そして禿パブから出版された数々の書籍、これらによってタスクシステムという
呼称をその実装と共に伝道し、素人プログラマの間で爆発的に普及させた

それ以前にタスクシステムなんて単語を駆使する学生や子供は稀有だった。
X68界隈の草の根BBSみたいな閉じた狭いコミュニティでヲタ同士でコソコソ
やってただけ

松浦御大の教えに染まった子が増えたことで2DSTGを作る子も増えた。まぁ全てが悪いわけじゃない

545 :名前は開発中のものです。:2009/01/13(火) 03:10:52 ID:b0jQ54sW
>>544の前半
ニュースの映像でさえ本物かどうか疑わないといけない時代に
唐突にそんな逸話だけ出されてもねえ。
前にオカルトとかエセ科学とか言ってる人がいたからじゃないけど
検証可能性を担保できる話をしようよ。

546 :名前は開発中のものです。:2009/01/13(火) 07:57:07 ID:rWb6fNii
>>541
わかんねぇ奴だな
たとえばクラスAとBがあったときクラスBだけがもつmoveBメソッドを呼びたかったと
したらまずごった煮リストの取り出した要素がクラスAかBか判断する必要があんだろが
じゃねーとBにしかないメソッドなんだから呼べないだろ

547 :名前は開発中のものです。:2009/01/13(火) 08:35:28 ID:cnR3vXss
>>546
dynamic_cast の意味しらべるのオススメ

まあ、ゲーム開発だと RTTI はたいてい切ってるんだけどね

548 :名前は開発中のものです。:2009/01/13(火) 08:37:32 ID:cnR3vXss
ちょっと訂正。

ゲーム開発 → コンソールでのゲーム開発

360, PS3 世代ならもういいかも。


549 :名前は開発中のものです。:2009/01/13(火) 09:47:27 ID:ZKmCcGGs
タスクシステムなコードを昔見たとき

char data[256];

DataA *p = (Data A *)data;

こんな感じで領域確保してキャストして利用してたのは
C++から入った自分としてはへーと思ったな

550 :名前は開発中のものです。:2009/01/13(火) 10:08:51 ID:TI8LHl+M
頭悪い子のほうの撲殺天使の人暇だったんだな

551 :名前は開発中のものです。:2009/01/13(火) 10:43:44 ID:vYGbQe0C
>>539
>ごった煮リストから判別して特有の処理を呼び出す話をしてるんだよ
>なんで共通のupdateの話をするの?

>>546
>したらまずごった煮リストの取り出した要素がクラスAかBか
>判断する必要があんだろが
>じゃねーとBにしかないメソッドなんだから呼べないだろ

リストの個々のオブジェクトはupdateメソッドを保有している
で、そのupdateメソッドは自分が何者か知っているわけで
わざわざ型の判別をする必要はないだろ

552 :名前は開発中のものです。:2009/01/13(火) 10:58:08 ID:ZsPdzCtd
オブジェクト間の相互作用の話をしているんだと思うよ

相手が自明ならキャストは普通は要らない
敵の中で〜なもの、といった風に条件付でスキャンしたいのなら
型の判別とキャストがいるだろう

代数データ型が使える言語ならもっと型安全にヴァリアントな型を
扱えるが、C++なら結局はキャストするしかない

で、「ごった煮リスト」とは言うが、実際には例えばTaskだのGameObjectだの
というインタフェースを継承したクラス群になるわけだろうから
型を判別する方法なんぞいくらでもある

言語組み込み機能なら、何度も言われているようにdynamic_cast
そうでなければ、例えば自分が誰かを示すメソッド等を、統一したインタフェース
として持たせればいいだけだ
なんも難しい話じゃないはずだが

553 :名前は開発中のものです。:2009/01/13(火) 11:11:47 ID:BJ2f3Qgk
>>546
こっちの話はすぐわかるからいける。多分>>551はリストのノード自体が多態性してる。
ゲームオブジェクトをupdateのみを持つ別のクラスで包むか、
ゲームオブジェクト自体がupdateをもち、オーバーライドしてupdate内で自分のメンバを呼んでいるんだろう。

ところで、タスクですべきことがゲームオブジェクトのupdate、positionの取得、など個々の場合
>>491みたいなEventTaskでやるべきことを判別する必要がある・・・で合ってる?

554 :名前は開発中のものです。:2009/01/13(火) 11:38:16 ID:ZsPdzCtd
オブジェクトのグループ/階層がはっきりしているのなら
少なくともリストよりはツリーがいいように思う

全体も走査できるし
特定のグループに限定したいのなら、サブツリーを走査すればいい
フラットなリストでmap/filterを毎度やるよりは効率的だろう

多態とダウンキャストは、C++でOOやるなら宿命みたいなもんだから、
そこを突っ込んでみても仕方がない

555 :名前は開発中のものです。:2009/01/13(火) 12:52:30 ID:rWb6fNii
型の判別が必要ってのはいいかい?
全く同じメソッドもってたって型を判別する必要あるな
自機、敵、自弾、敵弾の内、敵と敵弾だけに絞りたい場合なんかも型を判別する必要あるよな
こんときやらなきゃいけないのは一斉検索だろ?
んで処理をするもんとしないもんといちいち判別しながら処理しないといけないわけよ
何が言いたいかってーと
ごった煮である利点は少ないよねってことよ

ツリーも惜しいけどそれでもやはり意味がない

続く

556 :名前は開発中のものです。:2009/01/13(火) 13:00:10 ID:ZsPdzCtd
>>555
「どうやって型を判別するんだよ」とか言ってるから
型なんか簡単に判別できるだろ、とだけ言っただけで
別にタスクシステムとやらを褒め称えてるわけじゃないんだけどね

ツリーも、少なくともフラットなリストよりはマシだろうってだけね

557 :名前は開発中のものです。:2009/01/13(火) 13:09:33 ID:dTl8CSoX
>ごった煮である利点は少ないよねってことよ
それはゲームによるでしょ
過去に作った横スクロールアクション、RPGでごった煮採用だが、全然困らん
逆にオブジェクトごとにリスト用意するのはメンドイ
ま、弾幕シューティングしか作らないような御仁は分けた方がいいのかもしれないな

558 :名前は開発中のものです。:2009/01/13(火) 13:17:38 ID:W8WRraB+
なんとなくすれちがいポイントがみえてきた

・入り口のメソッドだけあわせておけばあとはオブジェクトが自発的に処理すりゃいいだろ派

・オブジェクトの相互作用はまとめてかいたほうがいいだろJK。
 そうすると個別のオブジェクトの区別が必要だから1つに束ねると効率悪いだろ。

こんなかんじ?
まあ、両者ごもっとも。

俺なら今ならふつうに富豪的アプローチだな。
一連の処理を行う構造と、検索・相互作用用の構造は別の形でもったほうがいい。

・大枠は前者的思想でつくってメインループを回す。
 イベント処理>状態変更>画面更新
 とかそういう単位

・親に、自分以外のオブジェクトの検索をしやすいような辞書的構造を
 別途整備する。オブジェクトはこれを参照して自分の動作を決める

・複雑な処理は親の専用のロジックで辞書を直接総なめするような操作を
 作って、これ自体を処理オブジェクトとして一連の処理に投入するようにする

こんなかんじ?

559 :名前は開発中のものです。:2009/01/13(火) 13:28:07 ID:IILw8mY9
>>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関数を作るか……)は好きにしてくれ。

以降のレスは呼んでる暇がないので、既にフォローされてたらごめん。

560 :名前は開発中のものです。:2009/01/13(火) 13:49:36 ID:W8WRraB+
>>559
型判定の方法は論点じゃないから dynamic_cast の話は放置しておk

561 :名前は開発中のものです。:2009/01/13(火) 20:22:42 ID:rWb6fNii
まともな人がいて助かる
型の判別方法は問題じゃ無い

続き

結局、型は判別しなきゃいけないんだよ
だったら別にまとめることなくね?
まとめた処理がしたかったらそんときだけ必要なもんだけ入れたポインタリストでも作ればいいんじゃないの?
わざわざごった煮にする意味がわかんないね
次の行動にターゲットが必要になった時点で共通仕様の縛りのせいでかなり悩まなきゃいけないじゃん
グローバル変数使ったり、生きてるか死んでるか不明のポインタをゲームオブジェクトが保持るとかいう
かなりアフォな構造になるじゃん

562 :名前は開発中のものです。:2009/01/13(火) 20:39:48 ID:OyiDbbba
もうさ、タスクシステム勉強会を開いてそこで議論したほうがよくね?

563 :名前は開発中のものです。:2009/01/13(火) 21:15:46 ID:wPNmVciu
ごった煮にしなければいけないなんて決まりはない。
リスト、ツリーに色々種類があるのと同じ。
使いやすいように各自工夫すればいい。

564 :名前は開発中のものです。:2009/01/13(火) 22:38:35 ID:jI2d6wDl
>>563
結局、タスクシステムって何? どこまで「工夫」したら、タスクシステムじゃなくなるの?

565 :名前は開発中のものです。:2009/01/13(火) 22:42:14 ID:BhFnEm7r
単なる名称だからタスクシステムでもなんでもいいんだよね。
最近はフレームワークとか言ってる。

566 :名前は開発中のものです。:2009/01/13(火) 23:45:59 ID:qw2v5RK8
引数なくしてグローバル変数やシングルトンでやり取りされるのが一番困る
バグったら最後
誰もバグとれないくせに使い続けるんだもんなぁ・・・

567 :名前は開発中のものです。:2009/01/14(水) 00:48:21 ID:uviUrAzN
上位階層の改修を前提にするのは賛成しかねる

568 :523とか:2009/01/14(水) 01:11:41 ID:j8O4TfZ6
判別方法は関係ない?
>>525,534,539,546
俺には、一貫して型の判別方法を聞かれているようにしか読めなかったんだが。
じゃあ、俺は一体何について聞かれていたんだ?

569 :名前は開発中のものです。:2009/01/14(水) 01:22:41 ID:eV0+hChb
ポリモーフィズムのポの字も知らない馬鹿はスルーしろってことじゃねえの

570 :名前は開発中のものです。:2009/01/14(水) 01:45:38 ID:FCqVMcI1
>>525,534,539,546
特有の処理についてもっとkwsk

>>566
>引数なくしてグローバル変数やシングルトンでやり取りされるのが一番困る
何をやり取りされるのが困るかkwsk

571 :名前は開発中のものです。:2009/01/14(水) 03:06:10 ID:0DnXfUAy
>>568
うーん・・・たぶん。こういうことだろう。

>>561は、たとえば衝突判定とかするときに、結局型判定(というか属性判定)するじゃない。
たとえば自機と敵機が同じリスト構造内にいても、自機⇔敵機衝突判定するときに、
リスト構造内を検索、その際にゲームオブジェクトが自機なのか敵機なのか属性判定する事は避けられない。
といいたいんだと思う。

だから多態性とか継承とかとはまったく別の問題だよーってことじゃね。>>558見てわかった。


>・入り口のメソッドだけあわせておけばあとはオブジェクトが自発的に処理すりゃいいだろ派
これが俺や>>568が言ってたこと。

>・オブジェクトの相互作用はまとめてかいたほうがいいだろJK。
 そうすると個別のオブジェクトの区別が必要だから1つに束ねると効率悪いだろ。
これが>>561がいってたこと。

たぶん。

・敵リスト
・自機リスト
・背景リスト
みたく属性ごとにリストを分ければ、衝突判定等の記述がシンプルにかける。全部ごった煮にするとかけねーよってことか。




572 :名前は開発中のものです。:2009/01/14(水) 03:10:43 ID:j8O4TfZ6
なんだか同じことの繰り返しで対話にならないっぽいので、
他の人から何もなければひとまずこれで引くわ。

>>555
>自機、敵、自弾、敵弾の内、敵と敵弾だけに絞りたい場合なんかも型を判別する必要あるよな
最初から敵を管理するクラス、敵弾を管理するクラスを用意すればいい。
「タスク」レベルまで抽象化したものをわざわざ判別して取り出す必要はない。
使用頻度が低いとか、必要かどうか前もって分からないとかだったら、
後から取り出しても別に構わないとは思うけど。

>>561
>まとめた処理がしたかったらそんときだけ必要なもんだけ入れたポインタリストでも作ればいいんじゃないの?
これはそのとおり。タスクリストは「毎フレーム(優先度順に)処理関数を呼ぶ」
「親子関係を持ち、親が死ぬと子も死ぬ」処理を行うためのもの。
(メモリ管理云々は、個人的にはタスク処理とは別の話だと思う)
積極的に他の目的のために使おうとするからおかしなことになる。

>>561の後半は何が言いたいのかまったく分からん。
「次の行動にターゲットが必要にな」るってのはどういうこと?

生きてるか死んでるか不明のポインタって、まだ必要なポインタが
解放されてるかもってこと? それは構造関係なくただのバグじゃん。


ああ、念の為書いとくけど、別にタスクシステムを(他の方法より)
優れた方法だと言うつもりもないし、ましてや薦める意図はまったくないよ。
既に他の方法を確立しているならそれを使えばいいし、初心者なら
テクニックに走らず、ゲームの構造をそのままクラスにしたほうがいいと思う。
ただ、自分で制限つけたり、他の目的に使おうとしたりして、
「使いにくい」「利点がない」ってのはどうかと思っただけ。

573 :名前は開発中のものです。:2009/01/14(水) 04:33:34 ID:j8O4TfZ6
>>571
>>525がそういう意味だとは思えないし、もしそうだったとしても、それについては
「それを必要とするクラスのメンバ変数として持てば、判別の必要はない」と何度も答えてる。
もちろん、「敵の種類」とかの判別は必要になるだろうけど、
それは「ごった煮リストからの判別」とはまったく別の話だよね。

つか、「個別のオブジェクトの区別が必要だから1つに束ねると効率悪い」はそもそも順番が逆で、
同じように扱いたいから1つに束ねたのに、個別のオブジェクトに戻そうとするから効率が悪くなる。
それに、オブジェクトが自発的に(見えるように)updateするのと、そのupdate関数内で
関連するオブジェクトを(個別のオブジェクトとして)利用するのは、別に背反することじゃない。

574 :名前は開発中のものです。:2009/01/14(水) 06:12:22 ID:Db9o/NUw
>>572-573
長w
駄目だよ
レス自体誰も前提にもってない話が勝手に常識のように入ってるし
自分の妄想だけで話進めて俺と会話するつもりもない感じ
いいたいことまとめないとレスつけないよ

575 :名前は開発中のものです。:2009/01/14(水) 06:16:11 ID:Db9o/NUw
だいたい判別する必要あるじゃん
何がねぇんだよ
オブジェクト内に別オブジェクトの型なんかごちゃまぜにアクセスできたら
そもそもカプセル化も糞もねーじゃん
自機クラス内で敵クラスにも弾クラスにもアクセスできる時点でオブジェクト指向破綻してんじゃん
もう言ってることおかしい

576 :名前は開発中のものです。:2009/01/14(水) 08:54:18 ID:t2+2vepU
>>575
コンポジットというものがあってな
もうしょうがなからぺにっぺにっでにっしんさせるね

577 :名前は開発中のものです。:2009/01/14(水) 10:11:36 ID:eV0+hChb
OOスタイルで構文解析機を書けば「ごった煮」なASTになるわけだが……
DOMぐらい知らんのか?

まあ、dynamic_castすら知らないぐらいだから仕方がないね

578 :名前は開発中のものです。:2009/01/14(水) 14:21:56 ID:lc7Z4t3A
ごめん俺DOMナメてたわ




リックドム。なんちて

579 :名前は開発中のものです。:2009/01/14(水) 18:21:13 ID:rLaI4JeW
dynamic_cast未サポートのコンパイラが普通にあることすら知らないぐらいだから話合わないのも仕方がないね

580 :名前は開発中のものです。:2009/01/14(水) 18:27:56 ID:eV0+hChb
dynamic_castが使えないのなら、型タグに相当するものを実装すればいいだけだよ
Cのunionならいつもやることだろうに、アホか

581 :名前は開発中のものです。:2009/01/14(水) 19:02:01 ID:t2+2vepU
え?
そんなコンパイラをお使いで?
相当のマゾでつね
D どんなもんだい
O オレは
M マゾっ気100%だぜ

582 :名前は開発中のものです。:2009/01/14(水) 19:45:31 ID:rLaI4JeW
>>580
union使ったら型システムに穴が空くジャン
できることなら使わずきれいに済ませたいジャン

>>581
それはさすがに釣る気みなぎりすぎwww

583 :名前は開発中のものです。:2009/01/14(水) 20:15:23 ID:HVlDjb3P
また、全然関係無いレスばっかりつける
ちょっと前も型の判別方法なんて問題じゃないってのに
キャストキャスト連呼してる恥ずかしい奴がいたけどにたようなのしかいないのか?

584 :名前は開発中のものです。:2009/01/14(水) 20:44:37 ID:eV0+hChb
>>583
いや、それは>>525が「型の判別方法わからん」とか言ってるから
何人かが教えてやってただけだろ……

585 :名前は開発中のものです。:2009/01/14(水) 20:49:28 ID:eV0+hChb
>>582
Cなら仕方ないだろ
unionの類を使わずにLispインタプリタでも組んでみたらどうだ?

C++にしても、代数データ型はないのだし、ポリモーフィズムの手段が
継承なのだから、ダウンキャストはある程度宿命であり必要悪だ
無論、それを最低限に抑えることが望ましいがな

586 :名前は開発中のものです。:2009/01/14(水) 20:58:47 ID:HVlDjb3P
>>585
はぁ?なんのための必要悪なの?
そもそもベタ書きでゲーム作ったことあるのかすら怪しいね
だってゲーム作って複雑になるところとキャスト云々って全然関係無いもん

587 :名前は開発中のものです。:2009/01/14(水) 21:08:00 ID:rLaI4JeW
>>583
ごめんよ
以前dynamic_castが使えない環境でゲームプログラム書くことがあったから動的キャスト必須は移植性を考えるとありえないという頭があった。
あとunionは宗教上の理由で滅多に使えないので型タグ相当も小資源で作ることができない。これは俺のポリシー。
ライブラリ内なら使うかも。

そういう条件下だと性能の良し悪しとか概念の洗練度なんて議論とは全く別次元で、簡単に一意に解答が定まってしまう。
 「オブジェクト群を1つに束ねることは不可能」
って。
そういう立場の人もいるかもと頭の片隅にでも置いとくと怒りが安らぐかもしれない。

union使える宗教の人とかdynamic_cast使える環境が大前提の人にとっては有用な議論なんだろうなぁ、きっと。

588 :名前は開発中のものです。:2009/01/14(水) 21:16:40 ID:Db9o/NUw
>>584
それは>>523が特有のメソッドを追加しても問題ないっていうから
特有のメソッドを読んだら型判定が必要になって
ごった煮リストにしておくメリットねーぞって話のつもりだった

が、読み返してみるとたしかに型判定知らないアフォみたいだなwスマンコw
でも問題はそこじゃないんだ

589 :名前は開発中のものです。:2009/01/15(木) 09:09:38 ID:4Cibcxeg
>>572
> これはそのとおり。タスクリストは「毎フレーム(優先度順に)処理関数を呼ぶ」
> 「親子関係を持ち、親が死ぬと子も死ぬ」処理を行うためのもの。

それって、単に子インスタンスをメンバ変数で持つだけで良いんじゃね?

class Enemy;
class Player;
class Scene {
 Player player_;
 std::list<Enemy> enemies_;
public:
 void exec() { PlayerExec(); EnemyExec(); HitCheck(); ... }
};

タスクって何?

590 :名前は開発中のものです。:2009/01/15(木) 12:21:31 ID:etjpUhRT
>>587
なんだか俺がdynamic_cast云々の発端っぽいので一応言っておくけど。
dynamic_castは「型の判別方法」を聞かれたから答えただけで、
必要なものは元の型のままメンバ変数として持てば、
通常、dynamic_castが必要になる場面はないよ。

>>589
それでいいよ。
別にそういう書き方を否定してないよね。

591 :名前は開発中のものです。:2009/01/15(木) 12:42:59 ID:hP+cZz1k
>>590
>589 で十分だと言いながら、 >572 を読む限りあんたは何かの目的を持って
ごった煮リストにつなぐ(ことがある)んだろ?
しかもそれが初心者にはおすすめできない「テクニック」であると言うじゃないか。

それは何のためなのか、どんなメリットがあるのか、あるいはどんな問題が解決されるのか
ってのがこのスレ的には主題だと思うんだ。

592 :名前は開発中のものです。:2009/01/15(木) 20:17:43 ID:M6pRbS27
まず、タスクシステムによって解決する問題をはっきりさせるほうが先じゃね?

593 :名前は開発中のものです。:2009/01/15(木) 22:01:19 ID:fj87WfsG
>>592
>>535


594 :名前は開発中のものです。:2009/01/15(木) 22:28:38 ID:zGhdH5sn
裏山で出土した石器を明日の仕事でどうやって使うか話し合うスレはここですか?

595 :名前は開発中のものです。:2009/01/15(木) 22:46:56 ID:UMJHCNa4
>>594
なんて適切な表現だ

596 :名前は開発中のものです。:2009/01/15(木) 23:31:42 ID:ifLaXFYJ
>>594
いいえ。そういう話し合いを望んでいる人間で、現状で生存確認が取れてるのは数人だけ。
筆頭は確定君。「確定」で検索しなさい。

村人達がとっくの昔に遺棄し朽ち果て忘れ去られたはずの山道、というか舗装もされてない獣道。
ある日ハーメルンの笛吹き男が現れこの獣道の入り口だけをお色直しして純真向くな都会の若者達を
招き入れるようになりました。

 「さぁおいで。夢の国へ続く道だよ。通行料代わりに私の本を買ってきなさいピーヒャララ♪」

その獣道は先に進めば進むほど細く険しくなる茨の道。落石や崩落で寸断され死人も出た危険な道。
今では村には国道や高速道路や鉄道が整備されトンネルで一直線に隣村や町に行けるようになり
その危険な獣道を使う村人はもういません。沢山の若者達が嬉しそうに入っていく様子を村人達は
とても不思議そうに眺めていました。「都会の若者が考えるこたわがんねなぁ」
ある村人は興味本位でその疑問を入山する若者に問いかけました。すると若者は快活に答えました

 「え、知らないんですか。可搬性と拡張性に優れた素晴らしい世界へ続く道ですよ。これ確定です」

村人は意味がよくわかりませんでしたが、戻ってきたら旅の感想を聞かせてくれると若者が約束
してくれたので楽しみに待つことにしました。しかし待てど待てどその純真無垢な若者が帰ってくる
ことはありませんでした

597 :名前は開発中のものです。:2009/01/16(金) 00:30:47 ID:J+ghoaMj
タスクシステムって名前じゃなけりゃ
こんなにまで議論の対象にならなかったと思うんだけどなぁ

名前を初めて聞いたときどんなすごいシステムなんだろうと思ったが、
詳細見てしょぼさ加減に思わず吹いたよwww

タスクと聞くとOSをイメージしてしまうし、
システムとかたいそうな名前付けてる割には
パターンやイディオムレベルの構造だしな


598 :名前は開発中のものです。:2009/01/16(金) 00:49:04 ID:Vh/vd+Ew
>>597
そういうことなんだけど、それを理解できずに荒らす人がいるんだよね。
だからそういう人をこのスレに閉じ込めてるんでしょ。

599 :名前は開発中のものです。:2009/01/16(金) 01:04:30 ID:gk0Vk8Iw
タスク信者を荒らし認定すんなカス

600 :名前は開発中のものです。:2009/01/16(金) 01:07:52 ID:Fyhxl6Le
タスク信者乙

601 :名前は開発中のものです。:2009/01/16(金) 07:37:53 ID:V+6xOIyR
タスク信者は
プログラム言語に型なんかないほうが扱いやすいって言ってるのと同じだよね
実際、タスクシステム使って組むと思いっきり型邪魔だしね

602 :名前は開発中のものです。:2009/01/16(金) 08:38:19 ID:OtZdxkWX
タスク信者はあいかわらずソースを出さないので相手にしない

603 :名前は開発中のものです。:2009/01/16(金) 09:33:58 ID:u7vFuzDx
タスクシステムに似た仰々しい名前を教えるね
「コントロールブレイク」
ミンナニハナイショダヨ

604 :名前は開発中のものです。:2009/01/16(金) 12:05:28 ID:SSSDupAm
>>596
>今では村には国道や高速道路や鉄道が整備されトンネルで一直線に隣村や町に行けるようになり

詳しく


605 :名前は開発中のものです。:2009/01/16(金) 15:33:43 ID:Tw20N5by
1ヵ月ぐらい住み着いてる抽象的な話で煙に巻く君だ。
放置推奨。

606 :名前は開発中のものです。:2009/01/16(金) 16:31:33 ID:DxCTIuim
托鉢癖の乞食には酷く癇に障るものらしいよ

607 :名前は開発中のものです。:2009/01/16(金) 16:58:27 ID:Sf00Y3yI
>>606
韓国語でおk

608 :名前は開発中のものです。:2009/01/16(金) 18:18:09 ID:KRZAOczr
??? ???

609 :名前は開発中のものです。:2009/01/17(土) 00:19:12 ID:OfSsMU0e
型安全なタスクシステムってC++のtemplateとか使えばできるかな?
無理?

610 :名前は開発中のものです。:2009/01/17(土) 00:20:32 ID:Oxq6Kdrs
>>609
コード書いてみ

611 :名前は開発中のものです。:2009/01/17(土) 00:44:48 ID:YP2g0z+6
>>609
templateはあくまでコンパイル時の・静的なポリモーフィズムが実現できるだけでしょ

612 :名前は開発中のものです。:2009/01/17(土) 01:43:07 ID:1fr/EvSg
>>609
>>2じゃなくて(ごった煮にはしないで)素直に組む場合
型別で管理クラスを作るのにテンプレートは便利


613 :名前は開発中のものです。:2009/01/17(土) 13:05:26 ID:OfSsMU0e
レス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);
  }
};

614 :名前は開発中のものです。:2009/01/17(土) 15:40:02 ID:8YYLBgEp
>>613
通りすがりだけど、そのlistが持っているCPlayer*とかは誰が解体するの?

普通のタスクシステムなら、タスクシステムが解体を保証するだろうし、
さもなくば、auto_ptrなりshared_ptrなりを使うのが普通だと思うのだが。

解体責任を明確にする上でもタスクシステムは有効なのだが、
そのことは理解してる?

あと、C++なんだから、structをtypedefするのやめようよ。
それとtemplateの部分、何がしたいのかわからない。

615 :名前は開発中のものです。:2009/01/17(土) 16:06:08 ID:WEwgflmD
吹きそうにやるからタスクシステムって言うのやめてくれwww

616 :名前は開発中のものです。:2009/01/17(土) 16:16:24 ID:6QZ2ql1t
>>613
ちょっとまて
それが何を目的としたどんな問題を解消するのか
それを宣言してから先へ進んでくれ

617 :名前は開発中のものです。:2009/01/17(土) 17:01:51 ID:6uPHKAvn
>>615
話が進まなくなる。
なにか名前がないと会話できないだろ。
フレームワークだけ先に浸透しちゃったから、それぞれが勝手に名前付けてるんだよ。
>>2の人たちは、できるだけ統一したいから、多数派っぽいタスクシステムって名前を使ってるだけじゃないかな。

618 :名前は開発中のものです。:2009/01/17(土) 18:04:41 ID:1fr/EvSg
>>613
ESPを使ったところ、処理単位の粒度を粗くしようとしているのかな。と読み取ってみた

>>614
まぁ>>613のコードがスマポ使ったほうがよさげというのは同意だけど
俺のESPによるとそれは枝葉末節の話のような気がする

ところでその枝葉末節について思うこと

>普通のタスクシステムなら、タスクシステムが解体を保証するだろうし
>(中略)解体責任を明確にする上でもタスクシステムは有効

@キミのタスクシステムというのが何なのか知らんので
 ⇒>>2みたいにひとつの循環リストに全オブジェクトをぶち込んでると仮定
A解体というのが具体的に何(ゲーム上の生死なのかリソース開放なのか)か知らんので
 ⇒リソース(メモリ、OSから発行されたデバイス等のインターフェース、etc)の開放と仮定
B>>2の循環リストが何でソートされてんのか知らんので
 ⇒差分処理の順序(>>2のプライオリティ?)でソートされてると仮定

以上の仮定のもとでレスを書くと、キミは
「全部入りの循環リストを舐めれば全リソースを開放できるから>>2は解体を保証してるのだ」と言ってるのね。
ところで>>2の循環リストは第一義にはゲームの処理の手続き、差分処理の順序を表わすものなんだよね?
単に全部入りのコンテナだからという理由でリソース開放用にこれを流用するの?

619 :名前は開発中のものです。:2009/01/17(土) 18:07:08 ID:1fr/EvSg
>>614
常々思うのは、何で>>2は(>>2を擁護する人は)ひとつの循環リストを特別にユーザーオブジェクトに侵入させ
ごった煮の全部入りとし、更にはこれにいろんな責任を与えようとするのかってこと。そこに合理的理由はあるのかな。
単なる貧乏性なんじゃないのかと思うんだよね

順序と集合が共通だから、ということで複数の責任・役目を与えるのはまぁいいよ
でも>>614みたいに第一義にはゲーム更新処理用のコンテナをリソース管理の責任も与えようとするなら
集合は共通してるけど順序は違うんだよね。ソートしなおすんだろうね

あと別件で、以前に>>2は親が死ねば子も死ぬという死の連鎖を表現できるという人がいたけど
これを直接に表現するのは>>2の侵入式の循環リストではなく、ユーザー側で用意する親子関係を表わすツリーだよね。
で、必要ならそのツリーをトラバースした順序をもとに>>2の侵入式循環リストの当該箇所をソートしなおすんでしょう?
>>2は親子の死の連鎖とかぶっちゃけ関係ないよね。ユーザー側に丸投げしてるでしょ

何で普通の(つまり外部収納の)コンテナを役割毎に持たないの?リソース管理用ならリソース管理用
更新手続き用なら更新手続き用、親子関係なら親子関係用、機能を明確に分離できずに無闇に
癒着させるってのは、硬直して首が回らなくなる危険を犯すってことだよ。経験に裏打ちされたものがない人に
こういう貧乏j根性主導のコンテナ共同利用はオススメできないよ

620 :名前は開発中のものです。:2009/01/17(土) 18:09:41 ID:OMxmEozH
わけわかんなくなるから想像や仮定を前提にして話を進めようとするのはやめてくれ。
わからないことは素直に聞けよ。答えが返ってこなければそこまでの話だ。

621 :名前は開発中のものです。:2009/01/17(土) 18:16:35 ID:j81Idijo
> @キミのタスクシステムというのが何なのか知らんので
>  ⇒>>2みたいにひとつの循環リストに全オブジェクトをぶち込んでると仮定
> A解体というのが具体的に何(ゲーム上の生死なのかリソース開放なのか)か知らんので
>  ⇒リソース(メモリ、OSから発行されたデバイス等のインターフェース、etc)の開放と仮定
> B>>2の循環リストが何でソートされてんのか知らんので
>  ⇒差分処理の順序(>>2のプライオリティ?)でソートされてると仮定

とはいえこれは妥当な仮定だわな
解体はゲーム上のオブジェクトの死ではなくリソース開放だろ
>>2のプライオリティの使い方は処理順だ
これも一致してる

ま、仮定するまでもなく的中だろう

622 :名前は開発中のものです。:2009/01/17(土) 18:33:30 ID:6uPHKAvn
なんで妥当なの?
オブジェクトごとのリスト、優先度なし、ソートなし。
これはタスクシステムと言ってはいけない?

623 :名前は開発中のものです。:2009/01/17(土) 18:45:51 ID:/hhL36V6
>>622
普通は優先度ありはデフォっぽい気がするけどねぇ
じゃないと全てを入れるリスト構造がまともに動くとは思えないし。

全部まとめるから優先順位が必要になるんだよなぁ・・・

624 :名前は開発中のものです。:2009/01/17(土) 19:05:28 ID:Z6Q3Qavn
http://codezine.jp/article/detail/297
ここにあるサンプルを見る限りでは
オブジェクトごとのリストというよりタスクのリスト(似たようなものかな
優先度あり
優先度によるタスクのソートあり
だが

オブジェクト指向でのタスクシステムで異論を唱えている方は
同じことをやっているが手段が違うといったところですかな

625 :名前は開発中のものです。:2009/01/17(土) 19:06:04 ID:xBhfw9Lc
>>622
で?なんなのその聳え立つ一本糞コレクションは。
それでナニすんのおめぇ?食うの?食えんのか?え、食うの?

もう今となってはさ、タスクシステムとか言ってる奴って
こういうカスばっかなんだな。認めざるを得ないわ

626 :名前は開発中のものです。:2009/01/17(土) 19:08:03 ID:R1+oPS+N
>>621
いやいや >613 が >2 を理解しているとは限らないだろ。
少なくとも >613 からはそれは読み取れん。
むしろ >613 が >2 を理解している信者であるという仮定は >613 のコードからすると大胆すぎる。

そもそもこれまでの流れを見る限り信者もアンチもこのスレの住人が >2 を理解してるとは思えん。
俺もよくわからん。書いてることバラバラじゃねえか。

627 :名前は開発中のものです。:2009/01/17(土) 19:12:23 ID:Z6Q3Qavn
http://nullpo.vip2ch.com/ga26086.jpg

628 :名前は開発中のものです。:2009/01/17(土) 19:17:12 ID:/hhL36V6
待てなんだこの図は
どこにこんなんあるんだw

629 :名前は開発中のものです。:2009/01/17(土) 19:18:01 ID:OfSsMU0e
>>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;};

630 :名前は開発中のものです。:2009/01/17(土) 19:20:42 ID:6uPHKAvn
>>623
言葉が悪かった。
オブジェクトの種類ごとにリストを分けるだけで、単純なものなら優先度が不要になる。
シューティングの弾だったらほとんど生成順に描画で問題ないでしょ。

631 :名前は開発中のものです。:2009/01/17(土) 19:21:16 ID:8YYLBgEp
>>618
> ところで>>2の循環リストは第一義にはゲームの処理の手続き、差分処理の順序を表わすものなんだよね?
> 単に全部入りのコンテナだからという理由でリソース開放用にこれを流用するの?

解体責任が分散すると解体忘れにつながるからC/C++で書くなら
(auto_ptrやshared_ptrを使わずに愚直に書くなら)全部入りのコンテナか、
あるいは、その周辺が解体責任を担うように設計するのは普通だと思うんだが。

>>619 は一理あるので否定はしない。

ただ、(俺が作ってきた)タスクシステムは、タスクの生成/解体まで
タスクシステムがその権限/責任を持っていて、タスクデバッガのようなものを
attachさせて、実行時に走っているタスクをwatchしたり、実行時にbreakを
かけて特定のタスクを生成を指示したりすることが出来る。

まあ、これは「タスクシステム」ではなく、「タスクに関するフレームワーク」と
呼ぶべきかも知れない。ともかく、これが使い回しが利いてとても便利なんだ。

特定のタスクがイレギュラーな構造になっているとこのフレームワークの
恩恵を受けられない。それが嫌なんだな。

まあいいや。たぶんこのスレの趣旨とは違うんだろうから、おとなしくROMっとくよ。

632 :名前は開発中のものです。:2009/01/17(土) 19:25:08 ID:8YYLBgEp
>>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*>のようなものを持っていると、
親が死んだ子に対してアクセスしてしまう。これをどうやって防ぐの?


633 :名前は開発中のものです。:2009/01/17(土) 19:57:14 ID:OfSsMU0e
>>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)でまとめるも良し。そのままでも良し。

634 :名前は開発中のものです。:2009/01/17(土) 19:58:56 ID:Z6Q3Qavn
>>628
私の趣味の画像でございます
お気にさわるようでしたら削除いたします

635 :名前は開発中のものです。:2009/01/17(土) 20:07:56 ID:1fr/EvSg
>>631
ごめん。相手を見誤ってた。俺は>>618
ID:8YYLBgEpの言うタスクシステム=>>2と仮定してたんだけどこれ間違いだね。

ID:8YYLBgEpの言うタスクシステムはゲームオブジェクトのモニタでもあるんだね。
(というかモニタ機能がむしろメインだろうと思う)

>解体責任が分散すると解体忘れにつながるからC/C++で書くなら
>(auto_ptrやshared_ptrを使わずに愚直に書くなら)全部入りのコンテナか、
>あるいは、その周辺が解体責任を担うように設計するのは普通だと思うんだが。

これは同意。上記の仮定間違いに伴うすれ違いだった。具体的には
>>2の場合、ユーザーは(ゲームオブジェクトのジョブを書く奴は)TCBにかなり自由に頻繁に触るので
TCBのパラメータが全く信用ならない⇒解体には別の、外部収納のコンテナが欲しい
(デバッグ用モニタとしては別のアドレス空間に欲しい)という趣旨で書いたんだ

>ただ、(俺が作ってきた)タスクシステムは、(後略)

全くもって同意。異論を挟む余地がない

以下蛇足

モニタ機能の記述が完全に欠如したタスクシステム解説のWEBページや書籍があまりに多いので、俺は
「世間ではこういうものがタスクシステムと呼ばれるようになったのか。じゃあタスクシステムという言葉を
職場内で使うのも止めよう。」ということでタスクシステムという呼称を使うのやめちゃった

636 :名前は開発中のものです。:2009/01/17(土) 20:09:40 ID:Z6Q3Qavn
タスクシステム信者にお伺いしたいことがございますが
class A;
class B {
A *obj;
};
が理解できますか?

637 :名前は開発中のものです。:2009/01/17(土) 20:10:28 ID:OMxmEozH
モニタ機能って、なんか、わざわざ発生させた問題に対策を用意して
対策を売り込むとか、マッチポンプじゃないの?

普通に組んで、普通にデバッガ使うのと何が違うの?

638 :名前は開発中のものです。:2009/01/17(土) 20:12:34 ID:Z6Q3Qavn
>モニタ機能の記述が完全に欠如したタスクシステム解説のWEBページや書籍があまりに多いので、俺は
>「世間ではこういうものがタスクシステムと呼ばれるようになったのか。じゃあタスクシステムという言葉を
>職場内で使うのも止めよう。」ということでタスクシステムという呼称を使うのやめちゃった

揚げ足を取るようで申し訳ないのですが
Observer パターン というものがございます
http://ja.wikipedia.org/wiki/Observer_%E3%83%91%E3%82%BF%E3%83%BC%E3%83%B3

639 :名前は開発中のものです。:2009/01/17(土) 20:18:18 ID:8YYLBgEp
>>635
了解しました。あなたとは同業者っぽいね。

640 :名前は開発中のものです。:2009/01/17(土) 20:21:32 ID:1fr/EvSg
>>636
コンポジションがどうかしたの?
まぁタスクシステム(>>2)信者じゃないから反応する理由はないんだけど
>>2とは全く異なる、自社製のマイクロカーネルがタスクシステムと呼ばれてたもんでね
まぁ、どうでもいい田舎モンのローカル用語だから実態が違うのは当然だし
世間様の前で「これがタスクシステムだ!」なんて絶叫したりしないから俺は心配ない。はず

641 :名前は開発中のものです。:2009/01/17(土) 20:24:28 ID:Z6Q3Qavn
>>640
いや、なに
一流と呼ばれている方が私のコンポジションだらけのソースを
わけわからんとおっしゃいまして
彼はタスクシステムを理解できていたようで
疑問に思っていた次第であります

642 :名前は開発中のものです。:2009/01/17(土) 20:25:29 ID:1fr/EvSg
>>638
GoFのデザパタに関する知識は後付け・付け焼刃のハンパなもんだけど
揚げ足をとられてる実感が全くないので詳しく頼むわ

643 :名前は開発中のものです。:2009/01/17(土) 20:27:33 ID:Z6Q3Qavn
>>642
>呼称を使うのやめちゃった
最後まで読んでおりませんでした
私の論理的ミスです
申し訳ございません

644 :名前は開発中のものです。:2009/01/17(土) 20:47:54 ID:6QZ2ql1t
実際、>>619はタスクシステムで組んでるとぶち当たる問題を的確に表現してるな
これを問題と意識せずに華麗にスルーしてしまうとタスクシステムを使い続けるようになるんだろう
まずいものはまずいとちゃんと認識したほうがいい

645 :名前は開発中のものです。:2009/01/17(土) 21:38:03 ID:OfSsMU0e
>>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したり
  ...
}

646 :名前は開発中のものです。:2009/01/17(土) 21:55:50 ID:8YYLBgEp
>>645
> 1. Yes. コピペ上等の精神で乗り切る、はダメ?

・類似コードなのに再利用できない
・同じ処理内容のコードが複数の箇所に現われる

のは、プログラムの書き方がおかしいからだということを
もっと意識しておいたほうがいいと思うよ。

> ・deleteを一気に1フレームでやらずに残り時間に応じて分散させたい場合に
>  ゲームオブジェクト内のステートだけではタイミングを判断できないかもしれない。

それは、まったく逆だと思う。deleteしているのが一カ所に集中していれば、1フレームでN回以上は
deleteしないという処理を書くのはたやすいけど、deleteしている部分が分散していたら
そんな処理を書くのはとても面倒。

> 親子タスクは無いけれど親子データとか親子オブジェクトは欲しい。
> それは単なるオブジェクト間の通信に帰着可能だと思うので
> 下のupdate()群のように等価に置き換えできないでしょか。

そのコードのどこにオブジェクト間の通信のコードがあるのかわからない。
あと、その1フレーム分の処理、updateを書き忘れたり、新たに動かすものが増えるごとに
新たにその関数のなかにupdateを呼び出すコードを追加しなくてはならない。

これだといわゆる従来のタスクシステム(>>2)と比べても大幅に劣っている。

647 :名前は開発中のものです。:2009/01/17(土) 21:59:52 ID:OfSsMU0e
そういえば >>613 でゲームオブジェクトとからタスクを分離させた着想の元は
>>553 のレスの
>ゲームオブジェクトをupdateのみを持つ別のクラスで包む
だったかも。
それと「template使ったら何かがきれいに書けるかも!」という思い付きがなぜか混ざった。
昨晩は酔っ払っておりました。

648 :名前は開発中のものです。:2009/01/17(土) 22:24:03 ID:OfSsMU0e
>>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
はできないのでは? 運用でカバー?

649 :名前は開発中のものです。:2009/01/17(土) 23:04:24 ID:8YYLBgEp
>>648 は何が言いたいのかよくわかんないのでもう帰ることにするよ。最後まで相手できなくてごめんね。

2chを久々に見にきて、たまたま面白そうな話題だったからちょっと首つっこんでみただけなんだ。

しかし2chって面白いね。ID:1fr/EvSg みたいなベテランプログラマと、 ID:OfSsMU0e みたいな
ド素人(気を悪くしたらごめんね)とがひとつのスレで議論してたりするんだね。新鮮だった。

俺は大手ゲーム会社でかれこれ15年ぐらいプログラム書いてきてるんだけど、従来のタスクシステム( >>2 )は
出発点としては意味があると思うね。それをフレームワークとしてどう発展させていくかという問題はあるけどね。

650 :名前は開発中のものです。:2009/01/17(土) 23:27:01 ID:OfSsMU0e
>>649
整理して言えずごめんなさいね
ド素人には気は悪くしましたがタスクデバッガのようなものとか私作れないのでまぁ仕方ない。
何年も実業務に携わってる人にケチつける気は毛頭ないです。

651 :名前は開発中のものです。:2009/01/17(土) 23:49:44 ID:oi21N11D
生存タスクを列挙したりとか、生成・解放のログを取ったりとかは普通にやるよね。
それ以上のことは普通のデバッガで十分じゃない?

652 :名前は開発中のものです。:2009/01/18(日) 02:57:06 ID:iPXWFM98
>>609
デザインパターンのオブザーバーとかをスマートポインタあたりでくるんで使うと
だいたい良い感じにそうなると思うよ。

C++の機能を使えばタスクシステムとやらを作っても危険性はまったくなくなるのだが
どうもC言語から離れたくない人が多いみたいだ。

653 :名前は開発中のものです。:2009/01/18(日) 03:49:58 ID:Qv/3jmn6
>>652
>C++の機能を使えばタスクシステムとやらを作っても危険性はまったくなくなるのだが
危険性じゃなくて意味がないってほうが言いたいけどな

654 :名前は開発中のものです。:2009/01/18(日) 03:54:18 ID:cT0+DXHH
ほとんどROMってるだけだけど、たまには俺も口を出そう。

何でも同等に扱うごった煮的アプローチが批判されてばかりいるけど、
昔のゲームみたいに敵/味方とはっきり分かれているのは別として
最近の自由度が高いゲームだと元々システム的にあらゆるオブジェクトが
ほとんど対等な扱いだったりするから、そういう状況で使うのは有りだと思う。

PCのゲームだとデータ改竄で普段なら有りえない現象を見たりできるけど、
実装がごった煮っぽい現象はたまに見るよ。

655 :名前は開発中のものです。:2009/01/18(日) 10:28:34 ID:Qv/3jmn6
>>654
はぁ?そりゃゲームの仕様の話だろ?
なにいってんだよ
お前、いままでで一番ピントがズレてんだよ
たまに口挟むなんてやらないほうがいいぞ
ここで煽りあって議論してる奴等もピントはずしたらどうなるか
一応わかってレスつけてるからレスを返せるんだぞ

656 :名前は開発中のものです。:2009/01/18(日) 12:40:20 ID:HRDa2XEn
えらそうw

657 :名前は開発中のものです。:2009/01/18(日) 17:40:56 ID:fcoHRa0z
>>655
でもゲームの仕様、つまり実装目標を無視して構造を考えるって、極めて無意味っぽくね?
手段と目的が完全に逆転してる希ガス

658 :名前は開発中のものです。:2009/01/18(日) 23:23:33 ID:Qv/3jmn6
>>657
は?仕様がごった煮だからごった煮でいいって?
アフォでしょ?相手にもしたくない驚愕すべきレベルだな

659 :名前は開発中のものです。:2009/01/19(月) 00:03:33 ID:0Y2N5kFB
ここでタスクシステムの議論してる人らってそのタスクシステムをなにに使おうとしてるの?
何が便利になるの?

660 :名前は開発中のものです。:2009/01/19(月) 00:22:29 ID:YFq/jvI1
>>653
どっちにしろ出来上がったものはタスクを処理するシステムになる。意味がないもくそも
タスクシステムって名称を貶めたいだけだろうアホめ。

661 :名前は開発中のものです。:2009/01/19(月) 00:38:58 ID:f259EVPA
>>659
それが重要だよね

662 :名前は開発中のものです。:2009/01/19(月) 00:49:42 ID:YFq/jvI1
デザインパターンの本を読めばどう便利なのか書いてある

663 :名前は開発中のものです。:2009/01/19(月) 00:58:44 ID:f259EVPA
>>662
デザインパターン自体なにも利点のないものが入ってるし疑わしい
そもそもそれがゲームに適用できるのかどうかって検証も必要になると余計ややこしい
やっぱりたとえ話じゃなんの説明にもならないんだよ
説明する内容が複雑でその構造を説明するときにたとえ話はいいかも知れないけどね
この場合デザインパターンの例は役に立たないと思う

664 :名前は開発中のものです。:2009/01/20(火) 01:29:34 ID:AtWTdZiU
デザインパターンの使い方が判らんのか?

665 :名前は開発中のものです。:2009/01/20(火) 06:01:22 ID:KNFisALs
正確にはデザインパターンのゲームプログラムへの適用が適切がどうかわからない
デザインパターンはゲームの本じゃないからね
使ってる奴が間違った適用をしてたら意味ないし

666 :名前は開発中のものです。:2009/01/20(火) 20:39:32 ID:1EQivU9h
なんでこのスレの人は抽象的な話しばっかするんだろう

667 :名前は開発中のものです。:2009/01/20(火) 22:54:01 ID:AtWTdZiU
ゲームプログラムとプログラムが違うと思ってる時点でへんな先入観を持っている。

デザインパターンのオブザーバーとストラテジーはまんまタスクシステムだよ。

668 :名前は開発中のものです。:2009/01/20(火) 23:06:24 ID:KNFisALs
オブザーバーとストラテジー?
両方とも目的と適用可能性の説明がゲームオブジェクトとかけ離れていて全く理解不能
どこがわからないとかじゃなくて共通箇所が欠片もみあたらない
パターン間違ってない?

669 :名前は開発中のものです。:2009/01/20(火) 23:24:36 ID:AtWTdZiU
いろんなオブジェクトにメッセージなげて処理してもらって
状況に応じてそれぞれのオブジェクトの中身が変わるんだろ?

670 :名前は開発中のものです。:2009/01/21(水) 00:25:19 ID:Ik+L+FW+
>>667
デザパタを理解してないヤシは出てくんな。

671 :名前は開発中のものです。:2009/01/21(水) 00:55:30 ID:HcSl8u5v
オブザーバっていわゆるコールバックなんだぜ

こいつらがいっているタスクシステムにコールバックなんて単語でてきたか?


672 :名前は開発中のものです。:2009/01/21(水) 01:25:14 ID:bCc+S9vA
>>2はVSYNC信号をトリガーに循環リストの全要素・全ゲームオブジェクトを総ナメしてupdate() 関数を呼び出す
ここで注意が必要なのは「システム」を自称する>>2は何故か一本糞の循環リストしか持ってないっつーこと。
そしてVSYNC信号が発生する度に、相手の都合なんてお構いなしに、呼び出される必要があろうが無かろうが関係なく

              【問答無用でとりあえず全てのゲームオブジェクトを叩き起こす】

「ねーVSYNC信号発生したよ?起きなさいよ。やることない?やることない?あるならやれよ早く。無いなら処理返せよ早くホラ」

これポーリング処理。一本糞リストしか持たない>>2がオブザーバ・パターンだとか言ってる時点で何かがおかしい

673 :名前は開発中のものです。:2009/01/21(水) 01:57:42 ID:Ik+L+FW+
chain of responsibilityがタスクシステム(に使われている)と言うなら
まだほんの少しはわかるが、>>667 はただの馬鹿にしか見えない。

674 :名前は開発中のものです。:2009/01/21(水) 02:01:19 ID:bCc+S9vA
>>665
>正確には

正確に言え。

675 :名前は開発中のものです。:2009/01/21(水) 07:32:47 ID:8MTRCkQM
どうやらデザパタはただのノイズだったようで

676 :名前は開発中のものです。:2009/01/21(水) 09:05:35 ID:xk4WvI9i
>>671
ttp://diary.imou.to/~AoiMoe/2008.12/early.html#2008.12.02_s01_p04
> .タスクシステム - 私も検索してみたけど、タスクなんてご大層なもんではなくて単なる
> コールバックキューに見える。私のような GUI 屋とかはむしろこの手の仕組みは
> 自家薬籠中のもんで、タイムクリティカルじゃないことをやるには便利。実装は簡単そうに
> 見えて結構奥が深いので手を出さないのが無難。趣味のプログラミングとしては
> 実によい題材だけど。線形リストの奥深さを知れ。

677 :名前は開発中のものです。:2009/01/21(水) 12:44:37 ID:8MTRCkQM
引用して何がいいたいのかわからない
見えるなんて表現してる人の言葉使わずにデザパタからきっちり説明したまえ
第一そのリンク先の人の言葉なんて誰が保証してくれんの?

678 :名前は開発中のものです。:2009/01/21(水) 12:54:55 ID:8MTRCkQM
ちなみに別にデザパタを説明してほしいわけじゃなくて
なぜそのパターンがタスクシステムだと考えたのか?ってとこな
ま、それが説明できてもそのパターンの効果をみるとそれがタスクシステムの利点とイコールか?
って言われると全く見当違いな気がすんだけどな
俺の勘だけど

679 :名前は開発中のものです。:2009/01/21(水) 12:57:43 ID:0OYCNchY
>>678
> タスクシステムの利点
詳しく

680 :名前は開発中のものです。:2009/01/21(水) 19:35:20 ID:8MTRCkQM
>>679
俺はアンチタスク派なんだけど
あえていうとごった煮で引数の同じ関数を一気に実行できるとこじゃね?
利点ていうと違うな
俺はこんなことしちゃいけない派

681 :名前は開発中のものです。:2009/01/21(水) 19:44:20 ID:8MTRCkQM
そうすると基底クラス関数よんじゃだめなの?とか言われそうだが
そうじゃなくて
本当は引数で渡すべき処理をグローバル変数やシングルトン使ってやりとりするのが駄目

682 :名前は開発中のものです。:2009/01/21(水) 23:59:06 ID:bCc+S9vA
ID:f259EVPA
ID:KNFisALs
ID:8MTRCkQM

・・・。ずーっと観察してるがやっぱグダグダだなお前
もう少しよく長考してから書き込めよ

>デザインパターン自体なにも利点のないものが入ってるし疑わしい

ほう。kwsk。(どうせシングルトンのこと言ってるんだろう)

>正確にはデザインパターンのゲームプログラムへの適用が適切がどうかわからない

素直に「デザパタ分かりませんので噛み砕いて説明してくださいお願いします」
って頭下げればいいんじゃないのお前

>両方とも目的と適用可能性の説明がゲームオブジェクトとかけ離れていて全く理解不能
>どこがわからないとかじゃなくて共通箇所が欠片もみあたらない

んー。イベントドリブンな仕組みを作るとオブザーバのようなものになるわけだが
>>2は搭載してないけどな。(ユーザーに丸投げてる)

683 :名前は開発中のものです。:2009/01/22(木) 00:06:47 ID:Y0w/+LcV
まぁ、>>2におけるイベントといえるものはVSYNCくらいだな。これだけ。
ゲームオブジェクトにとっては全く足りない。

ゲームの基本プログラムはメッセージ駆動システムの体をなすことが多い。
衝突・タイマー・etcetc。システム側で提供することが望ましいものは沢山ある
>>2はなにひとつ提供しない。ユーザー側で実装することになる

ある時間に覚醒するジョブがあるとすると、ユーザーは毎フレーム呼び出される度に
自らグローバルタイマをチェックするか、自前のカウンタをデクリメントして時間が到来したか
チェックする。


684 :名前は開発中のものです。:2009/01/22(木) 00:13:19 ID:CJkxnn0x
むしろ、デザパタはお前>>682のが理解してないよ
だってオブザーバーの目的って
あるオブジェクトが状態を変えたときに、それに依存するすべてのオブジェクトに自動的にそのことが知らされ略
って奴だぜ
目的は本当にそれでいいの?
仕組みとコードだけ拾ってテキトーに適用したでしょ?違う?
そうでもないとこの適用はありえないよね?

685 :名前は開発中のものです。:2009/01/22(木) 00:29:27 ID:Y0w/+LcV
>>684
>>2が一切サポートしない機能の話しになるからアレだが
指揮システムが必要なゲームはこんな感じになるよ。結果的にな

・中隊本部の信号弾(赤)を合図に状況開始
・班長の拳に注目セヨ。拳を振ったら停止・全周警戒

686 :名前は開発中のものです。:2009/01/22(木) 00:51:50 ID:Y0w/+LcV
AIで動く敵軍にチート情報を与えるようなエンティティをマップに配置することもある
ゾーンアラームなど。プレイヤーが指定された範囲内に侵入すると
登録された敵分隊に警報が発令され、指定された戦術行動を取らせる
そのエリアのパトロールに向かわせる、など


687 :名前は開発中のものです。:2009/01/22(木) 01:27:08 ID:Y0w/+LcV
威勢はいいが反応が悪いな。
上ではかなりジャンルが偏った例をあげたが似たような仕掛けは
いろんなゲームで登場する。特に後者のAI補助用のエンティティ。

まぁ、なんだ。【ありえない】とか簡単に言い切る前に長考しろってこと

688 :名前は開発中のものです。:2009/01/22(木) 06:03:42 ID:4Hs/k2j6
http://www.nicovideo.jp/watch/sm2078250
3分30ぐらいまで見てると、タスクシステムが登場するぜwww
(序盤音量とかいろいろ注意)

689 :名前は開発中のものです。:2009/01/22(木) 07:34:35 ID:CJkxnn0x
>>686
特殊な例あげて正当化しやがって(笑)
そもそもそれじゃそいうことしないオブジェクトに対しては全く意味ないってことでいいの?

690 :名前は開発中のものです。:2009/01/22(木) 08:59:51 ID:7pC44zR+
いちいちageんなクズ共

691 :名前は開発中のものです。:2009/01/22(木) 12:35:12 ID:CJkxnn0x
携帯からだとsageっていれんの面倒なんだよもん

692 :名前は開発中のものです。:2009/01/22(木) 12:43:31 ID:XAaINowR
sの時点でsageが候補に出るおれの携帯って・・・

693 :名前は開発中のものです。:2009/01/22(木) 19:55:36 ID:Y0w/+LcV
>>689
マップ上にセンサーを配置するのが特殊とな?
ゲームバランスをコントロールするために、あるいは演出のために
空間内にセンサーを配置する、という選択肢をレベルデザイナーに
与えるのは特殊とな?

んー、興味深いな。

キミはいつもどういう人数構成でどんなゲームを作ってるんだい?

694 :名前は開発中のものです。:2009/01/22(木) 20:55:51 ID:CJkxnn0x
マップの話なんかしてないよ
どうつながったのかしらないけど
頭おかしいんと違う?

695 :名前は開発中のものです。:2009/01/22(木) 21:10:15 ID:Ejlz3BFK
>       『目的は本当にそれでいいの?』
>       『仕組みとコードだけ拾ってテキトーに適用したでしょ?違う?』
>       『そうでもないとこの適用はありえないよね?』

簡単にありえないとか言い切るってすごいね
視野狭窄で自己中で思考停止。病気じゃないの?

696 :名前は開発中のものです。:2009/01/22(木) 21:26:12 ID:3jTewWuY
だけどデザパタのObserverの動機を読むと
ソースの記述だけ似てたから適用してみた感は強いな
デザパタの説明だとあくまでオブジェクト間の依存関係について説明してるのに
目的や動機を全く読まずに形だけ自分のソースに適用してしまった感はぬぐえない
これはデザパタをよく読んでみればわかる

697 :名前は開発中のものです。:2009/01/22(木) 22:09:13 ID:Y0w/+LcV
うん。デザパタについての理解不足は当然あるだろうね
俺はデザパタ用語は自発的には使わない。専らヒアリング専門なんだ。
デザパタ用語を駆使する人とのコミュニケーションを成立させるための
リテラシーとして頭の片隅に置いてる程度。至らぬところは素直に
ごめんなさいする用意はある

さて、詳しそうな人が出てきたので質問してみますよ

>>696
お、そう見えますか…
前記したとおり、まぁ結果的に後付でオブザーバーなんじゃないのと感じただけで
GoFのデザパタありきで仕事するほどの大した者じゃあございません。
手元にデザパタ本があるので念のため再読しておりますが
動機も含めて符号していると理解しているのでもう少し具体的に説明しますよ

センサー(Subject)は、登録されてるゲームオブジェクト(Observer)に
【俺の縄張りに何かが入ってきた】を通知するだけの存在です
そのイベントに対する具体的な行動(処理)は登録されている
各ゲームオブジェクトに委ねられております

Observerが地雷原のコントローラであれば、これが起爆のトリガーになります。
野鳥の群れ(のリーダー)であれば、驚いて飛び立ちます。
前記した歩兵部隊の分隊であれば、分隊長(Observer)が各班長に具体的な
行動を指示します。

このようにリスナーは多様です

698 :名前は開発中のものです。:2009/01/22(木) 23:06:41 ID:Y0w/+LcV
ん、肝心の質問文が抜けてた

>>696
で、「目的や動機を全く読まずに形だけ自分のソースに適用してしまった感」
を感じた原因、これがObserverパターンであると説明するには問題がある理由
について宜しければご教示ください。真摯に受け止めます

699 :名前は開発中のものです。:2009/01/22(木) 23:11:33 ID:3jTewWuY
>>698
ん?書いたつもりだけど?
>デザパタの説明だとあくまでオブジェクト間の依存関係について説明してるのに
これこれObserverの作者はオブジェクト間の依存関係を薄くしかったんだ

700 :名前は開発中のものです。:2009/01/22(木) 23:27:27 ID:Y0w/+LcV
>>699
>オブジェクト間の依存関係を薄くしかったんだ

これは俺があげた例においても目的のひとつでありました。
センサーは自分が情報を通知する相手が何者なのか
その情報を何に使うのか、可能な限り知る必要がないことが
求められておりました

マップに配置する汎用のセンサーに対してそのような
要求が出るのは珍しいことでしょうか

以上の説明でObserverの提案者の目的との不整合は
ありますでしょうか

701 :名前は開発中のものです。:2009/01/22(木) 23:46:07 ID:Y0w/+LcV
× 目的のひとつでありました。
○ 要求のひとつでありました。

702 :名前は開発中のものです。:2009/01/22(木) 23:49:32 ID:3jTewWuY
>>700
それじゃ君の意見としては
タスクシステムの目的=オブジェクト間の依存関係を薄くしたい
ということでいいのかな?

703 :名前は開発中のものです。:2009/01/22(木) 23:51:41 ID:Y0w/+LcV
>>702
>>672

704 :名前は開発中のものです。:2009/01/22(木) 23:53:34 ID:3jTewWuY
>>703
依存関係、全然関係ないじゃんw
やっぱりてめーテキトーに適用しやがったな
折角本買ったんだろうしちゃんと読めよ

705 :名前は開発中のものです。:2009/01/22(木) 23:56:09 ID:Y0w/+LcV
なんだかド偉い勘違いされてるようだが

>>704
>テキトーに適用しやがったな

はて?俺はタスクシステム(>>2)なんて使わない人間なんだが
なんか根本的におかしな思い込みしてね?

706 :名前は開発中のものです。:2009/01/23(金) 00:19:48 ID:FRn83395
>>705
それとお前がデザパタ全然理解してないことはまた別だろ?w

707 :名前は開発中のものです。:2009/01/23(金) 00:24:36 ID:2rWIRnW3
>>706
ん?はっきり言って>>704のいみがわかんねーんだが?
どうして理解してないっつー話になるんだい?具体的によろしく頼むよ



708 :名前は開発中のものです。:2009/01/23(金) 00:26:15 ID:FRn83395
>>707
>どうして理解してないっつー話になるんだい?
だってお前、自分の目的と全然違うパターン適用して喜んでるアフォじゃん

709 :名前は開発中のものです。:2009/01/23(金) 00:29:09 ID:2rWIRnW3
>>708
どうぞ具体的に。どこで?どこで?引用してくんね?

710 :名前は開発中のものです。:2009/01/23(金) 00:32:12 ID:FRn83395
>>709
タスクシステムは>>672みたいなものだと言ってるくせに
タスクシステムの目的=オブジェクトの依存関係を薄くしたい
って言ってるんでしょ?

711 :名前は開発中のものです。:2009/01/23(金) 00:32:28 ID:/oVs2I+7
ID:FRn83395
この子は頭がおかしいんじゃないかなとおもた
デザパタヲタってこういうボーダー君多いよね

712 :名前は開発中のものです。:2009/01/23(金) 00:33:31 ID:2rWIRnW3
>>710
>タスクシステムの目的=オブジェクトの依存関係を薄くしたい

え?どこで?

713 :名前は開発中のものです。:2009/01/23(金) 00:34:06 ID:FRn83395
>>711
ん?ちなみに俺はデザパタ使えない派だけど?
俺は他のアフォと違ってちゃんとよく読んだ上で使えないって言ってるので
ちょっとは話相手になると思ってるぞ

714 :名前は開発中のものです。:2009/01/23(金) 00:35:48 ID:FRn83395
>>712
それがObserverの目的であって
タスクシステムがobserverってことは
タスクシステムの解決する問題も当然オブジェクトの依存関係を薄くするってことになるよね?
だけどお前は全然違う目的でobserverを適用してしまっているわけだ

715 :名前は開発中のものです。:2009/01/23(金) 00:36:09 ID:/oVs2I+7
>>713
いや、明らかにキチガイ系デザパタヲタだよ
否定しても無駄だってwwww

ずっとROMってたけどお前の突っ込み全部的外れジャンwww
カスだな

716 :名前は開発中のものです。:2009/01/23(金) 00:41:02 ID:2rWIRnW3
>>714
>それがObserverの目的であって
>タスクシステムがobserverってことは
>タスクシステムの解決する問題も当然オブジェクトの依存関係を薄くするってことになるよね?

あー、お前まさか、>>2はObserverパターンだとか言ってた人?
ねー、聞いていい?>>2の目的は何なの?依存関係を薄くするために>>2なの?

>だけどお前は全然違う目的でobserverを適用してしまっているわけだ

だからどこで?具体的に頼むよ。な?な?

717 :名前は開発中のものです。:2009/01/23(金) 00:42:53 ID:FRn83395
>>715
的外れ?
どこが?
少なくとも目的と違うパターンを適用するほどは的外れじゃないと思ってるんだけどな

718 :名前は開発中のものです。:2009/01/23(金) 00:44:46 ID:/oVs2I+7
>>715
全部だよwwwww
おまけにタスク厨だろ?デザパタヲタでタスク厨とか超大物じゃん
おまえコテ名乗れよ。おもしれーwwwww

719 :名前は開発中のものです。:2009/01/23(金) 00:46:23 ID:/oVs2I+7
あー、腹がよじれるwwwww
草はやしすぎてアンカー間違えちゃったぜ。>>717

720 :名前は開発中のものです。:2009/01/23(金) 00:49:24 ID:2rWIRnW3
怖いよ

721 :名前は開発中のものです。:2009/01/23(金) 00:54:13 ID:/oVs2I+7
すげぇアフォだな。大バカだよwwwwタスクシステムを愛して
これはObserver Pattern DA!バカにすんな!とか言ってんだったら
辛抱たまらんwwwwwwwwたまんねーwwww

>>720
あ、わりぃなwwwww邪魔しちまってよ
だってよwwwwギャハハハハwwww

722 :名前は開発中のものです。:2009/01/23(金) 03:19:22 ID:AxWyjil1
何となく暇だったから200程たまったレスを読んでたらこんな時間だよ!

>513
タスクシステムという言葉が死滅するまで終わりのないモグラ叩きを続けるぐらいなら、
適切な構造をこのスレででも担ぎ上げて、新生タスクシステムとして過去の遺物を駆逐しようとした方が、健康的じゃない?

まあスレで意見がまとまるとも思えないし、万が一まとまっても、
このスレの検索順位からして影響力はまるで皆無な気もするけど。

723 :名前は開発中のものです。:2009/01/23(金) 03:24:42 ID:a4EaNGGN
新生タスクシステムとして過去の遺物を駆逐することを目的に作られた構造なんか
技術的にはまるで役に立たないに決まってるだろ。

具体的な目的に沿ってコードを書け、で FA

724 :名前は開発中のものです。:2009/01/23(金) 03:38:08 ID:1MKfvCI2
ID:FRn83395 は、デザパタヲタどころか、プログラムを1行も書けない
なんちゃってプログラマなんじゃね?

いくらなんでもひどすぎる。

725 :名前は開発中のものです。:2009/01/23(金) 04:42:57 ID:VUWPQz8b
デザパタかじっただけで半分近く読んでない自分が通りますよ、と。
とりあえずオブザーバーの所軽く読んだけど、・・・これ便利だな。
じゃなくて。

なんか一連の流れ、どっかで中の人入れ替わってない?


726 :名前は開発中のものです。:2009/01/23(金) 06:18:55 ID:FRn83395
>>721
もうwの連発しかできなくなったか・・・
よっぽどショックだったんだな
悪いけどお前、プログラマの初心者にアリガチな
説明をよく読まずに当てはまりそうなキーワードを
テキトーに当てはめて問題を解決しちゃおう俺には特別な力がある(多分)症候群にかかってることから
初心者だろ?(俺も昔なったぞ 治るのに時間かかった)

もしくは一度も壁にぶち当たったことのないPGか
たしかにはじめに覚えなきゃいけない知識の量が多いから
そうなっちゃう理由もわからんでもないけど
徐々に克服していかないと会社にでたとき困るぞ

727 :名前は開発中のものです。:2009/01/23(金) 07:38:50 ID:p63dr1PD
うわ。。。鏡どぞ

728 :名前は開発中のものです。:2009/01/23(金) 12:47:51 ID:7wK4EC9/
タスクシステム=オブザーバーは痛すぎた

729 :名前は開発中のものです。:2009/01/23(金) 23:58:00 ID:KrDV7TjS
なんか>>726読んでると道端の酔っ払ったプータローさんの説法を
傍で聞いてるような滑稽な気分になるのは何故なんだろうな
きっと>>726ののたまう戒めの御言葉がむしろID:FRn83395自身に
現在進行形で適用されるべきものだからなんだろうね

730 :名前は開発中のものです。:2009/01/24(土) 00:26:40 ID:vG9CxCiM
その症候群になるやつは根本的にこの仕事向いてないよ
単純な話、視野は絶対的に足りてない

731 :名前は開発中のものです。:2009/01/24(土) 00:58:39 ID:X9GpZcXG
ID:3jTewWuY(ID:FRn83395)

なんつーか、、こういうオッサンっているよな。。。。
お説教が大好きなんだろうね。日頃の行ないが伴ってないから説得力ゼロだけどお説教したい。
そしてもちろん相手を見下したい。でも理詰めでそいつをノックダウンする知恵がない。悲惨だね。
で、焦れて発狂。>>704以降はもう前後不覚。最悪のパターン

結局>>726が言いたかったことなんだろうけど過程がズタボロだから哀愁ばかりが漂うと

732 :名前は開発中のものです。:2009/01/24(土) 01:01:59 ID:PNkXyl5G
>>718,719,721
このw連発の発言は全く擁護できんな

733 :名前は開発中のものです。:2009/01/24(土) 01:14:25 ID:vG9CxCiM
洋画なんか必要ないだろ
ただの荒らしだ

734 :名前は開発中のものです。:2009/01/24(土) 01:15:04 ID:vG9CxCiM
擁護ね。。。

735 :名前は開発中のものです。:2009/01/24(土) 01:19:55 ID:PNkXyl5G
FRn83395はちゃんと受け答えしてただろ
w連発して荒らし始めた奴は技術者向いてない

736 :ID:2rWIRnW3:2009/01/24(土) 01:19:55 ID:qI05bbL0
お取り込み中申し訳ないんだが
>>726
草ボーボーの馬鹿の相手なんかして人生語る暇があるなら
俺の質問に答えてくれないかな。ずっと待ってるんだよな

帰宅と同時にもう睡魔到来中だから早急じゃなくていいから。な。

737 :名前は開発中のものです。:2009/01/24(土) 01:37:15 ID:X9GpZcXG
>>732-736
あれれ申し訳ない。ボクは大変な勘違いしてたみたい。。。。
>>726ってID:2rWIRnW3に対するお説教だと思ってたけど
茶々を入れてる雑草君へのアドバイスだったんだね

早とちりしちゃった。テヘッ

738 :ID:2rWIRnW3:2009/01/24(土) 01:52:06 ID:qI05bbL0
>ID:FRn83395
眠い。とりあえず>>696-からもう一度読んでくれ。俺とお前の争点ここなのよ
お前、俺とのやり取りで>>700の質問に至った段階で回答渋っただろ。
で、>>702で論点をスライドさせたよな。まず>>700の質問に答えてくれ。な。

739 :名前は開発中のものです。:2009/01/24(土) 02:47:27 ID:7DvDFMqL
>>732>>733>>735>>736>>737
何これひどい言われようwwwwwwwwwww
俺涙目wwwwwwwwww

ごめんなさい
「俺は他のアフォと違ってちゃんと」(←キーワード検索)協調性と
自愛に溢れてるから顔真っ赤のオッサンの水準に合わせてあげただけなんだ
もうしない。ごめんなさい





>>726
は?みたいな
悪いけどオッサンあんたさー散々論理的にイカレた発言を連発しまくっといて
よくそんなえらっそうこと思い込みエスパーレスができるよねー
恥ずかしくない?自分と同類のクズ相手なら饒舌になれるの?小さいね!
というか>>726の内容すごいね。受け売り?いつも散々言われてるの?
それを復唱しただけなの?もっと身の丈にあったセリフを吐こうね!

あと何度も言うよ?なんでタスクシステムがObserver Patternなの?BAKA?

740 :名前は開発中のものです。:2009/01/24(土) 06:56:00 ID:NcSxiNZk
>>738
横から突っ込むけど
タスクシステムの議論をしてるのに俺システムの目的を語るのはおかしい
オブザーバーの発言に矛盾がでないようにした苦肉の議論にしかみえない

741 :名前は開発中のものです。:2009/01/24(土) 09:21:08 ID:fYq33vrr
>>740
それはちょっと筋違いなツッコミとおも
もう少し遡るといいんじゃないかな

ID:f259EVPA
ID:KNFisALs

> デザインパターンのゲームプログラムへの適用が適切がどうかわからない

> オブザーバーとストラテジー?
> 両方とも目的と適用可能性の説明がゲームオブジェクトとかけ離れていて全く理解不能

この人物が話をゲームプログラムに拡大してる

742 :名前は開発中のものです。:2009/01/24(土) 10:11:20 ID:PNkXyl5G
>>741
だからゲームプログラムのタスクシステムの話だろ

743 :名前は開発中のものです。:2009/01/24(土) 12:09:57 ID:SVdZHBka
ゲームプログラムと言えばタスクシステムのことになるタスク脳

744 :名前は開発中のものです。:2009/01/24(土) 20:08:15 ID:vG9CxCiM
逆だろ

745 :名前は開発中のものです。:2009/01/24(土) 23:21:19 ID:7VkdRsBc
タスクシステムアンチは見かけるけど
タスクシステム信者は見たことない。
どこ行けば見れますか?

746 :名前は開発中のものです。:2009/01/25(日) 10:58:10 ID:/rbWxoh3
>>745
既知外アンチによればこのスレにうじゃうじゃいるらしいw

747 :名前は開発中のものです。:2009/01/25(日) 12:42:11 ID:GMpY8msp
そんなムキになって自分の黒歴史をなかったことにしようと頑張らなくてもいいんだよ
過去から現在までのスレログもウェブにSNSその他至るところのタスク日記や記事はアーカイブや魚拓でいつでも見れるんだからさ

甘酸っぱい記憶は楽しまなくちゃ

748 :名前は開発中のものです。:2009/01/25(日) 13:55:13 ID:8tAZUMav
どうでもいいけど、つまりここにはいないんだな?

749 :名前は開発中のものです。:2009/01/25(日) 15:21:33 ID:/rbWxoh3
既知外アンチが、読点を打てなくなるくらい必死だということはわかった。

750 :名前は開発中のものです。:2009/01/25(日) 15:24:14 ID:L+MfRmk2
このスレは、基本的にタスクシステムってなに?どんなんなの?って言う人間と、
タスクシステムなんてただの線形リストだろ、しかも使えねー。と思ってる人で構成されています。

751 :名前は開発中のものです。:2009/01/26(月) 10:44:34 ID:Mjs4eHQi
仕事だりぃ

752 :名前は開発中のものです。:2009/01/26(月) 20:39:45 ID:DoPYwd08
哀れな奴らだ。タスクシステムは素晴らしい。夢と希望に溢れている
新清士によるとひらしょーには夢も希望もないそうだ。それはそうだ
タスクシステム(神つまりゴッド)を否定する者に夢や希望が語れる
はずがない

753 :名前は開発中のものです。:2009/01/26(月) 20:51:48 ID:DoPYwd08
タスクシステムとはストラテジーパターンのことだというが順序が違う
ストラテジーパターンがタスクシステムの理念の劣化パクったのだ
StrategyPattern = ConstrainedTaskSystem

即ちタスクシステムとはオーバーストラテジーなのさ
ピーキーすぎてお前らには無理だよ

754 :名前は開発中のものです。:2009/01/26(月) 21:17:37 ID:j13Mtbl7
夢と希望以外なにも語れてないようですが

755 :名前は開発中のものです。:2009/01/26(月) 21:23:11 ID:ytXeAosm
上のほうで書かれてたAグループのメインPGの方ですね分かります

756 :名前は開発中のものです。:2009/01/26(月) 22:17:57 ID:dq77cME0
>>753
ちがそーw

デザパタさw
パターンを拡大解釈するととんでもねー見当違いになりがちだからさw
もうちょっと適切かどうか考えるか
パターン名を出したら目的文を自分でどう解釈してそういう結論にいたったのか
説明してくんねー?w

757 :名前は開発中のものです。:2009/01/26(月) 23:30:15 ID:DoPYwd08
なんという了見の狭い頭コチコチのデザパタオヤジ。デザパタ用語というのは
このように原典に縛られた了見の狭い気持ち悪いマニアの玩具となっているのだ

パンピー : 「これは○パターンといえると思うのです」
マニア   : 『それは○パターンではない。適用した理由を言ってみろ』
パンピー : 「△△だから○パターンと思ったのですがどうでしょう」
マニア   : 『テキトーに適用しやがったな』
パンピー : 「というと?」
マニア   : 『デザパタ全然理解してないアフォめ』
パンピー : 「どのあたりですか?」
マニア   : 『目的と全然違うパターン適用して喜んでるアフォめ』
パンピー : 「どうぞ具体的に」
マニア   : 『俺は他のアフォと違うから!ちゃんとよく読んでるから!』

大川いそうに。なんという知能障害。これがデザパタ用語に取り憑く原典オヤジだ


758 :名前は開発中のものです。:2009/01/27(火) 06:01:47 ID:Oxh3DJ4f
>>757
説明できるの?できないの?

759 :ID:2rWIRnW3:2009/01/27(火) 07:06:37 ID:PaAZpHkh
えーと、横から割り込むようで悪いが
俺の獲物は>>756,>>758でいいのかな
いつまでコソコソ逃げるのかなー

ずっと待ってるんだよな。頼むわ。な。

760 :名前は開発中のものです。:2009/01/27(火) 07:26:37 ID:Df6y9ZuD
なにを?

761 :ID:2rWIRnW3:2009/01/27(火) 07:44:29 ID:PaAZpHkh
>>736,>>738

ま、威勢はいいんだが、頭の回転が鈍いのか即レスを要求すると
論理展開がボロボロになる傾向があるんだよな。このプロ気取り。
で、長考時間を与えてやったら今度は痴呆症でド忘れかい?

やれやれだね

762 :名前は開発中のものです。:2009/01/27(火) 11:39:40 ID:Y7t+hjzj
そいつらと関係ないけど、その流れ結局どうなってんの。たぶん直接の起点は>>667の一言からだろう

>>667問題の一言>>668-678はそれに対する反応と多少のノイズ。
>>682が埋まりかけてた話題を掘り起こす。
>>685がなぜかきわめて局所的な話をしだす。ここまでは『タスクシステム』自体はどういった『デザインパターン』なのかという流れだったのに。
>>695が屁理屈。ノイズ。しかしここから話が派生。
>>685>>696のズレが埋まらないままレスが続く。
>>703>>685が(>>696にとって)意味のわからないレスをする。
(>>696、3jTewWuY = >>706 FRn83395はそれまでのレスが、タスクシステムとオブザーバーについてだと思っていた。)
(>>685 = >>707はそもそもタスクシステムの話をしていないつもりだった。)以下ズレの埋まらない無意味なのレス応答が続く。
>>711/oVs2I+7が発生。だれだこいつ?このグダグダから先の話をまとめてくれよ。ってかむしろ掘り返した>>761 = >>707がまとめてくれ。

763 :名前は開発中のものです。:2009/01/27(火) 11:42:53 ID:Y7t+hjzj
本文多すぎでレス削ってたらよくわからないレスになっちまった。
要するに、>>716あたりから先の話を>>761にまとめてほしい。
なんつーか自分がまとめた場所までの時点でかなり無意味なレス応答感が否めないが。

764 :名前は開発中のものです。:2009/01/27(火) 12:04:13 ID:4zmNqN4Q
>>762-763
>>741とかが指摘してるけど、反タスク派で、たまに
OOP/デザパタ/ポリモーフィズム否定にまで勇み足をする(ように見える)
のがいるので、話が発散してるんじゃないのかな

前にもごった煮にしたら型の判定ができないとか言ってたのがいたし

765 :名前は開発中のものです。:2009/01/27(火) 12:46:47 ID:Df6y9ZuD
今度はストラテジーかよ笑
それって場面によってバブルソート使うかクイックソート使うかマージソート使うか選べる奴だろ?
適用したデザパタの目的と動機は自分の最終目的と一致してるか?

766 :名前は開発中のものです。:2009/01/27(火) 15:14:11 ID:tThR5Acq
タスクシステムがstrategyとか言ってる奴、本当にプログラム1行でも書けるの?

ただの基地外にしか見えん・・・

767 :名前は開発中のものです。:2009/01/28(水) 03:26:34 ID:6GcH3nW3
ID:Df6y9ZuD

↑(・∀・)↑

768 :名前は開発中のものです。:2009/01/28(水) 07:57:24 ID:NLCX4YQf
たまに湧くデザパタ厨はデザパタわかってないみたいだけど
職場でもこんな人いるよ
明らかに目的と外れたパターンを適用してみんなにボコボコにされる

769 :名前は開発中のものです。:2009/01/28(水) 09:29:30 ID:62r5BQN2
>>768
だな。

デザパタって、抽象度そんなに高い話じゃないんだよな。

デザパタを拡大解釈し、抽象度をあまりにも上げて、どんな事例にでもパターンが適用できたら、
その概念自体、あまり意味をなさない。

狭い範囲に対して適用できるからこそ意味が明確で概念として有効なんだ。

770 :名前は開発中のものです。:2009/01/28(水) 14:09:01 ID:xO7fEt0t
ひょっとしてタスクシステムってファクトリーパヤーンじゃね?

771 :名前は開発中のものです。:2009/01/28(水) 19:53:33 ID:NLCX4YQf
パヤンに悪意と釣り針が見える

772 :ID:2rWIRnW3:2009/01/29(木) 19:34:28 ID:QSSosLPK
>>762
>ここまでは『タスクシステム』自体はどういった『デザインパターン』なのかという流れだったのに。

そんな流れとは知らなかった。つかそんなのウンコパターンとかでいいんじゃないか
>>741>>764も指摘しているみたいだが、ID:KNFisALsが流れに支流を作っており
俺はその支流に乗っかったってだけ。迷惑ならウンコパターン話を続ければいいよ

> 3jTewWuY = >>706 FRn83395はそれまでのレスが、タスクシステムとオブザーバーについてだと思っていた

スレ読まずに書き込む間抜けでなければそれはあり得ない
それに俺は初っ端の>>672において既に、>>2をオブザーバーというのは何かがおかしい、と書いてる
 (※理由は>>672で書いたとおり、>>2では全ゲームオブジェクトは誕生した瞬間に唯一の
  循環リストに強制登録される。選択肢は全くない。生きてる限り、【必要の有無を問わず】
  VSYNC信号発生の度に呼び出しを食らう。この時点でObserverとSubjectの関係と明らかに異なる)

773 :ID:2rWIRnW3:2009/01/29(木) 20:32:00 ID:QSSosLPK
>>762
(>>772続き)
スレ読まずに書き込む間抜けってのは勿論ID:3jTewWuY,ID:FRn83395のことな

んで、更に>>682以降で「オブザーバーのようなものになる具体例」として書き始めた内容が
>>2にはないものであるということも最初に>>682で念押しもしている

反応した>>864,>>689,>>694はどうやら自分が作り出した支流の話であると理解していたようだ
>>696,>>699はどうかな。もし君の言うとおりなら「流れ読まずに書き込んだ間抜け」ということになるが
その仮説が正しいかどうかは本人に聞いてみないとなー

>>685がなぜかきわめて局所的な話をしだす

これはゲームプログラムにおけるオブザーバーの存在を疑問視している人間に対しては
具体例を書いたほうがいいだろうと判断したから。一般化・抽象化するとオブザーバーの
ようなものになる必然性が見えてこないし、>>2では無駄が多すぎるということも見えて
こないだろう

マップに配置するセンサー類の設置数は比較的多くなる可能性が高く
総処理時間の上限枠は既に定められているが優先順位は低く削られる可能性も高い
処理内容はさほどタイムクリティカルなものではない(応答速度が数百msでも許容される)

時間刻みがVSYNC固定というのは苦しい。背後に空間領域分割や階層型スケジューラが
必要になる。特に後者のスケジューリング機構はゲームプログラムのかなり低レベルの
層で実装されることが望ましく、スケジューリング機構を持たない>>2はゴミとなる

774 :ID:2rWIRnW3:2009/01/29(木) 20:51:40 ID:QSSosLPK
>>762
(>>773続き)

なお>>685の軍事っぽいジャンルについては完全にでっちあげの架空
実際にはファンタジーものしか作らせてもらえない。しかたないね

>>703>>685が(>>696にとって)意味のわからないレスをする

タスクシステム(>>2)の目的とは>>672である。極めて簡潔な答えだ
もし彼にその意味が伝わらなかったのなら彼の脳内フィルターが
異常をきたしており、何かおかしなバイアスをかけているからだろう

>>704以降の反応で、ID:3jTewWuY の思い込み・先入観の強さが確認された

775 :名前は開発中のものです。:2009/01/29(木) 20:58:52 ID:/s4Iqftx
ごちゃごちゃ長いけど要約すると全部
デザパタ理解してなかった言い訳にしか見えないね

776 :ID:2rWIRnW3:2009/01/29(木) 21:03:33 ID:QSSosLPK
出た出た。いつも監視してんのか。すげぇ暇人だな。助かるよ

>デザパタ理解してなかった

で、早く理解してない部分、とっとと抜粋して晒してくれないかな
ずっと待ってるんだよな。頼むわ。
あと>>738のほうもよろしく頼むわ。な。

777 :名前は開発中のものです。:2009/01/29(木) 21:07:05 ID:/PUT5suM
>>776
だっせ
あまりにも惨めだな
明らかに理解してないのになんで頑張るの?

778 :ID:2rWIRnW3:2009/01/29(木) 21:09:52 ID:QSSosLPK
>明らかに理解してない

どこが?

779 :名前は開発中のものです。:2009/01/29(木) 21:10:34 ID:/PUT5suM
>>778
このスレでオブザーバーとか出てきちゃうあたりw

780 :名前は開発中のものです。:2009/01/29(木) 21:11:54 ID:/PUT5suM
そもそもデザパタの本もってるのかなぁ・・・
ちゃんと目的と動機の欄読んでるのかあやしい
お馬鹿なサイト丸写ししてわかった気になっちゃったんだね

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

ここまで断言&強弁するのはかなりの勇者だとおもうよ
自宅が全焼して髪チリチリになっても勝利宣言してる感じ

お年寄りってプライド傷付けられると狂ったように怒るよね
可哀相



782 :名前は開発中のものです。:2009/01/29(木) 21:35:28 ID:/PUT5suM
>>781
IDまで取り出してきてずいぶん熱心だねw
専用ブラウザの抽出だけならわかるけどw
デザパタ読んでないのにソースの形だけみて適用するからそういう
赤っ恥かくことになるんだよwニヤニヤw

783 :名前は開発中のものです。:2009/01/29(木) 21:37:02 ID:/PUT5suM
これから成長するのにいい薬になるからもっと言っておいてあげるよ

あーだっせw
すげー恥ずかしいw
馬鹿が目的も見ないでパターンとか知った気になっちゃってるの?
説明書読まないでゲーム始めんなよw
中学生か?お前?w

784 :ID:2rWIRnW3:2009/01/29(木) 21:37:27 ID:QSSosLPK
ID:/s4Iqftx
ID:/PUT5suM
はい、どうぞ。引用して俺の発言との矛盾点、指摘してくださいな

785 :名前は開発中のものです。:2009/01/29(木) 21:41:57 ID:/PUT5suM
>>784
その必要はもうないだろw
デザパタ読んで目的と動機の項目読めばアフォでもわかる
恥ずかしい奴だなお前

で?お前誰?
俺、お前にも興味ないしID抽出とかやんないからお前知らないんだけど?

786 :名前は開発中のものです。:2009/01/29(木) 21:43:03 ID:CK8Av1bR
草はやしてる奴は何故に顔真っ赤なのか?


787 :名前は開発中のものです。:2009/01/29(木) 21:43:19 ID:/PUT5suM
だいたい>>781にレスつけたのに何別の奴が返してんだよ

788 :名前は開発中のものです。:2009/01/29(木) 21:50:09 ID:tPxukM8x
ごめん
スレの流れ読まずに書き込んじゃった
ID:/PUT5suMがご本人だったのかな
タイミング悪かったみたい

>>782-783
それにしてもすごい剣幕だね
血圧に注意してね

789 :名前は開発中のものです。:2009/01/29(木) 21:51:22 ID:/PUT5suM
>>788
これだけたくさんIDを集めてきた君が
人の血圧気にするなんてよっぽど顔真っ赤にしてるのがわかるよw

790 :名前は開発中のものです。:2009/01/29(木) 21:56:20 ID:CK8Av1bR
>787
オレに噛み付くなよ。めんどくせー奴だなキミは

791 :ID:2rWIRnW3:2009/01/29(木) 22:08:31 ID:QSSosLPK
>>785
>その必要はもうないだろw
>デザパタ読んで目的と動機の項目読めばアフォでもわかる
>恥ずかしい奴だなお前

頼むからさ、逃げないで答えてくれないか?

>で?お前誰?

それはないだろ。ちゃんと過去IDコテまで入れてるんだからさ
どうか落ち着いてほしい。な。

792 :名前は開発中のものです。:2009/01/29(木) 22:13:41 ID:tPxukM8x
>>789
スレの流れが分からないから追うしかないんすけど。。。
ちゃんとコテ名乗ってくれればID追う必要ないんすけど。。。。
私の推測がハズレならそう言ってくれればいいのに。。。。。。

なんでこの人はこんなに反応するの?むしろこの人誰?
ご本人じゃないなら無視すればいいのに。。。よくわかんない人でつ

793 :名前は開発中のものです。:2009/01/29(木) 22:21:12 ID:CK8Av1bR
>792
そいつは御本人様で確定だろ女子高生的に考えて

794 :名前は開発中のものです。:2009/01/29(木) 22:29:58 ID:/PUT5suM
>>790
誰?レスつけてないじゃん

>>791
は?誰?何聞いてるの?
オブザーバーはタスクシステムじゃないってw
まだ納得してないの?

>>792
>ご本人じゃないなら無視すればいいのに。。。よくわかんない人でつ
お前もレスつけなきゃいいのにねw
一番熱心にIDかき集めてきたの君だけどw

795 :名前は開発中のものです。:2009/01/29(木) 22:34:32 ID:CK8Av1bR
すげぇチキンだなコイツ

796 :名前は開発中のものです。:2009/01/29(木) 22:46:01 ID:/PUT5suM
>>795
お前こそなにか主張はねぇよかよw

797 :名前は開発中のものです。:2009/01/29(木) 22:55:32 ID:CK8Av1bR
なんでオレに話しかけてくんだこのニワトリ
世話役の奴ちゃんと面倒見ろよ

798 :名前は開発中のものです。:2009/01/29(木) 23:05:24 ID:C5KCdvlq
おまえにまかせた

799 :名前は開発中のものです。:2009/01/29(木) 23:14:57 ID:/PUT5suM
>>797
ん?主張がないなら俺の勝ちだけど?w

800 :名前は開発中のものです。:2009/01/29(木) 23:20:53 ID:tPxukM8x
イタタタ

801 :名前は開発中のものです。:2009/01/29(木) 23:24:21 ID:/PUT5suM
>>800
おw
また頑張ってID集めてくんのか?w
自分のがナチュラルに痛いくせに人のこというのか?

802 :名前は開発中のものです。:2009/01/29(木) 23:26:29 ID:/PUT5suM
お前等、何度もいうけどデザパタよく読まないで書き込むからこういうことになるんだぞ
次はパターンも目的ぐらいは自分が適用した理由に添えられるように努力しろよ
いまのままじゃ恥ずかしいぞお前等

803 :名前は開発中のものです。:2009/01/29(木) 23:38:46 ID:KxuOv8bV
イベントドリブンなプログラムでobserverは基本中の基本だろ……
コールバックをOOPスタイルに抽象化したのがobserverだぞ
発言が面白すぎるので愛でさせてもらってるけどな


804 :ID:2rWIRnW3:2009/01/29(木) 23:47:12 ID:QSSosLPK
>>794
>は?誰?何聞いてるの?

いや、だから過去IDでコテ名乗ってるんだが
そうやって自分の都合の悪いときだけ痴呆症を発症されても困るんだわ
まず>>700。これは>>738でも催促しているよな。頼むわ。な。

>オブザーバーはタスクシステムじゃないってw

今度はなんの話だい?初っ端の>>672で既に回答は出してるよな
>>772でもそれは指摘してるよな。何度書いてもすぐ忘れるんだな

805 :762:2009/01/29(木) 23:48:20 ID:e5MgZbFT
だーもーお前ら整理してって言った自分が悪いのもわかってるけど、もうどうでもいいよw
自分はデザパタ本のオブザーバー読む機会が出来たから、ほー程度に思ってたが。

結局現在の論点は>>685->>686な状況を考えたとき、オブザーバーパターンが適用できるか。でしょ?
だれかあってるかどうか理由もつけていってよ。俺?今読んでる無理。



806 :名前は開発中のものです。:2009/01/30(金) 00:04:31 ID:9+H4SV2g
>>804
だからお前誰なんだよw

>>805
はぁ?冒頭の目的読むだけでこりゃちげーってわかるべw

807 :名前は開発中のものです。:2009/01/30(金) 00:06:54 ID:9+H4SV2g
>>805
>結局現在の論点は>>685->>686な状況を考えたとき、オブザーバーパターンが適用できるか。でしょ?
全然違うじゃん
そもそも>>686なんてタスクシステムと関係ないじゃん
完全にスレ違いな上に言ってることも間違ってる

808 :名前は開発中のものです。:2009/01/30(金) 00:14:45 ID:5R1NkGJS
>>805
普通に可だとおも
監視者(人とか)に対して監視対象(センサーとか)の数が多くて
その状態変化が滅多に起きないなら監視者が監視対象の状態を
毎回毎回全走査するよりもイベント駆動にするよ

それがobserverパターンになっていても何も不思議じゃないし

809 :名前は開発中のものです。:2009/01/30(金) 00:17:13 ID:ffjsoOsM
>>806
いや、冒頭の目的なら問題ないだろ。

いくら読んでもイベントと相違がみえねぇ。
強いてあげるなら、イベントを発生させる要因が、イベントを受け取るやつらから来る(≒相互参照)、という特殊な状況な事くらいか??
でもこれは本で挙げた例がそうなってるだけで、ここは重要ではないな。

>>807
いや・・・だから・・・タスクシステムは直接関係ない話題が延々と続いてるって事実がホントわかってないのがいるのか・・・
何度も俺や他のやつらが言ってるじゃん・・・何で人のレス読まないかなー

>>772よ、つまり>>807見たいのがいるんだよ。

810 :ID:2rWIRnW3:2009/01/30(金) 00:55:05 ID:JU1rNfjo
>>809
そうみたいだな。参った

811 :ID:2rWIRnW3:2009/01/30(金) 01:07:41 ID:JU1rNfjo
>>806
>だからお前誰なんだよw

俺の名前欄を見ろって。それでCTRL+Fでスレ検索しろよ。頼むよ。な。

>>807
>そもそも>>686なんてタスクシステムと関係ないじゃん
>完全にスレ違いな上に

それは>>685で断ってる

    【>>2が一切サポートしない機能の話しになるからアレだが】

スレ違いだと思うならグダグダ食ってかかる前に「スレ違いだろ氏ねカス」って開口一番に喚いとけって

>言ってることも間違ってる

確認するが、>>2と関係ない話という前提でも間違ってるって言ってるのか?正気か?
お前…「スレ違いだろ氏ねカス!」、俺…「この文盲野郎!バーカバーカ!」で決着させてもいいんだぞ?
いいのか?続けるぞ?

ではどうぞ。間違ってるところはどこ、説明してくれ、と延々再三催促してるからな。頼むわ。な。
あと俺もう寝るから。まぁ頑張って長考してくれ。な。
次に反応するのはたぶん数日後とかになるから別に焦らなくていい
続けたくなくなったら「スレ違いだろ氏ねカス!」ってちゃんと書くように

812 :名前は開発中のものです。:2009/01/30(金) 01:27:49 ID:kL+m0iCz
直近の流れはぶったぎって書く

タスクシステム総合スレの1らしきものがあったので読んでみた

http://www.23ch.info/test/read.cgi/gamedev/1173708588/

見事に話題ループしてて笑ったw

813 :名前は開発中のものです。:2009/01/30(金) 06:22:51 ID:9+H4SV2g
>>811
あれあれ?キレちゃったの?w

814 :名前は開発中のものです。:2009/01/30(金) 07:12:22 ID:9+H4SV2g
>>809
おw
やっと冒頭の目的を読んだ奴が出現
そうかそうかやっと読んだかw
まあ、読んだならわかると思うけど









どうみてもオブザーバー=タスクシステムですw
ありがとうございましたw

815 :名前は開発中のものです。:2009/01/30(金) 07:27:07 ID:65fIVgj5
不思議だよね
明らかにタスクシステムなのにこの点を指摘する人がでてこないの

816 :名前は開発中のものです。:2009/01/30(金) 09:41:25 ID:+pNTqaYg
えーと聞いていいかな
タスクシステム=オブザーバー・パターンという場合、そのタスクシステムはどういうもので
サブジェクトとオブザーバーはどこにあって、それはどういう振る舞いをするの?

タスクシステムって>>2を見る限りはリストひとつになんでもかんでも放り込んでごった煮にして
一定の時間間隔で定期的に巡回UPDATEする仕掛けを提供するだけで後はおまえらで勝手にやってね
というようなものにしか見えないんだけど、どこにオブザーバー・パターンがあるの?

817 :名前は開発中のものです。:2009/01/30(金) 10:52:34 ID:88nsX3SX
>>816
リストひとつになんでも放り込んで
→VSYNCイベントを受け取りたいオブザーバを登録して

一定の時間間隔で定期的に巡回UPDATE
→VSYNCイベントをオブザーバにnotify

ほら同じだ

818 :名前は開発中のものです。:2009/01/30(金) 11:26:26 ID:ffjsoOsM
>>814はびっくり発言連発するからほっとくとして。

>>817
それってまさにデザインパターンを強引に適用した、あるいは強引にそうみなそうとした、じゃね?
果たしてフレームの更新をsubjectの状態の変化と捉えるか普通? いや、捉えられないって言ってるわけじゃないけど。
また、パターン全般は再利用性があることが前提になる。もちろんクラスライブラリにしても意味のないパターンもあるが、
イベントなんてJavaやC#ならデフォがいる。そのくらいクラスライブラリ化が簡単に出来るものだ。

となると。オブザーバーパターンは、最低限のメソッドに提供することが前提で(可能な限り自由性を持たせる)、
クラスのある言語ならクラスライブラリとして構築できなきゃビミョーなんじゃないの?

でそう考えると。>>553に類似する構造が前提になりそうなんだが。
さてさてこのスレで散々語られてたタスクシステムはどうでしょうか。



819 :名前は開発中のものです。:2009/01/30(金) 11:45:35 ID:88nsX3SX
>>818
そうかなぁ
オブザーバってのは割り込みハンドラやシグナル、
イベントディスパッチャ/コールバックのようなものを
OOのデザパタとして記述したものでしょ
Document/Viewみたいなのにも使われるから、適用範囲はもっと広いけど

>>2はアセンブラかせいぜいCで記述されたものだろうから、そりゃ表面的には
違うだろうさ、だが本質的には別に大した違いじゃないように見えるけどな

VSYNCをイベントとして「捉えない」ほうが、俺には意味が分からないけど

820 :名前は開発中のものです。:2009/01/30(金) 12:04:53 ID:88nsX3SX
何となく論点の違いが分かった

タスクシステムとオブザーバは=ではないでしょ、そりゃ
タスクは昔のゲーム設計の一手法に過ぎないから、OOのデザパタほど
抽象化も汎化もしていない(し、その必要も無い)

別に誰もそんなことは主張してないと思うよ(少なくとも俺は)

821 :名前は開発中のものです。:2009/01/30(金) 16:47:08 ID:O2nIHOeq
デザパタは過去の技法をパターンとして集めただけだぞ?
抽象化されていなからデザパタより格下という論法がわからん

822 :名前は開発中のものです。:2009/01/31(土) 00:48:06 ID:vZh4GSBD
ゆーき先生の本がわかりやすいよね

823 :名前は開発中のものです。:2009/01/31(土) 02:06:18 ID:knmkZjZM
>>817
>→VSYNCイベントを受け取りたいオブザーバを登録して

タスクシステム=>>2では全ゲームオブジェクト(タスク)は必ずただひとつのリスト(タスクリスト)に
登録されることが義務付けられているぞ。ゲームオブジェクトに選択の自由なんて全然無いからな
どんな性質のゲームオブジェクトだろうと必ずVSYNC発生毎に通知を受けなければならないんだよ

タスクシステムというのは、ゲームオブジェクトとはVSYNCに依存して当然、依存しないなんてあり得ない
VSYNC発生の度に通知を受けることを全ゲームオブジェクトが望んでいるに決まっている、という仕組み
CodeZineのコードはゲームオブジェクト生成と同時に暗黙のうちに唯一のリスト(タスクリスト)に登録する

たとえばゲーム開始時点で生まれて一定時間経過後に何らかの行動を始めるゲームオブジェクトがあるとする
タスクシステムではこういう性質のゲームオブジェクトも生まれると同時にタスクリストに登録する
VSYNC発生の度に通知を送り続ける。このゲームオブジェクトは通知を受けるたびに行動開始の時間かどうかを
自分でチェックしなければならない。まだ行動開始の時刻でなければ何もせずに処理を返す。時間がくるまで
そういうことを延々繰り返す

このゲームオブジェクトが本来受け取りたいイベントというのは行動開始時間で、VSYNCイベントとの依存関係は
本来はない。でもタスクシステムではVSYNC(一定周期の)通知機能しか提供しないから仕方なくこれを代用して
自分でポーリングを行なっている

タスクシステムでは依存関係があろうがなかろうが通知を全員に送る。オブザーバー・パターンの目的とは違う

824 :名前は開発中のものです。:2009/01/31(土) 02:30:33 ID:2y83CUUn
デザインパターンで安全にタスクシステムを構築できるということについて
具体的に否定できるヤツは一人もいないなw

ファビョって否定してるやつが数人いるようにみえるがID変えてるだけのアホが一人なんだろうな。

825 :名前は開発中のものです。:2009/01/31(土) 02:41:36 ID:8CtHI7i5
>>823
んーちょっとよくわかんない

> このゲームオブジェクトが本来受け取りたいイベントというのは行動開始時間で、
> VSYNCイベントとの依存関係は本来はない。

より高い抽象度では、「時刻Xになったら行動開始」だけども、
実装レベルでは、結局のところVSYNC割り込み単位でのフレーム更新という
「必要」が先立ってるんでしょ?
コルーチンや継続のようなものが使えるのなら、VSYNC単位で微分せずに
もっと自然に書けるだろうけども、
「その設計では」VSYNCイベント通知が「必要」だから、そう作ってあるのでは?

設計の良し悪しとか、無駄が多いとかはいくらでも言えると思うんだけど、
「オブザーバとは違う」ということにこだわることにそんなに意味があるようには
俺には見えないけどねえ

オブザーバは単なるパターンだから、
オブザーブする対象は別にVSYNCイベントだろうがタイマだろうが構わないわけでしょ

826 :名前は開発中のものです。:2009/01/31(土) 02:44:15 ID:rIovvj90
>>824
安全には無理でしょ
明示的な引数がない時点でプログラムの作法云々なんてもう
気にしない組み方だと思うけどね

update();

で動くのと

update(jiki,teki,tama,unko);

で動くのとじゃ
プログラムとしては絶対に下のがいい
上は結局、その関数で何が必要なのか要素がまったくわからない
アクセスしているものを知るには中身のプログラムを読むしかないし

827 :名前は開発中のものです。:2009/01/31(土) 04:32:28 ID:gO0Oi008
趣味プログラマにはワケワカメw
ごった煮リスト+メッセージプロシージャでこれからも頑張っていきます( ^ω^;)ゞ

828 :名前は開発中のものです。:2009/01/31(土) 11:36:23 ID:9d5EHsE6
>>826
> プログラムとしては絶対に下のがいい

あんた、どんだけ素人なんだ…。
本当にプログラムが1行でも書けるのか。

829 :名前は開発中のものです。:2009/01/31(土) 11:54:07 ID:ZWCB0Sk3
素人目にも、上( update(); )のほうがよさそうに見えるのだが、俺はおかしいのか。

830 :名前は開発中のものです。:2009/01/31(土) 12:58:57 ID:p4gnaDmU
いや、やはり下の方がいいね。
下手にクラス変数に他のオブジェクトへのポインタを持たせたり、グローバル変数(シングルトン含む)を使ってしまうと、
オブジェクト間の関連が複雑になって、わけがわからなくなる。
各メソッドに処理に必要な情報(メディエータとか)渡すようにすると、
末端のオブジェクトは実にシンプルになる。

JavaのAWT/Swingでよく使うpaint(Graphics g)みたいにね。



831 :名前は開発中のものです。:2009/01/31(土) 13:16:50 ID:rIovvj90
>>828-829
素人もいいところだな
じゃ、上(update();)でアクセスしてるデータは何と何?

update関数の中をすべてみないとわからないでしょ?
これがグローバル変数の最大の害
下(update(jiki,teki,tama,unko);)ならjiki,teki,tama,unkoインスタンスにアクセスしていて
仮にソースでグローバル変数を使わないという決まりをきちんと守っていた場合
update関数によってこれら以外のインスタンスが変更されることは絶対にないという
ソースを読む側の確信がもてる
これはバグを追う場面でも強力に働く
これがキチンと守られているかどうかで
開発期間やプロジェクトで出る総バグ数がまるで違う結果になる(俺の経験)
だからタスクシステムはバグが増える

ヘッダファイルにしても同じ
必要なヘッダを必要な分だけインクルードしてるソースなら影響するクラスがわかりやすい
が、タスクシステムはごった煮ソースになるので
ほぼ全クラスを一括インクルードしなければ動かないとかかなり糞
これではバグがいつまでたっても減りませんわw

832 :名前は開発中のものです。:2009/01/31(土) 13:31:15 ID:8N26Dxd2
安全性ってのは2つの観点があるんじゃね?
・メモリ上のオブジェクト寿命の保証
・データ確定性の保証

データ確定性というのは「今このデータ更新中だからアクセスしないでね」っていう期間に
ちゃんと排他制御出来てること(更新してるやつ以外はアクセスしないで待ってること)。

上(update();)はスマートポインタ使うから安全って言いたいのかもしれないけど、
スマートポインタが解決できるのはメモリ上のオブジェクト寿命の保証のみ。
データ確定性の保証は別途対策が必要。

それに比べて下はオブジェクト間の関係性が単純化できているから
データ確定性の保証もしやすい。
だから下が良い。

833 :名前は開発中のものです。:2009/01/31(土) 14:22:57 ID:qt9xmuQG
>>831
>>ほぼ全クラスを一括インクルードしなければ動かないとかかなり糞
お前タスクシステムで組んだこと一度もねーだろ

834 :名前は開発中のものです。:2009/01/31(土) 14:27:19 ID:rIovvj90
>>833
あるし、ちゃんとタスクシステムでゲームを3本ぐらいコサエタよ
どれも途中参加だったけどかなり苦痛だったな

835 :名前は開発中のものです。:2009/01/31(土) 14:29:40 ID:qt9xmuQG
>>834
じゃあソースの分け方が下手なだけだ、タスクシステムだからって理由でそんなことには絶対ならない

836 :名前は開発中のものです。:2009/01/31(土) 14:34:18 ID:rIovvj90
>>835
ふーん、じゃそれでいいよ
ただ、そうしないとごった煮判別のところでやりにくいだけだと思うけどね
どうせわからないんだから一括でインクルードしちゃえばいいじゃん
って俺は思ったけどね(タスクシステムプロジェクトに参加してるときは)
グローバル変数も当然のように使いまくりになるしいまさらそんなところ争っても
大した違いにならないのでこの話(ヘッダの話)はここで終わりにしてくれ頼む

837 :名前は開発中のものです。:2009/01/31(土) 14:49:50 ID:9d5EHsE6
>>830
> JavaのAWT/Swingでよく使うpaint(Graphics g)みたいにね。

Graphicsのような汎用contextを引数として渡すのは構わない。
826はupdate(jiki,teki,tama,unko);のようにそのゲーム専用でかつそのタスク専用のcontextを渡しているわけで、
そんなものを渡すとその部分を抽象化できなくなる。

>>831
> じゃ、上(update();)でアクセスしてるデータは何と何?
> これがグローバル変数の最大の害

グローバル変数を使うだなんて一言も言ってないし、実際updateメソッドのなかでは
グローバル変数なんかにはアクセスしない。

> update関数によってこれら以外のインスタンスが変更されることは絶対にないという
> ソースを読む側の確信がもてる

そんなことは全く保証されないし確信が持てるわけではない。
updateメソッドでは自由に他のインスタンスにアクセスできる。

838 :名前は開発中のものです。:2009/01/31(土) 14:57:52 ID:qt9xmuQG
>>836
そうやって一括でインクルードするからわからなくなるって自分で言ってんじゃないの?矛盾してるよ、
ソースがしっかり分かれていればupdateの引き数で判断しなくても何がインクルードされてるかで判断できるよ。

839 :名前は開発中のものです。:2009/01/31(土) 14:59:25 ID:9d5EHsE6
>>832
> 上(update();)はスマートポインタ使うから安全って言いたいのかもしれないけど、

そんなことは俺は言っていない。

updateの引数として、汎用性のないcontextを渡すと呼び出し部分も呼び出される部分も抽象化できない。
それが最大の弊害であり、やるべきではない理由である。

>>833
実際831はド素人。「タスクシステムはごった煮ソースになる」の時点でド素人。

template<class Context> class Task
{
virtual void update(Context context);
};
こう抽象化しておいて、std::list<Context> tasksに対してforeachでupdateを呼び出すだけ。
「ほぼ全クラスを一括インクルードしなければ動かない」なんでド素人もいいところ。




840 :名前は開発中のものです。:2009/01/31(土) 15:02:01 ID:9d5EHsE6
>>836
> ただ、そうしないとごった煮判別のところでやりにくいだけだと思うけどね

「ごった煮判別」ってなんだ?

> グローバル変数も当然のように使いまくりになるしいまさらそんなところ争っても

タスクシステムを使ってようが、グローバル変数なんてひとつも使わないぞ。

あんたみたいなド素人、仕事に参加されると迷惑きわまりない。
俺が教えてやるから、何がしたいのか詳しく書いてみな。俺がお手本を見せてやんよ。

841 :名前は開発中のものです。:2009/01/31(土) 15:09:27 ID:j5ds1u2H
一括インクルードとかグローバル変数使いまくりとか、
単にそのチームが酷かっただけのように思えるが。

842 :名前は開発中のものです。:2009/01/31(土) 15:12:32 ID:8TBQ0Fdj
ID:rIovvj90は途中参加って言ってるし。
ゼロからタスクシステムを組んでみたら、どういうものか分かると思う。
そうすればグローバル変数とか関係ないことがわかる。

>>841
そういう理由があっても、それがすべてと思って批判するのはどうかと思う。

843 :名前は開発中のものです。:2009/01/31(土) 15:13:38 ID:8CtHI7i5
いや発言のレベルが流石に低すぎるから
ただの釣りか、BASICやHSPぐらいしか知らないド素人なんでしょ

OOPを知らないのは確実だけど、Cでもちょっと抽象化したコードを
読み書きしたことはなさげ

844 :名前は開発中のものです。:2009/01/31(土) 15:18:02 ID:rIovvj90
>>839
だからそれってソースをみたときに何が渡されてるのか確定できんの?

845 :名前は開発中のものです。:2009/01/31(土) 15:18:54 ID:rIovvj90
単純に>>826の問題は解決してないように見えるけど?

846 :名前は開発中のものです。:2009/01/31(土) 15:20:49 ID:9d5EHsE6
>>832
何故そこでスマートポインタが出てくるのか意味不明なんだが、
updateで引数がないということは次のようになっていると俺は想定している。

template <class Context>
class Task
{
public:
Task(const Context& context_) : context(context_) {}
virual void update();
private:
Context context;
};

それぞれのタスクはこのTaskクラスから派生させる。

updateメソッドでは、this.context に対してアクセスするので、スマートポインタなんか使う必要はないし
グローバル変数も使わない。

847 :名前は開発中のものです。:2009/01/31(土) 15:21:53 ID:rIovvj90
>>846
>、this.context に対してアクセスするので、
これが何か知らないんだけど説明してくれない?

848 :名前は開発中のものです。:2009/01/31(土) 15:23:19 ID:9d5EHsE6
>>844
> だからそれってソースをみたときに何が渡されてるのか確定できんの?

何が言いたいのかよくわからん。

「何が渡されてるか」って、updateの引数がないのだから、何も渡されていない。
C++でメソッド呼び出しなら、thisが渡されている。

と確定できるが?

849 :名前は開発中のものです。:2009/01/31(土) 15:25:08 ID:rIovvj90
>>848
仮に呼び出し側で>>862のような違いを
見つけたいソース(=引数を明示的にしたい)を書きたい場合にはどうするの?

850 :名前は開発中のものです。:2009/01/31(土) 15:25:28 ID:rIovvj90
>>862
>>826

851 :名前は開発中のものです。:2009/01/31(土) 15:27:05 ID:9d5EHsE6
>>847
>>、this.context に対してアクセスするので、
> これが何か知らないんだけど説明してくれない?

templateになっていて、ゲームを作りたいなら、そのゲームでタスクにとって必要なcontextを入れるんだ。

例えば、シューティングゲームで敵の弾だけ列挙したくて、それをタスクリストからdynamic_castなどで型判別するのが
嫌なら、このcontextに

std::list<Task*> enemy_shot_tasks;

というstd::listを持たせておく。そうすれば、敵の弾に対してforeachしたりできる。
描画するのにGraphicsクラスが必要なら、それもこのcontextに持たせておく。


852 :名前は開発中のものです。:2009/01/31(土) 15:28:55 ID:9d5EHsE6
>>849
> 仮に呼び出し側で>>826のような違いを見つけたいソース
> (=引数を明示的にしたい)を書きたい場合にはどうするの?

呼び出し側は、単に、一定のタイミングごとにupdateを呼び出すだけの存在であって、
呼び出し側に違いが現われるのは論理的におかしく、設計がまずい。

だから、呼び出し側にそのような違いを見いだそうとすること自体がおかしい。

853 :名前は開発中のものです。:2009/01/31(土) 15:33:03 ID:8CtHI7i5
>>849
詳細で個別的なメソッド呼び出しが必要で適している状況ではそうすればいいし、
そうするだけだよ

上のupdate()のような例では、呼び出し側は、オブジェクト間の差異を
意識したくない、統一的に扱いたいから、より抽象度が高い方法でやるだけさ

差異を選択的に無視して、問題をそれに適した/適切な抽象度で
扱えるようにすることが「設計」でしょ

車の運転をしているときに、エンジンに使われているネジのことなんぞ
いちいち気にしたくはないわけだ

854 :名前は開発中のものです。:2009/01/31(土) 15:38:27 ID:j5ds1u2H
>>842
俺もそう思うよ。
批判すべきはチームの設計・開発体制であって、タスクシステム自体の是非はまた別の問題。
ID:rIovvj90はそのへんの問題点の切り分けが出来てないんだな。
坊主憎けりゃ袈裟までってやつか。
途中参加した3本が全部別々のチームなんだったら、流石にその不運には同情するが。

855 :名前は開発中のものです。:2009/01/31(土) 15:44:45 ID:9d5EHsE6
俺には 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)に持たせておきこれをチェックするのが普通。

856 :名前は開発中のものです。:2009/01/31(土) 15:49:35 ID:8N26Dxd2
>>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まわり恐らく書き方違うだろうけど意図は大体通じるよね?

857 :名前は開発中のものです。:2009/01/31(土) 15:57:08 ID:9d5EHsE6
>>856
> そこでスマートポインタ使うから安全って言うのかと思った。
> そうでなければどういう意味で安全といったの?

すまんが、俺は「安全」という言葉は一言も言ってない。
「安全」と言ったのは俺じゃない。

俺は、オーバーヘッドがあるから、スマートポインタを使わなくて済むところでは
使わないし、この手のタスクをコントロールするのにスマートポインタは持ち出さない。
またオブジェクトが生きているかどうかの判定については >>855 で書いた。

ただ、
> Contextとやらでポインタ使うことになるっしょ。

については、このContextが保持しているstd::listなりstd::mapなりは、
Taskの解体の時に自動的にここから該当タスクのポインタをremoveするので
このstd::listなりstd::mapなりにあるオブジェクトが実在して、かつ生きている
ことだけは保証される。だから>>855 の方法で問題ない。

858 :名前は開発中のものです。:2009/01/31(土) 16:00:48 ID:9d5EHsE6
いま読み返してみたら、855の書き方が悪かったので以下補足&修正とお詫び。

> Task chainに対して、
> tasks.isContain(jiki)
> のような判定が必要である。

だけど、tasksから一度removeされて、同じメモリがオブジェクトに割り当てられる
ことがあるので、このjikiというのは、オブジェクトのアドレスやポインタではなく
incremental ID(いわゆるhandle)だ。

誤解を生じさせる書き方をして済まない。

859 :名前は開発中のものです。:2009/01/31(土) 16:14:46 ID:8CtHI7i5
contextって俺は長命オブジェクトをイメージしてるんかと
思ったけど、違うの?
マネージャなりメディエータなり

よくある子に親への参照を持たせているようなケースは、
親が先に死なないデザインなら安全

オブジェクト間の相互参照グラフが無軌道に複雑化する場合は、
確かにGCなしでは酷いことになるだろうし
IDルックアップを毎回やるのは遅そうだな

860 :名前は開発中のものです。:2009/01/31(土) 16:21:35 ID:rIovvj90
>>852
その状態でなんで>>826,830-832の内容を否定するの?
俺が書いたのは>>831のみだけど
その状態をダメだって言ってるのが>>826,830-832の内容なわけ

ソースの記述で引数を明示的に表現しなければならないって話なのよ?
タスクシステム使うと完全に>>826,830-832の問題をどうにもできないでしょ?
ソースの記述で引数を明示的に表現できる?
(ま、別にする必要がないって主張をもってるからタスクシステム派なんだろうけどさw)

861 :名前は開発中のものです。:2009/01/31(土) 16:28:02 ID:9d5EHsE6
>>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で実装するのがスマートだと思うな。

862 :名前は開発中のものです。:2009/01/31(土) 16:30:05 ID:9d5EHsE6
>>860
> ソースの記述で引数を明示的に表現しなければならないって話なのよ?

何故そんな必要があるのか、そのメリットがどこにあるのか俺には全く理解不能だ。

863 :名前は開発中のものです。:2009/01/31(土) 16:38:26 ID:8CtHI7i5
なんとなく論点のズレが分かった

ID:rIovvj90
は、タスクマネージャからのupdate()呼び出し
以外の関数呼び出しは一切存在しない(あらゆるオブジェクト間の相互作用を
それで解決する)プログラムを仮定しているように見える

他の人は(ID:9d5EHsE6)は、誰もそのようなものは仮定していない

普通に引数を使うところでは勿論使うわけで、
あくまでジェネリックなupdate()を書く時の作法として
どっちが適切かという話をしていただけでしょ

864 :名前は開発中のものです。:2009/01/31(土) 16:41:05 ID:9d5EHsE6
>>863
正解。

865 :名前は開発中のものです。:2009/01/31(土) 16:43:43 ID:rIovvj90
>>863
違うってなんで曲解するんだ?
update関数の中でアクセスするインスタンスがソースの記述から
わからないのがダメだって言ってるんだ(もちろんダメだと思わなければそれまでだがw)

>>826,830-832で言ってることがすべてだって
これがわからないって経験値が低いぜ
わかってやってるってのも俺的にはちょっと考えにくいんだけどね

866 :名前は開発中のものです。:2009/01/31(土) 16:46:49 ID:8CtHI7i5
>>865
> update関数の中でアクセスするインスタンスがソースの記述から
> わからない

???
C++だからthisポインタ越しに、オブジェクト参照をたどるだけでしょ
参照はメンバ変数に持っているのだし

何が「わからない」のかが分からない

867 :名前は開発中のものです。:2009/01/31(土) 16:49:34 ID:9d5EHsE6
>>865
> update関数の中でアクセスするインスタンスがソースの記述から
> わからないのがダメだって言ってるんだ

何度でも言うが、そんなものはわかる必要がないんだ。

Javaのupdate(Graphics g)メソッドひとつにしても
updateメソッドのなかでGraphics以外のオブジェクトにアクセス
することは当然あるし、それを禁じる方法はないし、
update(Graphics g)というシグネチャを見てGraphicsにしかアクセス
しないと判断することは出来ないし、
実際そんなコーディングスタイルで書く必要もないし、
そんなコーディングスタイルを強要されるとまともにプログラムを書けない。

868 :名前は開発中のものです。:2009/01/31(土) 16:52:11 ID:9d5EHsE6
すべてのタスクファイルのヘッダをincludeして
それが普通だと思っているID:rIovvj90みたいなド素人と
話していても時間の無駄なので俺は、ID:8CtHI7i5と勝手に話を続ける。

869 :名前は開発中のものです。:2009/01/31(土) 16:52:32 ID:9d5EHsE6
■ 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は安全
}

こうなるな。

870 :名前は開発中のものです。:2009/01/31(土) 16:56:11 ID:9d5EHsE6
>>869 の続き。

TaskHandle enemy1;
TaskHandle enemy2;

に対して

EnemyTask* enemyTask1 = TashHandleToPtr<EnemyTask>(enemy1);
EnemyTask* enemyTask2 = TashHandleToPtr<EnemyTask>(enemy2);
if (enemyTask1!=null && enemyTask2!=null)
{
 // これらのタスクは生存している
 update_something(enemyTask1,enemyTask2);
}

という生存チェックが必要になるな。仕方ないと言えば仕方ないが、
使う前に必ず必要なのがちょっとうざい気はする。

871 :名前は開発中のものです。:2009/01/31(土) 16:58:07 ID:8CtHI7i5
>>869
まあ概ね想定どおりっすね
俺の考えを言うと、

・C/C++なら、そもそもオブジェクトの相互参照グラフを整理する
 のがベスト

・問題が不可避な場合にはGC, スマポ, ID管理などの解決方法があるが、
 スマポは良く知られているように巡回参照には無力(そもそもグラフが
 複雑化したから欲しくなったはずなのだから、それでは意味が無い)
 
 ID管理が一番シンプルでポータブル、仮に全てが利用できると
 仮定した場合、性能や特失に関しては研究の余地あり(ただ、ゲームでは
 いずれにせよGCは利用しにくいでしょうね)

ってとこかしら

872 :名前は開発中のものです。:2009/01/31(土) 17:00:55 ID:9d5EHsE6
>>871
>(ただ、ゲームではいずれにせよGCは利用しにくいでしょうね)

これは何故?俺は、C#で商用ゲームプログラムを書いたけど
別にGCがあるので困るということはなかったのだが。

どんなことが問題だと思ってるの?

873 :名前は開発中のものです。:2009/01/31(土) 17:03:36 ID:8CtHI7i5
>>872
優秀な世代別GCで、決してワールドがストップしないと
確信できるケースでは、問題ないかもしれません
その確信が持てないなら、ゲームでは難しいかもしれません

ということです

874 :名前は開発中のものです。:2009/01/31(土) 17:06:51 ID:9d5EHsE6
>>873
> 優秀な世代別GCで、決してワールドがストップしないと
> 確信できるケースでは、問題ないかもしれません

それが確信できないとそもそもXNAでプログラミングなんて出来ないわけで…。

あ、もちろん、大きなリソースを解放するときは要注意なのでそのタイミングは
なるべくコントロールしてやる必要があるけども。それはC++でも一緒なわけで…。

875 :名前は開発中のものです。:2009/01/31(土) 17:07:52 ID:9d5EHsE6
>>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

876 :名前は開発中のものです。:2009/01/31(土) 17:08:52 ID:8CtHI7i5
>>874
いやその、「C#でゲームプログラミングは不可能である」という主張ではないので
誤解無きよう
そういう意味では、「GCはゲームではありえない」と読み取れるので、
強い主張すぎたかな、訂正します

877 :名前は開発中のものです。:2009/01/31(土) 17:12:32 ID:9d5EHsE6
>>876
いやまあ、C#で弾幕シューティング作ったら、やっぱり
GCが変なタイミングで動いてときどきカクカクなるから
object poolingするコードをtemplateで書きまくったとか
そういうことは日常茶飯事なので、GCに対して世間の目が
冷たいのはよくわかってるつもり。

このスレの趣旨に見合う形で話を戻すと、GCつきのほうが
タスクのinteractionは楽に書けることは書けるけども、
それでもC++でも >>875 のように書けるなら、さほど手間は
変わらないと思う。

878 :名前は開発中のものです。:2009/01/31(土) 17:16:15 ID:rIovvj90
>>866
それは別クラスのポインタの保持をするってこと?
まあ、ようは関数読んだときにアクセスしてるクラスがわからないようなのはダメってことよ
当然そういうメンバに別クラスのインスタンスのポインタを保持させるようなのも禁止だよ

>>867
それができるんだよ
グローバル変数・関数の使用禁止(当然スタティックとかも禁止)とか徹底して
メンバに別クラスのインスタンスの保持禁止にするのをちゃんと徹底すれば
後、可能性があるのは引数とメンバ変数ぐらいだろ?
こうするとバグが比較にならないほど減るぞ

自分で一度この方式でプログラム組んでみてほしいね
決して面倒臭くない
むしろ開発が進むにつれこっちのが作りやすいとわかるはず

しかも読む人間もソースを追いやすいからバグの発見も早い

879 :名前は開発中のものです。:2009/01/31(土) 17:20:08 ID:9d5EHsE6

>>878
> メンバに別クラスのインスタンスの保持禁止にするのをちゃんと徹底すれば
> 後、可能性があるのは引数とメンバ変数ぐらいだろ?

別クラスのインスタンスの保持をすると何故いけないと思うんだ?

親オブジェクトが子オブジェクトのstd::listなんかを持っているのは普通であり、
当たり前だろ?これを禁止するなら、どのオブジェクトがある親オブジェクトに
対する子オブジェクトを持っていると言うんだ?具体的にソース書いて見せてくれ。

880 :名前は開発中のものです。:2009/01/31(土) 17:24:54 ID:8N26Dxd2
>>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)を導入することの利点について考えたこと有りますか?
きちんと比較したことありますか?という辺り

881 :名前は開発中のものです。:2009/01/31(土) 17:27:48 ID:9d5EHsE6
>>878
ひょっとして
> メンバに別クラスのインスタンスの保持禁止にする

の「インスタンス」には「std::list<EnemyTask*>」のようなものは
含まれないのか?これも立派な「インスタンス」だと思うんだが。

何かコンピュータ用語以前に、ID:rIovvj90は日本語が不自由で
何が言いたいのかよくわからない。

そもそも俺にしても >>875 のようなスタイルで書いているわけで
別のTaskのインスタンスなど(compositionでの)保持はしない。

しかしHandleは保持する。それは、参照するのに必要だからである。

882 :名前は開発中のものです。:2009/01/31(土) 17:39:37 ID:9d5EHsE6
>>880
あなたの想定しているように、ゲーム画面ではプレイヤと弾と敵が
存在するが、タイトル画面ではそんなものは存在しないという場合、
タイトル画面を構築に不要なものを排除して、タスク間のinteractionを
なるべく簡素で見える形にしたいという動機は当然ありえる。

それでも
> Scene::update(void) {
>  player.update(jiki,teki,tama,unko);
>  enemy.update(jiki,teki,tama,unko);
>  bullet.update(jiki,teki,tama,unko);
>}
は良くない。この書き方はド素人くさい。

883 :名前は開発中のものです。:2009/01/31(土) 17:41:19 ID:rIovvj90
>>882
>は良くない。この書き方はド素人くさい。
良くない理由はなんで?

884 :名前は開発中のものです。:2009/01/31(土) 17:41:49 ID:8N26Dxd2
>>882
そう、結局そこに帰結する。
>この書き方はド素人くさい。

この1点の是非

885 :名前は開発中のものです。:2009/01/31(土) 17:43:39 ID:j5ds1u2H
メンバもグローバルも駄目なら、
update(jiki,teki,tama,unko)を呼ぶ側のクラスは
jiki,teki,tama,unkoをどこに持ってるんだ?
main関数のローカルに持って、延々と渡していくのか?

まあ、そんなことより、
ID:9d5EHsE6のタスク周りの実装をもう少し聞きたいな。
新しいContextを追加すると、Taskのリストがひとつ増えるんだよね?
そのリストは誰がどういうふうに持つの?

886 :名前は開発中のものです。:2009/01/31(土) 17:48:59 ID:9d5EHsE6
>>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;
};
こう書くべきだろう。

887 :名前は開発中のものです。:2009/01/31(土) 17:49:22 ID:9d5EHsE6
>>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クラスにも依存していないということだ。

888 :名前は開発中のものです。:2009/01/31(土) 17:51:28 ID:9d5EHsE6
>>885
> ID:9d5EHsE6のタスク周りの実装をもう少し聞きたいな。
> 新しいContextを追加すると、Taskのリストがひとつ増えるんだよね?

増えない。Contextはタスク階層ごとに必要となるだけ。cf. >>886

889 :名前は開発中のものです。:2009/01/31(土) 17:56:00 ID:8CtHI7i5
>>880
> オブジェクト間関係の見える化の推進度合い

詳細を「隠したい」場合と「見たい」場合があるはずなので、
その場合はどっちですか、という話になるだけでは。
ネジ一本のツクリまで気にしなければ運転できないような車は設計の欠陥で、
「見える」ことが常に良いことである、という発想は誤りです。
OOPのカプセル化やポリモーフィズムの意味を理解してください。

>>885
直接のインスタンス参照ではなく、事実上参照代わりに使えるハンドル(ID)を
持っていると書いてあったと思うけど。
勿論それは寿命が微妙な短命オブジェクトの話で、
寿命管理が明確な長命オブジェクトは直接参照でしょう。

890 :名前は開発中のものです。:2009/01/31(土) 17:58:00 ID:8N26Dxd2
>>889
ネジ一本のツクリまで気にして設計してある車でなければ運転したくないです。
運転手の話したいの?
設計者の話でしょ?

891 :名前は開発中のものです。:2009/01/31(土) 18:00:52 ID:8CtHI7i5
>>890
クラスAを作るとき、クラスAを利用する人間は、クラスAのユーザになる。
どちらも同じ人間かもしれないが、クラスはユーザに対しては詳細を
隠蔽するように働き、汚い泥仕事はその中に閉じ込め、問題の局所性を
高める。
本当にネジを気にしなければならないコードを局所化するわけだ。

OOPどころか、構造化プログラミングの基本中の基本ですので、
一から勉強しなおして下さい。

892 :名前は開発中のものです。:2009/01/31(土) 18:05:52 ID:9d5EHsE6
>>891
> 問題の局所性を高める。

そのためには、あるオブジェクトが実装のために利用するオブジェクトの
種類について >>882 のように制約をかけたいという欲求はあるのでは。

だからこそ俺は、template <class Context>とContextを用いて、
こいつにしかupdateメソッドのなかではアクセスしないという制約
のかけ方を示し >>886 、さらにそれを抽象化して >>887
何故、update(jiki,teki,tama,unko);と書くのが良くないのかに答えた。

893 :名前は開発中のものです。:2009/01/31(土) 18:19:35 ID:8CtHI7i5
意味論的にupdate()をどう捉えるかでしょう

update()の抽象的意味が、「VSYNCを通知する」ということであれば
(というか多分そうだと思うのですが)
jikiだのtekiだのtamaだのunkoだのといった情報は抽象的意味とは無関係な
代物、ということになります。

引数jiki, teki, tama, unkoを取るupdate()の「意味」は何でしょうか?

894 :名前は開発中のものです。:2009/01/31(土) 18:22:23 ID:j5ds1u2H
>>888
Task<GameGlobalContext> のリストは TaskList<GameGlobalContext> で、
Task<SceneXXXContext> のリストは TaskList<SceneXXXContext> なわけでしょ?
Contextが増えたらTaskListが増えてるじゃん。
Contextの種類数=リストの種類数ってことなんじゃないの?

895 :名前は開発中のものです。:2009/01/31(土) 18:25:58 ID:9d5EHsE6
>>893
> update()の抽象的意味が、「VSYNCを通知する」ということであれば
> jikiだのtekiだのtamaだのunkoだのといった情報は抽象的意味とは無関係

ああ、それは正しいね。通知するだけなら、引数は必要ないね。

ただ、世の中のイベントハンドラがすべてそうであるように、
そのハンドラのなかで使いたいであろうもの(マウスイベントならばマウスの状態、
キーボードイベントなら押されたキーの情報)を引数として渡すのは常識的なことなので
今回のケースも、updateなら何らかのContext(それは描画のためのものであったり、
そのSceneで使うものであったり)が付随していてもそれはおかしくはないと思うけど。

896 :名前は開発中のものです。:2009/01/31(土) 18:35:35 ID:8CtHI7i5
>>895
ええ、そうですね
Cならば、コールバックの第一引数として、いずれにせよthisポインタ代わりのもの
を使うのが普通ですし

ところで、違う目的のものに同じ"Context"という用語を用いているのは
混乱の元のように見えます

引数渡しをする場合には、テンポラリな情報のジェネリックラッパーを仮定していて
依存性をオブジェクト生成時に注入している場合には、長命オブジェクトへの
参照を仮定しているのではありませんか?

897 :名前は開発中のものです。:2009/01/31(土) 18:46:16 ID:rIovvj90
>>885
メンバはダメじゃないだろ
ただ、別クラスのインスタンスのポインタの保持が禁止なだけ
それとupdateの例ではなにやらゲームのオブジェクトのクラスに
同じゲームオブジェクトのjiki,teki,tama,unkoを突っ込んでるようなソースに
なってしまっているがこれも間違いでありえない
仮にシーンクラスなんてのがあったらそこのメンバとして
jiki,teki,tama,unkoをもつ

ちなみに俺が最初に書いたソースのupdateはゲームオブジェクトの更新処理のつもりの
updateだったが引数でゲームオブジェクトを入れてるのは間違い
必要な情報だけ入れる
まあ、この場で話す分にはあんまり気にしなくておk

898 :名前は開発中のものです。:2009/01/31(土) 18:46:59 ID:9d5EHsE6
>>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の種類を減らして
生成されるコードを縮めることにある。

899 :名前は開発中のものです。:2009/01/31(土) 18:58:37 ID:9d5EHsE6
>>896
> ところで、違う目的のものに同じ"Context"という用語を用いているのは
> 混乱の元のように見えます

どれとどれが違う目的?
また、どう呼ぶべきだと思う?

ここで言うContextはtemplate class名なのでtemplate <class T>のTみたいなもので
それほど厳密な意味や名前は必要ないと思うのだけど。
(あったほうが理解したり、読みやすかったりするんだろうけど)

また、updateメソッドはContextとメンバ変数の状態のみによって、
次のContextの状態を作り出すことが出来るので、DFAと見なせる。

だもんで、CFTG(context-free tree grammar)とかの "context" という用語を
ここに持ってくるのはおかしくないと思ったんだけどな。

900 :名前は開発中のものです。:2009/01/31(土) 19:14:54 ID:8N26Dxd2
>>886

> >>882 そういう動機なら
って番号ずれてる?
>>884 以降流れについていけてない俺に愛の手を

901 :名前は開発中のものです。:2009/01/31(土) 19:21:22 ID:9d5EHsE6
>>900
番号はずれてない。
>>886 の「そういう動機」の「そう」が指すのは、 >>882 の 「あなた」から「したいという」まで。

わかりにくくてすまん。

902 :名前は開発中のものです。:2009/01/31(土) 19:31:42 ID:j5ds1u2H
>>898
その場合、呼ばれる側はdynamic_castか何かで必要なContextの型に変換するんだよね。
呼ぶ側がどのContextを渡すかはどうやって判断するの?

903 :名前は開発中のものです。:2009/01/31(土) 19:31:50 ID:9d5EHsE6
俺、実は主婦なので、いまから買い物にいかなきゃならん。

そんなわけで、明日まで、返答できない。

904 :名前は開発中のものです。:2009/01/31(土) 19:35:06 ID:9d5EHsE6
半額セールがはじまる時間なんだ…。

>>902
> その場合、呼ばれる側はdynamic_castか何かで必要なContextの型に変換するんだよね。

この場合は、しない。

place holder的に、Contextの派生型だけ宣言しておく( >>898 )という使い方がありうると言いたかっただけ。
902を混乱させたようで悪かった。些末な問題なので、忘れてもらって構わない。

905 :名前は開発中のものです。:2009/01/31(土) 19:57:21 ID:8CtHI7i5
>>899
> (あったほうが理解したり、読みやすかったりするんだろうけど)
無論、議論の参加者にとってはそのほうが良いわけですから、
その点の指摘に過ぎませんよ。

> また、updateメソッドはContextとメンバ変数の状態のみによって、
> 次のContextの状態を作り出すことが出来るので、DFAと見なせる。

updateメソッドの引数としてのcontextという名前が非常に典型的であるのは
その通り(特にその中身がopaqueで、その意味内容をその場で論じたくない場合)
ですが、一方クラスメンバの名前としては、「context」は適切で意味が
明快な名前であるとは言いがたいでしょう。

906 :名前は開発中のものです。:2009/01/31(土) 21:06:47 ID:rIovvj90
タスクシステム信者いたんだ?w
なんかタスクシステムがヤバクなるとスレを流しにかかるよねw
>>826,>>830-832からの一連のレスは面白いから次のスレにも貼ろうw

907 :名前は開発中のものです。:2009/01/31(土) 21:14:54 ID:8N26Dxd2
>>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());
   }
 }
(続く)

908 :名前は開発中のものです。:2009/01/31(土) 21:21:41 ID:8N26Dxd2
(続き)
最後に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); が良い。

909 :名前は開発中のものです。:2009/01/31(土) 21:42:33 ID:9d5EHsE6
買い物から戻ってきた。

>>905
> ですが、一方クラスメンバの名前としては、「context」は適切で意味が
> 明快な名前であるとは言いがたいでしょう。

俺の書いた、>>886では、そのメンバ変数の宣言は、
 SceneXXXContext context;
となっているけど、
A) SceneXXXContextのメンバ名がcontextとなっているのが適切ではない
と言いたいのか、
B) SceneXXXContextという名前が十分わかりやすいものではない
と言いたいのか、どちら?

俺としては、SceneXXXContextの変数名がcontextなのは、
大きなクラスでない限りはそれくらいの省略は許されるべきだと
思うんだが。また、SceneXXXContextは、SceneXXXを構築するのに必要な
文脈という意味で、意味明瞭だと思うのだが。

910 :名前は開発中のものです。:2009/01/31(土) 21:46:18 ID:8CtHI7i5
>>909
ああ、申し訳ないっす。後のほうの話を念頭に置いてなかった。
そっち見りゃ、少なくとも「なんのつもりか」は分かるでしょうね。


911 :名前は開発中のものです。:2009/01/31(土) 21:51:42 ID:9d5EHsE6
>>910
了解

912 :名前は開発中のものです。:2009/01/31(土) 21:54:52 ID:9d5EHsE6
>907-909
> 理由はゲームオブジェクト間は通信が多いので引数渡しを使用可能としたいため。
> タスクでは引数渡しができないのが嫌。

タスクでは引数渡しがなんで出来ないの?

template <class Context>
void update(const Context& context);

このcontextって引数渡しでない?
それとも、これはいわゆるタスクではないの?

「オブジェクト間の通信」って何がしたいのかよくわかんないのだけど、
Handle経由で参照すれば(>>875)いいじゃん。

どうせ、ゲームオブジェクトにしてもそのオブジェクトの
生存の確認は必要なんだろうし、>>875 のコードと何ら変わらないんじゃ?

913 :名前は開発中のものです。:2009/01/31(土) 22:22:05 ID:8N26Dxd2
>>912
実質グローバル変数渡ししかできないから。

foreach t (teki) {
  if (jiki.hit_check(t.get_hit_area())) {
    jiki.set_hp(jiki.get_hp() - t.get_attack_point());
  }
}
これならそもそも生存してるやつ同士しか参照が発生しないから生存確認必要ないかと

914 :名前は開発中のものです。:2009/01/31(土) 22:24:13 ID:rIovvj90
>>912
明示的なって意味じゃねぇの?
だいたいそんな十把一絡な引数あってもしょうがねぇし

引数はソースコードに明示的にわかるようなものでないと俺は意味がないと思ってる
グローバルにしてテキトーに渡したほうが速いじゃん

915 :名前は開発中のものです。:2009/01/31(土) 22:34:27 ID:9d5EHsE6
>>913
> 実質グローバル変数渡ししかできないから。

何故、そう思ったのかは知らないが、俺の書いたソース( >>869-870,875 )では
グローバル変数なんか経由していないし使ってもいないし、使うつもりもないのだが。

だから俺には、何が言いたいのかさっぱりわからない。

そもそも>>908の「ゲームオブジェクト」が何を指すのかがわからない。
「タスク」とどう違うのか。

そもそも、俺の「タスク」(>>846)とは「タスク」そのものが違うような気がする。

916 :名前は開発中のものです。:2009/01/31(土) 22:37:59 ID:9d5EHsE6
>>914
> 明示的なって意味じゃねぇの?
> だいたいそんな十把一絡な引数あってもしょうがねぇし

templateは実体化して使うだから
compile-timeには型が確定するし十分明示的じゃん。

templateが「十把一絡な引数」だと思うなら、お前はstd名前空間使用禁止な!

> グローバルにしてテキトーに渡したほうが速いじゃん

グローバル変数なんか使わないっちゅーの。
本当、ID:rIovvj90は、タスクシステム以前にプログラミング自体、ド素人なんだな。

917 :名前は開発中のものです。:2009/01/31(土) 22:41:36 ID:rIovvj90
そもそもまずいのはグローバル変数・関数じゃなくて
グローバル・スタティックの変数・関数、別クラスのインスタンスのポインタの保持、
シングルトン、アドレスジャンプ等を使用することによって
明示的な関連が全く見えなくなることだけどね

別にそこにこだわってないならいいんじゃないの?
どう組んでもw

918 :名前は開発中のものです。:2009/01/31(土) 22:44:58 ID:8N26Dxd2
>>915

> EnemyTask* enemyTask1 = TashHandleToPtr<EnemyTask>(enemy1);
これが実質グローバル変数。
これがダメ。
これをやめるべき。
これがグローバル変数とほぼ等価だと認識できないの?

俺の「ゲームオブジェクト」は
「自機と敵機の座標が重なっていたら自機にダメージ与える」という処理において言えば
「自機」と「敵機」がそれぞれゲームオブジェクト。

俺の「タスク」は
class Task {
public:
 virtual void update(void)=0;
}
的なやつを実装したもの。update(Context?)=0;でもいいけど。

919 :名前は開発中のものです。:2009/01/31(土) 23:31:26 ID:9d5EHsE6
>>918
>> EnemyTask* enemyTask1 = TaskHandleToPtr<EnemyTask>(enemy1);
> これが実質グローバル変数。
> これがグローバル変数とほぼ等価だと認識できないの?

出来ないね。
それがグローバル変数に見えるならあんたの目が腐ってるとしか言いようがない。

ID:rIovvj90 と ID:8N26Dxd2 はいつも時間的に連続して出てきて、
二人とも極端にレベルの低いド素人プログラマなんだが、これは
同一人物なのか?

それとも、こんなド素人が二人も都合良くこのスレに出没してるのか?

920 :名前は開発中のものです。:2009/01/31(土) 23:37:25 ID:9d5EHsE6
>>918
>「自機と敵機の座標が重なっていたら自機にダメージ与える」という処理に
> おいて言えば「自機」と「敵機」がそれぞれゲームオブジェクト。

タスクとの違いがわからない。

> 俺の「タスク」は
> class Task {
> public:
> virtual void update(void)=0;
> }
> 的なやつを実装したもの。update(Context?)=0;でもいいけど。

「ゲームオブジェクト」とやらも、そのTask派生クラスでいいじゃん。
何がまずいの?

921 :名前は開発中のものです。:2009/01/31(土) 23:55:45 ID:rIovvj90
>>919
違うっつの
しかも、グローバル変数が問題じゃなくて
明示的な関連(アクセスかな?)が見えないのがまずいって言ってるだろ
関数の実行に必要なもんをソースみてわかるようにしろ
簡単だろ?
何もむずかしいこといってやしねぇだろ?

922 :名前は開発中のものです。:2009/01/31(土) 23:59:28 ID:9d5EHsE6
>>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) のポインタを渡す。

だから「実質グローバル変数」ではない。

923 :名前は開発中のものです。:2009/02/01(日) 00:02:59 ID:YQa72ap1
>>921
> 関数の実行に必要なもんをソースみてわかるようにしろ

についてだが、

> EnemyTask* enemyTask1 = TaskHandleToPtr<EnemyTask>(enemy1);

の「関数の実行(コンパイル?)に必要なもん」は、EnemyTask*で、
これはEnemyTaskクラスの定義してあるheaderが必要だ。

これは「みてわかる」と思うんだが、何をそんなに問題にしているのか
それがわからない。

924 :名前は開発中のものです。:2009/02/01(日) 00:13:31 ID:YQa72ap1
いま気になったので、ID:rIovvj90 と ID:8N26Dxd2 の書き込みを
全部読み返したのだが、この二人(一人?)は極端に日本語が不自由だな。

この二人は専門用語の使い方もかなり間違いだらけで、
何が言いたいのか理解に苦しむ。

本当にこれで社会人なのか…。

というのはさておき、わかってないのはこの二人(一人?)だけみたいなので
IDも変わったことだし、俺はもう寝る。

925 :名前は開発中のものです。:2009/02/01(日) 00:23:24 ID:rVEgp4cM
>>924
文体が全然違うのに病気だろそれはw
ちなみに俺はID:rIovvj90ね

926 :名前は開発中のものです。:2009/02/01(日) 01:03:01 ID:DFOa0Cn0
君たち、タスクシステムの話をしなさい。
素人だとかプロだとか、技術と関係ない感想は取り除いて話しなさい。

927 :名前は開発中のものです。:2009/02/01(日) 01:07:33 ID:wxGi2uAC
ID:8N26Dxd2 です

>>919
グローバル変数の嫌なとこは
プログラムのどこかで変数の内容が変更される可能性があるのにそれが把握できないことでしょ

「ポインタを全タスクにばらまいてどこからでも全データ参照できる機構」の嫌なとこは
プログラムのどこかで変数の内容が変更される可能性があるのにそれが把握できないことでしょ

俺には両者はほぼ等価でどちらも忌むべきものにしか思えないが
もし「グローバル変数」と呼称するのが受け付けられないだけなら呼び方はどうでもいいけど
技術者として設計に不吉なにおいを感じないか?

>同一人物なのか?
違うっつの

>>920
>タスクとの違いがわからない。
object: 物体, もの, 実物; 対象
task: コンピュータが処理する仕事の最小単位
*goo辞書より

>何がまずいの?
タスク間の通信は実質グローバル変数渡しでしかできないのにゲームオブジェクト間は通信たくさん必要でミスマッチなとこがまずい

#話全く関係ないけどgoogleびびったw

928 :名前は開発中のものです。:2009/02/01(日) 01:42:31 ID:ZI4Z1t2K
>>919
> 同一人物なのか?
人を陥れるために真似る奴もいるぜ
あまり単純に考えない方がいい

つか>826にあるコードの断片だけを見て
どっちがいいか判断できるなんてエスパーとしか思えん。

929 :名前は開発中のものです。:2009/02/01(日) 01:52:34 ID:7YDjPQ+X
>>826
引数でどうしても縛りたいならupdate()のなかでupdate(jiki,teki,tama,unko)呼べば解決じゃねーのか。
何が問題になるんだ。

930 :名前は開発中のものです。:2009/02/01(日) 01:59:33 ID:v/nkqtd/
>>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)を例に出すのは間違ってる。

931 :名前は開発中のものです。:2009/02/01(日) 02:01:26 ID:YQa72ap1
>>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);

933 :名前は開発中のものです。:2009/02/01(日) 02:09:16 ID:wxGi2uAC
>>922
俺が実質グローバル変数と言う判断基準は

「グローバル変数そのものではなくとも、
 グローバル変数のように動き、グローバル変数のように扱えるのならそれはグローバル変数だ」

これ。
だから実装方法はとくに想定していないし、する必要も無い。

まぁグローバル変数という呼び方がだめならその呼び方はやめるよ。
問題点は
>初期化のときに、HashTable (>>869) のポインタを渡す。
こんな感じでポインタをプログラム中にばらまくと
プログラムのどこかで変数の内容が変更される可能性があるのにそれが把握できなくなること。
「メモリ上のオブジェクト寿命の保証」は対策できてるから問題ないとして、
「データ確定性の保証」の観点から見た場合はどうなの?ってこと。

もしかしたら
>>886

> Jiki jiki;
> Teki teki;
> Tama tama;
> Unko unko;
を扱う記述例はどんな感じになる? と聞いた方が手っ取り早いのかもしれないが


>>924
>極端に日本語が不自由だな。
うん

ねもいにょ。俺ももう寝るにょ

934 :名前は開発中のものです。:2009/02/01(日) 02:13:36 ID:YQa72ap1
>>932
俺、ID:9d5EHsE6で、その>>826 に反論してた側の立場なんだけど、
その>>932に対する返答らしきものが、>>907-908 にあるのだが、
これの意味が俺にはさっぱりわからない。

935 :名前は開発中のものです。:2009/02/01(日) 02:20:15 ID:7YDjPQ+X
>>934
俺にもさっぱりです。

936 :名前は開発中のものです。:2009/02/01(日) 02:21:59 ID:YQa72ap1
>>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();
};

何かこれで不満でも?

937 :名前は開発中のものです。:2009/02/01(日) 02:28:22 ID:YQa72ap1
>>933
936の補足。

Jiki,Teki,Tama,UnkoがTask派生クラスとは限らないなら、そのへんはケースバイケース。

場合によっては>>886 のように書いたりもする。

Jiki,Teki,Tama,UnkoがTask派生クラスであるなら、
boost::weak_ptrを用いるか、TaskHandle(>>869) を用いるか、>>886 のようにContextに持たせるか。

方法はいろいろある。

938 :名前は開発中のものです。:2009/02/01(日) 02:36:57 ID:wxGi2uAC
>>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());
>      }
>    }
>    ...

みたいに変化すべきと思うけども

939 :名前は開発中のものです。:2009/02/01(日) 02:42:44 ID:U7FhX9ul
意味というか、論点がわかんねぇ……

>>938
その引用部分は、何のつもりだかはある程度は想像はつくが、
update(jiki, teki, tama, unko)
はどこでも呼んでいない
「update(jiki, teki, tama, unko)が欲しい」という主張じゃなかったの?
その引用部分のコードを、(引数のない)「update()」の中に
記述できない理由は何?

940 :名前は開発中のものです。:2009/02/01(日) 02:44:19 ID:YQa72ap1
>>938
> ゲームオブジェクトはタスクにすべきではない

俺には、この根拠がいまだにわからない。

V-SYNCに応じてupdateを呼び出されたり、描画のために呼び出されたりするのだから、
少なくともTask派生クラスであるべきだと思うのだが。

それとも、その自機、弾、敵は描画には関係ないのか?

それとも、描画に関係あって、Task派生クラスではあるが、foreachでぶん回したいから
std::list<敵*> のようなものがいると言っているのか?

941 :名前は開発中のものです。:2009/02/01(日) 02:50:32 ID:wxGi2uAC
>>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());
    }
  }
  ...
}
こう進化させていけるから。
ド素人くさいとか泥臭い書き方が嫌という場合は劣化と受け取るかもですが。

942 :名前は開発中のものです。:2009/02/01(日) 02:51:44 ID:U7FhX9ul
あーそうか

ゲームオブジェクトのステートは
相互に依存していることが往々にしてあって、独立しているとは限らないから
おのおのについて「自分のステートを更新しろ」という号令を発する
モデルが常に適切とはいえない、という主張か

もう少しランクが上のクラスで(相互に関連した)ゲームオブジェクトのの
ステート更新をまとめて行う設計であれば、その配下のオブジェクトが
号令(VSYNC通知)を受け取る必要は無いし、むしろそれは無駄だと

そういう意味だと俺は解釈した

943 :名前は開発中のものです。:2009/02/01(日) 02:55:14 ID:YQa72ap1
>>941
Task派生クラスではないならタスクではないのだから、好きなように書けばいいじゃないか。

それらは、いま議論しているタスクシステム(タスクフレームワーク?)とは何ら関係ないのだから、
タスクシステムの書き方に準拠する必要はないだろう。

しかし、どう見ても自機、敵、弾は描画の必要がありそうなのにTask派生クラスじゃないが
わけわかんないし、俺のタスクの書き方をどうして、タスクと関係のないプログラムの書き方を
持って否定されなきゃならんのか、まったくわけがわかんない。

944 :名前は開発中のものです。:2009/02/01(日) 02:58:30 ID:wxGi2uAC
>>940
>それとも、その自機、弾、敵は描画には関係ないのか?
関係ないっすね
Task派生クラスでも無いです
foreachでぶん回したいのはあります。
std::list<敵*> のようなものは要ります。


945 :名前は開発中のものです。:2009/02/01(日) 02:59:14 ID:YQa72ap1
>>942
それは、俺も理解しているし、たぶんみんな理解している。

本人はそれをうまく説明する言葉を持ち合わせていなかったようではあるが…。

しかも、もしその理解が正しければ、ID:wxGi2uACの反論は誰に対する反論にもなっていない。

946 :名前は開発中のものです。:2009/02/01(日) 03:02:00 ID:YQa72ap1
>>944
>> それとも、その自機、弾、敵は描画には関係ないのか?
> 関係ないっすね

なにー!それなら、いかにもシューティングみたいで、いかにも、描画します、みたいなものを例に
持ってくるのがわけわかんない。しかも接触判定とか、もろに描画考慮しているように見えるじゃん。

それなら最初から、
 「主人公の体力」「主人公の生命力」「主人公の知力」(それぞれ描画は不要)
とか、そのくらいの説明は欲しいよ。

長々とつきあって損した。

947 :名前は開発中のものです。:2009/02/01(日) 03:16:59 ID:wxGi2uAC
>>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派生クラスとするのは問題ないと思います。

夜遅くなっちゃいました。そろそろほんとに寝ます。

948 :名前は開発中のものです。:2009/02/01(日) 03:22:54 ID:wxGi2uAC
>>945
>たぶんみんな理解している。
それは・・・
そういうスレになったらうれしいですね


949 :名前は開発中のものです。:2009/02/01(日) 03:24:59 ID:YQa72ap1
>>947
話はわかった…。お疲れさま&おやすみ。

950 :名前は開発中のものです。:2009/02/01(日) 04:01:32 ID:rVEgp4cM
話がさっぱりわからないけど
ゲームオブジェクトまたはその他もろもろのごった煮リストとは
違うタスクの話を始めたの?

951 :名前は開発中のものです。:2009/02/01(日) 04:03:36 ID:7YDjPQ+X
眠れねー。
どうでもいいけどforeachでヒットチェックしてるとこ、べた書きはないだろ。
判定対象は同士は同じメソッド持ってんだし。

952 :名前は開発中のものです。:2009/02/01(日) 04:04:49 ID:7YDjPQ+X
×判定対象は同士
○判定対象同士

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

954 :名前は開発中のものです。:2009/02/01(日) 04:20:37 ID:3I9VPm/8
ID:rIovvj90=ID:rVEgp4cMって本当にプログラム書いてんのか?
どう見ても役に立ちそうにないんだけど。

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

955 :名前は開発中のものです。:2009/02/01(日) 05:38:23 ID:1JPWlzeO
シーンなんて最も抽象化しやすいものの1つだと思うんだが……。

956 :名前は開発中のものです。:2009/02/01(日) 11:56:06 ID:wxGi2uAC
>>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初心者でも書ける位に簡単化されることです。
(私はゲームオブジェクトにタスク導入反対派なので、こう記述すればタスク使うより楽にプログラミングできますよねという意図で書いてます)

957 :名前は開発中のものです。:2009/02/01(日) 12:07:10 ID:wxGi2uAC
そういえば
> ・InputDevice・jiki間はswitch (InputDevice->popKey()) 〜
> ・jiki・OutputDevice間はcontext.dev3dg->draw_model(jiki_gazou, jiki.x, jiki.y);
これらをそれぞれタスク化するのはありかも。
処理だし

958 :名前は開発中のものです。:2009/02/01(日) 12:39:31 ID:rVEgp4cM
タスクシステム総合スレ part4
http://pc11.2ch.net/test/read.cgi/gamedev/1233459490/

959 :名前は開発中のものです。:2009/02/01(日) 13:07:49 ID:1YAKubd4
なんだこの損した感は

960 :名前は開発中のものです。:2009/02/01(日) 20:36:02 ID:3I9VPm/8
ID:rVEgp4cMには>>954の返答がもらえないみたいなんだが
無視して>>958みたいに次スレ立ててるところを見ると本当にニートなのか

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

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

961 :名前は開発中のものです。:2009/02/01(日) 21:15:33 ID:rVEgp4cM
>>960
一応、本職のPGですわ
ってなんでお前にそんなこと言わなきゃいけないのか?
内容でレス返せなくなったから人格攻撃に移ろうと思ったの?
育ちが悪いなぁ

962 :名前は開発中のものです。:2009/02/01(日) 21:29:27 ID:3I9VPm/8
>>961
あんたの書いた>>831とか

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

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

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

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

963 :名前は開発中のものです。:2009/02/01(日) 21:36:14 ID:DFOa0Cn0
自分が三下ではないと思うのならぜひ >>497 の問いかけに答えてみて欲しい。

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

964 :名前は開発中のものです。:2009/02/01(日) 21:46:58 ID:rVEgp4cM
>>962
全然主旨と違うところに噛み付いてるけど
ソースに明示的に引数を書いて関数に必要なインスタンスをわかるようにしろ
ってのがメインなんだけどね
ここをあんまりずらしてほしくないな

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

965 :名前は開発中のものです。:2009/02/01(日) 22:02:08 ID:wxGi2uAC
>>953
> jiki,teki,tama,unkoと同じ問題が今度はシーンにうつるだけだ
まあね。

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

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

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

966 :名前は開発中のものです。:2009/02/01(日) 23:42:46 ID:YQa72ap1
>>953
> 俺的には>>936もいいとは言えないね
(snip)
> まったく汎用性のない糞クラスだ

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

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

967 :名前は開発中のものです。:2009/02/01(日) 23:52:08 ID:rVEgp4cM
>>966
だったらなぜにTask?w

968 :名前は開発中のものです。:2009/02/02(月) 00:23:38 ID:+kwO8CZh
何故理解していないものを批判できると思うのか。
Taskはより抽象的なクラス。こちらは汎用的である必要がある。
SceneTaskはより具象的なクラス。こちらは汎用的である必要はない。

969 :名前は開発中のものです。:2009/02/02(月) 00:25:53 ID:cShVBku0
>>968
したらどうして継承して〜Taskクラスである必要があるのん?w(俺はないと思うんだけどw)
ばっかじゃねぇんw

970 :名前は開発中のものです。:2009/02/02(月) 00:30:10 ID:SpnGISw5
まさかの第2ラウンドwww
遅刻の予感www


971 :名前は開発中のものです。:2009/02/02(月) 00:31:50 ID:+kwO8CZh
名前の話か? それは単にサンプルだからだろ。
実際にはSceneTaskなんて何も表してない名前は使わないだろう。
Scene全体のスーパークラスとしてはあり得るかもしれんが。

972 :名前は開発中のものです。:2009/02/02(月) 01:19:55 ID:ZmvZOOAJ
俺はID:rVEgp4cM(スレ主)と議論するのは時間の無駄だと思うので
よそのスレでやりたいわ。

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

973 :名前は開発中のものです。:2009/02/02(月) 01:38:35 ID:lhNqT94l
いいスレなのに、スレ主がいるだけ邪魔というのが惜しいな

974 :名前は開発中のものです。:2009/02/02(月) 06:25:56 ID:cShVBku0
>>972
アレアレ?
敗北宣言?w

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

975 :名前は開発中のものです。:2009/02/02(月) 06:49:09 ID:lhNqT94l
>>974
お前が一人でスレのレベルを下げてるのな
せっかく、いいスレなのにな・・

976 :名前は開発中のものです。:2009/02/02(月) 07:40:15 ID:P5kryGXr
タスク信者、反論できなくなっちゃったかw
ていうか、タスク信者っていたんだ?

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

978 :名前は開発中のものです。:2009/02/02(月) 11:18:38 ID:LfmM5Xp6
タスクシステムではタスクがどうのこうのという割に、
実際にはタスク=オブジェクト みたいな図式ができあがってて、
それ、劣化オブジェクト指向だよねって突っ込まれる事例が増えていると。

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

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

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

とか言ってみるテスト。

979 :名前は開発中のものです。:2009/02/02(月) 12:05:21 ID:ZmvZOOAJ
こんな基地外(>>976)、死ねばいいのに…

980 :名前は開発中のものです。:2009/02/02(月) 21:18:42 ID:SpnGISw5
>>978
なるほどなー
なんか自分がすごいことを考えてるような気がしてきた

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

981 :名前は開発中のものです。:2009/02/02(月) 21:36:01 ID:SpnGISw5
タスクだけで組もうとしてタスクシステムに行き着き、
結果、タスク間にまたがるデータのやりとりがおろそかになった。

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

こんな感じかな?

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

982 :名前は開発中のものです。:2009/02/03(火) 03:34:35 ID:dxGO6tf5
初心者向けを適当にピックアップ。
というよりぱっと見て自分が理解できる情報。用語力のなさと前提条件がわからないのが致命的。

>>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の初心者ですわ。
(当時タスクシステムが何いいたいかよく分からんかった。ので、自機、敵機のリストで多態性して組んだ。
ってかこの本のやつは別にごった煮リストじゃナカタヨ。普通に自機系、敵機系と分けてるよ。)



983 :名前は開発中のものです。:2009/02/03(火) 04:10:21 ID:dxGO6tf5
>>684-686,>>762,803,762,>>805,807-811
>>816-819,>>823

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

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

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



984 :名前は開発中のものです。:2009/02/03(火) 04:53:00 ID:dxGO6tf5
>>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

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






985 :名前は開発中のものです。:2009/02/03(火) 05:01:55 ID:dxGO6tf5
>>983になぜか>>762が2つあるね。明らかなミスです。

986 :名前は開発中のものです。:2009/02/03(火) 05:38:27 ID:SI2YL2Kh
>>978
>タスクシステムではタスクがどうのこうのという割に、
>実際にはタスク=オブジェクト みたいな図式ができあがってて、
>それ、劣化オブジェクト指向だよねって突っ込まれる事例が増えていると。

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

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

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

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

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

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


988 :名前は開発中のものです。:2009/02/03(火) 05:51:19 ID:SI2YL2Kh
このスレには様々なセカイの人々が入り乱れてる

 @-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
  だったのだ(←な、なんだってー!?)といったかなり無理矢理な話をはじめたりする。狂気に見えるが
  どうも本気らしい

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

990 :名前は開発中のものです。:2009/02/03(火) 06:51:54 ID:SI2YL2Kh
 【アンチ】

 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 アンチ[タスク厨]
  アンチタスクではない。タスク厨がお嫌いな人

991 :名前は開発中のものです。:2009/02/03(火) 08:29:51 ID:SI2YL2Kh
>>986

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

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

992 :電車から訂正:2009/02/03(火) 09:04:55 ID:Xqi0Cwaa
>>990
朝一番は寒くて知能が一層働かない
罵詈雑言、ばりぞうごん、だよ
馬耳東風とこんがらがっちったよ

993 :名前は開発中のものです。:2009/02/03(火) 11:02:13 ID:m6a2F9Ll
>>986-992
正直言ってキモイ
次スレにこれを持ち込むなよ

994 :名前は開発中のものです。:2009/02/03(火) 20:17:20 ID:WfRBR2t7
アンチ完全勝利か
もうタスク信者も終わりだな
ひらしょの一撃で弱り切ってたところでこの大敗退
決定的だな

995 :名前は開発中のものです。:2009/02/03(火) 20:25:58 ID:B9Lc/65b
>>994
最近の流れはまともにプログラムを書けない基地外アンチが馬鹿にされてるだけじゃんw

996 :名前は開発中のものです。:2009/02/03(火) 20:36:47 ID:WfRBR2t7
ひらしょーの奇襲攻撃が強すぎだろ
セガの技術者に知らないなんていわれたら
求心力なんてなくなっちゃうだろ

997 :名前は開発中のものです。:2009/02/03(火) 21:04:43 ID:SXSAJl/c
最近、タスクシステムを過小評価している、と噂される某企業の経験者の名が散見されるが、



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





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

998 :名前は開発中のものです。:2009/02/03(火) 21:36:16 ID:8pOsGvCV
ちんこ

999 :名前は開発中のものです。:2009/02/03(火) 21:56:12 ID:j8kWE6ld
999!


1000 :名前は開発中のものです。:2009/02/03(火) 21:57:22 ID:az8GBqBA
1000なら>>1が死亡

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

458 KB
★スマホ版★ 掲示板に戻る 全部 前100 次100 最新50

read.cgi ver 05.04.00 2017/10/04 Walang Kapalit ★
FOX ★ DSO(Dynamic Shared Object)