タスクシステム総合スレ 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/

**名前は開発中のものです。** · 2008/12/07(日) 14:40:22

>>208
まぁその記事の「タスク」は、MTフレームワークの用語としての「タスク」だと
思うが。

**名前は開発中のものです。** · 2008/12/07(日) 16:34:44

>>209
このスレで言ってるタスクシステムとなにが違うの？

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

**名前は開発中のものです。** · 2008/12/07(日) 17:02:09

>>210
まあ、似たようなもんだろ

**名前は開発中のものです。** · 2008/12/07(日) 17:12:29

ただ、あんまりうまくいってねぇ気がするね
だってそんなもん作ったわりにそれほど見応えのあるソフト連投してねぇし

**名前は開発中のものです。** · 2008/12/07(日) 20:03:21

ジョブコンがアンチパターンである理由

１．グローバル変数（または静的クラス変数）を多用しがち
２．抽象的すぎる（シーン、入力処理、衝突判定、描画物などを同じ抽象レベルでリスト化できてしまう）
３．２のためにプライオリティ変数のような順序制御機構が別途必要になる
４．３のために処理の流れがコードから読み取りずらくなる（このスレの「ＦＳＭが云々」のくだりはこれを指摘している？）
５．配列の方が速い（ＣＰＵ最適化厨乙ｗいやマジでがんばれｗ）
６．ひらしょー先生が批判している（よく知らんけど・・・）

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

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

**名前は開発中のものです。** · 2008/12/07(日) 20:56:55

タスクシステム否定派　＝　人の意見に盲従するヘタレ

ということはわかった。

**名前は開発中のものです。** · 2008/12/07(日) 23:20:58

＞１．グローバル変数（または静的クラス変数）を多用しがち
変数の参照範囲は必要なだけ広く、そして最小範囲
タスクシステムだからこれが出来ないという理由はない
少なくともリストや配列を使った非タスクシステム比べて
変数の参照範囲を広くとる必要などない

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

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

＞４．３のために処理の流れがコードから読み取りずらくなる
＞（このスレの「ＦＳＭが云々」のくだりはこれを指摘している？）
順序制御機構があるならコードは見やすいだろう
関数ポインタのせいで直感的ではないという指摘ならともかく

**名前は開発中のものです。** · 2008/12/07(日) 23:21:29

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

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

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

**名前は開発中のものです。** · 2008/12/08(月) 00:01:48

>順序制御機構があるならコードは見やすいだろう

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

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

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

**名前は開発中のものです。** · 2008/12/08(月) 00:11:25

>>215
>変数の参照範囲は必要なだけ広く、そして最小範囲
>タスクシステムだからこれが出来ないという理由はない
>少なくともリストや配列を使った非タスクシステム比べて
>変数の参照範囲を広くとる必要などない
それってソースコード読む人にどうやって伝えるの？

**名前は開発中のものです。** · 2008/12/08(月) 08:47:20

>>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。多少回りくどいが、メッセージのパスがシンプルになってコード
見れば一目瞭然になるので、バグは減るし追加処理を入れやすい。

単一型リストにしちゃうと引数型も当然単一になるから、引数で情報を渡すのが
不可能になって、結局グローバルな領域に情報を記録することになる。そうなると
いつ誰が読み書きするかわからないので、予期しないタイミングで予期しない処理を
されて泣くわけだ。

**名前は開発中のものです。** · 2008/12/08(月) 08:52:11

ゲームの場合は、プログラムの基本構造が「一定時間ごとに外から関数を呼ばれる
小さなオブジェクトの塊」になる。

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

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

なんかいきなりジョブコン叩きをはじめた奴がいるが。

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

**名前は開発中のものです。** · 2008/12/08(月) 12:28:19

叩いているようには見えないし
そもそもコルーチンじゃないし
信者を装うにも無理がある

**名前は開発中のものです。** · 2008/12/08(月) 12:56:45

>>220
仕様変更が起こってもソースの変更範囲を小さくできるなんてメリットだとは思わないな。
それができるということは仕様とソースが乖離していること、乖離していくことを示している。

**名前は開発中のものです。** · 2008/12/08(月) 13:24:53

>>223
確かに仕様変更の中身に強く依存することなので
一般論としてしまうには無理があるな。
設計によって対応しやすい変更としにくい変更があるだろうから
それらを具体的に考えてみるのもいい。

