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

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

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

part8 http://pc11.2ch.net/test/read.cgi/gamedev/1250678891/
part7 http://pc11.2ch.net/test/read.cgi/gamedev/1241670786/
part6 http://pc11.2ch.net/test/read.cgi/gamedev/1238725539/
part5 http://pc11.2ch.net/test/read.cgi/gamedev/1234977661/
part4 http://pc11.2ch.net/test/read.cgi/gamedev/1233459490/
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/

・タスクと呼ばれる実装は、非常に多岐に渡ります
　古典タスクシステムについての話題は「>>2」と明示してください
　そうでない場合はカスタム版であることを明示してください

・人を憎んで言語を憎まず

**名前は開発中のものです。** · 2009/12/30(水) 21:44:27

タスクシステムを(アカデミックな方向に)発展させていくと、

gotoタスク：　引数で指定した番号のタスクにジャンプする。
ifタスク：　タスクの評価が非0の時、引数で指定した番号のタスクにジャンプする。

とかになるぞ。変だろ。

**名前は開発中のものです。** · 2009/12/30(水) 21:55:31

C言語には、プログラムを上から順番に実行していくというタスクシステム的な仕組み以外にも、
if文があったり関数に引数が指定できたり、型があったりと、
目いっぱい便利な仕組みが用意されているのに、
なんでわざわざバーチャルマシンもどきのタスクシステムを自分で実装しようとするんだ？
そんなことするから、C言語に元から用意されていた、
構造化制御とか型とか関数の引数などの便利な機能が使えなくなるんだろ。

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

技術的に低すぎる馬鹿みたいな例をあえて出して
釣ろうって手段かね。
釣りだとしてもいまいち・・・

**名前は開発中のものです。** · 2009/12/30(水) 23:03:38

タスクシステム自体がバカみたいな例そのものだとおもうが。
既存のものを使わずに自作して周囲からの恩恵を受けられなくなるという。
そういう趣味性を否定するわけではないが。

**名前は開発中のものです。** · 2009/12/30(水) 23:17:16

タスクシステムって、基本は動的関数呼び出しがキモで、それって、
OSに対するアプリとか、
ブラウザに対するプラグインとか、
ウィンドウマネージャに対するウィンドウとか、
そういった、後から拡張を要する場合に利用される手法なんだよ。
単一アプリのゲームの開発に持ち出すのはナンセンス。
増築の手法で一戸建てを立てるようなものだね。
ディアゴスティーニじゃないんだから。

**名前は開発中のものです。** · 2009/12/30(水) 23:46:59

>>47
ネタにマジレスだが
関数ポインタもＣ言語に元から用意された便利な機能だろ？
タスクシステムの実装っていかにもＣ言語的（というかthe spirit of C）なんだが。良くも悪くも。
古典的タスクシステムなんて古きよきUNIX時代のC言語のコードを見てる気分になる。
これこそCのプログラムって感じ。
「プログラマを信頼する」というＣの精神と同じ思想で
信頼されたプログラマ、つまりタスク仕様上の「落とし穴」を正しく理解したプログラマであれば
その穴に陥らずにプログラムを書けるはずである、といういかにもな精神。

ネタじゃないなら、HSPとか使う方が君には合ってる気がする。

**名前は開発中のものです。** · 2009/12/31(木) 00:48:41

>>51
関数ポインタ⊂タスクシステム

**名前は開発中のものです。** · 2009/12/31(木) 10:05:26

>>47に>>51と返す奴の理解力が心配だなｗ

**名前は開発中のものです。** · 2009/12/31(木) 13:56:13

ネタにマジレスしてくれる優しい人なんでしょｗｗ
引数君のレベルが低すぎて話が噛み合ってないが

**名前は開発中のものです。** · 2009/12/31(木) 14:48:06

>>45
> というか、普通にかけばいいじゃん。
それはお前にとっての普通だろｗ

一般のＣプログラマにとっては関数ポインタ使った方法もＣ言語の
言語仕様で想定された"普通"の方法の一つなんだけど。

お前にとっては「そんなの使ったら僕理解できない！型とか関数の引数などの
便利な機能が"僕には"使えなくなる（涙）」ってだけｗ

その程度で「ＯＳでも作るのか？バーチャルマシンでも作るのか？」って涙目ｗ

**名前は開発中のものです。** · 2009/12/31(木) 17:00:50

>>55
頭の弱いものいじめ、カコワルイｗｗ

**名前は開発中のものです。** · 2009/12/31(木) 18:52:03

