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

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

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

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

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

とりあえず、描画タイミング、ゲームオブジェクトの移動、当たり判定なんかの処理は一定間隔で行いたい。
だから、単純なゲームのとあるシーンは以下のようになる。
while(1) {
　　描画
　　ゲームオブジェクトの移動
　　当たり判定
　　時間調整
}

次にタイトル画面を表示するシーンが欲しいなと思ったら、もう一つループを追加する
while(1) {
　　描画(タイトル画面表示)
　　キー入力
　　時間調整
}

シーンの数だけループができた。
じゃあ、このループを一般化して、ハードコーディングではなく、外部からのスクリプト読み込みなどで
動的に生成できないかと悩んでみると、タスクシステム(っぽい何か)に行き着いた。

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

>>318
ただのFSMではなくコルーチン＆スケジューラが実装されていたのなら
そう書いてもらったほうが分かりやすい

**名前は開発中のものです。** · 2009/02/08(日) 23:28:08

>>298
指標をいくつか決めて実装手法ごとに○×付け。一番○が多いのを使う。
これでいいんじゃね？

どういった表現方法使ったってどうせ全部「データの受け渡し」であることには変わりない。
概念的には一つのことを実現しようとしてるだけ。

もし引数の概念が無い言語ならグローバル変数使わざるを得ないし、
グローバル変数の概念が無い言語なら引数使わざるを得ないかもしれない。
この辺の手法の差異なんて言語に左右されるような瑣末なこと。

C++ではたまたまいろいろな手法が利用可能だけども
概念的には「データの受け渡し」だけが目的なんだから、
CPU使用時間とかメモリ使用量とかソース可読性とかそういった瑣末な指標によって選択すればいい。
「C++におけるデータ受け渡しの実装手法はどれが一番概念的に優れてるか」とか悩むのは
そもそも問いかけの選択からして間違ってる。どれも概念的には「データの受け渡し」で同一のもの。比較不可。
優劣が付けられるのは前述の瑣末な指標で比較した場合のみ。

C++がやれること多すぎて悩むの疲れたのならいっそもっと選択肢少ない言語に変えてみたら？
Cとかに。わりと本気で。
#レスなげえ、俺きめえ。ごめんね

**名前は開発中のものです。** · 2009/02/08(日) 23:36:38

C縛りは問題の本質を考える上でいいと思うが
納得しない人たちもいると思う

オレはC++大好きデザパタ大好きだが、自戒をこめてこの言葉を君たちに

C++ はひどい言語だ。これは、多くの平均以下のプログラマーが使ってるために
さらに輪をかけてゲロゲロになっていて、どうしようもないゴミが簡単に生産されるようになってる。
正直いって、C を選ぶ理由が C++ プログラマーを追っぱらうため *だけ* だったとしても、
それ自体、C を使う強力な理由になりうる。
-- Linus Torvalds

**名前は開発中のものです。** · 2009/02/08(日) 23:36:54

「ホットスーププロセッサ」・・・チッ、気取った名前付けやがって。
「タスクシステム」を批判できる立場にねーだろ。

**名前は開発中のものです。** · 2009/02/08(日) 23:42:17

>324
いやいや、作ったソフトにどんな名前をつけるかは作者の権利だ。
それについてどうこう言うのと、『タスクシステム』という名前についてアレコレ言うのは
違う気がするぞ。

**名前は開発中のものです。** · 2009/02/08(日) 23:44:14

>>325
悪い、ちょい嫉妬しただけだ。
大人げなかったな。

**名前は開発中のものです。** · 2009/02/08(日) 23:46:18

いや、落ち着いて逝こうぜ。

**名前は開発中のものです。** · 2009/02/08(日) 23:48:32

>>322
確かになー。
本当に悩むべきはそんなところじゃねーだろーっていつも頭では思うんだけど、
「もし理想のやり方が見つかれば、二度と悩まなくて済む」って甘い罠に取りつかれちゃうんだな。

つーかなんかタスクシステムに限った話じゃなくなってるな。
↓こっちの話題だなすまん。

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

**名前は開発中のものです。** · 2009/02/08(日) 23:49:52

タスクシステムとやらにこだわる人は
HSP使った方がいいよ、資源の無駄
かっこつけてC++なんて使う意味ないって
俺かっこいい超天才C++使いこなす俺超天才って言って
一ヶ月かけて作ったゲームも
HSPなら三日で作れるから
所詮タスクシステムなんてその程度
DSL的アプローチとしてはHSPの方が有益
タスクシステムはうんこ
うんこに指差してうんこって言って何が悪い
これはうんこじゃないやいって言ったところで
それはうんこだ
うんこうんこ

**名前は開発中のものです。** · 2009/02/08(日) 23:54:43

あぁ、ウンコが何か吠えているw

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

>>328
いっぺん表作っちゃえば二度と悩まなくて済むよ
処理時間短縮重視ならこれ、メモリ使用量極小を狙うならこれ、
とかって簡単に決定できる

まぁ、大体PCならメモリとかCPUなんて潤沢に使えるから気にせず
コードの可読性だけでさくっと決めていい気がするけど

**名前は開発中のものです。** · 2009/02/09(月) 00:28:43

>>315
普通にできるだろ
馬鹿かお前大丈夫か？
ていうか一度でも組んでみてから言ってくれよ

つーか、お前、タスクシステム云々がどうとかそういうところこだわる前に
プログラマとしてヤバイだろｗ

**名前は開発中のものです。** · 2009/02/09(月) 00:54:39

