タスクシステム総合スレ 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/15(日) 14:43:31

アンチタスク派に一つ聞きたいんだが、例えば自機選択式のSTGがあったとして、機体それぞれの
jikiについての関数は当然別々に書くんだよな？　違うの？

**名前は開発中のものです。** · 2009/02/15(日) 14:55:33

>>695
今後ゲーム開発はスクリプト使う方向に行くだろうし、
それ自体は賛成だけど

タスクシステムの上にスクリプトが乗っかるのか、スクリプトの上にタスクシステムを構築するのか、って感じで
スクリプト自体はタスクシステムの有無とはまた違う話だよね。

間接的にデータ駆動でコード中の複雑性が減ってタスクシステムでもコード見通しがよくなるね、という程度の話なのかな？

まぁネイティブコードの量は減るから見通しは良くなりそうだけど、スクリプトの分量が増えると
ネイティブコードと中間コードの二系統をメンテする手間で結局あまり変わらない気もする…

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

>>696
処理よっては別になるかもわからんねぇ
敵のパーツを奪って武器・装甲を強化するタイプの自機と
経験値蓄積型のパワーアップをするタイプの自機ぐらいの違いがあると
もうプログラム自体共通部分を探すほうが難しいぐらいになるかもしれんし
まあ、仕様によるかな？
何が来てもいいように別にしておくのがいいな
もし、共通部分があったとしてもたかが数箇所（自機分）でしょ？

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

>>697
スクリプトだけでタスクは乗らないです。
どっちも載せたりすると直感的に分かりづらくなる。
フレーム間をまたぐ処理の場合は、コルーチン(いわゆる協調スレッド、ファイバー、マイクロスレッド)を使います。

>まぁネイティブコードの量は減るから見通しは良くなりそうだけど、スクリプトの分量が増えると
>ネイティブコードと中間コードの二系統をメンテする手間で結局あまり変わらない気もする…
これは同意です。1人で実装するとなると2倍手間になりそうですが、そこは明確な作業分担でできるってことで。
スクリプトのメンテはスクリプトの動的ロードを実装すれば、プログラム実行中でも即座に反映されるようになるから便利ですぜ

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

アンチです。

>>696
ごめん。よくわからない多分自分の理解力不足だけれど
タスクでもそうでなくても、jikiを別々には書かないかと。
タスクにした場合と壮でない場合で、その点に違いが出るの？

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

>>699
>フレーム間をまたぐ処理の場合は、コルーチン(いわゆる協調スレッド、ファイバー、マイクロスレッド)を使います。
オブジェクトの粒度をどの単位にするかにもよるけど
例えば敵の弾一個一個につき協調スレッド、ファイバー、マイクロスレッド、のどれかの生成、破壊を繰り返すの？
そりゃパフォーマンス的に厳しいんでないかなぁ…
協調スレッド、ファイバー、マイクロスレッドのどれも普通のスレッドに比べればかなり軽いけど
タスクシステムの関数コール同等の負荷とは比べ物にならないぐらい重いし。

まぁ、十年後のPC環境なら全然問題ないレベルの負荷かもしれんが。

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

>698
じゃ、自機が変更されると言う仕様を実装すると、それぞれの機体別jikiをswitch～caseで
分岐して呼び分けるわけ？

>700
じゃ、jikiの内部で、機体によって処理をswitch～caseで分岐するわけ？

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

>>701
コルーチンはスクリプト言語が実装してくれてるから、スクリプト内で使うんです。
(LuaやSquirrelがスクリプトの実行順に関して、協調型のスレッドをスタック型で内部実装してくれている)
コルーチンの生成にはちょっとコストが掛かるので、一度作ったら再利用して呼び出すことで無駄をなくしますね。
パフォーマンス的に厳しいデメリットに関しては、ネイティブ側で対応します。
(例えばSquirrelはC++のクラスをオブジェクトとして持つことも出来ます)

**名前は開発中のものです。** · 2009/02/15(日) 15:24:03

>703
スクリプト上のコルーチンの中から呼んでるC/C++関数の中でyieldしたい場合は？

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

話はすれ違ってるが設計は多分同じだ。

　擁護派　：本来スクリプト言語を適用すべき箇所に絞ってタスクシステムの導入可否の話をしている
　アンチ派：本来ネイティブ言語を適用すべき箇所に絞ってタスクシステムの導入可否の話をしている

どちらもスクリプト言語を適用すべき箇所まで >>641 で組むとは考えてないだろうし、
どちらもネイティブ言語を適用すべき箇所までスクリプト化すべきとは考えてないだろう。

多分論点はここかな
論点１：「ゲームエンジン部分＝ネイティブ言語の相互作用記述＋スクリプト言語解釈部」は意見一致してるよね？
論点２：「個々のスクリプト→個々のタスク」というのも性能UPが必要ならありでは？

