Skip to content

RevFramework – Sample Scene: 00_Save_Quickstart

Goal

Teach the whole save contract with no system installed:

Participants → RevSaveCoordinator.Capture → one payload string → RevSaveCoordinator.RestoreRevSaveReport.

This scene has no system dependencies by design.


What This Scene Demonstrates

The coordinator composes any number of IRevSaveParticipants into a single versioned payload, and routes a saved payload back to them.

The flow is:

IRevSaveParticipantRevSaveCoordinator.Capture → payload → your storage → RevSaveCoordinator.RestoreRevSaveReport

  • The coordinator never parses a participant's data
  • It asks for a string, labels it with the participant's key and version, and hands it back later
  • Formats, versions, and meaning all belong to the participant
  • Nothing here writes a file — storage is yours

Both participants are defined inside the panel's own script, in about fifteen lines each. That is the point: your quest flags and unlocked levels join the same save file the framework's systems use, through the same interface, with no privilege difference.

Participant Key Purpose
PlayerProgressParticipant demo.playerprogress Ordinary game state — level, coins, checkpoint
TemperamentalParticipant demo.temperamental Can be made to throw on demand

What To Look For

Use the Save Coordinator panel. Its sections follow the order below.

  • 1. Player Progress (live state)

  • A live readout of level, coins, and checkpoint

  • Advance Progress changes it; Wipe Progress clears it
  • Values return on restore because the payload held them, not because anything was undone

  • 2. Capture and Restore

  • Capture produces the payload string

  • Restore is disabled until something has been captured
  • Restore applies sections in the order you supply the participants, not the order in the file

  • 3. The Payload

  • The real string, not a summary

  • Each section carries its participant's key and version
  • This is exactly what a game would write to disk

  • 4. A Participant That Misbehaves

  • Toggle Capture: fine / Capture: throwing and the same for restore

  • The throwing participant is recorded as Failed; the other still completes
  • One broken section never costs the rest

  • 5. A Save From A Build You Do Not Have

  • Load a save with extra data restores a payload containing a revframework.crafting section nobody here claims

  • It is reported as Unrecognised rather than failing
  • The muted note shows what is being carried over into the next capture

  • Last Result

  • The RevSaveReport for the most recent operation

  • Renders as a success box or a warning box depending on the outcome

Sample Scope

This scene covers:

  • Implementing IRevSaveParticipantKey, Version, Capture, Restore
  • Composing participants with RevSaveCoordinator.Capture and Restore
  • Reading a RevSaveReport and its per-section outcomes
  • Failure isolation when a participant throws
  • Carry-over of sections no participant claims

This scene does NOT cover:

  • File I/O, encryption, or cloud storage — the coordinator does none
  • Any framework system's save format (see Integrations/Save/)
  • Scene-object identity via StableId
  • Version migration between payload versions
  • Multiplayer replication or networking

How To Use

  1. Enter Play Mode. The panel is drawn through OnGUI and shows nothing in edit mode.
  2. Press Advance Progress two or three times and watch the live readout change.
  3. Press Capture. Section 3 fills with the real payload string.
  4. Press Wipe Progress. The readout resets.
  5. Press Restore. The values come back, and Last Result reports what each section did.
  6. Toggle Capture: throwing, then press Capture. The temperamental section is reported Failed while player progress still captures.
  7. Set it back to Capture: fine, then toggle Restore: throwing and press Restore for the same behaviour on the way back in.
  8. Press Load a save with extra data. The unclaimed revframework.crafting section is reported Unrecognised and the note shows it is being carried.
  9. Press Capture again and read the payload — the unclaimed section is still there.

Step 9 is the one worth pausing on: without carry-over, saving on a build with a system removed silently destroys that system's data.


Failure Behaviour

  • Panel is not visible

  • The panel draws in Play Mode only

  • Fix: enter Play Mode

  • Panel is a missing script

  • REV_TEACHABLES is not defined, or Teaching/ has been removed

  • Expected after a Pre-Build Clean — the panel is gated on that symbol on purpose

  • Restore button is disabled

  • Nothing has been captured yet in this session

  • Fix: press Capture first

  • A section reports Failed

  • That participant threw — in this scene, because you asked it to

  • The report names the key and the message; the other sections are unaffected

  • A section reports Unrecognised

  • No participant claimed that key

  • Normal when loading a save written by a build with more systems installed

Behind The Scenes

The panel uses public Core Save APIs:

  • IRevSaveParticipant

  • Key, Version, Capture(), Restore(payload, version)

  • RevSaveCoordinator.Capture(participants, out report, carryOver)

  • composes one payload, optionally carrying unclaimed sections forward

  • RevSaveCoordinator.Restore(payload, participants)

  • routes each section to the participant that claims its key

  • RevSaveReport

  • Success, Outcomes, Unrecognised, Unapplied, PartiallyApplied, Displaced

  • RevSaveSection

  • key, version, payload

The report's Unrecognised list is fed straight back into the next Capture — that is the whole carry-over mechanism, and there is nothing else to it.


Key Takeaway

The coordinator composes. Participants own their data.

It never parses a payload, never writes a file, and never privileges a framework system over yours — which is why the two participants teaching it here are fifteen lines each and live in the panel.