Skip to content

🧩 Health Components

This folder contains optional, plug‑and‑play MonoBehaviour components that extend the Health system without modifying or coupling to HealthSystem itself.

Components in this bucket are:

  • Behavioural helpers, not core systems
  • Opt‑in and safe to remove
  • Designed to react to Health events and state
  • Suitable for gameplay, AI, UI, VFX, audio, and prototyping

If you delete this folder, the core Health system continues to function normally.

📦 What Belongs Here

Health Components are:

  • MonoBehaviours you add to the same GameObject as HealthSystem
  • Event‑driven or state‑driven observers
  • Small, focused behaviours with a single responsibility
  • Free of internal Health logic and mutation rules

They typically: - Subscribe to Health events - Read Health state - Emit UnityEvents or simple signals - Gate or coordinate other systems

They should not: - Implement damage/heal rules - Own health state - Replace HealthSystem functionality - Contain authority, networking, or persistence logic

🧠 Design Philosophy

This bucket exists to keep a clear separation between:

  • Core systems (HealthSystem, rules, pipelines)
  • Authoring data (profiles, configs)
  • Behavioural glue (these components)

Components are intentionally:

  • Easy to understand
  • Easy to remove
  • Easy to replace with custom logic

Think of them as reference patterns and quality-of-life helpers, not required architecture.

🧩 Provided Components

HealthCombatState

A lightweight "in‑combat" tracker.

  • Enters combat when damage is taken
  • Exits combat after a configurable delay with no further damage
  • Optional manual hook for outgoing damage
  • Emits UnityEvents on enter/exit

Common uses: - Gating regeneration - Driving AI behaviour states - Triggering combat music or VFX - Coordinating UI state

This component: - Listens to Health events - Reads Health state for safety - Does not mutate Health

🧭 Usage Guidance

Use Health Components when you want:

  • Behaviour that reacts to Health
  • Inspector‑friendly hooks
  • Minimal coupling
  • Rapid iteration

Avoid adding complex logic here if it: - Belongs in a rule - Belongs in authority - Belongs in persistence/save systems - Needs to be deterministic or server‑authoritative

Those concerns belong elsewhere in the framework.

❌ What Not To Do

  • Do not treat Components as core systems
  • Do not put mutation logic here
  • Do not depend on internal Health types
  • Do not assume Components are always present

These are optional helpers — not required infrastructure.

🔗 See Also