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

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.

Currency ¶

Ledger-based value system with policies and transactions.

Economy ¶

High-level orchestration across money and items.

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?¶

Every system raises its events in two flavours — a C# event for code, and a serialized UnityEvent for hooks wired in the inspector. 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

Each system's order 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.

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	✅	❌	❌	✅
Health	❌	✅	❌	✅
Status Effects	❌	✅	❌	✅
Currency	❌	❌	✅	✅
Economy	❌	❌	✅	✅

Online Documentation¶

RevFramework Documentation Site

Quote

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