Posted Articles

ゲーム制作's articles. (12)

わんころのUE5勉強会 Aug/21/2023 20:14

【UE5】Add to Viewport の ZOrder にハマったというお話

皆様、こんばんは!

先日から UI(Widget)周りを触っているのですが、タイトル通り「Add to Viewport」の ZOrder でハマってた時のお話になります。


「Add to Viewport」は、「Create Widget(ウィジェットを作成)」で指定した Widget を画面上に表示する時に利用する関数です。


今回ハマった問題ですが、表示した Widget のボタンが昨日まで反応してたのに何かを実装してから反応しなくなったというものでした。
しかも別 Widget で作成したインベントリの方も同じ症状が発生しました。
(ButtonWidget の On Hovered や On Clicked が効かない症状です)





その「Add to Viewport」ですが、関数の下にある▽をクリックして展開すると、ZOrder という引数が表示されます。

ZOrder は描画順(優先順位)で、数値が大きい程手前に描画されます。
デフォルトで ZOrder は 0 に指定されており、特に意識しなければ後から「Add to Viewport」したものが手前に描画されていきます。


例えば WidgetA を作成し、画面の真ん中にボタンを配置しただけの Widget を作成します。

更に WidgetB を作成し、Border を画面全体に入れておきます。

「CreateWidget」で WidgetA、WidgetB を作成しておき、WidgetA→ WidgetB の順で「Add to Viewport」をすると WidgetA のボタンは反応しません。

後で「Add to Viewport」した WidgetB(画面全体の Border) が手前に来ているため、後ろのボタンが触れないようになっているということになります。

そのため、WidgetA を後で「Add to Viewport」するか、WidgetA の ZOrder を WidgetB より高くしておけばこの問題は解決です。


なんだそれだけ...なことなんですが、実はもう一個気づけなかった理由があります。

私のプロジェクトで一部の Widget のみ「Add to Viewport」した後、「Set Visibility」を使って Visible/Collapsed で表示を切り替えていたものがあったんですが、Collapsed になっている Widget が悪さをしているということが分かりました。
(この Widget が画面大半を占める Border を配置しているものでした)


Collapsed で非表示にしていたので、それが邪魔をしているのに暫く気づけませんでした。「Remove from Parent」をしなければ画面上に表示されていなくても ZOrder の影響を受けるということを知れて大変勉強になりました。


この問題に遭遇し、今まで他の Widget に干渉するような画面配置をしたことがなかったんだと思いました。
たまたま被らないような配置になってたということになりますね...

それではまた!

If you liked this article, support the creator with a tip!

Sending tips requires user registration.Find details about tips here.

わんころのUE5勉強会 Apr/12/2023 22:21

【UE5】MetaSoundで同時に鳴らす音を制限する

効果音を鳴らす際、複数の効果音を同時に鳴らすと音が重なり、数によっては音割れや爆音が発生することがあります。

例えば敵Actor を撃破した時に「Play Sound 2D」を使って撃破時の効果音を鳴らしたとします。

1体の敵であればただ効果音が鳴るだけですが、30体の敵が存在し、必殺技などで同時に撃破した場合、「Play Sound 2D」が(多分)30回呼ばれ結果的に効果音が沢山重なって凄い音が鳴ります。


今回は MetaSound を使い、最大で発生する音の数を制限する方法を記事にしてみました。

MetaSound を利用する前に


MetaSound を利用するためにはプラグインを有効にする必要があります。

メニューバー「編集」>「プラグイン」を開き、MetaSound を有効にします(プロジェクトの再起動が促されるので再起動も行います)

※ 本記事を執筆時点では MetaSound は Beta 版となってますのでご注意下さい ※

MetaSoundソースを作成


次にコンテンツブラウザで右クリックし「サウンド」>「MetaSoundソース」を選択します。

「MetaSounds」>「メタサウンド」

「サウンド」の中に別途「MetaSounds」というカテゴリがあります。そこから「メタサウンド」というものが作成できますが「MetaSoundソース」とは役割が違います。