抽象化はメリットがなければじゃまなだけ。
メリットが明確じゃないから使わないんだろ。
メリット感じてるやつだけが使えばいいんだよ。

**名前は開発中のものです。** · 2009/12/31(木) 19:06:43

「タスクシステムでゲームを作る」って言うよりは、
「有限状態機械を組み合わせてゲームを作りたいけど、
　使用する言語にコルーチンのような機構が無いから、
　同じような物を自前で実装するためにタスクシステムを使用する」
っていうのがタスクシステムを使う本来の動機だと思う

**名前は開発中のものです。** · 2009/12/31(木) 19:28:41

正直最初に実装した人は少なくともそんな小難しく考えてないだろう。
・俺がメモリを管理する！がしたい
・状態(データ)と処理(動作)を一まとめに出来たら直感的
・それらの一まとめを個別に自由に追加・削除したい。

以上の要求にC言語で応えようとすると、リスト構造を純粋に作るか、
>>2で示すような(リスト+配列)/2のような構造がぱっと思いつくのでは?

**名前は開発中のものです。** · 2009/12/31(木) 19:38:27

>>57
つ >>43
それもう結論出てるから。

今はメリット・デメリットの比較までたどりつけない子がイジメられてるだけｗｗ

**名前は開発中のものです。** · 2009/12/31(木) 19:48:27

でも誰も語れない不思議

**名前は開発中のものです。** · 2009/12/31(木) 19:53:57

FSMとコルーチンってなんか特別な関係があるの？
コルーチンって状態遷移に対してメリット思いつかないんだが

**名前は開発中のものです。** · 2009/12/31(木) 20:43:02

>>61
でも誰も"僕の理解できることを"語れない不思議

>>62
コルーチンをサポートする言語のVMをFSMとして見るなら、コルーチンの単位を一つの状態として見れるかもね。
そもそも用語の次元が違う話だけど。

**名前は開発中のものです。** · 2009/12/31(木) 21:44:09

それでも語らない不思議

**名前は開発中のものです。** · 2010/01/01(金) 00:33:49

>>59
その動機ならalloc系をラッピングしたほうが自然では？

**名前は開発中のものです。** · 2010/01/01(金) 03:30:24

>>55
>一般のＣプログラマにとっては関数ポインタ使った方法もＣ言語の
>言語仕様で想定された"普通"の方法の一つなんだけど。

関数ポインタ？使えば良いんじゃね？
タスクシステムが糞といってるだけで、関数ポインタが悪いとは言ってないんだが。

タスクシステムのまずい点は、言語レベルで初めから持っているはずの、
「プログラムは上から順番に実行される」を自前で実装しちゃってる点。
考えてもみろよ。結婚式のプログラムだろうが運動会のプログラムだろうが、
プログラムと名のつくものは大概順番に実行されていくものだろ。
コンピュータだって機械語レベルでそうなってるし、C言語以下の低級言語ですら、それぐらいの機能は持ってる。
それを何で今更自前で用意する必要がある？
そんなの独自にやろうとするから、C言語既存の、
「引数受け渡し」や「型」や「構造化制御」との親和性が低くなる。

なんでも言語標準の機能を使えとは言わないが、
あまりにも基本的な部分を覆すのはどうかと。

**名前は開発中のものです。** · 2010/01/01(金) 03:49:11

もちろん、実行順序を動的に制御したい場合もあるだろうけど、
そういう汚い部分は、個々のモジュール内に閉じ込めて、表に撒き散らさないようにした方が賢いと思うが。
Zソートを例に挙げると、それは描画エンジン内でこっそり行えばよい話で、
タスクシステムみたいに変に統合しちゃって、猫も杓子もそれつかえってのは無茶。

**名前は開発中のものです。** · 2010/01/01(金) 04:12:13

>>62
>FSMとコルーチンってなんか特別な関係があるの？
>コルーチンって状態遷移に対してメリット思いつかないんだが

これも良く引っかかる罠なんだが、
コルーチンはスタックフレームの状態が保存できるから
スタックフレーム上のプログラムカウンタを状態とみなすことで状態変数をなくすことが出来る。
しかしそれは状態が独立している場合のみに有効で、
状態と状態が連携をとる場合は、状態変数は消せない。

例）
if( stateA && stateB ){}
else if( !stateA && stateB ){}
else if( stateA && !stateB ){}
else{}

FSMの中身が上記のようになる場合は、コルーチンを使っても状態変数は消せない。
つまり、あんま意味無い。

状態変数の数だけコルーチンは必要なんだけど、状態と状態が連携をとる場合、
各コルーチン同士で状態のやり取りをする必要が出てきて、結局状態変数を復活せざるを得ないってこと。

