第12回「プレイヤーキャラが空中にいても追ってきてくれるタスク」

今回はプレイヤーキャラクターが空中にいても敵キャラクターが追ってきてくれるタスクを作る。

どうもUE4のファーストパーソン、サードパーソンは一般的なやつを考慮していてナビゲーションメッシュを利用するのが前提みたいだけど、空中にプレイヤーがいる時は位置を読み込んでくれない。

またDoN AI NavigationというBox状のメッシュで判定するプラグインがあるけれど、使い方がよくわからないのと重いため広いマップに不向きだったので使わない方向でいきたい。

という訳で下記のHPを参考に組んでみました。

【UE4】AIを空中で移動させる時に使えそうなノード

前回の記事で作ったRapidMoveToというタスク(ナビメッシュにそってプライヤーをゴールに設定し追ってくるタスク)内部の『AIMoveTo』を『MoveToLocationOrActor』に置き換えただけ。

ただし下記に注意。

※UsePathfindingのチェックを外すこと

※またLockAILogicのチェックを外さないとブラックボード上でターゲットの変数が消されてもゴールがなくなった判定にならず永遠に追ってくる

※上記二つはノードのどこにあるの?ってなったらノードの▽マークをクリックすると隠れてるよ

とりあえずこれだけで空中でも追ってきてくれるようになりました。

ただしナビメッシュを使用していないため障害物があっても避けて移動してくれません。

で、ナビメッシュを使用せずに障害物を避けて移動できないかと四苦八苦していたのですが、ぶっちゃけいい方法が思いつきませんでした。

ただアーマードコアの敵や地球防衛軍の敵を見ていると、その問題は無視していいように思えてきました。

ACの場合

敵はこちらが建物に隠れていると対面でピョンピョン跳ねていたりするだけで的確に向かってくるわけではないです。

地球防衛軍5の場合

アリは建物の角度お構いなしにプレイヤー一直線に向かってくるので障害物を気にする必要はなし。

カエルの場合は視線から外れると、見失った位置もしくはランダムな箇所?にまで移動して、それでも視線にプレイヤーが映らないと巡回行動になる臭い(合ってるかは知りませんが…。ただ空中にいても見つけたときは器用に建物を避けながらプレイヤーに向かってくるので、何らかの方法でナビメッシュ的なものをうまく使っているのだとは思いますが、エンジン違うしよくわかりません)

EDF:IRの場合

UE4使用しているので参考になるかと思ったら、巨大な敵(ロボ系)は建物(障害物)を破壊して進んでくるので障害物を避ける必要などない!!という超力技でした。

多分今作っている敵のイメージ的にも障害物はぶっ壊して突き進んできてくれるのが一番いいと感じたため、ナビメッシュ無しで障害物を避けてくる判定は無しでいいかと思い至りました。

(使用するとしてもプレイヤーが最後に着地した箇所に向かうなどを設定するならその時だけナビメッシュ使用するとか?)

そのため次回は障害物判定をやめてAIの攻撃作成を目指してみたいです。

あとノックバックとか。

そのあたりができたら本格的にビヘイビアツリーを作りこんで1キャラほぼ完成までかこつけたいところ。

頑張るぞい。

第11回「敵を作る_SinmpleMoveの注意点とビヘイビアツリークイックスタートガイドでのメモ」

プレイヤーキャラクターの動きがある程度できてきたので今度は敵の作成を開始。

SinmpleMoveの注意点

またプレイヤーキャラクターの動きは改造する予定だけど、敵との戦闘をしながら調整したいのでまず敵を作ってしまいたい。

という訳で「アクションゲームブループリント入門」よりナビゲーションメッシュを利用してキャラクターを動かすSimpleMoveToActorでキャラクターを動かしてみる…と、なぜだか動かない。

UE4ANSWRHUBで聞いてみてもなかなか分からずかなり解決に苦戦した。

参照:UE4ANSWRHUB :Simple Move to Actorでキャラクターが動かない

で、原因はなんとまあプレイやキャラクターのカプセルコリジョンが大きすぎたため。

どうも自キャラのCapsulecConponentのShepeのCapsuleHalfHeightが257を超えるとSinmpleMoveToActorが反応しなくなる様子。

多分SinmpleMoveToActorの仕様っぽいためどうしようもなさそう……。

ナビゲーションメッシュはプレイヤーキャラクターが空中にいると読み取ってくれないためあまり使用したくないのだけれど、なにに使用するか分からないので使用できるようにはしておきたい。

プレイヤーキャラクターのロボットは8m程度で作成していたのだけれど実際のサイズはグレーマンと同じ程度のサイズにしてしまってマップを縮小した方が今後の処理を考えると不具合が少ないかもしれない。ナビゲーションメッシュも広いほど重くなるし。

どうもUE4は巨大なものを動かすのに不向きな印象がある。

それに敵やエフェクトはアセットストアのものを利用しようとしていが、基準サイズがグレーマンのため全部拡大すると不具合が生じる可能性は十分にあるし、面倒なことが多くなりそう。

俺は面倒が嫌いなんだ。

役に立ちそうなオマケ参照:UE4AIで使う移動と停止のまとめ

敵AIを作成する~なぜか生じたエラーについて~

ビヘイビアツリーのクイックスタートガイドと下記のHPを参照に敵AIを作成する。