アンチはネイティブ言語を全廃してスクリプト言語に置き換えるべきとは言ってないと思うし、
擁護派はネイティブ言語の相互作用記述を分解してタスクに置き換えるべきとは言ってないと思う。

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

>>702
まだ理解し切れていないのだけれど、
普通に継承使っては駄目ですか？

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

>>702
どう変更されるかによるなぁ・・・
例えば、自機Ａが後方に下がるシーンと自機Ｂが変わりに前方に出てくるシーンなんか入る日には
もうインスタンス２ついるわけだし操作がユーザにあるって点以外はすべてが別処理じゃね？

ペカっと光ってチェーンジ！でよくてもやっぱり変更が怖いから完全に別にオブジェクトだな・・・俺なら

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

>>703
スクリプト内で対応しているコルーチンならコンテキストスイッチとか無いからパフォーマンスは大丈夫かもね。
でもそうなるとスクリプト管理オブジェ同士の依存関係が有る場合、状態取得とかで同期処理が必要になるが…

**名前は開発中のものです。** · 2009/02/15(日) 15:31:07

>706
いや、別にそれでいいけど、このスレに約一名C++ワカランチンが常駐してるから、最底辺にあわせて
判りやすいレベルで話した方がいいかと思って。

じゃ、共通部分をtemplateにしてvariantsをfactoryから作るようにして対応するんだ。
常道だよね、やっぱり。

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

C++わからんとか、510のプログラム読めんとかは、ゲームなんか悠長に作ってる場合じゃねぇだろ。

はじめてのCでも猫でもわかるでも読んで出直してくるべきじゃね？

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

>>704
こうやって実装できなくないけど、実装しない方が良いと思う
http://www.chiark.greenend.org.uk/~sgtatham/coroutines.html
速度が必要でC++で実装しつつ、関数を途中で止めて戻す場面ってのがあまり思いつかないし、
スクリプト側でcoroできれば十分かと。
なので、スクリプトからC/C++関数へはサブルーチンのみと縛るべきかな。
もし必要になればそのときに考えます。

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

>>709
そんなことして共通部分が共通でなくなっちゃったら大変だぜ

俺は継承はやらないほうがいい派
メンバで持つ派

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

>712
そんなのは結局、どこまでをまとめて一つのクラスにするかの問題だから、瑣末なことだよ。
作ったものを修正せずに済むとか思ってるほうが間違いだ。たとえメンバにしたとしても、
それを分離修正する必要があれば同じこと。

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

>>709
あ、すまん継承って軽く書いてしまったけれど、
自分も>>712と同じく、コンポジションとかいうの派

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

>>708
そこが一番のネックですね。
スレッドは協調型のみですので普通のスレッドのような並列処理に関しては、
同期処理が保障されていないです。
(基本はシングルスレッドのみで実装しているので試してみたことがない)
並列可能なスクリプト言語は今後の課題ですね

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

>>713
上の修正が末代まで来るのがやだから、集約使うのではないの？

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

集約のメリットは、その部分を丸ごと交換できること。
修正の手間はさほど変わらないよ。とくに機能を分離する場合はね。

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

>>715
あれ？
>フレーム間をまたぐ処理の場合は、コルーチン(いわゆる協調スレッド、ファイバー、マイクロスレッド)を使います。
ってことはフレームをまたぐオブジェクトが複数ある場合は必然的に
並列処理が必要になるんだよね？

>並列可能なスクリプト言語は今後の課題ですね
となってしまうとその方法（コルーチン）では使い物にならないんじゃない？

結局、スクリプト使ったゲームで一部データ駆動されてるものも
オブジェクト単位ではタスクシステムなりに乗っかってスクリプトのupdate部分がオブジェクト数分定期的に呼ばれる
という実装なんじゃないかな。

でないとマルチスレッドの複雑性の問題をスクリプトが抱え込むことになるような…

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

実際の話、C/C++のcoroutine使うにしてもスクリプトのcoroutine使うにしても、それが中断してる最中に
内部の状態変更要求を外から通知された場合、どう処理するかが問題。

実行途中のcoroutineを強制的に終了したとしても大丈夫かどうか。

**名前は開発中のものです。** · 2009/02/15(日) 15:55:33

>>715は現状ではシングルスレッド＆コルーチンを使っているんじゃないの
マルチプロセッサでのネイティブスレッドとは違って並列処理にはならないので
同期制御の類は要らないはず
時分割された処理の継続をあからさまにFSMのような形で実装するのと
違って、自然に書けるのがコルーチンの利点で、プログラムカウンタや
スタックのリストアを処理系がやってくれる

>>715が「課題」と言っているのは、マルチコアでのパフォーマンスが求められる
ようになった場合にどうするか、という類の話では

**名前は開発中のものです。** · 2009/02/15(日) 16:00:34

遅レスだが、

>>699
＞コルーチン(いわゆる協調スレッド、ファイバー、マイクロスレッド)
ってのは結局・・・

