【西川善司が語る“ゲームの仕組み” Vol.4】実際のゲームの「当たり判定」はカプセル剤で出来ていた！？

西川善司

前回は「直方体同士の衝突判定」として、前回は「AABB」(axis-aligned bounding box)と「OBB」(Oriented Bounding Box)という2つの手法を紹介しました。

今回は「簡易的だけど直方体よりはだいぶ正確」な衝突判定手法を紹介してみようと思います。ここで取り上げる手法は、最近の市販ゲームでもよく使われているので、興味深い話題かと思います！

漫画やアニメなどの表現手法に「デフォルメ」があります。デフォルメにはさまざまな手法が存在しますが、そのひとつに実在するモノの特徴を残して形状を簡略化するというアプローチがあります。

突然ですが、今から著作権に触れない程度に「ドラえもん」をデフォルメして表現することに挑戦してみましょう。まず、大きい「○」を頭部として上に配置します。続いて小さい「○」を胴体として下に配置して、“逆”雪だるま形状を描いてみます。この頭部と胴体の接合部の左右付近から下向きの楕円を描きます。これが両腕です。各腕の先端にはまた小さな「○」を描きます。これが手です。

そして最後に、胴体の最下部の左右に横向きの横長の小さな楕円を2つ配置します。これが足です。なんだか絵描き歌みたいですが、これでドラえもんのデフォルメ形状が表現できました。

○の組み合わせで描いたデフォルメの「ドラえもん」

この絵を見て「わぁ、ドラえもんだぁ！」と叫ぶちびっ子は少数だと思いますが、「これ、ドラえもんに見えなくない？」と聞いてみれば「まあ、そう見えなくもないかもね」くらいの愛想笑いをしてくれるちびっ子はけっこういそうです。

表現対象をシンプルな幾何図形に置き換えていく技法は、ある種のデフォルメ表現といえるはずです。もし、このデフォルメ形状で衝突判定をとるとしたらどうなるでしょうか？

丸い鼻やお尻から突き出た尻尾については衝突判定が取れないですが、全体としては精度の高い衝突判定ができそうですよね。少なくとも、梱包箱のような直方体で衝突判定を取るよりは、格段に高精度な衝突判定が取れそうだということは想像できると思います。

実際のゲームでも、衝突判定において、こうしたデフォルメ表現が導入されています。

この「シンプルな幾何形状(プリミティブなオブジェクト)で表現対象を置き換えていく考え方」は、3Dゲームグラフィックスにおいては、衝突判定以外の用途でも高頻度で採用されるアイディアだったりします。脳みそのどこかに記憶しておくと、いつかいいことがあるかもしれません。

衝突判定を球体の組み合わせで表現！？

突然、話題がずれるようですが、安心してください。脱線はしていません。

Vol.03では簡単な衝突判定の仕組みとして「直方体ベースの衝突判定」を取り上げたわけですが、実はもっとシンプルな衝突判定手法があります。それは「球体形状で衝突判定を取る方法」です。

「直方体ベースの衝突判定」では、最もシンプルなAABBの方法でも、2体の直方体形状の衝突判定には直方体を構成する8個の頂点に関する大小関係の判定が必要でした。しかし「球体形状の衝突判定」では、球体それぞれの半径の情報さえあれば、2つの球体の中心座標同士の距離が2つの球の半径の和より短ければ「衝突している」となり、遠ければ「衝突していない」という超シンプルな演算で済みます。

球同士の衝突判定方法

ただ、この「球体形状の衝突判定」がいくら低負荷だからといって、さすがに3Dキャラクターを球体一個でデフォルメすることには無理があります。「星のカービィ」みたいな丸っこいキャラクターであれば3Dモデルの衝突判定に使っても良いかもしれませんが、人間のような縦に長い人体の3Dモデルを一個の球体形状で表現すると、左右に大きな隙間ができて無駄が多くなりそうです。