実際HSPでもシューティングゲームぐらい作れるしな。

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

HSPで済むならそれを使っておけばいいんだよ。
適材適所。

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

>>315
なーにが広義のタスクシステムだ。バッカじゃねーの？このカッペ野郎
毎度毎度テメェの都合でローカル用語の解釈を変えてんじゃねー
あと"ジョブ時間管理"とか訳のわかんねー用語を発明すんな

お前いつもそんなふうに新しい用語をクリエイトしながら他人とお話しするの？

**名前は開発中のものです。** · 2009/02/09(月) 07:48:20

>>320こ
タイトル画面や戦闘シーンは、相互依存がほとんどなく、インスタンス数もたかが知れてる。また処理パターンが仕様変更で変わる可能性がある。

そういう用途には、std::list<> に virtual void exec() だけ実装したクラスのインスタンスを入れておいて、定期的に呼び出してやれば良い。システムと呼ぶ程のモノじゃないがな。

一方、プレイヤーや敵キャラなどは、上の前提条件が成り立たない。相互依存が多く、処理も一度「移動、ヒット判定、死亡判定」と決めたら、まず変更しない。
困難なポイントが違うので、解決策も必然的に変わってくる。

**名前は開発中のものです。** · 2009/02/09(月) 12:40:04

>>336

これでＦＡ。

**名前は開発中のものです。** · 2009/02/09(月) 13:30:04

>>335
>あと"ジョブ時間管理"とか訳のわかんねー用語を発明すんな
まだ君の頭では理解できないことかもしれないけど
”MTフレームワーク”でググって勉強してみれば意味が分かるかもね…

**名前は開発中のものです。** · 2009/02/09(月) 16:20:33

もうちょっと違う切り口から。
今、ゲームを　ウィンドウ　と　DirectX　と　ゲーム管理　と　ゲームオブジェクト　の4つに分けて考える。
データの流れ(処理の流れ)に着目すると、
　　DirectX　　　　　　　　→　ウィンドウ
　　　　↑　　　　　　　　　　　　　　　↓
　　ゲームオブジェクト　←　ゲーム管理
という関係が成り立っている。
ウィンドウと入力と出力に分解すると、
　　ウィンドウ(in)→ゲーム管理→ゲームオブジェクト→DirectX→ウィンドウ(out)
となり、<入力>→<プログラム>→<出力>　という昔ながらのシンプルなモデルになる。

ところがここにオブジェクト指向の概念(データ構造でプログラムを分解する)を導入すると、
　　ウィンドウ→DirectX→ゲーム管理→ゲームオブジェクト
となり、前述のデータの流れ(処理の流れ)
　　ウィンドウ(in)→ゲーム管理→ゲームオブジェクト→DirectX→ウィンドウ(out)
と相反してくる。
この問題を解決するには、データ構造とデータの流れ(処理の流れ(制御構造))をそれぞれ別々に記述できる
C言語が最強ということになる。カプセル化なにそれ。

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

わけのわからない例題は読みたくないという人へ。
プログラムの三大要素は
・データ構造(struct、etc)
・制御構造(function、etc)
・定数(define、etc)
である。
それぞれ別のものだから、別々のところに別の方法で別々に作成するのがCスタイル。
一方、データ構造に合わせて制御構造と定数を分断し、すべてデータ構造に括り付けるのがC++スタイル。
当然、C++スタイルでは制御構造は制御的に意味のないところで分断される。
また、C++には制御構造をどこでも分断できるようにするためのナイフが用意されていて、それが仮想関数。
プログラマは仮想関数を使いデータ構造にしたがって制御構造を分解する。
晴れて本来一つのまとまった処理だったものがあちらこちらに散らばる。

**名前は開発中のものです。** · 2009/02/09(月) 16:43:55

>>340
わけがわからないから3行でまとめて。

**名前は開発中のものです。** · 2009/02/09(月) 16:47:46

>>341
今一度C++で何が起こったか考えるべき。
データ構造と制御構造と定数はそれぞれ別々のもの。
一つに纏めようとするのはナンセンス。

**名前は開発中のものです。** · 2009/02/09(月) 16:54:17

MVC
知らない奴は
サヨウナラ

**名前は開発中のものです。** · 2009/02/09(月) 17:06:06

MVCとか的外れもいいとこ

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

定数を分ける意味がわからん

**名前は開発中のものです。** · 2009/02/09(月) 17:11:46

>　　ウィンドウ→DirectX→ゲーム管理→ゲームオブジェクト
>となり、前述のデータの流れ(処理の流れ)
>　　ウィンドウ(in)→ゲーム管理→ゲームオブジェクト→DirectX→ウィンドウ(out)
>と相反してくる。

ミドルウェア（グローバル関数）→ゲーム管理（シーンクラス）→ゲームオブジェクト（クラス群）→ミドルウェア
こうならいいのかな。よく分からんけど。

**名前は開発中のものです。** · 2009/02/09(月) 17:23:48

>>345
C++とかだと、定数は、
class C
{
private:
　enum{ HOGE_MAX=10, PIYO_SIZE=100, };
public:
　enum{ ERR_MEM=1, };
};
とかするのが美徳とされている。

**名前は開発中のものです。** · 2009/02/09(月) 17:38:52

>>336
それは、プレイヤーや敵キャラのループはハードコーディングしかありえないって意味？
あるいはループとは違う仕組みとか。(タイマ割り込みとか)

>>339-340
それは単なるプログラミングスタイル(表現)の違い。
Cを始めとする手続き型言語を用いたプログラミングでは処理を始めから最後まで小説のように一本の線で書くことが得意。