//万里ゆうじ氏が著書で紹介していたタスクシステムを参考
struct Task
{
//(1) データ更新・描画処理用関数ポインタ
void (*Update_n_Draw)(Task*);

//(2) データ記録用バッファ。場合によってはメンバ変数に分解して固定。
char WorkBuf[WOKK_BUF_SZ];

//以下省略
：　　　　 //タスク・チェーン結合用ポインタ
};

上のタスクシステムで言うところの、
１．Task構造体の生成・破棄
２．（１）の関数の切り替え
３．（２）のメンバ変数への分解
の処理パターンを、ある程度、限定・抽象化して、スクリプト駆動でルーチン化してるだけなんじゃね、実質？
コルーチンの生成・フレーム間維持・破棄のために、結局バックグラウンドで、タスクシステムが必要でしょ。
データのまとまりって言うのは、結局構造体だ。

**名前は開発中のものです。** · 2009/02/15(日) 16:03:52

全然違うよw

**名前は開発中のものです。** · 2009/02/15(日) 16:03:59

>>718
>>720で合ってます。
現在の組み込みスクリプト言語はシングルスレッド仕様で、
マルチスレッド化やマルチコアの恩恵は受諾できないと思います。

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

>>723
そーなると結局
コルーチン同士のリソース同期処理はどうなったの？

これはスクリプトの仮想マシンがシングルスレッドかマルチスレッドか、というのとは
別の話なのだが。

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

>>722
詳しく

**名前は開発中のものです。** · 2009/02/15(日) 16:19:47

コルーチン同士のリソース同期処理？？
同期処理はLuaやSquirrelの仕事ですね。こちらが意識する必要はないです。
そもそも走っているスクリプト解釈スレッドは1つだけです。

複数のコルーチンをつくり、中断／再開を行うことで擬似マルチスレッドっぽいことはできますが、あくまで擬似です……。

あくまでコルーチンはコードの見晴らしの為だけに使います。(使うのも使わないのもスクリプト実装者の裁量による)

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

>725
> ２．（１）の関数の切り替え
のあたりが違う。

＞コルーチン(いわゆる協調スレッド、ファイバー、マイクロスレッド)
でFSM的なものを書くのは、関数ポインタなりswitch～case使うなりするよりも面倒な時がままある。
特に外から状態が変更されるような場合は。

普通に、外から影響を受けないsequentialな処理を途中でyieldさせつつ、しかも並列に実行したい
場合には効果ある。

だから使う対象をよく観察すること。

**名前は開発中のものです。** · 2009/02/15(日) 16:36:18

>>727
つまり相互影響処理の無いタスクってことだろ。
関数の切り替えは、スクリプトで駆動されたタスク種類によって切り替えるという意味。

**名前は開発中のものです。** · 2009/02/15(日) 16:44:48

>728
関数ポインタは、FSM的な状態変数の代替という意味ではない、と言うこと？

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

>>729
さっきの例ではそう考えていた。

ところで、FSMっていうのは、例えば、
弱気→（攻撃を受ける）→好戦的→（さらに叩かれる）→発狂→・・・
みたいなタスクの状態メンバ変数の仕様がネットワーク化した場合に、
状態切り替え処理の複雑化を吸収するパターンだろ。

**名前は開発中のものです。** · 2009/02/15(日) 16:59:21

>>730みたいな本質的な状態遷移は素直に状態遷移として書くのがよいでしょう
コルーチンで楽になるのは、継続を実現するために
FSMを使わなければならないようなケースではないかと

Xをやって→nフレーム寝て→Yをやる
みたいなのを、ある関数（コルーチン）の中に
単に三つの文を繋げて記述できるか
FSMとして書かなければならないかの違いは大きい

**名前は開発中のものです。** · 2009/02/15(日) 17:30:58

で？なんかタスクシステムと関係あるの？

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

フレーム間をまたぐような連続した処理を書きたいときはコルーチンという手もあるよって事だよ
コルーチンを使うのは、タスクでもいいし、非タスクでも良い
それにより見通しの良いコードが書ける　ってだけ

自分は以前はタスク派だったのが、スクリプトとコルーチンを扱うことで、
アンチタスク派になりました。
(タスクが絶対必要ってわけじゃなく、無くてもコードが書けるよね。
タスクシステムでも別にいいけどさ、正直読みづらくねぇ？　という意見)

**名前は開発中のものです。** · 2009/02/15(日) 18:42:32

DSLはスクリプトと同義じゃないよ
DSLで紹介されている言語はDSLに近いということ
DSLは理想言語、直感的に書ける言語、又はツール、簡単に手早く書ける言語
コストの問題でDSLに近いスクリプトがよく利用されているという
つまり、DSLについて考えるということは
出来る限り簡単に、出来る限り速く書くことを考えるということ
よくわからないけどそういうこと

