Gameplay Systems

CommonUI WWE Menu System

WWE 2K-style layered front-end navigation prototype built in Unreal Engine 5.3 with CommonUI and UMG - activatable widget stacks, input ownership per layer, focus restoration, and keyboard/gamepad input foundations.

unreal

commonui

ui

blueprints

navigation

TL;DR

Reproduced the layered menu navigation feel of WWE 2K games in Unreal Engine 5.3 using CommonUI. The project is Blueprint-first and focuses on the behavioral fidelity that makes menus feel production-ready: only the topmost layer consumes input, transitions stay stable under fast actions, and parent menus recover their exact focus state when submenus close.

Role & Scope

• Role: Solo developer
• Duration: 1 week
• Engine/Stack: Unreal Engine 5.3, CommonUI, UMG, Enhanced Input, Blueprint
• Primary goal: Reproduce WWE 2K-style menu behavior - layered overlays, modal input ownership, animated transitions, reliable back navigation

Why This Project Matters

Most UI demos focus on appearance. This project focused on behavior fidelity:

1. Layer ownership - which widget is currently authoritative for input
2. Input isolation - preventing lower layers from receiving accidental actions
3. Focus continuity - restoring the exact selection context after pop
4. Transition safety - guarding against re-entrant push/pop during animation

These are the details that make menus feel production-ready across controller, keyboard, and mixed input devices.

Problem

WWE 2K menus follow a distinct interaction grammar:

• A base layer remains visually persistent
• New screens slide in above the current layer
• Back/cancel closes only the active top layer
• Input is modal - lower layers are inert while covered

Replicating this in Unreal requires deliberate configuration across CommonUI activatable widgets, action routing, and focus rules. The out-of-box behavior is functional but not sufficient for this interaction style without additional architecture.

Project Setup

• Engine: Unreal Engine 5.3
• Plugins: CommonUI, WinDualShock (controller support on Windows)
• Input: Enhanced Input classes configured as project defaults for player input and input components
• Default map: A dedicated Main_Menu level set as both editor startup map and game default map - the menu system is always the entry point
• Input data: Per-platform controller data assets registered for keyboard and gamepad, giving a clean base for future dynamic glyph swapping

Architecture

Implementation

Root layout

The persistent root widget hosts a UCommonActivatableWidgetContainerBase stack. It serves as the visual shell for menu backgrounds and shared framing elements and is registered through the CommonUI.GameViewportClientClass config entry so CommonUI lifecycle and input integration are active from startup.

Shared activatable base

All menu screens derive from a shared UCommonActivatableWidget subclass to centralize behavior:

• NativeGetDesiredFocusTarget() overridden to return a deterministic first-focus element
• NativeOnActivated() / NativeOnDeactivated() used for enter/exit transition hooks, focus caching, and restoration

This avoids duplicating fragile focus code across individual pages.

Stack navigation model

Push flow:

1. Parent screen requests NavStack->AddWidget<ChildType>()
2. Child is activated and transition-in begins
3. Action router rebinds effective input target to child
4. Parent remains rendered but non-authoritative for input

Pop flow:

1. Child receives back/cancel action
2. Child deactivates (transition-out + guard window)
3. Stack reveals parent as topmost widget
4. Parent restores previous focus target and resumes input ownership

Input routing

The routing objective is deterministic modal control:

• ECommonInputMode::Menu used for activatable layers requiring full menu capture
• Action router configured to prioritize top-of-stack widget
• Back actions consumed by the active layer first; unhandled actions may bubble by policy

This prevents input bleed where d-pad or face button actions reach lower layers unexpectedly.

Focus management

• Each widget stores the most-recently focused child before losing activation
• On reactivation, widget restores that child if still valid
• If invalid, falls back to the deterministic default from NativeGetDesiredFocusTarget()

Users return to the exact row/button they came from, preserving navigation context across push/pop cycles.

Code Snippet

// The activation/focus pattern used in this project.
// Actual implementation is Blueprint-driven; this represents
// the equivalent C++ override behavior.

void UWWEBaseMenuWidget::NativeOnActivated()
{
  Super::NativeOnActivated();

  if (EnterAnimation)
  {
      PlayAnimation(EnterAnimation);
  }

  SetIsFocusable(true);
  SetKeyboardFocus();
}

UWidget* UWWEBaseMenuWidget::NativeGetDesiredFocusTarget() const
{
  // Always return the first actionable element in the screen
  // for deterministic controller navigation on entry.
  return PrimaryButtonList && PrimaryButtonList->GetChildrenCount() > 0
      ? PrimaryButtonList->GetChildAt(0)
      : nullptr;
}

Video Demo

Challenges & Solutions

Challenge 1: Input bleeding through widget layers

Cause: Lower stack widgets still reacted to navigation actions under certain configurations.

Solution: Set ECommonInputMode::Menu on all activatable screens and configured the project's action router so only the topmost active widget receives directional and confirm/cancel input.

Challenge 2: Focus not restored after submenu close

Cause: Default reactivation did not always recover the prior child selection, leaving controller users with no focused element.

Solution: Cache the focused child widget before deactivation. On reactivation, explicitly restore that child. If it is no longer valid, fall back to the deterministic default from NativeGetDesiredFocusTarget().

Challenge 3: Back spam during transitions

Cause: Overlapping pop requests during exit animations caused double-pop stack corruption.

Solution: A transition guard flag blocks stack mutations while a transition is unresolved. Back and select inputs are ignored until the completion callback clears the flag.

Performance & Production Considerations

• Pre-instantiate frequently used widgets at level load; push/pop toggles activation and visibility rather than constructing new instances
• Keep transition animations lightweight - menu response latency is noticeable
• Use soft object references for heavy visual widgets if the menu tree scales up
• Profile focus events and input latency with Unreal Insights before shipping

What I'd Build Next

1. UCommonTabListWidgetBase for horizontal category switching at the top level
2. Fully dynamic glyph swapping - Xbox / PlayStation / Keyboard prompts driven by detected active input type
3. Data-driven screen registry: rows and screens defined by data assets to eliminate hard-wired screen class references
4. Automated UI flow tests covering back-stack correctness at each depth under rapid input