Quick Start

By the end of this page you have the full UI stack running: a policy that creates one root layout per local player, tag-keyed layers registered on it, and a HUD layout pushed onto the Game layer at startup. Every screen you build later is a two-line push onto this stack.

1. Enable the plugin

Open Edit -> Plugins, type Crimson in the search box, tick CrimsonUI's checkbox (and CrimsonCommon, its dependency), and restart the editor when prompted. For a Blueprint project that is the entire install - you never hand-edit the .uproject or any .Build.cs.

C++ projects: after enabling the plugin, add its module to your build file so your game code can use its types:

// YourGame.Build.cs
PublicDependencyModuleNames.Add("CrimsonUI");
PublicDependencyModuleNames.Add("CrimsonCommon"); // policy/layout base layer

2. Set the Game Instance and Local Player classes

The UI manager boots off two classes from CrimsonCommon. UCrimsonCommonGameInstance broadcasts player-added/removed events the manager subscribes to; UCrimsonCommonLocalPlayer is the local-player type the manager requires (players of any other class are silently ignored). UCrimsonCommonGameInstance is Abstract, so make a subclass first.

BlueprintC++

3. Set the viewport client

UCrimsonGameViewportClient (a UCommonGameViewportClient) drives hardware vs software cursor from the Platform.Trait.Input.HardwareCursor platform trait. CommonUI needs a UCommonGameViewportClient for its input routing, so set it even if you never touch cursors:

BlueprintC++

Open Edit -> Project Settings -> Engine -> General Settings, expand the Default Classes section, and set Game Viewport Client Class = Crimson Game Viewport Client. The editor prompts to restart - accept it, because the viewport client class is only swapped in on startup. No .ini editing needed; the picker writes the same GameViewportClientClassName line for you.

4. Give CommonUI its Click and Back actions

CommonUI's action router needs a Click and a Back input action to drive activatable widgets. Those are configured inside a UCommonUIInputData asset, and the plugin ships one - Crimson_CommonUIInputData - with its Click and Back already set to Crimson_IA_UI_Confirm / Crimson_IA_UI_Back. Assign it to the Input Data field in Project Settings -> Game -> Common Input Settings (or the ini in the C++ tab) and enable Enhanced Input support, so glyphs resolve from live key bindings and update on rebind. (The other shipped actions - Crimson_IA_UI_Escape / Next / Previous - are yours to bind wherever you like.)

BlueprintC++

Open Project Settings -> Game -> Common Input Settings. Set Input Data = `Crimson_CommonUIInputData` - the shipped asset already has its Click and Back actions set to Crimson_IA_UI_Confirm / Crimson_IA_UI_Back - and tick Enable Enhanced Input Support. The picker writes the same DefaultGame.ini lines for you - no file editing needed.

Registering the actions is only half of it - Enhanced Input still needs to know which keys trigger them, or nothing happens when the player presses a button. Create an Input Mapping Context (Content Browser -> right-click -> Input -> Input Mapping Context, e.g. IMC_UI) and map keys to the shipped actions: e.g. Space Bar + Gamepad Face Button Bottom -> Crimson_IA_UI_Confirm, Escape + Face Button Right -> Crimson_IA_UI_Back (and keys for Crimson_IA_UI_Escape / Next / Previous). Then add that context to the local player:

5. Layer tags (shipped - add your own if needed)

Layers are gameplay tags under the UI.Layer parent. The base set - UI.Layer.Game, UI.Layer.GameMenu, UI.Layer.Menu, UI.Layer.Modal, UI.Layer.ContextMenu - is defined natively in CrimsonCommon (the shared layer that owns the layout/push system), so the tags exist whenever any Crimson UI is present and appear in every UI.Layer picker automatically. The shipped root layout registers a stack under each, so there is nothing to set up here. Define an additional layer only if your game needs one (e.g. a dedicated tooltip or notification layer):

; Config/DefaultGameplayTags.ini - only for EXTRA layers beyond the shipped base set
[/Script/GameplayTags.GameplayTagsSettings]
+GameplayTagList=(Tag="UI.Layer.Notification",DevComment="Toasts / transient notifications")

6. UI policy & defaults (pre-configured)

Nothing to set up here - CrimsonUI ships these settings pre-filled at Project Settings -> Crimson -> Crimson UI (UCrimsonUISettings, saved to DefaultCrimsonUI.ini), each pointing at its ready-made asset. So a fresh project already has a working policy, dialogs, and context menus. The default DefaultUIPolicyClass is B_CrimsonUIPolicy, whose LayoutClass is W_CrimsonOverallUILayout - the root UCrimsonPrimaryGameLayout that owns a stack for every standard layer (Game, GameMenu, Menu, Modal, ContextMenu). Open the panel only to point a setting at your own subclass:

7. Push the HUD layout

The plugin ships W_CrimsonHUD_Layout (a UCrimsonHUDLayout) - the always-present root HUD screen, already wired with the escape/pause menu (W_CrimsonGameMenu via Crimson_IA_UI_Escape) and the controller-disconnect screen. Push it onto the Game layer when the local player is ready:

8. (Recommended) Set the HUD actor class

ACrimsonHUD registers itself with UGameFrameworkComponentManager, which lets GameFeature actions attach HUD widgets/components later, and feeds the ability-system debugger a useful actor list. Set it as your GameMode's HUD Class:

BlueprintC++

Open Project Settings -> Maps & Modes. Under Default Modes, set Default GameMode to your GameMode Blueprint, then set Selected GameMode -> HUD Class = Crimson HUD (or a Blueprint subclass of it). This saves onto your GameMode Blueprint - no .ini editing required.

The Selected GameMode rows are editable only while the Default GameMode is a Blueprint. You can set the same value directly on the GameMode Blueprint instead: open it and use Class Defaults -> Classes -> HUD Class.