「メタサウンド」の方はオーディオソースとしての入出力(In/Out)は存在しません。

代わりにグラフとしての入出力が提供されており、MetaSound 版の関数のような役割になっています。

例えば音にある効果を掛ける処理を「メタサウンド」で作っておき、実際に「MetaSoundソース」で利用する時にグラフ上へドラッグすると追加することができるため、処理を使いまわすような使い方が可能になってます。(マテリアル関数と同じような扱いかなと思いました)


音を鳴らす最大数を直に設定する

先程作成した「MetaSoundソース」を開き、画面上部の「ソース」をクリックします。

「ボイス管理」>「Concurrency」まで展開し "Override Concurrency" のチェックを入れます。

そうすると "Concurrency Overrides" が編集できるようになります。
ここにある最大数を設定すると音を同時に鳴らす数を制限できるようです。

この方法はその「MetaSoundソース」のみ適用されるので、他の「MetaSoundソース」と設定を共有したい場合は、サウンドの並列処理というアセットを作成することで対応可能です。


サウンドの並列処理

サウンドの並列処理(Sound Concurrency)に関しての公式ドキュメントはこちらです。

サウンド並列処理のリファレンス ガイド


コンテンツブラウザで右クリック>「サウンド」>「サウンド並列処理」をクリックし、適当な名前を付けてこれを開きます。


このアセット開くと先程の "Concurrency Overrides" の項目がアセット化されていることが確認できます。

プロジェクト全体でこの「サウンド並列処理」をデフォルトにしておく設定も可能です。(上記公式ページの「サウンド並列処理アセットを設定する」をご確認下さい)

サウンドの並列処理をMetaSoundソースにセットする


「MetaSoundソース」に戻り、「ボイス管理」>「Concurrency」まで展開し "Override Concurrency" のチェックを外した状態にすると "Concurrency Set" の [+] ボタンがクリックできます。

ここに先程作成した「サウンド並列処理」をセットすればOKです。
(ファイル名は Sound Concurrency の頭文字で SC_ をプリフィックスでつけてます)

この設定だけアセット化されているので他の「MetaSoundソース」でも同じアセットを使いまわすことも可能になりました。
その他の細かいプロパティの説明も公式サイトに記載されております。

おまけ:サウンドキュー


サウンドキューにも同じ設定があるので同じように設定可能です。

If you liked this article, support the creator with a tip!

Sending tips requires user registration.Find details about tips here.

わんころのUE5勉強会 Apr/10/2023 20:34

【UE5】別Widgetを「Add Child」した後、その子Widgetを使いたい

忘れそうなので覚書きです。

はじめに

直前が切れていますが「For Each Loop」を利用し、Scroll Box へ自分で作った WidgetB(子Widget)を「Add Child」していく画像です。

複数の WidgetB が Scroll Box 内に含まれます。

その追加した WidgetB 個別の関数や変数へアクセスしたい時にどうすればいいのかよく分かりませんでした。



Scroll Box から「Get Child...」で調べるといくつかヒットしました。

「Get Children Count」

追加されている子Widget の数を取得できます。
子Widget 分ループする場合、そのまま利用すると配列の範囲外へアクセスしてしまうため -1 する必要があります。

「Get Child At」

指定したインデックスの子Widget を取得できます。
欲しい子Widget はどうやって判断すればいいのか一応確認してみました。

「Add Child」した順番に画面も並んでたので心配する必要はなさそうでしたが、「Add Child」した順番で配列[0]から入ってそうでした。

「Cast To WidgetB」

この後、WidgetB へキャストしてアクセスできました。

まだ未確認ですが、ターゲットが指定できるのなら Blueprint Interface を利用できそうです。


「Blueprint Interface」を利用してみる


適当な Blueprint Interface を作成し、WidgetB に適当な変数を「Print String」するだけの実装を行いました。

結果はそれぞれの変数の値が出力されました。
あとは WidgetB に配置した「On なんとか」系のイベントが実行されたかを WidgetA 側で判断出来たら色々便利そうな気がしなくもないんですが、これも確認出来たら追記しようと思います。


