概要

ue4jamで作ったミニゲームの物理挙動実装についての反省。

・UE4組み込みの物理(PhysX)を使わず、自作実装した

・いろいろ勉強にはなったが、それの構築に時間かけすぎた

・PhysXだとどうなるのか、というのはわかっていた方が良さそう

という話です。

前提

・ゴルフのミニゲーム

・ボールのショットは自動で、飛んだあとのボールを色々な手段で制御する

・と言いつつ、今回は「草地にボールが乗っている時に運ぶ」手段しか実装できなかった

・厳密な物理挙動は求めてない

・プレイヤーの予想を裏切らない程度に動けばよい

やったこと

CableActorの挙動分解で学んだ質点制御の物理計算方法を元にして、

ボールの物理挙動を自作した。

・GameModeが物理システムクラスの実体を持つようにした

・PostInitPropertiesでそれを初期化

・constructorでやると、ホットリロード時にクラッシュの原因になりやすかった為

・Editor内でインスタンスがどのような寿命を持つのかは、結構複雑なようだ

・GameModeのBeginPlayでやると、レベルに配置済みのActorよりもBeginPlayのタイミングが前後するかもと考えたため

・実際にはGameModeは最初に実行されるっぽい

・地面とのコリジョンはGameModeが解決する

・ボールアクターはGameModeがBeginPlayで1つスポーンする

・ボールアクター自身は、自分のBeginPlayで自分を物理システムに登録する

・LineTraceで衝突判定した。

・FHitResult::PhysMaterial で物理マテリアルが取れるので、パラメータを以下のように使った

・Restitution : 衝突時、法線方向への速度減衰率として利用。

・Friction : 衝突時、接戦方向への速度減衰率として利用。

・Density : 「草の密度」と解釈して、ボールへ付与する加速度の倍率として利用

・関連ツイート

なぜそうしたか

・質点制御でアクターを動かすのが面白かったので、掘り下げてみたかった

・いろいろな物理ギミックを作るにあたり、自前で物理実装していたほうが作りやすかろうと考えた

・実際には作る時間なかったが…

・PhysX神のあらぶりでゲームが破綻することを恐れた

・エフェクト物理で使う分にはいいけど…という先入観があった

良かった点

・挙動を自作したので、異常な挙動の再現や原因特定は容易だった

・LineTrace系関数の使い方を学べた

・FHitResult::Normal で衝突の法線がわかるのを知ったのは、ボールの反射挙動を書いた後だった…

悪かった点

・短期間Jamなのに、基底をつくるのに時間かかりすぎた

・7日しかないのに、3日ぐらい使ってこれやってた

・何が物理システムを動かせばいいだろうとか、いつ初期化すればいいだろうとか…

・UE4使いならSimulate Physicsを有効にするだけで済むような処理を全部自前で実装する必要がある…

・ボールが転がらない

・質点１つだと、転がり挙動を簡単には再現できない

・ActorとGameModeがくっついてしまった

・特定のGameModeでしか正常に動作しないActorになっている

・GameMode自身がスポーンするからいいかもしれないけど、

新規レベルにいきなりボールアクターを配置しても何も動かない

・一応、「ゲームモードが物理ゲーム派生じゃないよ」みたいなエラー文を出せるようにはした

・正直、物理挙動のような基底部分に近いところだと、この部分で結合してしまうのは免れない気はする

・どの程度PhysXが暴れる感じなのか、あまりわかっていないまま自作路線に入っている

・Project Settingでsubstep設定すれば、挙動のばらつきは抑えられる

・速度を監視してあらぶらないようにする事もできそう

今後どうする

・期間をみてチャレンジ項目を決める

・特に短期間なJamでは、楽しい部分を作る比率を高めた方がいいだろう

・PhysXを使うかどうかの判断のためにも、ある程度使って慣れておく

・Unityでも使えるし、つぶしがきくだろう

・substep機能を使えば、挙動も安定する

以上