それに対しC++やJavaを始めとするオブジェクト指向な言語によるプログラミングでは地図のように、オブジェクト間にはりめぐらされる道(ネットワーク)によってプログラムを表現しようとする。
だからソースを上から順番に読めば全体が理解できるとかいう話では無くなる。
C++で書かれたプログラムの全体を理解したいのであれば、クラス図(UML)でも書き起こすと良いと思うよ。
Doxygen対応のコメント書いておけば自動生成できるし。

**名前は開発中のものです。** · 2009/02/09(月) 17:45:46

>>346
　ゲームオブジェクト（クラス群）→ミドルウェア
の部分はどうなってるの？
1．ミドルウェアはグローバルであり、どこからでもアクセスできる。
2．ミドルウェアへのアクセサは処理の都度、引数でもらう。
3．ゲームオブジェクトはミドルウェアへのアクセサを内部に保持している。
　　(ゲーム管理クラス経由、など間接的な場合を含む)

**名前は開発中のものです。** · 2009/02/09(月) 17:51:54

>>349
１

**名前は開発中のものです。** · 2009/02/09(月) 18:07:00

で？
なんかごちゃごちゃ長いけど
タスクシステムが何の問題の何を解決するのかでたのかい？

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

>>348
>それに対しC++やJavaを始めとするオブジェクト指向な言語によるプログラミングでは地図のように、
>オブジェクト間にはりめぐらされる道(ネットワーク)によってプログラムを表現しようとする。

あなたは「オブジェクト指向では地図のように～～」と言うが、その理由までは考えないのか。
また、そういう性質はゲームに向いていると思う？
「地図のようにはりめぐらされるネットワークによってプログラムを表現」したい？
それに例えオブジェクト指向でも、地図のようにはりめぐらされるネットワークは決して歓迎されていない。

**名前は開発中のものです。** · 2009/02/09(月) 18:22:40

>>350
データ構造よりもデータの流れ(処理の流れ)
　　ミドルウェア（グローバル関数）→ゲーム管理（シーンクラス）→ゲームオブジェクト（クラス群）→ミドルウェア
を重視した設計だね。

**名前は開発中のものです。** · 2009/02/09(月) 18:51:16

次の新説
タスクシステムは実はフレームワークだったのだよ
なにー!?

**名前は開発中のものです。** · 2009/02/09(月) 18:53:31

>>338
＞まだ君の頭では理解できないことかもしれないけど

http://www.google.co.jp/search?hl=ja&q="ジョブ時間管理"
"ジョブ時間管理"との一致はありません

google様が聞いたことねーっつってるわけ。意味わかる？
お前はそんだけ奇特な用語をポコポコ発明してるわけよ
自覚ねーの？ワナビーだから？知ったかクンだから？巣篭もりしてっから？
とっとと部屋から出ろよバーカ

で、もしかしてお前、ジョブスケジューラとかジョブスケジューリングのことが言いたいの？
だったら何で

＞”MTフレームワーク”でググって勉強してみれば意味が分かるかもね…

何でMTフレームワークでググって勉強とかいう超絶的に頭悪そうなお話になるのかな？
ジョブスケジューラとかジョブスケジューリングってもっと汎用的な、OSの概念だよねぇ？
MTフレームワークのお勉強？低学歴ワナビーは紹介記事を読んだだけでお勉強になるの？
おめぇそんなんで何かを知っちゃった気になれるわけ？ワナビーが背伸び発言するには十分なの？

**名前は開発中のものです。** · 2009/02/09(月) 18:59:43

タスクシステムは何なの
イディオムなの?
デザインパターンなの？
フレームワークなの?
それとも、それらを超越した存在、神いわゆるGODなの?
それとも、新しいプログラミング言語のプロトタイプなの?
それとも、やっぱりただのうんこなの?
謎は深まるばかりだ

"working time management"
マイナーなつづりだな、きっと一部の選ばれしものだけが読める
論文かなんかで秘密裏に発表されているんだろう
俺ら凡人に対してそんな高度な言葉を使うなんて
普通に嫌な奴だな

**名前は開発中のものです。** · 2009/02/09(月) 20:37:24

>>275
mediatorやobserverがゲームプログラムの中に登場するというなら問題ない
タスクシステム（>>2）の中にmediatorやobserverがあるというなら知能障害確定だな

ねーよ。どこにも

前スレで>>2はオブサーバーだとか言って喚いてたバカに何度も何度も何度も
何で？何で？何で？何で？何で？何で？何で？何で？何で？何で？何で？
と質問責めにしたが、まともな返事は返ってこなかった

**名前は開発中のものです。** · 2009/02/09(月) 20:47:32

>>357
帰ってきてたじゃん
アレだろ？
更新タイミングはメッセージじゃね？
って返答だっただろ？
んでそうだよ→ちがうよ→そうだもん→ちがうもん・・・以下ループ
で終わったじゃん
俺は当事者じゃねぇけどｗ

**名前は開発中のものです。** · 2009/02/09(月) 21:03:37

ビデオゲームにおけるジョブ。ジョブを分解したタスク
タスクという内部の処理単位を扱う何らかのシステムであるわけだ
>>2はビデオゲームにおけるあらゆる処理を1/60[sec]で起床させる

何で？何で？何で？何で？何で？何で？何で？何で？何で？何で？
バカ？バカ？バカ？バカ？バカ？バカ？バカ？バカ？バカ？バカ？

ほれ。これに答えた奴は一人もいねーよ

