[表示 : 全て 最新50 1-99 101- 201- 301- 401- 2chのread.cgiへ]
Update time : 05/10 00:46 / Filesize : 159 KB / Number-of Response : 417
[このスレッドの書き込みを削除する]
[+板 最近立ったスレ&熱いスレ一覧 : +板 最近立ったスレ/記者別一覧] [類似スレッド一覧]


↑キャッシュ検索、類似スレ動作を修正しました、ご迷惑をお掛けしました

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



1 名前:名前は開発中のものです。 mailto:sage [2009/12/13(日) 18:11:06 ID:ESt66YNz]
タスクシステムについての議論、相談、質問、雑談などのスレです

part8 pc11.2ch.net/test/read.cgi/gamedev/1250678891/
part7 pc11.2ch.net/test/read.cgi/gamedev/1241670786/
part6 pc11.2ch.net/test/read.cgi/gamedev/1238725539/
part5 pc11.2ch.net/test/read.cgi/gamedev/1234977661/
part4 pc11.2ch.net/test/read.cgi/gamedev/1233459490/
part3 pc11.2ch.net/test/read.cgi/gamedev/1226199100/
part2 pc11.2ch.net/test/read.cgi/gamedev/1196711513/
part1 pc11.2ch.net/test/read.cgi/gamedev/1173708588/


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

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

38 名前:名前は開発中のものです。 mailto:sage [2009/12/30(水) 11:56:09 ID:HbFRn4m1]
>>37
ありがとう。マジでその意味は知らなかった。
レトリック 詭弁でぐぐるとザクザク出てくるし、
「それはレトリック=詭弁と呼ばれ、禁じ手とされてきた。」などと一発目に目に付く。

39 名前:名前は開発中のものです。 mailto:sage [2009/12/30(水) 12:01:47 ID:LqQKx7uV]
タスクシステムとやらで不要なシステムを強要してバグを大量生産するプロジェクトが
よく見られますがどう思いますか

40 名前:名前は開発中のものです。 mailto:sage [2009/12/30(水) 12:06:48 ID:HbFRn4m1]
>>39
ホントはね、「触らぬ神に祟り無し」これだけで十分。
相手をして遊ぶのは仕事から離れた、2ちゃんとかだけにしときたいよね。
私怨をもたれたらめんどいから。

41 名前:名前は開発中のものです。 mailto:sage [2009/12/30(水) 12:21:26 ID:wSMcXtGv]
>>39
プロジェクトのメインプログラマーが、タスクシステムのデメリットを超える
メリットがある、と判断したて採用したんだろうなぁ、と。

不要に見えるならもっと良い方法を提示してあげたらいいんじゃない?できるんなら。

一本メインで任せられるほど会社から実績と信頼もらってる優秀なプログラマなんだから
もっと良い方法提示されたら喜んで受け入れてくれるよ・・・

42 名前:名前は開発中のものです。 mailto:sage [2009/12/30(水) 12:25:22 ID:bWAUJXLm]
おれがメインやるときは使わないが
火の車のプロジェクトにヘルプで入るとってパターンばかり
おれは使うなとはいうけど責任ないプロジェクトにまで影響力ないな

43 名前:名前は開発中のものです。 mailto:sage [2009/12/30(水) 13:24:09 ID:wSMcXtGv]
個人的な経験の範囲ではプロジェクトに火がつくかどうかとタスクシステムの有無に因果関係はほとんど無かったけどな。
火がつく理由は非常識な納期とか仕様の甘さとか進捗管理のまずさとか、もっと外側の原因がほとんど。

まぁタスクシステムは良くも悪くも「Cの精神」と「ゲームプログラマ固有のケチさ」が色濃くでてる
システムではあるんだけど。

新人がタスクシステム使って「何でこんな簡単な処理を、ここまで複雑で危険な処理にできるんだろう」
というのも見たことあるし。

スーファミ時代から現役の40歳超え超ロートルプログラマがDS用にタスクシステムで作ったゲーム
コードでは、美しい数学の証明でも見てるみたいに理解しやすくシンプルで、高速高効率なコードに
仕上がってるのみ見たこともある。