参照:ビヘイビアツリーのクイックスタートガイド

参照:おっさんのゆるゆる研究開発 UE4で敵キャラクターAIを制御する

組んだBPは記載されているままなので割愛。動くぞ、こいつ!

……が、なぜかエラー発生。なんで?

エラーメッセージの内容とエラー箇所で処理を止める機能で原因を探る。

参照:妹でもわかるUnrealEngine4:ブループリントでエラーが起きた時にすぐ止める設定について

で、どうも原因はAIコントローラー上でHomeLocationがBlackboardに格納されていないのが原因臭い。

さらに原因を探してみると、どうも試しに作っていたレベルブループリントのSpawnActorが悪さをしていた様子。予想だけどHomeLocationを読み取る時にキャラクターが生成されていないから値をブラックボードの格納できていなかったのだと思われる。

逆に今後SpawnActorでキャラクターを生み出すときは位置の指定をしてやる必要があるのかと思われる。注意。

判定として使えそうなもの

上記のHPを参考にして組んだBPのAgroCheckでは敵キャラクターからプレイヤーキャラクターまでトレースを飛ばして、間に障害物があるかどうか(見えているかどうかの判定)をしている。下記のようなBPを組むとよくわかる。

これをうまく使えば敵の行動の判定に利用できるかもしれない。

・キャラクターとの間に障害物があれば射撃を行わない

・障害物を感知したら避けて移動する(ナビゲーションメッシュを利用しない移動)

上手く応用出来たらいいと思う。

今後の予定

とりあえず索敵範囲に入ってきたら索敵範囲内にいるうちは追ってくるAIを組むことができた。ただナビゲーションメッシュはキャラクターが空中にいる場合は判定してくれないため別のものを使用してプレイヤーキャラクターを追ってきてもらう必要がある。

それも踏まえて下記のことを実現していきたい。

・プレイヤーキャラクターが空中にいても追ってきてくれる

・ナビゲーションメッシュを利用せずに障害物を避けてプレイヤーを追ってきてくれるか

・攻撃するAIを入れる

・アニメーション、音の導入

・限界いっぱいまで敵をスポーンしてみる

ここまでできればほぼ1体の敵が完成するのでだいぶゲームっぽさが増すと思う。

という訳で次回は「敵を作る_プレイヤーキャラクターが空中にいても追ってきてくれる」の予定。

第10回「飛行モード後の疑似的な慣性をつける」

前回はゲージ作ろうか、と書いてましたがそれは没にしました。というのも「アクションゲームブループリント入門」という参考書を見て実装できたのですが、ぶっちゃけると参考書の内容まんまなのでここでわざわざ書く必要はないかな、と。

備忘録的には組んだBPは何を見れば思い出せるか分かればいいのです。

……正直この参考書もうちょっと早くほしかった。

というわけで今回は 飛行モード終了後の疑似慣性についてのメモです。

現状の飛行モードだと「AddActorLocalOffset」で前方に飛ばしているため終了したとたんにビタッと停止してしまいます(毎時間キャラを指定された方向に移動させるという内容のため慣性が働いていないため)

アーマードコアのOBみたいなスピードで飛んでいても飛行モードをやめたとたんにビタっと停止します。それはどうも違和感があるなぁ……という訳で飛行モードを終了させても飛んでいた方向に慣性で飛んでいくような挙動を設けたいと思いました。

で、最初はハイブーストに使用していた「Velocity」で飛ばしてやればキャラに力を与えて飛ばしているわけだから慣性が得られるのでは?と考えやってみた結果、一応慣性は得られました。ただしハイブーストで「Velocity」を使っている関係上、飛行モードにまで「Velocity」を使用すると飛んでいる最中はハイブーストの「Velocity」が効かなくなってしまい、飛行中にハイブーストが使えなくなってしまったので没。

ではキャラクターを任意の方向に飛ばす「LaunchCharacter」では?と試してみたところ、こちらも慣性は得られたのですが、どうも飛行中の挙動がおぼつかない……。移動中も慣性が効きすぎて滑ってしまうというか、とにかく操作がしづらい。なので没。

どうも私の現状だと飛行モードは「AddActorLocalOffset」で前方に飛ばすのがベターのよう。でもそれでは慣性が……

で、行きついた発想が「飛行モード終了後にキャラクターが向いている方向にキャラクターを飛行モードのスピードで飛ばして疑似的な慣性をつける」でした。

というわけで疑似的な慣性のマクロがこちら

中身は単純でtickが流れたときにキャラのカメラの向きを取得して飛行モード時の速度でキャラクターをその向きに飛ばす、というもの。

(変数の「FallingLateralFrictionON/OFF」はこの後説明)

これを飛行モードがOFFになったときの処理にねじ込みました。

(飛行モード自体のBPは第7回および第8回参照)

注意としては飛行モードがOFFになったときにキャラクターの角度を0に戻すのですが(第7回参照)そのノードの前に配置しないと飛行モードがOFFになったときの方向ではなくて強制的に前方へ跳んでしまうからです。

飛んでからキャラの角度を戻す、という順番にする必要があるので注意。

ただこれだけだと思った通りにキャラが飛ばず、じゃあどうしようと色々いじっているうちに気づいたのが「CharacterMobement」の中にある「LateralFriction」を低くしてやるといい感じに飛んでくれることでした。

