- 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/
- 153 名前：仕様書無しさん mailto:sage [2007/02/14(水) 20:52:34 ]
- 「うちはオブジェクト指向のタスクシステム」とかいうところにヘルプにいったら、
無駄に仮想関数使いまくりだったりダイナミックキャストの嵐でパフォーマンスが
ぼろぼろ（ステージ途中でインスタンス作りまくりのおまけつき）、
しかもタスクシステムのリソース開放タイミング管理が甘くて、ぬるぽとメモリリークの嵐で後始末が大変でした。
- 154 名前：仕様書無しさん mailto:sage [2007/02/14(水) 20:57:29 ]
- >>149
それは言い訳ジャマイカ。
システム組んだ奴や使ってる奴が糞ならどんなやり方でもバグは出るだろうに。
>>150
参考までに聞きたいんだが、そのメインルーチンから呼び出す単純な方式って奴で
複数のキャラが非同期に生まれたり死んだり、お互いに干渉するようなケースって
普通に多いと思うけど、そんな場合はどういう風に組むのが正解だと思う？
俺は昔の人なのでタスク風の書き方以外知らないんだよ。
つーかマジで教えてください、たのんます・・・
- 155 名前：仕様書無しさん mailto:sage [2007/02/14(水) 21:03:05 ]
- >>153
馬鹿が使うとそうなる
- 156 名前：仕様書無しさん mailto:sage [2007/02/14(水) 21:07:32 ]
- >>154
ゲームと関係無い。
普通にプログラムの能力が低いと思う。
- 157 名前：仕様書無しさん mailto:sage [2007/02/14(水) 21:12:56 ]
- いまどきの組み込みはX68000よりはるかに速いから
サブルーチンコール程度でグダグダ言わない。
- 158 名前：仕様書無しさん mailto:sage [2007/02/14(水) 21:23:14 ]
- >>154
普通はキャラクラスとか敵弾クラスとか地形処理クラスとか作ってメインループから呼び出すんじゃね？
タスクなんて処理作らなくてもいけると思う。キチンと設計すれ。
- 159 名前：仕様書無しさん mailto:sage [2007/02/14(水) 21:44:04 ]
- CPUの仕組みを理解すればメインだけに全部いれようが
タスクにしようがサブルーチンにしようが違いはないということがわかると思うが。
人間のための仕組みですよ。
- 160 名前：仕様書無しさん mailto:sage [2007/02/14(水) 22:26:17 ]
- >>154
>メインルーチンから呼び出す単純な方式
1.状態の数だけenumでswitch
2.状態の数だけ関数ポインタ
3.デザパタのステートパターン
4.有限状態遷移機械(FSM)でデータドリブン
- 161 名前：仕様書無しさん mailto:sage [2007/02/14(水) 22:41:39 ]
- タスクシステムとかおなかいっぱい('A`)
別に好きなように組めばいいじゃん。
いい加減、細かい処理を自前でset→long jumpとかもうそんな時代じゃないの気づけよｗ
OpenMP でガシガシ書いたほうがはるかに効率いいっつーの。
- 162 名前：仕様書無しさん mailto:sage [2007/02/14(水) 22:58:26 ]
- 擬似タスクとマジタスクが混じってる予感。
- 163 名前：仕様書無しさん mailto:sage [2007/02/14(水) 23:03:20 ]
- マジタスクってPCとスタックが復帰するやつのことですか？
- 164 名前：仕様書無しさん mailto:sage [2007/02/14(水) 23:18:37 ]
- >>160
１．ありがちだが、これだとシーンの遷移程度にしか使えんだろ。複数キャラを効率よく動かすのには別の仕組みが必要では？
２．これもよく見るけど、微妙にデバッガで追いづらい。
あと、ポインタが破壊されたらあっという間に再現しづらいバグに変化するよな。
つーか、今時関数ポインタとか古臭いよ。
３．オサレに名前を変えただけで本質的には１と変わらんよなｗ
４．データによって変化するという事はコードだけでは処理の流れが追えなくなる。
元データをそのまま使う場合はまだマシだけど、データの内容によって流れが変化するような仕様にすると（そういうケースは多いが）とたんにバグだらけ。しかも再現させずらい最悪のパターンに陥りやすい。
なんかもっとこう、スマートでエレガントでオサレでぬるぽな実装は無いのか？
- 165 名前：仕様書無しさん mailto:sage [2007/02/14(水) 23:23:59 ]
- 関数ポインタは古いのか・・
- 166 名前：仕様書無しさん mailto:sage [2007/02/14(水) 23:29:30 ]
- Gems3に関数ポインタをWrapしたtemplateクラス使った状態遷移マシンのネタがあったな。
なぜかツボにハマってそれ使わせてもらってる。
- 167 名前：仕様書無しさん mailto:sage [2007/02/14(水) 23:48:02 ]
- 個人的にhotateのページの擬似タスクのテンプレートクラス版使ってるけど
集団で作る時は、メインの人がC++好きか嫌いかで
クラスの擬似タスクか構造体の擬似タスクかのどちらかになってる。
どっちにしても関数ポインタとメモリ管理の安全がミソのコーディング手法だけど。
仕事で初めて見た時、C++の擬似タスクだったけど、これが有名な擬似タスクですね、って言っても
メインの人が「？」って感じの返答してたから。通称が無いのかもしれん。
自分は Hotate's Core とかいうホームページで実装方法知ってその人が”擬似タスク”と言ってたからそう覚えてる。
- 168 名前：仕様書無しさん mailto:sage [2007/02/14(水) 23:58:54 ]
- >>164
１と３は全然違う。１だとメイン側が状態の数を全部知ってる必要があるんで、
状態が増えるたびにメイン側をいじる必要がある。
関数ポインタがデバッガで追いづらいって、仮想関数も同じ理由で使わなかったりするの？
- 169 名前：仕様書無しさん mailto:sage [2007/02/15(木) 00:01:32 ]
- ぐぐってみたが、Hotate's Coreって無くなってるね。
- 170 名前：仕様書無しさん mailto:sage [2007/02/15(木) 00:10:06 ]
- >>167
どうせ抽象クラス（へのポインタ）をコンテナに突っ込めばできあがりな構造だろ。
NGワードを持ち出してまでひとくくりにする必要は無いと思われ。
- 171 名前：仕様書無しさん mailto:sage [2007/02/15(木) 00:13:34 ]
- >>167
５年以上前の過去ログにぴったりなレスを見つけて
面白いというか、悲しいというか変な気分になった。
pc.2ch.net/tech/kako/985/985540361.html
ここの 150 ね。
- 172 名前：仕様書無しさん mailto:sage [2007/02/15(木) 00:18:02 ]
- 最近自分のwindowsはこんな↓
メッセージスレッド（メインループ）
計算スレッド（座標ヒットチェックとか入力判定とか）
描画スレッド
サウンドスレッド（DirectSoundのおかげでほされそう）
通信スレッド
各スレッドが擬似タスクにクリティカルセクションでアクセスする感じ。
- 173 名前：仕様書無しさん mailto:sage [2007/02/15(木) 00:26:51 ]
- >>171 そのスレの65-68とか128-165とかのレスを読んでたら全米が泣（ｒｙ
2001年時点から全然進歩してねーのな、おまいら。
たぶんもっと前から同じ議論が繰り返されてるんだろうなぁ。
こりゃ日本のゲームが衰退するはずだわｗ
- 174 名前：仕様書無しさん mailto:sage [2007/02/15(木) 00:27:55 ]
-
トップクリエイターが福岡に集結！「Game for Future 2007」イベント開催！
ttp://www.gff.jp/newsDetail.php?key=20070201-020011-ip-test01-ip-t
- 175 名前：仕様書無しさん mailto:sage [2007/02/15(木) 00:54:44 ]
- まあカプコンがまだタスクとか言ってるんだから大丈夫だろ。
- 176 名前：仕様書無しさん mailto:sage [2007/02/15(木) 01:03:10 ]
- >>164
> なんかもっとこう、スマートでエレガントでオサレでぬるぽな実装は無いのか？
>160とFiberで満足できなけりゃあとはSchemeの継続でもやってくれと言うしかないね。
ゲームの状態遷移なんてその場限りの使い捨てなんだからswitchかFiberの
汚くなりやすいが軽量な手法が向いてるんじゃないかと思うけど。
- 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の内容が理解できているなら真っ先に書いてしかるべきなのに無い。
こいつの組むプログラムには本当に無いんだろうな。
この辺の違いがバグを出す奴と出さない奴との差なんだろうな。
それと敵と弾の当り処理タスクなんて本当にこの形でもっといた方がいいもんなのか？
爆発タスクって当りタスクの後に動かさないとまずいよね？
それともその処理は次のフレームに持ち越すんだろうか？（俺はこれを許さないが）
俺には複雑過ぎて制御はできそうにないな。＞擬似タスク
|
 |