結局、誰がどんなプラットフォームでどんな仕様のゲームを作るのか、という目的にてらしてメリットデメリット
比較して使えるところではうまく使えばいいんじゃね?という当たり前の結論。


44 名前:名前は開発中のものです。 mailto:sage [2009/12/30(水) 19:13:10 ID:EC518Flk]
ヒットに責任もつやつが主導権持つのは当たり前。
そういう点ではここのプログラマーが下に見られるのは当たり前。
決してプログラマーはヒットに貢献出来ないといってるわけではない。

45 名前:名前は開発中のものです。 mailto:sage [2009/12/30(水) 21:37:14 ID:PB4TpBDR]
というか、普通にかけばいいじゃん。

tasks.push_back( task1 );
tasks.push_back( task2 );
tasks.push_back( task3 );
for(;;){ for( size_t i=0; i<tasks.size(); ++i){ tasks[i](); } }

よりも、

for(;;){
task1();
task2();
task3();
}

の方が自然だろ。
プログラム自体が処理のリストなのに、何故わざわざ処理のリストを自前で用意するんだ?
バーチャルマシンでも作る気か?

46 名前:名前は開発中のものです。 mailto:sage [2009/12/30(水) 21:44:27 ID:PB4TpBDR]
タスクシステムを(アカデミックな方向に)発展させていくと、

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

とかになるぞ。変だろ。



47 名前:名前は開発中のものです。 mailto:sage [2009/12/30(水) 21:55:31 ID:PB4TpBDR]
C言語には、プログラムを上から順番に実行していくというタスクシステム的な仕組み以外にも、
if文があったり関数に引数が指定できたり、型があったりと、
目いっぱい便利な仕組みが用意されているのに、
なんでわざわざバーチャルマシンもどきのタスクシステムを自分で実装しようとするんだ?
そんなことするから、C言語に元から用意されていた、
構造化制御とか型とか関数の引数などの便利な機能が使えなくなるんだろ。

48 名前:名前は開発中のものです。 mailto:sage [2009/12/30(水) 22:22:56 ID:wSMcXtGv]
技術的に低すぎる馬鹿みたいな例をあえて出して
釣ろうって手段かね。
釣りだとしてもいまいち・・・

49 名前:名前は開発中のものです。 mailto:sage [2009/12/30(水) 23:03:38 ID:PB4TpBDR]
タスクシステム自体がバカみたいな例そのものだとおもうが。
既存のものを使わずに自作して周囲からの恩恵を受けられなくなるという。
そういう趣味性を否定するわけではないが。


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

51 名前:名前は開発中のものです。 mailto:sage [2009/12/30(水) 23:46:59 ID:wSMcXtGv]
>>47
ネタにマジレスだが
関数ポインタもC言語に元から用意された便利な機能だろ?
タスクシステムの実装っていかにもC言語的(というかthe spirit of C)なんだが。良くも悪くも。
古典的タスクシステムなんて古きよきUNIX時代のC言語のコードを見てる気分になる。
これこそCのプログラムって感じ。
「プログラマを信頼する」というCの精神と同じ思想で
信頼されたプログラマ、つまりタスク仕様上の「落とし穴」を正しく理解したプログラマであれば
その穴に陥らずにプログラムを書けるはずである、といういかにもな精神。

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

52 名前:名前は開発中のものです。 mailto:sage [2009/12/31(木) 00:48:41 ID:ksb+2wzg]
>>51
関数ポインタ⊂タスクシステム

53 名前:名前は開発中のものです。 mailto:sage [2009/12/31(木) 10:05:26 ID:jmX7vBje]
>>47>>51と返す奴の理解力が心配だなw

54 名前:名前は開発中のものです。 mailto:sage [2009/12/31(木) 13:56:13 ID:V8ENfRFL]
ネタにマジレスしてくれる優しい人なんでしょww
引数君のレベルが低すぎて話が噛み合ってないが

