Runtime/UnityIntegration¶
Unity-facing wiring. Not game logic.
Runtime/UnityIntegration contains scene-level adapters and Unity-backed components for small framework seams — chiefly input probing and cooldown scaling.
This folder exists so RevFramework systems can stay decoupled, while still having a practical Unity setup that works out of the box in samples and small projects.
Some of what is in here is deprecated
SceneCooldownService and UnityCoroutineRunner implement interfaces that nothing in the framework calls. Both are marked [Obsolete], both still work if you call them directly, and both are scheduled for removal in 2.0. This page used to advertise them as the folder's purpose and invite you to replace them with your own services; that was misleading, and the table below says which components are which.
What is actually in here¶
| Type | Status | What it is |
|---|---|---|
UnityInputService (+ InputServiceRegistry, ReflectionAccessors) | Live | IInputService over legacy input or the Input System package, chosen by reflection so neither package is a hard dependency |
CooldownMultiplierSink | Live | ICooldownScaleSink receiver — this is what Haste actually pushes into |
CurrencyServiceRelay | Live, opt-in | A UnityEvent bridge so an inspector-wired button can raise a currency call |
SceneCooldownService | Deprecated | ICooldownService implementation. Nothing consults the interface — Pickups owns its cooldowns through PickupEffectStaticCooldowns |
UnityCoroutineRunner | Deprecated | ICoroutineRunner implementation. Nothing runs coroutines through it; the framework drives timed behaviour from Update on the component that owns it |
There is no IResourceLoader or IObjectFinder implementation in this folder or anywhere else. Both interfaces are [Obsolete] in Runtime/Core/Abstractions/Services and were never wired up: framework assets are authored references assigned in the inspector rather than loaded by path, and each system uses its own scene-scoped resolver. The implementations that once backed them were removed outright in 1.0.4 because nothing, including the tests, referenced them.
CooldownMultiplierSink, specifically¶
It is worth naming this one, because nothing else in the docs does and it is the receiving half of a feature people do use.
HasteStatus.Apply resolves an ICooldownScaleSink from the target — checking the target's own components, then its parents, then its children — and pushes its multiplier into whatever it finds. If it finds nothing, the status applies, ticks and expires with no effect at all. CooldownMultiplierSink is the shipped implementation of that receiving end: attach it to the actor, or implement ICooldownScaleSink yourself on a component the search can reach.
Its push and pop apply the same floor to the multiplier, on purpose. An earlier version floored on push and divided by the raw value on pop, so a haste buff applied and removed left the actor permanently faster until the stack happened to empty. The comment above Applied() in the source is the record of that; do not "simplify" it away.
What this folder is for¶
- Scene-level service wiring (attach components, simple setup)
- Compatibility helpers that avoid hard dependencies between optional modules
- Safe defaults so samples and teachables work without extra infrastructure
What this folder is NOT for¶
- ❌ Gameplay features
- ❌ System rules / balance logic
- ❌ Extending framework behaviour
- ❌ A required architecture for your game
If you’re building gameplay:
👉 Start in Runtime/Systems/<System> and follow that system’s Public API / Teachables.
Design Intent¶
UnityIntegration is a host adapter layer:
- Systems depend on Core abstractions
- This folder provides Unity-specific implementations of those abstractions
- Nothing here should introduce system-to-system coupling
These implementations are:
- optional
- intentionally simple
You are free to:
- use them as-is
- ignore them entirely if your project already has infrastructure
“Replaceable” does not apply to the deprecated pair
For UnityInputService and CooldownMultiplierSink, replacing the component with your own implementation of the interface works exactly as you would expect — a system resolves the interface and finds yours.
For SceneCooldownService and UnityCoroutineRunner it does not. Writing your own ICooldownService or ICoroutineRunner connects it to nothing, because no framework code accepts or consults either interface. This page previously told you to replace them; taking that advice would have cost an afternoon wiring into a seam with no other end. Own the concept in your own code instead.
Reflection note (important)¶
Some utilities use reflection to support optional dependencies (e.g., Input System support without requiring the package).
This is compatibility glue — not a pattern to copy into gameplay systems.
If you need reflection to integrate gameplay, a supported seam is missing — reach out.
TL;DR¶
Three live components — input, cooldown scaling, a UnityEvent currency bridge — and two deprecated ones kept only because they have been public since 1.0.
Use them, ignore them, but don’t build gameplay systems here, and don’t write an implementation of ICooldownService or ICoroutineRunner expecting the framework to pick it up.