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

**名前は開発中のものです。** · 2008/11/09(日) 11:51:40

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

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

**名前は開発中のものです。** · 2009/01/01(木) 15:12:29

編隊飛行が表現できるなら木構造になるし
ロックオンした目標が複数あればグラフ構造にもなるな

**名前は開発中のものです。** · 2009/01/01(木) 15:18:57

>>403
わかってないのお前ひとりだけじゃん。
お前が底抜けの馬鹿だからわからないだけで・・・

**名前は開発中のものです。** · 2009/01/01(木) 16:17:14

板違いスレ違いを続けるのはそろそろどうかと思うんだな。

**名前は開発中のものです。** · 2009/01/01(木) 16:53:23

全然関係無いよね
なんか
わからないんだ？ﾌﾟｷﾞｬｰ(笑)
的な流れにして説明責任果たそうとしない流れにしがちだけど
現実、仕事となったらここが一番大事だしその後の理論がどんなに立派でも糞とカワンネ
仮に関連してたとしてもこれ関連性を説明するの滅茶苦茶大変だぜ

**名前は開発中のものです。** · 2009/01/01(木) 16:58:11

訂正。わかってないの、>>406,407のお前ら二人だけだよ。

大馬鹿はお前ら二人。

**名前は開発中のものです。** · 2009/01/01(木) 17:27:22

触んないほうがいいんじゃない？

**名前は開発中のものです。** · 2009/01/01(木) 18:05:53

>>404
こういうのってHFSMみたいな記述になるのかしら

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

**名前は開発中のものです。** · 2009/01/01(木) 18:30:10

HFSMは状態の木構造、状態の中にさらに状態がある
みたいなものじゃなかったっけ（ちがったかな）
編隊のリーダーと部下みたいなFSM同士の主従関係とか
組織のヒエラルキーをあらわす木構造の場合は
単に木構造のコンテナにFSMが入ってればいいだけなので
HFSMとは違うかもだ

**名前は開発中のものです。** · 2009/01/01(木) 19:05:56

>>408
そんなこと言って難しい部分は説明できないから逃げる気でしょ？
職場でもこんなわけのわからないもの採用させるなんていったら大変なのはそこだよ
逆に批判をかわすのもわけわかんないこと叫んでかわせばいいけど
そうゆうこと馴れると技術者として死ぬよ
批判する側に説明責任の押し付けゴッコ始めていつもかわすけど
そもそもなんの関連もないの明らかじゃん

**名前は開発中のものです。** · 2009/01/01(木) 19:19:14

>>412
何度でも言うがわかってないのお前ら馬鹿二人だけなんだよ。

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

**名前は開発中のものです。** · 2009/01/01(木) 19:29:46

説明責任放棄する奴は二言目には必ずそういう
関係無いから関連を説明しろっていってるだけじゃん

**名前は開発中のものです。** · 2009/01/01(木) 19:44:34

>>414
馬鹿すぎて周りに友達いねーのか。それは可哀想に。

**名前は開発中のものです。** · 2009/01/02(金) 07:00:34

>>386-387
すげぇな
飛行機や対空ミッソー飛ばしてもデッドライン（敵が目標上空に着く時間）までに
敵とご対面させてやらなきゃ全部パーだよな？

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

**名前は開発中のものです。** · 2009/01/02(金) 16:48:56

匿名でも記名でもi君の人を見下した態度は相変わらずだな

**名前は開発中のものです。** · 2009/01/02(金) 20:57:49

>>411
㌧ｸｽ。なるほど。状態に子あ孫があるのか

**名前は開発中のものです。** · 2009/01/03(土) 19:21:39

で、代替案はまだ出ないの？

**名前は開発中のものです。** · 2009/01/03(土) 23:49:19

代替案？
なんの？
こんなもん使わなきゃいいだろ
普通に必要なだけ処理書いて引数で必要なもんだけ渡せよ

**名前は開発中のものです。** · 2009/01/04(日) 09:29:42

つまり420は配列派というわけですね？

**名前は開発中のものです。** · 2009/01/04(日) 09:42:16

アホか

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

**名前は開発中のものです。** · 2009/01/04(日) 10:01:35