もし、身長180cmの人間キャラクターの衝突判定を一個の球体形状で取っていたら、前後左右約90cm以内の空間にも当たり判定が存在し、空振りにしか見えない攻撃でもダメージを食らってしまいます。これでは実用は難しいでしょう。

身長180cmの人体を球一個で衝突判定をデフォルメすると、攻撃が当たっていないのにダメージを喰らってしまうことがあり得る

ここで、先ほどの「（ドラえもんの）デフォルメ」のアプローチを導入してみます。人体3Dモデルの球体デフォルメでは、より多くの、かつ多様なサイズの球体の組み合わせで表現されています。

頭は球体一個で表現できるとしても、腕や脚は伸びる方向に、ソフトボールくらいの大きさの球体を数珠繋ぎのようにして覆い被せるような感じにする必要がありそうです。胴体については、バレーボールくらいの球体を複数個､連結させて表現するのがよさそうです。

任意のサイズのボールでデフォルメした人体モデル

半径の異なる球体を連結させた作った「デフォルメ人体」は、元の人体3Dモデルからは細部においては形状に誤差が生じてますが、球体一個でデフォルメした衝突形状や、直方体一個のデフォルメした衝突形状よりは、だいぶ精度の高い衝突判定が行えそうです。

球一個（左）、任意サイズの複数の球（中央）、直方体一個（右）で衝突判定を設定した場合の比較。任意サイズの球によるデフォルメした衝突判定は他2つと比較して無駄な隙間の空間が少なくて、相対的には良さそうに見える

もう少し衝突の精度を上げたければ、デフォルメに用いた単位球体の直径を小さくして、球体の数も増やして表現すればよさそうです。その分、「球体形状の衝突判定」の回数は増えることになりますが。

「より高精度にしたければ、単位球の直径を小さくして､球体の数を増やす」という概念は「画像を高精度に表現したければ単位ピクセルをより小さくて、その数を増やせばいい」という画像解像度の概念と酷似しています。解像度が上がればそのぶん画像処理に際して処理負荷が増えるところもよく似ています。

左は高解像度、右は低解像度。キレイな方が嬉しいが、処理負荷とトレードオフになる関係にある

これを「球体解像度」に置き換えると、こんな感じ。「球体形状の衝突判定」も球体形状によるデフォルメを高解像度で行うほど、衝突精度は向上しますが、そのぶん処理対象の球体形状が増加するため演算負荷は高くなります。

また、ゲーム進行において重要なキャラクターの衝突判定は正確に設定しておきたいので、球体を多め(→処理負荷高め。衝突精度は高め)に使ったデフォルメを行うとし、その一方で脇役キャラは球体を少なめ(→処理負荷低め。大ざっぱな衝突判定)で済ますというような「球体形状の衝突判定」における“粗密”の最適化を行うこともできそうです。

主役級は細かく、雑魚キャラは粗く……といった具合に、登場キャラクターによって球体形状の割り当てを細かく設定したり、粗く設定したりすれば、処理負荷を軽減・最適化できる

「球体形状の衝突判定」は、それなりに実用的な感じもしますが、すこし冗長な点があります。これは人体の腕や脚のような細長いパーツに対して顕著となります。ヘビの身体のような、くねくねと曲がるパーツに対しては、複数の球体形状の衝突判定を割り当てることには意味があります。くねくねと曲がったボティの形状に沿って「球体形状の衝突判定」が追従させれば、細かい変形に対しても衝突判定の精度を維持させることができますから。

ところが、人体の腕や脚は関節の箇所では折れ曲がりはしても、上腕や前腕、そして太もも(大腿)、すね(下腿)の部分は太めの棒状ですから、平常時、折れ曲がりはしません。もし、折れ曲がったら「大怪我」状態か「びっくり人間」状態です。

人間の腕や脚などは、関節でしか曲がらないので、複数の球体形状の衝突判定を割り当てることには冗長性が生じる

