UE4には4.19からPythonがスクリプトプラグインとして組み込まれている。以前からLuaなど好きなスクリプトエンジンをソース組み込みできたが、プラグインかつ標準組み込みとなったことで今後Pythonの活用が進むと思われる。

そこで、UE4上で動くスクリプトのプラグインのPythonの２種類（公式¹、3rd Party）とJavaScriptについて比較してみた。

比較表

※2018-08-25現在

• 補足
  • ※1：githubのものをビルドすることで4.20に対応
  • ※2：エンジンをソースからビルドすることで3系統に対応
  • ※3: 3.6以外は別途python実行エンジンのインストールが必要

302 Found

docs.unrealengine.com

20tab/UnrealEnginePython

Embed Python in Unreal Engine 4. Contribute to 20tab/UnrealEnginePython development by creating an account on GitHub.

github.com

Unreal.js in Code Plugins - UE Marketplace

Javascript runtime built for UnrealEngine

www.unrealengine.com

対応UE4 ver.

公式Pythonは比較的最近のver.にしか対応しない。UnrealEnginePython、Unreal.jsは古いver.でも対応する。

Unreal.jsはやや最新ver.への追従が遅い（githubのソースをビルドして導入することで最新にも対応する）。

言語ver.

対応するスクリプトの言語のver.の比較。

公式のPythonプラグインの問題として2系統であることが一つあげられる。というのも、Pythonの2系統は2020年までのサポートとされているため将来性に乏しい。

なぜ２系統なのかというと映像制作系の業界基準ガイドライン「VFX Reference Platform」の最新でもPython2が指定されているためとされており、これに合わせた形らしい。

VFX Reference Platform

VFX Platform : Reference Platform for VFX Software

www.vfxplatform.com

なお、UnrealEnginePython、Unreal.jsに関してはそれぞれの言語の比較的新しいものが使える。

提供形式

いずれもプラグインであるが提供方法はバラバラ。

• 公式Python
  • 既に入っているので有効化する
• UnrealEnginePython
  • githubからバイナリをDLしてくる
• Unreal.js
  • Market placeから導入
  • 最新盤はgithubからソースDLしてビルド

対応実行プラットホーム

公式のPythonはそもそもエディタオンリーのため、モバイルでは動かない。

UnrealEnginePython、Unreal.jsに関してはAndroidのサポートの記載がある。

ランタイム実行

公式のPythonはエディタ上でのみ使用可能。つまりPythonでゲームを作ることはできない。

UnrealEnginePython、Unreal.jsはランタイム実行に対応。つまり、PythonやJavaScriptでゲームを作れる。

エディタ実行

どのプラグインもエディタ上で実行可能。エディタのマクロやバッチ処理的なことができる。

GUI付エディタ拡張

専用のUIを持った、ツール的なエディタ拡張ができるかどうか。
公式のPythonは将来的には対応予定があるらしいができない。
UnrealEnginePython、Unreal.jsは可能。複数のサンプルあり。

専用コンソール

インラインでスクリプトが実行できる専用のコンソールがあるかどうか。どのプラグインも用意されている。

• 公式Pythonは標準のOutput Logコンソールを切り替えることで専用コンソールになる
• Unreal.jsのJavaScriptコンソールはAPIの補完機能がある
• UnrealEnginePythonは専用のテキストエディタさえもある

まとめ

• 公式のPythonは導入が簡単
• 公式のPythonはPython2系統で将来性に不安
• 公式のPythonはエディタ実行のみ
• 公式のPythonは（まだ）GUIのあるエディタ拡張が作れない

おまけ：APIの比較

膨大になってしまうので詳細な比較は避けるがざっと見た感じの差。

• 公式のPythonはローカライズの機能がある
  • Unreal.jsはローカライズの機能にアクセスするのは難しい
• UnrealEnginePythonはSlateにアクセスするAPIが充実している
  • Unreal.jsもSlateへアクセスできるが間接的/部分的なAPIになっている
• Unreal.jsはBlueprintと相互に連携できる
  • UnrealEnginePythonはBP -> Pythonができるかどうか不明
  • 公式Pythonは両方向とも不明

UE4のエディタにデフォルトで使われているフォントには誤読しやすい問題がある。特に顕著なのはIとl(大文字のアイと小文字のエル)、Oと0（大文字のオーとゼロ）の区別。これは誤読の原因になったり、スペルミスに気が付かないと言った問題を引き起こす。UE4はアセットのリネームに癖があるので、リネームせざるを得ない状況を起こしやすいのも問題である。

そこで『UE4Editor Customize』というプラグインを使って、特にContentBrowserのフォントを区別しやすいフォントに差し替えて誤読を減らしてみる。

『UE4Editor Customize』プラグイン

MarketPlaceから無料で導入できる(2018-07-28現在)。

UE4Editor Customize：コードプラグイン - UE マーケットプレイス

Change UE4Editor To a New Style

www.unrealengine.com

サンプルの画像を見てわかる通りエディタに背景画像を表示したりもできるのだが、今回は　フォントのカスタマイズ機能 を使用する。

