投稿

[UMG]インベントリシステムを作る

イメージ
この記事を読むと、UMGで図1のようなインベントリシステムが出来上がります。

はじめに インベントリシステムは多くのゲームで使われるシステムで、UE4でこれを実現する方法を調べると、既にたくさんの人が実装方法を紹介しています。特に役に立ったのは以下の2つのページです。 ビデオチュートリアルフォーラムでの議論 作り方としてはドラッグ&ドロップ関連の、既に用意された関数を少し実装することで、簡単に作ることができるようです。今回は、図1のような「要素の交換が可能」なインベントリシステムの実装方法を紹介します。 ドラッグ可能ウィジェットの作成 まずは、ドラッグ可能なウィジェットを作成します。図1における、カーソルで掴んで移動しているウィジェットの部分です。はじめに、UI_DraggableElementという名前のWidgetBlueprintを作り、図2のようなレイアウトにします。
SizeBoxを図2の赤い部分のように設定します。サイズは128*128で固定して、SizeBoxにマウスオーバーしたときにカーソルの見た目を手形にするために、CursorをHandにします。 SizeBoxの子ウィジェットにはNamedSlotを配置します。ここでのNamedSlotは、UI_DraggableElementの見た目をHUD上で変更するためのものです。
次に、図3のようにOnMouseButtonDownを実装します。
関数のオーバーライド一覧からOnMouseButtonDownを選んで関数を作成し、次に、その関数をDetectDragIfPressedノードを用いて図3のように実装にします。これで、UI_DraggableElement上でマウスの左ボタンが押されると、DetectDragが通知されるようになります。
次に、図4のようにOnDragDetectedを実装します。
こちらも同様に、オーバーライド一覧から作成します。関数はCreateDragDropOperationノードでDragDropOperationオブジェクトを作成し、それを返します。ここで作成したDragDropOperationは、ドラッグ&ドロップ関連の様々な関数が実行される際に、引数として渡され、その実装で自由に使用することが出来ます。
このノードの引数の意味は次のようになります。 Class…

[UE4]ベンチマーク結果に応じて描画品質を変える

イメージ
はじめに UE4の[Settings]->[Engine Scalability Settings]には、品質をまとめて設定するボタンがあります。特にAutoボタンは、品質を自動決定してくれる便利な機能です。

品質はランタイムで変更することができます。詳しくはalwei氏の記事が参考になります。基本的には、図2のようにGetGameUserSettingsノードでGameUserSettingsオブジェクトを取得して、Set~ノードで品質の各項目を設定し、ApplySettingsで設定を反映させます。

今回はその中でも、図1のAutoボタンに相当するRunHardwareBenchmark&ApplyHardwareBenchmarkResultsノードを紹介します。
ベンチマーク結果に応じて品質を変更
図3のようにノードを設定すると、Autoボタンに相当する結果が得られます。 各ノードについて説明します。 RunHardwareBenchmarkは、ベンチマークを行うノードです。ただし、これはSet~ノードと同じで、ノードを実行してもベンチマークが行われるだけで、その結果による最適な設定を反映しません。Set~ノードではApplySettingsノードを実行することで設定を反映するように、RunHardwareBenchmarkノードではApplyHardwareBenchmarkResultsノードを実行することで、ベンチマーク結果による最適な設定を反映します。 RunHardwareBenchmarkの引数は次のようになっています。 WorkScale:ベンチマーク試行回数CPU Multiplier & GPU Multiplier:ベンチマーク結果の倍率 WorkScaleはベンチマークの試行回数です。最終的なベンチマークの結果は、複数回行われるベンチマーク結果の総和をWorkScaleで割ることで得られる平均となります。WorkScaleが小さいほど試行回数が少なく、計算量は減りますが、結果の信頼性に関わるため、通常はこの値は変更しない方が良いかと思われます。 CPU MultiplierとGPU Multiplierはベンチマーク結果の倍率で、この値が高い程、高い品質(負荷 高)を維持しようとし、値が低いほど、低い品質(負荷 低)に抑…

[UBT]ビルドイベントで自動ローカルバックアップ環境を作る

