CrimsonUIComing to FabFree
Get early access on Discord

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.

Video coming soon

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.

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?
Not anymore. The plugin ships a working reference implementation — a pre-assigned UI policy and root layout, a fully wired HUD layout with escape menu and controller-disconnect screen, confirmation dialogs, all three context-menu presentations, button bases with CommonUI styles, tab lists, a bound-action bar, perf-stat widgets, and preset CommonUI input data. Use them as-is to get running, then duplicate or subclass to make them yours.
Do I need C++ to use it?
No. Every class is designed to be subclassed in Blueprint — the policy, layouts, widget bases, dialogs, context menus, ViewModels, indicators, and touch widgets are all Blueprint-accessible, and the shipped assets are Blueprints you can open and study. For a Blueprint project, ticking the plugin in Edit → Plugins is the entire install; C++ is there only if you reference the types from your own code (PublicDependencyModuleNames.Add("CrimsonUI")).
Does it depend on other Crimson plugins?
Only CrimsonCommon, per the suite's Cardinal Rule — it supplies the policy/layout base classes, 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?
Yes. CrimsonUI is free — it's part of the suite's foundation layer alongside CrimsonCommon, so every Crimson UI project starts here at no cost.
What does it replace?
It replaces the CommonGame dependency. Instead of pulling in Epic's CommonGame sample, you get a maintained, game-agnostic CommonUI foundation — UI policy/primary layout, activatable widgets, the HUD layout with Escape routing, the dialog and context-menu subsystems — with shipped, pre-configured assets CommonGame never gave you.
Does it work for mobile and touch?
Yes. The Touch widgets — 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.