**名前は開発中のものです。** · 2009/02/09(月) 21:18:37

機械語で組んでた頃のテクニックの代替手段なんて今はいくらでもあるんだから好きに作ればいいのに

**名前は開発中のものです。** · 2009/02/09(月) 21:25:02

だよねぇ

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

タスクシステムは、こびりついて流れないうんこみたいだ
すげぇむかつく
設計の本読んで初めてタスクシステム詐欺に騙されたと気づいたときには
無意味なクソコードを何ヶ月も書いていたあのいまいましい思い出と共に
うんこと一緒に流れてしまえ
いまだにタスクシステムを擁護している連中は
俺から見ると、やっと流したウンコを拾ってきてまたこびりつけるような奴だ
このクソいまいましい観念は俺が3Dを覚えるときにも邪魔しやがった
本当に俺の前に立ちふさがるうんこだった
このうんこは除去しなければならない

**名前は開発中のものです。** · 2009/02/09(月) 23:07:22

「オブジェクト指向(Object-Oriented)という言葉は私が作った。そのとき、C++ を想定していなかったことは確かだ」

**名前は開発中のものです。** · 2009/02/09(月) 23:24:44

>>287
＞そういうのやねうらおだけじゃなかったけどね
＞昔は多少わかりにくくても考えながら聞いてやったけど
＞いまって時代が変わったってのもあるよね
＞もう別に奴等の言うことをわざわざ理解してやる義理も必要もないし
＞情報が氾濫しすぎてて何かしゃべっても説明責任はてめぇの方にあんだよバーカ

説明責任かー。前スレでそれ絶叫してシカトされまくってたタスクバカがいたなぁ
自分に都合の良いウソを語る奴には説明責任を追及しないくせに
自分に都合の悪い事実を語る奴に説明責任を追及するタスクバカ

例えば、タスクバカにとってタスクシステム（>>2）ってのはゲーム業界固有の秘儀！至宝のテクニック！
であらねばならなかったわけなんだが、その根拠レスな確信を揺るがしかねない歴史的事実には
頑として抵抗して耳を塞いでたな。ほんとカルトってこえーわ

んで、「それはスレ違い！スレ違い！タスクステムと関係ないから関係ないから！」って一人で騒いでたね

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

>351
なんか今日は違う流れっぽい。

**名前は開発中のものです。** · 2009/02/09(月) 23:43:53

ウンチタスク厨（＝アンチタスク厨）に聞きたいんだけどさ、
>>2の代わりとなるわかりやすい原型を紹介してくんねーかな？
「普通に書く」っていうけど、その実態がよく分からんから、
普通の人に、鼻つまみモノ扱いされるんだと思うぞ。
タスクシステムについては、>>2で最も初歩的な原型が示されているわけだしさ。

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

コマンドをリストに突っ込んでるだろだろーが
それを万能のフレームワークのようにありがたがって無意味に誇張して
本質を語る邪魔をする、全て捨てろ、それは錬金術だ
今の体系的なパターンに含むことも出来ない過去の遺物だ
タスクシステムをありがたがっている奴は
設計の本なんて一冊も読んだことがないだろ、DSLすら知らないだろ
過去の栄光にすがっていると自覚しろ
わしの若いころはこうじゃった、だからお前もこうしろって
じじいかよ、性質の悪い爺かよ
役に立たない上に新しい観念を考えるときに邪魔にしかならない
最初に覚えるべきことじゃない、それは博物館に飾って置いておくだけのもので
実用するべきものじゃない
うんこー

**名前は開発中のものです。** · 2009/02/09(月) 23:58:59

while ( true )
{
　　　wait_vblank();

　　　自機.update( ... );
　　　foreach ( 敵 in 敵リスト )
　　　　　　敵.update( ... );
　　　foreach ( 弾 in 自弾リスト )
　　　　　　弾.update( ... );
　　　foreach ( 弾 in 敵弾リスト )
　　　　　　弾.update( ... );

　　　checkCollision_自機vs敵弾( 自機, 敵弾リスト );
　　　checkCollision_自機vs敵( 自機, 敵リスト );
　　　checkCollision_敵vs自弾( 敵リスト, 自弾リスト );
}

とかやっていくんじゃないの？
これでも出来ないことは無いよ。

**名前は開発中のものです。** · 2009/02/10(火) 00:11:36

>>368
その部分を汎用的にすることを止めれば
すなわちタスコシステムを使わないという選択肢を取れば
使える手が増える、増えるワカメぐらいに増える
それが様々なパターン、フレームワークの選択に繋がる
そこを汎用的にすることに執着することが、もっとも愚かしく
そして考えの浅さを露呈している箇所である
そこを隠しても大きなメリットはない
男の乳首と同じだ、わざわざ隠すような所ではない
お前らは乳首を隠してパンツはいてない
そういう間抜けなことを他人に強要しているのだよ
君たちはノーパン信者なんだよ
何も知らない奴に乳首を隠せノーパンに目覚めよと言っている
恐ろしいカルトなのだよ

**名前は開発中のものです。** · 2009/02/10(火) 00:12:45

>>367
否定的見解はよくわかった。
だがしかし、>>2に代わる初歩的原型は具体的に無いということだな。

>>368
それって実質タスクシステムじゃん。

**名前は開発中のものです。** · 2009/02/10(火) 00:13:38

>369
> それが様々なパターン、フレームワークの選択に繋がる

じゃ、タスクというパターンを選択してもいいんだ。
よかったな、お前ら>1-1000

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

>>370

