【UE5】派生開発を考慮したブループリントプロジェクトの構成戦略:よっしーシューターテンプレのCBP設計

※本サイトはアフィリエイト広告を利用しています。

― ユーザー改造とバージョンアップの両立を目指した設計方針 ―

私が公開しているシューターテンプレートでは、
ユーザーが自由にキャラクターを制作・拡張できるようにする一方で、
今後のテンプレートのバージョンアップとも競合しにくい構造を採用しています。

この記事では、その中核となる キャラクター Blueprint(CBP)階層構造について、
「どこを編集すればよいのか」「なぜこの構造なのか」をユーザー向けに解説します。

よっしー
よっしー

※ 私の今後のアップデートを自力で必要な部分だけ取り込みたい方は自由に改変してください


■ 全体構造(CBPのクラス階層)

テンプレートのキャラクターは、次のような階層で構成されています。

CBP_Base                    →(開発側:私の実装)
 └─ CBP_RetargetBase      →(ユーザーが編集する共通部分)
     ├─ CBP_PlayerBase    →(開発側:プレイヤー機能)
     │    └─ CBP_MyPlayer→(ユーザーが作る最終プレイヤーキャラ)
     └─ CBP_AI_Base       →(開発側:AI機能)
          └─ CBP_MyAI     →(ユーザーが作る最終AIキャラ)

それぞれの役割は以下の通りです。


■ CBP_Base(開発側・アップデート対象)

テンプレートの中核になる 基底キャラクターBP です。

含まれる内容:

  • 主要な移動機能(歩行、ダッシュなど)
  • 主要な戦闘機能の共通処理
  • 重要な変数・インターフェイスの定義
  • コンポーネント接続(Movement、Combat、Shooter など)

ここはテンプレートのアップデートで変更が入る可能性があるため、
ユーザーが直接編集することは推奨していません。


■ CBP_RetargetBase(ユーザー編集の中心)

ユーザーによる改造や共通機能追加は、この CBP_UserBase に集約していただきます。

ここに書くべき内容:

  • 自作の共通ロジック
  • プロジェクト固有の変数
  • アニメ通知 → ロジック呼び出し
  • 武器・ギミック・アクションの拡張

ポイントは、
「プレイヤーとAIの両方で必要になる処理はここに置く」
ということです。

ここをひとつ挟んでおくことで、

  • あなたのプロジェクト固有のコードはここに固められる
  • テンプレート側のアップデートが発生しても最小限の影響で済む

というメリットがあります。


■ CBP_PlayerBase(開発側)

ここには、「プレイヤー固有」の共通機能や I/F 実装が含まれています。

例:

  • プレイヤー視点処理
  • 入力アクション(IA)との接続
  • カメラや武器切り替えなど、操作キャラ専用の処理

これらはテンプレート側で提供しており、
ユーザーは通常 編集不要です。

次項の UserPlayer がユーザーの最終的な編集ポイントになります。


■ CBP_MyPlayer(ユーザーの最終キャラ)

いわゆる「ゲームに登場する実際のプレイヤーキャラ」です。
CBP_PlayerBaseの子クラスを作成してください。名前は任意。

ここで実装すべきもの:

  • メッシュ・アニメーションの割り当て
  • プロジェクト固有の処理
  • 見た目やステータスの設定
  • カスタムアクションの追加

テンプレート側で変更が入っても、この階層は触れられないため、
ユーザーの作業が壊れにくくなっています。


■ CBP_AIBase(開発側)

AIキャラクター専用のベースクラスです。

含まれる内容:

  • AI向け移動制御
  • AI向けの戦闘処理
  • Blackboard/Behavior Tree 用の I/F
  • AI感知系の処理

これもテンプレートのアップデート対象になります。


■ CBP_MyAI(ユーザーAIキャラ)

ユーザーが作成するAIキャラはここに配置します。
CBP_AI_Baseの子クラスを作成してください。名前は任意。

例:

  • 外見や武器の差し替え
  • 独自のAI行動追加
  • HPやステータスの設定
よっしー
よっしー

敵AIは全く独自の仕組みにしたい場合はCBP_AI_Baseの複製でも構いません。
その場合でもCBP_AI_Baseを編集してしまうとバージョンアップ時に取り込みが面倒になりますのでご注意ください。


■ なぜこの階層構造なのか(目的)

🎯 1. ユーザーの改造を壊したくない

テンプレートをバージョンアップすると、
ユーザーが直接編集していた部分に競合が起きる、という問題があります。
一般的なプログラミング言語はテキスト形式で簡単に変更点のマージができますが、ブループリントはバイナリ形式でそれが現状は簡単にできません。

そのため、
ユーザーが触る場所と、開発側がアップデートする場所を明確に分離しています。


🎯 2. テンプレートの進化を止めないため

私(開発側)が後から機能追加・修正をしやすくするために、
基底クラス(CBP_Base / CBP_PlayerBase / CBP_AIBase)はユーザーが触らない構造にしています。


🎯 3. プロジェクトごとに自由に拡張できるように

ユーザーごとに必要になる拡張は異なるため、

  • 共通 → CBP_RetargetBase に集約
  • 個別 → CBP_MyPlayer / CBP_MyAI に自由に追加

という二段構造が最も柔軟です。


■ ユーザーはどこを編集すればいいの?

🟦 編集してOK

  • CBP_RetargetBase(共通ロジック)
  • CBP_MyPlayer(プレイヤー用の最終キャラ)
  • CBP_MyAI(AI用の最終キャラ)

🟥 編集しないほうがいい(テンプレ更新対象)

  • CBP_Base
  • CBP_PlayerBase
  • CBP_AI_Base

■ 今後アニメーションBP(ABP)も同じ思想で設計予定

アニメーションBPは子クラスは構造変更できず、親のロジックで使われているアニメーションシーケンスを差替えるだけの仕組みなため、
現状は手作業でのマージ作業が必須な状況となっています。

が、

  • ABP_Core(開発側)
  • ABP_UserLayer(ユーザー側)

という Linked Anim Layer 方式で同じ分離構造を用いる形に改善予定です。

こちらは後日別記事で詳しく解説します。


■ まとめ

今回紹介した CBP 階層構造は、

  • ユーザーが自由に改造できる
  • テンプレート側のアップデートにも壊れにくい
  • 使い回しやすい

という三つを両立するために設計されたものです。

少し複雑に見えますが、
実際には ユーザーは 共通部と末端 の3つを触るだけなので、
非常にシンプルな運用になります。

よっしー
よっしー

複数人での開発などにも参考になれば幸いです

コメント

タイトルとURLをコピーしました