**名前は開発中のものです。** · 2010/01/01(金) 04:27:38

では、状態が独立している場合にはコルーチンが有効かというと、実はそうでもない。
なんでかっていうと、状態が独立しているのなら、初めからプログラムはそんなに複雑にはならないから、
ベタで書いても大したこと無いから。

同期の粒度が大きければコルーチンは便利かもしれないけど、
一フレーム毎に同期を取るゲームでは無用かな。

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

古典タスクシステムの

メリット：

多数のFSMを逐次実行するための一手段になる

簡単な古典TS（>>2の「最も基本的なTCBの構造」だけで済むTS）ならコードはシンプル

MVCのMとCが分離されているため、タスクシステム（C）を実装すれば、
後は動的に実行される関数（M）の実装に専念できる

デメリット：

逐次実行するFSMの数が少ないならわざわざ使う必要が無い

各TCBのワーク領域割当に苦労する
ワーク領域を動的確保にする場合はガベージコレクトの問題が出る

簡単な古典TSには、TCB間の情報・イベント伝達や、親子関係を持たせる機能などが無い
これらを実装しようとすると、気持ち悪いコードになる可能性が高い
（TCBの逐次実行がウリなのに実行順序を無視したり、グローバル変数にアクセスしたり）
設計・実装にプログラマの良し悪しが出る

TCBから呼ぶ関数内でMVCのMとVを分離せず書くと、今時のプログラミングでは混乱しやすい
（特に、直接API（DirectX等）や、APIが比較的剥き出しになっているラッパーライブラリを使う場合）

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

>>70
> 簡単な古典TSには、TCB間の情報・イベント伝達や、親子関係を持たせる機能などが無い
> これらを実装しようとすると、気持ち悪いコードになる可能性が高い
今時のタスクシステムにしろUnreal EngineとかのActorにしろ、今時のゲームエンジン系で
イベント伝達や親子関係とかをサポートしてないものを探すほうが難しいな。
つまり実際に製品規模のゲームを作るうえでは必須な機能だ。

ゲームロジック部分は嫌でも土臭くなる部分が出てくるし、これはタスクとかActor
を使わなければ綺麗に書ける、というものでもない。

「いや、俺はそんなもの使わずに製品規模のゲーム作る方法知ってるよ」って天才がいるのなら
CEDECなりGDCなりで発表すればきっと世界中のゲームプログラマから賞賛受けるよ。

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

>>70
逐次実行がタスクシステムの売りっていわれても、そもそもプログラムは基本全部逐次実行だ。
ますますfor(;;){ task1(); task2(); task3(); }で問題ないな。

>>71
それらはゲームエンジンという制約からくるものだ。

ゲームのメインロジックは泥臭くなるというが、それはゲームエンジンを使おうとするから。
ゲームなんて、入力→状態更新→描画　を永遠と繰り返すだけなわけで、
普通に書けばそんなに泥臭くならない。
WindowsアプリがWindowsの仕様にあわせるために窓周りが泥臭くなるのと同じ理由で、
ゲームエンジンでゲーム作ると泥臭くなる。
増築の手法で一戸建て立てようとしているのだから当たり前。

**名前は開発中のものです。** · 2010/01/01(金) 09:50:21

>>72
>ゲームのメインロジックは泥臭くなるというが、それはゲームエンジンを使おうとするから。
>ゲームなんて、入力→状態更新→描画　を永遠と繰り返すだけなわけで、
>普通に書けばそんなに泥臭くならない。
UEエンジンやFarCryエンジン、タスクシステム使ってる時代遅れの開発者達に
「ゲームエンジンなんて使わずに普通に書け」と教えてあげなきゃ！
世界中のゲーム開発者が気づかなかったことを気づくなんて天才だね。
・・・紙一重にはかなわんｗｗ

**名前は開発中のものです。** · 2010/01/01(金) 10:00:29

今時ゲームなんて作ってる奴はもとより時代遅れなのかもしれないよ？

あーあと、親子関係とかは(何の親子関係かは知らんが)実装しても良いと思うよ。必要ならね。
それをタスクやactorに結びつけるのは糞の極みだが。

**名前は開発中のものです。** · 2010/01/01(金) 10:21:15

>>74
>今時ゲームなんて作ってる奴はもとより時代遅れなのかもしれないよ？
ゲーム製作技術なんて時代遅れの板では天才様のレベルには合わないようですよ？ｗｗｗ

