今日もいつものルーチンワークとお仕事のプログラミング作業を終えた後、残った時間でアンリアルエンジンを触っていた。

まずはブループリントの扱いから。

まぁ、大体のイメージはつかめた。

これ、ほんとにスクリプトをUMLやフローチャートのように視覚的に組み立てられるようにしたものなんだな。

データベースのSQLやストアドプロシージャなんかを同じようにノードを置いてリンクしていくようなミドルウェアなら仕事で使ったことがあったけれど、プログラミングそのものに適用したようなもんだね。

ゲームエンジンは、ゲームループが固定パイプラインとしてあって、全てのリソースがオブジェクトのヒエラルキーとして表現できるということから、極限まで突き詰めるとこうなるのかも知れない。

Unityも遅かれ早かれ、同じようなUIにとって変わられるかもしれない。

ブループリントには、レベルブループリントと、クラスブループリントというのがあって、レベルブループリントはUnityで例えると空のゲームオブジェクトにスクリプトを貼り付けたようなものだ。

それに対し、クラスブループリントをUnityで例えると、カメラやライト、モデルや地形のメッシュなど、実体のあるゲームオブジェクトに貼り付けたスクリプトのようなもの。

Unityだと、このスクリプトの Start() と Update() を実装していくことになるんだけれども、ブループリントではコンストラクションスクリプトとイベントグラフで構成される（もちろん両方ノンコーディング）。

そして、Unityではライブラリの関数呼び出しや、入力処理、トランスフォームの制御などをコードで記述していくわけだけれども、ブループリントでは、これら関数や変数、入出力などに対応するノードがあるので、そのノードを組み合わせて同じことを実現するのである。

俺の場合、今はまだコードのほうが慣れているし、生産性も断然スクリプトのほうが高い。

しかし、ブループリントには、一度設計したブループリントを関数化して再利用出来たり、その性質上難解なプログラムは作れなくて、ある種セオリーの組み合わせみたいになっていくと思われる。

そうなると長い目で見たときに、ブループリントで手早くプロトタイプを組んで、チューニングが必要な部分だけコードに置き換えていく、という方法がスピードの面でも、メンテナンスを含めたコストの面でも、逆転しうる可能性は十分あるなと。

そうそう、冒頭の画像は、サンプルのシーンからメッシュだけ借りてきて、MMOのハウジングの要領で適当に組み立ててみたシーンだ。

太陽光とポイントライトを二つ配置して、ライティングを焼きこんだ。

なんか、自分がレベルアップしたような錯覚におちいる。

これでダンジョンマップを作成したら…

夢は膨らむ。