Skip to content

☣️ Status Effects — What This System Does (and Doesn’t Do)

This page explains what the Status Effects system is responsible for and what is intentionally left to you.

No implementation details. No hidden assumptions. Just clear responsibility boundaries.


✅ What Status Effects does

Status Effects is responsible for:

  • Applying status effects to runtime actors
  • Tracking active status instances
  • Managing duration, expiration, and ticking
  • Handling stacking, refresh, replace, and per-source stack behaviour
  • Managing potency scaling and duration scaling
  • Supporting immunities, resistances, and adjustable magnitudes
  • Supporting dispels and cleanse-by-tag flows
  • Raising lifecycle events for apply, refresh, remove, and expire
  • Supporting optional authority gating before mutation
  • Providing optional runtime helpers like aura zones, buff bars, registries, and FX hooks
  • Providing extension seams for gameplay-specific integrations

👉 In short:

Status Effects owns the lifecycle and runtime state of status effects


❌ What Status Effects does not do

Status Effects intentionally does not provide:


Combat Balancing

The system supports:

  • DOT
  • HOT
  • slows
  • haste
  • vulnerability
  • stun
  • thorns
  • custom effects

But it does not decide your game balance.

You own:

  • poison damage tuning
  • stun fairness
  • PvP balancing
  • encounter difficulty
  • buff/debuff balance
  • crowd-control limits
  • RPG scaling formulas

The included effects are examples and usable defaults — not mandatory gameplay canon.


Networking

Status Effects does not provide:

  • replication
  • rollback
  • prediction
  • server reconciliation
  • multiplayer sync
  • ownership replication

The system supports optional authority checks.

It does not provide a multiplayer framework.

👉 Status Effects can ask:

“Is mutation allowed?”

But your game decides:

“Who owns this object?”


Persistence

Status Effects does not provide:

  • save/load systems
  • cloud sync
  • offline persistence
  • automatic serialization
  • save slot management

You decide:

  • what gets saved
  • when statuses persist
  • how expiration behaves offline
  • how snapshots are versioned

AI Behaviour

Status Effects does not decide:

  • when enemies cleanse
  • when bosses buff
  • target prioritization
  • combat rotations
  • NPC behaviour
  • encounter scripting

It only provides runtime state and lifecycle handling.


Animation / VFX / Audio Direction

Status Effects includes:

  • events
  • FX hooks
  • optional UI helpers

It does not define:

  • your animator graphs
  • hit reactions
  • stun animations
  • sound design
  • VFX pipelines
  • camera shake
  • presentation style

Those are game-specific presentation layers.


UI Ownership

The system includes optional helpers such as:

  • buff bars
  • icon views
  • icon libraries

These are convenience helpers — not a complete UI framework.

You still own:

  • HUD design
  • boss bars
  • combat text
  • accessibility
  • icon styling
  • layout
  • animation
  • player feedback

🧩 Supported Extension Style

The system is intentionally modular and extension-friendly.

Need Extension Point
Custom status logic IStatusEffect
Potency scaling IStatusPotency
Duration scaling IStatusResistance
Immunity IStatusImmunity
Adjustable magnitudes IAdjustableMagnitude
Authority checks IStatusAuthority
Custom time ITimeSource
Runtime math IStatusMathService
Registry construction StatusRegistry
Scriptable authoring StatusEffectDefinitionBase
UI integration Events / Buff Bar
FX integration StatusFx

🧠 Responsibility Split

Responsibility Owner
Status lifecycle Status Effects
Ticking and expiration Status Effects
Stack handling Status Effects
Potency scaling Status Effects
Duration scaling Status Effects
Immunity / resistance checks Status Effects
Cleanse / dispel flow Status Effects
Runtime status state Status Effects
Multiplayer sync You
Persistence You
AI decisions You
Combat balancing You
Ability logic You
Animation / VFX / Audio You
Final UI / UX You

🧩 The Mental Shortcut

If you’re ever unsure:

  • “What happens while the effect is active?” → Status Effects
  • “How does the effect tick, refresh, expire, or stack?” → Status Effects
  • “Can resistances, potency, or immunity modify this?” → Status Effects
  • “Who owns this in multiplayer?” → You
  • “How is this saved?” → You
  • “How should this be balanced?” → You
  • “How is this animated or presented?” → You

🎯 The Point

Status Effects is designed to be:

  • Modular
  • Explicit
  • Runtime-focused
  • Adapter-friendly
  • Safe to extend through public seams

It gives you:

👉 a reliable status lifecycle and runtime mutation system

It does not try to be:

👉 your entire combat framework


TL;DR

Status Effects owns status lifecycle, ticking, stacking, scaling, and runtime state.

You own persistence, networking, AI decisions, combat balancing, and presentation.