**名前は開発中のものです。** · 2010/01/01(金) 10:31:24

ID:7lwJSlZL、そんなに怖がるなよｗ
ID:4JKBI3JGは少なからず理屈で出てるんだから、
お前が逃げると、見てるほうとしては物足りないぞ。
もっと頭を使わないと立派な大人になれないぞ。

**名前は開発中のものです。** · 2010/01/01(金) 11:00:53

>>2の構造ならポインタインクリ、デクリできるからじゃね？
あとなんかヒープ領域をリアルタイムでこまめに確保するのってなんかCっぽくないと思えるように最近なってきた。不思議。

77 · 2010/01/01(金) 11:01:41

安価忘れ。>>65へ

**名前は開発中のものです。** · 2010/01/01(金) 11:17:47

>>76
みえみえ・・・

**名前は開発中のものです。** · 2010/01/01(金) 15:18:56

イベントドリブンとgotoの違いがわかりません

**名前は開発中のものです。** · 2010/01/01(金) 16:25:03

>>76
>>71-75の流れ見ればID:4JKBI3JGの完敗にしか見えんが
ゲームエンジン否定して毎作エンジン自作しろってか？正気とは思えん。
ID:4JKBI3JGが勝ってるように見える人間の理屈を教えて欲しい。まじで。

**名前は開発中のものです。** · 2010/01/01(金) 16:33:22

なぜタスクシステムをゲームエンジンと読み替えるの？

**名前は開発中のものです。** · 2010/01/01(金) 16:36:10

>>82
>>72で本人が言ってるけど。

**名前は開発中のものです。** · 2010/01/02(土) 01:19:18

ゲームエンジン(タスクシステム含む)なんて糞ですよ。
ゲーム用ライブラリ、これで十分。
でも俺もゲーム用ライブラリ作って商売しろって言われたら、
マーケティングの都合上、そりゃゲームエンジン(フレームワークみたいな奴)
にするけどな。使い勝手とかじゃなく、身の保身のためにな。

ゲームのメインループは各モジュールに制御を分配する、いわば心臓みたいなもんで、
そんなもんを安々他人や他社に明け渡す気にはなれん。
裏を返せば、他人の心臓は握りたいってことだが。
そりゃあ、誰だって甘い汁すいてぇよなぁ。

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

あーだから、UEエンジンとかも、ライブラリ的に気軽に利用できる部分はどんどん使えばよいと思うよ。
ただ、actorとかマジで要らないよね。
なんていうか、トラップにすら思える。

**名前は開発中のものです。** · 2010/01/02(土) 01:41:11

>ゲームエンジン否定して毎作エンジン自作しろってか？正気とは思えん。

だから、なんでゲームエンジンが必要なんだ？
ゲームエンジンが無きゃゲームが作れないのか？
ゲームの種類は千差万別でやらせたいこともまちまちなのに、
汎用なゲームエンジン作ったってしょうがないだろ。てか出来ないだろ。
なんですぐそう統合したがるのかが分からん。
個々の機能ごとに、たとえば、
描画エンジンとか当たり判定エンジンとか、そう言う単位で用意すりゃいいだろ。

**名前は開発中のものです。** · 2010/01/04(月) 19:31:30

タスクシステムの利点は、ゲームプログラミングの学習の段階で
ゲーム中のオブジェクトを抽象化する練習が出来ることだと思う
ゲーム中のイベントやキャラクター、エフェクトを
どのようにオブジェクトに分割して実装するか、とか考える練習になると思う

まあ、同等の事が出来るなら、特に今ではタスクシステムである必要はないけど

**名前は開発中のものです。** · 2010/01/04(月) 19:44:33

今のゲームプログラマって抽象化ができないんだよね

**名前は開発中のものです。** · 2010/01/05(火) 03:55:23

しかし、抽象化に限界を感じるのも事実かも。特に汎化。
車輪の再発明はするなとか、再利用性とか・・・。

**名前は開発中のものです。** · 2010/01/05(火) 10:58:16

10年以上タスクを使ってたおれが、いま非タスクでゲームを実装してるよー！
正直どっちでもいいよとおもった。

**名前は開発中のものです。** · 2010/01/05(火) 12:01:30

たしかにどちらでも動作するので
プレイする側からしたらどうでもいい話
しかし、抽象化のできないマと話をするのは嫌

**名前は開発中のものです。** · 2010/01/05(火) 14:17:47

タスクシステムはともかくゲームエンジンまで不要と言い出したのか。
昔のタスクスレでＯＯＰ不要とかクラス不要と言ってた人と同一人物っぽいな。