フォントの選択

誤読防止なので以下などが区別のつくフォントを選択する。

• Oと0
• Iとl

この辺りはプログラミング用などに用意されたフォントであれば考慮されている事が多いので調べてみるとよいだろう。

今回は例として「VLゴシック」を選択した。

VL Gothic Font Family

vlgothic.dicey.org

フォントアセットの用意

フォントファイルを元に、アセット化する。といっても特別なことは何もなく、ゲーム中のUIで使用するときと同じように作ればよい。

ContentBrowserのAdd New > User Interface > Fontと選び、新規Fontアセットを作成する。Add Fontからフォントのotfやttfファイルを選択する。

上記の例はVLゴシックの例。VLゴシックはフォントファミリーとして等幅とプロポーショナルがある。今回誤読防止で使用するのは等幅の方（VL Gothic Regular）になる。

プラグインを有効化して設定

『UE4Editor Customize』を導入後、Pluginsから有効化して再起動する。
有効になると、Project Settings > Pluginsの中に「UE4Editor Customize」が増えているので選択する。

設定画面の下の方に「Text Style」というテキストのスタイルをカスタマイズできる箇所があるのでここでフォントを先ほど作成したフォントアセットを指定する。

ContentBrowser上のアセット名のフォントを変える例は以下になる。

Content Browser以下の,
– Asset Tile View Font Name
– Asset Tile View Font Name Small
– Asset Tile View Font Name Very Small

それぞれのFont Familyを事前に用意したフォントに差し替えると置き換わる（例：VLGothic）。
※VLゴシックのように等幅・プロポーショナルなど複数入っている場合は、Type Faceで選択する(VL Gothic Regular)。

無事に置き換えが済むと以下のようになる。

比較

_	差し替え前	差し替え後
表示

マニュアル

プラグインの公式マニュアルにはどこの設定がどこに当たるのか、画像付きで説明がある（英語のみだが）。

UE4EditorCustomize Documentation

jack-myth.github.io

Content Browser以外のフォントも変えられるのでごっそり変えてしまってもよいだろう。

注意点

• 実験的プラグインとされている
  • 実際、再起動しないと反映されないこともあった
• 最新の4.20はまだ未対応

追記(2018-08-05)

UE4 Editor Customize プラグインが #UE4.20 に対応。 #ue4arketplacehttps://t.co/2J1bvTaSMB

— K. S. (@ConquestArrow) 2018年8月5日

間違い探しに挑戦！

まずは次のグラフを見てほしい。

A,B,C,Dの４つのブロック（関数ノード、Get変数ノードの組）がある。A,B,C,Dはすべて異なるノードで構成されている。さて、どの辺が違うのかよく見てほしい。

分かった人は次へ。分からない人も次へ。

答え合わせ

• Aは特に _ を使用していない
• Bは語頭に _ を使用。関数ノード名でスペースが多いことに気が付いた人もいるだろう。
• Cは語尾に _ を使用
• Dは単語の区切りに _ を使用

おそらく大半の人がBの関数ノード以外の違いを見分けられなかっただろう。

なんでこんなことがおきるのか？

グラフエディタ上では_はスペースに変換される、という機能があるため。

元々UE4では名前の命名規則はPascalCaseが採用されている。

https://wa3.i-3-i.info/word13955.html

wa3.i-3-i.info

このPascalCaseを一般的な英文にして読みやすくするために単語の区切りに自動的にスペースを表示してくれる、というのがBPなどのグラフエディタの便利機能としてある。この時、略字と単語が続く（例：XMLAndHTML）時などにどこからが区切りかわからないために区別がつくように_で単語の区切りを示す書き方があり（例：XML_AndHTML）、この書き方にも対応したために_をスペースに表示する機能になった、と思われる。

なので本来はこれは便利な機能のはずなのだ。

問題が起きる条件

見た目でスペースと区別がつかない、という問題が起きる条件は次になる。

語頭（プレフィックス）に「_」

テキスト系のスクリプト言語ではグローバルな変数とローカルな変数の名前被りを避け、ローカルであることを明示するために語頭(プレフィックス)に_を付けるルールを設けていることがしばしばある（JavaScriptやPythonなど）。

その感覚でローカルな関数や変数名の頭に_を付けてしまうと、グローバルなものと区別がつかない、という残念なことが起きる。

語尾（ポストフィックス）に「_」

語頭の場合と異なり意識的につける文化などはないので大きく問題にはなりがちではないが、区別のつかなさでは語頭にあるよりも凶悪でまったく区別がつかない。

語頭にある場合、スペースの幅分でかろうじてわかることもあるが、語尾は無理！
混乱の危険性ではよりこちらのほうが上である。

大文字が続かない場合の語中の「_」

前述の通り、 略字などで単語の区切りなのに大文字が続く場合を除いて 、語中、特に単語の区切りに_を入れては全く区別がつかなくなる。

余談：単語の区切りに「　(スペース)」

