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 blob stored under the save slot. 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. |
| Pluggable storage | UCrimsonSaveStorageProvider, UCrimsonPlatformSaveStorageProvider | Decides where save bytes go. Defaults to the engine's ISaveGameSystem - correct on PC and console. Swap the class to retarget a directory or a cloud backend. |
| 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.
- Need saves somewhere other than the default location, or on a cloud backend? See How-To: Change Where Saves Are Stored.
- 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.
- Need saves somewhere other than the default location, or on a cloud backend? See How-To: Change Where Saves Are Stored.
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. Where those bytes physically land is the storage provider's job, not yours; see Concept: Where Saves Are Stored.3. Never make one fragment depend on another fragment's data. Each system restores itself from its own fragment only.