「LateralFriction」は落下中のキャラクターにかかる空気抵抗(摩擦と一緒)のようなもので、低ければ空中で滑るように動くというものです。

ただずっとこれを低いままにするわけにもいかないので、飛行モードがOFFになったときだけ「LateralFriction」が低くなるようなマクロを組みました。

さっき組んだ疑似慣性のマクロにtickが流れたときだけ瞬間的に「FallingLateralFrictionON/OFF」によって「LateralFriction」の値が0になり、そこから徐々に1へ戻るというものへ。

これで冒頭の動画のような慣性が完成しました。

しかしここで別の問題点が……

どうも慣性を利用して飛行ボタン連打で無限飛行が可能になってしまうことが判明。こらあかん。

という訳で飛行モードにクールタイムを設けました。

これで飛行モード終了時に2秒間は飛行モードにいけなくなったので無限飛行はできなくなりました。

アーマードコアのOBのチャージとかコレのためにもしかしたら設けてるのかも……

このゲームでは飛行モード終了後にクールタイム設けましたが、似たような処理を開始時に仕込むことで飛行モード移行までのチャージタイムを設けることができます。

これで本当に慣性が完成しました。やったね!

次回こそは攻撃とか作るのに移行していきたいところ。

それができれば大分ゲームッぽくなるのではないかと。

頑張ろう。あと社畜辞めたい……。

第9回「カメラの追従にラグを設ける」

AC4みたいにカメラの追従にラグを設けたい。

というわけで下記を参考にしました。

UE4ANSWERHUB:サード・パーソンゲームでのプレイヤー移動方向にカメラ向きも追従する機能の実装について

ただここの回答に記載されているSetControlRotationの意味が実はよく分かってません。

私の作っているゲームだとGetPlayerControllerをそのままつなぐと左スティックの入力をカメラが拾ってしまってまともに移動できなくなってしまいました。

なのでいっそそれを外してBPを組んだのが下記です。

SetControlRotationは私のゲームの場合は外しても問題はありませんでした。

サードパーソンベースを使用してるので前提はそう変わらないと思うんですが、色々チェック入れたりしてかみ合わなくなってるのかもしれません。

なのでこちらのゲームではSetControlRotationは外してしまいます。

(というか外さないと正常に機能しない)

よっしゃこれでOK!

そんなふうに考えていた時期が俺にもありました。

実はコンポーネントCameraBoomのLagのEnableCameraLagにチェック入れておかないとラグが生じません!!

これが分からなくてまた半日潰しました。クッッソ!!

とりあえずこれでカメラのラグを追加できました。

次回はブーストのエネルギーゲージでも作ってみようかな。

それができたら弾でも出す処理作って敵も作って徐々にゲームっぽくしていく予定です。

GWは作業が進んでいいですね。あー社畜辞めたい!!

第8回「Anthemっぽい飛行-その2」

前回組んだ飛行のBPをとりあえずそのままオリロボの方へ持ってきて移植。

その後の調整メモです。

調整内容は下記の4つ+α。

⓪飛行モードの加減速(没)

①飛行モード移行時の加速度をつける

②飛行モード中の超加速

③ハイブースト、グライドブーストとの調整

④衝突判定をつける

今回は無駄に長いです。

⓪飛行モードの加減速(没)

もともと左スティックでキャラを中心に上下左右に動くようにしていたのですが、上下の移動を廃止してスティック上下で速度の加減速を行うようにしようと思って組んだのが下記のBPです。

左スティックの上下入力を取得するところにUE4のFlyingベースにあった加減速のBPをそのまま流用してます。

これで飛行時の加減速ができるようになるのですが……。

よくよく考えてみると作ろうとしているゲームにおいて飛行モードをどのように使おうかと思案した結果、アーマード・コアのオーバーブーストのような使用になるかな?と思ったので加減速はやっぱり不要だなぁ、という結論に。

というわけでこれは没としました。

なので左スティックの上下左右でキャラも上下左右に動くBPで進めていきます。

第7回のBPの組み方で進めます)

①飛行速度の加減速をつける

飛行モードに移行した際に前回のままのBPだといきなり最高速度で飛んでいってしまうため、初速から加速して最高速度になるようなBPを追加しました。

まず関数を2種類作ります。

・FlyingSpeed

まず下記の変数を用意

・FlyingModeSpeed(飛行中の速度の変数)

・FlyingMaxSpeed(飛行中の最高速度)

・FlyingMinSpeed(飛行中の最低速度)

・FlyingMoodAcceleration(飛行速度の加速度)

それを没にした⓪番のBPを参考に画像の様に組みます。

これでFlyingModeSpeedがFlyingMaxSpeedに達するまでFlyingMoodAccelerationが足されていく関数ができました。

しかしこれだけだとFlyingMinSpeedに戻らないため、別で下記の関数を作ります。

・FlyingSpeedReset

上画像のBPこれでFlyingModeSpeedがFlyingMinSpeedにリセットするようにします。

※この処理のためにFlyingModeSpeedの値=FlyingMinSpeedの値にしておく必要あり(でないと最初の速度と次から使用した速度で違いが出てしまう)

正直もっとうまい方法あるような気がするのですが……誰か教えてください…