_ではないが、自動でスペースが入力される位置にスペースを入力するのも危険。
UE4のBPのグラフ・関数・変数名にはスペースが入れられるためにこれも併せて要注意。

まとめ

• BPのグラフ・関数・変数名で次は危険なので避ける
  • 語頭（プレフィックス）に「_」
  • 語尾（ポストフィックス）に「_」
  • 大文字が続かない場合の語中の「_」
  • 単語の区切りに「　(スペース)」

Gamemakin UE4スタイルガイドにもこの辺は書いていないので要注意。
新しく始めるプロジェクトでは是非このルールを採用してほしい。

akenatsu/ue4-style-guide

An attempt to make Unreal Engine 4 projects more consistent - akenatsu/ue4-style-guide

github.com

BlueprintUE.comという、ブループリント（以下、BP）をWEB上で簡単に共有できるサイトの紹介。

PasteBin blueprints For Unreal Engine 4

BlueprintUE.com is a tool for sharing, rendering and rating blueprints for Unreal Engine 4. UE4 is a game engine which use visual scripting called blueprint.

blueprintue.com

BlueprintUE.comとは

いわゆるPastebinサービスの一種。

Pastebin（ペーストビン）とは、テキストデータを保存し公開することができる、ウェブアプリケーションサービスである。保存されたテキストデータごとにURLが発行されるため、そのURLを伝えることで他人に閲覧させることができる。

出典 Wikipedia

テキストベースのスクリプト言語などでは一般的なのだが、BlueprintUE.comはバイナリデータのBPに対応したサービスだ。

通常BPをWEBで共有しようとすると画像が一般的だがこの場合コピペができないため、人力で目コピするしかなく共有が大変になる。一応テキストで共有する方法もあるのだが…。

[UE4]BlueprintをQiitaなどのブログで共有する方法 - Qiita

UE4の強力なビジュアルスクリプティング言語である Blueprint は、ビジュアルスクリプティングという特徴から、Qiitaやブログで一般的な「コードを張り付けて共有」、といったことがしにくい。そこでいくつか方法をまとめてみた。 ...

qiita.com

BlueprintUE.comはほぼBPエディタ上の見た目をそのまま再現することができ、再現性が高い。またそのままコピペしてBPエディタに張り付けるだけで共有できる。しかもノードを動かして確認することもできる。

BlueprintUE.comを匿名で使う

まずは一番カンタンな方法から。

1. サイトに行く

PasteBin blueprints For Unreal Engine 4

BlueprintUE.com is a tool for sharing, rendering and rating blueprints for Unreal Engine 4. UE4 is a game engine which use visual scripting called blueprint.

blueprintue.com

2. 共有したいBPを選択してCtrl+Cする

3. BlueprintUE.comのトップページに張り付ける

黒い文字列入力欄があるのでCtrl+Vして張り付ける。

4. 名前をつける（半角英数字で）

半角英数字で名前をつける。日本語は入力可能だが、ランダムな半角英数字の文字列に強制的に置き換えられる。

5. 公開範囲、公開期間、UE4のバージョンを設定

• A : 公開範囲
  • どこまで見せるかを決められる
  • public : 全体に共有。トップメニューの下などにリストアップされる
  • unlisted : リストアップされない。URLが知っている人のみ見られる
  • private : 非公開。匿名ユーザーの場合は使用不可。
• B : 公開期間
  • いつまで見せるかを決められる
  • never : いつまでも残す
  • 1 hour : 1時間だけ
  • 1 day : 1日だけ
  • 1 week : 1週間だけ
• C : UE4のバージョン
  • 共有したいBPを作ったUE4のバージョン
  • BPもバージョンごとに少しずつ違う

6. 投稿

左下の「 Create your pasetebin 」ボタンを押して投稿する。

投稿後はグラフをズームイン・アウトしたり、スクロールしたり、ノードを移動したりできる。部分選択も可能。

実際に投稿したのはこちら。

Pastebin Blueprint

blueprintue.com

7. 共有する

投稿してできたページのURLを教えることでそのままコピペ共有が可能になる。

また、iframeが埋め込めるサイトなら下のようなコードをコピーして埋め込むことができる。

<iframe src="https://blueprintue.com/render/xd26ksrr" scrolling="no"></iframe>

実際に張り付けてみると以下のようになる。

ブログなどでBPの説明をする際に大変便利だ。

BlueprintUE.comにユーザー登録して使う

単純に公開するだけならユーザー登録も不要で簡単だ。
しかし、たとえばブログなどで公開する際にあとから中身を修正したり、やっぱり公開を辞めたりといった編集をしたい。この場合はユーザー登録をしておく必要がある。

また、完全非公開で使いたい場合、これもユーザー登録が必要になる。

1. トップページの右上の「Register」をクリック

2. ニックネームとパスワード入力してSign UP

1. nickname(ニックネーム、ユーザー名)を入力する
   • このサイト上でのユーザー名表示になる
2. パスワードを入力 もしくは　SNSアカウントと連携する
3. Sign Upボタンをおして登録

