Skip to content

RevFramework — Teaching Overview

The Teaching section contains the Teachable Panels and scene overlays that walk you through each system step-by-step inside Unity.

Note (SKUs): This package includes Teaching panels only for the systems you own.
For example, the Currency & Economy SKU ships only Currency/Economy teaching content.
The Complete package includes Teaching panels for every system.

These are not shipping UI — they’re: - Lightweight IMGUI panels - Focused on learning, debugging, and copying patterns - Safe to drop into any demo or sandbox scene

If you want to understand how a system actually behaves at runtime, this is where you start.

Table of Contents

What Are Teachable Panels?

Teachable Panels are small, focused editor/runtime helpers that:

  • Expose the exact services and calls used by each system
  • Show live results (OpResults, reasons, state changes, balances, stacks…)
  • Provide toggleable options for edge cases (caps, authority, routing, cooldowns…)
  • Mirror the same concepts you’ll see in the docs and sample scenes

They’re designed so you can:

“Press a button, see what happens, then copy the pattern into real UI.”

How to Use This Section

For each system:

  1. Open the matching sample scene under Samples/Systems/<System>/Scenes/.
  2. Press Play. The Teachable Panel is a component already placed in that scene and its overlay draws itself while the scene runs — there is no menu to open. To retune a panel, select its GameObject in the Hierarchy and edit it in the Inspector.
  3. Follow the panel’s inline steps:
  4. Read the Goals / What this teaches
  5. Toggle options
  6. Press buttons
  7. Watch the live output change in the panel and scene
  8. When something makes sense, copy the pattern:
  9. Service calls
  10. Result handling
  11. Events
  12. Authority checks
  13. UI updates

You can freely experiment — the panels operate on live runtime state and will not modify project assets or persist changes unless you explicitly do so.

Note: The sample scenes include pre-configured panels and bindings for clarity. If you copy panels into your own scenes (or delete and recreate sample scenes), you may need to rebind and resize them to suit your layout.

The visual setup (panel width, font sizes, background opacity, etc.) reflects my own testing preferences and may not suit everyone. If you need larger text, higher contrast, or different opacity, adjust the Inspector settings as needed — nothing is locked.

Accessibility matters. If you have a specific accessibility requirement that isn’t covered by the current options, you can reach out to discuss it. Any adjustments are considered case-by-case and focus on improvements that make sense at the panel base level.

Available Teaching Areas

RevFramework provides Teaching panels per system. In SKU packages, you’ll only see the systems included in your purchase:

  • Inventory — items, stacks, slots, restrictions, search, sort, snapshots, save files
  • Pickups — definitions, effects, decorators, cooldowns, world pickups
  • Crafting — recipes, validators, modifiers, routing, offline progress, save files
  • Loot — drop tables, weighted and independent rolls, delivery
  • Health — damage/heal rules, shields, regen, IFrames, combat state, save files
  • Status Effects — DOT/HOT, cleanses, immunity, auras, potency, snapshots, save files
  • Currency — balances, caps, batch operations, awaiters, inventory-backed, save files
  • Economy — a single quickstart panel: buying and rewarding against a currency-only economy
  • Save — a single coordinator panel: capture and restore across participants, failure isolation, carry-over

Save is in every package, unlike the rest of this list. The coordinator it demonstrates lives in Runtime/Core and ships in all four SKUs, so its panel does too — the per-system save participants are the part that appears only if you own the system.

On disk each area is a folder under Teaching/, named without spaces: Status Effects is Teaching/StatusEffects, the rest match their display name.

See the left-hand nav under Teaching for the full breakdown.

Two Kinds Of Panel, And Why It Is Not A Quality Difference

Where a system has enough panels to sort, it splits them into HostileConsumers/ and, where it needs one, Demos/. Economy and Save have a single panel each and no subfolder at all — their panel sits directly at Teaching/<System>/. The folder names are about what a panel can prove, not about how carefully it was written, and it is worth being clear on that before they suggest otherwise.

Every panel under Teaching/ obeys the same two enforced rules: no reflection, and no .Internal namespace access. Both are checked by gates that scan the whole Teaching tree, not just one folder. There is no panel here that reaches inside the framework to make its demonstration work.

