Cross-Platform UI Adaptation Guide for Roguelikes

If you want a roguelike to feel native on PC, mobile, and controller-based platforms, UI adaptation cannot be a late polish pass. It has to be a core design system that handles input, layout, and interaction shifts from the beginning.

Who This Helps

• Teams shipping the same game to desktop, handheld, and mobile devices
• Developers whose UI feels good on mouse but awkward on touch or controller
• Designers trying to keep one ruleset instead of maintaining platform-specific chaos

The Problem

Cross-platform UI usually breaks in predictable ways:

• Menus designed for mouse hover feel slow on gamepad
• Dense desktop HUD layouts collapse on mobile
• Touch targets are too small because the original design assumed a cursor
• Runtime input switching leaves the player with the wrong prompts or layout

The real problem is not just screen size. It is that interaction models, precision, and player expectations change with the device.

Why It Matters

Players do not judge UI by how elegant the code is. They judge it by whether the game feels natural on the device in their hands.

For a roguelike, bad cross-platform adaptation can directly damage:

• inventory and equipment management
• map readability
• combat clarity
• navigation speed
• accessibility and fatigue

Good adaptation protects both usability and retention.

Core Principles

1. Abstract the action, not the device

Game logic should respond to player intent, not raw device events.

That means:

• "confirm"
• "cancel"
• "move selection"
• "open inventory"
• "use item"

should exist as shared game actions, while keyboard, gamepad, and touch inputs map into them differently.

2. Layout must be responsive, but interaction must also be responsive

Teams often focus on resizing panels, but the harder part is interaction behavior:

• controller navigation needs clear focus states
• touch needs larger targets and simpler gestures
• mouse supports denser precision and faster hovering

The best cross-platform UI systems adapt layout and interaction together.

3. Runtime switching matters

Players increasingly move between mouse, controller, and touch contexts. The game should detect the active input source and swap prompt language, focus logic, and hint presentation without forcing manual settings changes.

4. Safe areas and orientation are product requirements

On mobile and handheld devices, notches, aspect ratio differences, and orientation changes can destroy carefully aligned UI if they are treated as edge cases.

How To Apply It

1. Build an input abstraction layer first

Start with a shared action map such as:

• move up/down/left/right
• primary action
• secondary action
• interact
• pause
• inventory
• map

Then connect each platform input to the same action system.

Phaser

• Centralize keyboard, pointer, and gamepad mapping in one manager
• Detect active source to switch prompts at runtime
• Keep touch-specific UI flows separate from hover-heavy desktop flows

Unity

• Use an action-driven input system rather than binding gameplay directly to UI widgets
• Separate navigation state from rendering state so controller focus can evolve cleanly

Godot

• Route keyboard, joypad, and touch events into shared gameplay actions
• Avoid baking device assumptions directly into individual scenes

Unreal

• Treat input prompts, menu focus behavior, and widget rules as data-driven where possible
• Expect controller-first navigation to need different hierarchy rules than cursor-first layouts

2. Design with platform-specific stress points in mind

Desktop

• supports high information density
• rewards fast hover and precision interaction
• tolerates smaller click targets than touch

Controller

• requires strong focus order
• benefits from fewer competing actions on the same screen
• needs visible selection states at all times

Mobile

• needs larger hit areas
• punishes dense edge-aligned controls
• benefits from shorter action paths and clearer prioritization

3. Use adaptive layout rules instead of one-off exceptions

A stable system usually includes:

• anchor rules
• safe-area handling
• orientation-aware rearrangement
• scalable spacing and typography
• platform-specific prompt components

This keeps the UI maintainable when new devices or screen shapes appear.

Common Mistakes

1. Treating controller support as "keyboard support with a different icon"

Controller navigation has its own pacing, focus, and hierarchy needs. It is not just another button legend.

2. Shrinking the desktop layout onto mobile

This usually creates tiny targets, crowded panels, and unreadable combat information.

3. Updating prompts but not behavior

If the game swaps from keyboard icons to controller icons without changing focus logic, it still feels wrong.

4. Forgetting runtime transitions

If the UI only works when the player commits to one device at startup, the experience feels fragile.

Checklist

• [ ] Input is mapped to shared gameplay actions, not hardcoded device paths
• [ ] Desktop, controller, and touch each have appropriate interaction behavior
• [ ] Focus navigation is explicit and visible for controller users
• [ ] Touch targets are large enough for real use
• [ ] Safe areas and aspect-ratio changes are handled by system rules
• [ ] Runtime input switching updates prompts and interaction state
• [ ] Inventory, map, and combat HUD were tested on at least two device styles

References

• Phaser 3 Scale Manager documentation
• Phaser 3 Gamepad documentation
• Apple Human Interface Guidelines
• Google Material Design responsive layout guidance
• MDN Screen Orientation API
• MDN safe area environment variables