配列はインスタンスの話だろ
多分

**名前は開発中のものです。** · 2009/01/04(日) 11:18:31

Taskをモナドにしよう

**名前は開発中のものです。** · 2009/01/04(日) 15:08:16

オブジェクト指向で普通に書いたらタスクシステムだけど？

**名前は開発中のものです。** · 2009/01/04(日) 16:24:39

オブジェクト指向プログラミングでは双方向リストをガチガチに手書きするのが
普通なんですかそうですか。

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

**名前は開発中のものです。** · 2009/01/04(日) 16:48:53

リストかどうかって別に本質じゃないような。

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

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

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

**名前は開発中のものです。** · 2009/01/04(日) 19:15:52

そういう、Cでオブジェクト指向を実現するためのテクニック
（有名どころではXtとかが使ってた）の真似事みたいなことは
してるけど、オブジェクト指向とはどうにも認めがたい。

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

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

**名前は開発中のものです。** · 2009/01/04(日) 22:14:00

C++で普通に作ったらタスクシステムというものをわざわざ用意しなくてもいいのは事実。
単一のインスタンス構造に多数の関数ぶらさげてただけだし。

**名前は開発中のものです。** · 2009/01/04(日) 23:50:15

とんでもない神レベルの人ととんでもない馬鹿とが混在するのがこのスレの面白いところだな

**名前は開発中のものです。** · 2009/01/05(月) 01:24:39

>>429
あんまりその辺こだわってる奴ってもういないと思うぜ
オブジェクト指向云々とかあまり問題じゃない
たまに急に振る奴がいるけど別にクラスなんかあってもなくても同じ問題に直面する

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

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

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

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

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

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

**名前は開発中のものです。** · 2009/01/05(月) 02:50:49

一括して扱える、同じコードで扱えるというのはCPUにとっては全くうれしくない

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

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

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

**名前は開発中のものです。** · 2009/01/05(月) 03:19:03

あ、クズの所業ってのは>>2の各URLの中の人のことじゃないからな
そこで解説されてる手法（？）を祀り上げてるカルト信者のことな

**名前は開発中のものです。** · 2009/01/05(月) 07:07:50

×HSYNC毎に
○ライン毎に

**名前は開発中のものです。** · 2009/01/05(月) 08:26:50

>>432
>大昔に興味本位で測定した。AMDのAthlonXP（Bartonコア）で>>2を使うと速度は半分になった
面白いですね。比較対象ってどんな組み方のものですか？

**名前は開発中のものです。** · 2009/01/05(月) 09:23:56

いまどきのオブジェクト指向のメッセージ処理で多用される間接ジャンプを、
現代のプロセッサでは性能が出ないとか扱き下ろしている人がいるのは
このスレですか？

**名前は開発中のものです。** · 2009/01/05(月) 10:41:47

制御対象の計算粒度と数の特性ゆえに>>2は不利となる
パフォーマンスアナライザやプロファイラを使わず現実を見ずに先入観のみで
>>2はきっと良いに違いないと盲信するならエンジニアではない
エセ科学信仰とかカルト信仰に溺れる知的弱者だ

**名前は開発中のものです。** · 2009/01/05(月) 10:51:52

>>431
①か②を採用するかは
ゲームによって臨機応変に対処すればいいんじゃないかな
どちらか絶対という事はないと思う
弾幕シューティングなどは明らかに後者が適していると思う
自分が最近作ったゲームはシーン（メニュー、コンフィグ、ゲームプレイなど）すら
オブジェクト化した①を採用してみた

**名前は開発中のものです。** · 2009/01/05(月) 13:00:39

>>437
> パフォーマンスアナライザやプロファイラを使わず現実を見ずに先入観のみで
> >>2はきっと良いに違いないと盲信するならエンジニアではない
> エセ科学信仰とかカルト信仰に溺れる知的弱者だ

あっそう。

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

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

**名前は開発中のものです。** · 2009/01/05(月) 13:07:36

性能「だけ」で何かを論じるのはおかしくね？
性能だけで論じるなら早い話がC++とか消えろって話だよね

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

**名前は開発中のものです。** · 2009/01/05(月) 13:24:38

タスク同士で関連づけってどうやってる？

