Intermediate Godot Tutorial: Composition

Main topic: “Composition” vs “Inheritance” in Godot (GDScript/game architecture)

Inheritance

• Inheritance: child scripts inherit properties/functions from parent scripts, forming a branching “tree” of classes (e.g., Character → Player / Enemy → specific enemies like Zombie / Robot).
• Problem with inheritance: when you add new entities with mixed mechanics (e.g., a flying enemy like a bat when base enemy movement assumes ground movement), inheritance tends to either:
  1. force you to modify the base class (leading to unused/irrelevant code in other variants), or
  2. create more branching subclasses, which quickly becomes overwhelming/overly complex.

Composition (preferred in the tutorial)

• Composition: build entities from self-contained, reusable components that can be mixed and matched.
• Example component set for enemies:
  • Health, Combat, GroundMovement, AirMovement, PlayerInput, AI targeting, etc.
• A bat enemy can be assembled by plugging in only the components it needs, instead of inheriting unwanted behavior.

---

Key Godot-specific point: Godot nodes already favor composition

• Godot’s node system already follows composition:
  • Example: an Area3D uses child nodes like CollisionShape3D (colliders) and MeshInstance (rendering).
• Each node has a singular purpose, and you customize behavior by combining nodes.

---

Tutorial example (practical composition): Component-based pickup item

Demo scene

• A player controller that can move.
• A pickup “star” that:
  • bobs/rotates
  • scales
  • changes color over time
  • detects when the player enters it, printing something like “player detected”.

Initial approach: single script with multiple responsibilities

• One script handles:
  • rotation
  • scaling
  • color change
  • player detection
• Drawback noted in the video:
  • you may add boolean flags to enable/disable features,
  • which creates dead/unused code paths for pickups that don’t need all effects.

Composition approach: split into 4 smaller scripts

Instead of one large script, the tutorial breaks behavior into separate component scripts:

1. rotate over time

   • Extends Node3D
   • Uses a rotate speed
   • Rotates the parent each frame using delta
   • Targets the parent using target = get_parent()

2. scale over time

   • Extends Node3D
   • Uses scale amount and scale speed
   • Modifies target.scale each frame
   • Also targets the parent via get_parent()

3. change color over time

   • Extends Node3D
   • Uses:
     • a color range/gradient
     • a color change rate
     • a reference to the mesh instance whose material color changes over time
   • The mesh is assigned by dragging in the MeshInstance node.

4. player detector

   • Extends Area3D (because it detects overlaps/collisions)
   • Defines a signal (e.g., on player detected)
   • Handles the body_entered event:
     • checks whether the entering body belongs to the correct player group
     • prints a message and emits the signal (or triggers logic)

---

Steps shown in the editor/code

• Create a folder for the new scripts: composition/scripts/new (as shown).
• Create the four scripts and give each one a class name, so it can be added via the Add Node menu.
• For each script:
  • attach it as a child node under the pickup root (Node3D)
  • use get_parent() so each component controls the parent’s transform/material/collision behavior.
• Test by pressing play:
  • removing one component (e.g., deleting scale over time) removes only that behavior.

---

Benefits emphasized by the tutorial

• Components are drag-and-drop, easy to remove/add, and reduce messy boolean-flag logic.
• Encourages keeping code concise and aligned with the node’s responsibility.
• Components can optionally interact via detection signals, and don’t have to be strictly required.

---

Main speakers / sources

• Speaker/source: The YouTube course author/instructor (no specific name provided in the subtitles).