**名前は開発中のものです。** · 2008/12/08(月) 13:40:00

>>223
> 仕様変更が起こってもソースの変更範囲を小さくできるなんてメリットだとは思わないな。
> それができるということは仕様とソースが乖離していること、乖離していくことを示している。

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

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

**223** · 2008/12/08(月) 14:05:31

>>225
ごめんよ。もちろん１つの仕様変更であちこち変更するのを基準に「小さく」って話を
してるわけじゃないんだ。

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

**名前は開発中のものです。** · 2008/12/08(月) 19:17:09

>>226
同意
特にグローバル変数まで使って変更を強引に縮小することにメリットは全く無い

**名前は開発中のものです。** · 2008/12/08(月) 21:47:43

グローバル変数を使っていれば、明示的に引数などで渡す必要がない
struct 使っていれば、わざわざ setter, getter を使う必要がない

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

**名前は開発中のものです。** · 2008/12/09(火) 21:57:26

タスクシステム
ストラテジーパターン
FSM

違いがわかりません

**名前は開発中のものです。** · 2008/12/09(火) 23:12:27

タスクシステムはC言語より前に生まれたのでは

**名前は開発中のものです。** · 2008/12/09(火) 23:57:46

>>230
キミはＣ言語の誕生をいつと思ってるのカネ？

**名前は開発中のものです。** · 2008/12/10(水) 00:41:20

UNIX用に作られたくらいだった気がするので３０年前くらい？

http://www.ijinden.com/_c_12/Ken_Thompson/Pears_UNIX.html
１９７３年だな。

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

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

**名前は開発中のものです。** · 2008/12/10(水) 01:56:38

230を好意的に解釈すると

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

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

**名前は開発中のものです。** · 2008/12/11(木) 00:44:32

>>208
汎用。これはとても便利な言葉だ
これは何にでも使えるね、というポジティブな意味に使えるし
これは何にもできないね、というネガティブな意味にも使える
どちらに重みが置かれるかはケースバイケースだが
仮に後者の重み係数が大きくても角が立たないという魅力的な言葉だ

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

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

**名前は開発中のものです。** · 2008/12/11(木) 01:28:26

いちいち駆け引きしなきゃ話もできんようなやつとは
仕事したくないなあ

**名前は開発中のものです。** · 2008/12/11(木) 10:19:51

90年代？自分の記憶がソースかよ

**名前は開発中のものです。** · 2008/12/11(木) 22:05:22

>システムはどうかしらないけど、ゲーム業界でタスクは一般的になってると思うよ。

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

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

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

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

>>237訂正
>ユーザーに直接タスクを記述させて

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

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

**名前は開発中のものです。** · 2008/12/12(金) 01:51:42

半年程うだうだやってようやくタスクシステム卒業できた気がする俺からのヒント。
これでこのスレからも卒業だ！

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

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

**名前は開発中のものです。** · 2008/12/12(金) 01:52:20

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

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

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

**名前は開発中のものです。** · 2008/12/12(金) 02:04:21

おまえらやっぱり1度Java経験しといたほうがいいと思った

**名前は開発中のものです。** · 2008/12/12(金) 05:20:00

>>239-240
タスクシステム大好きっ子を締め上げたりしてる俺だが流石にお前は可哀相に思う

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

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

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

**名前は開発中のものです。** · 2008/12/12(金) 07:57:45

タスクシステムって単なるオブジェクト指向プログラミングなんじゃねーの？
時代に乗り遅れた奴らが悶絶してるスレにしか見えないｗ

**名前は開発中のものです。** · 2008/12/12(金) 08:56:23

>>243
オブジェクト指向のキモは、クラスの洗い出しと、クラス間の関連を見極めること。
何でもかんでもグローバル変数に書いて共有するのはダメだろ。

**名前は開発中のものです。** · 2008/12/12(金) 13:54:57

タスクシステムとグローバル変数には何の関連性もないし
タスクシステムがオブジェクト指向であるというのもそのとおり。

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

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

**名前は開発中のものです。** · 2008/12/12(金) 22:29:53

クラスもなければプロトタイプでもない、CLOS のような多態のメカニズムもない。
どこがどうオブジェクト指向なんですかね。

**名前は開発中のものです。** · 2008/12/12(金) 22:35:04