**名前は開発中のものです。** · 2009/01/05(月) 19:58:30

タスクシステムって１つのリスト限定なの？
じゃあ俺のタスクシステムじゃなかったんだｗ

**名前は開発中のものです。** · 2009/01/05(月) 20:04:55

>>438
そのごった煮状態ってなんかいいの？
ソース見る側としちゃ勘弁してほしい感じだけど

**名前は開発中のものです。** · 2009/01/05(月) 23:51:57

あけましておめでとうなのねー

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

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

**名前は開発中のものです。** · 2009/01/06(火) 00:05:24

>>432
半分はないと思うよJK

**名前は開発中のものです。** · 2009/01/06(火) 00:16:06

>>441
めっちゃくちゃ複雑じゃね？
そこまでなったらもうバグのオンパレード状態で収集つかない希ガス

**名前は開発中のものです。** · 2009/01/06(火) 12:42:23

>>438
マルチコアなら②の方がいいと思う。
カプコンのMTフレームワークもそんな感じだったような。

**名前は開発中のものです。** · 2009/01/06(火) 14:37:10

>>443
ごった煮かもしれんが、並列処理ができるのがいいのよ
例えばタイトル画面表示中に、雪を降らせるなんてことも容易に実現できる
シーン式のゲームでもやろうと思えばできないことはないが面倒だろ
流石に全てのゲームジャンルでこの方法が適しているとは思わない

**名前は開発中のものです。** · 2009/01/06(火) 15:13:06

よくわからんが
より抽象度の高い話をすれば
「全てのゲームオブジェクトについて、1フレーム内でiterativeに処理を行いたい」
あるいは
「全てのゲームオブジェクトに、同じメッセージをブロードキャストしたい」
ことがあるかどうか、という話じゃなかろーか
あるのなら、それをリストに持っておくという実装もあるだろう

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

**名前は開発中のものです。** · 2009/01/06(火) 17:34:45

>>448
ジョブエントリのリストをなめて順次処理（バッチ処理）するだけの
コードをもって、これは並列処理できるのだと豪語するか。これいかに

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

**名前は開発中のものです。** · 2009/01/06(火) 20:14:08

>>448
何を言ってるのか本気でわからない
②で組んだことない？
仮にごった煮にしないでシーン？とゲームオブジェクトを別に管理したら
そっちのが扱いやすいだろ？
まとめるってことはアクセスするたびにそいつを判別するなんらかの仕組みが必要になるってことだし基本的には面倒が増えるよ
よほど一括で処理したいなにかがないとメリットはないと思うんだけど？

**名前は開発中のものです。** · 2009/01/06(火) 20:27:19

結論：

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

**名前は開発中のものです。** · 2009/01/06(火) 20:36:30

うおおおおお！

**名前は開発中のものです。** · 2009/01/06(火) 21:25:55

アクセスするたびに判別が必要ならそれはタスクシステムじゃないじゃん？C++あたりで組むなんちゃってタスクシステムだよ

**名前は開発中のものです。** · 2009/01/06(火) 22:20:13

タスクシステムが賛否両論なのはきっと分割の粒度・観点とかの違いですよ。ええ。
と思いついたので分類してみた。C++なんちゃってタスクシステムの話

　1. マルチプロセス級：ゲームタスク、バッテリ残量監視タスク、...
　2. マルチスレッド級：入力監視タスク、ゲーム処理タスク、描画処理タスク、鳴音タスク、...
　3. 仮想関数インタフェース級：仮想update関数タスク、仮想move関数タスク、仮想draw関数タスク、仮想onkey関数タスク、...

・マルチプロセス級はほぼ関係無い処理だけど1台のPCにはともに入ってて欲しい位のとこで分割。.exe相当。
・マルチスレッド級は決まりきったデータ通信が発生する程度に関係のある処理で分割。
　通信を標準化するのもそう悪くないってとこで分けるのがミソかも（使ったこと無い俺）。
・仮想関数インタフェース級は関係性とか概念の違いとか無視してたまたま関数インタフェースが似た感じっぽいところを探して
　縦横無尽に共通化（抽象化）したもの。イベントハンドラの延長？
　仮想関数インタフェース自体の仕様変更耐性とか再利用性が最悪。最悪。最悪。
　それでいて性能も悪いかも。仮想関数ゆえにメモリキャッシュまわりとか？
　でも１画面ミニゲーム、画面エフェクト無し、凝ったギミック無しとかなら使い勝手良かったりする。
　グローバル変数が通常サイズのクラス１個分に収まる程度までが利点を享受できる適正規模？

