A game-agnostic CommonUI foundation — policy, layouts, activatable widgets, dialogs, world-space indicators, and touch input — that replaces the CommonGame dependency.
Free · Foundation · Unreal Engine 5
Ship menus and HUDs on a battle-tested CommonUI foundation — without the CommonGame dependency.
CrimsonUI is a game-agnostic CommonUI layer: a policy/primary-layout system with one layout per local player and layer-keyed widget stacks, activatable widget and HUD-layout bases, a dialog & messaging subsystem, MVVM base classes, a pooled world-space indicator system, simulated touch input, and performance-stat widgets. It ships base classes only — you supply the visual layer; CrimsonUI handles routing, lifecycle, and input config.
Why CrimsonUI
Everything a CommonUI front end needs — layout policy, widget bases, dialogs, MVVM, indicators, and touch — wired up and ready to subclass.
Policy & primary layout
One UCrimsonGameUIPolicy spawns one UCrimsonPrimaryGameLayout per local player, and widgets push onto named layer-tag stacks (Game, Menu, Modal). It's the Lyra/CommonUI three-tier policy pattern — wired for you, with a one-call GetPrimaryGameLayout accessor from anywhere.
Activatable widgets & HUD escape
UCrimsonActivatableWidget carries input-mode, mouse-capture, and focus-restoration metadata that auto-applies on activation. UCrimsonHUDLayout routes the Escape/Pause action — Enhanced Input (5.8+) or a legacy tag — to push your pause menu, and UCrimsonTaggedWidget shows or hides HUD elements from the player's ASC tags.
Dialogs & messaging
UCrimsonMessagingSubsystem shows Yes/No, Yes/No/Cancel, OK, and OK/Cancel confirmation and error dialogs from C++ or Blueprint, pushes them onto the modal layer, and fires your callback with the result. Need something custom? Subclass UCrimsonGameDialog and the subsystem still routes it.
MVVM base classes
UCrimsonViewModelBase / Screen / Entry expose the owning ULocalPlayer and a list-row EntryIndex with FieldNotify, so your ViewModels pull per-player state without re-resolving it every frame. Built on the engine's ModelViewViewModel plugin.
World-space indicators
A pooled indicator system projects widgets onto world positions with clamp-to-screen and off-screen arrows. A manager component, per-indicator descriptor, and a layer canvas do the per-frame projection; your widget just implements BindIndicator / UnbindIndicator.
Touch input & perf stats
UCrimsonJoystickWidget and UCrimsonTouchRegion inject synthetic Enhanced Input, so a virtual stick or button fires the same UInputAction as a gamepad — your gameplay code never knows touch exists. Plus FPS, ping, and packet-loss stat widgets grouped under a container with text/graph display toggles.
A closer look
Stand up a working UI stack in a handful of steps
Enable CrimsonUI (and its dependency CrimsonCommon), set the viewport and game-instance classes in DefaultEngine.ini, author a policy and a root layout that calls RegisterLayer for each stack, then push a HUD layout to the Game layer at game start. Blueprint projects never touch a .uproject or a .Build.cs.
Subclass everything, ship nothing extra
CrimsonUI ships only base and abstract classes — no concrete in-game widgets. You supply the visual layer; the plugin handles routing, lifecycle, input config, and pooling. Pick the right base — UCrimsonActivatableWidget for focus-stealing screens, UCommonUserWidget for passive HUD, UCrimsonTaggedWidget for tag-driven visibility, plus button and dialog bases — and the wiring comes free.
Drop the CommonGame dependency
CrimsonUI replaces Epic's CommonGame sample with a maintained, game-agnostic foundation built on CrimsonCommon — policy/layout, tab lists, multi-type list and tile views, drag-and-drop, single-node Blueprint async actions (PushToLayer, ShowConfirmation, CreateWidgetAsync), and UI Extension Point widgets that Game Feature Actions can fill at runtime.
Technical details
- Engine
- UE 5.8
- Platforms
- Windows, Mac, Linux
- Blueprint-ready
- Yes
- C++ required
- No
- Network replicated
- No
- Dependencies
- CrimsonCommon, CommonUI, UMG, EnhancedInput, ModelViewViewModel, GameplayAbilities
- Last updated
- June 2026
Frequently asked questions
Do I need C++ to use it?
PublicDependencyModuleNames.Add("CrimsonUI")).Does it depend on other Crimson plugins?
UCrimsonLocalPlayer, UCrimsonGameInstance, ACrimsonPlayerController, and UI extension subsystem. On the engine side it relies on CommonUI, Enhanced Input, ModelViewViewModel (MVVM), and GameplayAbilities (for ASC tag reads and HUD ability debug).Is it free?
What does it replace?
Does it work for mobile and touch?
UCrimsonJoystickWidget and UCrimsonTouchRegion — inject synthetic Enhanced Input values through the standard injection API, so a virtual stick or button fires the same UInputAction your gamepad and keyboard do. Your gameplay code doesn't need to know touch exists.Build your front end on a foundation, not boilerplate
Enable CrimsonUI and CrimsonCommon, author a policy and a root layout, and push your first HUD in minutes. Every class is yours to subclass — the routing, lifecycle, and input config are already done.
Ready for more? Add a premium system
You're already on the Crimson foundation — these paid systems drop straight in, no glue code.
Layout-agnostic, fully replicated inventory and crafting.
- Pluggable Topology
- Runtime Constraints
- Scoped Containers
- Crafting
- No RPCs to Write
Replicated, GAS-native skill trees with a two-graph editor.
- Two-Graph Editor
- Material Splines
- Server-Authoritative
- Atomic Respec & Loadouts
A full Gameplay Ability System layer for UE5.
- Custom ASC & Abilities
- Slot-Based Augments
- Modifiers & Phases
- Graph-Based Combos