Storm the Train

CTO & Lead Programmer·2012·3 min read

A free-to-play iOS and Android action game that passed 50 million downloads, running on a proprietary OpenGL/C++11/Lua engine built for low-end hardware.

Overview

Storm the Train was Games Faction's largest commercial success — over 50 million downloads across iOS and Android. It ran on a proprietary 2D/3D engine written in C++11 and Lua against OpenGL ES, built specifically so one codebase could ship to both platforms and still perform on the cheap Android hardware that most of the audience actually owned.

Problem

Reaching download numbers at that scale means running well on the devices most of the world has, not the devices developers own. That is a hard performance floor, and it sits alongside two other problems: shipping the same game to two platforms without maintaining two codebases, and tuning a free-to-play economy where progression and monetisation have to stay in balance as the player base grows.

Constraints

  • Low-end Android hardware as the real performance target, not flagship devices
  • iOS and Android feature parity from one codebase
  • Free-to-play: progression and economy tuned post-launch, not fixed at ship
  • Small team relative to the audience being served

Approach

Own the engine so the performance floor is a decision rather than a discovery. C++11 for the runtime with Lua for gameplay and economy, giving a single cross-platform core and a scripting layer where tuning could happen without a store submission cycle.

Key Decisions

Proprietary OpenGL ES/C++11 engine rather than a commercial mobile engine

Reasoning:

Mobile engines of the era carried runtime overhead that mattered on the low-end devices making up most of the install base. Owning the renderer and the memory behaviour made the difference between running acceptably on cheap hardware and not shipping to that market at all.

Alternatives considered:
  • Unity
  • Cocos2d-x
  • Native per-platform implementations

Lua for gameplay and economy values

Reasoning:

Free-to-play balance is a live, continuous process. Keeping progression and economy in script meant tuning could ship without a full native rebuild and store review for every adjustment.

Alternatives considered:
  • Native C++ with server-delivered config
  • Fully server-authoritative economy

Target the low end first, then scale up

Reasoning:

Setting the performance budget from the weakest supported device rather than optimising down from a flagship build meant the game was playable across the whole market by construction. Reversing that order tends to produce a game that has to have features removed late.

Alternatives considered:
  • Build for current-generation devices with a reduced-quality fallback
  • Restrict the supported device list

Tech Stack

  • C++11
  • OpenGL ES
  • Lua
  • Objective-C
  • Java

Result & Impact

  • 50M+
    Downloads
  • iOS & Android
    Platforms

Passed 50 million downloads across both platforms on a single shared codebase. The engine and its Lua tuning layer supported continuous economy and content adjustment after launch, which is where a free-to-play title is actually won or lost.

Learnings

  • On mobile the performance target is the market's hardware, not your hardware — and setting that budget first shapes every decision after it
  • A scripting layer over a native core is what makes post-launch tuning viable when every native change costs a store review
  • Cross-platform from one codebase is an architecture commitment made at the start, not a port undertaken at the end
All projects