速いマシン。
曲がりやすいマシン。
空を飛ぶのが得意なマシン。
『カービィのエアライド』には、乗ってみると操作感がまったく違う、個性的なエアライドマシンが登場します。
これだけ性能や操作感が違うと、
「マシンごとに別々の処理を作っているのでは?」
と思うかもしれません。
しかし、桜井政博さんのYouTubeチャンネル「桜井政博のゲーム作るには」では、『カービィのエアライド』について非常に興味深い設計思想が紹介されています。
基本的なマシンの仕様は同じ。
そして、
パラメータを振り切ることで個性を作る。
というものです。
では、この考え方をUnreal Engineで実現するとしたら、どんな構造になるのでしょうか?
この記事では、
- 全マシンで共通するロジック
- マシンごとに異なる見た目や演出
- Data Assetによるパラメータ管理
- 同じBlueprintから違うマシンを作る方法
- パラメータを「振り切って」個性を作れる設計
という観点から考えてみます。
※この記事で紹介するUnreal Engine上の構造は、『カービィのエアライド』や『カービィのエアライダー』の実際の内部実装を解説するものではありません。公開されている設計思想をもとに、「UEで作るなら?」という観点から考察したものです。
エアライドマシンの「仕様は全部同じ」
まず今回の出発点です。
桜井政博さんの「ゲーム作るには」で公開されている『カービィのエアライド【企画コンセプト】』では、製品版のエアライドマシンについて、
それぞれ非常に個性的で、仕様まで異なるように感じるものの、基本的には同じ仕様で作られている
という趣旨の説明があります。
スター型とバイク型という違いはありますが、それ以外の中身はパラメータの違い。
そして、その個性は、
「数値でできうる個性を振り切った結果」
として説明されています。
ここが今回、一番面白いところです。
「違うマシンだから違うプログラムを作る」
のではなく、
同じ仕組みの中で数値を変えることで、別物に感じるほどの違いを作る。
これをUnreal Engineの設計に落とし込んでみます。

まず「同じもの」と「違うもの」を分ける
UEでどう作るかを考える前に、マシンを構成している要素を分解してみましょう。
大きく分けると、3種類あります。
1. ロジック
まずは、すべてのマシンに共通する「ふるまい」です。
例えば、
- 移動する
- 加速する
- 旋回する
- チャージする
- ドリフトする
- 滑空する
といったものです。
「どれくらい速いか」ではなく、そもそも加速できる、旋回できる、滑空できるという仕組みそのものです。
2. 上物
次に、見た目や演出です。
例えば、
- Static Mesh / Skeletal Mesh
- Material
- Texture
- Animation
- VFX
- SFX
など。
同じ「チャージする」という処理でも、エフェクトや音、アニメーションが違えば、プレイヤーから見える印象は大きく変わります。
3. パラメータ
最後が、ロジックへ渡す数値です。
例えば、
- MaxSpeed
- Acceleration
- TurnRate
- ChargeRate
- GlidePerformance
- Weight
などです。
「加速する」というロジック自体は同じでも、Accelerationが違えば加速性能は変わります。
つまり今回考えたい構造は、
ロジック = 何ができるか
上物 = どう見えるか
パラメータ = どの程度できるか
という分離です。

Unreal Engineではどう作る?
では、ここからUnreal Engine上の構造を考えてみましょう。
一番単純な方法は、
BP_WarpStar
BP_WingStar
BP_DevilStar
BP_FormulaStar
というように、マシンごとにBlueprintを作る方法です。
もちろん、これでもゲームは作れます。
ただし今回の前提では、
マシンごとに「ふるまいそのもの」が違うわけではありません。
違うのは主に、
上物とパラメータ
です。
だったら、マシンそのものを別Blueprintとして増やすのではなく、
共通するマシンを1つ作り、差分だけを外から与える
という構造を考えることができます。

共通のマシンBlueprintを作る
まず、
BP_AirRideMachine
という共通Blueprintを1つ作ります。
このBlueprintには、
Root
├ MachineMesh
├ RiderPosition
├ VFX
├ Audio
└ Movement
など、すべてのマシンで必要になるComponentを持たせます。
さらに、
- 移動
- 旋回
- チャージ
- ブースト
- ドリフト
- 滑空
などの共通ロジックも、このBlueprint側に実装します。
ここで重要なのが、
BP_AirRideMachine自身は、自分がワープスターなのかウィングスターなのかを知らない
という状態を作ることです。
BP_AirRideMachineは、
「自分は移動できる」
「自分は旋回できる」
「自分はチャージできる」
ということは知っています。
しかし、
「自分はワープスターだから最高速度は○○」
とは知りません。
マシンごとの情報は、別の場所から受け取ります。