登録が成功しログインすると右上のメニューの「Register」「Login」が「My Profile」「Logout」に変わる。

3. 投稿する

投稿は匿名の時と同じ。

4. 個人設定を見る＆投稿一覧を見る

画面右上の「My Profile」をクリックすると個人ページに移動する。

1. 個人ページのプロフィール設定
   • TwitterやGithubなどのアカウントへリンクを追加できる
2. プロフィール編集ボタン
   • 編集はこのボタンから設定可能
3. これまでに投稿したPastebinの一覧
   • タイトルをクリックするとそのBPのページに飛ぶことができる

5. 以前の投稿を編集する

ログイン状態でBPのPastebinページにアクセスすると右上に「Edit」ボタンができているのでクリックする。

5.1 追加情報を加える

編集ページの上部では追加情報を加えることができる。

1. タイトル名
   • タイトル名を変更できる。半角英数字のみ。
2. タグ
   • 検索などで使えるようにタグを入力できる。
3. 説明文
   • 説明文章を追加できる。
4. ビデオ
   • 説明などの動画がある場合は動画URLを指定できる
   • 指定できるのは　Youtube, Vimeo, Dailymotion　の動画
5. サムネイル画像
   • サムネイル画像を設定できる

5.2 BPを更新する

1. 新しいBPをここに張り付ける
2. 更新理由を書き込む
   • 必須項目。更新の理由を書き込む。簡単なver.管理の目安になる。
3. BPを更新する

更新するとBPのページの下部に履歴が残る。

5.3 設定変更

同じページで設定変更もできる。

4. 公開範囲の変更
5. UE4バージョンの変更
   • BPを新しいUE4バージョン用に更新した場合はここも一緒に変更する
6. コメントの許可・不許可
   • 交流しなくない場合はコメント不許可にするとよい
7. 設定変更

BlueprintUE.comの困ったところ

BlueprintUE.comは便利だが、ちょっとだけ困ったことがある。

• 微妙にサイトが重い
• 微妙に再現性が低い
  • 逆に戻るワイヤーがおかしなことになる

EpicGamesが買収してくれれば良くなりそうな…自社サービスにしてくれないかな…？

UE4を使うなら、SSDは人権、CPUは４コア以上、などと言われる。
意外に言及されないのがディスプレイの広さ（解像度）。
UE4をつかうならおすすめは4Kディスプレイだ。

なぜ 4K ?

ここでいう「4K」とは 「2160p, UHD」のこと。いわゆるFull HDの画面４枚分。
なぜこれが快適なUE4環境に必要なのかを考えてみたい。

快適な作業に必要な画面領域

一般的なUE4の環境を考えてみると、
①まずメインのレベルエディターのウィンドウを開き、
②さらに何らかの作業をするのでBPエディタやペルソナエディタなどのウィンドウが開いている、
というのが最も多いケースとして考えられる。

①、②ともに画面解像度が必要なウィンドウなのでそれぞれFullHDの画面を占有したい。

③さらに何らかの資料（Excelなりブラウザなり）を確認しながら作業をするとなると、もう一枚ディスプレイ領域が必要になる。

ここまで考えてみると、快適にUE4を使うようにするためには FullHDのトリプルディスプレイが必要になる（1920x1080 x 3）。

トリプルディスプレイの問題点

実際にトリプルディスプレイ環境を構築した人ならわかると思うが、ディスプレイのインチ数にもよるが横並びにディスプレイを３つも並べると、目線移動が大変 だ。作業を進めるにあたって目線や首をあちこち動かさないといけない。一番左の画面の資料を見ながら、一番右の画面で操作する、というのは効率的とは言い難くなるのだ。

では縦に並べてみるのはどうか。もちろん１枚だけ上か下にし、残りの２枚は横並びにするというものだ。これは目線移動つらい問題は解決する。ただし、 デスクトップの横幅が途中で異なってしまう 上に、３つの画面の中央には画面の枠が来てしまう 。

4Kディスプレイなら

4Kディスプレイならトリプルディスプレイのような目線移動つらい問題は軽減される。
インチ数とディスプレイとの距離にもよるが、デュアルディスプレイと同様の目線移動で済む。

当然ながら１枚のディスプレイなので画面の中央にディスプレイの枠が来ることはない。
これはデュアルディスプレイ環境であっても問題なのでそこが解決するのは大きい。

物にもよるが４枚ディスプレイをそろえるよりは安い。場合によっては３枚そろえるよりも安いか同程度の価格で手に入る。

たとえば現時点で調べると40インチクラスで5万円台から、というものすらある。TVパネルを流用したハーフグレア系のモニターはかなり値段がこなれてきている。

価格.com - 解像度（規格）:4K（3840x2160）のPCモニター・液晶ディスプレイ モニタサイズの小さい順 (モニタサイズ:30型(インチ)〜)

