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 services (ICooldownService, ICooldownScaleSink)
actor traits (IFacingProvider, ITeamProvider, IMovementSpeedFactor)
time providers (ITimeProvider, IWallClockProvider)
generic services (IObjectFinder, IResourceLoader, IRandomProvider, IInputService)
presentation hooks (IWorkbenchFeedback)

These interfaces are intentionally small and focused.

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.