← OUTLINE

The God Object

Where big scripts go to die

Your player.gd, week 12

• Week 7: movement and jump. Clean. Proud of it.
• Week 8: health, damage flashes, a death animation.
• Week 9: coins, a combo meter, the HUD wants updates.
• Week 10: footstep audio, landing dust, a dash with a cooldown.
• Week 11: dialog when near an NPC, checkpoint saves.
• Week 12: 900 lines, and every feature you add has to tiptoe around every feature you already have.

Inheritance will not save you

First instinct: make a class tree. One axis works fine, until an entity needs two.

THE TREE THAT COULD NOT
Entity
├─ MovingEntity
│  ├─ Player
│  └─ Rival
├─ ShootingEntity
│  └─ Turret
└─ FlyingShootingMoving...Entity   ?!

← OUTLINE

One Part, One Job

GPP: Component, the pattern engines are built from

The component pattern

This is GPP: Component, this week's reading. It is also, quietly, the architecture of every engine you have heard of.

You have been composing all along

RIVAL-BRAINS, SEEN AGAIN
Rival (CharacterBody2D)      the brain
├─ Sprite2D                  the looks
└─ CollisionShape2D          the body

Every child node is a part. Drawing lives in Sprite2D, the physical outline lives in CollisionShape2D, and your script only ever wrote the brain.

Build a part: health_component.gd

extends Node
class_name HealthComponent

signal died
signal changed(current: int)

@export var max_health: int = 3
var current: int

func _ready() -> void:
    current = max_health

func take_hit(amount: int = 1) -> void:
    current = clampi(current - amount, 0, max_health)
    changed.emit(current)
    if current == 0:
        died.emit()

• Plain Node: no position, no sprite. Pure bookkeeping.
• class_name registers the type engine-wide, so any scene can add one.
• It announces (died, changed); it does no killing and no drawing.
• One job: track hit points. That is the whole file.

Bolt it onto anything

PLAYER.TSCN
Player (CharacterBody2D)
├─ Sprite2D
├─ CollisionShape2D
└─ HealthComponent   max_health = 3

RIVAL.TSCN
Rival (CharacterBody2D)
├─ Sprite2D
├─ CollisionShape2D
└─ HealthComponent   max_health = 1

Same part, added as a child in two scenes, tuned differently in the Inspector. The part never asks who owns it; it counts hits for anyone.

Wiring: signals up, calls down

# player.gd
@onready var health: HealthComponent = $HealthComponent

func _ready() -> void:
    health.died.connect(_on_died)

func _on_spike_touched() -> void:
    health.take_hit()

func _on_died() -> void:
    respawn()

• The owner calls down: health.take_hit().
• The part signals up: died fires, whoever cares connects.
• The part never reaches into its owner, so it works inside any owner.

Rules of parts

Lab 4, out Thursday, hands you a kit of parts to build and combine. This slide is its grading rubric in disguise.

← OUTLINE

Numbers Belong in Data

The Inspector is the designer's control panel

You already started

# rival.gd
@export var patrol_speed: float = 140.0
@export var chase_speed: float = 220.0
@export var sight_range: float = 260.0
@export var give_up_range: float = 360.0

• Every @export moves a decision from code to the Inspector.
• Run the game, feel the chase, nudge the number, run again. No code edit between tries.
• That loop is tuning, and whoever owns it controls how the game feels.

Four rivals, one problem

A file full of numbers: Resource

# rival_stats.gd
extends Resource
class_name RivalStats

@export var patrol_speed: float = 140.0
@export var chase_speed: float = 220.0
@export var sight_range: float = 260.0
@export var give_up_range: float = 360.0
@export var flee_speed: float = 260.0

• Scripts hold behavior; this holds settings.
• Saved to disk as .tres files you can name, copy, and git-diff.
• One class, as many files as you want personalities.

One script, four temperaments

# rival.gd
@export var stats: RivalStats

    State.CHASE:
        velocity = to_player.normalized() * stats.chase_speed
        if to_player.length() > stats.give_up_range:
            _change_state(State.PATROL)

FOUR FILES, ZERO NEW CODE
rivals/
├─ chaser.tres     chase 240, sight 320
├─ ambusher.tres   chase 200, sight 220
├─ flanker.tres    chase 220, sight 280
└─ wildcard.tres   chase 180, sight 380

• The brain reads stats.chase_speed instead of its own copy.
• Each rival instance gets a .tres dropped into its stats slot.
• New difficulty mode? A new folder of .tres files. The code never hears about it.

Why the numbers move out

• Tuning without touching code: either teammate can balance the game, even mid-playtest.
• Playtests become number edits: a tester says the chase feels unfair; you change 240 to 220 in a file and rerun.
• Balance you can diff: .tres changes show up in git like any other change, so a bad tune is one revert away.
• Content scales: more enemies, more berries, more mazes become more files, while the codebase stays the same size.

← OUTLINE

Co-op Mode

Your game, in parts and numbers

The parts list

← OUTLINE

Game Over Screen

What you know now

Checkpoint reached

Sources

• Nystrom, Game Programming Patterns: Component (gameprogrammingpatterns.com/component.html), this week's reading.
• Godot docs: Resources (docs.godotengine.org, Scripting section).
• Godot docs: Nodes and scene instances, the engine's own case for composition.
• The rival-brains repo (github.com/LucasCordova/rival-brains): git checkout demo5 runs today's refactor: RivalStats plus four .tres temperaments to swap in the Inspector.