>>243
１口にオブジェクト指向といってもメッセージングとオブジェクト主体の動的なものと、
構造体主体の静的なものとかがある。前者はスクリプト言語とか。C/C++は主に後者。

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

**名前は開発中のものです。** · 2008/12/13(土) 00:25:41

このスレの異常に不憫な嫌タスク厨を見てて
いつも思うことがあるんだが・・・

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

**名前は開発中のものです。** · 2008/12/13(土) 00:26:53

>>242
WM_LBUTTONDOWNとかWM_MOVINGとかWM_DESTROYみたいなイベントも扱う。
それら入出力関係・アプリ生存期間の制御関係のものと、ゲーム処理をいっしょくたに
扱える標準的インタフェースなんて作るなというのが主旨。
もし作ろうとすると
　1.イベントハンドラで統一
　2.やっぱ使い勝手悪いのでゲーム処理はenter_frame(), display(), move()の３つだけに集約
　　→タスクシステムいっちょあがり
となる。

あとenterframe()とdisplay()で分けたけど、よく考えたらenterframe()１個で足りるかも。
ゲーム処理は1フレームに1回、1つの関数呼ぶだけで足りるし。
というかenter_frame()さえもいらないかも。
どこかで誰かが全入出力デバイスの面倒見る必要は結局あるもんね。
俺はなんか分けてたからああ書いたけど。その辺はごめん。

重要なのは「入出力デバイス処理とゲーム処理は別物」ということ。
そして別物なので、「ゲーム処理にまでイベントハンドラ適用しようとすんな」ということ。
タスクシステム＝イベントハンドラ崩れorイベントハンドラの俺ゲーム最適化後というイメージを持ってる。
OSも昔とか組み込み系の貧弱な環境とかではユーザランドとOSの切り分け曖昧だったりOS無しで自前管理だったりするけど、
規模大きくなるとそれじゃ成立しなくなるのに似てるかも。

メインループとかの構造はそう、大体そんな感じでＯＫじゃね？　あんまそこは興味ない。
main関数からじゃなくいきなりイベントハンドラから始まる環境とかあるし、正直動けばそれでいい。
一応俺はそのd3ddev->Present()をdevice.wait_frame()に置き換えてその中でDispatchMessage()ぐるぐる回しつつ1フレーム待ってるやり方。

**名前は開発中のものです。** · 2008/12/13(土) 01:06:41

>>249
それってホーミングミサイルがターゲッティングした相手とか
キャラと移動床、移動床と固定壁の相互判定の処理とかって
どこ飛んでいっちゃってんの？

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

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

**名前は開発中のものです。** · 2008/12/13(土) 01:16:46

>WM_LBUTTONDOWNとかWM_MOVINGとかWM_DESTROYみたいなイベントも扱う。
>それら入出力関係・アプリ生存期間の制御関係のものと、ゲーム処理をいっしょくたに
>扱える標準的インタフェースなんて作るなというのが主旨

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

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

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

**名前は開発中のものです。** · 2008/12/13(土) 01:38:03

>>250はレス先間違えたｗ

**名前は開発中のものです。** · 2008/12/13(土) 02:16:57

>タスクシステム＝イベントハンドラ崩れorイベントハンドラの俺ゲーム最適化後というイメージを持ってる。

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

**名前は開発中のものです。** · 2008/12/13(土) 09:18:22

イベントというかメッセージだったかな
HSPerは頭よくないから使い分けがよくわかんないの

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

**名前は開発中のものです。** · 2008/12/13(土) 15:00:33

>>242
不憫なやつだな、お前
なんかわかった気になっちゃってんだろうけど

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

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

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

**名前は開発中のものです。** · 2008/12/13(土) 15:49:54

モナドを使ったステートレスなタスクを考えてください

**名前は開発中のものです。** · 2008/12/13(土) 16:20:05

CPSでおｋ

**名前は開発中のものです。** · 2008/12/13(土) 21:30:40

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

**名前は開発中のものです。** · 2008/12/13(土) 23:19:03

本当のタスクシステムはリストではなくリングバッファ
リスト使うやつはまがい物

**名前は開発中のものです。** · 2008/12/14(日) 02:07:26

>>255
で、なんで急に「ジョブコン」の話を始めてるのかな？
俺は>>2の話をしたがお前はそれを「ジョブコン」の話だと思ってるのかな？
もしかしてお前、>>2＝「ジョブコン」だとでもいいたいのかな？まさかね

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

