(動画チュートリアル関連) コンパイルすると関数でエラーになるのはなぜ?

ThirdPersonCharacter というブループリントに次のような関数 CalParcent を作りました。

この関数を MyDoughBP という別のブループリントから呼び出す処理を組み、コンパイルしようとしましたがエラーになりました。

[コンパイル結果] というタブには「このブループリントは ThirdPersonCharacter_C ではありません」と書かれていました。なぜエラーになるのでしょうか?

異なるクラス (ブループリント) の関数を呼び出すにはそれなりの手続きが必要だからです。以下のように組めばエラーは起きません。

このグラフの意味は、Get Player Character (プレイヤーによってコントロールされるキャラクターを取得する) という関数でプレイヤーキャラクターへの参照 (:arrow_forward:関連する UE4 AnswerHub スレッド 変数の型で Reference とはどのようなものですか?) を取得し、その参照を利用して、そのキャラクターが ThirdPersonCharacter であるかどうかを [ThirdPersonCharacter へキャストする] というノードで調べています。そのキャラクターが ThirdPersonCharacter であるならば、ThirdPersonCharacter をターゲットにすることによって、ThirdPersonCharacter が持っている関数 (この場合 CalParcent) を使うようにしています。


( 以下は参考まで。 以下を理解しなければ上記の機能を使えない、というわけではありません。)

では、そもそもなぜ異なるクラスの関数を使えないのかと言うと、プロパティと機能はクラス単位で管理されているからです。

つまり、それらのプロパティと機能は、原則的に、そのクラスの中だけで使用するようになっています。言い換えると、他クラスからそれらを使用するためには、それなりの手続きが必要となります (上のキャストの画像のように)。他のクラスでプロパティを簡単に変更できないようにしてクラスの独立性をある程度確保し、「(気が付かないうちに値をうっかり変えてしまって) なぜゲームが正しく動かないのか分からない」という状況を防いでいる面があるのです。

また、クラス単位でプロパティと機能を管理すれば、クラスが異なると同じ名前の変数、関数をもつこともできます (:arrow_forward:関連する動画チュートリアル Third Person Blueprint Game: 18. Animation Blueprint Punching Setup)。もしクラスがなければ、名前はすべて異なるようにしなければなりません (区別がつかなくなるからです)。これはゲームの規模が大きくなるととても大変なことになります。

さらに、クラス単位でプロパティや機能を管理することによって、どこに何があるか、ある程度分かりやすくなる、ということもあります。キャラクターにはキャラクターに必要な機能が置かれるべきですから。

なお、クラスを実際にレベルで使うには、エディタではレベルにドラッグしますが、それでできたものはインスタンス (または オブジェクト) と呼ばれます。

インスタンスはクラスという設計図からできているので、クラスと同じと機能と同じ種類のプロパティをもちます。ただし、インスタンスのプロパティはインスタンス毎に変えることができます (たとえば、サイズのプロパティなどをインスタンス毎に変更できます)。また、キャスト ノード (一番上の画像) のピンの色は青になっていますが、これは、このようなインスタンス (オブジェクト) を扱っていることを示しています。