RPGやアクションを作っていると、必ずぶつかるのが キャラクターの量産 です。「スライム」の基本形はできた。でもレベルを作り込むうちに、「HPが多いスライム」「攻撃力2倍のレッドスライム」「レアドロップのメタルスライム」……と、無数のバリエーションが欲しくなります。
最初はつい Slime.tscn をコピペして1体ずつ数値をいじりがちですが、これはすぐ破綻します。あとで「全スライムの移動速度を上げたい」と思ったら、コピーした全シーンを開いて直す羽目になるからです。この記事では、これをエレガントに解決する シーン継承 と Editable Children 、そして大規模化に効く Resourceによるデータ駆動 を、使い分けまで含めて解説します。
この記事でわかること
- シーン継承 ——テンプレートから差分だけ変えて派生させる王道
- 親の変更が 全ての子に自動で伝播 する仕組みと、
superでの拡張- Editable Children ——「この一体だけ」を即席で変える例外処理
- Resource によるデータ駆動との使い分け
動作確認環境: Godot 4.7
シーン継承：テンプレートから派生させる
シーン継承は、オブジェクト指向の「クラス継承」の考え方を、Godotのシーンに持ち込んだものです。既存のシーンを 「親」 とし、その構造と機能をすべて受け継いだ 「子」 シーンを作れます。再利用性と保守性を重視するなら、これが第一候補です。
継承の強みは2つです。
- 差分だけ管理する ：子シーンでは、親から受け継いだプロパティ（位置や
@export変数）を自由に上書きできます。変えた項目はインスペクタに「元に戻す」アイコンが付き、 親との差分がひと目で分かります 。 - 親の変更が子に自動で伝わる ：これが最大の利点です。親シーンにバグ修正や新機能を加えると、その変更は すべての子シーンへ自動で伝播 します。「全キャラ共通の修正」と「特定キャラの個別調整」が同時に成り立ちます。
これは、コピペとは決定的に違います。コピペした複製は親との縁が切れているので、あとから共通の修正をしたくても全部を手直しするしかありません。
実践：BaseEnemyから敵バリエーションを量産する
RPGのスライム色違い、アクションの強化版ザコ、シューティングの弾種違いの敵——「共通の土 台＋種類ごとの違い」は、シーン継承の得意分野そのものです。実際に組んでみましょう。
まず、すべての敵の土台になる BaseEnemy.tscn を作り、共通のスクリプトをアタッチします。数値は @export にして、 子やインスペクタから調整できる ようにするのがコツです。
# base_enemy.gd
extends CharacterBody2D
@export var health: int = 100 # @exportにすると継承先で個別に上書きできる
@export var attack_power: int = 10
@export var speed: float = 50.0
func take_damage(amount: int) -> void:
health -= amount
if health <= 0:
die()
func die() -> void:
queue_free() # 共通の死亡処理（全敵で使い回す）
次に、FileSystemドックで BaseEnemy.tscn を右クリック →「新しい継承シーン」で StrongEnemy.tscn を作ります。この時点では見た目も機能も親と同じ。あとはインスペクタで health を250、attack_power を25に 上書きするだけ で、強化版が完成します。コードは1行も書いていません。
さらに、独自のスクリプトで 親の機能を拡張 することもできます。親のメソッドを上書き（オーバーライド）しつつ、super で親の処理も呼べます。
# strong_enemy.gd
extends "res://base_enemy.gd"
func die() -> void:
print("強敵が断末魔の咆哮をあげた！") # この敵だけの追加演出
super.die() # 親のdie()（queue_free等）も実行する
ポイントは2つです。
- 共通はBaseEnemy、違いだけ子で上書き ：移動や被ダメージの共通ロジックは
BaseEnemyに一本化。子は「どこが違うか」だけを持ちます。だから後日「全敵の移動を直す」ときも、BaseEnemyを1回直せば全バリエーションに伝わります。 superで親を活かす ：die()を丸ごと書き直すのではなく、追加演出だけ足してsuper.die()で親の後始末を再利用します。親の処理を壊さずに拡張できます。
注意:
queue_free()はノードをすぐには消さず、 そのフレームの処理が終わったところで 削除します。削除後のノードを参照し続けると null参照エラー の原因になります。他ノードから参照される場合は、is_instance_valid()で有効性を確認するか、NOTIFICATION_PREDELETEで後始末する習慣をつけましょう。
継承の考え方そのものは GDScriptで使うOOPデザインパターン の記事も参考になります。
Editable Children：この一体だけ即席で変える
シーン継承が「再利用するテンプレートを作る」機能なら、 Editable Children は「配置した特定の1体だけを、その場でいじる」機能です。新しいシーンファイルを作らずに、インスタンス化した子シーンの 内部ノードを直接編集 できます。
こんな「一度きり 」の調整で輝きます。
- ボス部屋のゴーレム1体だけ、腕の
CollisionShape2Dを大きくして攻撃範囲を広げる（形の大きさはShapeリソースの側にあって、ほかのゴーレムと共有しているので、先にShapeを右クリック →「ユニーク化（Make Unique）」してから変えます） - チュートリアル最初の敵1体だけ、
speedを0にして動かなくする
やり方は簡単です。メインシーンに配置したインスタンスを右クリックし、「編集可能な子（Editable Children）」にチェックを入れると、内部のノードがツリーに展開され、直接選択・編集できるようになります。
上の画像では、NPC は折りたたまれた普通のインスタンスですが、NPC2 は Editable Children が有効になっていて、内部の Sprite2D や CollisionShape2D まで展開・編集できる状態です。
ただし、この変更は そのインスタンス限り で、再利用はできません。「後でも使いそう」と思ったら、右クリック →「ブランチをシーンとして保存」で、新しいシーンファイルとして書き出しておくのが定石です。
使い分けと、Resourceによるデータ駆動
3つのアプローチは、目的で使い分けます。
- シーン継承 ：種類ごとに ノード構成や見た目が変わる バリエーション。基本戦略。
- Editable Children ：配置した 1体だけの例外調整 。使い捨ての微調整。
- Resourceデータ駆動 ：構成は同じで 数値だけが違う大量のバリエーション 。
特に、数百種類のモンスターが出るRPGのような規模では、シーン継承だけだとシーンファイルが増えすぎて煩雑になります。そこで、キャラのパラメータを Resource（データ）として分離 する「データ駆動設計」が効きます。
BaseEnemy.tscn に @export var data: CharacterData を1つ持たせ、slime_data.tres や dragon_data.tres を差し替えるだけで、 シーンは1つのまま 何百種類もの敵を表現できます。パラメータ調整は .tres ファイル側で完結します。詳しくは カスタムリソースの作成と活用 を参照してください。
「見た目・構成が違う＝継承」「数値だけ違う＝データ駆動」、そして両者を組み合わせる（継承したシーンにデータリソースを差す）のが、実戦的な落としどころです。
よくある間違いとベストプラクティス
| よくある間違い | ベストプラクティス |
|---|---|
| 何でもEditable Childrenで済ませる | 再利用の可能性があるなら シーン継承 を選ぶ。「後で使うかも」と思ったら継承シーンにする |
| 継承階層を深くしすぎる | 継承は 2〜3階層まで を基本に。それ以上は継承よりコンポジションやデータ駆動を検討する |
| 親シーンが子の状態を仮定する | 親は 自己完結 させ、汎用機能を提供。具体的な振る舞いは子が決める |
| 数値変更のためにスクリプトを増やす | HP・攻撃力・速度は @export にして、デザイナーがインスペクタで安全に調整できるようにする |
おまけ：先に知っておくと良いこと
- 継承よりコンポジション ：オブジェクト指向の定石です。深い継承より、機能を子ノードとして足していく「合成」の方が、Godotでは柔軟に働く場面が多いです。「攻撃コンポーネント」「HPコンポーネント」を組み合わせる発想は、継承の限界を感じたときの次の一手になります。
- 実行時のパフォーマンスは気にしなくてよい ：シーン継承もEditable Childrenも、最終的には1つのシーンツリーとして解釈されるため、実行時の負荷に大きな差はありません。 選ぶ基準は「保守性」 です。
- 継承シーンでノードは消せない ：親由来のノードは子から削除できません。不要なら、子シーン側のスクリプトで
queue_free()します（非表示にするだけでは、当たり判定やスクリプトは止まりません）。
まとめ
- シーン継承 は、テンプレートから 差分だけ変えて派生 させる王道。親の変更が全ての子に自動伝播する
- 子スクリプトで
superを使えば、 親の処理を活かしつつ拡張 できる - Editable Children は、配置した 1体だけを即席で調整 する例外処理。再利用はできない
- 大量バリエーションは Resourceによるデータ駆動 （1シーン＋種類ぶんの
.tres）が管理しやすい - 「構成が違 う＝継承」「数値だけ違う＝データ駆動」「1体だけ＝Editable Children」で使い分ける
まずは BaseEnemy を1つ作り、継承シーンで health を書き換えるところから試してみてください。「親を直すと全部に効く」感覚が掴めれば、量産の設計はぐっと楽になります。
さらに学ぶために
- 「シーン」と「ノード」の基本を徹底解説 ——インスタンス化とシーンの基礎
- カスタムリソースの作成と活用 ——データ駆動でパラメータを分離する
- GDScriptで使うOOPデザインパターン ——継承とコンポジションの考え方
- Godot公式ドキュメント：Scene Inheritance ——シーン継承の一次情報