2と3の間にゲームオブジェクトとかシーンオブジェクトとかで分けた「クラス分け級」を入れようとしたけどなんか無理だった。
3番と同じ気がしてしっくりこなかった。

**名前は開発中のものです。** · 2009/01/06(火) 23:16:50

実際のゲームってどういう設計が使われてるんだ？

**名前は開発中のものです。** · 2009/01/06(火) 23:22:37

そもそも実際のゲームには何か共通した設計というものがあるのか？

**名前は開発中のものです。** · 2009/01/07(水) 00:21:50

その共通部分を抽出したものがタスクシステムだと思っていたんだが・・・

**名前は開発中のものです。** · 2009/01/07(水) 02:21:29

>>458
残念だがそのシナリオを選択する（orデカイ声で叫ぶ）のは遅すぎだな。というか無理がありすぎるな

>>2（特にLogicianLord。拡散の元凶）と>>2を誤読したゲッベルス（松浦大先生。拡散させた偉大な男）
およびその忠実な部下（熱烈な読者）は、パンピー(neutralな人)たちに対して、奇妙なまでに一致した
偏った「とあるヘンテコリン実装」でもってタスクシステム（？）なるものを解説しネット・雑誌・書籍で
流布した。流布し尽くした。2009年現在、ネット上で>>458説を提唱するのは完全に手遅れといえる

タスクシステムという言葉は>>2に代表される、極めて特徴的な、奇異なまでに一致したヘンテコリン実装

　　　　　　　「TCBがプライオリティをサブルーチンアドレスでディスパッチなのです＞＜」

と完全に癒着している。もう引き剥がせない。OoOやマルチコアプロセッサの普及により>>2の実装が
obsoleteといえるならば、タスクシステムという呼称もまたこの味噌が付いた実装と共に成仏することになる

**名前は開発中のものです。** · 2009/01/07(水) 08:38:38

ところで次スレからは書籍もテンプレに入れようぜ、戦犯としてw
Cマガ2004/12「ゲームのためのタスクシステム」松浦
単行本「シューティングゲームプログラミング」松浦
「Windowsプロフェッショナルゲームプログラミング2」やね

これだけ？

**名前は開発中のものです。** · 2009/01/07(水) 20:53:38

>>459
じゃあ実際はどんなのが使われてるのか教えてください。
まったく違うものなんですか？
オブジェクトの種類ごとに持つデータが違うとか、
オブジェクトのデータのメモリ管理方法が違うとか、単一のリストじゃないとか、
そんなのは違いのうちに入らないと思うよ。

**名前は開発中のものです。** · 2009/01/07(水) 21:57:34

>>459
オイ、コラァ！
「ヘンテコリン」はお前とお前のキチガイじみた駄文だろーが
やたら人を見下した態度をとっているが、具体的論理展開は全く無し。
典型的なチキンだな。

**名前は開発中のものです。** · 2009/01/07(水) 22:12:07

>>457
シーン遷移とシーン管理。
あれはひとつクラス作って使い方を決めときゃどんなゲームでも鉄板では？

**名前は開発中のものです。** · 2009/01/08(木) 00:12:58

>>461
> じゃあ実際はどんなのが使われてるのか教えてください。
過去ログぐらい嫁

**名前は開発中のものです。** · 2009/01/08(木) 00:19:01

上で議論した気にってるやつはC++を使いこなせてない。
不必要に全部のオブジェクトを１個のリストに乗せる必要もない。

Cとは縁を切るところからはじめるんだ。

**名前は開発中のものです。** · 2009/01/08(木) 00:46:34

ただの倉庫ならどう作っても同じ
俺たちが作りたいのは電動車庫なんだ

ボタンを押せば欲しいものが出てくる仕組み
Javaではリスナー、Cではタスクシステム、C++ならコンテナ、DelphiならTList
みんな完璧じゃないけど一工夫してある