いや、原型が>>368なんじゃね？もうベタベタまんまの原型なんじゃね？
で、>>368を↓という風に美しくまとめたのがウンコシステムじゃなかったっけ？

while ( true )
{
　　　wait_vblank();

　　　foreach ( ウンコ in ウンコリスト )
　　　　　　ウンコ.update( ... );
}

んで、↓みたいなのはウンコ同士のつっつきあいで表現するんだろ？
ウンコがウンコを生成したり消滅させたりしながら。

　　　checkCollision_自機vs敵弾( 自機, 敵弾リスト );
　　　checkCollision_自機vs敵( 自機, 敵リスト );
　　　checkCollision_敵vs自弾( 敵リスト, 自弾リスト );

違ったっけ？
違ったらスマン。

**名前は開発中のものです。** · 2009/02/10(火) 00:23:48

なんでリストを一つしか持たないって仮定してるんだろう？

**名前は開発中のものです。** · 2009/02/10(火) 00:25:21

>>370
>それって実質タスクシステムじゃん。
うん
実質は同じだ。データのやりとり。
違うのは可読性。
実質は同じ。
違うのは可読性。
実質は同じ。
違うのは可読性。

>>371
タスクはOK
マルチスレッドの単位もスレッドだし。

だがタスクシステム。てめーはダメだ！

**名前は開発中のものです。** · 2009/02/10(火) 00:37:44

class BaseTask
{
　　virtual void update( Context& );
};
typedef list< BaseTas* > TaskList;

class JikiTask : public BaseTask { ... };
class TekiTask : public BaseTask { ... };
typedef list< TekiTask* > TekiList;
class JidanTask : public BaseTask { ... };　　　　// 自弾全部管理してるタスクだと思えw
class TekidanTask : public BaseTask { ... };　　　// 敵弾全部管理してる(ry
====

TaskList tasks;
JikiTask jiki;
TekiTask teki[100くらい];
TekiList tekis;
JidanTask jidan( 100くらい );
TekidanTask tekidan( 弾幕系なので2000くらいw );

**名前は開発中のものです。** · 2009/02/10(火) 00:38:27

tekis.append( teki全部 );
tasks.append( jiki );
tasks.append( teki全部 );
tasks.append( jidan );
tasks.append( tekidan );

while ( true )
{
　　　wait_vblank();

　　　foreach ( タスク in tasks )
　　　　　　タスク.update( context );

　　　当たり判定( jiki, tekis, tekidan );
　　　当たり判定( jidan, tekis );
}

とかはイカンのか？

**名前は開発中のものです。** · 2009/02/10(火) 00:39:20

なんか
tasks.appen( teki全部 );
が一つ余計だな。

**名前は開発中のものです。** · 2009/02/10(火) 00:41:18

c = a + b;
これをタスクシステムに投入すると
list.add(a).add(b).add(new C(a, b)).execute();
c.execute() { value = a + b; }
こうなる

dという要素をこのリストに突っ込む場合
abcがdに干渉されないのであれば
d.execute()を適当に実装すればよい
干渉するのであればabcのexecuteを修正する
よって追加に強いというメリットはないと断言できる
コマンドのメリットである追加に強いというメリットはない
ないのだよ
これじゃあコマンドパターンの意味がないじゃないか
この屈辱、コマンドに対する屈辱
コマンドパターンがかわいそうだ
タスク信者はコマンドパターンに謝れ、あやまれよぅ

**名前は開発中のものです。** · 2009/02/10(火) 00:46:45

>>374
>>368は局部的な実装をちょこっとだけ厚化粧しただけ。
その程度の可読性有り難がってどうすんだよ。

必ずしも個々のオブジェクト（タスク）の発生と消滅のタイミングが整然としている、
例えば60フレームごとに、全タスクが一斉に発生・消滅してるわけじゃないじゃん。
つまり発生と消滅のタイミングが、微妙にずれていることにより、カオスが表現できる。
しかしカオスな状態を裏方で制御する努力は、>>2でも>>368でも変わりがない。

つまりさ、
現実を見ろ、
タスクシステムに立ち向かえ、
カオスを克服する運用ルールを見極めろ、
ってことだよ。

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

『可読性が悪い』って言ってるのは、『オレ頭悪いからワカンネぇしwww』って言ってるのと実質同義？

**名前は開発中のものです。** · 2009/02/10(火) 00:53:47

可読性を軽んじる香具師は職人オナニープログラマー

**名前は開発中のものです。** · 2009/02/10(火) 00:53:54

実質同じ？　いや、やっぱ同じじゃないと思うぞ。

主従関係があるとないとでは全然違う。
要素が要素に直接干渉し、要素がさらなる要素を生成消滅させるのと、
リストを扱う奴が要素同士の関係を管理して、要素を生成消滅させるの、
違うよな。

>>336がFAでいいと思うがな。
＞タイトル画面や戦闘シーンは、相互依存がほとんどなく、インスタンス数もたかが知れてる。また処理パターンが仕様変更で変わる可能性がある。

こういう部分で>>2を使うことには何の異論もない。
「相互依存がほとんどなく」ってのがポイント。
タスクシステムとかいう単語を見るとな、全部ウンコリストの中でやっつけようというイメージがあるんだが、ちゃうの？
ちゃんと使い分けしてるんならそれは否定しない。>>2は否定する。全部一緒だから。

**名前は開発中のものです。** · 2009/02/10(火) 00:56:22