55 名前:名前は開発中のものです。 mailto:sage [2009/12/31(木) 14:48:06 ID:BNue/Y+a]
>>45
> というか、普通にかけばいいじゃん。
それはお前にとっての普通だろw

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

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

その程度で「OSでも作るのか?バーチャルマシンでも作るのか?」って涙目w

56 名前:名前は開発中のものです。 mailto:sage [2009/12/31(木) 17:00:50 ID:5+vTlDqR]
>>55
頭の弱いものいじめ、カコワルイww



57 名前:名前は開発中のものです。 mailto:sage [2009/12/31(木) 18:52:03 ID:h+8Shtga]
抽象化はメリットがなければじゃまなだけ。
メリットが明確じゃないから使わないんだろ。
メリット感じてるやつだけが使えばいいんだよ。

58 名前:名前は開発中のものです。 mailto:sage [2009/12/31(木) 19:06:43 ID:Z2PxtqgR]
「タスクシステムでゲームを作る」って言うよりは、
「有限状態機械を組み合わせてゲームを作りたいけど、
 使用する言語にコルーチンのような機構が無いから、
 同じような物を自前で実装するためにタスクシステムを使用する」
っていうのがタスクシステムを使う本来の動機だと思う

59 名前:名前は開発中のものです。 mailto:sage [2009/12/31(木) 19:28:41 ID:dXSivK3c]
正直最初に実装した人は少なくともそんな小難しく考えてないだろう。
・俺がメモリを管理する!がしたい
・状態(データ)と処理(動作)を一まとめに出来たら直感的
・それらの一まとめを個別に自由に追加・削除したい。

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

60 名前:名前は開発中のものです。 mailto:sage [2009/12/31(木) 19:38:27 ID:5+vTlDqR]
>>57
>>43
それもう結論出てるから。

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

61 名前:名前は開発中のものです。 mailto:sage [2009/12/31(木) 19:48:27 ID:r+thC80S]
でも誰も語れない不思議

62 名前:名前は開発中のものです。 mailto:sage [2009/12/31(木) 19:53:57 ID:MpNp4sOV]
FSMとコルーチンってなんか特別な関係があるの?
コルーチンって状態遷移に対してメリット思いつかないんだが

63 名前:名前は開発中のものです。 mailto:sage [2009/12/31(木) 20:43:02 ID:5+vTlDqR]
>>61
でも誰も"僕の理解できることを"語れない不思議

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

64 名前:名前は開発中のものです。 mailto:sage [2009/12/31(木) 21:44:09 ID:6w1nCnA3]
それでも語らない不思議

65 名前:名前は開発中のものです。 mailto:sage [2010/01/01(金) 00:33:49 ID:VUgsc33T]
>>59
その動機ならalloc系をラッピングしたほうが自然では?

66 名前:名前は開発中のものです。 mailto:sage [2010/01/01(金) 03:30:24 ID:4JKBI3JG]
>>55
>一般のCプログラマにとっては関数ポインタ使った方法もC言語の
>言語仕様で想定された"普通"の方法の一つなんだけど。

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

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

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



67 名前:名前は開発中のものです。 mailto:sage [2010/01/01(金) 03:49:11 ID:4JKBI3JG]
もちろん、実行順序を動的に制御したい場合もあるだろうけど、
そういう汚い部分は、個々のモジュール内に閉じ込めて、表に撒き散らさないようにした方が賢いと思うが。
Zソートを例に挙げると、それは描画エンジン内でこっそり行えばよい話で、
タスクシステムみたいに変に統合しちゃって、猫も杓子もそれつかえってのは無茶。

68 名前:名前は開発中のものです。 mailto:sage [2010/01/01(金) 04:12:13 ID:4JKBI3JG]
>>62
>FSMとコルーチンってなんか特別な関係があるの?
>コルーチンって状態遷移に対してメリット思いつかないんだが

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

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

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

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