ただの線形リストとタスクシステムの違いはデータにメッセージを送ると能動的に処理が走ること
プログラム側からデータを触ってやらないといけない線形リストだとデータがグローバル変数と
同じように扱われ保守性が落ちる

タスクリストはただの線形リストではない

**名前は開発中のものです。** · 2009/01/08(木) 02:59:34

>>464
過去ログ読んでも同じような煽りしか無いじゃないかw

**名前は開発中のものです。** · 2009/01/08(木) 05:04:27

>>466
ただの線形リストでも要素がクラスインスタンスなら、その「タスクシステムの違い」ってのは
無くなるね。

**名前は開発中のものです。** · 2009/01/08(木) 07:36:03

>>466
何言ってるかわかんない
結局ありがちなごった煮リストなんだろ？
違いをもたせるなよ(笑)

**名前は開発中のものです。** · 2009/01/08(木) 22:56:20

>>469
おまえはまずデザパタとエフェクティブC++を読め。

**名前は開発中のものです。** · 2009/01/08(木) 22:58:05

>>470
やだよ
そんなの役に立たないもん

**名前は開発中のものです。** · 2009/01/08(木) 23:00:27

ニートは金ないから本薦めるても無駄

**名前は開発中のものです。** · 2009/01/08(木) 23:03:23

デザパタは結城浩さんのがわかりやすくていいな

**名前は開発中のものです。** · 2009/01/08(木) 23:10:47

デザパタ自体俺の理論と合わない
ああいうごちゃごちゃしたソース組んで悦に浸ってるのは下手っぴ

**名前は開発中のものです。** · 2009/01/08(木) 23:57:46

開発遅延中の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（・・・）

**名前は開発中のものです。** · 2009/01/09(金) 00:37:39

>>475←こいつＮＧ余裕でした

**名前は開発中のものです。** · 2009/01/09(金) 09:13:46

>>466
コードで語ってくれ

**名前は開発中のものです。** · 2009/01/10(土) 02:10:09

た

**名前は開発中のものです。** · 2009/01/10(土) 03:01:45

す

**名前は開発中のものです。** · 2009/01/10(土) 07:10:36

け

**名前は開発中のものです。** · 2009/01/10(土) 19:24:56

な

**名前は開発中のものです。** · 2009/01/10(土) 22:56:42

ん！？

**名前は開発中のものです。** · 2009/01/10(土) 23:27:35

>>471
読まずに役に立たないだと？

EffectiveC++が役に立たないというならおまえがC++をまったく
使えてないか完全に仕様を理解しているのどちらかでしかない。

C++を理解してデザパタイランというなら頭おかしい。
そのまま流用する必要は無いが、似たようなものを作ることになるのは目に見えてる。

**名前は開発中のものです。** · 2009/01/10(土) 23:41:41

>>483
>EffectiveC++が役に立たないというならおまえがC++をまったく
>C++を理解してデザパタイランというなら頭おかしい
これ好きな人ってだいたいセットで好きだよね

ただ、毎回「これ駄目っていう奴は馬鹿」みたいな雰囲気あるから言わなかったけど
正直、これ何がいいの？って思うようになった

俺もはじめの頃はＣ言語勉強してそのままＣ＋＋に来て
仕事でＣ＋＋で組んでるけど正直、クラスのメリットってよくわかんないんだよね

っていうかよくわからなくなった
ちなみにプログラム経験１２～１３年
Ｃ言語とＣ＋＋では仕事ではＣ＋＋しか使ったことない

>C++を理解してデザパタイランというなら頭おかしい
そうか？
具体的に何がいいの？
俺は実際に使いたがる奴の行動見てたけど
なんでそんな無駄な構造にしたのか上司と衝突ばっかり起こしてて苦労が多そうな奴だなと思った

**名前は開発中のものです。** · 2009/01/10(土) 23:58:22

ダメなやつが使ってるからダメとかいったら何も残らないじゃない。
C言語ではダメなやつは苦労してないの？

どう使えばよいか判らないといってると理解したけども、それでいいのかな？

