Quick Start: Saveable Systems

By the end you'll have a system - a subsystem, component, or plain object that owns gameplay data - that writes its data to a save fragment and restores it on load.

Systems vs world actors
This track is for objects that hold data but are not placed in your level - inventory, progression, quest log, user settings. To persist an actor placed in the level (a door, chest, lever), follow Quick Start: World Actors instead: it uses a different interface and needs no registration.

1. Enable the plugin

Open Edit -> Plugins, type Crimson in the search box, tick CrimsonSaveSystem's checkbox (and CrimsonCommon, its dependency), and restart the editor when prompted. For a Blueprint project that's the entire install - you never hand-edit the .uproject or any .Build.cs.

Edit -> Plugins -> search 'Crimson' -> tick CrimsonSaveSystem's Enabled checkbox -> restart the editor.
Blueprint-only project?
Enabling the plugin in Edit -> Plugins is the whole installation - there is no .uproject or .Build.cs to edit. The editor writes the plugin entry for you. The C++ step below is needed only when you reference CrimsonSaveSystem types from your own C++ code.

C++ projects: after enabling the plugin above, add its module to your build file so your game code can use its types:

csharp
// YourGame.Build.cs
PublicDependencyModuleNames.Add("CrimsonSaveSystem");

2. Implement ICrimsonSaveableSystem and register it

This is the step that actually makes an object saveable. Implement the ICrimsonSaveableSystem interface, return a unique fragment name, and register with the save manager on startup. Until a system is registered nothing it holds is saved - the SaveGame flag in the next step does nothing on its own.

On an Actor or Actor Component: **Class Settings -> Interfaces -> Add** `Crimson Saveable System`. Override **Get Fragment Name** to return a unique string, then on **Event BeginPlay** call **Register Saveable System** on **Get Crimson Save Game Manager**, passing Self.
Blueprint: host it on an Actor or Component
The C++ example implements the interface on a UGameInstanceSubsystem, which cannot be created in Blueprint. In a Blueprint-only project, implement Crimson Saveable System on an Actor or Actor Component (e.g. an inventory component) instead - Get Fragment Name and Register Saveable System work identically. For a player-owned system, also override Get Player Save Key and return Resolve Player Save Key (Crimson Save Player Identity).
Verify
With bVerboseLogging on (Project Settings -> Crimson -> Crimson Save Game Manager), the output log shows your fragment name registering when the system starts up.

3. Mark the data you want saved as SaveGame

Now that the system is registered, tag each field you want persisted with SaveGame. The manager captures every SaveGame-tagged property on the registered object automatically (via FObjectAndNameAsStringProxyArchive) - no fragment subclass needed for simple data.

For each variable to persist: select it in **My Blueprint** -> **Details -> Advanced** -> tick **SaveGame**. Works on any Actor, Component, or Blueprint that participates in saving.
SaveGame alone does nothing
A SaveGame field is captured only because its owning object implements ICrimsonSaveableSystem and is registered (step 2). Ticking SaveGame on an object that never registers saves nothing. World actors are the exception - they opt in through a different interface, no registration; see Quick Start: World Actors.

4. Save and load

Trigger a save server-side. RequestNewGameSave creates a slot and writes every registered fragment; RequestSaveProgress re-saves the active slot; RequestLoadFromSlot restores it. All save calls are server/standalone only.

From a menu or checkpoint: **Get Crimson Save Game Manager** -> **Request New Game Save** (Slot 0, character name) to start a slot, **Request Save Progress** to re-save, **Request Load From Slot** (0) to restore.
Verify
Change a SaveGame value, call RequestSaveProgress, then RequestLoadFromSlot - the value comes back. A fragment file named after your GetFragmentName appears in Saved/SaveGames/Slot_0/. Want a ready-made save menu instead? See How-To: Turnkey Save Setup with CrimsonCore.

5. Wire your GameMode (multiplayer, optional)

If your game is multiplayer, forward PostLogin and Logout so the save manager can handle per-player fragment loading and flushing. The full wiring rules live in Concept: Multiplayer & Player Scoping.

In your Game Mode Blueprint: **Event On Post Login** -> Get Crimson Save Game Manager -> **Notify Player Logged In** (New Player). **Event On Logout** -> cast Exiting Controller to Player Controller -> **Notify Player Logged Out**. The On Logout event fires while the controller is still valid, so no manual ordering is needed.
Single player
For single-player games the GameMode wiring is optional - the auto-load and save-on-logout Developer Settings still work, but per-player key scoping is not needed so NotifyPlayerLoggedIn/Out are no-ops.
What's next
To persist actors placed in your level, follow Quick Start: World Actors (a different, registration-free path). For a zero-boilerplate menu, see How-To: Turnkey Save Setup with CrimsonCore. To build your own slot list, see How-To: Build a Save/Load Menu.