- 1 名前：仕様書無しさん [2007/02/03(土) 20:11:09 ]
- ま、聞かない方が良い事もあるけどね。
ゲームプログラマーの人に聞きたい
ttp://pc.2ch.net/test/read.cgi/prog/1062855581/
ゲームプログラマーの人に聞きたい 2問目
ttp://pc3.2ch.net/test/read.cgi/prog/1078293745/
ゲームプログラマーの人に聞きたい 3問目
ttp://pc5.2ch.net/test/read.cgi/prog/1080491019/
ゲームプログラマーの人に聞きたい 4問目
ttp://pc5.2ch.net/test/read.cgi/prog/1086890676/
ゲームプログラマーの人に聞きたい 5問目
ttp://pc5.2ch.net/test/read.cgi/prog/1093629292/
ゲームプログラマーの人に聞きたい 6問目
ttp://pc5.2ch.net/test/read.cgi/prog/1100665806/
ゲームプログラマーの人に聞きたい 7問目
ttp://pc5.2ch.net/test/read.cgi/prog/1103458370/
ゲームプログラマーの人に聞きたい 8問目
ttp://pc5.2ch.net/test/read.cgi/prog/1108481342/
ゲームプログラマーの人に聞きたい 9問目
ttp://pc8.2ch.net/test/read.cgi/prog/1110993642/
ゲームプログラマーの人に聞きたい 0xA問目
ttp://pc8.2ch.net/test/read.cgi/prog/1115375538/
ゲームプログラマーの人に聞きたい 11問目
ttp://pc8.2ch.net/test/read.cgi/prog/1119537622/
ゲームプログラマーの人に聞きたい 12問目
ttp://pc8.2ch.net/test/read.cgi/prog/1125150865/
ゲームプログラマーの人に聞きたい 13問目
ttp://pc8.2ch.net/test/read.cgi/prog/1131010658/
ゲームプログラマーの人に聞きたい 13問目 (※実質14問目)
ttp://pc8.2ch.net/test/read.cgi/prog/1131024006/
ゲームプログラマーの人に聞きたい 15問目
ttp://pc8.2ch.net/test/read.cgi/prog/1143779166/
- 177 名前：仕様書無しさん mailto:sage [2007/02/15(木) 01:05:42 ]
- >>165
時代はクロージャーだ関数オブジェクトまんせーデレゲートまんせーとかw
つか関数生ポインタはデータに対する生ポインタより障害は少ないと思うし、有効だと思うんだが駄目な理由はなんなんだろうな？
壊したら普通即飛びで、スタック追えは一発だと思うのだが。
- 178 名前：仕様書無しさん mailto:sage [2007/02/15(木) 01:09:34 ]
- 配列よりListやVectorがいいとかそういう程度の問題では。
初期化忘れや未定義変数へのアクセスが出来てれば
アホにもいじってもらえる。
- 179 名前：仕様書無しさん mailto:sage [2007/02/15(木) 01:30:35 ]
- >>176
＞その場限りの使い捨て
だといいですねぇ、ほんとにまったく。
- 180 名前：仕様書無しさん mailto:sage [2007/02/15(木) 05:42:52 ]
- >>177
実行するもんによって引数違うことのが多いから役にたたね。
関数ポインタ使う＝グローバルでアクセスできるなにかが必要になる。
だから、あんまりうまい設計にならないことに気がついて辞めた。
- 181 名前：仕様書無しさん mailto:sage [2007/02/15(木) 06:50:53 ]
- 稲葉敦志。神谷英樹。三上真司。そして、選りすぐりのスタッフ達。
新会社SEEDS。
ttp://www.seeds-inc.jp/index.html
- 182 名前：仕様書無しさん mailto:sage [2007/02/15(木) 06:53:09 ]
- SEEDSは社員を募集しています。
プログラマー
ゲームプログラム全般、
ツール及びライブラリ制作
CGツールプラグイン制作（XSI等)
サウンドドライバ制作
C/C++言語でのプログラミング経験
ゲーム作りに対する強い意志と忍耐力
- 183 名前：仕様書無しさん mailto:sage [2007/02/15(木) 07:04:13 ]
- なんか話が食い違うと思っていたらやっと原因がつかめた。
オレは昔の人なんだけど、擬似マルチタスクとかを作って使っていた世代。
昔は機械の性能が低くて「開発のし易さ＜実行時のパフォーマンス」だったのね。
今は機械の性能が高いから適当にできる「開発のし易さ＞実行時のパフォーマンス」なのね。
だから、ソースも出てこないFiberとかデバッグがしずらいウンヌンとかいっているのか・・・
日本のゲームプログラマも落ちたもんだ。オレは日本のソフトウェア屋でゲーム屋が一番賢い
と思っているし、日本が海外へ輸出する数少ないソフトウェアだと思ってた。
ゲーム以外のソフト開発もしているからわかるが、ゲーム屋は間違えなく平均艇に賢いし、
手際もいい。土壇場で逃げ出さない根性もあるはず。だからハードに頼らずいいものを
作って欲しい。
Cコンパイラもなく、メーカーからライブラリが提供されなくて、あるものはハードの仕様書のみ。
って状態でコツコツ作っていた時代に戻れないのはわかっているが、もうすこし魂を入れて開発
してもらいたい。
- 184 名前：仕様書無しさん mailto:sage [2007/02/15(木) 07:30:29 ]
- >なんか話が食い違うと思っていたらやっと原因がつかめた。
>>3を読めば原因は明らかだよなｗ
- 185 名前：仕様書無しさん mailto:sage [2007/02/15(木) 07:34:10 ]
- ネタにしちゃ面白くないし、マジなら引退した方がいいんじゃね？
- 186 名前：仕様書無しさん mailto:sage [2007/02/15(木) 07:38:17 ]
- >>183
俺も昔からやってるけど、擬似タスク使う奴は昔からバグ多かったよ。
１フレーム単位のキャラの動作からいって同期してねーようなもん作る奴ばっかりだった。
- 187 名前：仕様書無しさん mailto:sage [2007/02/15(木) 08:05:14 ]
- >>186
1フレーム単位のキャラの動作の同期が気なるようなゲームの場合こそ、
擬似マルチの方が適切だと思うが・・・
各タスクの動作順番をリアルタイムで変更できるし、同じタスクを二度動くように
スケジューラーをいじる事もできるし・・・・
使い方を知らないだけだと思う。
- 188 名前：仕様書無しさん mailto:sage [2007/02/15(木) 08:38:38 ]
- ttp://60.43.240.156/profile/index.html
↑DNSが反映されていない人向け
- 189 名前：仕様書無しさん mailto:sage [2007/02/15(木) 09:22:13 ]
- >>183
>昔は機械の性能が低くて「開発のし易さ＜実行時のパフォーマンス」だったのね。
>今は機械の性能が高いから適当にできる「開発のし易さ＞実行時のパフォーマンス」なのね。
違うよ、昔は開発規模が小さかったから高速化をしようとプログラム全体をチューニングできたが
今は開発規模が大きくなって、全てをチューニングしていたら何年かかっても完成にこぎ着けない、いつの間にか途中で妥協する事になるんだよ。
だからポイントを絞って高速化する必要があるし、高速化のための作業時間を捻出する必要があるの。
パフォーマンスの事ばかりをやっているとかえってパフォーマンスが下がる事に気づけ。
- 190 名前：仕様書無しさん mailto:sage [2007/02/15(木) 22:35:48 ]
- >>181>>188
こうだな
ttp://www.seeds-inc.jp/
ttp://60.43.240.156/index.html
↑DNSが反映されていない人向け
- 191 名前：仕様書無しさん mailto:sage [2007/02/15(木) 23:07:26 ]
- >>187
各タスクの動作順をいじる意味が全くわからない
長いことゲーＰＧやってるけどそんな需要は欠片もねぇ
- 192 名前：仕様書無しさん mailto:sage [2007/02/16(金) 00:49:26 ]
- それより動作順でバグが出る方がおかしいと思うよ。
- 193 名前：仕様書無しさん mailto:sage [2007/02/16(金) 01:05:33 ]
- まあ知能が低いみたいだからスルーで。
- 194 名前：仕様書無しさん mailto:sage [2007/02/16(金) 01:19:11 ]
- 擬似タスク＝クラス
擬似タスクは所詮クラスが無かった頃に、同じような機能をCで実現する為の仕組みでしかない。
ようは関数呼び出しの定型化と関数とデータのカプセル化、マルチプルインスタンスの実現を
Cでやる為に考え出されたテクニックに過ぎん。
いまさらタスクというやり方にこだわらなくても、各キャラごとのクラスを作って
シーンクラス内で処理すればまったく問題ない。
C++で組んでるくせにワザワザ、タスク処理を実装する奴がいまだにいるんだよな（激爆笑
そういう奴に限って枯れた技術マンセーとか慣れたやり方のがいいとか、ぬるい言い訳ばっかりしやがる。
…まぁ、俺のことなんだがな。
- 195 名前：仕様書無しさん mailto:sage [2007/02/16(金) 01:27:43 ]
- この流れを見て改心してくれたんなら、それはとてもうれしいことだ。
何事も完全に無駄ではないと言うことだな。
- 196 名前：仕様書無しさん mailto:sage [2007/02/16(金) 01:35:29 ]
- 動的にタスクを増やしたり親子構造にしたりできるようにすれば
タスクを名乗っててもあんま恥ずかしくないんでは。
- 197 名前：仕様書無しさん mailto:sage [2007/02/16(金) 01:45:30 ]
- 動的にインスタンスを作るのは普通にできるし
親子構造もテンプレートなりでツリー構造を実装すれば良い。
そろそろゲーム屋は擬似タスク（又は古典タスクシステム）という言葉の呪縛から脱却した方がいいと思うぞ。
- 198 名前：仕様書無しさん mailto:sage [2007/02/16(金) 01:50:17 ]
- 親子構造やツリー構造に名前をつければ解決すると思われ。
- 199 名前：仕様書無しさん mailto:sage [2007/02/16(金) 02:37:43 ]
- >>196 ダメ。ゼッタイ。
- 200 名前：仕様書無しさん mailto:sage [2007/02/16(金) 03:19:21 ]
- 魔流血多巣苦
- 201 名前：仕様書無しさん mailto:sage [2007/02/16(金) 07:10:01 ]
- >>192
壁とキャラの判定順が変わるだけですり抜けバグが多くなると思う。
- 202 名前：仕様書無しさん mailto:sage [2007/02/16(金) 11:03:18 ]
- 親子構造ってのがそもそも直感的ではなく、バグの温床になる。
ここはぜひとも、お兄ちゃんと妹構造 にすべき。
- 203 名前：仕様書無しさん mailto:sage [2007/02/16(金) 11:18:40 ]
- ワーク領域という発想の無かった俺には、天啓以外のなにものでもない。
- 204 名前：仕様書無しさん mailto:sage [2007/02/16(金) 11:32:51 ]
- >>199
ttp://www.dapc.or.jp/info/poster.htm
- 205 名前：仕様書無しさん mailto:sage [2007/02/16(金) 13:09:09 ]
- ネタが無いな。
AIについてでも語ってくれ。
- 206 名前：仕様書無しさん mailto:sage [2007/02/16(金) 13:25:31 ]
- >205
君のひとみに乾杯。
- 207 名前：仕様書無しさん mailto:sage [2007/02/16(金) 13:49:40 ]
- タスクはおいといて、ゲームのメインループってやっぱりステータスみてswitch文てのが一般的なん？
状態を変数で持つんじゃなくて評価関数を持たせる事でもっと柔軟に実装できるような気がするんだが。
たとえば色んな条件が組み合わさって、キャラの移動60%＋ジャンプ15%＋攻撃25%みたいなパラメーターを渡すと
処理の方でも渡された行動比率に従って、それぞれの処理をキャラクタの行動にフィードバックするみたいな。
たとえば通常の移動でも速度100がMAXってことにしておけば、それこそ一度処理しておくだけであとは計算の必要が無く
次回以降は比率を掛けて返すだけ。攻撃も同じで動作のモーションに対してパラメーターが渡されれば
あとは比率に応じてアニメパターンを適当に変更したり速度を変えたりするだけ。
キャラ間の干渉も比率の操作だけで住むので処理順序などに依存する必要も無く強固な構造が可能になる。
個別の処理は極力単純化しつつ、オブジェクト間の干渉度をパラメーター操作するだけで複雑な結果を作成する事ができる。
こういう風にすればゲームはもっと柔軟にプログラムすることが可能になるはず。
・・・とか妄想してみたんだが、やっぱ意味わかんねえよな。
実は俺もだ。
すまん。
- 208 名前：仕様書無しさん mailto:sage [2007/02/16(金) 14:11:32 ]
- >>207
最初の一行しか意味がわからんが、
> ゲームのメインループってやっぱりステータスみてswitch文てのが一般的なん？
C++ でそれは無い。 C でもやらない人が増えてるんじゃないの？
- 209 名前：仕様書無しさん mailto:sage [2007/02/16(金) 15:05:12 ]
- ＞C++でそれは無い。
そうか？stateパターンとか言いつつ実態はswitchで実装してるだけってのを見た事あるが・・・
＞最初の一行しか意味がわからんが、
なんか3Dでモーションをブレンドする時にパラメーターによって微妙に変化するじゃん。
そういうのを通常の処理に組み込めたら面白いなって思っただけなんだ。
キャラクタの行動やステータス変化など全てをパラメーターで操作できるようにしておいて、
外部からはパーセンテージのみでそれをいじくれて、ブレンドできたら面白いかなって。
たぶんデバッグで死ぬると思うが・・・
- 210 名前：仕様書無しさん mailto:sage [2007/02/16(金) 15:38:25 ]
- 別に長文で語るほどのことではないでしょ。
その程度のことはどこでも実装しているよ。
状態でswitchフラグだけのほうが不自然だわ。
- 211 名前：仕様書無しさん mailto:sage [2007/02/16(金) 16:17:54 ]
- >>209
ゲームでは高速化のためにブレンド比率の固定値をまわしてるだけだし、
そういうことを動的にするアプリって、モデリングソフトとかじゃまいか？
そういうゲーム作ってるってんなら星飛雄馬の姉ちゃんなみに草葉の陰から応援するけど。
- 212 名前：仕様書無しさん mailto:sage [2007/02/16(金) 16:40:35 ]
- ＞その程度のことはどこでも実装しているよ。
そうか？俺の知る限り、>>209のアイデアを形にしてるのって、「Spore」ぐらいなんだがな。しかもまだ製作中のハズ。
video.google.com/videoplay?docid=8372603330420559198
これをその程度とは・・・ハッ！？ウィルライト降臨か？
- 213 名前：211 mailto:sage [2007/02/16(金) 17:46:26 ]
- トゥイーニングがじゃなくって
その頂点がボーンマトリックスに対してどの程度ブレンドするか
を動的に設定できるようにするってんでしょ？
なんか仕事っぽいゲームしか想像できないｗ
- 214 名前：仕様書無しさん mailto:sage [2007/02/16(金) 23:03:57 ]
- 自分は、各処理毎にメイン(メッセージ)ループを持つかな。
各シーンで関係ない所を分岐チェックするのがじゃま。
- 215 名前：仕様書無しさん mailto:sage [2007/02/16(金) 23:09:15 ]
- うーん・・・そういうのもたまに見るけど、シーンの分岐チェックが嫌だからって
ループのコードが分散するのも無駄にコードが増えて美しくないような希ガス
- 216 名前：仕様書無しさん mailto:sage [2007/02/16(金) 23:39:24 ]
- 確かに、コードはかなり増える。
ただ例えば、昔のドラクエなんかだと、
戦闘中は戦闘中の事だけできればいいから、
フィールドコマンドの事には触れたくない。
戦闘ループに入る時に、味方の能力、敵の能力などの
必要なデータだけを渡し、戻り値で勝ち負けを返す感じにする。
ただ逆に、戦闘中にフィールドの情報、
例えば、水に居る時は水属性が有利になるとか、
拡張させる時に、めんどくさくなる場合もある。
- 217 名前：仕様書無しさん mailto:sage [2007/02/16(金) 23:52:20 ]
- 俺は個別にループを作る方が好きだな。
フラグのon/offが分散する方が嫌だ。
といっても好きに組めることはほとんどないし、さすがに慣れたけど。
- 218 名前：仕様書無しさん mailto:sage [2007/02/17(土) 00:12:36 ]
- おお、数少なき同士よ・・
自分は個人製作だから、共同の場合は、
switch型、個別loop型が向いているとかあるんかな。
- 219 名前：仕様書無しさん mailto:sage [2007/02/17(土) 00:40:18 ]
- >>218
個人と法人(共同開発)は、その部分に限らず別物だわさ。
手間よりも品質と分業効率が優先される。
- 220 名前：仕様書無しさん mailto:sage [2007/02/17(土) 00:59:33 ]
- 誰かが使ってくれると信じて作ってはみたものの、使われないクラスたち・・・
- 221 名前：仕様書無しさん mailto:sage [2007/02/17(土) 01:12:43 ]
- >>215
そういう時は関数の銘銘規則を見直して、関数の配置位置を整理してみるといいよ。
はー、最近自動リファクタになれてしまってリファクタつらい、自動リファクタツールが欲しい、C++のリファクタ面倒くせー
誰かー諸悪の根源プリプロセッサをぶっ潰してくれー
- 222 名前：仕様書無しさん mailto:sage [2007/02/17(土) 01:43:44 ]
- 必要のないものは親子構造から切り離す。
ツリー式のタスク作ればループ1個で必要なものだけを
処理できて幸せになるよ！
- 223 名前：仕様書無しさん mailto:sage [2007/02/17(土) 02:07:07 ]
- またNGワード出たな。
Stateパターンでいいだろ。適当に入れ子にして。
- 224 名前：仕様書無しさん mailto:sage [2007/02/17(土) 02:20:20 ]
- ループをいっぱい作ってるやつに言ってやれよ。
- 225 名前：仕様書無しさん mailto:sage [2007/02/17(土) 03:58:07 ]
-
これが秀逸だなｗ
ttp://www.youtube.com/watch?v=1R5hC217eBE
- 226 名前：仕様書無しさん mailto:sage [2007/02/17(土) 04:24:44 ]
- お前ら海外のゲーム作りの修行に行ってこい！
今の日本発のゲームの臭い事ったらねーぞ！
恥ずかしくなるだろ！おまえらも洋ゲープレイしてるとわかるだろ？和ゲーの陳腐さが！
- 227 名前：仕様書無しさん mailto:sage [2007/02/17(土) 04:48:40 ]
- 実は日本人が流出している罠
- 228 名前：仕様書無しさん mailto:sage [2007/02/17(土) 09:54:26 ]
- アメリカの大学でゲーム専攻の学位取りたいな。
どんな教育が受けれるのか見てみたい。
- 229 名前：仕様書無しさん mailto:sage [2007/02/17(土) 12:01:10 ]
- >>228
アメリカの大学でビデオゲーム関連の学科を卒業した連中と仕事をしていたが、
各人が個別のタスクシステムを持っていたぞ。
タスク管理、メモリ管理、タスク間通信等。どのプラットフォームでも対応できるって。
メーカーが提供するコードは信用できなから可能な限り使わない方向がはやりらしい。
日本の昔の人達がやっていることを海外の連中が今やっている感じではあるわな。
- 230 名前：仕様書無しさん mailto:sage [2007/02/17(土) 12:30:51 ]
- >>228
うわ、クセーなそれ。
ドロップアウトしたプログラマが教える側に立ってそう。
- 231 名前：230 mailto:sage [2007/02/17(土) 12:31:28 ]
- アンカー間違えた。 >>229 ね。
- 232 名前：仕様書無しさん mailto:sage [2007/02/17(土) 12:55:44 ]
- >>230 そこだけ聞くと日本のゲーム専門学校も同じような状況な訳だがｗ
- 233 名前：仕様書無しさん mailto:sage [2007/02/17(土) 14:01:52 ]
- どこかの記事に、ロクなこと教えてなくて無駄ってあった。
日本と変わらず。
- 234 名前：仕様書無しさん mailto:sage [2007/02/17(土) 14:15:12 ]
- カリフォルニア大学やらワシントン大学など名門校がゲーム専攻を導入し始めたのは最近だから、まだ指導体制やらカリキュラムがうまく確立してないのかもな。
将来はどうなるかわからんけど。
- 235 名前：仕様書無しさん mailto:sage [2007/02/17(土) 19:05:11 ]
- まあ、２プラットホーム以上経験すれば全部自前でそろえた方が
楽だと気がつくはず。
気がつかないのはそういう苦労をしてくれる神の元で楽に生きてるからだろう。
- 236 名前：仕様書無しさん [2007/02/17(土) 19:16:54 ]
- ゲームプログラマなんて余裕だろｗ
コナミでウイイレ作るかｗｗ
バスケゲームもいいなｗ
- 237 名前：仕様書無しさん mailto:sage [2007/02/17(土) 19:23:37 ]
- 上の方で擬似タスク云々の話が出てるけど、
擬似タスクでバグってる奴の多くはワンフレーム単位での矛盾が解決できて無い奴が多い。
ＳＴＧなんかで敵に弾があたったとして敵と弾のステータスの遷移を
次のフレームに持ち越すような設計になってることが多い。
そういうことを一つ一つ解決していけば擬似タスクでも問題は無いかもしれない。
この問題はswitch文の連発で作った場合でも下手糞だと起こるが
switch文で作った方が楽という結論を出した奴の多くはこの問題の本質が見えている。
擬似タスクで作ったときに一番頭に入れて置かなきゃいけないのは複数の物が絡んだときの
状態遷移をどこで行うか？っていうところだ。
これを管理できてる奴とできてない奴でできるもんの質が全く違うものになる。
- 238 名前：仕様書無しさん mailto:sage [2007/02/17(土) 19:40:37 ]
- だからそれは擬似タスクやswitch文とは関係のない話で
ちゃんと処理の流れを理解してて、バグになりそうな部分を意識しつつ
コードを設計していればどんな組み方だろうが何の問題もない。
それをタスクだとかswitch制御だとかコルーチンだとかの手法のせいにするのが
そもそもの間違い。自分がよく分からなくてメインプログラマやネットで拾った
やりかたをなんとなく使いまわしているからバグが頻発する。
キチンと設計し、コードの隅々まで目を通し、動作を理解しろ。
それをキッチリやった上で手法の良し悪しについて議論するのなら意味があるが。
- 239 名前：仕様書無しさん mailto:sage [2007/02/17(土) 19:42:35 ]
- 間違いを起こしにくい設計もあるんじゃないかと。
動きゃいいってのは、なにかとても素人くさい。
- 240 名前：仕様書無しさん mailto:sage [2007/02/17(土) 19:48:48 ]
- >>239
だよな。
擬似タスク使う奴の多くってのは追加物増やしたときに
それをメインのループに組み込む＝メインのプログラムを変更するのを嫌って（どっちかというと面倒とかそういうの）
そういう設計にする奴が多いように見える。
しかし、この怠惰が状態管理も怠り、バグを生んでるように見える。
直接の原因は擬似タスクではないかもしれんが、引き金になってしまってる面はある。
特に擬似タスク以外の組み方を知らないって奴はまずいと思う。
一度switch文の連発で組んでみることをオススメする。
- 241 名前：仕様書無しさん mailto:sage [2007/02/17(土) 19:56:33 ]
- >>240
君は知能が低い上に視野も狭い。中２病ってやつ？
- 242 名前：仕様書無しさん mailto:sage [2007/02/17(土) 19:56:45 ]
- >>240
メインのプログラムを変更するのを嫌うのはただの怠惰じゃなくて、
単純に影響範囲が違うんだから当然だろう。
- 243 名前：仕様書無しさん mailto:sage [2007/02/17(土) 20:12:18 ]
- >>242
でも、実際はする必要があるのにしないってのがまずいポイントじゃん。
明らかにする必要があるんだよ。
だって、敵と弾があたって出る爆発クラスのインスタンスやら衝突イベントは
敵クラスにも弾クラスにも属さない別のクラスにいるべきなんだから。
まあ、この問題について詳しく語りたいわけじゃないけど、
追加したタスク（クラス？）だけで解決しようってのがそもそもの間違いなのに
それを考えずに・・・って状況があると思うんだよね。
- 244 名前：仕様書無しさん mailto:sage [2007/02/17(土) 20:13:44 ]
- 誰か置いてけぼりの俺に"擬似タスク"ってなんなのか説明してくんない？何が擬似なんだ？
- 245 名前：仕様書無しさん mailto:sage [2007/02/17(土) 20:16:27 ]
- >>244
スレをはじめから読むなりなんなりしてくれ。
いわゆる普通のタスクとはちょっと性質が違うので現場でぶち当たった奴にしかわからんと思う。
- 246 名前：仕様書無しさん mailto:sage [2007/02/17(土) 20:32:39 ]
- ふと思ったんだが、擬似マルチタスクの擬似？
e-words.jp/w/E693ACE4BCBCE3839EE383ABE38381E382BFE382B9E382AF.html
- 247 名前：仕様書無しさん mailto:sage [2007/02/17(土) 20:41:04 ]
- >>243
アホなお前にも分るようにオレが作ってた例をあげてやろう。
自機管理タスク
敵管理タスク
敵弾管理タスク
爆発管理タスク
各種タスク生成タスク
各種タスク削除タスク
描画タスク
なんか処理を増やしたいならタスクを増やせばいいだけ。
アイテム制御タスクとかな。
あーくだらねぇ。知恵遅れは道具の使い方に工夫がない。
- 248 名前：仕様書無しさん mailto:sage [2007/02/17(土) 20:52:43 ]
- おさらいだが、
コメントがある >>>> 越えられない壁 >> すごい処理 > しょぼい処理
ということだな。
- 249 名前：仕様書無しさん mailto:sage [2007/02/17(土) 20:54:11 ]
- 他人を知恵遅れとか罵倒しなきゃならない時点で説得力0。
- 250 名前：仕様書無しさん mailto:sage [2007/02/17(土) 20:58:12 ]
- >>243
新しいクラスを作るのは必要に応じてやればいいが、それが
メイン（メインループ）のコードをいじるのと直結していると、
些細な変更でプログラム全体に影響が広がる可能性が高いので
バグを抑えるという観点からするととても良くない。
- 251 名前：仕様書無しさん [2007/02/17(土) 21:09:15 ]
- >>247
え？俺の言ってることの１％も理解できてないじゃん。
タスクの生成はいいけどさ、それをどこでやるか？って話だよ。
敵と弾の当り処理をどこに書いてる？
- 252 名前：仕様書無しさん mailto:sage [2007/02/17(土) 21:34:11 ]
- 敵と弾の当たり処理タスク
- 253 名前：仕様書無しさん mailto:sage [2007/02/17(土) 22:02:43 ]
- >>252
それだな。それが>>247には無い。
>>243の内容が理解できているなら真っ先に書いてしかるべきなのに無い。
こいつの組むプログラムには本当に無いんだろうな。
この辺の違いがバグを出す奴と出さない奴との差なんだろうな。
それと敵と弾の当り処理タスクなんて本当にこの形でもっといた方がいいもんなのか？
爆発タスクって当りタスクの後に動かさないとまずいよね？
それともその処理は次のフレームに持ち越すんだろうか？（俺はこれを許さないが）
俺には複雑過ぎて制御はできそうにないな。＞擬似タスク
- 254 名前：仕様書無しさん mailto:sage [2007/02/17(土) 22:05:03 ]
- 弾が持つに気まってんだら
- 255 名前：仕様書無しさん mailto:sage [2007/02/17(土) 22:09:40 ]
- >>254
なんかおかしくね？
- 256 名前：仕様書無しさん mailto:sage [2007/02/17(土) 23:27:48 ]
- おまいら>>3-4嫁。
そもそも「擬似タスク」への理解が統一されてないのに釣られすぎ。
これはもう、「疑似餌タスク」と呼んだ方がいいなｗ
- 257 名前：仕様書無しさん mailto:sage [2007/02/17(土) 23:38:24 ]
- >>253
仮にSTGだとしてループでやるとしたら大まかに↓みたいな感じじゃないか？
仕事でSTG作った事無いから思いつきでしかないけど。
ループ{
キー入力
敵出現管理
自機移動＆弾発射 敵移動＆弾発射
弾移動
自機＆敵＆弾 相互の衝突突判定
自機＆敵＆弾位置補正
爆発
オブジェクト消滅管理
描画
}
- 258 名前：仕様書無しさん mailto:sage [2007/02/17(土) 23:41:17 ]
- >>257
まあ、よくみとらんからそれが正しいかはわからんけど、順序は固定だよね。
擬似タスクな人はなんでタスクにすんだろね？
なんか実行順序変えることに意味があるのかな？
- 259 名前：仕様書無しさん mailto:sage [2007/02/17(土) 23:49:00 ]
- タスクにすると順序が変わるとか言ってるのは釣り？
- 260 名前：仕様書無しさん mailto:sage [2007/02/17(土) 23:51:34 ]
- >>258
一元管理できるからじゃないかな。
- 261 名前：仕様書無しさん mailto:sage [2007/02/17(土) 23:53:23 ]
- 関連が多くなればなるほどタスク作りまくるみたいだけど
やっぱりバグりそうだよな。
発生した爆発で特定の弾を消すなんてなったらまたタスク作るのか？
- 262 名前：仕様書無しさん mailto:sage [2007/02/17(土) 23:54:56 ]
- >>259
絶対に固定なのに実行順序を変えることができる仕組みをわざわざ作ってることに意味が見出せ無いってだけ。
バグも多くなる部分だし、単純にやらないほうがいいじゃないか。
- 263 名前：仕様書無しさん mailto:sage [2007/02/17(土) 23:56:11 ]
- >>260
どうやってだよ・・・。
もうこの時点で実行順序は固定だし一元管理できてる部分なんてないじゃんよ。
- 264 名前：仕様書無しさん mailto:sage [2007/02/18(日) 00:04:57 ]
- そもそもなんでタスク分けするのか考えてないんだろ
- 265 名前：仕様書無しさん mailto:sage [2007/02/18(日) 00:10:37 ]
- >>263
キー入力、敵１体ずつ、弾個ずつ、時機それぞれをタスクにすればおｋ。
- 266 名前：仕様書無しさん mailto:sage [2007/02/18(日) 00:10:45 ]
- >>263 擬似タスクという枠に嵌め込む事で、生成と消滅を一箇所で行えるという利点はある。＞一元管理
ただ、擬似タスクという仕組みを今更作る必然性は全く無い。ゼロ。無駄。忘れて良し。
描画クラス用と実行用クラス用の中傷クラス作って紐付ければよいだけ。
- 267 名前：仕様書無しさん mailto:sage [2007/02/18(日) 00:15:08 ]
- >>262
お前が３Ｄのゲーム作ると、処理が先に行われる、視界の奥にあるオブジェクトが手前に描画されそうだな。
- 268 名前：仕様書無しさん mailto:sage [2007/02/18(日) 00:15:53 ]
- >266だが、スマン。一個だけ擬似タスクシステムを使う必然性というか利点があった。
「昔からのプログラマと話すときに共通言語として擬似タスクという言葉を使うと話が早い。」
これだけ。
なので、自分の場合は普通に作ってても、クラス名を○×Taskとするようにしてる。
- 269 名前：仕様書無しさん mailto:sage [2007/02/18(日) 00:18:24 ]
- >>267
つ[Zバッファ]
- 270 名前：仕様書無しさん mailto:sage [2007/02/18(日) 00:23:38 ]
- >>267
タスクの実行順序と描画の優先度は別じゃないか･･･
- 271 名前：仕様書無しさん mailto:sage [2007/02/18(日) 00:40:20 ]
- ところでタスクってなに？
自分は各要素(自機、敵機など)をMainメソッド(更新処理)とDrawメソッド(描画処理)に
分けてそれぞれ処理してるけど、これじゃだめですか？
タイトルシーンやゲームシーンの分け方は、基底シーンクラスを継承したものをそれぞれ作ってる。
- 272 名前：仕様書無しさん mailto:sage [2007/02/18(日) 00:49:22 ]
- >>271 気にするな。それでいい。
- 273 名前：仕様書無しさん mailto:sage [2007/02/18(日) 00:58:35 ]
- >>271
それを体系化したものの通称がタスクシステム
- 274 名前：仕様書無しさん mailto:sage [2007/02/18(日) 01:43:55 ]
- 体系化というより会社ごとPGごとの方言が多すぎて収集つかなくなってるけどなｗ
- 275 名前：247 mailto:sage [2007/02/18(日) 01:51:18 ]
- 衝突判定がないからダメときたか。
必要なら増やせばいいと書いてあるのに。
結論ありきで語ってるやつはすぐ論理が破綻するし
会話もなりたたねーからウザイ。
こういうやつの肩もってるやつは自演だと信じたいよまったく。
知能が低いにもほどがあるわ。
- 276 名前：仕様書無しさん mailto:sage [2007/02/18(日) 02:06:27 ]
- スマン、誰に向かっての発言かわからんのでアンカー付けてくれ。
- 277 名前：仕様書無しさん [2007/02/18(日) 02:35:25 ]
- >>275
だってお前のは必要なことが書いてなかったじゃないｗ
後だしジャンケンで正当化する前にやることしっかりやっときなよ。
プロの仕事じゃないね。バイバイ。用無しｗ
|
 |