**名前は開発中のものです。** · 2009/02/15(日) 18:58:38

DSLは難しい。スクリプト≠DSLであり、スクリプト≒DSLなんだよね。
すまんが実装例が無い現状ではDSLは良く分からない。
しかし、ゲームプログラマが考える範疇ではないことは理解できた。

**名前は開発中のものです。** · 2009/02/15(日) 19:03:00

問題は結婚にも似てるよね。
1．箱入り娘派。全部親が取り持つ。当人同士は直接接点を持たない。完全カプセル化。
2．お見合い派。仲介屋が縁を取り持つ。以降は当人同士の問題。半カプセル化。
3．恋愛結婚派。自分たちで勝手にやってよ。アンチカプセル化。

**名前は開発中のものです。** · 2009/02/15(日) 19:14:30

出来ちゃった婚派と不倫泥沼略奪婚派が無いな。

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

>>735
//敵のアルゴリズム定義
//aは動くで、bは止まる。
#define ZAKO_ALGORITHM_DSL "abaaababaaaabababaaab"
#define BOSS_ALGORITHM_DSL = "aaaaaaaaaabababaaaba";

～～～

teki *zako = new teki(ZAKO_ALGORITHM_DSL);
teki *boss = new teki(BOSS_ALGORITHM_DSL);

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

みるからにタスクシステム関係ないな

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

まぁ要するに所謂データは全部DSLってことだよ。
文字列にしろPCMにしろmp3にしろjpgにしろ実行バイナリにしろ。

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

>>738
説明してもらってすまんｗ
思ってたのとさらに違って、よりわけ分からんくなった
データ主導設計をさらに超えて、アルゴリズムやAIもデータ主導で記述しろってことかな？
全てDSLで渡したとして、どこかでDSLを解釈しなくてはならない箇所ができるから、そこのコストがゲームではネックになってるってこと？

**名前は開発中のものです。** · 2009/02/15(日) 19:36:49

あのごちゃごちゃしたC++のタスクシステムを作る能力があるんだったら
HSPで高い完成度を目指して作った方が速いし完成度も高いのが作れるDSL的に考えて
熟練した職人がのこぎりとプライドを捨てて、チェーンソーを使えば
ものすごい出力を得られるだろう
C++は実用的な言語ではなくて、亀仙人の甲羅だと思っている
脱ぎ捨てたときに初めてその真価を発揮する

**名前は開発中のものです。** · 2009/02/15(日) 19:39:36

正規表現や埋め込みSQLも一種のDSLと捉えられるようだから
>>738はDSLと言っていいんじゃないのかな

正直DSLの適用範囲は非常に広いように思う

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

タスク信者完全に論破されもんだから
ＤＳＬとかいう新ワード使ってスレを流そうと必死な奴がいるなｗ

**名前は開発中のものです。** · 2009/02/15(日) 19:43:40

DSLは問題領域を限定して、その領域の問題を解決するために理想を追求する
弾幕の軌道という問題を解決する手は数多にある

そのままコードを書く
マクロで書く
スクリプトで書く
ドローソフトで軌跡を描く
弾幕ツールを作って出力する
自動軌跡生成プログラムを作って出力する

考えられる限りの手段の中から、コストを考慮して、最適なものを選択する
難しいものをできるだけ簡単に書ければ
大量のリソースをできるだけ簡単に作ることができるなら
その問題領域をDSLとして書く意味が大きくなる

**名前は開発中のものです。** · 2009/02/15(日) 19:43:44

>>742
> C++は実用的な言語ではなくて、亀仙人の甲羅だと思っている
> 脱ぎ捨てたときに初めてその真価を発揮する

ああ、それはマジでそれは実感するわ・・

俺、C++を10数年やってんだけど、たいていの他の言語がプーだな。

他の言語、ちょろ甘すぎる。

**名前は開発中のものです。** · 2009/02/15(日) 19:44:51

>>742
HSPではDSL用のコンパイラを書きにくい。
HSPでやり始めると、言語としてHSPしか使えない。

**名前は開発中のものです。** · 2009/02/15(日) 19:50:53

>>642
> これでブラックホールとか自機とかさらに複数の要素が加わったら全部の要素を
> このwhile内にハードコードで追加して巨大化していくのかな？
ふつーに書く場合、まずゲーム全体を

1) ゲーム全体で利用する、比較的低レベル（システム寄り）の内容
例：非同期ファイル I/O 管理とか、デバイス管理など

2) 独立性が高く、ユーザから見た「実行中の内容」を反映する単位
例：タイトル、デバッグメニュー、ミニゲーム
「シーン」とか、ウチの社内だと「タスク」と呼ばれてる

3) シーンを構成する個々の要素
例：プレイヤー、体力ゲージ、エフェクト

と 3 レベルに分けて考える。

