Mobile UI Design for Complex Games: Lessons from RuneScape Mobile

# gamedev# unity3d# programming

Ocean View Games

Porting a game to mobile is never just a resolution swap. When the source material is a 20-year-old...

Porting a game to mobile is never just a resolution swap. When the source material is a 20-year-old MMORPG with dozens of overlapping menus, right-click context actions, and a keyboard-heavy control scheme, the challenge becomes an entirely different beast.

During our founder's tenure at Jagex, we were part of the team that brought RuneScape to iOS and Android, a project that touched over 10 million players. That experience now underpins every mobile development project we take on at Ocean View Games.

This post distils the hard-won lessons from that process into practical principles any studio can apply when adapting complex desktop interfaces for touchscreens.

The Core Problem: Information Density vs. Screen Real Estate

Desktop MMORPGs are information-rich by design. A typical RuneScape session might have the game world, an inventory panel, a chat window, a minimap, action bars, and skill trackers all visible simultaneously. On a 24-inch monitor, that works. On a 6-inch phone, it is unplayable.

The instinct is to shrink everything. That instinct is wrong. Tiny buttons lead to mis-taps, frustration, and uninstalls. The real solution is not miniaturisation but prioritisation.

Key Takeaway: The goal of mobile UI adaptation is not to fit everything on screen at once. It is to show exactly what the player needs, exactly when they need it.

Principle 1: Context-Sensitive Interfaces

The single biggest architectural shift we made was moving from a static panel layout to a context-sensitive interface that dynamically adapts to what the player is doing.

When a player is mining, they need to see:

The rock they are interacting with
Their inventory (to track ore)
A progress indicator

They do not need to see their friends list, their quest log, or a chat window full of trade spam.

How It Works in Practice

We built a state machine that tracks the player's current activity and adjusts visible UI panels accordingly:

Combat mode - health bars, prayer points, and action bar take priority. Inventory minimises to a quick-access strip.
Skilling mode - the relevant skill interface expands. Non-essential panels collapse.
Social mode - chat and friends list expand. Game HUD elements shrink to the periphery.

The transitions between modes needed to feel instant and invisible. Any animation longer than 150ms felt sluggish during combat. We settled on 100ms slide transitions with a subtle fade, fast enough to feel responsive but smooth enough to avoid visual jarring.

Principle 2: Tap Targets Are Sacred

Apple's Human Interface Guidelines recommend a minimum tap target of 44x44 points. Google's Material Design suggests 48x48dp. In a complex game with dozens of interactive elements, meeting these minimums is a constant battle.

We established a strict rule: no interactive element smaller than 44x44 points, regardless of how it looks visually. The visual footprint of a button can be smaller than its hit area. We used invisible padding to extend tap zones beyond their visual boundaries.

The Right-Click Problem

RuneScape's desktop interface relies heavily on right-click context menus; a mechanic with no direct mobile equivalent. We evaluated three approaches:

Long-press - Mimics right-click but adds latency to every interaction
Dedicated context button - Adds UI clutter
Swipe gestures - Discoverable but conflict with scrolling

We ultimately used a hybrid: long-press for context actions, with a visual "hold" indicator that fills radially around the finger position. This gave players clear feedback that a long-press was registering, reducing accidental cancellations.

Principle 3: Decouple UI from Game Logic

One of the most valuable architectural decisions was fully decoupling the UI layer from the underlying game systems. The game logic did not care whether the player pressed a keyboard shortcut or tapped a button. It
received the same event.

This separation had two critical benefits:

Cross-platform parity - Mobile and desktop players could exist in the same world without either platform receiving an advantage. Network packets and client-side prediction remained identical.
Iterative design - We could redesign the mobile UI without touching game logic. When early playtests revealed that the combat interface needed restructuring, the change was confined to the UI layer.

Key Takeaway: If your UI code is entangled with game logic, you will pay for it during every porting project. Invest in clean separation early.

Principle 4: Design for Fat Fingers, Not Pixel Perfection

Desktop interfaces can rely on pixel-perfect cursor positioning. Mobile cannot. We adopted several techniques to accommodate imprecise touch input:

Generous hit zones - As mentioned, always larger than the visual element
Snap-to targets - When dragging items in the inventory, the item snaps to the nearest valid slot within a tolerance radius
Forgiveness windows - Tapping slightly outside an interactive element still registers if no other element is within range
Confirmation for destructive actions - Dropping valuable items requires a deliberate double-tap, preventing accidental loss

These techniques sound minor individually but collectively they transform the experience from "playable but annoying" to "feels native."

Principle 5: Respect the Viewport

Mobile players are often in portrait orientation on a phone, but in landscape on a tablet. A fixed layout breaks one or the other.

We built the UI on a responsive anchor system. Critical HUD elements anchor to screen edges and corners rather than absolute positions. The minimap anchors to the top-right. The action bar anchors to the bottom-centre. As the viewport changes, elements reflow without overlapping.

For panels that needed scrolling (inventory, skill lists, quest logs), we used native scroll physics with momentum and rubber-banding. Custom scroll implementations that ignore platform conventions feel immediately wrong to players, even if they cannot articulate why.

Applying These Lessons to Your Project

You do not need to be porting an MMORPG for these principles to apply. Any game with moderate UI complexity (such as strategy games, RPGs, management sims, or educational apps) benefits from:

Designing for context, not static layouts
Respecting minimum tap target sizes
Separating UI from game logic
Building for imprecise input
Using responsive anchoring instead of fixed positions

At Ocean View Games, we apply these principles across every mobile project and porting engagement we take on. Whether we are optimising performance for mid-range devices or adapting desktop controls for touch, the foundation is always the same: put the player's needs first.