人として

**名前は開発中のものです。** · 2008/12/14(日) 04:35:12

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

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

**名前は開発中のものです。** · 2008/12/14(日) 06:36:31

描画順序を内包するから問題になるのであってそれは外にだせばいいだけだな
それでも複雑・特殊化した描画のシーケンスに対する柔軟性のなさは相変わらずだけど

**名前は開発中のものです。** · 2008/12/14(日) 08:13:40

業務用アプリでさえタスクシステムなのにお前らいつまでこんなネタを繰り広げてるんだよ

**名前は開発中のものです。** · 2008/12/14(日) 10:46:26

×タスクシステム
○イベント駆動

**名前は開発中のものです。** · 2008/12/14(日) 13:38:40

タスクシステム　＝　リアルタイム・ゲームにおける並列動作処理の基本アイデア

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

**名前は開発中のものです。** · 2008/12/14(日) 13:55:05

>>265
ゲームの基本アイデアは、

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

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

**名前は開発中のものです。** · 2008/12/14(日) 14:13:11

「定期的」オブジェクト：
　フレームワーク（タスクの生成／消滅／アクティブ化／非アクティブ化）

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

・・・ということ？

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

**名前は開発中のものです。** · 2008/12/14(日) 20:09:25

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

**名前は開発中のものです。** · 2008/12/14(日) 23:37:27

イベント駆動とメッセージングOOPの組合せ程度じゃ
単なるよくあるGUIプログラミングの定石じゃない

**名前は開発中のものです。** · 2008/12/15(月) 07:22:29

>>267
for (;;) {
　player.exec(*this);
　std::for_each(enemies.begin(), enemies.end(), boost::bind(&Enemy::exec, ::_1, boost::ref(*this)));
　WaitVSync();
}

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

**名前は開発中のものです。** · 2008/12/15(月) 22:10:39

ポエマーだけど、人違いされたままなのは気に入らないので横合いからちょっかい出してみるのねー

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

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

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

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

**名前は開発中のものです。** · 2008/12/15(月) 22:12:34

×師事を受けた
○教えを授かった

**名前は開発中のものです。** · 2008/12/15(月) 22:14:32

△ジョブ（複数個）、固定時間刻みで
○ジョブ（複数個）を固定時間刻みで

**名前は開発中のものです。** · 2008/12/15(月) 22:22:24

一方で、>>238とか>>253の順次処理というのは連結リストに繋がれた順番の話だと思うのねー
繋がれた順番に実行するということ。つまり順次処理。バッチ処理だね

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

**名前は開発中のものです。** · 2008/12/15(月) 23:09:23

×>>257
○>>261

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

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

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

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

**名前は開発中のものです。** · 2008/12/15(月) 23:57:34

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

**名前は開発中のものです。** · 2008/12/16(火) 07:45:28

スクリプトも無節操に使うとグローバル変数、関数とかわんない

**名前は開発中のものです。** · 2008/12/16(火) 10:06:25

タスクシステム＞働いたら負けかなと思ってる

**名前は開発中のものです。** · 2008/12/16(火) 11:17:10

というか、ジョブコン（コルーチン）話はこのスレのスコープに入るわけ？

**名前は開発中のものです。** · 2008/12/16(火) 20:51:33

>>270
それってタスクシステムのアイデアを、そのままライブラリで厚化粧しただけじゃん

**名前は開発中のものです。** · 2008/12/16(火) 22:19:38

> ジョブコン（コルーチン）
は？

**名前は開発中のものです。** · 2008/12/16(火) 23:25:50

>>277
一般的には、スクリプトは C++ の単一のインスタンスに張り付ける。

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

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

**名前は開発中のものです。** · 2008/12/17(水) 01:53:45

スクリプトのほうが利点があるなら最初から全部スクリプトで作ればいいじゃない？

**名前は開発中のものです。** · 2008/12/17(水) 02:06:46

>>283
適材適所。大半を全部スクリプトで作ったほうが良いのは、アドベンチャー
ゲームぐらいじゃないかなぁ。

**名前は開発中のものです。** · 2008/12/17(水) 02:40:55

>>281
ジョブコン＝コルーチンって理解じゃ違うのか？

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

**名前は開発中のものです。** · 2008/12/17(水) 10:18:44

