Customizing the Vitality Systems (Health, Stamina, Breath) for Any Game Genre

Intro: Every Game Needs Vitality Systems Whether it’s managing health in combat, stamina in movement, or breath underwater, vitality systems are core to gameplay. But most controllers hardcode these systems into the player, making them rigid, hard to customize, and nearly impossible to reuse. The Modular Third-Person Framework takes a different approach: Health, Stamina, and Breath are standalone, interface-driven systems. They work out-of-the-box with the player, but they can also be reused across NPCs, AI, or even non-humanoid entities. 

The Challenge: Rigid Vitality Systems Most frameworks tie vitality directly to the player prefab. This leads to: 

• Health being hardcoded into the player, with no reuse for NPCs.
• Stamina values tangled inside movement scripts.
• Breath hacked into dive logic instead of being a modular system.
• UI tightly coupled with logic, making it hard to separate presentation from gameplay.

The Solution – Modular Vitality Systems The framework provides three standalone vitality systems: 

• Health System → Tracks max/current health, applies damage, healing, and destruction events.
• Stamina System → Handles stamina usage, recovery, and drained states for movement and actions.
• Breath System → Manages oxygen levels, depletion, and recovery with event-driven notifications.

 Key Features 

• Interface-driven contracts→
  • IHealthState, IStaminaState, IBreathState define clear APIs.
  • Systems can be attached to player, AI, or NPCs alike.
• Abstract Base Classes → HealthBaseSystem, StaminaBaseSystem, BreathBaseSystem handle shared logic.
• Events & Delegates → notify subscribers on every change (OnHealthChanged, OnStaminaDrained, OnOxygenOut).
• Configurable ScriptableObjects → assign max values, regen rates, depletion thresholds via configs.
• Standalone & Decoupled → UI isn’t tied directly — it listens through the PlayerCoreUIOrchestrator (covered in UI post).

Proof: Flexible Across Genres Without the framework: 

• Stamina is buried in movement → can’t reuse for NPCs.
• Health logic duplicated for enemies and player.
• Diving feels hacked in without a real breath system.

 With the framework: 

• Add PlayerStamina to the player → climbing, sprinting, and swimming automatically drain stamina.
• Attach AIHealth (derived from HealthBaseSystem) to an enemy → same event system powers their health bar.
• Add PlayerBreath to enable diving → breath depletion triggers UI and oxygen-out events.

Developer-Friendly by Design 

• Separation of Concerns → Health, Stamina, Breath exist independently from movement or UI.
• Reusable Architecture → Base classes + interfaces make vitality plug-and-play across any entity.
• Event-driven → Systems broadcast changes; other systems (UI, audio, AI) just subscribe.
• ScriptableObject configs → Designers can tweak max values and recovery rates in the Inspector.
• Extensible → Want energy instead of stamina? Just implement IStaminaState differently.

Use Cases 

• Combat games → robust health & stamina for players and enemies.
• Survival games → stamina for resource gathering, breath for underwater exploration.
• Adventure games → integrate health and stamina seamlessly with climbing, swimming, and diving.
• AI consistency → reuse the same systems for NPCs to ensure a unified game feel.

Closing: Vitality Systems That Scale With Your Game Health, stamina, and breath are fundamental — but they shouldn’t be rigid. The Modular Third-Person Framework makes them modular, reusable, and easy to integrate across all entities, giving you systems that scale with your game’s needs. 

👉 Get the Modular Third-Person Framework on the Unity Asset Store: Modular Third-Person Framework | Game Toolkits | Unity Asset Store