人体の腕や脚は細長い形状をしているがゆえに、衝突判定に一定の精度を保たせるためには、球体のデフォルメに際して球体を多く割り当てる必要があります。そうなれば、シンプルな「球体形状の衝突判定」といえども、個数(回数)が増えれば負荷は高まっていきます。わかりきっている”無駄”は、なんとかしたいものです。

マリー・アントワネットならば、もしかすると「球体形状がダメならば直方体を使えばいいじゃない？」と言ったかもしれません。たしかにそれは「パンが無ければ、お菓子を食べればいいじゃない」よりも的を射ていると思います。ただ、ゲーム業界では、もっといい方法が考案されて採用されています。

それは、カプセル形状の衝突判定です。カプセルとは､薬剤が中に詰められたお薬のカプセル剤、あの形状のことです。

誰が最初に考案したのか定かではありませんが、「カプセル形状の衝突判定」は、「デフォルメする際の都合の良さ」(つまりは衝突判定の精度の高さ)と「演算負荷のシンプルさ」を両立させる手段として優秀です。前出の人体の上腕や前腕、そして太もも(大腿)、すね(下腿)は、角ばった角材の直方体形状よりは、丸みを帯びたカプセル形状の方が見るからに親和性は高そうですよね。棒状の部位には、複数の球体を割り当てずとも、長めの「カプセル形状の衝突判定」を1つで済ませることができるでしょう。

球体を使った人体衝突判定とカプセルを使った人体衝突判定の対比。カプセルの方が明らかに効率がよい

この「カプセル形状の衝突判定」。先ほど「演算負荷は低め」と述べましたが、その根拠はどこにあるのでしょうか？なんだか丸みを帯びていますし、形状としては複雑性を増していますから、イメージ的には「演算負荷が低め」というのはにわかには信じがたいです。

ここにもちょっとした工夫があります。実は、ゲームにおける「カプセル形状の衝突判定」で取り扱うカプセル形状には、ちょっとした制限(ルール？)を設けているのです。

それは、カプセルの両端の半球部分、そして円柱(円筒)部分の丸みの部分を「同じ半径とする」制限です。いうなれば、衝突判定で用いるカプセル形状とは、つまり「半径rの球体が一定方向(直線方向)に距離nだけ移動した立体的な軌跡」ということです。この「移動距離nの軌跡」は、円柱の長さを表す「中心線n」と同じものです(下図)。

つまり、各カプセル形状の表現パラメータは2つで済むことになります。1つはカプセル形状の長さを表す「中心線の長さn」です。2つ目は「丸いもの」の形状の根幹パラメータである「半径」です。この半径rは、各カプセルごとに個別に与えられますが、そのカプセルの丸みは全て同一の半径rに規定します。

衝突判定で用いられるカプセル形状はこんな感じ

ここで、話が複雑化する「カプセル形状とカプセル形状の衝突判定」について考えてみましょう。半径がr1,r2の、2つのカプセル形状があったとき、その2つのカプセル形状が衝突しているかどうかの判定を、2つの球体形状の移動軌跡同士の衝突判定として考えます。

Vol.03では直方体同士の移動軌跡の話が出てきましたが、今回は、球体の移動軌跡です！

こう考えると、2つのカプセル形状同士の衝突判定は、それぞれのカプセル形状の丸みを表現している球体の移動軌跡(すなわち中心線)同士の最短距離が、2つのカプセルの丸みを表している半径の合計値より「短ければ衝突している」「長ければ衝突していない」と判定できます。

「カプセル形状同士の衝突判定」は、両カプセル形状の中心線間の最短距離と、両カプセル形状の半径同士の和との比較で求められる！

突き詰めて考えれば「カプセル形状同士の衝突判定」に際して必要な計算は、2つのカプセル形状それぞれの「中心線同士の最短距離」の値だけでいいことになります。そして、この「中心線同士の最短距離」の値と、2つのカプセル形状のそれぞれの半径r1とr2の合算値の大小比較で済んでしまうわけです。