あぁ、そういえば昔
仮想関数とか関数ポインタとか使うと
可読性が悪くなってデバッガで追えなくなるから
全部switch/caseで書けって言ってたプログラマが居たなぁ…

**名前は開発中のものです。** · 2009/02/10(火) 00:57:58

>>379
馬鹿じゃね。
>例えば60フレームごとに、全タスクが一斉に発生・消滅してるわけじゃないじゃん。
>つまり発生と消滅のタイミングが、微妙にずれていることにより、カオスが表現できる。
それのどこがカオスなの？寿命管理なんて、結局自クラスで閉じてるジャン。

そんなことより、例えば、宇宙に漂う星々を観賞するソフトをタスクシステムで作ることを考える。
星をタスクで実装したとして、各星の間に働いている万有引力はどう記述するの？

現実を見るのはお前だな。

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

>384
厳密にやるならワークをそれぞれ2つ持って、フレームごとにフリップだろ。
面倒だったら一つ一つ更新して、n+1がnを参照してもn+1を参照しても対して問題が無い様にするさ。
どこまで誤差を容認できるか知らんけど。

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

>>384
そーいうタスクの実行順序が結果に影響する場合は
実行時間単位でタスク状態のスナップショットを取って相互参照はそのスナップショットを参照、
という方法で擬似的に「いっせーのせ」をやる方法を物理演算系ライブラリでよくやってる。

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

>>373
＞>>2に代わる初歩的原型

初歩的原型？>>2が？どーこがだよ
なんだこれ。ジョブエントリのリストを周期的にナメナメしてバッチ処理するだけ
なんでこれがゲームプログラムの初歩的原型なんだよ。バカこくでねーよ

　・おめぇ、何か処理したかったら必ず先頭にTCB（は？）を入れたデータ構造にしろよ
　・おめぇが書いた処理はどんなものだろうと必ず1/60[sec]で周期的に呼び出すからな。覚悟しろよ
　・俺に呼び出された後はてめぇの責任で全部やりな。俺は何にもしらねーからな

こういうちゃんこ鍋ポーリングヘンテコプログラムをゲームプログラムの原型とかほざく理由を書け

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

で、何でか知らないが僕タスクシステム！って言って紹介してる糞は揃いも揃って
ユーザーのあらゆる処理単位のデータ構造にTCBとかいうものをねじ込んでるよな

　・サブルーチンアドレス
　・プライオリティ
　・連結リストのパラメータ

みんな仲良くなーぜかこういうものを押し付けてきやがる。なーんでなんで？どうして？
おまけにこれが日本ビデオゲーム業界黎明期の秘儀であるなどと権威付ける。正気か？
だったら何度だっていってやる。RAM4KBにROM数十KBにBGやOBJを出力する回路を
積んだZ80マイコンボードでこれ組んでみろよ。ほれ

そして、この仕組みをそのまんま

　・64bitマルチコアCPU
　・数GBのメインメモリ
　・ローカルメモリ数百MB搭載のGPU（DSP）カード

こういう環境上で律儀に真似しようとするのはなーんでなんで？どうして？

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

>387
> >>373
> ＞>>2に代わる初歩的原型
> 初歩的原型？>>2が？どーこがだよ

俺のレスに突っ込みかよw

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

>>387のはアンカーミスだ。>>370

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

>>385
>>386
それは論点が違う。書き方が悪かったかな・・・

>宇宙に漂う星々を観賞するソフトをタスクシステムで作ることを考える。
>星をタスクで実装したとして、各星の間に働いている万有引力はどう記述するか。

この問題の論点は、タスクシステムにおいて、タスク間にまたがる処理はどこに書くのか？。

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

>391
とりあえずこの問題に限定するけど、フリーの物理エンジンの実装見たことある？

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

>>388
>こういう環境上で律儀に真似しようとするのはなーんでなんで？どうして？
そのまま同じコードで実装して使ってるところは無いと思うけど。
特にC++が主流になった現場では。

まぁ、同じ考え方のシステムはスペックにあった実装されて使われてるけどね。
スペックに関係なくゲーム作るうえで処理のプライオリティ付きでゲームの状態遷移によって出し入れできるタスク管理は便利だから。
他にいい方法があれば淘汰されてるだろうけど、この考えのシステムを淘汰できるような物は今のところ無いみたいだしね。

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

>388
FPSなんかは、全部仮想関数でupdateを持つEntityクラスのサブクラスにしてたりするよ。

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

>>392
無いけど。

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

>395
答えが全部書いてあるから、見てみるといいよ。

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

>>396
逃げるなよ。絶対書いてないと断言できる。
今ここで示して見せてくれ。

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

位置と速度を分離して、万有引力は個々の更新で処理しない。

万有引力は距離関係ないけどまぁ有効距離を設定したとして、一つ一つの星にかかる引力を合計して
その星の質量から加速度と速度を計算する。
で、単位時間（多分1フレーム）あたりの移動量がでるから、それを位置に加算するだけ。

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

>>393
>>394
数値積分の（代表的な、最小の）タイムステップとして例えばリフレッシュレートを選択し
そのタイムステップで可視属性のエンティティの処理を周期的に呼ぶというのは問題ない

アニメーション処理など、表示系の処理はリフレッシュレートに同期させないと美しくないからだ
>>2が腐ってるのは「あらゆる処理をちゃんこ鍋リストに入れてリフレッシュレートを基準に
周期的にバッチ処理して起床させる」というトンチンカンプログラムだから

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

>>398
>一つ一つの星にかかる引力を合計して
どこで合計するの？誰が合計するの？星タスクの中でやるの？
結局、タスクシステムの外で計算するしかないんじゃないの？

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

