CrimsonSaveSystem
CrimsonSaveSystem is a fragment-based save system built for multiplayer projects. Instead of one monolithic save file, each saveable system writes its own fragment - a small, independent .sav file inside the save slot directory. Systems register themselves and contribute their own data without knowing about each other, and actors placed in your levels persist automatically.
No Crimson plugin dependencies
CrimsonSaveSystem has zero required Crimson plugin dependencies beyond
CrimsonCommon. Any plugin that needs save support depends on this plugin directly and implements its own fragment independently.What's included
| System | Key types | Purpose |
|---|---|---|
| Fragment saves (systems) | ICrimsonSaveableSystem, UCrimsonSaveGameManagerSubsystem | Persist data-owning systems - inventory, progression, settings - as independent .sav fragments. |
| World-state saves (actors) | ICrimsonSaveableActor, UCrimsonSaveWorldManagerSubsystem | Persist actors placed or spawned in a level (doors, chests, levers) automatically, with no registration. |
| Slots, metadata & menu API | UCrimsonSaveGameHeader, ECrimsonSaveSlotType, UCrimsonSaveFacade | Per-slot header - display name, date, play time, thumbnail - plus UCrimsonSaveFacade, a one-call Blueprint library for building save/load menus. |
| Multiplayer scoping | UCrimsonSavePlayerIdentity | Global vs per-player fragments; dedicated-server, listen-server, and single-player ready. |
| Turnkey layer (CrimsonCore) | ACrimsonPersistentActor, ACrimsonPlayerState | Optional ready-made GameMode / PlayerState wiring and a persistent-actor base. |
Plugin dependencies
| Type | Name | Notes |
|---|---|---|
| Crimson | CrimsonCommon | Required - logging macros and shared types. |
| Crimson | CrimsonCore | Optional - only for the turnkey layer. See How-To: Turnkey Save Setup with CrimsonCore. |
| Engine | Core, CoreUObject, Engine | Core types, USaveGame, UGameInstance, subsystems, FInstancedStruct payloads. |
| Engine | CoreOnline | Resolving UniqueNetId for per-player save keys. |
| Engine | Slate, SlateCore | Used internally by the runtime module (e.g. save-thumbnail capture). |
| Engine | DeveloperSettings | The Project Settings page (UCrimsonSaveGameManagerDeveloperSettings). |
Which path do I choose?
- A data-owning system (inventory, progression, settings)? Follow Quick Start: Saveable Systems.
- An actor placed or spawned in a level (door, chest, lever)? Follow Quick Start: World Actors.
- Want a working save menu with almost no wiring? Use the turnkey layer - see How-To: Turnkey Save Setup with CrimsonCore.
- An actor placed or spawned in a level (door, chest, lever)? Follow Quick Start: World Actors.
- Want a working save menu with almost no wiring? Use the turnkey layer - see How-To: Turnkey Save Setup with CrimsonCore.
Cardinal rules
1. The simplest path is
2. Never call
3. Never make one fragment depend on another fragment's data. Each system restores itself from its own fragment only.
UPROPERTY(SaveGame) auto-serialization - no getters/setters, no custom fragment. Reach for a custom fragment only for data a SaveGame property can't hold (UObject references, GAS state, computed values).2. Never call
UGameplayStatics::SaveGameToSlot directly - use the CrimsonSaveSystem API exclusively.3. Never make one fragment depend on another fragment's data. Each system restores itself from its own fragment only.