この判定においてポイントとなる「2つの線分同士の最短距離の演算の導出方法」についての詳細は本稿では省略しますが、実際には、それなりの幾何学演算が必要になるので、決して“演算コストがタダ”というわけではありません。ただし、大きな体積領域に対しての衝突判定を「単一の衝突判定にまとめ上げられる」という意味においてはコストパフォーマンスは相応に良い手法だといえます。

ちなみに「球体形状とカプセル形状の衝突判定」については、ここまでの話題における、片方のカプセル形状の中心線の長さを「0」として考えれば同じことです。といっても「球体形状とカプセル形状の衝突判定」の実装においては、別の最適化が行えたりもするのですが、本稿ではそのあたりについての言及は省略します。

冒頭の「ドラえもんのデフォルメの話題」にて、腕と足を楕円で表現するとしました。ゲームにおける衝突判定のためのデフォルメ手段として、ラグビーボールのような楕円球の衝突判定を導入するのははどうなのだろう？と気になる人もいるかと思います。

ラグビーボールには長さが長い方向と短い方向を持ちますので、楕円球には向きがあることになります。つまり、「その丸み」に方向性へ配慮が必要になってくるので、衝突判定が複雑になってきそうということが想像出来ます。例外はもちろんあるかと思いますが、「衝突判定のデフォルメ」において、楕円球が用いられることはあまりありません。

楕円球に近い形状をもった3Dキャラクタがいて、これに対して衝突判定形状のデフォルメを適用しようとする場合は、楕円球を使わず、それに近い、カプセル形状で妥協するケースの方が多いようです。

この「カプセル形状の衝突判定」は、『バイオハザード ヴィレッジ』のような実際のタイトルにも採用されています。

2022年秋、カプコンは同社が開発した独自ゲームエンジン「RE ENGINE」のアーキテクチャを紹介・解説するイベント「CAPCOMオープンカンファレンス」を開催しました。このカンファレンスの詳細については本誌の取材記事に譲りますが、その会場にはなんと「バイオハザード ヴィレッジ」の衝突判定メカニズムが働く様子を、来場者自身が実際にゲーム自体をプレイしながら体験できる展示コーナーが公開されていました。

この時の展示内容に準じた画面ショットを同社から頂きましたので、ここに示しつつ、その内容を解説したいと思います。下の画面ショットは同作に登場する人型の敵キャラ(本稿では便宜上、ゾンビと呼称します)で、実際に画面に描画される3Dモデルになります。緻密にモデリングされており、顔面の表情や衣服の着こなし方もリアルですね。

画面に描画されたゾンビ

そして、実際のゲーム中では、この高精細なゾンビの3Dモデル”そのもの”に対して衝突を取るのではなく、デフォルメした衝突判定形状を3Dモデルの動きに追従するように設定しています。理由はここまで解説してきたように、物理シミュレーションの演算コストを軽減するためです。前出のゾンビは、実際のゲーム中では、下図のような「カプセル形状の衝突判定」を組み合わせたものになっていました。

実際のゲーム中での衝突判定はこのような「カプセル形状の衝突判定」の組み合わせで定義されている

この画面では「カプセル形状の衝突判定」パーツを可視化していますが、なんともカクカクとした低ポリゴンモデルのような形状として描画されていますね。これは可視化するに当たって便宜上そうなっているだけで、実際の演算においては各カプセル形状はポリゴン化されておらず、直接、数理次元で演算しています。イメージとして、無限大のポリゴン数で描かれた曲面構成されたようなカプセル形状で処理されているイメージです。

この画面ショットでは、背景物が水色で描かれていますね。実はこれ、背景の衝突判定の形状なんです。ゲーム画面の方を見てみてください。描かれているグラフィックスの背景モデルは、デコボコした複雑かつ緻密な凹凸形状を伴った石壁や石畳で表現されていますが、衝突判定の形状としては直方体や板ポリゴンで設定されていることが分かります。