>>394
例えばFPSのエンジン。これのエンティティのMODを作る人間がユーザーとしよう
エンジンは内部ではBSPなりPVSで空間領域分割しているがMODの開発者は
そんなこたしらねーわけ

可視範囲内にいる脅威のデータをくれっていえばエンジンはくれるわけ
例えば視界のコーン（or視錐台）を渡して、最近傍のバカのデータをよこしてくれる
俺が使ったのはそういうエンジンだった

敵AIを作る奴の目的はレベル内の敵性物体の掃討であり、それを適切に連携しながら
行なうことだ。

タスクシステムってのは

脅威の情報くれ　⇒　エンティティのちゃんこ鍋リストあげるからテメェで探せバーカ

こういうもの

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

>>399
画面のリフレッシュレートは特にウィンドウモードの場合まちまちだから、
ゲームロジックのFPSと描画のFPSが別々になることがある。
例えば、ゲームロジック60FPS、描画72FPSとか。
この辺のギャップを滑らかに埋める仕組みを作るのは結構面倒。
俺の自作描画エンジンはそれを勝手に面倒見てくれるように作ってる。
それすら実装されてないのにタスクシステムとか言われても・・・ねぇ。

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

＞エンティティのちゃんこ鍋リストあげるから

あ、これですらないわ。全処理のちゃんこ鍋リストだわ。ははーは

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

>>402
＞画面のリフレッシュレートは特にウィンドウモードの場合まちまちだから、

YES。フルスクリーンであろうと指定したリフレッシュレートにしてくれない
ポンコツビデオカードがまかり通ってた時代もあるしな

＞ゲームロジックのFPSと描画のFPSが別々になることがある。

YES。そのとおり。そしてリフレッシュレートが既知であろうとなかろうと
AIを作る奴にイベント駆動システムを提供することだってある
これはゲームエンジンが階層型スケジューラをサポートしている

**名前は開発中のものです。** · 2009/02/10(火) 02:05:40

>>399
>「あらゆる処理をちゃんこ鍋リストに入れてリフレッシュレートを基準に周期的にバッチ処理して起床させる」
これ、FPS単位では無いけどタイムシェアリングのOSのスレッド管理と同じような考え方だね。
タスクシステムもスリープ状態とか、スレッドのようなフラグ付けして使うのはよくある実装。

独立した時間軸のある処理を複数持ちたい、となるとスレッドなりタスクシステム的なものが必要になるわけで。
で、ゲームの場合はオブジェクト毎にスレッド立てるなんてのはパフォーマンス的に無駄なのでもっと簡素なシステムを使ってると、
そんな感じじゃないのかな。

別にそんなトンチンカンでは無いと思うけど。
タスクシステムで出来ることを全て網羅していてもっとスマートな方法があるならそれを使えばいいんだろうけど…
今まで見たことあるのは結局タスクシステム＋αしたようなタスク拡張システムで、パラダイムの違うのは見たこと無いなぁ…

**名前は開発中のものです。** · 2009/02/10(火) 02:18:31

>>405
やねちゃんなの？

**名前は開発中のものです。** · 2009/02/10(火) 02:26:24

＞ゲームの場合はオブジェクト毎にスレッド立てるなんてのはパフォーマンス的に
＞無駄なのでもっと簡素なシステムを使ってると、そんな感じじゃないのかな

ん。違うな。やねちゃんではないな
協調的マルチタスクシステムがタスクシステム的だとか言わんよな。彼なら
眠気を我慢してる状態でごにょごにょ長文を読むとみんなやねに見えるから困る
寝る

**名前は開発中のものです。** · 2009/02/10(火) 03:11:04

やねちゃんは、にちゃんなんか歯牙にもかけないでしょJK

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

>>405
＞これ、FPS単位では無いけどタイムシェアリングのOSのスレッド管理と同じような考え方だね。
＞タスクシステムもスリープ状態とか、スレッドのようなフラグ付けして使うのはよくある実装。

FPS単位とかよくわかんないけどさ
オラが村の自慢の生娘のウンコ（タスクシステム）に似てるとかドーデモイーわけ
所詮はローカル用語。お前さんの自慢のタスクシステムなんて誰も興味ねーし
お前さんが自慢のウンコを職場内でタスクシステムと呼んでようがドーデモイーわけ

俺がバーカバーカって言ってるのは公衆の前でタスクシステムとして布教されている>>2
そして>>2を超すごいオーパーツだとか可搬性と再利用性に優れたミラクル秘儀だとか
祭り上げてる（いた）バカ共
あと、定義不明瞭なオラが村のローカル用語（タスクシステム）を引っ張り出して擁護するイナカッペ
誰もてめぇのひりだしたウンコの名前の良し悪しの話なんてしてねーから安心しろ

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

>>405
＞独立した時間軸のある処理を複数持ちたい、となるとスレッドなりタスクシステム的なものが必要になるわけで。

いやだからそのタスクシステム的ってナニ？意味わかんねーのよ
なんでそういうオラが村のローカル用語を駆使するの？自覚ある？ない？
まずお前のいうそのタスクシステムってやつを説明してくれないと
ホント意味わかんねーから

＞で、ゲームの場合はオブジェクト毎にスレッド立てるなんてのはパフォーマンス的に
＞無駄なのでもっと簡素なシステムを使ってると、そんな感じじゃないのかな。