Data Assetでマシンごとの差を定義する
そこで使えるのが、Unreal EngineのData Assetです。
例えば、
BP_MachineDefinition
というマシン定義用のData Assetクラスを作ります。
ここに、
Visual
├ Mesh
├ Material
├ Animation
├ VFX
└ SFX
Parameters
├ MaxSpeed
├ Acceleration
├ TurnRate
├ ChargeRate
├ GlidePerformance
└ Weight
などを定義します。
そして、この定義をもとに、
DA_WarpStar
DA_WingStar
DA_FormulaStar
DA_HeavyStar
DA_DevilStar
DA_SlickStar
といったマシンごとのData Assetを作ります。
つまり、
Blueprintはマシンの動き方を知っている。
Data Assetは、そのマシンが何者なのかを知っている。
という役割分担です。

Level上では同じActorでも、別のマシンになる
例えばLevel上に2つ、
BP_AirRideMachine
を配置したとします。
片方には、
DA_WarpStar
もう片方には、
DA_WingStar
を指定します。
Actor Classとしては、どちらも同じBP_AirRideMachineです。
違うのは、
参照しているMachine Definitionだけ。
それだけで、
BP_AirRideMachine
+ DA_WarpStar
= ワープスター
BP_AirRideMachine
+ DA_WingStar
= ウィングスター
という構造にできます。

上物はData Assetから組み立てる
では、見た目はどうしましょう。
例えばDA_WarpStarに、
Mesh → SK_WarpStar
Material → M_WarpStar
Animation → BP_WarpStarSpin
VFX → FS_WarpStarCharge
SFX → SS_WarpStarCharge
といった参照を持たせます。
BP_AirRideMachineがDA_WarpStarを受け取ったら、その情報を使ってMeshやMaterial、VFX、SFXなどを設定します。
ウィングスターなら、
Mesh → SK_WingStar
Material → M_WingStar
Animation → BP_WingStarSpin
VFX → FS_WingStarCharge
SFX → SS_WingStarCharge
という別のセットを渡します。
ロジックそのものを変えなくても、使用するアセットを差し替えることで見た目や演出を変えられるわけです。


パラメータを適用して操作感を変える
見た目だけではなく、性能もData Assetから与えます。
例えばワープスターを、
MaxSpeed = 80
Acceleration = 50
TurnRate = 50
ChargeRate = 50
GlidePerformance = 50
とします。
一方、ウィングスターは、
MaxSpeed = 40
Acceleration = 47
TurnRate = 48
ChargeRate = 50
GlidePerformance = 90
とします。
どちらも実行しているのは同じBP_AirRideMachineのロジックです。
しかし、ロジックへ入力される数値が違います。
その結果、
ワープスターは標準的なマシン。
ウィングスターは飛行性能に特化したマシン。
という違いを作れます。


同じBlueprintから個性的なマシンを作る
ここまでの構造を整理すると、
BP_AirRideMachine
↑
共通するマシンロジック
+
Machine Definition
↙ ↓ ↘
DA_WarpStar DA_WingStar DA_DevilStar
という形になります。
Actor Classは全部同じ。
でも、渡されるData Assetが違う。
その結果、
- 標準的なワープスター
- 飛行特化のウィングスター
- 攻撃特化のデビルスター
といった、まったく違う個性を持ったマシンとして振る舞います。

「パラメータを変える」ではなく「振り切る」
そして、ここからがこの設計の面白いところです。
単純に、
Attack = 50
Attack = 55
Attack = 60
程度の違いを作っても、プレイヤーからすると「ちょっと攻撃力が高い」程度にしか感じないかもしれません。
そこで、パラメータを振り切ります。
例えば攻撃特化のマシンなら、
HP = 40
Defence = 10
Attack = 100
ChargeRate = 50
GlidePerformance = 50
とする。
すると、
圧倒的な攻撃力を持つが、非常にもろい
という個性になります。
あるいは最高速度を、
MaxSpeed = 100
Acceleration = 20
Drift = 30
TurnRate = 35
とすれば、
圧倒的に速いが、加速が弱い。
さらに、
MaxSpeed = 70
Acceleration = 80
Drift = 0
TurnRate = 5
Charge = 100
とすれば、
速い。でも曲がれない。
という極端なマシンも作れます。
重要なのは、新しいロジックを追加したわけではないことです。
同じ仕組みに対して、入力する数値を振り切った。
それだけで、ゲームプレイ上の個性が生まれます。



