Skip to content

RevFramework — Status Effects • Implementations

Concrete runtime effect classes that execute gameplay behaviour.

This folder answers one question:

What does this status do when it is applied, ticking, refreshed, or removed?

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

🎯 Purpose

This is the runtime behaviour layer of the Status Effects system.

Implementations:

  • perform gameplay effects (damage, buffs, debuffs, control)
  • react to lifecycle calls from StatusEffectController
  • optionally integrate with other systems
  • are expected to handle missing dependencies safely

Most implementations derive from TimedStatusEffect.

🧠 Usage Guidance

The system separates:

  • behaviour → this folder
  • execution → Core
  • contracts → Abstractions

This keeps implementations:

  • focused on behaviour
  • easy to extend
  • independent from system rules

🧩 What Lives Here

Damage / Over Time

  • PoisonStatus — damage-over-time
  • BurnStatus — fire DoT with optional spread

Buffs / Debuffs

  • SlowStatus — movement speed modifier
  • HasteStatus — cooldown scaling
  • VulnerabilityStatus — damage taken multiplier

Control / Utility

  • StunStatus — disables behaviours by type name
  • ThornsStatus — exposes reflection metadata

Health-linked effects such as RegenStatus and ShieldStatus live in the integration layer.

📦 Folder Overview

  • Runtime behaviour implementations
  • Lifecycle-driven execution via controller
  • Integration points through interfaces and lookups

⚠️ Important Notes

  • Implementations do not control lifecycle, stacking, or authority
  • New instances should be created per application
  • Potency scaling is applied after construction
  • Missing integrations are expected to fail safely

🧪 Diagnostics

Common pitfalls:

  • Reusing effect instances
  • Assuming implementations control execution timing
  • Missing required components for integrations

🚫 Not for Production Use

  • This folder does not define stacking rules
  • This folder does not define authority logic
  • This folder does not implement time sources
  • This folder does not coordinate system behaviour
  • Definitions → authoring assets
  • Core → lifecycle, stacking, authority
  • Abstractions → contracts and extension seams
  • Integration → system-specific behaviour

🧠 Mental Model

Implementations react to lifecycle events. The controller decides when and how they run.