A game-agnostic CommonUI foundation — policy, layouts, activatable widgets, dialogs, context menus, indicators, and touch input — that ships working Blueprint assets so a fresh project boots with a complete UI stack.
Free · Foundation · Unreal Engine 5
Ship menus and HUDs on a battle-tested CommonUI foundation. The boot assets are already built.
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, a context-menu system, MVVM base classes, a pooled world-space indicator system, simulated touch input, and performance-stat widgets. And it now ships ready-made Blueprint assets for all of it — policy, root layout, HUD layout, dialogs, context menus, buttons, and CommonUI input data come pre-configured, so you start from a working UI stack and subclass from there.
Why CrimsonUI
Everything a CommonUI front end needs — shipped as working, pre-configured assets you can use as-is, duplicate, or subclass.
Boots out of the box
The UI settings ship pre-filled: B_CrimsonUIPolicy is the default policy, its W_CrimsonOverallUILayout root layout registers a stack for every standard layer, and the dialog and context-menu defaults are already assigned. Enable the plugin, set two classes from Quick Start, push the shipped W_CrimsonHUD_Layout — done.
Policy & primary layout
One UCrimsonGameUIPolicy spawns one UCrimsonPrimaryGameLayout per local player, and widgets push onto UI.Layer.* tag-keyed stacks (Game, GameMenu, Menu, Modal, ContextMenu) defined natively in CrimsonCommon. It's the proven three-tier CommonUI policy pattern — wired for you, with single-node Blueprint push/pop by local player.
Activatable widgets & HUD escape
UCrimsonActivatableWidget carries input-mode, mouse-capture, and focus-restoration metadata that auto-applies on activation. The shipped W_CrimsonHUD_Layout already routes the Escape action to a pause menu and wires the controller-disconnect screen, and UCrimsonTaggedWidget shows or hides HUD elements from the player's ASC tags.
Dialogs & context menus
UCrimsonMessagingSubsystem shows Yes/No, OK, and OK/Cancel dialogs from C++ or a single Blueprint async node — the confirmation widgets ship ready to use. New in this release: UCrimsonContextMenuSubsystem pops cursor- or world-anchored action menus (modal, world, and radial presentations shipped) whose actions are gathered from the target itself — the same gather the server re-runs to validate the pick.
MVVM, tabs, lists & drag-drop
UCrimsonViewModelBase / Screen / Entry expose the owning ULocalPlayer and a FieldNotify list-row index. Alongside them: tab lists with runtime registration, list/tile views that pick a widget class per item type, payload drag-drop, countdown buttons, and input-glyph buttons that follow the player's device.
Indicators, touch & perf stats
A pooled indicator system projects widgets onto world positions with clamp-to-screen and off-screen arrows. UCrimsonJoystickWidget and UCrimsonTouchRegion inject synthetic Enhanced Input, so a virtual stick fires the same UInputAction as a gamepad. Plus FPS, ping, and packet-loss widgets under a display-mode container.
A closer look
Boot a working UI stack without building a single widget
Enable CrimsonUI (and its dependency CrimsonCommon), set the Game Instance and Local Player classes, set the viewport client, and push the shipped HUD layout. The policy, root layout, dialogs, and context menus are already assigned in Project Settings → Crimson → Crimson UI — a fresh project has a working UI stack before you create your first asset. Blueprint projects never touch a .uproject or a .Build.cs.
Shipped content is a reference implementation, not filler
Every widget type has a complete, working Blueprint in the plugin's Content folder — HUD layouts, a game menu, confirmation dialogs, button bases with styles, tab lists, a bound-action bar, all three context-menu presentations, perf-stat containers, and Crimson_CommonUIInputData with its Click/Back actions preset. Open them to study the wiring, duplicate one as a starting point, or subclass to restyle.
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), a per-map loading-screen bridge, and UI Extension Point widgets that Game Feature Actions can fill at runtime.
Screenshots
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
- July 2026
Frequently asked questions
Do I have to build all the widgets myself?
Do I need C++ to use it?
PublicDependencyModuleNames.Add("CrimsonUI")).Does it depend on other Crimson plugins?
UCrimsonCommonLocalPlayer, UCrimsonCommonGameInstance, the native UI.Layer.* tags, and the 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.Start from a working UI, not a blank canvas
Enable CrimsonUI and CrimsonCommon, set two classes, and push the shipped HUD layout — the policy, root layout, dialogs, and context menus are already configured. Every asset is yours to open, duplicate, or subclass.
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
- No RPCs to Write
Replicated, GAS-native skill trees with a two-graph editor.
- Two-Graph Editor
- Material Splines
- Server-Authoritative
- Atomic Respec & Loadouts
Data-driven settings framework with a ready-made CommonUI screen.
- Data-Driven Options
- Zero-Glue Persistence
- CommonUI Screen
- Presets & Profiles
- Live Preview