解像度（規格）:4K（3840x2160）のPCモニター・液晶ディスプレイ製品一覧 モニタサイズの小さい順！たくさんの製品の中から、価格やスペック、ランキング、満足度など、さまざまな条件を指定して自分にピッタリの製品を簡単に探し出すことができます。(モニタサイズ:30型(インチ)〜)

kakaku.com

UE4で制作するコンテンツは4K解像度をターゲットにすることは珍しくない。その開発環境で４Kで表示できないというのはそもそも開発環境として問題がある。

4K導入の障害と対策

「よし、4Kディスプレイ導入しちゃうぞ」となったときいくつか障害がある。

30hz問題

ひと昔前の内臓グラボなどは4Kのデスクトップ表示が可能なものの、30hzが上限になっているものがある。もっとも、UE4の開発環境なのでちゃんとしたグラボを導入しているだろうからこの問題はあまり起きにくい。

HDMIのver.問題

HDMIの1.4以前は4K解像度は30fpsが上限である。端子とケーブルがHDMI2.0以上かどうかを確認する必要がある。上記の内臓グラボの制限ははこのHDMI端子の問題の時もある。

HDMI - Wikipedia

ja.wikipedia.org

机の上のスペース

２４インチ、２７インチといったディスプレイ解像度のまま大きくするなら40インチクラスのディスプレイになる。その場合机の上のスペースが物理的に足りない、ということが起こりうる。

また、置けるけど奥行きが足りない、という問題も起こりうる。あまりにも顔に近いと圧迫感が出てしまうので机が小さすぎる環境でないかどうかよく考えたほうがよい。事前にしっかり計測しておくこと。

なお、３０インチクラス以下の4Kディスプレイもあるが、細かすぎる、値段が高い、などの問題がある。

１画面１ウィンドウの慣れ

１画面１ウィンドウ最大化することで使い分ける癖ができてしまっている人は、広大な４Kの領域を持て余してしまうかもしれない。これまで無自覚に最大化する癖がついてしまっていると、4Kのデスクトップで苦労することになる（間延びしたウィンドウに面食らい、マウス移動が大変になる）。

とはいえこれは慣れの問題である。そもそも4Kの場合、ウィンドウを最大化してはいけない。そこそこのウィンドウサイズで十分なスペースが得られるので最大化せずに並べるのだ。

Win10ならWinキー＋左右キー→Winキー＋上下キーで疑似的な画面分割ができるのでそれも使ってみるとよい。

https://cloud-work.jp/windows/shortcut/

cloud-work.jp

ハーフグレアってグレアやん問題

安価な4KモニタはTVパネルの流用のため、ノングレアが非常に少ない。よくてハーフグレアと呼ばれるものだ。しかし、ハーフグレアというのは見た印象はグレアそのものであり、PC作業環境としては反射が目立つ。

ちゃんとしたノングレアで40インチの4Kディスプレイ、となるとまだまだ価格が高くなってしまうのが現状だ。40インチクラスになるとノングレアにするフィルムもめちゃくちゃ高いので現実的な選択肢にはなりにくい。

ハーフグレアに関しては、光源からの角度をかえるなどである程度妥協するしかない。

まとめ

• UE4には4Kディスプレイがおすすめ
  • メイン、サブ、資料で３画面つかう
  • トリプルディスプレイは枠が邪魔で置き方に困る
• 4Kモニターなら
  • 枠無し
  • 目線移動も少ない
  • 意外と安い
  • 4Kコンテンツをちゃんと表示できる
• 障害と対策
  • 30hz制限
    -　ちゃんとした外付けグラボを導入しよう
  • HDMI ver.問題
    -　HDMI2.0以降をそろえよう
  • 机の上のスペース
    • 導入前に測ろう
  • １画面１ウィンドウの慣れ
    • やり方を変えよう
  • ハーフグレアってグレアやん問題
    • 角度を変えて妥協しよう

おまけ

自分が使っている・使ったモニター：

DOSHISHA OD4K-49B1

301 Moved Permanently

doshisha-av.com

後継機種がでてもう販売していないが、７万円台で購入。後継機種もどうやらディスコンらしく9万円台まで値上がりしていたが本来は７万円台の製品。

フィリップス　BDM4350UC/11

いわゆる40インチクラスで「鉄板」と言われていたモデル。

フィリップス BDM4350UC/11 [42.51インチ ブラック/シルバー] 価格比較 - 価格.com

42.51インチのIPSパネルを採用した4K UHD（3840x2160）対応モデル。フィリップス BDM4350UC/11 の最安値を見つけよう！全国各地のお店の価格情報がリアルタイムにわかるのは価格.comならでは。製品レビューやクチコミもあります。

kakaku.com

今年になって後継モデルがでたため売れ残りは値上がりしている。今からならこっちか。

フィリップス 436M6VBRAB/11 [42.51インチ ブラック] 価格比較 - 価格.com

ウルトラクリア 4K UHD（3840 x 2160）解像度対応の42.51型ディスプレイ。「MultiView機能」搭載で最大4つのシステムのフルHD画像を1画面に表示できる。フィリップス 436M6VBRAB/11 の最安値を見つけよう！全国各地のお店の価格情報がリアルタイムにわかるのは価格.comならでは。製品レ...