そうして組んだ関数を下記の場所に埋め込みます。

上記BP拡大1
上記BP拡大2

これでいきなり最高速度になることはなくなりました。

②飛行モード中の超加速

第5回目の時のように飛行モード中にジャンプボタンを押すことで加速するようにします。

まずカスタムイベントFlyingMpdeBoostを作り、画像の様にBPを設定します。

これは一気に最高速度でかっとぶイメージなのでFlyingMaxSpeedにFlyingModeSpeedmagnificationという変数をかけています。

(現状の設定ではFlyingMaxSpeedの3倍の速度で飛ぶようにしています)

次にカスタムイベントFlyingMpdeBoostにtickを流す個所を第5回の時に作ったグライドブースト中にジャンプボタンで加速の箇所に入れます。

これで飛行モード中にジャンプボタンを押している間は超加速するようになりました。

③ハイブースト、グライドブーストとの調整

・ハイブーストの調整

飛行中にハイブーストを使用すると上下左右に緊急回避するようにしたいので飛行中のスティック変数を取得し、その方向へVelocityを加えるようにします。

下記画像の様に飛行中のスティック情報を変数として取得し、第5回で関数化したハイブーストのBPに飛行中のスティック情報を加えます。

※スティック変数の取得は第4回を参照

飛行中の左スティックの変数を取得
ハイブースト関数のBPに飛行中のハイブーストを追加

なお飛行中のスティック変数のX,Z方向に0.5をかけているのはそのままだと移動しすぎてしまうため移動を弱くする目的で入れています。

とりあえずこれで飛行中は上下左右にハイブーストできるようになりました。

・グライドブーストの調整

今作っているゲームではハイブーストボタンを押しっぱなしでグライドブーストへ移行するように設定しているため、飛行中はハイブーストボタンを押しっぱなしにしてもグライドブーストが発動しないようにする必要があります。

そのため下記の箇所にBranchを入れて飛行中はグライドブーストへtickが流れないようにしました。

上記BPの拡大

グライドブーストの処理は、下記の様になっています。(第5回参照)

ハイブーストボタンを押しっぱなし

→グライドブースト(SetMovementModeがFlyingになる)

→ボタンを放すと歩行モードへ(SetMovementModeがWalkingになる)

という処理になっており、飛行中は両方のBPにtickが流れないようにしないと飛行中にハイブーストボタンを押したときにグライドブーストへ移行してしまったり、モードがWalkingになって重力が働いてしまったりしてしまいます。

※実際止めるBPを入れ忘れてハイブーストボタン押したらなんで落下すんの!?って小一時間悩みました。

④衝突判定をつける

これは第6回の時に壁衝突判定の関数を作っているのでそれをそのまま流用。

上記BPの拡大

カスタムイベントFlyingHitWallを作成し、EventTickを流す。

そして飛行中に壁に当たった場合に飛行モードOFFにtickが流れるようにしています。

ちなみに第7回に記載しているBPは飛行モードの切り替えをFlipFlop(交互に実行する)で行っていましたが、それで設定すると衝突判定で飛行モードがOFFになったときに再度飛行モードボタンを押しても一回飛行モードOFFにtickが流れて今うためBranchに変更していたりします。

とりあえず以上でオリロボにAnthemっぽい飛行を実装できました。

……これAnthemっぽさもはや皆無ですね。

ほんとは下向くと重力加速度も飛行速度に追加されるようにしたいのですが、いかんせんそこまで突っ込むと色々難しそうなのでそれはいつかの機会にして先に進めようと思います。

次回は「カメラのラグ追加」

動画見ればわかるんですがこのブログ書いてる時点で実はすでに実装できてます。

今回が長ったらしかった分、次回はさっぱり目で。

第7回「Anthemっぽい飛行-その1」

今回はAnthemっぽい飛行の制作メモ。

と、その前にブログの更新がいつもより遅いことについて愚痴らせてください。

タイトルで「社畜でもロボゲーできるもん!」とうたってたが……スマン、ありゃウソだった

社畜じゃロボゲーできねーよ!!

残業100時間越えが3か月続くとかふざけんな!!死ぬわ!!

・・・そりゃ確かにもっとやばい人といっぱいいるけどさ、少なくとも休日動けんのですよ、真面目に・・・

社畜じゃなくなったらタイトル変えます。もっと楽な部署にいきたい…

はい、というわけでAnthemっぽい飛行の制作していきます。

今回は一旦別のサードパーソンベースを用意して一旦飛行だけのお試しを作ります。

目指す挙動は下記の画像のような物。



最初はカメラの方向にキャラを飛ばすという考えに囚われすぎていてカメラも同時にいじり始めたもんだからわけわかんない状態になっていましたが、キャラクターをカメラの方向に向かせて前方に進めると考えを改めたら結構楽にできました。

それがこのBP

移動と飛行の切り替え
左スティックの入力切替

・飛行と歩行の切り替え

まず飛行モードと歩行モードの切り替えをFlipFlopとSetMovementoModeで作成。

「Flying」のときは「UseControllerRotationPich」にチェックを入れます。

これは第二回で触れていたキャラの向き(Yaw)をカメラに追従させるやつのPich版で、これにチェックを入れることでカメラの上下向きに合わせてキャラクターの向いている角度も変わります。