パラメータを振り切れる「土台」が必要
ただし、単純に数値を大きくすればいいわけではありません。
例えば、
MaxSpeed = 200
にした結果、
速すぎてカメラが追いつかない。
あるいは、
Drift = 200
にした結果、
滑りすぎてまともに移動できない。
これでは、個性的ではあってもゲームとして成立しません。
つまり、パラメータによって個性を振り切るためには、
極端な値を入れてもゲームとして成立する共通ロジック
が必要になります。
これはかなり重要なポイントだと思います。
パラメータ設計というと、
「どんな数値にするか」
ばかり考えがちです。
しかし実際には、
その数値をどこまで動かせるようにゲーム側を設計しているか
も重要です。
パラメータの自由度が高ければ、その分だけ同じロジックから生み出せるゲームプレイの幅も広がります。

「何が同じで、何が違うのか」を考える
今回の構造を一度整理します。
ロジック
すべてのマシンが同じふるまいをする。
移動、加速、旋回、チャージ、滑空などの仕組みそのものです。
上物
見た目・演出を変える。
Mesh、Material、Animation、VFX、SFXなどです。
パラメータ
ふるまいの大きさ・程度を変える。
MaxSpeed、Acceleration、TurnRate、ChargeRateなどです。
つまり、
共通ロジック
+
上物の差
+
パラメータの差
↓
個性的なマシン
という構造です。

この構造なら新しいマシンも追加しやすい
この設計にはもう一つメリットがあります。
新しいマシンを追加するときです。
例えば、
DA_NewMachineDefinition
を作って、
Visual
├ SK_NewStar
├ M_NewStar
├ BP_NewStarSpin
├ FS_NewStarCharge
└ SS_NewStarCharge
を指定する。
さらに、
Parameters
├ MaxSpeed
├ Acceleration
├ TurnRate
├ ChargeRate
└ Weight
を設定する。
基本的にはこれだけで、
BP_AirRideMachine
+
DA_NewMachineDefinition
という新しいマシンを作れます。
もちろん、本当に既存ロジックでは表現できないマシンを追加するなら、新しい仕組みが必要になることもあります。
しかし、
「新しいマシンを追加する = 新しいBlueprintとロジックを大量に作る」
とは限りません。
既存の土台で表現できる個性なら、Data Assetとアセット、パラメータの追加だけで済みます。

「違うもの」を作る前に、本当に違うのか考える
今回の話は、エアライドマシンだけに使える設計ではありません。
例えば、
- 武器
- 敵キャラクター
- プレイヤーキャラクター
- 車
- アイテム
- スキル
- カード
などにも応用できます。
ゲームを作っていると、
「新しい武器だから新しいBlueprint」
「新しい敵だから新しいBlueprint」
「新しいキャラクターだから新しいBlueprint」
と考えてしまいがちです。
しかし、見た目が違うからといって、必ずしもプログラムとして別物とは限りません。
違うのは、
見た目なのか。
数値なのか。
能力なのか。
それとも本当に、
ふるまいそのものなのか。
ここを分解して考えることで、ゲームの構造はかなり変わります。
まとめ:基本は同じ、個性は差分で作る
今回考えた構造は、とてもシンプルです。
BP_AirRideMachine
が、すべてのマシンに共通するロジックを持つ。
Machine Definition
が、マシンごとのVisualとParametersを持つ。
そして、
上物によって見た目・演出を変え、パラメータによって性能・操作感を変える。
その結果、
基本は同じマシンなのに、プレイヤーからするとまったく違うマシンに感じる。
という状態を作ります。
特に面白いのは、
個性を作るためにロジックを増やすのではなく、共通ロジックで表現できる範囲を広げる
という考え方です。
新しいものを追加するたびに仕組みを増やしていくのではなく、
「既存の仕組みの中で、どこまで違いを表現できるか?」
と考える。
これはUnreal Engineだけでなく、ゲームを設計するときにかなり使える考え方だと思います。

動画でも解説しています
今回の内容はYouTubeでも、図やゲーム映像を使いながら解説しています。

動画では、実際のマシンを見ながら、
「これだけ違って見えるものを、同じBlueprintからどう作るのか?」
という流れで解説しています。
文章より図で見た方が分かりやすい部分も多いので、ぜひ動画も合わせてご覧ください。
参考・出典
今回の記事では、桜井政博さんのYouTubeチャンネル「桜井政博のゲーム作るには」で公開されている『カービィのエアライド【企画コンセプト】』の内容を参考にしています。
桜井政博のゲーム作るには ― カービィのエアライド【企画コンセプト】
本記事で紹介しているUnreal Engine上のBlueprint / Data Asset構成やパラメータ例は、実際の『カービィのエアライド』または『カービィのエアライダー』の内部実装を示すものではなく、公開されている設計思想をもとにした筆者の考察です。
記事・動画内の『カービィのエアライダー』のゲーム画面には、筆者自身がプレイ・録画した映像から取得した素材を使用しています。
コメント