69 名前:名前は開発中のものです。 mailto:sage [2010/01/01(金) 04:27:38 ID:4JKBI3JG]
では、状態が独立している場合にはコルーチンが有効かというと、実はそうでもない。
なんでかっていうと、状態が独立しているのなら、初めからプログラムはそんなに複雑にはならないから、
ベタで書いても大したこと無いから。

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

70 名前:名前は開発中のものです。 mailto:sage [2010/01/01(金) 08:12:20 ID:PCKniPZB]
古典タスクシステムの

メリット:

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

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

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


デメリット:

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

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

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

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

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

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

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

72 名前:名前は開発中のものです。 mailto:sage [2010/01/01(金) 09:39:45 ID:4JKBI3JG]
>>70
逐次実行がタスクシステムの売りっていわれても、そもそもプログラムは基本全部逐次実行だ。
ますますfor(;;){ task1(); task2(); task3(); }で問題ないな。

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

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

73 名前:名前は開発中のものです。 mailto:sage [2010/01/01(金) 09:50:21 ID:7lwJSlZL]
>>72
>ゲームのメインロジックは泥臭くなるというが、それはゲームエンジンを使おうとするから。
>ゲームなんて、入力→状態更新→描画 を永遠と繰り返すだけなわけで、
>普通に書けばそんなに泥臭くならない。
UEエンジンやFarCryエンジン、タスクシステム使ってる時代遅れの開発者達に
「ゲームエンジンなんて使わずに普通に書け」と教えてあげなきゃ!
世界中のゲーム開発者が気づかなかったことを気づくなんて天才だね。
・・・紙一重にはかなわんww

74 名前:名前は開発中のものです。 mailto:sage [2010/01/01(金) 10:00:29 ID:4JKBI3JG]
今時ゲームなんて作ってる奴はもとより時代遅れなのかもしれないよ?

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

75 名前:名前は開発中のものです。 mailto:sage [2010/01/01(金) 10:21:15 ID:7lwJSlZL]
>>74
>今時ゲームなんて作ってる奴はもとより時代遅れなのかもしれないよ?
ゲーム製作技術なんて時代遅れの板では天才様のレベルには合わないようですよ?www

76 名前:名前は開発中のものです。 mailto:sage [2010/01/01(金) 10:31:24 ID:4C/yACts]
ID:7lwJSlZL、そんなに怖がるなよw
ID:4JKBI3JGは少なからず理屈で出てるんだから、
お前が逃げると、見てるほうとしては物足りないぞ。
もっと頭を使わないと立派な大人になれないぞ。



77 名前:名前は開発中のものです。 mailto:sage [2010/01/01(金) 11:00:53 ID:FSN4cjeN]
>>2の構造ならポインタインクリ、デクリできるからじゃね?
あとなんかヒープ領域をリアルタイムでこまめに確保するのってなんかCっぽくないと思えるように最近なってきた。不思議。

78 名前:77 mailto:sage [2010/01/01(金) 11:01:41 ID:FSN4cjeN]
安価忘れ。>>65

79 名前:名前は開発中のものです。 mailto:sage [2010/01/01(金) 11:17:47 ID:7lwJSlZL]
>>76
みえみえ・・・

80 名前:名前は開発中のものです。 mailto:sage [2010/01/01(金) 15:18:56 ID:Q96dsOT3]
イベントドリブンとgotoの違いがわかりません

81 名前:名前は開発中のものです。 mailto:sage [2010/01/01(金) 16:25:03 ID:kwLK11hf]
>>76
>>71-75の流れ見ればID:4JKBI3JGの完敗にしか見えんが
ゲームエンジン否定して毎作エンジン自作しろってか?正気とは思えん。
ID:4JKBI3JGが勝ってるように見える人間の理屈を教えて欲しい。まじで。

82 名前:名前は開発中のものです。 mailto:sage [2010/01/01(金) 16:33:22 ID:QDlESbUP]
なぜタスクシステムをゲームエンジンと読み替えるの?

83 名前:名前は開発中のものです。 mailto:sage [2010/01/01(金) 16:36:10 ID:kwLK11hf]
>>82
>>72で本人が言ってるけど。