イベントディスパッチャを使う(2023-04-11追記)

前述の WidgetA で「Add Child」した WidgetB に「Onなんとか」系のイベントがあった場合、それが実行されたかを親で知ることができないかなと思い Twitter に書いたところとても丁寧にご回答頂けました!

https://twitter.com/NelisLuna/status/1645449379397111810

まさにこの通りの実装で実現が可能でした。
ネリスさん、本当にありがとうございます!!
今後絶対使うテクニックですね!!




あまり使ったことがなかったため、バインドするイベントはカスタムイベントを作成してバインドしないと駄目なんだと思ってました。

そのため、関数内でのバインドに利用できないと勝手に思い込んでたのですが、バインドするイベントから引っ張ると「Create Event」というものがあり、更に "一致する関数の作成" を選択すると、その関数をバインドすることも可能でした。

これで通知するための手段が増えたので嬉しいですね~~!

If you liked this article, support the creator with a tip!

Sending tips requires user registration.Find details about tips here.

わんころのUE5勉強会 Jan/01/2023 00:00

【UE5:検証】Enhanced Input:Priority や Consume Input

皆様、あけましておめでとうございます!!
今年も一年宜しくお願い致します!

2022年で一番触ったはずの Enhanced Input が未だによく分かっていません。
すべての始まりである「Add Mapping Context」も初心者の私にはややこしかったため、色々確認したことをまとめた記事になります。

【この記事の内容を YouTube の動画で公開】
https://youtu.be/j8pUpNu8CuE


「Input Mapping Context」を記載するのが長いので、以降 IMC と記載しています。

Add Mapping Context


Enhanced Input を触った時に一番最初にお世話になるノードだと思います。

機能としては "Mapping Context" で指定した IMC を追加し、入力を使えるように準備します。

"Priority" で入力の優先度をつけることができます。
数字の大きい方が優先度が高くなります。


2023-01-02 追記:
"Options" ですが、とても重要なオプションであることが分かったため追記致しました。
どういうオプションなのかについてページ下部の「Ignore All Pressed Keys Until Release」に追記しております。


抑えておくメインの機能についてはたったこれだけです。
これだけなんですが、どういう挙動を示すのかを見ていくと意外とややこしいです。

しかも Enhanced Input を使う上で絶対理解した方がいい挙動ばかりでした。


▼ Enhanced Input の公式ドキュメント
https://docs.unrealengine.com/5.0/ja/enhanced-input-in-unreal-engine/

公式ドキュメントにこのような記載がされています。

適用したコンテキストに優先順位を付けることで、同じ入力を受け取る複数のアクション間の競合を解決できます。

複数の IMC があり、それぞれで IA_Jump という同じ入力アクションを設定した場合、ジャンプボタンを押した時にトリガーされるのは1回なのか、複数回なのか気になりますよね。

この記事はその優先順位に注目しています。
そんなわけで下記いくつか検証を行ってみました。

検証の前に

今回の検証ではジャンプのトリガーを基準に見てみます。


まず IMC_A と IMC_B の2つを用意し、両方に入力アクションの「IA_Jump:スペースバー」を割り当てています。

IMC_A は Triggers に Pressed を指定しています。
(Pressed はキーを押した瞬間トリガーされます)

IMC_B は Triggers に Released を指定しています。
(Released はキーを離した瞬間トリガーされます)

また、入力アクション IA_Jump には Triggers/Modifiers は設定していませんが、大事な設定なので "Consume Input" に赤枠をつけています。
最初は ON の状態で確認します。



トリガーの確認方法ですが、ジャンプがトリガーされた時「Print String」で "Jump" と出力するようにしました。

押した離したでどうなるか見ていきます。

検証1:IMC_A の優先度を高くする


「Add Mapping Context」の Priority を IMC_A が高くなるようにしました。

プレイして確認すると IMC_A の Pressed 入力が優先され、スペースバーを押した瞬間に1回トリガーされます。

IMC_B の Released はトリガーされません。


検証2:IMC_B の優先度を高くする


今度は IMC_B の Priority が高くなるようにしました。