**名前は開発中のものです。** · 2010/01/05(火) 15:46:08

タスクシステムもオブジェクト指向も、抽象化して複雑さを管理するための
メタファーでしかないんだけどな。

自分ひとりで作れるぐらい単純なレベルなら抽象化もしない方が見通しいいかもしれない。
プログラマ２～３人ぐらいの小さなプロジェクトでも無くても作ることはできるだろう。

次世代機の開発者数百人ってレベルで「普通に作れ」って何も基底システム用意しないのはさすがにありえんけど。

**名前は開発中のものです。** · 2010/01/06(水) 03:10:22

タスクシステムが制御構造のいったい何を抽象化するというのだろう。
俺からしたら、いわゆるif文とかで普通に制御する構造化制御のよりも、
抽象度が落ちているようにしか思えないのだが。
ノイマン型コンピュータの逐次実行性を抽象化するもの→VM　ってこと？

**名前は開発中のものです。** · 2010/01/06(水) 11:26:48

ifで制御とか、超具象的じゃね？

**名前は開発中のものです。** · 2010/01/06(水) 14:23:59

TCBは構造体やクラスだからデータの抽象化。TCBのリストはデータの抽象化
TCBリストのイテレーションはループ処理の抽象化
各TCBから呼び出される関数はサブルーチンの抽象化
つまり、タスクシステムはデータのリストから各サブルーチンを実行するループ処理の抽象化

これだけだと、VMの命令リストと同じように見えるけど、
最大の違いは、VMの命令リストは配列なのに対して、
タスクシステムのTCBリストは連結リストである点

TCBは連結リストで管理されているから、連結リストのメリットとデメリットを受ける
オブジェクトが頻繁に追加・削除されるゲームでは連結リストのメリットが生かされる

逆に言えば、連結リストの恩恵を受けられないようなゲームでは、
>>45の言うようにタスクシステムを使う必要がない

**名前は開発中のものです。** · 2010/01/06(水) 16:42:37

思ったとおりに動く
この快感を知らない理論派プログラマは去っていい

**名前は開発中のものです。** · 2010/01/06(水) 21:39:48

>>97
プログラマの思ったとおりに動かないプログラムって何だ？
ＡＩが知性持って反乱でも起こすのか？

**名前は開発中のものです。** · 2010/01/07(木) 01:20:32

>>96
俺が言いたいのはそう言うことじゃなくてさ。
タスクシステムも抽象化は抽象化なんだけど、
勝手手前な抽象化だから、C言語そのもののもつ抽象化と相性が悪く、
逆に退化してんじゃねーかって。

たとえば、タスクのプロシージャに引数が自由に指定できなかったり、
ダウンキャストが発生したり、
タスクの実行順をタスクの追加順やプライオリティーで指定しなければならなかったり。

タスクシステムも抽象化には変わりないんだけど、
C言語に元からある抽象化機能をスポイルしてしまうから、
トータルでは退化している部分の方が多いような。

タスクのプロシージャに自由に引数を指定でき、
書いた順に実行され、ダウンキャストの発生しない
タスクシステム誰か作れや。

**名前は開発中のものです。** · 2010/01/07(木) 01:27:41

タスクシステムって数々の苦行を強いるくせに、
皆が認めるメリットって、「実行順序を動的に制御できる」だけだろ。
なんか割に合わない。

**名前は開発中のものです。** · 2010/01/07(木) 01:38:41

>>99
>C言語に元からある抽象化機能をスポイルしてしまうから、
C言語に元からある抽象化ってまさかifとかswitchのことを言ってるの？

>>100
皆って誰よ。
リンク先には５～６個メリットが上がってるじゃん。

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

>>101
>C言語に元からある抽象化ってまさかifとかswitchのことを言ってるの？

型とか関数の引数とか構造化制御とか。
ちゃんと>>99で書いてるじゃん。勘弁してよ。

>リンク先には５～６個メリットが上がってるじゃん。

これのことですか？
「ゲームを開発するのに適したシステムで開発できる」
勘弁してくださいよ。

**名前は開発中のものです。** · 2010/01/07(木) 02:48:24

君、ノイマンがどうのとか前スレから言ってた奴だろ

**名前は開発中のものです。** · 2010/01/07(木) 02:57:51

ゲームが作れないあの子は昨夏から全く成長がないのだな
つまりセンスがないというか、頭が悪い

**名前は開発中のものです。** · 2010/01/07(木) 16:34:42

>>99
つまり、タスクシステムは実行コストが大きくて可読性が低く、デバッグが難しいということだな