メインループは 1 の処理と、状態に応じてどれか特定のシーンの更新処理を
呼び出す。更新処理の結果、シーンの遷移が必要になるかもしれないので、
それはシーンから戻り値か何かで取れるようにしておく。

コードはこんな感じ。

**名前は開発中のものです。** · 2009/02/15(日) 19:51:14

void Game::MainLoop() {
　// 1) の処理実行
　AsyncFileIO::GetInstance().Update();
　Pad::GetInsstance().Update();
　// 状態に応じてシーン実行
　switch (scene_) {
　case SCENE_INIT:
　　title_.reset(Title::Create());
　　scene_ = SCENE_TITLE:
　　break;
　case SCENE_TITLE:
　　switch (title_.Update()) {
　　case TITLE_DEMO_BEGIN:
　　　　title_.reset();
　　　　demo_.reset(Demo::Create());
　　case TITLE_GAME_START:
　　　　if (title->GetGameMode() == GAMEMODE_SINGLE_PLAYER) {
　　　　}

　　// 以下略

　}

**名前は開発中のものです。** · 2009/02/15(日) 20:00:55

シーンは、シーンを構成する各要素のコンポジションになる。

SceneDemo::Update() {
　player_.Update(*this);
　for_each(enemies.begin(), enemies.end(), boost::bind(&Enemy::Update, ::_1, boost::ref(*this));
　// ヒット判定など
}

ヒット判定など、シーン更新時に必要になる処理は

1) シンプルならシーンの Update() 関数に直接書く (player_.Update() とかね)
2) ちょっと複雑になってきたら、Scene のプライベートメンバ関数に分割
3) もっと複雑なら、別クラスを用意して、そっちに処理を分ける

とする。3 の例としては、たとえば敵とプレイヤーのヒット判定を行う (総当りではなく
BSP とか使って) ような処理が考えられる。そうすると、SceneDemo はこんな感じ。

class SceneDemo {
　Player player_;
　std::list<Enemy*> enemies_;
　HitManager hitmgr_;

　void AddEnemy(const EnemyCreateInfo& info) {
　　　Enemy* enemy_ = Enemy::Create(info);
　　　enemies.push_back(enemy);
　　　hitmgr_.add(enemy);
　}
public:
　void Update();
};

**名前は開発中のものです。** · 2009/02/15(日) 20:05:32

自分も>>748の書き方で必要十分だと思う。支持しますわ

**名前は開発中のものです。** · 2009/02/15(日) 20:06:11

>>696
1) ぜんぜんベツモノなら別クラスにして、シーン側からもまったく別扱い

2) 外から見た振る舞いは同じ (public メンバ関数は同じ) だが中身がぜんぜん違うなら
純粋仮想関数を定義した共通の基底クラスを用意して、それを継承して作る。シーン側からは
基底クラスを介してしか見ない。

3) 中身もほとんど同じでパラメタぐらいの違いから、単一のクラス。パラメタ部分だけスクリプトか
設定ファイルに切り出す

**名前は開発中のものです。** · 2009/02/15(日) 22:35:44

>>748
当たり判定クラスは、その中の1)に入るのかな。

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

>>738
それは>>643によれば外部DSLだよな
内部DSLを使うべきだと言っていた人とは別人か？

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

SAFE_RELEASEマクロとかが内部DSLだね。DSLって便利だね！！

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

うわｗ　確かにそうだけど
それだと怪しいマクロまみれの>>510も内部DSLだしｗ
おれイヤだよ２１世紀にもなってそんなパラダイムｗ

DSLは資料読む限り現実路線に見えるんだけど、
アランケイ教の頃のOOPと同じでなんか信者がうさんくさいｗ

**名前は開発中のものです。** · 2009/02/16(月) 07:27:13

さて、今週はタスク信者をどうボコボコにしてやろうか

**名前は開発中のものです。** · 2009/02/16(月) 07:41:29

今回も新ワード出して定義論争に持っていこうとしているがそれが通用したのは前時代まで
今は説明できなきゃただの詐欺師
新ワード出てきても論争なれてないやつは触るなよ
こういう無駄な勝負は何もにちゃんだけじゃねーぞ
会社でもそういう霞ヶ関風味の腐った人間ってのはたくさんいる
ちゃんとしたメルヘンブレイカーにまかせないと負けるぞ
ではこのスレの主旨をもう一度

で？タスクシステムのメリットって何？

**名前は開発中のものです。** · 2009/02/16(月) 08:27:22

>>748
乙。

もう750超えたのか。誰かpart1-4をまとめてくれないかな。
また次スレで不毛なループが発生するのが面倒だ。
>>510や>>641、その他の住人が書いてくれたコードも残しておきたい。

俺はやらんが、誰かやってくれ。

**名前は開発中のものです。** · 2009/02/16(月) 13:08:53

タスクって分岐を関数アドレス指定にすることで処理を稼ぐテクニックのことじゃないの？

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