プレイして確認すると IMC_B の Released 入力が優先され、スペースバーを離した瞬間に1回トリガーされます。

IMC_A の Pressed はトリガーされません。


検証3:同じ Priority にする


今度は両方の Priority を同じにしました。

プレイして確認すると後で追加された IMC_B の Released 入力が優先されスペースバーを離した瞬間に1回トリガーされます。

IMC_A の Pressed はトリガーされません。
同じ Priority の場合は後から追加したものが優先されます。


ここまでの結果で、入力が被った場合は Priority の高い方が優先され、同じ場合は「Add Mapping Context」で後から追加したものが優先された入力になることが分かりました。


検証4:割り当てるキーが違う場合


今度は IMC_B のスペースバーの代わりにマウスの右クリックを割り当てました。

入力の被りがなくなった場合はどう処理されるかも見てみます。
結果は Priority に関係なく両方ともトリガーの対象になります。

IMC_A のスペースバー(Pressed)と、IMC_B の右クリック(Released)が両方とも利用できるということです。

同じ IA_Jump を使ってるので Priority の高い方が優先されるのかなと思いましたが、キー入力も完全に一致してる時じゃないと効果はないようですね。


この設定をちぐはぐにしておくメリットがあるのか分かりませんが、入力があっちもこっちも反応してる場合はこの辺りを見直したほうが良いかもしれません。

検証5:Consume Input とは?

※ IMC_A と IMC_B 両方ともスペースバーの入力に戻しました


ここまでの検証は "Consume Input" が ON でした。
OFF にするとどういう挙動になるかも見ていきます。

結果は Priority に関係なく両方ともトリガーの対象になります。

入力はどちらもスペースバーですが、押した瞬間、離した瞬間それぞれでトリガーされるということです。

"Consume Input" は入力が被ったキーがあった場合、優先度が低い入力も処理するか?という設定になることがわかりました。

2023-01-03 追記:検証6:複数の IMC で入力アクションは異なるが同じキーを割り当てた場合


今度は IMC_B に違う入力アクション IA_Jump2 を割り当て、キーはスペースバーで同じキーを割り当てました。

入力イベントは異なっているが、割り当てたキーは同じというシチュエーションです。

この結果は Priority の高い方が優先されます。
それぞれの入力イベントでトリガーされるだろうと思っていたので意外でした。

検証の結果

ここまでの結果で、Enhanced Input の入力は、入力アクション(IA_○○)よりも割り当てたキーが被っているかどうかを優先的に判断し、その結果を Priority や Consume Input に準じて処理するという結果になっています。

入力が競合しないようにと、簡単に書いてましたが、
細かい挙動はドキュメントを見ただけでは分からない内容ばかりでした。



ただ追加するだけですが、設定によって色々なパターンがあることが知れて非常に勉強になりました。


IMC はキャラ移動用や UI 操作用など、ゲーム内で必要な新しい入力を追加することができるので、優先度について知っておくことは今後必要になると思います。


おまけ1:Remove Mapping Context


"Mapping Context" で指定した IMC を削除します。
IMC がなかった場合はエラーや警告もなさそうでした。

主に「Add Mapping Context」で追加した IMC を削除する時に利用することになると思います。

一例ですが、インベントリを開いた時に 「Add Mapping Context」で UI用の入力を追加し、閉じる時に「Remove Mapping Context」で削除するような使い方が出来ます。

IMC がアセット単位のためこういう付け替えが容易にできるのは非常に嬉しい機能です。


おまけ2:Clear All Mappings


追加したすべての IMC を削除できます。

ゲーム中タイトル画面に戻ることを想定した時、色々な IMC が追加されていることも予想されるため「Clear All Mappings」で綺麗にしてから必要な IMC だけ「Add Mapping Context」をするなどの初期化系の処理に使えそうです。

2023-01-02 追記:"Options"ピンの Ignore All Pressed Keys Until Release

先に Twitter へのリンクを貼っておきます。
https://twitter.com/UE5wancoro/status/1609488690421837825

