[過去ﾛｸﾞ]
ゲームにおけるデータ構造・クラス設計・パターン2 (627ﾚｽ)
ゲームにおけるデータ構造・クラス設計・パターン2 http://mevius.5ch.net/test/read.cgi/gamedev/1211544659/
上
下
前次
1-
新
通常表示
512ﾊﾞｲﾄ分割
ﾚｽ栞
抽出解除
必死ﾁｪｯｶｰ(本家)
(べ)
自ID
ﾚｽ栞
あぼーん
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索
歴削→次ｽﾚ
栞削→次ｽﾚ
過去ﾛｸﾞﾒﾆｭｰ
429: 名前は開発中のものです。 [sage] 2009/01/22(木) 00:12:28 ID:P249I5A7 ステージ情報の管理。 これを管理するクラスを一つ作る。主なデータとしては 敵出現データ情報（背景出現情報)、ランダムシード、ステージ進行速度。ついでに入力情報の蓄積もここがやると見通しがいいかも。 基本的に言語そのままでは出現情報は記述しづらいので適当なスクリプトを自作する。 wait、enemy、background、musicがあれば十分。 ボス戦手前などに掛け合いをはさむなら、event命令もあるといい。 簡単に変更できるようにすることを考えると、命令を分岐、並列に記述できる文法があると便利。 (waitによる相対時間出現なので。現在の出現配置を維持しつつ追加したいときとか。) この方法は読んだ人は気づいてると思うけど、ある本を参考にしました。 http://mevius.5ch.net/test/read.cgi/gamedev/1211544659/429
430: 名前は開発中のものです。 [sage] 2009/01/22(木) 00:45:44 ID:P249I5A7 で、今は あるオブジェクトの変数に依存するオブジェクトの管理、依存方法。(耐久力表示、バリア、レーザーなど。) ・依存オブジェクトの生成は、被依存が関わってくるのでそれの参照を取得する方法は深く考える必要はない。 ・完全な対応関係ならば、依存オブジェクトは被依存オブジェクトをその型で参照を保持する。 (スーパークラスで保持する必要性がない。被依存側の、依存側で必要なメンバはpublicにする。) ・逆に、誘導弾やエフェクトなどは被依存をスーパークラスで参照を保持する。 >>428で生存判定がインタフェースにいるので、ここら辺は融通が利く。 http://mevius.5ch.net/test/read.cgi/gamedev/1211544659/430
431: 名前は開発中のものです。 [sage] 2009/01/22(木) 00:57:55 ID:P249I5A7 オブジェクト同士の衝突判定の記述。衝突判定まで。 ・複数の矩形で衝突判定を処理するオブジェクトがいることが想定される(ボスなど。) →バウンディングボックスも実装。 ・後々考えると、回転可能な矩形判定が後腐れない。 →バウンディングサークルにしといた方が、記述の割りに回転に対応できる。 衝突判定データを保持するクラスを作って、オブジェクトは衝突判定データのインスタンスをリスト構造(場合によっては木構造)で保持。がいい感じ。 オブジェクトを2つ受け取り、それの衝突判定を走査する、という処理を行う関数をつくればいい。 誘導弾などの実装、は思案中。いい感じが思いつかない。 http://mevius.5ch.net/test/read.cgi/gamedev/1211544659/431
433: 名前は開発中のものです。 [sage] 2009/01/22(木) 04:40:32 ID:P249I5A7 >>432 サンクス。こんな考え方があったのか 言われてみれば、作り始めたての頃は○○Managerや○○Dataはかなりいた気がする。 今は1個だけしかいないところを見ると(UpdateManager)、自然とどうやら身についてはいるっぽい。 http://mevius.5ch.net/test/read.cgi/gamedev/1211544659/433
ﾒﾓ帳
(0/65535文字)
上
下
前次
1-
新
書
関
写
板
覧
索
設
栞
歴
ｽﾚ情報
赤ﾚｽ抽出
画像ﾚｽ抽出
歴の未読ｽﾚ
AAｻﾑﾈｲﾙ
Google検索
Wikipedia
ぬこの手
ぬこTOP
0.025s