84 名前:名前は開発中のものです。 mailto:sage [2010/01/02(土) 01:19:18 ID:QfJjPf0+]
ゲームエンジン(タスクシステム含む)なんて糞ですよ。
ゲーム用ライブラリ、これで十分。
でも俺もゲーム用ライブラリ作って商売しろって言われたら、
マーケティングの都合上、そりゃゲームエンジン(フレームワークみたいな奴)
にするけどな。使い勝手とかじゃなく、身の保身のためにな。

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

85 名前:名前は開発中のものです。 mailto:sage [2010/01/02(土) 01:27:01 ID:QfJjPf0+]
あーだから、UEエンジンとかも、ライブラリ的に気軽に利用できる部分はどんどん使えばよいと思うよ。
ただ、actorとかマジで要らないよね。
なんていうか、トラップにすら思える。

86 名前:名前は開発中のものです。 mailto:sage [2010/01/02(土) 01:41:11 ID:QfJjPf0+]
>ゲームエンジン否定して毎作エンジン自作しろってか?正気とは思えん。

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



87 名前:名前は開発中のものです。 mailto:sage [2010/01/04(月) 19:31:30 ID:i2Edvm4/]
タスクシステムの利点は、ゲームプログラミングの学習の段階で
ゲーム中のオブジェクトを抽象化する練習が出来ることだと思う
ゲーム中のイベントやキャラクター、エフェクトを
どのようにオブジェクトに分割して実装するか、とか考える練習になると思う

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

88 名前:名前は開発中のものです。 mailto:sage [2010/01/04(月) 19:44:33 ID:UpxJY3Kj]
今のゲームプログラマって抽象化ができないんだよね

89 名前:名前は開発中のものです。 mailto:sage [2010/01/05(火) 03:55:23 ID:tTEIn5Ga]
しかし、抽象化に限界を感じるのも事実かも。特に汎化。
車輪の再発明はするなとか、再利用性とか・・・。

90 名前:名前は開発中のものです。 mailto:sage [2010/01/05(火) 10:58:16 ID:hppQWDKd]
10年以上タスクを使ってたおれが、いま非タスクでゲームを実装してるよー!
正直どっちでもいいよとおもった。


91 名前:名前は開発中のものです。 mailto:sage [2010/01/05(火) 12:01:30 ID:XJonv3Ta]
たしかにどちらでも動作するので
プレイする側からしたらどうでもいい話
しかし、抽象化のできないマと話をするのは嫌

92 名前:名前は開発中のものです。 mailto:sage [2010/01/05(火) 14:17:47 ID:UmUFrQG9]
タスクシステムはともかくゲームエンジンまで不要と言い出したのか。
昔のタスクスレでOOP不要とかクラス不要と言ってた人と同一人物っぽいな。


93 名前:名前は開発中のものです。 mailto:sage [2010/01/05(火) 15:46:08 ID:egLjh0Im]
タスクシステムもオブジェクト指向も、抽象化して複雑さを管理するための
メタファーでしかないんだけどな。

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

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

94 名前:名前は開発中のものです。 mailto:sage [2010/01/06(水) 03:10:22 ID:xz1S9Fiq]
タスクシステムが制御構造のいったい何を抽象化するというのだろう。
俺からしたら、いわゆるif文とかで普通に制御する構造化制御のよりも、
抽象度が落ちているようにしか思えないのだが。
ノイマン型コンピュータの逐次実行性を抽象化するもの→VM ってこと?

95 名前:名前は開発中のものです。 mailto:sage [2010/01/06(水) 11:26:48 ID:sfZn8VJ7]
ifで制御とか、超具象的じゃね?

96 名前:名前は開発中のものです。 mailto:sage [2010/01/06(水) 14:23:59 ID:tFGAv+Wn]
TCBは構造体やクラスだからデータの抽象化。TCBのリストはデータの抽象化
TCBリストのイテレーションはループ処理の抽象化
各TCBから呼び出される関数はサブルーチンの抽象化
つまり、タスクシステムはデータのリストから各サブルーチンを実行するループ処理の抽象化

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

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

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