イメージ
今回はUE4でビルドイベントを使う方法を紹介します。
はじめに UE4プロジェクトの構成プロパティは少し特殊で、UBT(UnrealBuildTool)を使う都合上なのか、図1のように、設定できるプロパティが隠蔽されています(実際にはUBTを通して設定している、ということだと思われます)。
ここで、図1の右側には「ビルドイベント」や「カスタムビルドステップ」というものが確認できます。これは文字通りビルド前や後に、任意のコマンドを実行できる機能です。何に使うべきかイマイチ思いつきませんが、かなり昔、実行ファイルに必要なdllのコピーに使った記憶があります。
図1の左側にはこの項目が存在せず、機能として利用できないように見えますが、調べてみると、使用する方法が提供されていることがわかりました。今回は、これをUE4上で使用してみます。 Pre/Post build step in UBT プロジェクト全てをコピーするビルド後イベントを追加するによって、自動でローカルバックアップを作成してくれる環境を整備してみます。 .uprojectを次のようにしました。 Moduleの[]の後ろにカンマを置き、"PostBuildSteps"以下を実装しただけ(17~22行目)です。
コマンドは、UE4のプロジェクトをDドライブのUE4Project_LocalBackupディレクトリに丸ごとコピーする、といったことをしています。
詳細を少しまとめます。
まずxcopyコマンドですが、これはファイルをディレクトリ構造ごとコピーするコマンドです。詳しくは、こちらを参照してください。これにプロジェクトのパスを指定することで、プロジェクト内の全てのファイルをディレクトリごとコピーしようというアイデアです。
次に、ソースとして指定している$(ProjectDir)ですが、これはプロジェクトのディレクトリへのパスを表すマクロ(もしくはPATH、環境変数? 正しい名称はわかりません……)です。このように書くと、実行時に$(ProjectDir)の部分がプロジェクトへの絶対パスに置き換わります。使用可能なマクロはUE4のソースコード上に書いてあります。
ターゲットには、DドライブのUE4Project_LocalBackupディレクトリを指定しました。このディレクトリはコマンド…

[UnrealC++]UE4における正規表現について

イメージ
今回はUE4で正規表現を使う方法について紹介します。
はじめに UE4で正規表現を使うには、FRegexMatcherFRegexPatternを使います。 これらのクラスの実装(ICURegex.cpp)を見てみると、unicode/regex.hをラップして実装していることが確認できます。上記のFRegexMatcherとFRegexPatternのドキュメントを見ても関数の詳細が書かれていませんが、ICURegex.cppの実装とここを見れば関数の詳細を調べることができます。 UE4で使用されている正規表現は、名前から明らかにICU正規表現です。ICU正規表現のドキュメントはここにありました。把握するのが億劫になりますが、よく使う量指定子やキャプチャなどの書き方は、他の正規表現と大きく変わるものではありません。適当に検索した正規表現の書き方入門にあるものを参考に書いても、問題なく動くはずです。 正規表現のパターンを作る 今回は、文章の中に埋め込まれた「イベントの番号」を取得する方法について考えます。 例えば、次のような文章があります。
「この文章は<event 23>正規表現のテスト<event 551>です。」
この文中から、<event 23>と<event 551>をマッチさせて、キャプチャによって23と551を取得する正規表現を考えます。次のようにしました(筆者は正規表現にそれほど詳しくないので、見苦しい書き方があった場合は指摘するか大目に見てください)。
"< *event *([0-9]+) *>"
「<」は埋め込みの開始文字です。 「 *」は、スペースの0回以上の繰り返しにマッチします。「<event~」や「< event~」や「<      event~」のように、<とeventの間の任意の空白に対応するようしました。 「event」は埋め込みの識別文字です。 「 *」は前述と同じです。「~event21~」や「~event 345~」や「~event       8~」のようにeventと数字の間の任意の空白に対応するようにしました。 「([0-9]+)」は、1回以上の数字の繰り返しにマッチします。()は、キャプチャのために記述してい…

[UMG]マウス入力を阻害する-後編-

イメージ
今回は、前回の続きです。
前回は、Visibleなウィジェットを配置すると、それより後ろにあるウィジェットはカーソルとインタラクティブできないという内容について紹介しました。

実は、前回紹介した内容では、カーソルとのインタラクティブを完全に阻害できない例外があります。それが、アクターがクリックされたことを検出する「ActorOnClicked」イベントです。

