ゴミ箱.net

汚物は消毒

ゲーム製作日記4 衝突判定

道具立ても揃ったことだし、そろそろ実装に入るとするか。
はじめにゲーム作りの基礎ともいえる衝突判定の実装をすることにする。

ゲームが実世界の挙動をそれなりに再現してくれるのは大部分が衝突判定のおかげといっても過言ではない。
地面とプレイヤーキャラが衝突するから、プレイヤーは地面や足場をすり抜けずに立っていられたり、壁をすり抜けるなどの非現実的な挙動をしなくてすんだりする。
格闘ゲームで敵を攻撃したり敵から攻撃を食らったりするのも、自分がダメージを食らう領域と相手が攻撃を仕掛ける領域が衝突するからである。
さらには3次元空間で物体が物に隠れて見えなくなるのも、視線と物体の衝突を判定できてこそだ。

今回は昔ながらの2次元グラフィックスを使うので、2次元空間での領域どうしの衝突判定を考えよう。

領域といっても、直線や矩形、多角形、円などいろいろある。さらに、たとえば地形のようにそれらが複雑に組み合わさってできている領域もある。
領域の判定は基本的に数式で表せるが、図形ごとにその式はまったく異なるものになる。たとえば円どうしであれば「中心間の距離<半径の和」と表すことができるが、直線どうしの交差判定ではまったく異なる式になる。それをなるべく統合的に扱えるようにしたい。
こういう場合はオブジェクト指向的な考え方が非常にしっくりくる。

「領域」という抽象クラスを作成し、その抽象クラスは他の領域との衝突を判定するメソッドを外部に公開する。
そして、直線、矩形、多角形、…といった具体的な領域は抽象クラス「領域」を継承し、それぞれが他の領域との衝突を判定するメソッドを個別に実装する。

以下はインターフェースを使ったコードの例である。

interface IRegion {
bool Collides(IRegion other);
}

class Rectangle : IRegion {
bool Collides(IRegion other) {
//具体的な計算をする
}
}


また、抽象クラス「領域」を継承するクラスとして「領域を複数組み合わせた領域」というものを考えると、基本的な領域の組み合わせで複雑な領域も表現することができ、表現力がぐっと高まる。デザインパターンの1つ、容器と中身を同一視するCompositeパターンだ。
判定条件としては「組み合わせを構成する領域のいずれかが相手の領域と衝突している」というシンプルなものになる。

ただ、この実装方法にはちょっとした問題点がある。異なる種類の領域どうしについて、いったい誰が計算の責任を持つかという点である。円と矩形の衝突判定なら、クラス「円」とクラス「矩形」のどちらに計算をさせるべきか?それとも第三者が計算を担当したほうがいいのか?
スポンサーサイト

PageTop

コメント


管理者にだけ表示を許可する
 

トラックバック

トラックバック URL
この記事にトラックバックする(FC2ブログユーザー)

まとめteみた.【ゲーム製作日記4 衝突判定】

道具立ても揃ったことだし、そろそろ実装に入るとするか。はじめにゲーム作りの基礎ともいえる衝突判定も過言ではない。地面とプレイヤーキャラが衝突するから、プレイヤーは地面や足場をすり抜けずに立っていられたりゲームで敵を攻撃したり敵から攻撃を食らったりするの...

まとめwoネタ速suru 2012-04-11 (Wed) 01:00