A mouse game is not awkward on a phone. It's dead.

Most people who open a browser game do it on a phone. We knew that, and Salt & Stone — a town-builder on a bare rock island, trading across an inland sea — was still built for a mouse. The camera, placing a building and selecting one all hung off mouse events.

On a phone the result wasn't "a bit fiddly". Nothing moved. You couldn't pan the map, couldn't place anything, couldn't select anything. A management game gives no hint of how it is controlled, so a player who can't move the map simply closes it.

The one line without which nothing else works

The game now uses pointer events, a single path for mouse, pen and finger. That alone changes nothing on a phone, because of the browser.

By default the browser keeps a one-finger drag for itself as page scrolling, and a two-finger drag as page zoom. The game's canvas gets a message that the gesture was cancelled and nothing else. The fix is one line of CSS on the canvas, telling the browser that touches there belong to the page: touch-action: none. It has to be in the stylesheet, not set from script after the fact.

Three things a finger doesn't have

Every one of these needs its own answer. Mapping them one-to-one onto mouse actions doesn't work.

No hover. With a mouse, a building "ghost" follows the pointer before you click, showing whether the spot is valid. A finger isn't anywhere until it touches. So with a building selected, you drag the ghost and lift to place: you see the building, and whether it fits, before committing. It is the closest thing to hover that exists on glass.

A finger can't pan and aim at the same time. A mouse moves the pointer and the map separately. With a building in hand, one finger aims and two fingers pan and pinch. With nothing in hand, one finger moves the map, which is what people try first.

No wheel and no right button. Those were rotate-the-building and put-it-down. On touch they are two 56-pixel buttons that appear only while you're holding something, so they don't clutter the screen the rest of the time.

Ask what the device is, not how wide it is

The buttons also had to grow. The usual way to do that is a media query on screen width, and here it gets both cases backwards: a tablet is 1024 pixels wide and needs finger-sized controls, while a narrow browser window on a desktop doesn't.

So the size switch asks whether the main pointer is coarse — a finger — rather than how wide the window is. On a touch device the dock buttons go from 28 to 46 pixels and the building cards from 56 to 84.

One more phone-specific rule: held sideways, a phone is short. If the screen is under 520 pixels tall, the building tray doesn't open on its own, because open it covers more than half the screen — including the part of the town you're trying to choose a spot in.

The same lesson in an action game

Husktide had a different problem. It drew itself into a fixed 16:9 box and scaled that box to fit the screen. On a phone held upright that left a strip across the middle of the screen, with black above and below: the game used 26% of the display.

The fix was to choose the shape of the game's box from the shape of the screen before the game starts, keeping the same total number of pixels, so every layout measurement still holds. On an upright phone it now uses 99.9%.

That exposed a second problem. Everything is drawn in the game's own units and then scaled down to fit, so a button 52 units tall can arrive on a sideways phone as 27 real pixels — too small to hit reliably. Every tap target is now sized from a single number worked out from the actual scale, so it always comes out at least 44 pixels on the glass.

The general point

"Works on mobile" is not a feature you add at the end. A control scheme built around a hovering pointer, a wheel and a second button has to be redesigned for a finger, not remapped. And the first test is the dullest one: open it on a phone and try to do the first thing a player would do.

Play Salt & Stone on whatever you're holding.