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

Effect behaviour only; the controller coordinates it

  • 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.