RevFramework Documentation¶

This folder contains the bundled documentation for RevFramework systems.
Each system has its own README covering purpose, architecture, setup, and integration.

Audience

RevFramework is designed for developers comfortable with C# scripting in Unity.
If you’re looking for a no-code solution, this isn’t the right tool.

Start Here¶

👉 Start Here

If you're new to RevFramework, read this first.

It explains: - how to approach the framework - how to navigate the docs - how to avoid extending the wrong layer - how to learn using Teachables and Samples

The welcome window, and how to get it back

RevFramework opens a welcome window on your first import, with shortcuts to the documentation, the free test-suite download, and the Discord. It is shown once ever, not once per project, so it will not appear again in later projects — that is deliberate, not a fault.

Open it whenever you want from Tools ▸ RevGaming ▸ RevFramework ▸ Help ▸ Show … Welcome. Each package has its own entry, and an entry stays greyed out unless the systems it covers are actually installed — so a single-SKU install shows one live option, and a Complete install can open any of them.

Module Availability & SKUs¶

RevFramework documentation describes the entire modular ecosystem.

Some systems referenced here may belong to separate SKUs and may not be present in your project unless you’ve purchased that module.

This is intentional

Systems integrate automatically when present
No system is required unless explicitly stated
Missing modules do not cause errors or broken behaviour
Missing systems are treated as absent, not misconfigured
A system earns its place when your game has a problem for which it is currently the simplest appropriate solution — see One Rule

Documentation always shows how systems can work together — not what you must have installed.

Core Systems¶

Inventory ¶

Handles items, containers, equipment, and runtime item logic.

Pickups ¶

World pickups and interactables with modular effect delivery.

Crafting ¶

Recipe-driven item creation with validation and modifiers.

Health ¶

Damage, healing, shields, and combat rule pipelines.

Status Effects ¶

Buffs, debuffs, DOTs, HOTs, and controller-driven lifecycle.

Loot ¶

Drop tables, weighted and independent rolls, modifiers, and delivery to a receiver.

Currency ¶

Ledger-based value system with policies and transactions.

Economy ¶

High-level orchestration across money and items.

Attributes ¶

A general container for the numbers a character is made of — values keyed by owner and id, with bounds, change events, and adapters onto the stat seams other systems consume. Complete only.

Cross-Cutting Areas¶

These are not systems and are not sold separately. Both ship in every package.

Save ¶

The save coordinator collects a labelled string from each participant and hands them back on restore, without ever parsing a payload itself; the manager and file store beside it handle writing and reading. All of that lives in Runtime/Core, so it is in all four packages — the per-system participants that plug into it are the part gated on owning that system.

View Components ¶

Read this before you write a HUD element. A short set of rules for any component that watches a service and draws what it sees — a currency bar, an inventory binder, a buff row. It exists because four separately written components each shipped a different half of the same bug, and every one of them was reachable by hiding a panel and showing it again.

How to Use These Docs¶

Each system folder contains:

Overview → what it does
Mental Model → how it works
Public API → what is supported
FAQ → decision guidance
Integration Surfaces → extension points
Guarantees Matrix → behavioural contract

You do not need to read everything — follow the path that matches your goal.

Integration Language (Important)¶

Documentation uses presence-based language:

“If Currency is present…”
“When Inventory is available…”

This is deliberate.

RevFramework systems: - work standalone
- expose integration hooks
- activate additional behaviour only when other modules exist

No hidden dependencies. No forced bundles.

Events: C# first or designer first?¶

Some systems raise their events in two flavours — a C# event for code, and a serialized UnityEvent for hooks wired in the inspector. Where both exist, which of the two fires first is a per-system fact, not a framework-wide guarantee, and it is not the same in every system:

System	Order
Currency	C# event, then the designer `UnityEvent`
Crafting	C# event, then the designer `UnityEvent`
Health	Designer `UnityEvent`, then the C# event
Status Effects	Designer `UnityEvent`, then the C# event
Pickups	Designer `UnityEvent`, then the C# event

Each of these five is pinned by a test, so it will not change under you without that being a deliberate, visible decision. What you should not do is learn the order from one system and rely on it in another — that is the one mistake this table exists to prevent.

Not every system has both flavours

This section used to open with "every system", which is not true and made the table look exhaustive. Inventory and Loot raise C# events only — there is no serialized UnityEvent in either, so there is no order to know: subscribe in code. Economy raises neither flavour at all.

Pickups has both, on InteractablePickupBase and ShieldSystem, and all three of its emitters are now pinned — so it has a row above rather than a note here. One difference is worth knowing if you create a pickup from code: unlike Health's, these UnityEvent fields are declared without an initializer, so a component added with AddComponent has them null and the designer hook does not fire. Unity's deserializer creates them for a pickup authored in a scene, which is where the order matters; the fields are private, so nothing could have been wired to a runtime-created one anyway.

If you have a designer hook and a code handler that must run in a known order relative to each other, do not lean on the raise order at all. Have one of them do the work and the other observe the result, or sequence them yourself from a single entry point.

Why they differ, and why they have not been unified

It was not a decision, it was drift — four systems written at different times. Unifying them now would silently reverse the order for anyone whose project already depends on the current one, in the two systems that raise the most events. The cost of that outweighs the tidiness, so the behaviour is documented and pinned instead of changed.

Missing Systems¶

If a system is not installed:

Integration paths are skipped
No errors are thrown
Core behaviour continues normally

SKU Overview (Reference Only)¶

System	Inventory SKU	Health SKU	Economy SKU	Complete
Inventory	✅	❌	❌	✅
Pickups	✅	❌	❌	✅
Crafting	✅	❌	❌	✅
Loot	✅	❌	❌	✅
Health	❌	✅	❌	✅
Status Effects	❌	✅	❌	✅
Currency	❌	❌	✅	✅
Economy	❌	❌	✅	✅
Attributes	❌	❌	❌	✅
Save	✅	✅	✅	✅
View Components	✅	✅	✅	✅

The last two rows are not systems and cannot be bought on their own — they are in every package, which is why they have a tick in every column. Loot belongs to the Inventory SKU, alongside Inventory, Pickups and Crafting; it is not a separate purchase. Attributes ships in Complete only — it is the cross-system supply side of the stat seams, and no single system SKU owns that role.

Online Documentation¶

RevFramework Documentation Site

Quote

💡 Use one system, several, or the whole bloody lot.