97 名前:名前は開発中のものです。 mailto:sage [2010/01/06(水) 16:42:37 ID:JaFm52Ts]
思ったとおりに動く
この快感を知らない理論派プログラマは去っていい

98 名前:名前は開発中のものです。 mailto:sage [2010/01/06(水) 21:39:48 ID:QS9Yf2c/]
>>97
プログラマの思ったとおりに動かないプログラムって何だ?
AIが知性持って反乱でも起こすのか?

99 名前:名前は開発中のものです。 mailto:sage [2010/01/07(木) 01:20:32 ID:hnRcXVPe]
>>96
俺が言いたいのはそう言うことじゃなくてさ。
タスクシステムも抽象化は抽象化なんだけど、
勝手手前な抽象化だから、C言語そのもののもつ抽象化と相性が悪く、
逆に退化してんじゃねーかって。

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

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

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

100 名前:名前は開発中のものです。 mailto:sage [2010/01/07(木) 01:27:41 ID:hnRcXVPe]
タスクシステムって数々の苦行を強いるくせに、
皆が認めるメリットって、「実行順序を動的に制御できる」だけだろ。
なんか割に合わない。

101 名前:名前は開発中のものです。 mailto:sage [2010/01/07(木) 01:38:41 ID:socYDQ5J]
>>99
>C言語に元からある抽象化機能をスポイルしてしまうから、
C言語に元からある抽象化ってまさかifとかswitchのことを言ってるの?

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

102 名前:名前は開発中のものです。 mailto:sage [2010/01/07(木) 02:10:42 ID:hnRcXVPe]
>>101
>C言語に元からある抽象化ってまさかifとかswitchのことを言ってるの?

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

>リンク先には5〜6個メリットが上がってるじゃん。

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

103 名前:名前は開発中のものです。 mailto:sage [2010/01/07(木) 02:48:24 ID:9Rd9VjpK]
君、ノイマンがどうのとか前スレから言ってた奴だろ

104 名前:名前は開発中のものです。 mailto:sage [2010/01/07(木) 02:57:51 ID:9Rd9VjpK]
ゲームが作れないあの子は昨夏から全く成長がないのだな
つまりセンスがないというか、頭が悪い

105 名前:名前は開発中のものです。 mailto:sage [2010/01/07(木) 16:34:42 ID:bq7Zas9u]
>>99
つまり、タスクシステムは実行コストが大きくて可読性が低く、デバッグが難しいということだな

106 名前:名前は開発中のものです。 mailto:sage [2010/01/07(木) 22:33:24 ID:plkS+oZ9]
まあ動的言語でやってる事をC言語で強引に実装してる感じは否めない



107 名前:名前は開発中のものです。 mailto:sage [2010/01/08(金) 00:54:14 ID:DYplkFdV]
>>99
>タスクシステムも抽象化は抽象化なんだけど、勝手手前な抽象化だから

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

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

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


108 名前:名前は開発中のものです。 mailto:sage [2010/01/08(金) 01:33:44 ID:ANKhAB1L]
>>107
タスクシステムが劣勢になると、とたんに個人攻撃をしだすな。
毎度毎度同じパターン。スレを荒らしてうやむやにする。もう嫌になる。

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


109 名前:名前は開発中のものです。 mailto:sage [2010/01/08(金) 01:47:31 ID:DYplkFdV]
逃げんのかよ。女々しい奴だな
この程度の煽りくらいノイズフィルターで除去しなさいな

110 名前:名前は開発中のものです。 mailto:sage [2010/01/08(金) 01:55:49 ID:DYplkFdV]
ハード屋ねー。ふーん。で、何作っておまんま食ってるの。
あんた組み込みシステムの話からも逃げてたよねぇ。何作ってんのよ。
>>2の基本は、極めて平凡で古典的なtime triggeredなリアルタイムシステム
cyclic executiveの一種だと説明してやったのに、君は
「何の話かわかんなーいメリットわかんなーい」って知能障害起こして逃げたよねぇ

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

