Skip to content

🧩 Health — Components

📦 Folder Overview

This folder contains optional MonoBehaviour components that extend the Health system.

They provide behavioural glue on top of Health without modifying HealthSystem.

🎯 Purpose

Components exist to:

  • React to Health events and state
  • Provide inspector-friendly behaviour
  • Enable quick gameplay iteration
  • Act as reference patterns

They are:

  • Optional
  • Replaceable
  • Safe to remove

🧩 What Lives Here

Behaviour Components

Small MonoBehaviour helpers that respond to Health state and events.

⚠️ Important Notes

Boundaries

Components are:

  • Behavioural helpers
  • Event-driven observers
  • Consumers of Health APIs

Components are not:

  • Core systems
  • Rule implementations
  • Health state owners
  • Networking or persistence systems

🧠 Usage Guidance

Example: HealthCombatState

Tracks whether an entity is in combat.

Behaviour:

  • Enters combat when damage is taken
  • Exits after a delay without damage
  • Can optionally respond to outgoing damage
  • Emits UnityEvents and C# events

Internals:

  • Subscribes to:

  • HealthSystem.Damaged

  • HealthSystem.Died
  • Uses HealthSystem.IsDead for safety
  • Does not mutate health

Typical uses:

  • Regeneration gating
  • AI state transitions
  • Combat feedback (UI, audio, VFX)

Design Constraints

Components should be:

  • Single responsibility
  • Event-driven where possible
  • Stateless or lightly stateful
  • Safe to enable or disable at runtime

Boundaries

Do not:

  • Mutate health directly
  • Implement damage or heal rules
  • Depend on internal types
  • Encode authority or networking
  • Assume components are always present

If behaviour becomes complex, move it to:

  • Rules
  • Handlers
  • Core systems

🧠 Mental Model

  • HealthSystem → owns state
  • Rules → shape behaviour
  • Components → react

Components are observers and coordinators, not systems.

  • Health System
  • Rules
  • Authority
  • Abstractions