>>760
処理を稼ぐって何だよ。実行バイナリの容量削減？処理速度の向上？
どっちにしろ現代のPCでは全くの無駄な努力どころかむしろ余計なお世話だけどな

**名前は開発中のものです。** · 2009/02/16(月) 15:37:10

関数アドレスのLUTを使うことで条件分岐を高速化できるに違いない
こういう固定観念に縛られたオールドタイプが若者をカルトへ誘う

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

おじいちゃん「私たちが20台の頃はね、たった1つのswitch文をケチる時代だったんじゃよ」

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

ボトルネックじゃないところで頑張っても誤差の範囲。
つーか、switch文でテーブルジャンプ利かせるほうが関数ポインタより速いと思うが。

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

だからもうタスクシステムなんて誰も使ってねーよ

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

駄目だな
十年は次スレが立たないぐらい
タスク信者ども、ボコボコにしてやろ

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

俺主観での今までのまとめ

Q.タスクシステムのメリットとデメリットを教えてください
A.ハハン、自分で考えろ

Q.タスクシステムの代わりがないだろ、文句言うなら代わりをよこせ
A.コルーチン、DSL、各種フレームワーク
Q.あーあー見えない聞こえなーい

タスクシステムとは、ジョブコンを無駄にいじって
何がなんだかよくわからなくなったものではないかという説

タスクシステムは3Dの描画についてはまったく使い物にならないようだ

全角英数使うなこのバカやろう

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

>>760
＞処理を稼ぎたい

君は>>420かな？
>>2はジョブエントリのリストを舐めて、関数アドレスを使って処理を次々にディスパッチしていく仕組み
つまりバッチ処理の仕組みでしかないわけだが、この仕組みをどのような処理群に適用しているのか
教えてほしい

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

検索してメリットを探したけど
サイトごとに違っているから困る
全部を信じるならば、万能フレームワークという結論になった
弱点なんてないぜ、トレードオフなんて知ったことじゃないぜ
銀の弾丸を見つけたよ

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

タスクシステムって車で言うと、MT車に当たると思うんだ。
MT車は車の運転を楽しみたい人、スポーツ感を味わいたい人用のもの。
同じように、タスクシステムもプログラミングを楽しみたい人、スポーツ感を味わいたい人用のものだとおもう。
初心者用MT操作説明サイトが有っても良いように、>>2みたいな初心者用タスクシステム説明サイトが有っても良いと思う。
それに対して文句を言うのは、
今日日F1でもパドルシフトなのにMTってなにか意味あるの？とか、
家やホテルがあるのにわざわざキャンプするのってなにか意味あるの？とか、
ロープーウェイがあるのに登山するのってなにか意味あるの？とか、
買ったほうが安いのになんでDIYするの？とか、
言ってるのと同じで、何も分かってないのに分かったふりしたがる、大人ぶりたい子供のすること。
タスクシステムは大人のスポーツなんだから、ガキがごちゃごちゃいうなよ。

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

>HSPではDSL用のコンパイラを書きにくい。
>HSPでやり始めると、言語としてHSPしか使えない。
外部的にはその通りで
内部的にはDSLをHSPのコードに変換するという手がある
プリプロセッサ的な解決方法、マクロと言うのだろうか

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

乞食は食べることに必死だから、食えるときに食わないのはバカだという、
一方人間様は食べることに必死じゃないから、平気でダイエットしたりもする。
もう、立場がそれぐらい違うわけ。
多くの人にとってプログラミングってのは、単に趣味や遊びでしかなく、
数独やジグソーパズルと同じ感覚。
むしろそんな低俗なことで飯食ってる人が居るのが信じられない、何でそんなに必死なのかも分からない。
プロ野球選手が草野球をやってる人をつべこべ批判してたら、それって痛いだろ。
そういうこと。言われたほうは内心では「野球しか出来ないくせに」と思ってる。

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

>>770
残念だがタスクシステムは燃費最悪のダンボールカー。トラバントみたいなものだ
工作精度の低い2stエンジンで環境に全く優しくなく、煙モーモーあげる癖にスピード全く出ない
しかし走行音が激しいため、物凄く頑張ってくれてるような錯覚を覚える
手作り感抜群で品質は不安定。製造年月日が新しければ新しいほど品質が悪くなる
大半は車体強度不足で安全基準を全く満たしていない。事故るとよく燃える

あらゆる点がタスクシステムと符合している。「通」気取りにしかオススメできないゴミだ

現代社会でタスクシステムを使うというのは、現代社会でトラバントを使うようなものだ
公衆の前でタスクシステム凄いと叫ぶのは、高速の追越車線をトラバントで走る俺凄い！と同じだ

レトロ趣味の変態オヤジの愛車ノロケ話に付き合うと大渋滞が発生する

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

縁日に屋台でワイワイ射的をやってたら、
知らない猟師のおじちゃんが、撃ち方にケチをつけてきた。
そんな構図。

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