キャラクターの向きも変われば、あとは「Flying」の時にキャラクターを前方に移動させるだけでカメラの向いている方向にキャラクターが前進するという仕組みです。

「Walking」にモードを切り替えるときに「UseControllerRotationPich」のチェックを外しますが、実はこれだけだとキャラクターが「Walking」にモードを切り替えたときの向きのままになってしまいます。

なので「SetActorRotation」でPitch軸の数値だけを0にしてその軸の回転をリセットすることでキャラの向きを戻します。

ちなみに Flying中の前に進む処理について は AddActorLocalOffsetを使用 を使用していますが、 ハイブーストや移動にvelocityやAddMovementInputを使っている関係かこの2つは前に進む処理に使用するとなんかおかしくなってしまいました。

まあ、私のBPの組み方が悪いだけかもですが…

・左スティックの入力切り替え

サードパーソンベースのBPはフィールドに対して軸を取っています。そのためキャラクターがカメラに合わせて上を向いていても、左スティックを前に倒すと地面に対して前に進む、といった感じになります。

今回は上記の画像に上げた通り、「Flying」中はカメラの向きを主軸にしたいので、画像のようなBPとしました。

「Flying」中は「UseControllerRotationPich」にチェックが入っているのでそれを判定としてスティックの入力をBranchで切り替えています。

で、ターゲットを「FollwCamera」にした「GetRightVector」及び「GetUpVector」を設定してやることで飛んでいる最中はカメラを主軸にキャラクターが左スティックで移動するようになりました。

後でカメラをいじる予定なので恐らくターゲットの「FollwCamera」はその時に切り替えが必要になるかもです。カメラの設定の仕方にもよるのでしょうが、調べている感じ変更が必要そうです。

以上でAnthemっぽい(全然別物だけど)飛行のベーシックは完成。

次回はこれをオリロボの方に組み込んで、加減速などの処理、あと障害物に当たったときは飛行が解除されるとかの処理を試してみようと思います。

カメラの処理はその後ですかね。

次回は「Anthemっぽい飛行モードの実装―その2」の予定

ああ、社畜辞めたい・・・

第6回「アーマードコアVっぽい壁蹴り編」

今回はUE4でアーマドコアVの壁蹴りっぽいのができたのでその制作メモ。

と、壁蹴りBP制作前に一つ調整。

というのもデフォルトのサードパーソンBPだとジャンプボタンを押し続けてもジャンプにTickが流れるのが一回になっているため、ボタン押しっぱなしの間はジャンプボタンにTickが流れるようにします。

なんでそんなことをするかとういうと、ACVではジャンプボタンを押しっぱなしにしながらでも壁に触れたときに壁蹴りしてくれるからです。

これが意外に重要で、タイミングよくボタンを押して対応しようとすると反応がどうしても遅れてしまうんですよね。特に連続で壁蹴りする場合はボタン押しっぱなしでないと対応が難しくストレスが溜まるため、操作性向上としてボタン押しっぱなしに対応できるようにします。

というわけでまずボタン押しっぱなしで反応するようにジャンプのBPを改造します。

・ジャンプボタンを押しっぱなしで判定取れるようにする

下記のHPを参考にしてデフォルトのジャンプBPを改造。

参照:UE4マウスやキーボードを押している間の判定を取る。

「InputActionJump」からボタンを押しているかの変数を作り、押している間は「EventTick」が「Jump」のBPに流れるように作成。

※画像が「Jump」でなく「Jumping」になっていることについては下記の壁蹴りBPをカスタムイベント「Jumping」で作成しているため。その中に「Jump」が含まれます。

とりあえずこの段階ではボタンを押している間は「Jump」にTickが流れるようになったと考えておいてください。

という訳で早速壁蹴りのBP作成へ。

・壁蹴りの考え方

BPがちょっぴり長くなってしまったため、とりあえず先にどんなフローで作ったかの説明

1.ジャンプボタンを押した際に

  →地上なら普通にジャンプ

  →空中なら壁と接しているかどうかの判定

2.壁と接した場合の処理

3.入力している方向キーの向きの先に壁があるかの判定

 →壁がある時:垂直壁蹴り(上に上昇)

 →方向キーがニュートラルの時:垂直壁蹴り(上に上昇)

 →壁が無い時:方向キーの方向へジャンプ(横に飛ぶ)

とりあえずこんな感じ。

これだけだとよくわからないので備忘録としてもよろくないですね。

というわけで小分けにして解説。

0.壁に接しているかの判定の関数を作る

上記の1,3で壁と接しているかの判定があります。

これは下記のHPを参考に関数を作成しました。

参照:UE4のBluePrintだけで壁蹴りを実装する

・壁と自機が接しているかの判定関数

こちらは参考HPの組み方まんま。

ちなみに「SphereTraceForObjects」というのはカプセル状のTraceを作って当たり判定を取れるものです。

SphereTraceの位置、大きさ、何との判定を取るかを決めて使用します。

↓Traceってなんぞやっていう参考。

参照:UE4レイキャスト(ライントレース)を使う

キャラのサイズとかは参考HPとは違うので、判定するカプセルのサイズや位置は色々試して調整してます。

あ、純粋化することを忘れずに。

これしないとGetとして使用できません(これ気付くのに小一時間悩んだ)。

※「極み本」を持っている人はP320を読もう!

