(Advanced) Connecting signals through script

[Siltag]

Good question. This is where architecture either stays clean or turns into wiring hell.

Short answer:

Yes, signals must be connected.
But you do NOT have to manually connect them everywhere.

There are cleaner patterns.

---

First: Understand the rule

A signal does nothing unless something connects to it.

Declaring:

signal died

does NOT automatically notify anyone.

Godot will never auto-connect across scenes.

So the real question becomes:

Who should be responsible for connecting?

---

Pattern 1 — Parent wires child (most common, clean)

Component emits.
Parent listens.

Example:

# HealthComp.gd
signal died

Parent:

@onready var health := $HealthComp

func _ready():
	health.died.connect(_on_died)

Why this is good

• Parent owns lifecycle
• Clear direction
• Explicit
• Scales well

You must connect once per usage — but it’s clean.

---

Pattern 2 — Self-connecting component (when appropriate)

Sometimes a component depends on another component.

Example:

# HealthComp.gd
@export var owner_body: CharacterBody2D

func _ready():
	died.connect(owner_body._on_died)

This removes wiring from parent.

⚠️ Only do this when:

• Relationship is guaranteed
• The dependency is stable
• It won’t create circular logic

Otherwise this becomes hidden coupling.

---

Pattern 3 — Auto-connect by convention (cleanest for components)

This is my recommendation for you.

Component emits signal.

Parent does NOT manually wire specific functions.

Instead:

func _ready():
	for child in get_children():
		if child.has_signal("died"):
			child.died.connect(_on_child_died)

This scales:

• Add new HealthComp → automatically connected
• No manual wiring every time
• Clean for composition

---

Pattern 4 — Editor connection (low code, high coupling)

In the editor:

• Select node
• Signals tab
• Connect to parent

Good for UI.
Not great for reusable gameplay components.

---

Pattern 5 — Global event bus (advanced)

Autoload:

signal enemy_died

Components emit:

GlobalEvents.enemy_died.emit(self)

Systems listen globally.

Good for:

• score systems
• achievements
• meta systems

Not for local combat.

---

What you SHOULD do in your current project

For gameplay components (HealthComp, MovementComp, etc.):

Use Pattern 1.

Parent wires child in _ready().

It is explicit.
It is predictable.
It is not heavy.
It scales fine.

You are not building a reactive framework.
You are building a game.

---

Important mental model

Signals are not magic binding.

They are just:

“Hey, something happened.”

Someone must choose to care.

---

Final answer

Yes, you must connect signals.

No, there is no automatic connection.

The clean way:

• Parent connects child signals in _ready()
• Or use small auto-wiring loops
• Do not over-abstract early

If you want, next we can:

• refactor your current HealthComp signal wiring cleanly
• remove unnecessary signals
• decide when direct calls are better than signals

Good.
Now you’re asking the right architectural question.

You’re worried that:

If the parent defines _on_basic_enemy_hit,
it needs to know about the component’s internals,
which defeats the purpose of having a component.

Correct instinct.

And the answer is:

👉 If the parent needs component internals, your signal direction is wrong.

---

The Core Rule (Important)

A component should:

• Own its own state
• Own its own logic
• Emit signals only for external consequences

The parent should:

• React to high-level events
• Not manage component internals

If the parent is manipulating _currentHP, armor, etc.
You’ve broken encapsulation.

---

In your specific case

You have:

func _on_basic_enemy_hit(dmg: damage_profile, source_location: Vector2):
	take_damage(dmg, source_location)

That function lives in HealthComp.

Good.

That means:

• The component handles damage.
• Parent does not need to know anything.

So far so good.

---

Where you’re going wrong conceptually

You’re thinking the parent must define:

func _on_basic_enemy_hit(...)

But that’s only true if:

• The signal is connected to the parent.

It doesn’t have to be.

---

Correct Architecture (simple and clean)

Let the component connect to what hits it

Instead of:

Enemy → emits signal → Parent handles → calls component

Do:

Enemy hit signal → directly connected to HealthComp

So in enemy:

hit.connect(health_comp._on_basic_enemy_hit)

Now:

• Parent doesn’t define anything
• Component owns damage logic
• No variable leakage
• Encapsulation preserved

---

Even Better (cleaner still)

Remove _on_basic_enemy_hit entirely.

Just connect directly:

hit.connect(health_comp.take_damage)

If signature matches.

Now:

• No forwarding function
• No duplication
• Clean composition

---

When should parent handle signals?

Only when:

• Death affects score
• Death triggers spawn
• Death changes game state
• Parent owns consequence

Example:

health_comp.died.connect(_on_died)

func _on_died():
	queue_free()

That’s correct ownership.

---

What you must avoid

Parent doing:

health_comp._currentHP -= ...

or

Parent recalculating max HP.

That kills component isolation.

---

So your fear is valid — but misapplied

You don’t need to move variables to parent.

You need to:

• Connect signals in the right direction
• Let components handle their own logic
• Let parent only react to outcomes

---

Short Answer

No — you do NOT need to move component variables to parent.

If you feel like you must, it means:

• You’re connecting signals at the wrong level.

Connect the emitter directly to the component that cares.

---

If you want, we can:

• Refactor your current health + hit system into the cleanest form
• Or simplify it drastically (you might be overcomplicating)

Tell me which direction you want.

Good. That’s a precise requirement.

You’re fine with the parent doing wiring,
you just don’t want this:

func _on_health_died():
    movement.stop()

That’s reasonable. You want wiring without logic living in the parent.

---

The clean solution

You don’t need a parent handler function.

You can connect directly to the sibling’s method.

Instead of:

health.died.connect(_on_health_died)

func _on_health_died():
    movement.stop()

Do this:

health.died.connect(movement.stop)

That’s it.

No wrapper function.
No glue logic.
No duplication.

---

Even cleaner (multiple listeners)

If multiple components should react:

health.died.connect(movement.stop)
health.died.connect(attack.disable)
health.died.connect(ai.shutdown)

Parent only wires.
Components own behavior.

---

Why this is correct architecture

• HealthComp emits event
• Parent wires event routing
• Components define their own reactions
• Parent contains zero behavior
• No tight sibling coupling
• No wrapper functions

Parent becomes a mediator, not a logic holder.

That’s good design.

---

If you want even less visual noise

You can group connections:

func _ready():
    var reactions = [
        movement.stop,
        attack.disable,
        ai.shutdown
    ]

    for r in reactions:
        health.died.connect(r)

Still no parent logic.

---

Important boundary

Parent should:

• Connect signals
• Instantiate components
• Orchestrate relationships

Parent should NOT:

• Implement component logic
• Reach inside component state
• Duplicate component behavior

You’re on the right side of that boundary.

---

Final answer

Yes — let the parent connect signals.

No — you do not need wrapper functions.

Just do:

health.died.connect(movement.stop)

That’s the cleanest version of what you want.

---

If you want next:

• how to auto-connect all components generically
• how to eliminate even this wiring boilerplate
• or how to design a small event bus inside the entity

Tell me which direction.