**名前は開発中のものです。** · 2010/01/07(木) 22:33:24

まあ動的言語でやってる事をC言語で強引に実装してる感じは否めない

**名前は開発中のものです。** · 2010/01/08(金) 00:54:14

>>99
>タスクシステムも抽象化は抽象化なんだけど、勝手手前な抽象化だから

半年も経過したっちゅーのに相変わらず攻撃対象を明示せずに
「ぼくメリット分かんない分かんない癇癪起こるムキー」とか
性懲りもなく君は未だにやってるわけだが

一体どこの誰の自称タスクシステムの話をしているのか、それをどういう状況に
適用しようとしたのか。そういうことをこれっぽっちも書こうとしないな。なんでだ？
書けないんだろ。ゲーム作ったことないから。違うか？

どういうタイプの面子と、いつの時代、何を使って、どんなもの作ろうとした？
配当された人、時間、ツール、ターゲットハードウェア、etc。書いてみ？

**名前は開発中のものです。** · 2010/01/08(金) 01:33:44

>>107
タスクシステムが劣勢になると、とたんに個人攻撃をしだすな。
毎度毎度同じパターン。スレを荒らしてうやむやにする。もう嫌になる。

前にも言ったが、俺はハード屋だ。

**名前は開発中のものです。** · 2010/01/08(金) 01:47:31

逃げんのかよ。女々しい奴だな
この程度の煽りくらいノイズフィルターで除去しなさいな

**名前は開発中のものです。** · 2010/01/08(金) 01:55:49

ハード屋ねー。ふーん。で、何作っておまんま食ってるの。
あんた組み込みシステムの話からも逃げてたよねぇ。何作ってんのよ。
>>2の基本は、極めて平凡で古典的なtime triggeredなリアルタイムシステム
cyclic executiveの一種だと説明してやったのに、君は
「何の話かわかんなーいメリットわかんなーい」って知能障害起こして逃げたよねぇ

で、昨夏から成長したのハード屋さん

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

というか、本職の奴がこんなスレに居たらそりゃタスクシステムがそれだけおかしいってことだろ。
何の様でくるんだよ。潜在的な問題意識があるから覗くんだろ。
別に本職の奴は来るなと言いたい訳じゃねーぞ。
問題意識のある奴はどんどん書き込めばいいだろうし。

>>109
ごめん、これ本当に真面目に俺はハード屋なんだ。
ソフトウェアの知識が多少あるのは、大学がそっち系だったから。
日本で飯食ってくこと考えて、ハード屋に鞍替えした。
だから、何を期待されたのかは知らないが、お前の期待にはこたえられそうにない。
あれだね、対岸の火事だからひょうひょうと書き込めるってのもある。

**名前は開発中のものです。** · 2010/01/08(金) 02:09:41

はぁ。。。ため息しか出ない。

**名前は開発中のものです。** · 2010/01/08(金) 02:11:45

>>110
自社製品に使われる基板の設計をする部署に配属されてる。

>>2は俺に言わせりゃ、単に関数並べときゃいいのに、だ。
アロケーターが括り付けてあるのもキモい。別で用意すりゃいいのに。
なんで統合したがるんだろう。

**名前は開発中のものです。** · 2010/01/08(金) 02:16:52

ゲーム作ったことありません＞＜
でもタスクシステムとかいうものが気になって気になって仕方なくて
とにかくこれが憎い（怒）気に入らない（怒）

こういう季節性の周期的な発作を呈する自称ハード屋さんに
何をどうしてあげればいいのかなー。ほんとわかんなーい
さっさとハロワ行って、おまんま食べれるようになって。
批判の対象を明確に。何をどういう状況で使ったら糞でした（ペッ
と書ける生活のゆとりが出来たら戻ってきてください。そんな感じ

**名前は開発中のものです。** · 2010/01/08(金) 02:20:29

>>113
あー、すまん

> アロケーターが括り付けてあるのもキモい。別で用意すりゃいいのに。
> なんで統合したがるんだろう。

んとね、それは>>2のCodeZineの記事はゴミだから。気にするな
天下り式になんかそんなことやっちゃった学生さんの文章だから
深く考えちゃ駄目。読み流せ。大人なら

**名前は開発中のものです。** · 2010/01/08(金) 02:31:00

でも余計な機能を取っ払った純粋なタスクシステムって、
タスクを順番に逐次実行していくだけの代物だろ。
いまさらそんなもの本当に必要か？
そこが面白いんだよ。

**名前は開発中のものです。** · 2010/01/08(金) 10:30:26

