ENRUCV
← All work

Dungeon Dominator

Dungeon Management UI

Sole UX/UI designer · building, room management and a living Heart that explains its own rules.

View on Steam ↗
Genre
Comedic evil strategy · dungeon building & growth (cutaway view)
Platform
PC
Engine
Unreal Engine
Status
Open playtest
My role
Sole UX/UI designer — IA, flows, wireframes, UI kit, final UI art, specs & handoff to engineering
Scope
13 room types · [N] screens · [N] UI kit components · 3–4 months

01

Challenge

The player runs a whole dungeon at once: resources, time, spells, squads, rooms and quests.

  • Give a sense of control without overloading the screen.
  • Make a hidden rule readable: rooms only work when connected to the Dungeon Heart.
  • Keep the comedic tone without hurting readability.

02

Overview

  1. 1

    Resources

    [Why it sits here]

  2. 2

    Time controls

    [Why it sits here]

  3. 3

    Spells

    [Why it sits here]

  4. 4

    Inventory

    [Why it sits here]

  5. 5

    Squads

    [Why it sits here]

  6. 6

    Notifications & quests

    [Why it sits here]

  7. 7

    Build & Units buttons

    [Why it sits here]

HUD zones. Pins go on top once the real screenshot is in.
  1. 1Dungeon Heart
  2. 2Rooms
  3. 3Units
  4. 4Economy
System map. The Heart powers rooms, rooms unlock unit types, units drive the economy. Reconstructed greybox.

03 · Deep dive

Building & the Heart connection

Game design

A room only works when it's connected to the Dungeon Heart.

Feature by the game designer.

My task

Make this hidden rule readable at a glance, without tutorial text.

  1. 1Build button
  2. 2Room menu
  3. 3Build mode
  4. 4Dig cells
  5. 5Place room
  6. 6Connect corridors
  7. 7Room comes alive
Build flow. The last two steps are where the hidden rule lives.

My solution

Entry points with three states, plus arteries that show the whole powered network.

  • Filled green

    Available. You can connect here.

  • Filled crimson

    Already connected, closed.

  • Hollow

    Not connected yet. The hole asks to be filled.

  • Arteries

    The Heart is alive and feeds the dungeon through every connected corridor and room.

Abstract legend, redrawn on a neutral background.

Why it works

  • Points show the local state — where I can connect. Arteries show the global state — what is powered.
  • The rule is explained by the world's fiction, not by a tooltip.
  • "Not connected" differs by shape, not only by colour. [Keep only after the colour-blindness check]

Greybox

In game

  • Available

  • Not enough resources

  • Requires Heart level [N]

Build menu states.

04 · Deep dive

Room card

Problem

Every room carries a lot of data — level, HP, purpose, production, units, upgrades. Showing it all at once would overload the player.

My solution

One card template for all 13 rooms.

  1. A · Header Level, HP, description, on/off, sell, close. Status the player needs whatever they came for.
  2. B · Tabs (1–3) Ordered by importance. The main process opens by default.
  3. C · Upgrade Shows the unmet requirement instead of a silent grey button.
Card structure. Reconstructed greybox — the original wireframes are under NDA.

Why it works

  • The default tab is the main reason the player clicks a room → zero extra clicks to the key action.
  • Status lives in the header, visible from any tab.
  • One template for 13 room types: players learn it once, engineering builds one reusable component.
  • The upgrade button explains why it's locked, so the player always knows the next step.
Final card in game.

  • 1 tab

  • 2 tabs

  • 3 tabs

Same template, different rooms: the number of tabs changes, nothing else.

  • Locked — shows the unmet requirement

  • Available

Upgrade button: the requirement is on the button itself.

05

UI kit & style

[How the humour lives in the UI: shapes, fonts, icons, copy — 1–2 lines]

  • [Component 1]

  • [Component 2]

  • [Component 3]

  • [Component 4]

Core components and their states.

06

Handoff

[What I handed to engineering: asset slicing, state specs, animation references — and how I checked builds]

07

Results & reflection

Tested

[Mini-test on the open playtest: N players · build and connect a room · upgrade a room · find a damaged room · time and errors]

Player feedback

[What playtest reviews / Discord say about the UI, with counts and source]

What I'd change now

  • Add a sell confirmation: the Sell button sits next to Close, so a misclick destroys a room.
  • [After the colour check: if green and crimson are hard to tell apart, separate them by shape]