A hostile-consumer panel touches nothing it does not own. It is written as though it lived in a separate project consuming RevFramework from outside, so the fact that it compiles and runs is the evidence: the public API was sufficient on its own. That is the claim those panels exist to support, and it is why a panel breaking during a refactor is a signal about the API rather than about the panel.

A demo panel changes something — it attaches a helper component, configures a service, or wires up an optional seam so that receiver-side behaviour can be shown in a scene that does not already have it. That is an ordinary thing for a real game to do. It is also, precisely, why such a panel cannot double as proof that no such change was needed.

Of the panels that ship, the large majority are hostile consumers. The rest are demos because a seam had to be installed for the lesson to be visible at all — and each Demos/ folder says which of those things its panels do.

If you’re new to RevFramework, a solid path is:

  1. Inventory — core mental model: containers, slots, items.
  2. Currency — balances, caps, transactions, preview vs apply.
  3. Crafting — jobs, validators, modifiers, offline progress.
  4. Health / Status Effects — combat flows and runtime effects.

Each section is built to stand alone — you don’t need to learn everything up front.

When one system stops being the interesting part, the Cookbook is where to go next. These panels show a system working; the recipes there show systems meeting — small, complete compositions built from the public seams, each one with its whole implementation on the page.

Safety and Runtime Impact

Teachable Panels are:

  • Editor-only or sample-only where possible
  • Clearly marked as teaching/demo tools
  • Safe to delete from your project once you understand the patterns

They do not add hidden singletons or global state.
If you remove the teaching folder, the core runtime systems remain unaffected.

Why IMGUI

Every panel here is drawn with IMGUI — OnGUI, immediate mode, the old editor-tooling API — rather than uGUI or UI Toolkit. That is a decision, not a shortcut, and it is worth stating because the rest of this page depends on it.

The reason that decided it

We did not want to hand you our interpretation of how your UI should look.

A polished uGUI inventory panel shipped in a teaching folder stops being a teaching panel. It becomes the inventory panel — the one people copy wholesale, the one that fixes a look and a layout for projects that had no reason to share either, and the one whose visual choices quietly become the framework's. RevFramework has opinions about how a container behaves. It has none whatsoever about what your inventory should look like, and shipping a finished-looking one would have expressed an opinion we do not hold.

IMGUI is visually neutral in a way that matters here: it is unmistakably a development tool. Nobody copies its look by accident. That is exactly what makes the instruction in the next section work — "copy the service calls, ignore the layout code" is only realistic advice when the layout code is visibly not a candidate.

Two consequences that also fell out well

It keeps the panels prefab-free. A uGUI panel is a canvas, a hierarchy and a prefab — so every one of these would have arrived as a prefab dropped into the 47 sample scenes, competing with the hierarchy you are trying to learn in. An IMGUI panel is a single component on a single GameObject. Add it, and it draws. RevFramework does ship prefabs — item prefabs under the Inventory samples, and shared props and VFX under Samples/Shared/SharedAssets/Prefabs — but they are authored items and scene dressing, not delivery vehicles for framework behaviour, and none of them is a panel.

It keeps the teaching layer dependency-free. RevFramework.Teaching.UI declares "references": [] and no Teaching assembly references uGUI or TextMeshPro. Had the panels been built on uGUI, every teaching assembly would carry a hard UI-package dependency — in a framework whose runtime deliberately probes for the Input System rather than depending on it.

What it costs

Stated plainly, because these are real:

  • Panels need a GUI context. OnGUI does not fire under -nographics, so the panel suites cannot run in a fully headless job. They do run on every push, on a Linux runner under xvfb — the constraint belongs to that flag, not to headless running as such.
  • They are mouse-first. No touch, no gamepad navigation. Fine for a development overlay, useless as a basis for anything player-facing.
  • They look dated, and that is the point rather than an oversight.

None of these reach a shipped game: panels are Editor-only, REV_TEACHABLES-gated, and explicitly outside the supported runtime surface.

Copying Patterns into Your Own UI

RevFramework deliberately separates:

  • Runtime services & results (the real API)
  • Teaching panels (examples and overlays)
  • Sample UI (reference implementation)

When you want to build production UI:

  1. Look at the Teaching panel for the behaviour you want
  2. Copy the service calls and result handling into your own UI code
  3. Ignore the IMGUI/layout code — that’s just scaffolding

You should never feel “locked into” the teaching UI.
It’s a playground and reference, not a requirement.