[過去ﾛｸﾞ] ゲームにおけるデータ構造・クラス設計・パターン2 (627ﾚｽ)
上下前次1-新
抽出解除 必死ﾁｪｯｶｰ(本家) (べ) 自ID ﾚｽ栞 あぼーん
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
135(1): 2008/07/06(日)16:49 ID:NhLrwJLQ(1/4) AAS
おかしな奴の言い分もわかるぜ
日本の企業は総じて、コミュニケーション能力だのなんだの
わけのわからない能力やノウハウを好んでそれを要求するくせに
それらを他人に教えるようなことはしないからな、ヒントすらも
異常なほど排他的だ
数年前に某大作RPGの下請けの社長様が
「3Dできる奴なんて腐るほどいる死ね、コミュニケーション能力のない奴は死ね」(意訳)
省2
137: 2008/07/06(日)17:06 ID:NhLrwJLQ(2/4) AAS
ほらクソども設計について語れや
レイヤスーパータイプは
class Devicer { static Device device; }
で、スーパークラスとしてDevicerを使うことだ覚えとけ
Application Controllerは
class AP {
View GetView(入力と状態値);
省5
140(1): 2008/07/06(日)22:41 ID:NhLrwJLQ(3/4) AAS
シーン遷移をきれいに実装したいという話なら、俺は否定するぞ
ジャンルにもよるが大抵のゲームで使うシーンは、多くてもせいぜい十にも満たない数だ
この規模の小さい状態遷移を、そのまま適当に実装してもとくに肥大しない
後で追加が頻繁に発生するとも思えない、適当に修正しても特に難しくはならない
こういう部分に、色々な知恵を絞ったコードを書くことに意味はない
逆にそのクラスの為に他の部分にしわ寄せが行って、
難しいロジック部分や画面描画部分に関係のないシーン遷移のコードが入り込む
省3
142: 2008/07/06(日)23:34 ID:NhLrwJLQ(4/4) AAS
>>141
同感だ
そういう箇所に擬似コルーチンを使ってる
前はState使ってたが、あれは追加には強いが変更に弱いな、複雑になって死んだ
単純ならそのまま状態変数で適当に書いてもいいが
コルーチンのほうが書いてて楽しいな
上下前次1-新書関写板覧索設栞歴
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.018s