・方向キーの向いている方向に壁があるかの判定関数

こっちは上記のBPの位置の取得に前回作成した方向キーの変数を組み込んだもの。

これにより倒している方向にカプセルが移動し、そのカプセルが壁と接しているかどうかで方向キーの倒している先に壁があるかないかの判定を行うようにしています。

方向キーがニュートラルの時はキャラのカプセルコリジョンの中にSphereTraceが収まっており、方向キーを倒すと(押すと)その方向にSphereTraceが移動してカプセルコリジョンの外に出てくる、という感じになってます。 これで方向キーの先に障害物があるかの判定を取ってます。

1.ジャンプするか壁蹴りするかの処理

壁との接触判定の関数ができたので早速壁蹴りBP作成へ。

画像見ればすぐわかりますが、空中にいなければ普通のJump、空中にいた場合は先ほど作った関数(自機が壁に接しているかどうか)を利用して壁との接触の判定をとってます。

2.壁と接していた場合の処理

ここで記入している処理は壁蹴り自体に必須のものではなく個人的な操作感を作るために設けているBPなので、ぶっちゃけなくても問題はないです。

①リロード時間を設ける

「DoOnce」と「Delay」で壁蹴りのリロード時間を設けます。これを設けないと挙動が壁蹴りッぽくなくなってしまうためです。

②時期の速度を0にする

これは個人的な挙動処理として入れてます。

なんというか、壁に接して蹴ろうとした時に踏ん張って一旦自機の速度が0になるだろうというのを再現したいから入れただけです。あとは壁に衝突した時の自機の慣性が壁蹴り時の力に悪さしないように。

無くてもあまり挙動が変わらないような気がしたので、このノード入れるかは好みだと思います。

ちなみにこのノードで終わりにすると壁にボタンを押している間はペタッと張り付いているような挙動をします(微妙に重力の影響でずり落ちていきますが)。

これはこれで何か使い道はありそうです。

(壁に張り付いて、ボタンを放したらスティックを倒している方向へジャンプするとか?ロックマンXみたいの作れそうですね)

③壁蹴り中にハイブーストの使用制限を設ける

カスタムイベントを画像の様に設けて、壁蹴りで飛んでいる間は壁蹴り時体はハイブーストとみなしてハイブーストを使用した時間と同じリロードタイムをハイブーストに描ける処理をしています。

これをしないと壁蹴り直後でもハイブーストが使用可能になってしまい、個人的に好みの動作ではなかったためです

④方向キー入力時間を設ける

ここでの「Delay」は壁に接した後の飛びたい方向へ方向キーを倒すためのタメ時間です

これが無いと壁に接触した時に飛びたい方向へスティックを倒しておかないとならなくなり、かなり反応がシビアになるため設けています

ここで一旦Tickを止めるため、方向キーの先に壁があるか判定するまでのちょっとした間ができるので壁に接触してからスティックを倒す余裕ができます。

.壁蹴りするときにどう飛ぶかの処理

①壁がある時:垂直壁蹴り(上に上昇)

0.で作った方向キーの先に壁があるか判定する関数で判定します。

壁があれば上方へ「LaunchCharacter」ノードで自機を飛ばします。

「LaunchCharacter」ノードはキャラを与えれたベクトルへ飛ばすようなノードだそうです。

②方向キーがニュートラルの時:垂直壁蹴り(上に上昇)

③壁が無い時:方向キーの方向へジャンプ(横に飛ぶ)

ここら辺はブログの第4回を参照にBPを組んでます。③は方向キーのベクトルに少し上方へのベクトルを加えることで横に飛びつつ自機の高度を上げることができます。

以上で壁蹴りのBP備忘録メモは終了です。

ここからはオマケメモ

・グライドブースト中に一時的に加速させる

グライドブースト中にジャンプボタンを押すことでさらにハイブーストをかけているように見せて加速させる処理についてのメモ。

まずグライドブースト中は「Movement Mode」が「Flying」になっているので「浮いている」かどうかの判定式をジャンプボタンに設けます。

あとはハイブーストと全く同じ処理をもう一つ設け、ハイブーストの速度に変数をかけた関数(「GrlideHighBoostAcceleaor」)を設けてそちらで速度を上書きするようにして処理してます。

これでグライドブースト中にハイブーストをさらに重ね掛けしているような動作を作ることができます。

リロード時間のノードを無くしてしまえばボタンを押しっぱなしの際は常に加速できるような処理も可能です。ここら辺は完全に好みで、自分ももしかしたらリロード時間取っ払ってしまうかもです。

取り合えずこれでオマケも完成。

なんだか今回は長ったらしくなってしまったなぁ…という感じですが、とりあえずこの程度の情報があれば色々忘れてしまった後でも動きの再現はできそうです。

あくまで備忘録ですので。

次回は「Anthemっぽい飛行モードの実装」にチャレンジ

これができればキャラの動きに関してはやりたいことがほぼ揃うのでなんとか実装したいところ。

……できるかなぁ(;´・ω・)

第5回「グライドブーストっぽいやつ(ボタンの押し込みでハイブースト→グライドブーストへ移行)編」

今回はグライドブーストっぽいやつの作り方メモ

なんで「っぽい」とつけているかというとタイトル通りACV本家と色々違う箇所があるためです