kakaku.com

おまけその２

4KディスプレイならBPエディタがこんなに広大に使えるぞという例。

とりあえず快適に組めそう　#UE4 pic.twitter.com/Sp4x77FeXS

— K. S. (@ConquestArrow) 2017年4月3日

UE4のブループリント（以下、BP）はビジュアルスクリプティング言語¹と呼ばれるグラフィカルなプログラミング言語である。

ビジュアルスクリプティング言語はテキストベースのスクリプティング言語に比べて歴史が浅く、言語ごとに特性も大きく変わることなどから「こう書くべき」というノウハウがあまり溜まっていない。また、UE4のBPはゲームデザイナーやアーティストなどのノンプログラマ向けに作られた経緯もあることから、使用者が書き方・スタイルガイドへの意識やノウハウが少ない。

#UE4 のBlueprintはとても良いんだけど、文字通りスパゲッティ化しやすいという欠点も。スタイルフォーマッター的なツールがない ＆ 主に使うノンプログラマはノウハウ持ってない ＆ 見やすいスタイルが固まってない などが理由。

— K. S. (@ConquestArrow) 2017年4月24日

結果以下のような問題をBPは抱えている；

• 👎ノードをつなぐワイヤーのスパゲッティ化
  • 見て理解するのが困難になり生産性が落ちる
  • 問題のある処理を見逃しがちになる
• 👎ワイヤー繋げなおしの手間がかかることによる処理の移植のしにくさ
• 👎一画面に処理が収まりきらず処理を理解するために画面スクロール・ズームを多用せざるを得ない
  • UE4のエディタは一般的にDual Displayだと足りないといわれる一因

以下紹介する書き方は上記問題を解決し、不具合を防止し生産性を上げるBPの書き方のノウハウになる。

なお、以下に記載以外は原則 出典
Gamemakin UE4スタイルガイド に従うのが良い。

akenatsu/ue4-style-guide

An attempt to make Unreal Engine 4 projects more consistent - akenatsu/ue4-style-guide

github.com

基本単位は実行ピンのあるノード単位でまとめ、まっすぐに並べる

まず、実行ピン² が入出力ピンとしてついているノードを基本の単位として考える。

該当するのはフロー制御ノード、イベントノード、普通の関数ノード、変数のSetノード、マクロノード、サブグラフ(折りたたみグラフ)ノード等。

BPの処理は実行ピン同時をつなぐ 実行ワイヤー³ をたどって処理が行われる。実行ピンの付かないノードはその意味では「脇道」なので基本的な流れを追いかけるのはこの 基本単位⁴ を追いかければよい。

次に、『Gamemakin UE4スタイルガイド』⁵ を参考に実行ピン付ノード同士を直線状に並べてゆく。

前述のように、BPの処理は実行ピン同時をつなぐ 実行ワイヤー³ をたどって処理が行われるので、これらのノードがわかりやすく整列して並んでいないと人間の理解が困難になってゆく。仮に迷路のような並び方をしていた場合、遅かれ早かれバグの温床になってしまう。

実行ピン付ノードをまっすぐに並べる事で、 どこを目で追いかければよいかが一発で見分けられるようにする のが目的。
また、以降に記載するルールの恩恵を得るための基本的な前提となる。

• 出典StyleGuide 3.4.3 3.4.3 白い実行ワイヤーを最優先にするべき

実行ピン付ノードの下に実行ピン無しのノードを積み重ねる

実行ピン付のノードには「実行ピンではない入力ピン」（プログラミング用語でいえば関数の引数に当たる）があることがある。
そのピンへワイヤーを繋ぐ元のノードが実行ピン付でない場合は、実行ピン付ノードから位置を離すのではなくすぐ下に重ねるように隣接して設置する。

実行ピン無しノードからさらに実行ピン無しノードが繋がっている場合（例：コンポーネントの変数をGetするときなど）は、さらにその下に配置して、先がなくなるまで下に重ねてゆく。

該当するのは、数値の四則演算ノードや変数のGetノード、pureに指定された関数(純粋関数⁶)ノードなど。

実行ピン付のノードとそれ同士の繋がりを「木の幹」とすると、実行ピンの付かないノードは「木の枝葉」に当たる。
木の幹と枝葉（本筋と脇道）が一目で分かるように、並べ方で区別がつくようにする のが一つ目の目的である。

もしこのルールに従わない場合、ワイヤーの色に差があるとはいえメインの処理の流れにみえるように配置することも可能であり、人間の理解が困難になる。

二つ目の目的としては、 基本単位（実行ピン付きノード＋それから参照される実行ピン無しノード）をブロック状に一定範囲にまとめておくことで矩形選択しやすくする ことである。矩形選択しやすいということは処理の単位で動かしやすく整理しやすい、コメントノードでくくりやすい⁷、あるいはコピーやカットなど移植がしやすいということにつながる。

