RevFramework

If something fails, it tells you why

That is the rule every system here is built around, and it is the reason the rest of the architecture looks the way it does.

Every Currency, Economy and Inventory operation returns a result object: a success flag, a machine-readable reason code, and an optional message. A refused transaction says what refused it. A rollback can be traced. An authority check that rejects a mutation says so explicitly rather than quietly doing nothing.

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

Modularity is enforced at the assembly level, not by folder convention. Each system compiles independently — delete Inventory and Crafting still builds. Integration lives in optional, define-gated layers, and the scripting symbols update themselves as systems are added or removed. The onboarding series demonstrates it: systems deleted from a working project, then put back.

One deliberate exception, stated rather than discovered: Economy is the integration layer over Currency and Inventory, so it builds on both by design.

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 job-based with preflight validation and progress tracking: batch crafting, validators, modifiers, output routing, workbenches, deterministic RNG and optional offline progress. It integrates with Inventory if Inventory is present, and works without it if not.

Loot ships in this module too. Drop tables with weighted and independent-chance rolls, nested tables with cycle detection, and delivery that accounts for every award — given to the owner, dropped into the world, or named in an Undelivered event. Never silently discarded, which is the failure a loot system is likeliest to hide.

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 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.

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 is all three modules plus Attributes — somewhere to keep the numbers a character is made of, with no fixed stat list and no opinion about what a stat means. How contributions stack is a function you supply, because no two games agree and so nothing ships.

Saving, across all of them

A save layer sits under every system: a coordinator, a file store, participant ordering and carry-over. Save sections carry a format stamp, so a foreign payload is refused rather than restoring as a silent success — and a save written by a build that had a system you have since removed does not lose that data.

Teachable Panels

49 interactive panels across 49 sample scenes. Press Play, read what the panel is teaching, toggle the edge cases, press the buttons, watch live results — balances, stacks, failure reasons, state changes. When it makes sense, copy the service calls into your own UI and delete the panel.

Most are written as hostile consumers: restricted to the public API and nothing else. No internal namespaces, no reflection, no undocumented helpers, no sample-only utilities. If a panel can do it, so can your code.

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.

Testing

	Tests	Assemblies
EditMode	3,240	49
PlayMode	613	26

Both green, run on every push against a clean Unity project in CI. The counts are stated rather than summarised because a number you can check is worth more than an adjective.

The goal was never a coverage percentage, it was predictable architectural behaviour. Hostile Consumer tests exercise the public API the way a real project would, with no access to internals. Internal Truth tests pin assumptions a refactor could silently change — event ordering, rollback paths, authority rejection, restore semantics. PlayMode tests reach Unity lifecycle failures EditMode cannot. Convention tests are structural guards that stop a fixed bug class returning.

Test assemblies are not shipped, so your runtime stays clean and there is no NUnit dependency. The suite is a free download for owners.

Multiplayer

Stated plainly because it is the likeliest mistaken assumption: RevFramework does not implement networking. No replication, no prediction, no rollback.

What it gives you is authority binders — gate mutations through your own ownership and permission rules, across every system that mutates state. NGO, Mirror, Photon, Fusion, or something you wrote. The framework supplies the rules; your netcode drives the simulation.

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.

Alongside it, the Cookbook — 46 recipes, including a category called Systems You Own. That category exists because “we do not ship a quest system” and “here is a quest objective built from what we do ship” are a far stronger pair than either sentence alone.

Quests and reputation are absences on purpose. Both are thin once the primitives beneath them are right, and the Cookbook shows you building them.

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.