元： https://technicalsuwako.moe/blog/gamedev-blog-002
今日は、もっと作業を進められると思っていたのですが、キャラクター用のコライダーを作るのは、思っていた以上にずっと難しい事が分かりました。
其の代わり、コライダーはきちんと動作する様に成り、衝突判定で残っている作業は、動的な判定を実装する事だけです。
此れは、エレベーターや空飛ぶ絨毯、敵等、静的に配置されていないオブジェクトに使用します。
短い動画は此方です：
#video/mp4
此処では、狐が家や木に向かって走り、幾つかには衝突している物の、全てには衝突していない、という事しか見えないので、分かり憎いかもしん。
コライダーを表示してみましょう。
ご覧の様に、今では全ての家にコライダー（白い輪郭）が設定されていますが、焚き火にはありません。
其の為、焚き火は其のまま通り抜けられますが、家は通り抜けられません。
又、狐がカプセル形状で、木が円柱形状になっているのも分かると思います。
其の為、狐が木に向かって走り続けると、木から押し返される様に成ります。
家は立方体なので、狐が家にぶつかっても、其のまま家に向かって走り続ける事に成ります。
では、島はどうなっているのか、と疑問に思うかもしん。
島のコライダーは、グラフィックモデルを其のままコピーした物です。
十分に単純なのでラグを発生させる事もなく、其れでいて完全な精度を保つ事が出来ます。
桟橋には面取りが施されており、其処全体に衝突判定を設定すると、グラフィック面でもロジック面でも問題が発生する可能性があります。
其の為、桟橋のコライダーには平たくした立方体を使っています。
詰り、最終的にどのコライダーを使うべきかは完全に状況次第であり、此れが最適という唯一の解決策はありません。
又、ジャンプと泳ぎも確認出来ると思います。
ジャンプはかなり単純で、ジャンプのあるゲームを作った事がある人なら、どう動くのか分かるでしょう。
ゲームをゼロから書いていようが、Unity、Unreal、Godot、SDL、Raylibを使っていようが関係ありません。
ロジックはどの場合でも同じです。
泳ぎには「トリガー」と呼ばれる特殊なタイプのコライダーを使用しています。
通常のコライダーの役割は、其処からプレイヤーを押し出す事です。
此れによって床の上に立ったり、壁にぶつかったり出来る様に成ります。
そう、実際の所床がやっている事は、床に触れている間ずっとプレイヤーを上方向に押し続けて、床をすり抜けない様にしているだけなのです。
トリガーを使うと、コライダーをすり抜ける事が出来ますが、其の中に何かが入ったり、其処から出たりした時に、プログラマーが反応出来る様に成ります。
此れはカットシーンの開始、プレイヤーへのダメージ、アイテムの取得等、様々な用途に使えます。
今回の場合は、水の中にいるかどうかを判定し、水の中にいる場合は狐が泳ぎ、移動速度が遅くなる様にしています。
Khronosさんの狐モデルには泳ぎのアニメーションがないので、泳ぎには歩行アニメーションを其のまま流用しています。
ゲーム開発で出来る最高の工夫の一つは、既存のアセットを再利用して、用途に合わせて調整する事です。
例えば8ビットゲームなら、草むらのスプライトの半分を雲に簡単に流用して、緑から白に色を変え、反転させるだけで使えます。
此れによって、別のオブジェクト用にスプライトタイルを1枚節約出来、更に反対側には実質的に鏡像と成るだけの物をもう2枚使う必要がなく成ります。
8ビット機では使用出来るタイル数が非常に限られていたので、当時のゲームでは此の様な手法がよく使われていました。
ご覧の様に、此れで坂道の上にもきちんと立てる様に成りました。
昨日お見せした物より、ずっと説得力のある動きになっています。
そして勿論、屋根にコライダーがなくても、こういう事は出来ます。
コライダーがどの様に動作するのか理解する為に、Blenderのスクリーンショットを見てみましょう。
此処には狐のモデルはありません。
別のモデルだからです。
静止していない全てのモデルは別々のファイルに置き、静的なオブジェクトは1つのシーンファイルに纏めています。
オブジェクトの周囲にはたくさんの白い形状があり、水の周囲には緑色の輪郭があるのが分かると思います。
又、名前の先頭に「COL_」や「TRIG_」を付けている事にも気づくでしょう。
此れによって、エンジンはどのオブジェクトを衝突判定に使用するのかを判断します！
詰り、エンジンに対して「COL_ で始まる物は全て狐を中に入れない為の物」であり、「TRIG_ で始まる物は全て狐と相互作用させる物」だと伝えているわけです。
COL_ のコライダーは狐を中に入れない事だけが目的なので、後ろに付ける名前は好きな様に付けられます。
然し、TRIG_ のコライダーには一定の命名規則が必要です。
其の名前を使ってイベントを割り当て、其れらのイベントをC++のソースファイルに実装するからです。
全体としては、とてもシンプルなシステムですが、驚く程強力です。
というのも、Volt Engineにはエディターがありませんが、アーティストやレベルデザイナーはBlenderを使って其のままレベルを設計出来、プログラマーは何週間もかけて適切なコライダーを手作業で計算・設定する必要なく、トリガーにイベントを割り当てる事が出来るからです。
同時に、アーティストやデザイナーは新しいツールを覚える必要もありません。
既に使い慣れているツールを其のまま使えるからです。
詰り、チーム全体にとって正にウィンウィンというわけです！
以上