RevFramework — Status Effects • Effects¶

Authoring assets and runtime implementations for buffs, debuffs, crowd control, and utility effects.

This folder defines what effects do, not how they are managed. Lifecycle, stacking, authority, timing, and math are owned by Core.

🎯 Purpose¶

The Effects folder contains two layers:

Layer	Responsibility
Definitions	ScriptableObject assets used to author effect data
Implementations	Runtime classes that execute behaviour

Definitions build effects. Controllers run effects.

🧠 Usage Guidance¶

The system separates:

authoring → Definitions
behaviour → Implementations
execution → Core

This keeps effects:

reusable
testable
decoupled from system rules

🧩 What Lives Here¶

Definitions (Authoring)¶

ScriptableObject assets used to configure effects.

Includes:

PoisonStatusDefinition
BurnStatusDefinition
SlowStatusDefinition
HasteStatusDefinition
VulnerabilityStatusDefinition
StunStatusDefinition
ThornsStatusDefinition
StatusEffectDefinitionBase

Health-linked definitions (RegenStatusDefinition, ShieldStatusDefinition) live under the Health integration area.

Implementations (Runtime)¶

Runtime effect classes that execute behaviour.

Damage / Over Time¶

PoisonStatus
BurnStatus

Buffs / Debuffs¶

SlowStatus
HasteStatus
VulnerabilityStatus

Control / Utility¶

StunStatus
ThornsStatus

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

📦 Folder Overview¶

ScriptableObject definitions for authoring
Runtime effect implementations
Separation between data and behaviour

⚠️ Important Notes¶

Effects must be created as new instances per application
Effects may hold internal state
Potency scaling is applied after construction
Missing integrations are expected to fail safely
Effects do not control lifecycle, stacking, or authority

🧪 Diagnostics¶

Common pitfalls:

Reusing effect instances can lead to incorrect state behaviour
Effects relying on integrations require those systems to be present
Controller-driven interactions (for example spread logic) are expected

🚫 Not for Production Use¶

This folder does not define stacking rules
This folder does not define authority logic
This folder does not implement time systems
This folder does not orchestrate controller behaviour

Core → lifecycle, stacking, authority
Abstractions → contracts and extension seams
Auras → area-based modifiers
Integration → system-specific behaviour

🧠 Mental Model¶

Effects define behaviour. Core decides when and how that behaviour runs.