例えば、タスクシステムとやらで弾幕3DSTGの全OBJの1タイムステップ分の時間発展を計算するとしよう

…⇔[ザコ敵A]⇔[通常弾]⇔[閃光(粒子)]⇔[通常弾]⇔[通常弾]⇔[閃光(粒子)]⇔[ザコ敵B]⇔…

あるタイムステップではこういうちゃんこ鍋循環リストをペロペロシコシコナメナメすることになるね
何故このちゃんこリストはOBJの種類別でソートされてないのかって？そりゃ3Dゲーだからさ

>>2のちゃんこリストはOBJの種類でソートされてるように見えるが実は深度ソートなんだね
そもそもスプライト機ではOBJの重ね合わせがOAM内での並び順によって決定されていた
典型的なちゃんこリストはOAM内の属性配列にpush_backする順序でソートされた
典型的な2DSTGでは重ね順（深度）＝OBJの種類だった、というわけだね

さて、上のちゃんこの並び順でいくと、ザコ敵Aの処理が終わったら次は通常弾だ
　　サブルーチンアドレスを使って処理を呼び、『Δtの等速直線移動を計算』し、処理を返した
通常弾の処理が終わったら次は閃光だ。これもほぼ同様の手続きで処理
閃光の処理が終わったら次は通常弾だ。これもほぼ同様の手続きで処理

こうなるわけ
『Δtの等速直線移動を計算』。たったこれだけの処理をするために>>2の仕組みを使う。WHY？
これが処理速度を稼ぐための行為だというなら、鎖国中の独裁国家のファンタジーみたいなものだ

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

>>774
HSPer（俺）が縁日に屋台でワイワイ射的をやってたら、
自称猟師のおじちゃん（＝タスクシステマー）が現れ、撃ち方にケチを付けてきた
そんな構図

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

>>773
>工作精度の低い2stエンジンで環境に全く優しくなく、煙モーモーあげる癖にスピード全く出ない
>しかし走行音が激しいため、物凄く頑張ってくれてるような錯覚を覚える
>手作り感抜群で品質は不安定。

要するにDIYってことだろ。
日曜大工のなにが悪い。手作りでなにがわるい。あくまで趣味なわけ。
本職ではちゃんと社会のお役に立ってる。
むしろゲームなんて役にたたないのだから好き勝手で良いだろ。
ダンボールカーで公道を走るわけではない、庭を走るだけだ。

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

あえて合理的でないタスクシステムを使うことによって、
余裕を見せ付けていると言ってもいい。
秋の紅葉を写生しながら楽しむ。写真で良くね？じゃない。もう時間の使い方が全然違うわけ。
まさに貧乏暇なし。

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

好みの問題ってレベルじゃないからここでデバッグ／アンチウィルス作業してるんだ。
信者の洗脳を解こうと頑張ってるんだよ。
本職でこれをやられると時間と金の無駄だから非常に迷惑。
日本経済が傾いてる時に、こんなアホなことを現場でやられたんじゃ困る。

本職じゃないならいいよ。

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

>758
ハナから理解する気の無いバカに説明する暇人も、そう残ってないだろ。

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

>>510と>>641を見比べて自分が何をやっていたのか
早く気づいてほしいもんだな
タスク信者は

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

>本職でこれをやられると時間と金の無駄だから非常に迷惑。
>日本経済が傾いてる時に、こんなアホなことを現場でやられたんじゃ困る。

本職の人は困るだろうね。本職以外の人にとっては、
金儲けしなければならない立場であるにもかかわらず、
タスクシステムなんて使っちゃうような低脳の集まりの業界の未来なんて
知ったこっちゃないしな。まさに滅ぶべくして滅んでるだけだし。
そもそも、ゲームなんて社会の役にたたないんだから、そんなもので飯食おうと思うほうがどうかしてる。
社会の役にたたないってことは、それは趣味ってことだ。普通ならそう考える。たとえそこに市場があったとしてもな。

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

>775
> あるタイムステップではこういうちゃんこ鍋循環リストをペロペロシコシコナメナメすることになるね
相変わらずリスト一つで管理してるつもりになってる構ってチャンかw

> 典型的な2DSTGでは重ね順（深度）＝OBJの種類だった、というわけだね
うわぁ…w

> 『Δtの等速直線移動を計算』。たったこれだけの処理
うわぁ…www

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

>>777
歴史と記憶の捏造が始まった？

タスクシステムを褒め称えてきた自称プロ達の行ないを矮小化＆無毒化＆美化しちゃダメだよ
2003年以降、>>2はプロのスーパーテクとか言って本気で広めてた自称プロ、沢山いたね？
自分に都合の悪いことを全部無かったことにしちゃねー

