Skip to content

RevFramework — Status Effects • Implementations

Concrete runtime effect classes that execute actual gameplay behaviour. Most implementations subclass TimedStatusEffect.

This folder answers one question only:

“What happens when a status is applied, ticked, refreshed, or removed?”

Everything else (stacking, authority, math, timing) is owned by Core.

Table of Contents

Overview

Implementations are the runtime logic layer of the Status Effects system.

They: - Perform damage, healing, or stat modification - React to ticking driven by StatusEffectController - Integrate with other systems via explicit sink interfaces - Fail safely when dependencies are missing

Most implementations derive from TimedStatusEffect, which owns: - Duration and remaining time - Tick scheduling (via controller) - FX hook lifecycle

Implementations do not: - Tick themselves - Decide stacking rules - Enforce authority - Apply immunity or resistance - Interact with UI

Mental Model

A status implementation should be pure behaviour.

  • It reacts when the controller calls Apply, Tick, Refresh, or Remove
  • It never queries or mutates controller state directly
  • It never assumes multiplayer authority
  • It never assumes the presence of optional systems

If a dependency is missing, the effect should no-op gracefully.

Available Implementations

DoTs / HoTs

  • PoisonStatus — damage over time
  • BurnStatus — fire DoT with optional propagation
  • RegenStatus — heal over time

Multipliers

  • SlowStatus — movement speed reduction via MovementSpeedScaler
  • HasteStatus — cooldown scaling via ICooldownScaleSink
  • VulnerabilityStatus — increased damage taken via IDamageTakenModifier

Utility

  • ShieldStatus — temporary shield buffer via IShieldTicketPool
  • StunStatus — disables behaviours by fully-qualified type name
  • ThornsStatus — damage reflection via Health bridge

Support / Demo

  • SimpleShieldTicketPool — minimal IShieldTicketPool reference implementation

Sinks & Integration

Implementations integrate with other systems via sink interfaces:

Sink Purpose
IShieldTicketPool Shield buffering
MovementSpeedScaler Movement speed modification
ICooldownScaleSink Cooldown multipliers
IDamageTakenModifier Incoming damage modification

This pattern ensures:

  • No hard module dependencies
  • Safe no-ops when systems are absent
  • Clean separation between systems

Gotchas

  • Always create a new instance per application — never reuse effect objects
  • Potency (IAdjustableMagnitude) and resistance (IStatusResistance) are applied by the controller after construction
  • StunStatus requires fully-qualified type names; invalid types log editor warnings
  • Legacy shield fallback (ShieldLegacyBridge) may wipe all shields — prefer ticket-based pools
  • FX hooks must never mutate gameplay state

Extending

To add a new runtime effect:

  1. Subclass TimedStatusEffect or implement IStatusEffect
  2. Implement behaviour in OnTick, OnApplyFX, OnRefreshFX, or OnRemoveFX
  3. Add optional metadata via IStatusMetadata / IDispellable
  4. Implement IAdjustableMagnitude if potency scaling is required
  5. Integrate external systems only through sink interfaces

Keep implementations focused, defensive, and side-effect conscious.

See Also