ActorOnClicked イベントの作り方 はじめに、ActorOnClickedイベントでクリック入力を受け取るところまで紹介します。 まず、図1のように、PlayerControllerの「EnableClickEvents」を有効にします。
次に、クリックしたいアクターのコリジョンを確認します。コリジョンが有効でないと、ActorOnClickedは発生しません。図2はデフォルトのままですが、NoCollisionになっていなければ、とりあえず大丈夫かと思います。
最後に、図3のようにイベントグラフ上にActorOnClickedノードを追加すれば、アクターをクリックした時の処理を追加できるようになりました。このアクターをクリックすると、Helloと画面に出力されるようになります。
さて、これでアクターがクリック入力を受け取れるようになりましたが、これは前回のUMGによる手法では阻害できず、ActorOnClickedが実行されてしまいます。 今回に限っては、Branchで処理をはじく、Collisionを無効化する、EnableClickEventsをFalseにする等の方法が考えられます。ですが、それらの方法ではなくUMGによって阻害する方法を紹介します。
Buttonによって入力を阻害する 前回のSpacerのように、マウス入力を阻害するウィジェットとしてButtonを配置します。今回はどんなウィジェットでも良いわけではなく、Buttonでなければなりません。また、図4の右端のように、Buttonの前面をVisibleなウィジェット(図4ではBackgroundBlur)で覆うようなレイアウトは駄目です。
このままではButtonが見えてしまっているので、Spacerなどと同様に不可視にするため、Buttonの見た目を変更します。図5のように、次の項目を設定します。 画面全体に広げる(設定は親パ…

[UMG]ディゾルブエフェクトもできる、RetainerBoxについて

イメージ
RetainerBoxについて紹介します。これを使うと、例えば図1のようなUMG用ディゾルブエフェクトを作成することも可能です。

RetainerBoxとは Optimization(最適化)に分類されるウィジェットです。Retainer Boxの子ウィジェットの内容を、テクスチャ(RenderTarget)に指定間隔でオフスクリーンレンダリング(OSRと略します)し、その結果のテクスチャをスクリーンに描画するウィジェットです。OSRは毎フレーム行われるわけではなく、OSRが行われないフレームの間は最後にOSRされたテクスチャを再利用することでスクリーンへの描画負荷を減らします。 子ウィジェットの内容が複雑なものである場合、OSRの頻度が少ないほど描画パフォーマンスが向上する可能性があります。ただし、OSRの頻度を「毎フレーム」に設定したりすると、OSRされたテクスチャをスクリーンに描画する「二度手間」がある分、逆にパフォーマンスは悪化すると考えられます。今回は最適化の話に焦点を合わせませんが、使うときはパフォーマンスに留意する必要があると思われます。
今回は、Retainer Boxを用いたエフェクトを主に紹介します。実は、Retainer BoxはOSRされたテクスチャをスクリーンに描画する際、マテリアルによって描画内容を変えることが可能です。これはBorderやImageウィジェットのBrushにエフェクト用マテリアルを適用するのとは異なり、Retainer Boxにエフェクト用マテリアルを適用すると、子ウィジェット全てに対してエフェクトが適用されるのと同じ表現ができます。

Retainer Boxを使ってみる 前準備として、図2のようなUser Widgetを作成します。今回は、これをRetainer Boxの子ウィジェットにして全体にエフェクトを適用します。

まず、図2のウィジェットをRetainer Boxでラップして、図3のようにします。余談ですが、ウィジェットをラップするときはコピー&ペーストで作るより、Wrap With...の中から親としたいパネルウィジェットを選ぶ方が簡単です。

次に、Retainer BoxのEffect Materialにマテリアルを設定します。ここではCreate Materialを選んで、新しいマテリアル(アセット名は…

[UMG]カーソル入力を阻害する-前編-

イメージ
はじめに 今回は、UMGのテクニックを紹介しようと思います。
図1を見てください。Open Dialogボタンをクリックすると、図2のようなダイアログが表示されます。


このダイアログシステムには、ダイアログ表示中にOpen Dialogボタンを再クリックできてしまうという問題があります。
Open Dialogボタンを再クリックさせないための方法はいくつかあります。はじめに思いつくのは、Open Dialogボタンがクリックされたとき、ボタンのVisibilityをHit Test Invisibleに変更して、クリック不能にする方法です。しかし、この方法はHUDに新しいボタンが追加されるたびに、それぞれのボタンのVisibilityを変更しなければならず、あまり良い設計とはいえません。

カーソル入力を阻害する これを解決するために、ダイアログの後ろにカーソル入力を阻害するウィジェットを配置する方法で、再クリックさせないようにします。ウィジェットは何でもいいのですが、今回は見た目のないSpacerを使います。まず、図3のように、ダイアログの後ろにSpacerを配置します。

次に、図4のように、VisibilityをVisibleに変更し、配置したSpacerを画面全体に広げます。画面全体に広げるのは、Spacerより背後にある全てのウィジェットを覆い、その全てのウィジェットのカーソル入力を阻害するためです。今回はSpacerの親がOverlayなので、AlignmentをFillに設定すれば画面全体に広げられます。親がCanvas Panel等の場合は、別途Anchors等を変更する必要があります。これだけで、Spacerより後ろにあるボタン{1}とのインタラクティブが阻害され、Open Dialogボタンは再クリックできなくなります。

何故カーソル入力が阻害されるか 次の表はVisibilityによる違いをまとめたものです。Visibleだけが背後のウィジェットとのインタラクティブを阻害するという特徴をもっていることがわかります。前にSpacerをVisibleに変更したのは、Spacerが遮る背後のウィジェット(ここでは、Open Dialogボタン)とのインタラクティブを打ち切るためだったわけです。
また、「ウィジェットは何でもいい」と書きましたが、これは…