【第5回】追従カメラのラグ制御・肩越しカメラの動的切り替え＋おまけ
4Kモニターを買ったけど結局拡大して使うド近眼、僕です。
随分間が空いてしまいました。メカのデザインに悶々としたり関節機構に悶々としたり色々なことに悶々としていたせいです。
今回は生存報告も兼ねて、追従カメラのラグを制御したり、カメラが自動で左右に切り替わる処理なんかを実装していきます。
（前提）「カメラのラグ」ってなんぞい？
第1回で書きましたが、プレイヤーキャラクターに追従するカメラは基本的にキャラクターとの位置関係を維持し続け、ぴったり張り付いてきます。
「ラグ」というのは「遅れ」ですね。くっついてくるカメラをちょっと遅らせてやる処理をしてやろうという事です。
なぜそうする必要があるか？ それは演出上の理由です。
人間の感覚は事象を相対的に捉えます。例えば目の前を自動車が時速100kmで通り過ぎて行ったらものすごいスピードを感じます。一方で、その自動車に乗っていて内装を見ていたとしたら、停まっていようが動いていようが全く変わりません。ウィンドウから景色を見て、その動きからようやく速度を認識します。
ま、要するに、キャラクターに追従するカメラに「遅れ」を作ってやればスピード感が出る、というだけの話ですな。
百聞は一見にしかず
ラグ無し
前回実装したラピッドブーストを連打してるので結構な速度が出てるはずなんですが、スピード感がまるで無いですね。何かヘコヘコ上下してるだけの間抜けな絵になっています。
そしてラグをつけた場合がこちら。
ラグ有り
はい。スピード感が出ましたね。
ラピッドブーストの仕様とした「溜め」「若干の上昇力」も分かりやすくなっているかと思います。
比較して気付いたんですが、ゲームとしての体感もかなり変わりました。画面の端までキャラクターが移動するので、マップが狭く感じました。
実装だけなら簡単だけど
実はカメラにラグを付ける機能は〔Spring Arm〕コンポーネントに付属しています。
〔CameraBoom〕コンポーネントを選択して「詳細」タブにある「ラグ」をいじるだけです。
「Enable Camera Lag」にチェックを入れればラグが発生します。
「Enable Camera Rotation Lag」は回転方向へのラグです（たぶん）。今回はビハインドビュー固定なのでチェックを入れません。
「Draw Debug Lag Markers」はカメラの標準位置と現在位置、標準位置にあるかを表示してくれるデバッグオプション。
「Camera Lag Speed」は付いてくる速度。値が小さいほど大きく遅れ、戻りも遅くなります。今回は取り敢えず 7 に設定しておきました。「Camera Rotation Lag Speed」は回転方向への遅れでしょう。たぶん。
「Camera Lag Max Distance」はカメラが遅れた場合にどこまで離れるのを許容するかという数値。たぶんソケット位置から。〔Spring Arm〕の長さが 200 なので、画像の場合キャラクターから最大 320 離れると思われる。0にすると無限。
と、ラグを設けるだけならここだけで済みます。が、ブループリントでもう少し味付けしました。
止まっているときには早く戻る
このままでも支障は無いんですが、テストプレイを重ねるとカメラがヌルヌルして気持ち悪かったので、立ち止まった時には素早くカメラが戻って来る仕様を組みました。
大した処理はしていないので要点だけ。
カスタムイベント「Camera Movement」は〔Event Tick〕から呼び出されます。なので毎Tick「Camera Lag Speed」を書き換えないようにしています。
まず立ち止まった状態では「Do Once」で一度だけ「Camera Lag～」を 10 に設定。以降 Tick は「Do Once」でせき止められます。
動いている状態かつ「Camera Lag～」が 10 、つまり立ち止まったときのパラメータなら通常のパラメータに書き換えて、「Do Once」をリセット。以降動き続けている限り「Camera Lag～」が 10 ではないので、「Branch」でTickが止まります。
そしてまた立ち止まると「Do Once」が走る、という構造。
ゲームエンジン自体が常に膨大な変数を処理してるので別にそこまで気を遣う必要も無い気はしますが、塵も積もれば何とやらの精神でやっていきたい所存。
途中にある「Auto Camera Switch」イベントは次の肩越しカメラ切り替えに使います。
肩越しカメラの動的な左右切り替え
肩越し視点のTPSでは当たり前に実装されているカメラの左右切り替え。
大抵のシューターならボタン操作で行うものです。ゲームパッドなら右スティックの押し込みが一般的じゃないでしょうか。
だが『ARMORED CORE V』は違った……
実際には肩越しではなくて胴か腰あたり越しなんですが、そこじゃなく。
あのゲーム、いつの間にかカメラが入れ替わってるんですよ。色々と条件はあって、一つは旋回モーション（右スティックを倒しっぱなし）を一定時間し続けた場合。もう一つはハイブーストやグライドブーストと視点移動を組み合わせた場合。たぶん他にも。
それが本当に気付かない内に入れ替わっている。全然プレイヤーに意識させないレベルでこっそり入れ替わっている。左右の違いを考えるのって、スナキャ腕使いくらいじゃなかろうか。
なんでこんなシステムになっているか、理由は考え付きます。
一つは自機の形状変化。『V』系統は以前に比べて体高が低く横幅が広い。なのでそれまでのように頭部後方だとイマイチ迫力に欠けたんではないかと。
二つ目にブーストシステムの刷新。旧作のような自由な立体軌道による空中戦がなくなって、代わりに壁蹴りなどのアクションのために自機の位置が分からないといけなかった。
ここまではカメラ位置の変更理由。じゃあ自動で左右が入れ替わるのはなんでか。答えは簡単。ボタンが足りない。
ボタンが足りないのを前提に作っている本プロジェクトもこれをどうにか再現したい……再現したかった……無理でした。
試行錯誤を重ねてみたものの、考えが足りないのか上手くいきませんでした。ので、簡易的な実装にとどめておきました。
TimeLine を使って簡易実装
まずは実際の挙動を見て頂きましょう。
どういう動作かを先に説明しますと、移動操作が右かつ視点操作が左ならカメラのオフセット位置を左へ移動、移動が左かつ視点操作が右ならカメラを右へ移動、というものです。
ブループリントを見ていきましょう。
「InputAxisRight」というFloat型変数を作って左右の入力（緑色の線）を入れます。
視点側も同様に「InputAxisTurn」にセット。
そして肝心のカメラ移動処理です。
〔TimeLine〕ノードを使用することで滑らかな移動を実現しています。このノードについての説明はちょっと後回しにして、条件の確認をしましょう。
入力はニュートラル（入力無し）を 0 として、右で最大 1.0 、左で最大 -1.0 の値を返します。つまり 0 より大きければ右、0 より小さければ左です。
なので上の条件式は、移動が右かつ（AND）視点操作が左なら True、下は移動が左かつ視点操作が右なら True ということになります。
TimeLine ノードってなーに？
公式ドキュメントを読むのだ。
と、片付けてしまうと身も蓋も無いので簡単に説明すると、設定した値の間を時間単位で滑らかに推移させたりできるノードです。出来ることが多いので取り敢えずそんな認識でいいと思います。
それで今回作ったタイムラインはこちら。
何の変哲もない直線。時間は 1.4 秒で、0 秒にVector値のYだけが 50、1.4秒に -50 のキーフレームがあります。
さて、ここでもう一度処理を見ましょう。
移動が右かつ視点が左に入力されているなら、〔TimeLine〕ノードの「Play」に Tick が流れます。そうでない場合は「Stop」へ。
「Stop」はタイムラインを一次停止するピンです。
逆パターンの場合は「Play」ではなく「Reverse」に Tick を流します。こいつは現在の再生位置から逆再生するピンですね。
で、得られたVector値を「CameraBoom」の「SocketOffset」にセット。
以上！！
処理は最終的にとてもシンプルになりましたが、途中はマジで頭を抱えました。一時はもうしっちゃかめっちゃか。
この形態に落ち着きかけた頃、カメラが真ん中らへんで止まったら戻す、という処理を加えていて、それを友人に見せたら「気持ち悪い」と一蹴されたり。
ハァ～。スキルが欲しい。お金も欲しい。
おまけ
こちらの記事を参考に、カメラが近すぎた場合にキャラクターを透過する処理を加えてみました。
マテリアル関係を触るのはまだ当分先になると思うので、詳細は省略。