111 名前:名前は開発中のものです。 mailto:sage [2010/01/08(金) 02:00:01 ID:ANKhAB1L]
というか、本職の奴がこんなスレに居たらそりゃタスクシステムがそれだけおかしいってことだろ。
何の様でくるんだよ。潜在的な問題意識があるから覗くんだろ。
別に本職の奴は来るなと言いたい訳じゃねーぞ。
問題意識のある奴はどんどん書き込めばいいだろうし。

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

112 名前:名前は開発中のものです。 mailto:sage [2010/01/08(金) 02:09:41 ID:DYplkFdV]
はぁ。。。ため息しか出ない。

113 名前:名前は開発中のものです。 mailto:sage [2010/01/08(金) 02:11:45 ID:ANKhAB1L]
>>110
自社製品に使われる基板の設計をする部署に配属されてる。

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

114 名前:名前は開発中のものです。 mailto:sage [2010/01/08(金) 02:16:52 ID:DYplkFdV]
ゲーム作ったことありません><
でもタスクシステムとかいうものが気になって気になって仕方なくて
とにかくこれが憎い(怒)気に入らない(怒)

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


115 名前:名前は開発中のものです。 mailto:sage [2010/01/08(金) 02:20:29 ID:DYplkFdV]
>>113
あー、すまん

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

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


116 名前:名前は開発中のものです。 mailto:sage [2010/01/08(金) 02:31:00 ID:ANKhAB1L]
でも余計な機能を取っ払った純粋なタスクシステムって、
タスクを順番に逐次実行していくだけの代物だろ。
いまさらそんなもの本当に必要か?
そこが面白いんだよ。



117 名前:名前は開発中のものです。 mailto:sage [2010/01/08(金) 10:30:26 ID:nbdwgzL8]
必要だと言う奴には、理由を聞きたいね。

118 名前:名前は開発中のものです。 mailto:sage [2010/01/08(金) 10:50:56 ID:vSnmCn7z]
スケジューリングしないスケジューラ

119 名前:名前は開発中のものです。 mailto:sage [2010/01/09(土) 09:41:23 ID:fTujCO4e]
タスクシステムなんて伝統工芸みたいなものだろ

120 名前:名前は開発中のものです。 mailto:sage [2010/01/09(土) 15:25:43 ID:ob/tnXgt]
>>111
本職のプロが仕事で使ってるタスクシステムを
素人の君が何で「使えないもの」と結論付けられるのかわからんな。

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

121 名前:名前は開発中のものです。 mailto:sage [2010/01/09(土) 17:18:49 ID:nu64CGug]
「本職のプロが仕事で使ってる」って便利な殺し文句だよな。

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

122 名前:名前は開発中のものです。 mailto:sage [2010/01/09(土) 19:55:40 ID:ob/tnXgt]
>>121
COBOLもAdaも使えるじゃん?
ボーイングやF-22の制御ソフトウェアはAdaらしいし。
2009年現在、フォーチュン500の90%の企業はCOBOLプログラムを使用中、らしいし。

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

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

123 名前:名前は開発中のものです。 mailto:sage [2010/01/09(土) 23:33:43 ID:cg8I3o/u]
また香ばしいのが沸いてきたな

124 名前:名前は開発中のものです。 mailto:sage [2010/01/09(土) 23:40:13 ID:cg8I3o/u]
あーだから、ID:ob/tnXgt はタスクシステム使ってればいいと思うよ。

125 名前:名前は開発中のものです。 mailto:sage [2010/01/09(土) 23:48:41 ID:cg8I3o/u]
>「便利な殺し文句」の説明よろ!

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

126 名前:名前は開発中のものです。 mailto:sage [2010/01/10(日) 00:17:17 ID:9ahDY9xP]
>>125
説明になっていないな。
逃げてる?



127 名前:名前は開発中のものです。 mailto:sage [2010/01/10(日) 00:23:47 ID:Flkg59Va]
だからー、あの人も使ってるから安心〜みたいなのは要らないのよ。
エンジニアなんだったら理屈で説明しやがれ。