ユーザーがアクセスできない関数や変数を構造体にもてるだけでも十分メリットだと思うけど。
仕事で頼まれているモノはそうやって制限されてない？　使う側の工夫って使われる側には
見えないものなのよね。

**名前は開発中のものです。** · 2009/01/11(日) 00:05:02

あ、でもイラネって言ってるやつに無理に使ってもらう言語でもないな。
アセンブラに慣れてたら、Cを覚える必要ないわ。

**名前は開発中のものです。** · 2009/01/11(日) 00:30:04

>>485-486
なんの説明もしてないの自分でわかるよね？
他の奴等もだいたいこんな感じで逃げる
それかわけのわからんリンク貼って終了

書籍読んでもこれがこうよくなるって言ってもそのメリットがメリットに感じないし
C言語で書いたソースとC++で書いたソースを比べると
意外とC言語で書いたソースのほうがよく見えたりするよ
ていうかほとんどの場合、大して変わらない

**名前は開発中のものです。** · 2009/01/11(日) 00:49:50

それはどういう分野のソフトウェアを作ってるかによる。
例えばコールバックを多用するフレームワークを扱う場合はCでは面倒すぎる。
しかし昨今のコンシューマゲームでさえC++で開発が当たり前だ。
多分問題はオブジェクト指向原理主義的な野郎がいるってことだろう。

**名前は開発中のものです。** · 2009/01/11(日) 01:30:49

>>486
アクセス制限とデザパタとは関係ないような。
簡単に構造が説明できる(直感的に理解出来る)、非常に良く使われる構造である、統一的に機能を追加できる(またはそのようにする、そして楽)
のうち最低でもいずれかが実現できてることがデザパタの意義・・・かな？
逆に、これがどれも実現できてないのにデザパタ使いました、では
たとえパターンの構造通りになっていたり、また適切にアクセス制限がされていても本質からずれてる。

>>484の>なんでそんな無駄な構造にしたのか上司と衝突ばっかり起こしてて苦労が多そうな奴だなと思った
ってのもなんか多そう。中途半端に理解したデザパタは一番の害悪。果たして他人にぱっと説明できるのかと。

と、中途半端にデザパタを読んだ自分が言ってみる。

**名前は開発中のものです。** · 2009/01/11(日) 01:49:21

デザパタか
strategy?　ああ、lambdaと高階関数に珍妙な名前つけた奴ね
って奴にはまあ要らねーのかもな

Cは面倒くさいだろ流石に
と思うが、C++はC++で別の意味で面倒くさいんだよな
大して表現力ねーくせに無駄に複雑でな

**名前は開発中のものです。** · 2009/01/11(日) 09:05:10

>>466
流用性の無い足手まといイベントハンドラが増えただけにしか見えない。
あと戻り値はグローバル変数で渡すの？

//もともと必要な処理（ゲームオブジェクトクラス１個分）
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;

**名前は開発中のものです。** · 2009/01/11(日) 14:05:48

自分はいわゆるタスクシステムがどんな構造なのかよくわからんので色々気になったので読んでみた。
>>2のサイト先だと単なる動的配列(リスト構造)。別に『優先順位つきリスト構造』で説明が事足りる。
(全体長を固定する・またはノード自体をnewすることストを抑えたいならリスト構造2つ。事実上メモリ監視がついて回るのでこうなるが。)
で、色々読んでるといわゆるタスクシステムでは構造自体が重要なのではなく、メモリ使用の監視が主題ってのはなんとなくわかった。
だからメモリ監視にかかわる構造が必要でリスト構造に比べ多少複雑になってる、と。

つまりタスクシステムは

・ゲームを管理する構造△
・メモリの使用量など監視する構造○

タスクシステム自体の話は以上で完結するのよね。

タスク同士間の情報のやり取りやイベントハンドラ云々ってのはタスクシステム自体の話じゃなくて、
リスト構造で管理したときそれぞれのノード間のやりとりをどう管理するかって話でしょ？ふと思った。

**名前は開発中のものです。** · 2009/01/11(日) 17:12:30

仮にタスクシステムの主題がメモリ管理だとして、じゃあタスクシステムから主題じゃないはずのタスクの概念を取り除いたら後に残ったものは果たしてタスクシステム？
メモリ管理システムでは？