そう、バイオハザード ヴィレッジのような超一流の大作ゲームでも、このように、衝突判定のデフォルメは積極的に行われているのです。面白いですね。次の画面ショットは、REエンジンの開発ツール上で、ゾンビの3Dモデルと衝突判定形状をオーバーラップ表示させたものになります。

ゾンビの緻密な実体モデルに対して、デフォルメされた衝突判定形状が当てはめられていることが見て取れる

頭の衝突判定は、実体の頭部よりも大きく設定されています。これは、攻撃が頭部から多少外れていても「衝突した」と判断してもらえるような効果があります。ゲームとしては、この方がしっかり攻撃が当たって爽快感が出るため、意図的にこうしたのかもしれません。胴体には、頭部に当てたカプセル形状を4つも個別に設定しているのが見て取れますね。本作のゾンビ達はふんぞり返るような姿勢をすることがあるので、胸部や腹部が個別に動いたときに正確に追従できるようにするため、このように「カプセル形状の衝突判定」を細かく割り当てたのでしょう。

よく見ると、腕の衝突判定用のカプセル形状はとても細いことに気が付きます。

衝突判定の設定は、1体のキャラクター(3Dモデル)に対して1つとは限りません。ゲームメカニクスの都合や、シミュレーション用途に応じて、1体の3Dモデルに複数の衝突判定形状を設定することがあります。下の画面ショットをご覧ください。

左が、ゾンビの実体が描かれたゲーム画面。右は、同一シーンの同一の瞬間での衝突判定の状態

これは上で見てもらった画面ショットと同一シーンですが、こちらの衝突判定用の形状はイモムシのようになっています。先ほどのようにサイズの異なる「カプセル形状の衝突判定」を正確に割り当てたものとは違いますね。ここで見えている衝突判定は、このゾンビの実体モデルの全体を覆うような、大きな2つのカプセル形状を組み合わせた衝突判定形状になっています。なんだかピーナツの殻みたいにも見えますが、ゾンビの身体全体を覆う衝突判定形状となっています。

これは何のための衝突判定かというと、主人公たるプレイヤーからの直接的な攻撃判定用ではなく、このステージに設置されたランタンのような炎ギミックからの「炎の燃え移り」表現のための衝突判定形状なのです。下の画面は「炎の燃え移り」表現のための衝突判定形状を、REエンジンのツール上で確認したものになります。

ゾンビに対する「炎の燃え移り」表現のための衝突判定形状。燃え移りやすいよう、わざと詳細な判定を取っていない

ゲーム中のゾンビ達はやや猫背のような前屈みで歩くことから、2つの大きなカプセル形状を上半身と下半身に割り当てていることもわかります。実際のゲーム画面と衝突判定形状を比較した1つ前の画面ショットをよく見ると、このゾンビは前傾姿勢となっていて、それに合わせて、上半身の大きな「カプセル形状の衝突判定」が追従して前に倒れた感じになっているのが見て取れます。こういう演出をしたかったから、上半身と下半身に個別の「カプセル形状の衝突判定」を割り当てたわけですね。

もう一度、ゾンビに対する「炎の燃え移り」表現のための衝突判定形状を見てみましょう。よく見ると、手の周辺には衝突判定が割り当てられていないのに、衣服周りは大きな衝突判定が割り当てられているのが分かります。これは、舞台上に配置された炎ギミックや延焼中の炎が、たとえゾンビの身体の実体そのものに衝突しなくても、炎に近づいただけで「衝突した」(→燃え始める)と判定できるようにするために、わざと燃え移りやすいような大ざっぱなものにしているのです。

今後、ゲームをプレイする際、「このゲームは、どんな衝突表現のデフォルメを行っているのかなあ？」などと考えると、ゲームをより深く楽しめるようになるかもしれません。

西川善司

プログラマーを経て技術系ジャーナリストへと転身。以降、半導体、ソフトウェア、グラフィックス、ディスプレイ、自動車、人工知能、ゲーム開発などの分野に注力した取材を行っている。