俺は面倒が嫌いなんだ(あんな変態技術作れるかボケ)

本家と同じというのもつまらない、というかそれだったらACVやれよってなってしまうのでここら辺から本格的に仕様を変えていこうかと思ってます

ではまずは下準備から

・スティック方向の取得を変数化

前回作ったスティック方向を取得するブループリントを画像のようにして変数化

これはよく使うので変数化しておかないと面倒です

というか変数化してないと次回の内容ができないので必ず変数化しておきましょう

・ハイブーストの加速処理を関数化

こちらも前回作った画像部分のブループリントを関数化してます。

別に必須ではないのだけれど結構この処理を使いまわす羽目になったため、作業の簡略化と画面をすっきりさせるために関数にしてます(純粋化はしないこと)

※必要なBPを選択しておいて右クリックで関数化するだけ。こんな操作忘れる可能性あるの自分だけだろうけど……

簡易版グライドブーストの作成

で、さっそくグライドブーストっぽいものを作成

これだけ

ね、簡単でしょう?

グライドブーストボタンを押すことでキャラクターの「Movement Mode」を「Walking」から「Flying」に切り替えることでキャラが落下しなくなります。(ついでにジャンプも空中にいると判定されて効かなくなる)

あとはEventTickが「Flying」中に「HighBoostAcceleator」(さっき作ったハイブーストの加速関数)に流れてハイブーストと同じ速度で移動できますよ、となります。

本家と違って今のままだと空中でもグライドブーストできてしまいますが、今回作ろうとしているゲームでは空中でも使えるようにしたいのでその処理はしません。

あと、これはボタンを押すとグライドブーストにモードを切り替えるような処理になってますが今回はハイブーストボタンを一定時間押し込み続けることでハイブースト→グライドブーストへ切り替わり、ボタンを放すとグライドブースト終了としたいのでその処理に挑戦

本家で言えばブーストチャージの代わりにグライドブーストへ移行するイメージですかね?

ボタン押し込みでハイブースト→グライドブーストへの切り替え

とりあえずBP全体像

①ハイブーストと同時にグライドブーストへEventTickを流すゲートをOpen

②ボタンを放すとグライドブーストへEventTickを流すゲートをClose

 同時に「Movement Mode」を「Flying」から「Walking」へ変更

③ あとはハイブーストのボタンを一定時間以上押し込まれているいるかを判定し、グライドブーストへEventTickを流す

という処理で出来てます。ここでのポイントはどうやってキーの押している時間を取得するかです

キーを押し込んでいる時間を取得する

ハイブーストのボタンを押す

→ハイブーストを吹かす時間+α以上ボタンが押し込まれているかどうか

→上記時間以上にボタンが押し込まれていたらグライドブーストへ移行

のような処理を下記を参照につくりました

参照:UE4、Inputの長押し処理の実装

そしてできたものがこちら

「Get Input Key Down」で任意のキーが押されている時間を取得し、それがハイブーストのリロード時間+αの時間より長いかどうかを判定

押してる時間が上記の時間より長ければグライドブーストの処理へEventTickが流れる仕組みとなっています

ハイブーストのリロード時間を取得する理由は、ハイブーストを吹かしている間はグライドブーストへ移行しないようにするためです

最終的にハイブーストを吹かす時間はロボのカスタマイズ時に変更できるようにする予定の為こうした処理にしてます

とりあえずこれでグライドブーストっぽいやつの完成(仮)

次回の壁蹴り編のオマケでグライドブーストにちょっと追加するものがあるので、良ければそちらも見てくださいな

という訳で次回は「壁蹴り編」です

第4回「ACの動きを目指す―ハイブーストもどき編―」

前回に引き続きUE4でアーマードコアVのハイブーストもどきが出来たので、その作り方メモ。

ちなみに前回も触れていましたが、今回のBPは下記の注意点があります。

・ 「Third Person Template」 を使用

・下記のところにチェックを入れている

以上がされていないと同じようなBPを組んでも位置の基準の違いなどで別の挙動になる恐れがあります。

未来の、組んだBP忘れちゃってるだろう自分よ、要注意だぞ!そのための備忘録なんだから……

という訳でこんな動きになるという動画。

まずはBPの全体像

DoOnceとDelayを利用しハイブーストを吹かす時間とリロードの時間を作る。ブーストを吹かしている時間分、キャラクターをコントローラースティック方向に加速させるtickが流れる、という流れになっています。

①ハイブーストを吹かす時間(加速を与える時間)とリロード時間

まずDoOnceにtickが流れることでボタンを連打してもtickが流れないようにする。

そして最初に流れるtickでGateをOpenさせ加速処理にEventTickを流す。

Delayで指定した時間後にGateのCloseにtickが流れ、加速処理に流れているEventTickをせき止める。=これがキャラクターを加速させる時間(ハイブーストを吹かす時間)となる。

またさらにDelayで指定した時間後にDoOnceのRsetにtickを流すことによって再びボタンの受付ができるようになる。=これがハイブーストのリロードタイムとなる。

ここら辺は説明読むより画像見てもらった方が分かりやすいかもですね。

②キャラクターをコントローラーのスティック方向に加速させる

まずはコントローラーのスティック方向を取得する

これは「Third Person Template」の「MobementInput」に画像のBPを追加することで取得する。