ジョブコンってコンテキストスイッチないじゃん
ただのステートマシン

**名前は開発中のものです。** · 2008/12/17(水) 11:41:46

>>286
http://game.2ch.net/gamedev/kako/1006/10061/1006184421.html の 810 を
100 回読んでこい。

**名前は開発中のものです。** · 2008/12/18(木) 18:05:58

あった
http://jp.youtube.com/watch?v=3JWl1IikUBE&feature=related

**名前は開発中のものです。** · 2008/12/20(土) 00:01:42

>>287 読んだ。
>スタックにプッシュしてあるリターンアドレスも含めた
>ＣＰＵコンテクストを復帰させて各ジョブを呼び出す。
>ただし、リターンアドレスをポップする形で呼び出すので、
> RTS で呼び出す訳ですが。

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

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

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

**名前は開発中のものです。** · 2008/12/20(土) 15:39:24

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

**名前は開発中のものです。** · 2008/12/20(土) 16:29:07

貴様に命令されるいわれはない

**名前は開発中のものです。** · 2008/12/20(土) 23:01:46

>>289
ありゃ、間違ってるな。てか、興味ない人はスルー願います。
>ただし、リターンアドレスをポップする
>形で呼び出すので、 RTS で呼び出す訳ですが。

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

**名前は開発中のものです。** · 2008/12/21(日) 01:37:52

>>292 は>>287を読んだだけで内容を理解できてないと思うから
ぐだぐだ書く前にちゃんと理解する努力をしろ。

**名前は開発中のものです。** · 2008/12/21(日) 20:27:14

>>293
まあ、そう突っかかんなよw
ではよく理解している293に教えて欲しいんだけど、

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

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

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

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

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

**名前は開発中のものです。** · 2008/12/21(日) 20:30:02

定義ごっこウゼーからヤメロよ
名前なんて関係ねーよ

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

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

**名前は開発中のものです。** · 2008/12/21(日) 20:38:47

>>290にはたぶん向いているんだろう。俺にはちょっと使いづらいかなと思った。
あんまり頭よくないんで、全体を把握しにくいコードでポインタを使いまわす
のはおっかないと思ったよ。

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

**名前は開発中のものです。** · 2008/12/21(日) 21:37:18

>>295
new 厳禁, malloc問題外かあ、そりゃ難儀だな。
295 はよほどでかいスタック使ってるんだろうなあ。すばらしい。

**名前は開発中のものです。** · 2008/12/21(日) 23:03:28

>>297
ああ、やっぱり馬鹿なんだｗ
馬鹿だから横文字連発して誰でもできる名称の定義にこだわってんのバレバレ
あー恥ずかしいｗ

**名前は開発中のものです。** · 2008/12/22(月) 10:25:16

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

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

**名前は開発中のものです。** · 2008/12/22(月) 18:52:48

ID:oW76AwO4
ID:9M4acoh9
ID:1VWYpijd
＞みたいに口汚く否定しなければならないのか？

↑（ﾟ∀｡）↓

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

ルサンチマン号…

**名前は開発中のものです。** · 2008/12/22(月) 23:23:50

>>299
自キャラクタのデータを TCB に置くのは当然として、タスク間の相互作用を
どう記述するかが問題。ヒット判定とかホーミング弾とか。

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

**293** · 2008/12/22(月) 23:56:55

>>294
俺は271じゃないから271の考えてることはわからんよ。

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

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

**名前は開発中のものです。** · 2008/12/22(月) 23:59:47

>>289
やぁどうも

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

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

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

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

**名前は開発中のものです。** · 2008/12/23(火) 12:44:20

えーと。

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

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

確かにこっちは無理だw

**名前は開発中のものです。** · 2008/12/23(火) 12:52:38

文章長すぎる奴自重しろ
中身もねぇのにだらだら無駄に長い
ホントにプログラマーか？お前

**名前は開発中のものです。** · 2008/12/23(火) 12:53:09

>>302
> ・TCBとスタックポインタというRTOSで使われる用語を全く別の一般的じゃない意味で使ってる
> ので、ああいうのが代表的な解説になってるんじゃヤバいと思うよ。

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

**名前は開発中のものです。** · 2008/12/23(火) 12:54:05

>>305
継続を一言で説明できるのかお前は？

**名前は開発中のものです。** · 2008/12/23(火) 15:09:59

KEIZOKU？