【UEチャレンジ企画】ブループリントを深堀り！バグとの戦いも

Unreal Engine100日チャレンジに挑戦している、Neruです。


この企画は、Unreal Engineの初学者である筆者が、100日間の学習でどれだけのものを作れるのか、というチャレンジ企画です。

初回の記事で、この企画の詳細と、筆者の経験値がどの程度なのかを説明しています。
 

前回は、Unreal Engineに搭載されているビジュアルスクリプティングシステム、「ブループリント」について学びました。

今回の目標は、さらにブループリントを深堀りしていくことです。便利な機能を使い、効率的なプログラミングができるようになることを目指し、関数、マクロ、インターフェースなどを学習しました。

ただ、今回からは書籍の課題の難易度も上がり、プログラムを作ったものの、思うように動かないことも多々ありました。

前回はプログラムを動かすうえで基本的な知識を学びましたが、今回は一歩進んで、より効率的な開発の仕方について学びました。

効率的に開発を進める一つのやり方が、一度作ったプログラムを、色々な所でも使いまわすことです。

ゲームの中で同じ処理を何回も行う場合、処理を実装するたびに一からプログラムを組むのは面倒ですし、ヒューマンエラーの可能性も高まります。
 

そこで、あらかじめよく使う処理を作ってライブラリに保存し、必要に応じて呼び出すことで、同じ処理を色々なところで使いまわすことができるようになります。効率的な開発には必要なテクニックです。

今回学習した関数、マクロ、インターフェースは、いずれも一連のプログラムをまとめたもので、色々なプログラムから呼び出して使うことができます

関数、マクロ、インターフェースは、プログラム内で特定の動作を簡単に使い回すための便利なツールです。

関数は特定の処理をまとめて、再利用できるようにしたものです。

マクロはパターンを収めたテンプレートのようなもので、難しい処理をまとめて１処理にできます。

関数、マクロ、インターフェースの違いについては、少し複雑な話になりますので、詳しく知りたい方は下記の記事をご参照ください。

一つ前のバージョンであるUnreal Engine 4について書かれた記事であることには注意してください。

今回学習した知識を使って、コードをより簡潔に書き換えてみました。

以下のポストは、関数を使って自機のスプリント機能を簡略化した例です。
 

また、以下のポストはマクロを使った簡略例です。

 

まだ関数、マクロ、インターフェースを、場面に合わせて適切に使い分けられる自信はありませんが……。

効率的な開発の手法を学べたことは、これから自分でゲームを作るうえでも役立つ知識になります。ただ、今回から学習する内容が複雑になり、書籍の指示通り進めていると思っているのに、仕組みが思うように動かないことも増えていきました。

そこで、今回の記事では筆者が躓いたポイントを列挙して、筆者と同じUnreal Engine初心者に、転ばぬ先の杖として役立てていただこうと思います。経験者の方は、初心者が陥りやすいミスのサンプルとしてご覧いただければ幸いです。

 

エラーが発生して、一番多かった原因が、同じような名前の要素を間違えて設定してしまった、というパターンです。

ブループリントには、デフォルトでも数多くの設定が用意されています。例えば、ブループリントの画面でノードを探す際、「Add」で検索すると以下のように大量のノードの候補が表示されます。

 

「Add」が付くアクションの種類が多い反面、機能は全く別のものというケースは多いため、間違えて設定してしまうと、当然思ったように動いてくれません。

また、Unreal Engineの多くの要素は自分で命名をして管理ができるのですが、自分で名付けたものと近い名前がデフォルトで入っているというケースにも遭遇しました。確認を怠って痛い目を見ました。

何にどういう名前をつけたのか、また設定しているものが自作のものかデフォルトのものなのかという点は、きっちり管理、確認しておかないと、ゲームは思ったように動いてくれません。

例えば、以下の画像では、青緑色の「Cast to BP_Playerstate」と紫色の「Cast to BP_Playerstate class」というノードが設置されています。

 

名前は似ていますが、この二つは全く違う機能を持っています。

筆者はこの二つを間違えて設置しました。結果、プログラムが思ったような形に機能しない、という事態に直面。

他にも、イベント(赤いノード)を、自作のものとシステム上のものを間違って使っていたというケースもありました。

いずれのミスも、名前をしっかり正確に把握し、自作のものの名前をしっかり管理していたら防げたものです。開発の際はいっそう気を付けていこうと思いました。
 

「ノードのチェックの入れ忘れ」もよくあるミスでした。

ブループリントのノードの一部には、チェックボックスが含まれているものがあり、チェックをするか否かで挙動が変わります。

「set all bodies simulate physics」というノードに、「New Simulate」というチェック欄があるのが見えると思います。こちらのチェックをつけておかなければ、思うような挙動を作ることができません。

初歩的なミスだとは思うのですが、細かい点にまで目が行き届かず、思うように動かないというケースが、筆者の場合ままありました。

特にノードによっては大量の項目を有している場合もあるので、その場合は特に注意する必要があります。
 

クラスの設定ミスも多くありました。

クラスについては、前回も説明をしましたが、改めて説明します。

この設定を誤ってしまうと、当然ですが思ったように動いてくれません。また、ブループリントのほうでも、指定するクラスが間違っていると、こちらもバグの原因になってしまいます。

こちらも一度ミスをして、30分ほど格闘してやっと間違いに気が付きました。ミスに気付いたときは、灯台下暗しといった気分でした。

クラスを取り扱う際は、オブジェクト、ブループリントともに、想定しているクラスを設定しているか確認しなければいけないと実感しました。名前が似ているクラスもあるので、正確な把握が必要になります。

 

今回の記事は、自分が躓いた箇所を中心に紹介しました。

関数、マクロ、インターフェースといった、一歩先に進んだ事柄を学習するなかで、やることも少しずつ複雑になっています。

しかし今回紹介したように、ミスの原因を調べてみると、原因は初歩的なものが多かったです。

気づけば拍子抜けするようなことばかりで少し落ち込みましたが、学習段階で発生しやすいミスに気が付いたことは良かったです。

次の開発の際は経験したことを活かして、慎重に進めていく所存です。

次回学習するのは、当たり判定や物理エンジンについてです。

ゲームの物理面を深く学習して、3Dゲームとして違和感のない作りを実現することが目標です。

本企画も40日目にさしかかり、いよいよ半分が迫っています。これからも継続していきますので、引き続きよろしくお願いします。