RevByDesign

RevFramework

Modular gameplay systems for Unity developers who write code

Status
Available
Type
Framework
Platform
Unity 6+ · C# · prefab-free
Price
$149 per module · $299 complete bundle
Built with
C# · Unity 6 · ScriptableObjects · Assembly definitions

What it is

Explicit, independent gameplay systems you wire up yourself, in C#, with every piece of state and every requirement visible.

What it isn’t

A no-code solution. Drop-in prefabs that just work. Inspector-only configuration. If you aren’t comfortable scripting in Unity, this is the wrong tool and we won’t pretend otherwise.

Buy on the Asset Store (opens in a new tab) Read the documentation (opens in a new tab) Watch the onboarding series (opens in a new tab)

The argument

Most Unity gameplay packages ask you to accept a bargain: drop in the prefab, get the feature, and don’t look too closely at what it attached to your scene. That bargain is fine right up until the moment you need the system to do something its author didn’t anticipate — at which point you are reverse engineering somebody else’s magic under deadline.

RevFramework takes the other side of that trade. Everything is C#. Nothing is a prefab. There are no required singletons and no hidden dependencies, and every system shows its state, its requirements and its results. Nothing happens behind your back, which also means nothing happens by accident.

The cost is real and worth stating plainly: you have to wire it up. The framework provides logic. You bring the UI, the input and the presentation.

The systems

Each one is independent. Owning one does not require owning any others, and removing one does not break the rest — there is a demonstration of exactly that in the onboarding series, where systems are deleted from a working project and then put back.

Inventory, Pickups & Crafting

Item definitions as ScriptableObject data rather than behaviour, so they are inspectable, versionable and diffable. Slot restrictions and equipment acceptance are evaluated from that data, not hard-coded. Inventories know who owns them and what they are responsible for, so there is no global state to reason about.

Pickups resolve at runtime through composable effects, with optional decorators for VFX, audio and logging — so what happens on pickup is a configuration, not a monolithic handler you have to fork. A pickup can grant an item, currency, a status effect, or anything else you define. It has no hard dependency on Inventory or Health.

Crafting is recipe-driven with explicit inputs and outputs, optional station binding, deterministic evaluation and transparent failure reasons. It integrates with Inventory if Inventory is present, and works without it if not.

The Slots and Restrictions demo scene running in Unity. A RevFramework teachable panel fills the game view, showing seed items, a twelve-slot backpack, and an equipment table listing Weapon, Helmet, Chest, Legs and two accessory slots with an "Allows Selected?" column reading yes or no per slot. The Inspector on the right shows the Bronze Chest Plate item definition — its GUID, display name, stacking, rarity, category, tags, pickup prefab, use effects and equip socket.

Health & Status Effects

Health, damage, regeneration and death handling, with modular status effects — buffs, debuffs, damage over time, timed effects — layered on top. It makes no assumptions about your combat model, your ability system or your character controller, because those are the parts of a game worth writing yourself.

The Crit, Execute and Buffs demo scene. A teachable panel shows an attacker and victim, hit amount, crit chance and multiplier, an execute threshold, an attacker buff and a shield with capacity and reduction settings. The Inspector on the right shows a Damage Rule Hub listing the rules it discovered at runtime — CritRule at priority 50 and ExecuteThresholdRule at priority 90 — each expanded below with its own settings, including an RNG source and seed.

The Inspector in that shot is the architecture argument in one picture: the Damage Rule Hub lists the rules it discovered at runtime, each with its own priority, each independently inspectable. Nothing is hard-coded into a damage function you would have to fork.

Currency & Economy

Currency ledgers, transactions and balances, with economy routing, fees and multi-currency support. Deterministic and adapter-driven.

The Currency Policy Caps demo scene. A teachable panel shows two owners, a currency policy and a balance governed by a minimum of zero, a maximum of 250 and clamp mode. A set, credit and debit row reports a tentative amount of 100, adjusted to 100, outcome OK. Below it a caps-aware transfer from owner A to owner B reports "Blocked: InvalidArgs". The Inspector shows a Currency Set holding Gold and Gems currency definitions.

Note the panel reporting Blocked: InvalidArgs rather than silently doing nothing or quietly clamping to something plausible. A refused operation says it was refused, and why.

In the complete bundle

The complete bundle adds Attributes, and includes Loot alongside the three modules above.

Teachable Panels

Every system ships with panels that explain what it is doing while it does it — in the Editor, in Play Mode, against your actual data rather than a demo scene that has been arranged to succeed.

They are development tools, and the framework is blunt about it: they are not part of the supported runtime surface and they are not meant to ship. The REV_TEACHABLES define is derived from whether the Teaching/ folder is present and re-applied automatically, so clearing it by hand in Player Settings does not stick. Use Tools ▸ RevGaming ▸ RevFramework ▸ Validate ▸ Pre-Build Clean, which moves the optional folders out of the project (into _RevFramework_Trash_PreBuild, reversibly — nothing is deleted), or move Teaching/ yourself.

A player build with the define still set fails to compile on purpose, with a message from RevTeachablesBuildGuard. That is the guard working, not a bug to route around.

Documentation

The documentation is a separate MkDocs site, and it is the real deliverable alongside the code. It states what each system does not do as plainly as what it does, and when earlier advice turns out to have been wrong it says so in place rather than quietly editing history.

Read the documentation ↗ (opens in a new tab)

It is used in anger

ORDA, a horde survival game in development here, is built on RevFramework as an ordinary consumer of it — same package, same public API, no privileged access. Every system it adopts is recorded against what it actually cost: which game code had to change, what glue was required, what failed silently, and where the framework’s assumptions and the game’s design disagreed.

That record exists because a framework nobody has shipped anything with is a hypothesis, not a product.