はじめに
今回はこちらを見ていきます
6. ブループリント
理念と概念
- レベルスクリプティングはUEのエディタを通じて行われてきた
- よりアクセスしやすく、素早く操作できるように設計されてきた
- このような指針によりBPが生まれた
UE1 to UE2
- UE1にはイベント及びタグベースのシステムがあった
- アクタをビューポートに配置し、ビューポート自体でビジュアルスクリプティングを行う必要があった
- 何かが空中に浮いていて、また別の何かが空中に浮いていてそれらを接続する必要があった
UE3
- 2006年～
- ビジュアルスクリプティングが導入された、これはレベルエディティングのみが可能だったがレベルにアタッチされていた
UE4
- BPの導入。これはKismet(古いUEの仕組みのよう)を強化したもの
- コードのあちこちにはKismet V2のような記載が残っている
- もはやレベルには縛られておらず任意のクラスから派生可能
- BP
- 汎用的になり、アクセスしやすくなり、パワフルとなった
- チームの誰にとっても強力になりチーム全体の能力を高める
- 影響を最大限に高める
- プログラマーは単純なことから開放されるように設計されている
- 例えば武器のパーティクルを変更するなど
- 簡単に理解出来て、高速に反復できるように設計されている
- この意図により実験を活発にしてチーム全体が関与しやすくなった
- 全体にはC++があり緊密に結びついている
- C++にはプログラミングでも解説したとおりフレームワークがある
- BPとC++にレプリケーションが存在する
- Inheritance(継承)があり、BPはC++から継承している
- データを格納しC++またはBPからそのデータを読み取るためのデータ機能がある
- BP
スキマティック
- 左端(オレンジ円)はC++。BPのすべてはC++を基盤としている
- コアC++とBPの混在機能がある
- データ機能が存在する
- 例えばカーブまたはアセットでC++とBP療法が読み込むことができるもの
- 次にコア機能
- その他
- デバッグ
- BPが使用される部分
- BP間通信
Core C++ BP Supporting Features C++ BPP がサポートしている機能
Framework
- キャラクターの構築という単純な作業の場合、空から作ることはせずテンプレート(ファーストパーソン等)を使用する。このテンプレートはC++に基づいておりフレームワークがここにも存在するためプログラミングで一度触れたがここにもある理由となる。
Optional Data Features
- プログラムのコースでも触れたがこれらのデータを参照しプログラミングで使用する
Core Features of BP
- ブループリントのコア部分
- 下段３つはBPを開いた時に表示されているもの
Contruction Script
Viewport
- BPを構成するコンポーネントの単純なビジュアル表現
Event Graph
- ほぼ全てが存在する場所
Components
- 40を超えるコンポーネントがある
- Audio
- Emitter
- PointLight
- StaticMesh
Variables
- 多数の利用可能な型がある
- 親クラスから派生している
Function
- BP承認済み関数でローカルで存在している
Macro
- Functionに似ているがマクロ
Event Dispatcher
- 呼び出し、バインド可能なイベント
- おそらくあまり使用されていない
- BP間通信を行う方法の１つ
Replication
- BPだけでマルチプレイヤーゲームが数分で作成できる
- よくわかっていないが複数人でゲームをする場合に安全に変数などの情報を渡す為にあるものかな？
Timeline
- BPに埋め込まれているサブエディタ
Additional Features 追加機能
- BPは、これらのオプション機能により、さらに拡張することができます。
- 特定の目的のために設計されている
Child Actors
- アクタ内のアクタ
- BP内の別のBP
- 通常はBPだがBPである必要はない
- とにかく別のものに属するなにか
- 子アクタを使用する前提でゲーム全体を構築しないで下さい
- 用途 例えばプレイヤーが敵に遭遇した時にアクティブな敵である事を示すマーカーを頭上に示す
- そのようなバナーは小さなセットアップで全敵キャラが共通して持っている
- 様々なクラスにそのような小さなセットアップを埋め込むのにChild Actorは最良。らしい
Blueprint Components
Function Libraries/Macro Libraries
- C++が提供するものと同じ
- 1つのBPではなく中立のアセットに定義されプロジェクト内のBPからアクセスできる
Editor Blueprint Scripting
- 旧名: Blutility
- BPを使用してエディタを拡張する
- 3つの方法がある
- Editor Utility widget
- Action Utility
- Editor Utility Object
Editor Utility widget
ユーザーインタフェースを拡張する
Action Utility
右クリックしてスクリプトを確認ができる
Editor Utility Object
エンジンが何かを行っている時にバックグラウンドで自動的に実行される
Compilation
Nativization
- BPをネイティブ化する機能
- クック処理プロセス中にBPをC++コードに変換する
- 大規模プロジェクトではこれを推奨しません
- 調整や実験を行って結果を確認するためのもの
- BPに小規模な変更を加えるためのもの
VM (Virtual Machine)
Parts of the engine using BP (BPを使用するエンジンの一部)
- BPはエンジン全体に完全に統合されている
- エンジンの様々なツールを使用して作業する場合、BPの理解は避けては通れない
- ここではどのように統合されているかを見ていく
Actor Blueprint
- 標準で、最も一般的でエディタ内やツール内でBPが使われる最も明らかな方法
- コンテンツブラウザ内のアセット
Level Blueprint
- それぞれのレベルはBPを含みレベル固有の機能のために使われる
- レベル内のアクタへのハード参照を持っている場合はここに配置する
- レベル内にサブレベルがある場合それぞれ別のBPがある
Anim Blueprint
Sequencer
- 開き方 レベルから Sequencer を検索し選択、詳細からレベルシーケンスを開くを実行
- ここにBPを入れることができる
UMG
- インタフェースをスクリプティングするためのBP
Niagara
- BPでパーティクルの機能を拡張できる
Variants Manager
- BPには埋め込みのルールが有る
- これはエンジン全体に拡散されている
BP Communication
- BPの間、そしてツールの違いを超えて、5つの通信方法がある。
- これを間違えると、メモリ/ロードに大きな影響を与える可能性があります。
- どれを使用するか、いつ使用するかについては様々なメリットデメリットがあり短く説明するのが困難
Direct References
- シンプルで単純
- BPでパブリックになっているものを指す模様
Casting
- 対象を構成している変数が定義されていない場合に使用
- 直接オブジェクト参照が出来ない場合にそのアクタへのキャストして参照する
Interfaces
- 複数のBPで通信する方法のパワフルバージョン
- すべてのアクタのインタフェースにある任意の関数をキャストできる
- ポリモーフィズム用途かな
C++
- 難しいのでスキップ
Event Dispatcher
Performance and Debugging
- BPのデバッグやプロファイルするための様々なビルドがある
- ウォッチャー、ロジックビジュアライザー、BPデバッガー、フロントエンドは最も一般的でパワフルなもの
- 他のクラスですでに見たものもあり、それらは省略します
- FrontEnd エンジン
- Stats プログラミングとワールドビルディング
- Automated Testing エンジン
Stats
- ゲームプレイ中のBPの時間を確認する方法
stat gameコマンド実行後にプレイ
- 動画では Blueprint time という項目があったが、見当たらず。普通ならある模様
- stat を消す場合は
stat none
Blueprint Debugger
- Breakpoint、ステップ実行がBPツール内を通して行える
- Logic Visualizerと一緒に表示される
- Blueprintを表示させた状態でプレイしてデバッグ対象を選ぶと実行中にどこが実行されているか可視化でき
- 変数の値も確認できる
- ブレークポイントも設定可能
- しかし私の環境では デバッグ対象の選択ができなかった。ビルドの方法が違うのかもしれない
Logic Visualizer
- BPは実行時ロジックのフローや変数の値を表示する事ができる
- Blueprint Debuggerと一緒に表示される
Blueprint Watcher
- ウォッチャーパネルを介してトラックされている変数の値を読み込む
- ウィンドウの表示方法
Visual Logger
- 時間をかけて、ビューポート内で視覚的にアクターと変数を追跡
- ウィンドウ表示方法
アドバイス
- かなり高度で数分では説明できないことがたくさんあります
- 検討すべきことの見取り図と成ることを意図しています。
- どのように対処するべきかを正確に説明するわけではない
BP Learning/Usage Strategies BP学習 / 使用戦略
- みんなBPをマスターすべきです
- BPの力を避けないで。利用せずに済まそうとしないで
- 最初に手厚い指導やトレーニングを要求する場合があります
- そうすることでチーム全体で機能構築や微調整に関与できるようになります
- 直ちにスタイルや規約を確立して下さい
- Michael Allar氏のコミュニティで作成されたスタイルガイドは非常に優れている
- 経験豊富な Unreal Engineユーザー
- UE社の内部標準とも非常に似ている
- github.com
References 参照
- BPはコンテンツで必要になった時に読み込まれます
- 他のBPクラスやコンテンツへの参照は、最初のBPがロードされたときにロードされます
- プロジェクトに多大な影響を及ぼします
- 右クリックからサイズマップと参照ビューアが使用できます
- ロードされる時に何が読み込まれるか把握できる
- これを読み込むと1.1Gになりプロジェクトの半分がこのBPを読み込むことで読み込まれる。
- ロードされる時に何が読み込まれるか把握できる
- キャストとほかへの参照は制御されるべきです
- アセットのソフトロードが出来ます
- クラスの適切な階層は役に立ちます
- C++間のブリッジは間違いなく役に立ちます
- 図にある Async Load Asset は必要になったときのみアセットをロードします
- C++とBPの階層例
- InteractiveItem
- BP_Interactive_Item
- 機能追加のBP
- BP_Interactive_Item_Pipe
- Pipeアートのアセットはここにしかない
- BP_Interactive_Item_Bucket
- BP_Interactive_Item_Flashlight
- などなど
- BP_Interactive_Item
上記のようにしておくと BP_Interactive_Item がロードされても、他のコンテンツはロードされないままにする事が可能。
- castは一般的に行って参照を意味していると言って良い
- コア機能は常に存在する
- 状況に依存する機能は時折存在する
- あるレベルで壁にボタンが1つあるとする
- BP_Player から BP_TrafficSpawnerにキャストすることはトラフィックぽーなーが常にメモリ上にある場合以外は良くないアイデア
- BP_Button が BP_Door を参照している場合がある。ちょっとした自己完結グループで特に問題はない
- いろんな種類のものから プレイヤーのような中心となるクラスを参照する事は問題ない
- ブループリント関数ライブラリは常にメモリに存在する静的関数のライブラリ
- 呼び出したい時に仲介役をたてる必要はなく直接呼び出せる
- 図にあるようにコード内ではGame Modeを呼び出しAddEnemyを追加している
- BP上で見るとノードが１つなので変数のように見えるが実際は関数が背景にある事は留意しなければいけない
Balance C++/BP C++とBPのバランス
- 正確なバランスはプロジェクトにより異なる
- どちらも強みがある
- いくつかのおすすめなアプローチ
- 指針はあれどケースバイケースで常に例外はあり好みもある
- C++
- C++はより早い
- ロジック、数学、大きなシステムではより良い
- コア、重要な機能についてはより良い
- BPでは出来ないことも可能
- BP
- 芸達者
- 作成やプロトタイプが簡単
- すぐに反復可能
- より多くのチームメンバーを含む
- より高い柔軟性
- コンテンツとしてみなせる
C++で行ったほうが良いこと
- 一個以上の場所で使用される機能
- tickで使用されるもの。多くのアクターを扱うものなら特に
- 複雑な性質を持ちバグを生みやすくメンテナンスが大変なもの
- 後ほど大々的に拡張される可能性があるもの
- 重要な変数、enumなど
BPで行ったほうが良いこと
- コンテントリファレンスの大半
- 単純で見えている性質のもの
- 一つの機能、孤立した機能、レベルス栗生ティング、コアではない部分
- 局所的に存在してコアでもないということですね
- プロトタイプ段階にある機能、またはスピーディーな反復がされている機能
- C++にしてもパフォーマンス、スケーリング、エラー防止の観点からなんの恩恵もなさそうなすべての機能
Class lay-out
- 常に階層がある
BP Performance
- BPのパフォーマンスはまずまずで問題になることはレアです
- 例外もあります
- BPというよりユーザースクリとに問題がある方が多いです
- PIE = Play in Editor
- Shipping やDevのBPはそこまで重くないがPIEはものすごく思いため、実際のパフォーマンスを表していない点に注意
Ticking/Timiers
- Tickはパフォーマンス損失を引き起こす最も多い原因
- プロジェクト内のすべてのBPでデフォルトのTickをオフにしましょう
- dumpticks をコマンドすればTickしているすべてのリストが参照可能
- 可能であればタイマーとイベントを使いましょう
- Tickは条件に応じて遅くすることも無効にする事もできます
Collaboartions (共同作業)
- BPはバイナリファイルです
- diffコマンドで差異を調べたりマージは出来ません
- しかし組み込みのDiffツールはあります
- BP Diffツールは日課のワークフローの一部ではありません
- BPを別々にして機能を分割することは大人数で作業する最も良い方法です
- いずれにせよ2人のチームメンバーが1つのBPで作業をするという事があるならそれは設計に問題があります
- BP: Cars 車がありますが車の例ではありません
- 他のBPクラスがあり、その上にはC++のCarsがあります
- ヘッドライトの子アクタ
- データテーブルがある
- 上記の図は完全に分割されているためコラボレーションがずっとやりやすくなっている
- どれかがうまく行かなくなっても安全性にも優れている
Errors
- -run=CompileAllBlueprints
- IsValid/IsValidGetter 関数を使用することができます
- 存在しないものが実行されないようにすることを目的にしています
- リファレンスを参照して下さい
- BPは非推奨(Deprecated)としてマークする事ができます。
- Castを用いた戦略を明確にしておいて使いすぎないようにして下さい
メモ
- bug proofing は日本ではバグ防止やポカヨケというみたい
コマンド
- dumpticks
- Tickしているすべてのもののリストを表示する
ノード
UMG
userinterface widget を作る
Add to Player Screen
プレイヤー画面に追加する
