ゲームプログラマの人に聞きたい 23問目

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/ 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 だってお前のは必要なことが書いてなかったじゃないｗ 後だしジャンケンで正当化する前にやることしっかりやっときなよ。 プロの仕事じゃないね。バイバイ。用無しｗ 278 名前：仕様書無しさん [2007/02/18(日) 02:38:38 ] PCゲーであるエロゲなどのプログラムを書き換えて ディスクレス化や主人公の名前を書き換えたりとかしてみたいのですが どこでどんな勉強をすればいいですか？ できたらネットで勉強したいのですが。 279 名前：仕様書無しさん mailto:sage [2007/02/18(日) 02:44:36 ] 次からタスクで議論する奴は↓のどれを指すか宣言してくんない？擬似タスクとか意味わかんねーし。 A. プロセス B. プリエンプティブスレッド (非同期にコンテキストスイッチするもの) C. ノンプリエンプティブスレッド (明示的にコンテストスイッチするもの) (==Fiber/コルーチン) D. C++のクラスにupdate/draw関数を付けてリストで繋いだもの 280 名前：仕様書無しさん mailto:sage [2007/02/18(日) 02:45:37 ] >>278 まずは対象のゲームのライセンスをよく読むこと。 そのうえで以下のような知識が必要になるだろう。 ・バイナリエディタの使い方 ・Visual Studio などに付属のデバッガの使い方 ・Windows API ・使ってる CPU について 　・アーキテクチャ 　・マシンコード 　・逆アセンブラの使い方 281 名前：仕様書無しさん mailto:sage [2007/02/18(日) 02:46:56 ] >>279 それらのうちのどれを指すとしても、そもそも「タスク」なんて言葉を 使う必要が無いと思うんだが。 282 名前：仕様書無しさん mailto:sage [2007/02/18(日) 02:52:31 ] >>280 ありがとうございました。 283 名前：仕様書無しさん mailto:sage [2007/02/18(日) 02:54:01 ] 歴史的経緯によりあえてタスクという名称を使用する事になっておりますｗ 284 名前：仕様書無しさん mailto:sage [2007/02/18(日) 03:01:11 ] >>281 タスクって用語を使う人間に、じゃぁお前の言うタスクってどんなのなのさ？と 尋ねるよりは、この中のどれよ？と選ばせる方がまともな回答が得られるかと思ってね。 実際プロセスをタスクと呼ぶような組み込みもどきな人間ばかりじゃなくなってるし そろそろなくしたほうがいい用語だと思うけど、なくならねーだろうなぁ・・・。 285 名前：仕様書無しさん mailto:sage [2007/02/18(日) 03:08:42 ] だから、擬似タスクといわゆる普通のタスクは全然似てないんだってｗ 286 名前：仕様書無しさん mailto:sage [2007/02/18(日) 03:10:00 ] インド人とインドネシア人みたいなもんだよｗ 287 名前：仕様書無しさん mailto:sage [2007/02/18(日) 04:44:02 ] エヴァンゲリオンがリメイクされるみたいですね 288 名前：仕様書無しさん mailto:sage [2007/02/18(日) 07:52:13 ] >>279 Ｂがスレッド、Ｃがタスク、Ｄが擬似タスクだと思ってた。 289 名前：仕様書無しさん mailto:sage [2007/02/18(日) 11:26:36 ] Dのやり方なんて名前付けるほど大それたもんじゃねーと思うのだが デザパタと一緒で名前をつけるのは意思疎通するために必要なんだなと このスレ読んでて改めて感じた久々の休日 290 名前：仕様書無しさん mailto:sage [2007/02/18(日) 11:35:41 ] 意思疎通しようと思って擬似タスクを話題にした結果がこの有様ですよｗ 291 名前：仕様書無しさん mailto:sage [2007/02/18(日) 11:44:26 ] 俺もそれでいいと思うよ、いまさらタスク・タスク言い続けるのもどうかと思うし。 すでに分かりやすい概念が色々考えられているのだから、古いやり方に拘らずそちらにしてしまったほうが良いと思う。 ただ関数の銘銘に関しては Main より Update 等にしたほうが良いだろうな、Mainではどういう機能をもっているのかハッキリしない。 もう360のATGライブラリでもそういうタスククラス採用されていないだろ。 その内コンポーネントとか呼ばれるようになるんじゃないか。 292 名前：仕様書無しさん mailto:sage [2007/02/18(日) 11:45:20 ] >>291 アンカー書き忘れ >>271

---

---

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

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