Ocean View Games

Posted on Aug 24 Originally published at oceanviewgames.co.uk

Porting a 20-Year-Old Game to Mobile: Lessons from RuneScape

#gamedev #unity3d #programming

RuneScape is one of the longest-running MMORPGs in history. First released in 2001, it had already accumulated more than 15 years of content, systems, interfaces, and player expectations when I joined the mobile effort. Bringing a game with that history to iOS and Android is a very different problem from porting a title designed with mobile in mind.

I worked at Jagex from 2017 to 2019 as a Technical Developer on the RuneScape Mobile team. That put me inside the practical work of adapting a long-lived desktop game for touch devices and much more constrained hardware.

This article shares the technical lessons I took from that experience and how they now inform the mobile development and porting work we do.

Important note on attribution: The RuneScape work discussed here was performed during my previous employment at Jagex Games Studio. RuneScape is a trademark of Jagex Ltd. Ocean View Games was not a contractor or agency partner on the project. I reference the experience because the lessons directly inform how we approach mobile and legacy codebases today.

The Scale of the Challenge

To understand why porting RuneScape to mobile was so technically demanding, you need to appreciate what the game actually contains:

Over 20 years of accumulated content built by hundreds of developers across multiple generations of the codebase
A large set of skills and activities, many with their own interfaces and interaction patterns
Years of quests and bespoke content built across multiple generations of the game
A live, persistent world shared between mobile and desktop players
A player-driven economy that had to behave consistently across platforms
An established community with strong expectations about how the game should look and feel

This was not a case of building a simplified "mobile version" of the game. The mandate was full cross-platform parity: a mobile player needed to be able to do everything a desktop player could, in the same world, at the same time.

Key Takeaway: When porting a legacy title to mobile, the first and most important question is scope. "Full parity" and "mobile companion app" are fundamentally different projects with different technical requirements, timelines, and budgets. Define this boundary clearly before writing a single line of code.

Lesson 1: Legacy Code Is the Real Boss Fight

Understanding the Codebase

RuneScape's codebase had been evolving for over 15 years by the time the mobile port began. It contained code written by developers who had long since left the company, using patterns and conventions that predated modern best practices. The game's scripting language, RuneScript, was a proprietary system unique to Jagex.

The practical challenge was not just "make this run on mobile." It was "make this run on mobile without destabilising the desktop experience for an established live-game community."

The Lesson: Audit Before You Architect

Before our team wrote any mobile-specific code, we conducted a thorough audit of the systems we would need to touch. This revealed:

Hard-coded screen dimensions embedded deep in UI rendering logic
Mouse-specific input assumptions baked into core gameplay mechanics (right-click context menus were fundamental to the game's interaction model)
Desktop-specific rendering paths that assumed minimum hardware specifications far above any mobile device
Memory usage patterns that were acceptable on desktop (2GB+ RAM available) but catastrophic on mobile (often limited to 1-2GB total, shared with the OS)

The audit took weeks, but it saved months. Every assumption we identified and documented upfront was a crisis we avoided during production.

Applying This at Ocean View Games

This experience directly informed how we approach every porting project today. When we partnered with Inferna Games to remake Nub (originally a Java app for the Ouya console) in Unity for iOS, Android, and Steam, we started with the same audit-first methodology. Even with a much smaller codebase, the discipline of cataloguing every platform assumption before writing new code prevented the kind of cascading bugs that derail porting timelines.

Lesson 2: Touch UI Is Not "Smaller Desktop UI"

The Fundamental Problem

RuneScape's desktop interface was designed for a mouse and keyboard. The game relied heavily on:

Right-click context menus for virtually every interaction (talk to NPC, pick up item, examine, attack)
Hover states to preview information before clicking
Small, dense UI panels that displayed enormous amounts of information simultaneously (inventory, equipment, prayer, magic, combat stats - all visible at once)
Keyboard shortcuts for quick switching between interface panels

None of these patterns translate directly to touchscreens. A finger is far less precise than a mouse cursor, touch has no hover state, right-click needs an alternative, and a phone cannot comfortably display the same information density as a desktop monitor.

The Solution: Context-Sensitive Adaptive UI

The important design direction was to avoid simply scaling down the desktop interface. A mobile UI needs to adapt the information and interactions to the player's current context. The core principles are:

Show only what matters now. When a player is in combat, surface combat-relevant panels (health, prayer, special attack) and collapse non-essential ones (skills, quest log). When the player is skilling, swap the priority.
Give desktop-only interactions a touch-native equivalent. Right-click and hover behaviours need deliberate replacements such as long-press, tap-and-hold, contextual actions, or dedicated controls.
Expand tap targets aggressively. Visual elements that are easy to click with a cursor often need larger or more forgiving hit areas on touch devices.
Redesign, do not just resize. Any interaction built around precision mouse input should be reviewed as a mobile design problem. Preserve the intent of the mechanic, but be willing to change how the player expresses it.

The Lesson: Invest in a Dedicated Mobile UI Pass

A common mistake in porting projects is treating mobile UI as a configuration change - swap out some assets, scale some panels, ship it. This produces games that technically run on mobile but feel terrible to play.

My recommendation, based on that RuneScape experience: budget for a full UI redesign as a first-class work item. This does not mean changing the visual style. It means rethinking how every interaction maps to touch input and how information is prioritised for a smaller viewport.

Key Takeaway: The gap between "works on mobile" and "feels native on mobile" is almost entirely a UI/UX problem. Invest in dedicated mobile interaction design. Your players will notice the difference immediately.

Lesson 3: Cross-Platform Parity Requires Server-Side Discipline

The Synchronisation Problem

RuneScape Mobile was not a separate game. Mobile and desktop players existed in the same world on the same servers. This meant:

A mobile player and a desktop player could trade items face-to-face
A mobile player could participate in the same boss fight as desktop players
The game's economy, driven by the Grand Exchange marketplace, operated identically regardless of platform
Any content update had to work on both platforms simultaneously

Network Packet Optimisation

Desktop RuneScape could assume a stable broadband connection. Mobile could not. The mobile effort had to account for cellular connections as well as desktop broadband. That reinforced an important porting lesson: bandwidth, latency, reconnect behaviour, and failure recovery all need to be treated as mobile design constraints rather than tested at the end.

For a mobile port, that means reviewing the network path with mobile conditions in mind: payload size, reconnect behaviour, timeout assumptions, latency tolerance, and which state is truly critical. The exact implementation depends on the game's architecture, but those questions should be answered deliberately rather than inherited from the desktop client.

The Lesson: Define "Parity" Precisely

"Cross-platform parity" can mean different things:

Data parity: The same account, progression, and items across platforms (essential)
Feature parity: The same gameplay features available on all platforms (desirable but expensive)
Experience parity: The game feels equally good to play on all platforms (the highest bar, and the most important for player retention)

We now apply this three-tier framework to every porting project we scope. For our ongoing work on Domi Online, we designed the network architecture with cross-platform play in mind from the start, using FishNet to build lightweight server-authoritative backends that optimise bandwidth for mobile clients without compromising the desktop experience.

Lesson 4: Optimise for the Worst Device, Not the Best

The Android Fragmentation Reality

When targeting Android, you are not targeting one device. You are targeting thousands. During the RuneScape Mobile development, we had to ensure the game ran acceptably on:

Flagship devices (Samsung Galaxy S series, Google Pixel) with powerful GPUs and 6-8GB of RAM
Mid-range devices that represented the bulk of the player base
Budget devices with as little as 2GB of RAM and GPUs that struggled with basic shader operations

Tiered Quality Settings

A practical response is a tiered quality strategy so that the game can trade visual cost for stability on weaker devices. Typical controls include:

Draw distance and object density
Texture resolution and compression format
Shadow quality (or complete shadow disabling on the lowest tier)
Particle effect density
Frame-rate targets or caps appropriate to the device and thermal budget

Whatever the detection strategy, the default should be conservative enough that supported devices start in a playable state rather than making the player diagnose performance themselves.

Battery and Thermal Management

Mobile games face constraints that desktop games never consider:

Thermal throttling: When a phone overheats, the OS forcibly reduces CPU/GPU clock speeds, causing frame rate drops and stuttering
Battery drain: Heavy CPU/GPU use can make a technically smooth game unpleasant to play for long sessions
Background interruptions: Phone calls, notifications, and OS memory pressure can suspend or kill the game process at any time

The practical lesson is to test sustained sessions, not just a five-minute benchmark. A build that starts at 60fps can perform very differently after the device heats up. Profile frame time, loading spikes, memory pressure, and thermal behaviour on real hardware.

Lesson 5: Your Existing Players Are Your Toughest Critics

Managing Community Expectations

RuneScape's player community had been playing the game for years, sometimes decades. They had strong opinions about every UI element, every interaction pattern, and every visual detail. Any change made for mobile that visibly affected the desktop experience generated immediate and vocal feedback.

The Lesson: Isolate Mobile Changes

Wherever possible, mobile-specific behaviour should sit behind platform abstraction layers rather than leaking platform checks throughout shared gameplay code. For example:

Input handling was routed through an abstraction that returned platform-appropriate interactions
UI layouts used a responsive system that adapted to screen size without changing the underlying data model
Performance optimisations that benefited both platforms (reduced draw calls, better batching) were implemented in shared code; mobile-only compromises (reduced texture quality) were isolated behind platform checks

That extra structure costs some time up front, but it reduces the risk that a mobile-specific compromise accidentally degrades the desktop experience.

How These Lessons Inform Our Work Today

Every project we take on at Ocean View Games is shaped by this experience. Whether we are building a new title from scratch or porting an existing game to mobile, we apply the same principles:

Audit first. Catalogue every platform assumption in the existing codebase before writing new code.
Design for touch natively. Never treat mobile UI as a scaled-down version of the desktop interface.
Define parity levels explicitly. Agree with the client on exactly what "cross-platform" means before scoping the work.
Optimise for the floor, not the ceiling. Target the weakest supported device first. If it runs well there, it will run well everywhere.
Isolate platform-specific code. Use abstraction layers to prevent mobile changes from breaking the existing experience.

If you are considering a mobile port of an existing title, our mobile game porting case study provides a detailed technical breakdown of this approach. For new projects where you want to target mobile from Day 1, our mobile game development services page outlines how we architect for cross-platform from the start.

DEV Community