ReactiveVars

The problem it removes

A health bar needs to know about health. The naive fix is a reference: the UI holds the player, or a manager holds both. Six months later that reference is a chain four objects long, the UI can't be tested without a player in the scene, and deleting any one system breaks three others.

ReactiveVars replaces the chain with a shared asset. A FloatVariable lives in the project rather than the scene. Systems that change health write to it. Systems that display health subscribe to it. Neither knows the other exists, and either can be deleted without the other noticing.

What ships in the package

• Variable types. Float, int, bool, string and others, each a ScriptableObject asset with change notification.
• 50+ binders. Drop-in components that wire a variable to a UI element or object property without writing a subscription by hand.
• Drivers for input, physics and timers, so a variable can be fed from the engine rather than from gameplay code.
• A tween system for interpolating a variable over an animation curve instead of snapping.
• Game events and branching sequences with visual graph authoring, for the sequencing that would otherwise become a coroutine nobody wants to touch.
• Containers with JSON persistence. A group of variables that saves and loads as a unit.
• An editor window for browsing and editing every variable's value while in Play mode, and a runtime debug overlay for reading them in a build.

Why the editor tooling matters

Decoupling has a well-known cost. When nothing references anything, nothing is obvious. A designer who can't see the current value of a variable, or find what writes to it, will correctly conclude that the architecture is worse than a public field.

That is why the tooling matters as much as the runtime here. The editor window makes every value visible and editable during play, and the debug overlay carries that into a build, which is where VR bugs actually live. You can't read an inspector with a headset on.

Documentation

The docs are written designer-first, with programmer reference material kept separate. That ordering is deliberate. The people who most need to understand a decoupled data layer are usually the ones who didn't choose it.

Install

UPM, via git URL, or as a local folder. Depends on UniRx and TextMeshPro. Input System support is optional.