A data-driven settings framework — declare options in a data asset, persist them per-player with zero glue through a generic keyed store or bind them to live game code, and present them on a polished CommonUI screen.
Framework · Settings · Unreal Engine 5
The settings menu every game needs. Declared in data, not code.
CrimsonSettings is a modular settings framework built on Epic's GameSettings architecture: author sections and options in a UCrimsonSettingsDataAsset, tick one box to persist a value per player through a generic keyed store — no delegates, no fields to add — or bind it to live game code when it drives runtime state. The CommonUI screen ships search, tag filtering, presets, named profiles, live preview, confirmation countdowns, and a first-run wizard.
Why CrimsonSettings
Declare, persist, present — three layers that stay independent, so adding an option is a data-authoring task, not a plumbing one.
Options are data assets, not code
Author sections and setting entries — scalar (slider), discrete (options selector), action (button) — in a UCrimsonSettingsDataAsset, right in the Content Browser. Type-specific fields collapse when they don't apply, and a Blueprint UCrimsonSettingRegistry turns the asset into live settings with a single Populate From Data Asset call.
Persist per player with zero glue
The headline feature: tick Persist To Shared Store on an entry and its value saves into a generic Key -> value store on the per-player save — no getter, no setter, no delegate, no field added anywhere. UCrimsonSharedSettingsSubsystem loads it, auto-saves on a debounce, and broadcasts OnSettingChanged so consumers can react live.
Or bind straight to game code
When a setting must drive live state — a volume, a quality preset, a subsystem property — handle K2_BindSetting and wire the _BP value classes' get/set delegates to your own functions. In C++, UCrimsonSettingValueScalarDynamic and FCrimsonSettingDataSource resolve reflected getter/setter paths for resolution, scalability, gamma, and friends.
Two storage backends, scoped right
UCrimsonSettingsLocal extends UGameUserSettings for machine-tied state — resolution, scalability, frame pacing — while UCrimsonSettingsShared is a per-player save for taste: audio, sensitivity, accessibility. A one-call hardware benchmark (RunHardwareBenchmark) auto-detects quality and regenerates the UI to match.
A AAA screen out of the box
UCrimsonSettingScreen and UCrimsonSettingPanel are CommonUI widgets with search, tag filtering, dirty/default indicators, inline conflict warnings, and performance-impact badges built in. Risky settings get keep/revert confirmation countdowns, restart-required settings raise a banner hook, and a first-run wizard handles initial setup.
Presets, profiles & live preview
Ship one-click presets (Low/Medium/High) as UCrimsonSettingPreset data assets, let players save and load named profiles that snapshot every registered setting, and turn on live preview so changes show immediately but only commit on Apply — Cancel reverts everything through the built-in change tracker.
A closer look
From empty project to persisting settings screen in five steps
Create a data asset with your sections and options, make a Blueprint registry that populates from it, subclass UCrimsonSettingScreen with a Settings_Panel widget, and push it onto a UI layer. Tick Persist To Shared Store on each entry and values survive relaunch per player — the Quick Start wires nothing else.
Any plugin can add settings — without touching CrimsonSettings
Because the keyed store holds opaque Key -> value pairs, exposing another system's options is pure data authoring: give each entry a namespaced Storage Key like Camera.FieldOfView, and a consumer module that sees both plugins reads the keys and applies them. Neither plugin gains a dependency on the other — the suite's camera options are wired exactly this way.
The Apply flow players expect from a shipped game
With live preview on, dragging a slider updates the UI but commits nothing until Apply. Flag resolution or display mode with Requires Confirmation and the screen fires a keep/revert countdown after Apply — auto-reverting on timeout. Restart-required settings raise K2_OnRestartRequired for your banner, and the change tracker handles Cancel's rollback for free.
Technical details
- Engine
- UE 5.8
- Platforms
- Windows, Mac, Linux
- Blueprint-ready
- Yes
- C++ required
- No
- Network replicated
- No
- Dependencies
- CrimsonCommon, CommonUI, EnhancedInput, AudioModulation
- Last updated
- June 2026
Frequently asked questions
Do I need C++ to use it?
UCrimsonSettingsDataAsset, the registry and screen are Blueprint subclasses, and binding a setting to game code happens through K2_BindSetting delegates. C++ is there for the advanced tier — Dynamic value classes with reflected data sources for engine-level settings like resolution and scalability.Does it work in multiplayer?
UCrimsonSettingsShared saved per local player. It can be made available server-side for authority checks where a preference affects gameplay — but you shouldn't drive authoritative gameplay from a client's preference value, and the plugin doesn't pretend otherwise.Does it depend on other Crimson plugins?
UCrimsonCommonLocalPlayer, and the ICrimsonInputBindingProvider interface. Beyond that it's engine plugins: CommonUI, EnhancedInput, and AudioModulation. Pair it with CrimsonUI for a primary game layout to push the screen onto, but any UI layer works.How does it relate to the free CrimsonCommon foundation?
Can other plugins or my game add settings without modifying CrimsonSettings?
UCrimsonSharedSettingsSubsystem. A consumer module applies the values — the suite ships camera options (Camera.FieldOfView, Camera.ShakeScale, ...) wired exactly this way, with zero coupling between the two plugins.Ship the settings menu, not the settings plumbing
Author a data asset, populate a registry, push the screen — you have persisting per-player options in a sitting. Then layer in presets, profiles, preview, and confirmation as your game grows.
Pricing
CrimsonSettings is sold on Fab under Epic’s two standard licenses — both include the full plugin, source, and updates.
Completes your setup
Built on the free CrimsonCommon foundation, so it pairs cleanly with the rest of the suite:
Tag-driven Enhanced Input with GAS ability binding.
- Ability Input Binding
- Per-Player Rebinding
- Settings Modifiers
- CommonUI Actions
Game-agnostic CommonUI foundation for menus and HUDs.
- Layer & Dialog System
- Activatable Widgets
- MVVM Base Classes
- World-Space Indicators
Fragment-based saving — each system owns its own data.
- Independent Fragments
- No Cross-Plugin Coupling
- Blueprint-Ready