CrimsonSaveSystemFree
Get it on Fab

Fragment-based saving where every system owns its own data — no plugin is ever aware of another's save file.

Free · Persistence · Unreal Engine 5

Every system saves itself. No monolithic save file, no cross-system coupling.

CrimsonSaveSystem is a fragment-based save system for multiplayer Unreal projects. Each saveable system writes its own independent .sav fragment — tag a few UPROPERTY(SaveGame) fields, implement one interface, and the Save Manager handles slots, headers, world state, and per-player scoping. No system is ever aware of another's save data.

Video coming soon

Why CrimsonSaveSystem

A decoupled, multiplayer-ready persistence layer — each system owns its data and restores itself, with zero cross-system coupling.

Fragment-based architecture

Instead of one monolithic save file, every system writes its own small .sav fragment inside the save slot directory. Systems register and contribute their own data without knowing about each other — and no fragment ever depends on another's.

Automatic serialization

Tag any field UPROPERTY(SaveGame) and the manager captures it automatically via the engine's proxy archive — no fragment subclass needed. For data that can't be auto-serialized (UObject refs, GAS state), subclass UCrimsonSaveGameFragmentBase and both paths run together.

Save Manager subsystem

One UGameInstanceSubsystem orchestrates everything — new-game saves, save-progress, rotating auto-saves and quick-saves, slot deletion, and a per-slot header with display name, date, play time, slot type, and an optional thumbnail.

World state saves

Level actors opt in with ICrimsonSaveableActor — no registration call. Transform and SaveGame fields persist automatically, runtime-spawned actors are re-spawned on load, and destroyed actors stay destroyed. World slabs survive level transitions and streaming.

Multiplayer & player scoping

Global fragments are shared across all players; player-scoped fragments key per-player off a stable UniqueNetId, stored as Fragment__PlayerKey.sav. Every save is authority-guarded — client calls are rejected — with a full dedicated-server login/logout workflow.

Versioning & migration

Fragments are stamped with a schema version on every save. Override GetCurrentVersion() and UpgradeFromVersion() to migrate older saves before restore — so adding or renaming fields never silently drops a player's data.

A closer look

Make any system saveable in four steps

Enable the plugin, tag your fields UPROPERTY(SaveGame), implement ICrimsonSaveableSystem with a unique GetFragmentName(), and register with the Save Manager. For multiplayer, forward PostLogin and Logout to the manager and per-player loading and flushing are handled for you.

Video coming soon

Decoupled by the Cardinal Rule

No fragment ever reads another fragment's data — each system restores itself from its own fragment only. And you never call SaveGameToSlot directly; the CrimsonSaveSystem API is the single entry point. Any Crimson plugin that needs persistence depends on this one and implements its own fragment independently.

Video coming soon

Tuned from Project Settings, not code

Project Settings → Crimson → Crimson Save Game Manager controls PIE slots, session mode, auto-load on login, auto-save on logout, auto-save and quick-save rotation limits, world-state auto-triggers, a custom header class, and verbose logging — so behavior stays data-driven, not hard-coded.

Video coming soon

Technical details

Engine
UE 5.8
Platforms
Windows, Mac, Linux
Blueprint-ready
Yes
C++ required
No
Network replicated
No
Dependencies
CrimsonCommon, StructUtils, DeveloperSettings, OnlineSubsystemUtils
Last updated
June 2026

Frequently asked questions

Do I need C++ to use it?
No. ICrimsonSaveableSystem, the fragment base class, the Save Manager, and the lifecycle hooks are all Blueprint-accessible — enabling the plugin in Edit → Plugins is the whole install for a Blueprint project. C++ is there if you want it; you only touch a .Build.cs when you reference the plugin's types from your own C++ code.
How does saving work without a monolithic save file?
Each system writes its own independent .sav fragment into the slot directory. Tag fields UPROPERTY(SaveGame) for automatic capture, or subclass UCrimsonSaveGameFragmentBase for data that can't be auto-serialized — both run together. No fragment ever reads another's data, so systems stay fully decoupled.
Does it work in multiplayer?
Yes — it's built for it. Saves are server-authoritative (client calls are silently rejected), fragments can be global or scoped per-player off a stable UniqueNetId, and there's a full dedicated-server workflow with auto-load on PostLogin and auto-save on Logout.
Does it depend on other Crimson plugins?
Only CrimsonCommon, the suite's shared foundation. It depends on no other Crimson plugin — instead, any Crimson plugin that needs persistence depends on CrimsonSaveSystem and contributes its own fragment, so no system is aware of another's save data.
Is it free?
Yes. CrimsonSaveSystem is free on Fab — the persistence foundation that other Crimson plugins build their own save support on.

Add saving to your project today

CrimsonSaveSystem is free and takes four steps to adopt. Tag your fields, implement one interface, and every system saves and restores itself — independently.