メモリ単位管理システムと処理単位管理システムがもともと癒着しているタスクシステムというものを選択した時点で、既にタスクとかノードという概念の使用を選択したことになっている。
ノードという概念の使用を強制されるならノード間のやりとりをどう管理するかの検討も必須の話かなぁとか。

**名前は開発中のものです。** · 2009/01/11(日) 18:57:05

>>493
もちろん。
ただ、どうもこのスレはタスクシステムのどこの仕様決まりきってて、決まりきってないどこを議論すべきなのかが混沌としてるから。

例えばこのスレでもずっとタスクシステムはリスト構造じゃねぇ、という意見が殆どを占めていて俺リスト乙。的な流れが多い。
確かにタスクシステムはリスト構造ではない、は正しいが、
ノード間のやり取りを議論しようとしたら、リスト構造を踏まえて、というかハードを意識しなければリスト構造なのでそこで語るのは正解。
つまりその手の話は俺リストの話をするべき。

**名前は開発中のものです。** · 2009/01/11(日) 22:14:53

>>494
「ノード間のやり取りを議論しようとするならその前にまずは俺リストの話をするべき。」
と受け取ったけど、ノードから見た通信インタフェースなんて
　　1.グローバル変数直接アクセス
　　2.メッセージングとかイベントハンドラ的な仕組み
　　3.move, update, drawなど数を絞った仮想関数インタフェース
の3つ位しか思いつかない。しかも2, 3は表現が違うだけでやってることは等価だと思うので実質1もしくは2・3の２種類のみ。
グローバル変数を使用禁止とするなら2・3の手法一択。

乱暴に言えば、タスクシステムの意義は2・3をゲームオブジェクト単位に導入することを強制する意義と等価だとして話を絞ってしまえば
どのようななんちゃって俺タスクシステム・俺リストを使っていようが全く関係無く話できると思う。っていうか話終わると思う。
もっとおおざっぱに行こうじぇ

**名前は開発中のものです。** · 2009/01/11(日) 23:18:26

だよなぁ・・・。
うちら2人だけじゃいまいち不安だが、タスクシステムに関することってそんな感じだよね。

・タスクシステムはメモリ管理機能のある優先順位つきリスト構造
→メモリ管理およびリスト構造自体は決まりきった構造なので議論の余地なし。
→リスト構造のノード間のやり取りもメソッド等の使用であることは自明。

となるとかなりの部分はソースコードとして確定できそう。

で、まだでてきてない部分はこんなところか。
・具体的なメソッドややり取りはどのように管理するべきか。
煮詰めりゃ最適解は出せそう。

・タスクは別のタスクを追加しうる。生成したタスクはどうリスト構造に渡すか。
1、処理関数の戻り値として。追加の仕方はリスト構造自体を処理している誰かに委ねる。
2_A、リスト構造をタスク内でフィールドで保持。
2_B、処理関数がリスト構造自体を引数にとって内部で処理。
まぁ、2_Bが好きです、私は。

・タスクは例えばどんな塊なのか、どんなインタフェースを持つべきなのか。
これは色々考えられそう。
シーン管理はリスト構造の外側でしてるとして、他は全部リスト構造内で処理していると思いたい。優先順位機能搭載してるわけだし。
こっちも煮詰めりゃある程度解がでそう。

**名前は開発中のものです。** · 2009/01/11(日) 23:41:44

いや、普通に C++ で仮想関数とコンテナ使って組めって。
もっと言うと、コンテナにする必要だって常にあるわけじゃない。
普通にメンバに持ってれば十分、っていうかそっちのほうがわかりやすいこともあるだろ。

そうでないなら、「タスクシステム」とやらで解決される問題を挙げてから話してくれないか？

**名前は開発中のものです。** · 2009/01/12(月) 00:34:41

>>496
俺はタスクシステムやめとけ派
タスク化をゲームオブジェクト単位に導入することを強制する意義は無いと思う。
メソッドの数を絞らなきゃいけないのがきつい。その最大最悪の制約の解消の目処も立ってないうちから
他の特徴を生かす方向を先に検討するとかは順序が違うと思う。