必要だと言う奴には、理由を聞きたいね。

**名前は開発中のものです。** · 2010/01/08(金) 10:50:56

スケジューリングしないスケジューラ

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

タスクシステムなんて伝統工芸みたいなものだろ

**名前は開発中のものです。** · 2010/01/09(土) 15:25:43

>>111
本職のプロが仕事で使ってるタスクシステムを
素人の君が何で「使えないもの」と結論付けられるのかわからんな。

「"自分には"使えない」という意味で言ってるのか？
あるいはタスクシステム使った市販ゲームなんて都市伝説、と信じてるとか。

**名前は開発中のものです。** · 2010/01/09(土) 17:18:49

「本職のプロが仕事で使ってる」って便利な殺し文句だよな。

COBOLだってAdaだって、本職のプロが仕事で使ってる。

**名前は開発中のものです。** · 2010/01/09(土) 19:55:40

>>121
COBOLもAdaも使えるじゃん？
ボーイングやF-22の制御ソフトウェアはAdaらしいし。
2009年現在、フォーチュン500の90%の企業はCOBOLプログラムを使用中、らしいし。

ホビープログラマの選ばない言語は「"ホビープログラマにとっては"使えないもの」
になるという理屈かな？

「便利な殺し文句」の説明よろ！

**名前は開発中のものです。** · 2010/01/09(土) 23:33:43

また香ばしいのが沸いてきたな

**名前は開発中のものです。** · 2010/01/09(土) 23:40:13

あーだから、ID:ob/tnXgt　はタスクシステム使ってればいいと思うよ。

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

>「便利な殺し文句」の説明よろ！

これはあれだな、ここではプロが使ってるとか、そう言うのは誰も求めてないのよ。
タスクシステムを使うと何がどういう理屈でどうすばらしいのか、そういうのが求められてる。
また香ばしい展開になりそうな予感。

**名前は開発中のものです。** · 2010/01/10(日) 00:17:17

>>125
説明になっていないな。
逃げてる？

**名前は開発中のものです。** · 2010/01/10(日) 00:23:47

だからー、あの人も使ってるから安心～みたいなのは要らないのよ。
エンジニアなんだったら理屈で説明しやがれ。

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

>>127
理屈で説明どぞ
ささ、早く早くｗｗ

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

理屈で説明しなければならない理屈を説明するのですか？なにそれ。

もし、理屈で説明しないなら、それはその人の主観に過ぎない。
主観は求められていないので、「理屈で説明しない」、は求められてない。
よって、理屈で説明することが求められてる。

ほら、お前らの好きな背理法だぞ。

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

あいかわらずハード屋さんは逃げてばっかりだな。
>>120
を理屈で説明してみなって。

「ハード屋なんでソフトのこと聞かないでくれる？」って逃げ回ってるけど
"エンジニア"は理屈で説明するって自分で言ったよな。
それとも「僕はハード屋だけどエンジニアじゃなくて奴隷です」というオチ？ｗｗ

**名前は開発中のものです。** · 2010/01/10(日) 01:20:30

ソフトのこと聞いてくれてもかまわないけど、経験は無いから、
経験談とか聞かれても、それは答えられない。
逃げないってなんだ？うその経験談でっち上げることじゃなだろ。

>>120
>>116

**名前は開発中のものです。** · 2010/01/10(日) 01:22:59

だいたい、逃げるな逃げるな言われるが、何が求められてるのかさっぱり分からないんだが。
ようは煽りだろ。
もうそういうのもいらねーんだよ。

**名前は開発中のものです。** · 2010/01/10(日) 01:24:18

逃げないってあれか？ゲーム業界に転職して同じ土俵に立てってか？
そ、そこはさすがに逃げるだろー

**名前は開発中のものです。** · 2010/01/10(日) 01:28:37

>>131
>>120と>>116に何の関連も無いが。

んで、別にソフトのこと聞いてないし。
「プロも使ってる手法を素人が使えないっていうのはどんな理屈で？」
と聞いてるだけだ。

こんな簡単な質問がそんな難しいか？
話題そらして逃げまわらずに答えなよ。

**ID:Flkg59Va なんかアクセス規制くらった** · 2010/01/10(日) 01:42:00

使えないとは誰も言ってないだろ。メリットが無いと言ってるんだ。
タスクシステムでゲーム作ることは、そりゃできるだろうよ。

**名前は開発中のものです。** · 2010/01/10(日) 01:45:43

