Skip to content

RevFramework — Status Effects • Integration

Optional helpers that connect Status Effects to other gameplay systems such as Health.

These integrations are fully optional and intentionally decoupled.

Purpose

This folder contains bridge helpers used by status implementations to interact with external systems.

They answer one question:

How can an effect call into another system safely, if that system exists?

Usage Guidance

The Status system avoids hard dependencies on other modules.

Instead, integrations provide:

  • small, focused helpers
  • interface-based calls where available
  • reflection-based fallbacks when needed

This keeps the system:

  • modular
  • optional
  • safe when integrations are missing

What Lives Here

HealthStatusHooks

Used by:

  • PoisonStatus
  • BurnStatus

Purpose:

  • Routes integer damage ticks into a target exposing IDamageable

Behaviour:

  • Checks for IDamageable
  • Calls Damage(int)
  • Ignores statusId in current implementation
  • Performs no work if target is null, amount ≤ 0, or interface is missing

Folder Overview

  • Helper bridges for external systems
  • Interface-first integration

Important Notes

  • Integration helpers are called from effect implementations
  • They are not part of the core status pipeline
  • Removing this folder does not break the Status system
  • Missing dependencies result in safe no-op behaviour

Diagnostics

Common pitfalls:

  • Assuming integrations apply gameplay rules
  • Expecting integration helpers to run outside effect implementations

Not for Production Use

Bridge helpers, not a system in their own right

  • This folder does not define gameplay rules
  • This folder does not implement controller logic
  • This folder does not define stacking or authority behaviour
  • This folder does not represent a full system implementation
  • Effects → runtime behaviour
  • Core → lifecycle, stacking, authority
  • Abstractions → shared contracts
  • Integration (Health) → extended status behaviour

Mental Model

Integration code does not own gameplay.

It provides safe entry points into other systems and translates between their contracts. Gameplay decisions -- what a status does, how long it lasts, whether it stacks -- belong to the status itself, and health decisions belong to the Health system. Integration code carries a value across the boundary and does nothing else with it.

This is why the bridges here are thin, and why a bridge that finds nothing to talk to reports it rather than inventing a fallback: the absent system is a fact about the project, not an error to paper over.