Skip to content

🔗 Status Effects — Integrations

This folder contains optional integration layers that connect the Status Effects system with other RevFramework systems.

It answers one question:

“How do status effects interact with other gameplay systems without creating hard dependencies?”

These integrations are built and supported for RevFramework systems only. They are not intended as a general integration layer for third-party solutions.

🧠 What This Folder Is

The Status Effects Integrations layer is where cross-system behaviour lives.

These integrations allow statuses to:

  • apply healing or damage through Health
  • grant shields or reflect damage
  • be triggered via Pickups

All without the Status system depending directly on those systems.

💡 Why This Exists

The Status Effects system is designed to be:

  • modular
  • standalone
  • deletable

If Status directly depended on Health, Pickups, or anything else:

  • you couldn’t remove systems cleanly ❌
  • you’d introduce tight coupling ❌

Instead:

Status stays clean. Integrations handle the glue.

📂 Structure

StatusEffects/
  HealthIntegration/
  PickupsIntegration/

Each folder represents a specific integration pairing.

🔌 Health Integration

Located in:

StatusEffects/HealthIntegration/

Provides:

  • RegenStatus → heal over time via IHealthWriter
  • ShieldStatus → shield buffer via IShieldTicketPool
  • StatusRegistryHealthIntegration → registers health-based statuses
  • ThornsHealthBridge → injects reflect behaviour into Health rules

Key Idea

Status does not heal or shield directly. It calls into Health via interfaces.

🎁 Pickups Integration

Located in:

StatusEffects/PickupsIntegration/

Provides:

  • StatusApplyEffect → applies statuses from pickups/items
  • StatusPickupEffectDefinition → authoring asset for pickups

Key Idea

Pickups don’t know how statuses work. They just trigger them via the Status API.

⚙️ How Integrations Work

Integrations typically:

  • depend on both systems (Status + target system)
  • implement interfaces from one system
  • call APIs from the other
  • remain thin and mechanical

They are:

  • not gameplay systems
  • not feature layers
  • just bridges

⚠️ Define Gating

Each integration is compile-time gated.

Examples:

  • REV_HEALTH_PRESENT
  • REV_PICKUPS_PRESENT

If the dependency is missing:

  • the integration does not compile
  • there is zero runtime overhead

🧩 Mental Model

StatusEffects   ←→   Integration   ←→   Other System
  • Status remains independent
  • Other system remains independent
  • Integration knows both

⚠️ Gotchas

  • Integrations are optional — you can delete them safely
  • They do not implement networking or replication
  • They should remain lightweight (no heavy logic)
  • Behaviour depends on the target system being present and configured

🛠 Extending

To add a new integration:

  1. Create a new folder under StatusEffects/<System>Integration
  2. Reference both systems via asmdefs
  3. Implement bridge classes
  4. Keep logic thin and explicit

🌍 Third-Party / Custom System Use

These integrations are built for RevFramework systems only.

If you are integrating with non-RevFramework systems:

  • Treat these integrations as reference examples
  • Implement your own bridge or adapter
  • Use the public APIs of each system

👉 Custom or third-party integrations are not supported by this layer.

  • Status Effects (Core)
  • Status Effects (Implementations)
  • Health System
  • Pickups System