RevFramework – Sample Scene: 00_Save_Quickstart¶
Goal¶
Teach the whole save contract with no system installed:
Participants → RevSaveCoordinator.Capture → one payload string → RevSaveCoordinator.Restore → RevSaveReport.
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:
IRevSaveParticipant → RevSaveCoordinator.Capture → payload → your storage → RevSaveCoordinator.Restore → RevSaveReport
- 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 Progresschanges it;Wipe Progressclears it-
Values return on restore because the payload held them, not because anything was undone
-
2. Capture and Restore
-
Captureproduces the payload string Restoreis 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: throwingand 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 datarestores a payload containing arevframework.craftingsection nobody here claims - It is reported as
Unrecognisedrather than failing -
The muted note shows what is being carried over into the next capture
-
Last Result
-
The
RevSaveReportfor the most recent operation - Renders as a success box or a warning box depending on the outcome
Sample Scope¶
This scene covers:
- Implementing
IRevSaveParticipant—Key,Version,Capture,Restore - Composing participants with
RevSaveCoordinator.CaptureandRestore - Reading a
RevSaveReportand 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¶
- Enter Play Mode. The panel is drawn through
OnGUIand shows nothing in edit mode. - Press Advance Progress two or three times and watch the live readout change.
- Press Capture. Section 3 fills with the real payload string.
- Press Wipe Progress. The readout resets.
- Press Restore. The values come back, and Last Result reports what each section did.
- Toggle Capture: throwing, then press Capture. The temperamental section is reported
Failedwhile player progress still captures. - Set it back to Capture: fine, then toggle Restore: throwing and press Restore for the same behaviour on the way back in.
- Press Load a save with extra data. The unclaimed
revframework.craftingsection is reportedUnrecognisedand the note shows it is being carried. - 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_TEACHABLESis not defined, orTeaching/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.