CrimsonSaveSystem · Lesson 1 of 8
The Fragment Model
Before you start
- The CrimsonCommon — Setup & Foundations course
- Unreal Engine 5.8+
Chapters
Why fragments
CrimsonSaveSystem doesn't write one monolithic save file. Each saveable system — inventory, progression, settings — writes its own independent `.sav` fragment under the active slot, and level actors persist through their own world-state fragments. Systems register themselves and contribute data without knowing about each other, which is exactly how a modular plugin suite has to save.
The cardinal rules
| Rule | Why |
| Never call UGameplayStatics::SaveGameToSlot directly | The manager owns the slot layout; going around it corrupts the fragment model |
| Never make one fragment depend on another's data | Fragments load independently — a dependency is a race condition |
| Save operations run on the server / standalone only | Client calls are rejected (NM_Client) |
What we'll build
- Enable the plugin
- Make a system saveable and register it
- Trigger saves and loads
- Wire the multiplayer login hooks
- Persist world actors
- Build a save/load menu, then configure auto-saving
Two tracks
Saveable systems (data owners like inventories) implement an interface and register. World actors (doors, chests) implement an interface and are captured automatically — no registration. We'll do both.