128 名前:名前は開発中のものです。 mailto:sage [2010/01/10(日) 00:33:04 ID:9ahDY9xP]
>>127
理屈で説明どぞ
ささ、早く早くww

129 名前:名前は開発中のものです。 mailto:sage [2010/01/10(日) 01:02:11 ID:Flkg59Va]
理屈で説明しなければならない理屈を説明するのですか?なにそれ。

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

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

130 名前:名前は開発中のものです。 mailto:sage [2010/01/10(日) 01:10:53 ID:9ahDY9xP]
あいかわらずハード屋さんは逃げてばっかりだな。
>>120
を理屈で説明してみなって。

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

131 名前:名前は開発中のものです。 mailto:sage [2010/01/10(日) 01:20:30 ID:Flkg59Va]
ソフトのこと聞いてくれてもかまわないけど、経験は無いから、
経験談とか聞かれても、それは答えられない。
逃げないってなんだ?うその経験談でっち上げることじゃなだろ。

>>120
>>116

132 名前:名前は開発中のものです。 mailto:sage [2010/01/10(日) 01:22:59 ID:Flkg59Va]
だいたい、逃げるな逃げるな言われるが、何が求められてるのかさっぱり分からないんだが。
ようは煽りだろ。
もうそういうのもいらねーんだよ。

133 名前:名前は開発中のものです。 mailto:sage [2010/01/10(日) 01:24:18 ID:Flkg59Va]
逃げないってあれか?ゲーム業界に転職して同じ土俵に立てってか?
そ、そこはさすがに逃げるだろー

134 名前:名前は開発中のものです。 mailto:sage [2010/01/10(日) 01:28:37 ID:9ahDY9xP]
>>131
>>120>>116に何の関連も無いが。

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

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

135 名前:ID:Flkg59Va なんかアクセス規制くらった mailto:sage [2010/01/10(日) 01:42:00 ID:iYQ9vwhm]
使えないとは誰も言ってないだろ。メリットが無いと言ってるんだ。
タスクシステムでゲーム作ることは、そりゃできるだろうよ。

136 名前:名前は開発中のものです。 mailto:sage [2010/01/10(日) 01:45:43 ID:9ahDY9xP]
>135
使えないもメリットが無いもたいして違わん。主語が無いから。
「自分にとって」なのか「全ての人にとって」なのか、主語はどっちだ?
前者なら誰も疑問を持たないよ。「ああそうなの」って思うだけ。
後者なら>>120の質問に答えな。



137 名前:名前は開発中のものです。 mailto:sage [2010/01/10(日) 01:58:38 ID:iYQ9vwhm]
>>136
後者だ。
「プロも使ってる手法を素人がメリットが無いっていうのはどんな理屈で?」
メリットが無い理屈は>>116
プロが使ってる理屈は、その人が無能か、もしくはその人の趣味か、社風かなんかだろう。
もともと、アンチはプロが使ってることに意味は無い、という見解で、だからこそアンチなんだから、
そこに理屈を求めるのは擁護派の仕事だろ。
プロがタスクシステム使うのには理屈がある→タスクシステムのメリット ってことだからな。
だからさっきから散々、「プロが使ってる」の理屈を説明しやがれ、と言ってんだ。

138 名前:名前は開発中のものです。 mailto:sage [2010/01/10(日) 02:04:54 ID:9ahDY9xP]
>>137
>メリットが無い理屈は>>116
その理由は「ソフトの経験がないハード屋が想像した理由」だろ。
自分から「経験無いんでわかりません」と明言してるのに、
メリットが無い判断だけできる理由の説明をしろと言ってるの。

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

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






[ 続きを読む ] / [ 携帯版 ]

前100 次100 最新50 [ このスレをブックマーク! 携帯に送る ] 2chのread.cgiへ
[+板 最近立ったスレ&熱いスレ一覧 : +板 最近立ったスレ/記者別一覧]( ´∀`)<159KB

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef