概要

自主制作プロジェクトにおいて某SF宇宙船用の移動処理をBPで実装。
エンジンバージョンは5.2~5.3

基本要件

要求される挙動は...

最終的にブループリントはこのスパゲッティのようになりました_(┐「ε:)_

処理の構造としては以下の通り（折り畳み内に詳細を記載）

①推力制御部分

②センサー部分

Sphere line trace by channelを使用し、艦を中心に45°ずつ5本のトレーサーを広げる。
扇形範囲内の障害物の有無を検知する。
(長さが不均衡なトレーサーは自然な挙動になるように感知タイミングを調整したもの)

③制御中枢部分

センサー部分の情報と追跡対象との位置関係をもとに、大きく分けて4種類の行動に分岐する。
1. 目標座標に向け旋回する
  自艦から見たターゲットの方向(ローカル座標系)によって旋回方法を判定
2. ロール回転を水平に戻す
  仮想transformとアクターの相対ロール回転を計算し、それを徐々に0に近づけることで水平に戻す

仮想transform(仮称)
アクターの進行方向を示すベクトルを回転値に変換し、actor transformのrotatorと置き換えることでローカルのロール回転値を排除した仮想的なtransformを算出する

3. 僚艦接近時の回避機動
接近を検知した場合、検知方向と反対側に転舵する
例) 右上方向に検知-->左下方向に転舵

4. トレーサーがターゲットを検知した際の回避機動
左右45°のトレーサーが反応した場合は侵入角度が深すぎるということなので、フレームあたりの旋回角度をより大きくしている。
※ターゲットとの衝突(オーバーラップ)は絵面的に一番避けたいので、分岐の優先順位として最優先になるように配置している。

これらの分岐を経て実際のrotatorにする処理
アクターから見たアクターのローカル回転は常に0なので、現在値に変化量を与えてワールド回転に戻すというのが基本戦略。
（回転しすぎて裏返ると困るので、再び仮想transformを基準として最終的な回転に制限をかけている

実装から半年以上経っての記事作成となったため、改めて見ると計算処理の煩雑さが目立つ他、おそらくTimerノードを用いて動作クロックを30fps程度に落としても問題ない(今ならそうする)。
...が、ロール軸回転の算出で使用した仮想的なtransformを置く手法は我ながら良い発明だったと思う。