Skip to content

Runtime/Core/Abstractions

Minimal cross-system contracts. Not a feature layer.

This folder contains small, dependency-light interfaces used by multiple RevFramework systems to communicate without directly depending on each other.

These are contracts only — they do not contain behaviour.

What These Are

Abstractions exist to:

  • allow systems to interact through shared contracts
  • avoid hard references between optional modules
  • keep systems modular and independently shippable

Examples include:

  • damage surfaces (IDamageable, IDamageTakenModifier)
  • cooldown scaling (ICooldownScaleSink)
  • actor traits (IFacingProvider, ITeamProvider, IMovementSpeedFactor)
  • time providers (ITimeProvider, IWallClockProvider)
  • generic services (IRandomProvider, IInputService)
  • presentation hooks (IWorkbenchFeedback)

These interfaces are intentionally small and focused.

Five interfaces in this folder are deprecated and consume nothing

ICooldownService, ICoroutineRunner, IObjectFinder, IResourceLoader and IEventBus are all [Obsolete] and scheduled for removal in 2.0. Each shipped as a public contract with no consumer in front of it: implementing one connects it to nothing, because no framework code accepts, returns or consults it.

They are listed separately from the interfaces above for that reason, and each carries the same note on the interface itself. Runtime/Core/README.md marks the same set. If you were looking for the seam one of them suggests, own the concept in your own code — there is nothing on the other side to plug into.

What These Are NOT

  • ❌ Not a feature implementation layer
  • ❌ Not a “build your gameplay here” surface
  • ❌ Not a substitute for system APIs
  • ❌ Not a grab-bag of reusable utilities

If you are building gameplay features, you should be working in:

👉 Runtime/Systems/<System>

Should You Implement These?

Sometimes — but only when it makes sense.

Examples:

  • Implement IDamageable if your object should receive damage from systems
  • Implement ITeamProvider if you want systems to respect team logic
  • Implement ITimeProvider for custom time control or testing

But:

Do not implement interfaces just because they exist.

Only use them when a system explicitly supports or expects them.

Design Intent

These abstractions are:

  • small by design
  • stable in purpose (but not guaranteed as public API)
  • owned by the framework, not by individual systems

They exist to support:

  • loose coupling
  • clean system boundaries
  • optional integrations

TL;DR

These are contracts that let systems talk to each other — nothing more.
Use them when a system expects them.
Otherwise, stick to system-level public APIs.