HSPerは配列厨なんだけど、タスクシステマーに「プギャー。知らないの？」されたことあるよ
それまでフリゲや同人でちょこちょこ出してきたけど、こういう日曜大工にタスクシステム（>>2）
なんて使った試しない。マジこのオッサン死ねばいいのにって思った。リア厨だから仕方ないね

ちょっと前のコミケで売った弾幕STGはタスクシステマーが見たら怒り狂うような簡素なコードだったよ

**名前は開発中のものです。** · 2009/02/16(月) 22:34:31

>>783
具体的な反論ヨロー

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

>>778
君、タスクシステム派にとって物凄く迷惑な、無能な味方なんじゃない？
なんで趣味でしか通用しない玩具ですって認めちゃうの？
アンチじゃないの君？

**名前は開発中のものです。** · 2009/02/16(月) 22:50:48

ID:Bs7zALYvってもしかして
リアル金持ちはリボを使う。リボはリアル金持ちのステータス。一括払いを使う奴は貧乏人
とかいう超理論を展開していた某板の住人さんかしら？

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

>タスクシステムを褒め称えてきた自称プロ達の行ないを矮小化＆無毒化＆美化しちゃダメだよ
>2003年以降、>>2はプロのスーパーテクとか言って本気で広めてた自称プロ、沢山いたね？
>自分に都合の悪いことを全部無かったことにしちゃね

その自称プロはよっぽどの低脳なんだから放っておけばよい。
「プロのスーパーテク」なんてのは、厨を釣るための餌だよ。
プロとかスーパーとかテクとか、針みえすぎ。
なんちゃらProって名前のついてる商品が一杯あるだろ。あれと一緒だよ。
実際にはプロはあんなもの使わない。

>コミケで売った弾幕STGは
売り物にタスクシステムを使わないのは当たり前。

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

>>788
針じゃないよ。何なら過去ログ、Cマガのタスクシステム特集記事でも読めばいいよ
自分だけはまともな、良識的なタスク派だとか言ったって信じないよ
ギャラクシアン起源の由緒正しいプロテクです、使わないとカッコワルイ！とか叫んで
広めるような毒虫共に利用されるイタタタシステムなら、悪いけど名前ごと抹殺されたほうが世のため

厨房的にはそういう発想に至る。汚物は消毒したいお年頃だから仕方ないね

さて、あえて合理的でないリボ払いを使うことによって、
（金利払いをする）余裕を見せ付けていると言ってもいい。
秋の紅葉を写生しながら楽しむ。写真で良くね？じゃない。もう時間の使い方が全然違うわけ。
まさに貧乏暇なし。
yahoo知恵袋
http://etail.chiebukuro.yahoo.co.jp/qa/question_detail/q113605506
リアル金持ちだからできる、余裕の金利払いだそうです。ID:Bs7zALYvと馬が合いそうだね

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

>785
自分の間違いに、本気で全然気づいてないのか？

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

>>790
間違いだと言い切れる根拠をお願いします

まさか、あなたは究極の狭義の正しいタスクシステムをご存知の方ですか？
ぜひご教示ください。私の認識はきっと間違っているのでしょう

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

>>789
「プロのスーパーテク」なんて言葉が釣りじゃなきゃ一体なんだって言うんだろう。
この世に真顔でこんな言葉使うやつがいるとでも？
ライターに騙されたやつは本気だっただろうけどな。
ライターってのは読者の精神年齢に合わせて記事書くからな。

あとさ、リボ払いの件だけど、なに言ってるのか意味が分からない。
無駄なことに金をつかうのは単に成金趣味なだけ。
無駄なことに時間をつかうのが余裕のある人。
ただし、利害関係が出てくると仕事モードになって目の色が変わるが。

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

>791
その変り身、キモイw

煽っといて今更何言っちゃってんのwww

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

>>792
何きみ？誰を擁護してんの？ありえなくね？何故タスクシステムの名誉に固執するの？
誰かを演じてるの？松浦乙とか言ってほしいの？だったらコテ付ければ？
HSPerの厨房の俺でもアンタが何を守ろうとしてるのか全く分からない

利害関係が出てきたから仕事モードになって目の色が変わってるんじゃない？
でないとタスクシステムを必死に庇おうとするアンタの行動は理解できない

俺の行動原理は簡単。厨房だから。配列最高。タスクシステムなんてゴミ
こんな無様（>>2）なものが未だに持てはやされてるのは見るに耐えない
ガソリンぶっかけて信者も道連れにして全部燃やして墓標でも立てとけばいい
それがタスクシステムへのせめてもの供養になるだろう

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

>毒虫共に利用されるイタタタシステムなら、悪いけど名前ごと抹殺されたほうが世のため
う～ん、基本的にずれてるんだよなぁ。
そもそも、ゲーム自体が「抹殺されたほうが世のため」なわけで。
そういう、どうでもよい役にたたないものを暇つぶしで作るんだから、
タスクシステムはむしろ最適ともいえる。