もしこのルールに従わない場合、グラフを見やすく整理したり、リファクタリングしたり、処理を移動する際に、マウスクリックやコピーペーストなどの作業が何度も発生し、「書くのが大変」という状況になってしまう。

同じ基本単位のノード群は左端でそろえる

そろえることで 基本単位⁴を視覚的に認識しやすくする のが目的。
ただし、四端どこでもよいわけではなく左端でないといけない。

BPのノードは大きさが可変である。UE4エディタの表示言語を切り替えたり⁸、ノードの入力欄の内容の変化、ノードの対象や属するもの（例：関数ノードの属するBPクラス名）の名称の変更などによって、いくらでも大きさが変わる。

そのため右端でそろえたとしてもいつでもそろわなくなる可能性があり、あまり意味がない（かけた手間が無駄になる可能性が高い）。
左上が原点となるので、下に重ねるノード群も同じ左端でそろえるようにすることで ノードサイズの可変にも耐えられるようにする 。

実行ピン付ノード引数の順番とノードの積み重ね順を合わせる

順番を合わせることで理解をしやすく し、また 矩形選択しやすくする のが目的。

一つの基本単位に関連するノードを重ねた場合など、縦に大きくなることがしばしばある。この場合、仮に入力ピンの順番と繋がった先のノード群の並びの順番がバラバラであると、どのようにつながっているのかわかりにくい。また矩形選択も関係ないノードが混ざりこむためにしにくくなる。

ノードの入力ピンが多い場合はノード２つ分の幅を使って並べる

過剰に縦に長い基本単位ができるのを防ぐ のが目的。

入出力ピンから伸びるワイヤーを一本に絞る

１つ目の目的は スパゲッティ化の防止 。

特にあるノードの出力ピンから複数のノードでワイヤーが繋がっている場合、まるでタコ足配線のようにあちこちにワイヤーが繋がることになる。このような場合ワイヤーがノードと重なる可能性が高く、ワイヤーを目で追うときに邪魔になって理解がしにくくなる。また、遠く離れたノードからワイヤーを伸ばすことにもなり、画面をスクロールしないと処理が追えないという読みにくさにもつながる。

２つ目の目的は 基本単位の移植時にワイヤーの接続情報を維持する ことである。

具体的には次のルールに従う。

基本単位内で使うものは基本単位内で完結するようにする

たとえば　基本単位A　と　基本単位B　の２つの基本単位があり、ローカル変数Xの値を参照する共通の処理があるとする。

この時何も考えずに思わず、Get Xノードからそれぞれの基本単位内のノードにつなげたくなるが、そうしてしまうとスパゲッティ化の第一歩（２本のワイヤー だけ で済むならよいが本当に将来も２本だけなのかは 誰にも保障できない 。気が付いたらスパゲッティ化している。）につながるうえに、矩形選択時に一つだけGet Xノードが漏れるため選択しにくくなってしまう。

この例ではGet Xノードを２つ配置し、それぞれ　基本単位A　と　基本単位B　のブロックの中に納まるように配置する。

こうすることで 将来にわたってもスパゲッティ化を起こさず、矩形選択しやすさを維持できる。

複数本の実行ワイヤーは入力ピンにつなぐ前にRerouteノードでまとめる

ワイヤーを直接一つのピンにつなぐのではなく、一旦 Rerouteノード⁹ で束ねたうえで入力ピンには１本だけ繋ぐようにする。

コピー＆ペーストやカットなどで処理を移植する際に、Rerouteノード込みで選択しておくことで、 ワイヤーのつながりが維持される のが目的。繋ぎなおす手間、覚えておく手間を減らし、つなぎ間違いによるケアレスミスを防止する。

仮に、いきなりつながったままだと移植後にワイヤーが切れてしまい、繋ぎなおす手間がかかる。また、ちゃんと覚えていられれば良いものの、つなぐ先を間違ってしまい、処理を移植したことでエンバグする恐れがある。

原則、処理の結果は変数に入れ、他の処理単位にワイヤーで繋がない

「基本単位内で使うものは基本単位内で完結するようにする」のメリット、 スパゲッティ化防止・移植性の維持 を得るために、原則処理結果は変数に確保し、直接ワイヤーで繋がないようにする。

• 例外：
  • １回しか使用しない場合
  • 実行ノード同士が隣接する

実行ワイヤーで繋いだ”行”はSequenceノードを用いて繋ぐ

基本単位⁴ をつないでいくとき、処理の意味として区切りを作ることができる。これを”行”とみなす。
そうとらえることで、”改行”することができる。

“改行”をして”行”単位で分離することで、コメントノードで分かりやすく区別できるようにする ことが目的。また　行単位での移植性も確保 できる。

“改行”の実現方法としてはZの文字のようにワイヤーをつないでいくことができるが、行内の処理を変更するたびにつなぎなおしたり、斜めにワイヤーが張られることでノードにかぶったりとあまり好ましくならない。