メモリ管理が重要じゃなくなったのならタスクシステムやめてそれ以前に戻るとか、
タスク化の適用対象をゲームオブジェクト以外にするとどうなるかとか考えて、まずは最大の制約を取り除くのが先じゃない？
ここがダメなら他の機能の利点なんて全部ふっとぶ凶悪な制約だと思うよ＞通信の抽象化＆全体共通化強制

例えばフレームワークの内部実装だけに適用する。
例えばもっとたくさん、座標管理（なんちゃって）タスクシステム、当たり判定管理（なんちゃって）タスクシステム、UI管理（なんちゃって）タスクシステム、...を作って組み合わせる。
例えばシーンと呼ばれる枠組みだけに適用してみるなどなど考えてくと、タスクシステムという形を残す必然性がなくなった。俺の場合。

**名前は開発中のものです。** · 2009/01/12(月) 02:16:26

というかC++はタスクシステムをさらに豪華にしたものだからC++を極めろ。

**名前は開発中のものです。** · 2009/01/12(月) 03:55:30

>>498
タスクを管理するクラスからの呼び出しだけ同じにしておけば、
別にメソッドの数を絞る必要はないと思うけど。

**名前は開発中のものです。** · 2009/01/12(月) 06:10:14

一番シンプルな形がいわゆるタスクシステムで、
それをそのまま使ってる人はいないんじゃないの？

**名前は開発中のものです。** · 2009/01/12(月) 12:58:51

>>498,501見たいな流れに持ってくから話題がループするんだろ

>>498
色々勘違いしてるし、いってる意味がわからん部分がある。
1、タスクシステムの是非についてまったく話していない。結局タスクシステムの定番の形がどんな形なのかというのが知りたい。まだ定番の形は決定できる部分があるだろう。
2、順序が違う周りは何がどう違うのかさっぱりわからない。少なくともoopの設計の仕方ならば、オブジェクトを先になんとなくまとめ、メッセージを決めていくのもありなのだが。
それともいきなりソースコードレベルでびしっと決めるつもりだろうか？
3、ゲームオブジェクトでは抽象的過ぎる。それに含まれる具体例が最低3つぐらいあげてほしい。この定義により恐ろしいほど処理の範疇が変わる。
4、メモリ管理周りの話。何度もいうように、リスト構造のやり取りについて語ってる。タスクシステムについて語っていないと思う。まぁこちらの言い方も悪かったか。

それはそうとして、最後の話の構造、あれ思ったより拡張性低くね？仕様変更に迫られたときに耐えられないべ。
本来プログラムの構造はマトリョーシカ状にして、設計の修正が必要な場合の修正項目を最小限に抑えるべきだと思うんだが、ありゃ管理クラスが色々やりすぎてる気がする。

>>500
よくやる。つまりnode.run()みたいに一枚はさんでから、具体的な処理構造を実行するってことか。

>>501
多分この意見もかなりこのスレの流れでループしてるんじゃ無かろうか。だからもう少し話を進めて確定したい。

**名前は開発中のものです。** · 2009/01/12(月) 20:03:59

ID:JZO5iyFx ＝ ID:YXD0YS+N　　なのか？なんか至る所がおかしいな

>>492
＞>>2のサイト先だと単なる動的配列(リスト構造)

どこが動的配列なのか分からない。インターフェースも実装も動的配列ではない。

＞構造自体が重要なのではなく、メモリ使用の監視が主題ってのはなんとなくわかった。
＞だからメモリ監視にかかわる構造が必要でリスト構造に比べ多少複雑になってる、と。

悪いが意味が分からない。何を読んでその結論に至ったのか、アンカーを全部列挙してくれ

＞つまりタスクシステムは
＞
＞・ゲームを管理する構造△
＞・メモリの使用量など監視する構造○
＞
＞タスクシステム自体の話は以上で完結するのよね。

ならばそれはただのメモリプールでありアロケータの一種であり、それ以上でもそれ以下でもなく
タスクシステムなどと名乗る理由は微塵もないわけだから、お前は速やかにタスクシステムという
呼称を使うのをやめたらどうなのか。なぜタスクシステムという何処の馬の骨かも分からない田舎侍の
ローカル用語に固執するのか理解できない