ゲームの当たり判定のクラス設計を考えてみる

アクション系やシューティングゲームを作っていく上でほぼ必ずといっていいほどぶち当たるのが当たり判定(コリジョン)です。

フィールドに複数のキャラクターが存在するときは、衝突し得るキャラクター同士すべてで当たり判定処理を行う必要があります。
しかしながら、この当たり判定処理はキャラクターの数が増えるほど重くなります。
したがって、不要なキャラクター同士との当たり判定はしないように工夫する必要があります。

今回はこれらの当たり判定処理を管理するためのクラス設計について考えてみました。

キャラクタには円形や四角形などさまざまな形状のキャラクタが存在すると思います。
地形も平面な形状のキャラクタと捉えることが出来るかもしれません。

形状を保持するクラスの例です。

円と長方形が存在した場合は上記のように円と長方形の形状クラスを基底の形状クラスから派生させます。

形状同士の当たり判定の計算は、形状の組み合わせによって違ってきます。
上の例では、円と長方形が存在するので、円と円、円と長方形、長方形と長方形の3種類の当たり判定計算が存在します。
当たり判定計算も形状クラス同様に基底クラスから派生させます。

そして、任意の形状のキャラクタ同士との当たり判定を行うクラスを実装します。

もっとスマートなやり方があると思いますが(涙)、ひとまずこのような感じになります。

形状の種類に応じた当たり判定の計算は、当たり判定テーブル(m_colTable)で管理しています。
s1.GetType()、s2.GetType()の戻り値からオブジェクトの形状の種類を取得し、これをインデックスとしてm_colTableに与え、適切な当たり判定オブジェクトで判定するようにしています。

フィールドにはプレイヤーと敵と障害物が配置されているとします。
ここで、プレイヤーと敵、プレイヤーと障害物の当たり判定を行うとします。
(敵と障害物はすり抜けてもOK)
これらは、プレイヤーと敵と障害物の3種類のグループに分類して管理します。
そして、必要なグループ同士との当たり判定のみ行うようにします。

これで特定のグループ同士との当たり判定が出来るようになりました。

異なる形状同士の当たり判定には個別の計算が必要であること、キャラクタをグループで分類してグループ同士での当たり判定を行うことの2点を念頭に置いて設計していけばよいかと思います。
当たり判定の形状が増えるほど当たり判定の計算の種類も増えていくので、当たり判定クラスと当たり判定テーブルが複雑になっていきます。
形状の種類を最小限に抑えることも重要ではないかと思います。

LEAVE A REPLY

*

This site uses Akismet to reduce spam. Learn how your comment data is processed.