どういうシチュエーションなのかというと
IMC_A に IA_OpenPauseMenu という入力アクションを用意し、Escキー(Pressed)で Pauseメニューを開くという実装をしました。

Pauseメニューを開く際、Pauseメニュー専用の IMC_Pause を「Add Mapping Context」で追加します。

IMC_Pause には、IA_ClosePauseMenu という入力アクションを用意し、同じく Escキー(Pressed)で Pauseメニューを閉じるという実装しました。

Pauseメニューを閉じる際、IMC_Pause を「Remove Mapping Context」で削除します。


こういうシチュエーションで、IMC も入力アクションも Open/Close で違うけど、両方同じキーを割り当てたという内容です。

Escキーで Pauseメニューを開くと、なんとメニューが開く→ 閉じる→ 開く...と Escキーを押しっぱなしの間これがループします。

「Add Mapping Context」で違う IMC を追加したにも関わらず、入力アクション(入力イベント)も違うのに、入力はフラッシュされず押した状態が継続しているということになり普通にまずい挙動です。

期待していた動作は Escキーを押せばメニューがちゃんと開き、もう一回押したら閉じるという動作です。


その前に、この動作については historia 様が公開して下さっているこの記事で解決できます!
本当にありがとうございます!!

▼ [UE5][C++]EnhancedInputで独自のInputTriggerを作る~UIカーソル高速移動編~
https://historia.co.jp/archives/26608/




補足となりますが「Add Mapping Context」「Remove Mapping Context」の "Options" は「Modify Context Options 構造体」となっていて、画像のようにピンを分割することができます。


右側のようにピンを分割するか、「ModifyContextOptionsを作成」ノードを使うと出てくる "Ignore All Pressed Keys Until Release" のフラグにチェックを入れれば先程のメニューが開いて閉じてのループはなくなります。

注意したい点は "Options" ピンが結合されている状態だと先程のループする症状が発生するということです。

"Options" ピンを分割するとデフォルトでチェックが入っておりループはしません。

恐らくデフォルトで "Ignore All Pressed Keys Until Release" が False になっていると思われるので、明示的に True にしておく必要があるようです。

今まで使った事がなかった "Options" ですがこんな大事な設定が隠れているなんて思いませんでした。
これを知らずにデバッグしても解決策は見つからなかったと思いました。


押しっぱなしで反応してもいいケースや、そういう挙動にならないケースであれば False でいいと思いますが、これからは「Add Mapping Context」と「Remove Mapping Context」の "Options" ピンは分割し、True でも False でも明示的に設定しようと思いました。

年明けからまた勉強になりました。


「Add Mapping Context」は追加と Priority を決めるだけで簡単に利用できるためか、細かい検証をしている情報には辿り着かなかったためこの記事を公開してみました。


今年は一本ゲーム完成を目指したい所です!!

If you liked this article, support the creator with a tip!

Sending tips requires user registration.Find details about tips here.

わんころのUE5勉強会 Dec/18/2022 21:26

【UE5】プレイ開始時(PIE)にViewportを1回クリックしなくても操作可能にする

UE5 のエディタ操作でプレイして確認する時、
一度 Viewport をクリックしないと操作ができませんが、設定やノードを利用することで対処が可能です。


メニューバー「編集」>「プロジェクト設定」を開き
レベルエディタ内にある「プレイ」から「ゲームでマウスコントロールを取得」にチェックを入れるとプレイ時にすぐ Viewport をフォーカスしてくれます。


他にもゲーム開始時にロードされる場所(例:レベルBP、作成した Player Controller、Game Mode 等の「BeginPlay」)に「Set Input Mode Game Only」を繋げておいても開始時 Viewport にフォーカスしてくれます。
(画像はレベルブループリントの「BeginPlay」)

これでエディタ操作上でプレイ開始時にすぐプレイヤーを操作できるようになるので、ゲーム制作中は便利なオプションになりそうです。

If you liked this article, support the creator with a tip!

Sending tips requires user registration.Find details about tips here.

1 2 3

Search by Article Tags

Monthly Archive

Search by Exclusive Perks

Search Articles