もうチンプンカンプンだよ
お前さんは一体ナニが作りたいの？協調的マルチタスクシステムが作りたいの？
だったら何でそれが>>2になっちゃうの？コンテキストスイッチはどこ？目的と実装は一致してるの？
何度も言うけど、一体ナニが作りたいの？ゲーム作りたいんじゃなかったの？目的変わった？

**名前は開発中のものです。** · 2009/02/10(火) 06:12:33

>>405
＞別にそんなトンチンカンでは無いと思うけど。

ちゃんこ鍋リストに全てをぶち込んでバッチ処理がしたいんであれば>>2はトンチンカンじゃないな
ちゃんこじゃなくてウンコ鍋だったっけ

＞タスクシステムで出来ることを全て網羅していてもっとスマートな方法があるならそれを使えばいいんだろうけど…

網羅する必要？どこにあるの？ねーよ？まず、ゲームは
ちゃんこ鍋リストに全てをぶち込んでバッチ処理する必要ねーから
でもお前はある。しかもタスクシステムが出来ることが他にもあるという。
網羅できないと駄目だと。じゃあこれについて語ってくれないか？

お前のタスクシステムで出来ることを全て網羅的に説明してくれ
逐一、それが>>2である必要がないことをみんなが説明できるぞ

＞今まで見たことあるのは結局タスクシステム＋αしたようなタスク拡張システムで、パラダイムの違うのは見たこと無いなぁ…

たしかに>>2は強烈なウンコパラダイムだな。ウンコパラダイムシフトってのは巻き糞なのかな？

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

あーん出勤の時間だ。ばいばい！

**名前は開発中のものです。** · 2009/02/10(火) 06:27:18

>>411
>ちゃんこ鍋リストに全てをぶち込んでバッチ処理する必要ねーから
まったくその通りだなｗ

**名前は開発中のものです。** · 2009/02/10(火) 07:11:22

>400
だから『個々の更新で処理しない』って書いてるでしょ？
中じゃなかったら外でやるしか無いじゃん。

>401
そこまで判ってるなら言うこと無いよ。
実行巡回リスト以外に、必要な各種コンテナを追加すればいいだけ。
だいたいその存在目的が違うのに、なんで『ごった煮リスト』からEntityの検索をしないといけないんだ？

> 脅威の情報くれ　⇒　エンティティのちゃんこ鍋リストあげるからテメェで探せバーカ

オマエの邪推だろ。
実行巡回リスト以外に管理しているものがあるとか想像できない、その貧しい発想がダメだな。

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

>>2について採決を取ろうか。
話がぶれすぎ。

ウンコ信者は>>2をよく見て、それに含まれていないものを勝手に追加したり「想像しろ」とか言わないように。
>>2について決着がついたら、更なる進化系ウンコを提示してもらおう。

あと、質問には単純明快に答えてほしいな。
「どこで？」と聞かれたら「ここで」と答えよう。
「他のソース見たことある？」とか「フリーのソース見ればわかる」とか「こう計算する」とか「中ではない（だから外だ。でもどこかは言明しない）」ではなく、
明確にどこかを示してほしいもんだ。

**名前は開発中のものです。** · 2009/02/10(火) 19:16:53

対話は無理じゃないのか
タスカーの目的は保守だから逃げたり煙に巻くことだけを考えている
だからごまかせればそれでいい、逆に揚げ足取りを狙うだけ
自分からサンドバッグになるほどバカじゃないだろう

**名前は開発中のものです。** · 2009/02/10(火) 19:22:31

やねうらおの人生みたいだな

**名前は開発中のものです。** · 2009/02/10(火) 19:35:00

>>2 のいくつかについて
使い方だけが記述してある
使う理由や、使うことで得られるもの等は書かれていない

3Dではレンタゲ絡むから単純にコマンドリストにしてソートして描画は無理
一つをレンダリングした後にそれを加工して他に適応するような
複雑な手順が必要となるから、ほぼ間違いなく複雑になる

これを見てくれ、何かが色々とおかしい
>長所は次の通りです。
> * ジャンルを問わず様々なゲームに適用できる
> * 並列処理をうまい具合に実現できる
> * ゲームの流れを自然な形で表現できる
> * 大規模なゲームも開発できる
> * タスクごとに独立しているため、複数人で開発できる
無理やりメリットを列挙した感が伝わってくるよ

**名前は開発中のものです。** · 2009/02/10(火) 19:48:28

俺の主観

> * ジャンルを問わず様々なゲームに適用できる
ジャンルごとに最適な作り方を模索しようぜ
木造一戸建ての家と鉄筋コンクリートのビルを同じ手法で作らなくてもいいじゃないか

> * 並列処理をうまい具合に実現できる
そのうち、インテルが優秀なコンパイラを作って解決してくれるようになるさ
GPUの並列処理では使えない、全く役に立たない

> * ゲームの流れを自然な形で表現できる
自然な流れといったら、俺にとってはDSL、内部でも外部でもいいけど
DSL的アプローチとしてはHSPをそのまま使った方が比較できないほど有益

> * 大規模なゲームも開発できる
使わなくても出来るだろう
"大規模なゲームを簡単に開発できる"と書かないあたり良心的

> * タスクごとに独立しているため、複数人で開発できる
クラスで見かけ上分離しても、データのやり取りで
相互依存関係が存在しているので独立しているとは断定できない
近い箇所でわざわざ分けずに、サブシステムで担当分けろ

**名前は開発中のものです。** · 2009/02/10(火) 19:55:43

タスクは少しでも処理を稼ぎたい時くらいしか使わないな。
あと、クラスとタスクを勘違いしてる奴が多いな。