そこで Sequenceノード¹⁰ を使って複数の”行”をつなぐことで、行末端のノードからワイヤーを排除できる。例えば変数の初期化処理をまとめた行があった場合、Z字につないでいる場合は変数が増えるたびにつなぎなおしが必要になってしまうが、Sequenceノードを使えば単に後ろに初期化のノードを繋いでいくだけでよくなる。

Sequenceノードを使った”改行”は、 行単位での移植性をより高めておく のが目的。

なお、Sequenceノードはいくつか注意点がある。

例 : Delayノードは想定の挙動にならない

[UE4] SequenceとDelayの関係 - もんしょの巣穴blog

monsho.blog63.fc2.com

例 : 途中の出力ピンのワイヤー末端でReturnノードが来るとSequenceの処理は中断される。

このような点に注意して使用する。

“行”の途中の折り返しはRerouteノードを使ってノードに被らないよう直線的に引く

ワイヤーがノードなどに被ることを防止する ことが目的。

“行”があまりにも横に伸びてしまった場合や、ForEachLoopWithBreakノード等があった場合、”行”の折り返しが必要になる。何も考えずにそのままつなぐと、ノードや基本単位の中にワイヤーがかぶることで処理が追いにくくなってしまう。

ワイヤーが一つのノードにループして戻ってくる場合は上を通す

読みやすさを維持しながら更新のコストを下げる のが目的。

そのままつなぐと確実にワイヤーとノードが重なって処理が追いにくくなるのでRerouteノードで整理する。

下をぐるっと通すこともできるが、以下の問題がある。

• これまでのルールでノードを下に重ねるようにしたためかなり大回りになってしまう
• 処理を追加した場合など繋ぎなおし・Rerouteノードの配置しなおしが発生する
• ForEachLoopWithBreakノードのCompletedピンのように下に続きの処理が伸びる時に交差する

上を通すことで最小限のメンテコストで見やすさを維持できる。

https://blueprintue.com/blueprint/k21kb8k4/

余談：BP以外での活用方法

AnimBPのAnimノードグラフやマテリアルのノードグラフの場合、BPのグラフに比べて実行ワイヤーが少ない。その点注意すればこのルールを活用することもできる。

まとめ

ルールと目的まとめリスト

• ルール 基本単位は実行ピンのあるノード単位でまとめる
• ルール 基本単位同士をまっすぐに並べる
  • どこを目で追いかければよいかが一発で見分けられるようにする
• ルール 実行ピン付ノードの下に実行ピン無しのノードを積み重ねる
  1. 木の幹と枝葉（本筋と脇道）が一目で分かるように、並べ方で区別がつくようにする
  2. 基本単位（実行ピン付きノード＋それから参照される実行ピン無しノード）をブロック状に一定範囲にまとめておくことで矩形選択しやすくする
  • ルール 同じ基本単位（実行ピン付きノード＋それから参照される実行ピン無しノード群）のノードはその左端でそろえる
    • 基本単位⁴を視覚的に認識しやすくする
    • ノードサイズの可変にも耐えられるようにする
  • ルール 引数（入力ピン）が複数あるノードの場合には、そのピンにつながる先のノード群の配置も入力ピンの順番に合わせる
    • 順番を合わせることで理解をしやすく
    • 矩形選択しやすくする
  • ルール ノードの入力ピンが多い場合はノード２つ分の幅を使って並べる
    • 過剰に縦に長い基本単位ができるのを防ぐ
• 入出力ピンから伸びるワイヤーを一本に絞る
  • スパゲッティ化の防止
  • 基本単位の移植時にワイヤーの接続情報を維持する
  • ルール 基本単位内で繋ぐノードは他から繋ぐのではなく基本単位内で完結するようにそれぞれ配置して繋ぐ
    • 将来にわたってもスパゲッティ化を起こさず
    • 矩形選択しやすさを維持できる
  • ルール 複数本の実行ワイヤーは入力ピンにつなぐ前にRerouteノードでまとめる
    • ワイヤーのつながりが維持される
• ルール 原則、処理の結果は変数に入れ、他の処理単位にワイヤーで繋がない
  • スパゲッティ化防止・移植性の維持
• 実行ワイヤーで繋いだ”行”はSequenceノードを用いて繋ぐ
  • ルール 意味のある実行ピン付ノードの繋がりを”行”とみなし適宜”改行”する
    • コメントノードで分かりやすく区別できるようにする
    • 行単位での移植性も確保
  • ルール “行”同士をSequenceノードで繋ぐ
    • 行単位での移植性をより高めておく
• ルール “行”の途中の折り返しはRetouteノードを使ってノードに被らないよう直線的に引く
  • ワイヤーがノードなどに被ることを防止する
  • ルール ワイヤーが一つのノードにループして戻ってくる場合は上を通す
    • 読みやすさを維持しながら更新のコストを下げる

ルールの方針まとめ

これまでのルールは大きく以下の判断基準に沿ったもの。

1. 読みやすさの維持
2. メンテコストの削減
3. 選択しやすさ・移植性の確保

上記に見合うこれら以外に良いルールがあればどんどん採用して「きれいな」BPを書くべし。