>135
使えないもメリットが無いもたいして違わん。主語が無いから。
「自分にとって」なのか「全ての人にとって」なのか、主語はどっちだ？
前者なら誰も疑問を持たないよ。「ああそうなの」って思うだけ。
後者なら>>120の質問に答えな。

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

>>136
後者だ。
「プロも使ってる手法を素人がメリットが無いっていうのはどんな理屈で？」
メリットが無い理屈は>>116
プロが使ってる理屈は、その人が無能か、もしくはその人の趣味か、社風かなんかだろう。
もともと、アンチはプロが使ってることに意味は無い、という見解で、だからこそアンチなんだから、
そこに理屈を求めるのは擁護派の仕事だろ。
プロがタスクシステム使うのには理屈がある→タスクシステムのメリット　ってことだからな。
だからさっきから散々、「プロが使ってる」の理屈を説明しやがれ、と言ってんだ。

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

>>137
>メリットが無い理屈は>>116
その理由は「ソフトの経験がないハード屋が想像した理由」だろ。
自分から「経験無いんでわかりません」と明言してるのに、
メリットが無い判断だけできる理由の説明をしろと言ってるの。

>だからさっきから散々、「プロが使ってる」の理屈を説明しやがれ、と言ってんだ。
タスクシステムを使った製品があることは「主張」じゃなく「事実」だから。
理由の説明とか必要ない。

「メリットが無い」という「主張」とは違うことを理解しろ。

**名前は開発中のものです。** · 2010/01/10(日) 02:18:17

>メリットが無い判断だけできる理由の説明をしろと言ってるの。
現に、これだけスレが回ってて、いまだにメリットが出てこないだろ。
これも事実だぞ。

**名前は開発中のものです。** · 2010/01/10(日) 02:20:47

何かを主張する以上、それと矛盾する事実がある場合は筋の通った説明をする義務があるな。
じゃないと「その主張は間違い」ということになる。

>プロが使ってる理屈は、その人が無能か、もしくはその人の趣味か、社風かなんかだろう。
って判断を
>ソフトのこと聞いてくれてもかまわないけど、経験は無いから、
って人ができることをおかしいと思わないのかね。

**名前は開発中のものです。** · 2010/01/10(日) 02:27:32

>>139
事実は「"ソフトの経験の無いハード屋さんに理解できる"メリットが出てこない」
だ。「"全ての人の"メリット」じゃない。

なんで「自分一人」に理解できないことは「全ての人」にとっても理解できないこと、と考えるのかね。
その分野の第一人者でもこんなおこがましいこと考えないのに、経験が無いのでわからんと明言してる分野で。

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

>何かを主張する以上、それと矛盾する事実がある場合は筋の通った説明をする義務があるな。
そっくりそのまま擁護派に言いたいな。
なんでいまだにメリットが書き込まれないんだよ。
この、今まさにここで起こってる目の前の矛盾は無視ですかそうですか。

> >プロが使ってる理屈は、その人が無能か、もしくはその人の趣味か、社風かなんかだろう。
> って判断を
> >ソフトのこと聞いてくれてもかまわないけど、経験は無いから、
> って人ができることをおかしいと思わないのかね。

ここ一年ぐらいタスクシステムスレッドにへばりついてて、
結局メリットが書き込まれなかったって経験ならあるぞ。

**名前は開発中のものです。** · 2010/01/10(日) 02:34:25

>>142
>結局メリットが書き込まれなかったって経験ならあるぞ。
過去一年のスレの中に"メリットが書き込まれなかった"？
本当だな？

**名前は開発中のものです。** · 2010/01/10(日) 02:42:22

>事実は「"ソフトの経験の無いハード屋さんに理解できる"メリットが出てこない」
>だ。「"全ての人の"メリット」じゃない。

その、俺には理解できないメリットってどこに書き込まれているの？
ぜひ読みたいのだが。
あー、一個だけ面白いのがあったな。
タスクシステムは無能下請けを閉じ込める檻ってのがな。
別にタスクシステムである必要は無いと思ったが。

てか、俺がもしゲーム業界の人間で、そんで、タスクシステムにメリットはない、と言ってるとしたなら、
それはすんなり受け入れられるってこと？
さっきから俺が業界人でない事ばかりに「あえて」焦点を当ててくるから、
そう言うことになると思うんだけど。

**名前は開発中のものです。** · 2010/01/10(日) 02:48:42

>>144
>その、俺には理解できないメリットってどこに書き込まれているの？
>ぜひ読みたいのだが。
>あー、一個だけ面白いのがあったな。
こんな矛盾だらけのことを、何の疑問も持たずに発言できるなんて、ある意味才能？