Intro: Why Decoupling Matters Game systems constantly need to talk to each other: stamina drains when sprinting, UI updates when health changes, colliders adjust during crouch. In most controllers, this communication is handled through direct references — one script calling another. That works… until you want to remove or extend a system. Suddenly, you’re untangling spaghetti code where everything depends on everything else. The Modular Third-Person Framework solves this by using C# events and delegates for all system communication. That means systems can talk to each other without being tightly coupled, making the framework modular, extensible, and safe.
The Challenge: Tightly Coupled Systems In a rigid design, developers face:
- Direct dependencies → movement scripts directly reference stamina, health, or UI.
- Hard-to-remove systems → removing stamina breaks sprint logic.
- Limited scalability → adding new mechanics requires editing multiple files.
- Debugging nightmares → every change has ripple effects.
The Solution – Event-Driven Communication The framework uses events and delegates across all major systems. Key Features
- Stamina Events → OnStaminaChanged, OnStaminaDrained notify movement and UI without hardcoded links.
- Health Events → OnHealthChanged, OnDeath broadcast to UI, sound, and game manager.
- Breath Events → OnBreathChanged, OnOxygenOut trigger UI and gameplay changes.
- Movement Events → transitions between states broadcast cleanly to other systems (walk, jump, jog, roll, cover).
- UI Integration → UI listens to events through the PlayerCoreUIOrchestrator (no direct coupling to logic).
- Custom Extensions → developers can subscribe new systems (e.g., AI, quest, VFX) without editing existing code.
Proof: Events in Action Without events:
- Sprinting checks stamina directly inside movement scripts.
- UI polls stamina/health every frame.
- Removing stamina = null reference errors.
With the framework’s events:
- Sprinting state listens to stamina events → drains naturally.
- UI subscribes once → updates only when values change.
- Removing stamina system → no errors; events just don’t fire.
Developer-Friendly by Design
- Publisher/Subscriber Pattern → events broadcast changes; systems choose whether to listen.
- No Hard Dependencies → movement doesn’t know about UI, UI doesn’t know about stamina — they only know about events.
- Performance-Friendly → events fire only when values change, no polling needed.
- Extensible → add new listeners (VFX, AI, achievements) without touching core systems.
- Safe Defaults → if no system subscribes, nothing breaks.
Use Cases
- Health & UI → damage player → health bar updates instantly via event.
- Stamina & Movement → sprint drains stamina; when stamina is empty, event disables sprint.
- Breath & Diving → oxygen runs out → event triggers drowning state + UI warning.
- Game Managers → subscribe to player events (death, stamina empty) for level logic.
Closing: Clean Communication Without Spaghetti With the Modular Third-Person Framework, systems don’t shout at each other directly. They communicate through events and delegates, keeping everything modular, extensible, and safe. That’s why you can add or remove mechanics without fear — the rest of the framework keeps working.
👉 Get the Modular Third-Person Framework on the Unity Asset Store: Modular Third-Person Framework | Game Toolkits | Unity Asset Store