参考:BluePrintで左スティックキャラ前方(or後方or右方or左方)なのかどうか取得する方法

あとはスティックの方向に変数を掛けて加速させるだけ。

なお、スティックがニュートラル(値が0の時)はキャラクター(のカプセルを軸とした)の前方向に変数を掛けて前方にハイブーストする仕様になってます。

ちなみにこの処理をしない場合、ニュートラルでハイブーストボタンを押すと0×変数となるためキャラクターの速度が完全に0になりその場でビタッと停止してしまいます。それはそれで面白そうではあるけれど、今回は使用予定はありません。

こっからは余談

またスティックの方向に「×」ではなく「+」を使用すると、X,Y座標軸で考えれば当たり前なんですが、下記のような結果になりキャラが斜めに吹っ飛んでいきます。

仮にスティックを左下に倒したときx=-1、y=-1とする。また変数を+300とすると

スティック方向×変数=(-1、-1)×300=(-300、-300)

→左下に300の速度が与えられる・・・〇

スティック方向+変数=(-1、-1)+300=(299、299)

→右上に299の速度が与えられる・・・×

という感じ。

考えてみれば当たり前なんですけど、最初この考えに至らず+を使ってしまいキャラが斜めに吹っ飛んでしまったのでメモ。

……こんなのに引っかかるの自分だけだろうけど、備忘録だからいいのです!

とりあえず以上でハイブーストもどき完成。

本家はハイブースト発動までに若干チャージがあってその時のボタンの押し込み具合で若干ハイブーストの強さが変わったりと変態的な仕様になってますが、少なくともそこまで作るつもりはありません。フロムは変態すぎる……。

クイックターンも作ろうかと思いましたが、考えてるゲームの仕様的に不要な気がしてきたのでとりあえず今後はブーストドライブ(壁蹴り)とグライドブースト(空中でも使用できるように考えてます)に挑戦予定。

……また高い壁になりそうだなぁ、これ。

次回「ACの動きを目指す―壁蹴りorグライドブースト編―」

来月更新は多分無理!!

第3回「ACの動きを目指す―ブーストON/OFFもどき編―」

UE4でアーマードコアVのブーストON/OFFもどきができたので作り方メモ。

<注意>

ちなみにベースはUE4の「Third Person Template」を使用。

また前回記事の箇所にチェックを入れてることを前提にしてます

ここが違っているとキャラの位置の取得とかの関係で同じBPを組んでも違う結果になってしまうので注意(特に次回のハイブーストもどきづくりでは関係してきます)

まずはブーストON/OFFのBP全体画像

ブーストモードの切り替えtickが流れるとブーストON時のパラメーターとOFF時のパラメーターを交互に上書きしていく流れになっています。といってもこれだけだと何が何だかなので以下に詳細を記載

①ブーストモードの切り替え

これはもう画像の通り。ゲーム開始時はOFFのパラメーターがキャラクターに上書きされ、ボタンを押すとONのパラメーターが上書きされる。それを繰り返す流れになってます

②ブーストON時のパラメーター

1.パラメーターの上書き

まずブーストONにtickが流れると下記のCharacterMovementを書き換える

参考:【UE4】UCharacterMovementComponentのAPIリファレンスを翻訳してみる

ここで書き換えるパラメーターは下記の3つ

「MaxWalkSpeed」

歩行時の最高速度。ここではブーストON時の移動速度になる。

「GroundFriction」

地面の摩擦の強さ。地面上でのすべりやすさ。本家の動きを見ると慣性でスティックを放しても進行方向に少し滑っているように見えたので、ここで数値を低くしてキャラクターを少し滑るようにしている。

「AirControl」

空中での移動のしやすさ。0~1の範囲で決められ、0にすると空中での制御が全く効かなくなる。1にすると地上と同じぐらい制御できるようになる。

2.空中にいるかどうかの判定

まずキャラクターが空中にいるかいないかを「Is Falling」で判定。それをしておかないと画像のBPでは坂を下っていても上向きの力がかかってしまいます

3.落下中にホバリング

次にキャラクターが落下中かどうかを判定。これはどうすればいいのか分からずUE4 answerhubで質問したら回答をいただけました

参考:UE4 answerhub 落下中のキャラクターに上向きの力を加えて落下をゆっくりにしたい

要はキャラクターの速度ベクトルが-(下に下がる)になっているかを判定することで対応しました

あとはその時にターゲットの速度に上向きの力(ホバリングの浮力の力)をくわえるようなBPにしてあります

③ブーストOFF時のパラメーター

こちらはtickが流れたときにブーストONで上書きされたパラメーターをもとの値で上書きするというBPになってます。なのでON時のパラメーターと同じ項目をいじりましょう。

以上でACVのブーストON/OFFもどきを実装できました。細かい挙動は本家と違うけど、そこらへんは調整してお好みの挙動にしましょう。今はまだグレーボクシングを作っている段階なのでそこまでの調整は不要かと思ってます。本家まんま再現する気もないですし、とりあえず一旦完成ということで。

というかもっと改善する方法あると思うのですが今はこれが精いっぱい。もっとこうした方がいいよとアドバイスありましたら、メッセージか何かいただけると感謝感謝でございます。

次回は「ACの動きを目指す―ハイブーストもどき編―」です。