Can You Play Slow Roads on Mobile? The Honest Answer
Short answer: no. The build running on this site is the 2022 web release, version 1.0.1, and it has no touch controls of any kind. Open it on a phone and you do not get a cut-down version or an on-screen steering wheel. You get a polite refusal on the splash screen and nothing else.
That refusal is not laziness on anslo's part, and it is not a soft block worth working around. The steering model in this build is built entirely around key presses, and the code has no touch input path at all. Below is exactly what the game does, why it does it, the one override that exists and what it really achieves, and what hardware does work.
What a phone actually shows
The splash screen swaps its begin button for this message, word for word:
Apologies, this project is not yet supported on mobile devices as it requires a hardware keyboard.
Underneath, in smaller text:
If you're not on a mobile device, please disregard this message and click below to force a reload.
Below that sits a bordered, rounded box you can click. In anslo's original 2022 bundle that box is labelled I have a keyboard. That is the entire mobile experience: two sentences and an escape hatch.
Why there is no touch support
Steering is a binary key press smoothed over time
In the driving loop, steering input is not an analogue value. It is reset to zero every frame and then nudged by exactly one unit per held key:
- A or ← adds
+1 - D or → subtracts
1
The raw input is therefore only ever -1, 0 or +1. Everything that makes the cars feel weighty happens afterwards, in a routine the code calls getSoggySteerState. That function eases the wheel angle toward its target over a per-vehicle time constant, steerInterval: 1 on the Roadster, 1.8 on the Bike and 2 on the Coach. At the same time it shrinks the maximum lock as you gather speed — the factor is 1 - 0.75 * speedLerp, so at top speed you have roughly a quarter of the steering range you had at a crawl. Slip reduces it again on top of that.
There is a second per-vehicle term layered over the easing. On a car the delay scales as 1 + 0.5 * speedLerp, which is at worst 1.5× slower than standing still. On the Bike it scales as 1 + speedLerp², up to 2×, and because it is squared almost all of that penalty arrives in the top third of the speed range. The Bike does not get gradually vaguer. It goes numb late and suddenly.
That is the ramp people notice within the first minute of driving. The wheel does not snap, it rolls into the corner. It also means a touchscreen port would need much more than two arrows glued over the canvas. The whole handling model assumes you can hold a direction for a precise length of time and then release it cleanly, which is exactly what fingers on glass are bad at.
There is not a single touch listener in the game code
This is checkable rather than assumed. Searching the game's own bundle for touchstart, touchmove, pointerdown or anything from the Gamepad API returns nothing at all. The only events the game registers are keydown, keyup, mousedown, mousemove, mouseup, wheel, pointerlockchange and visibilitychange, plus window.onblur, onfocus and onbeforeunload. Not one of them fires from a finger. The vendor chunk that ships three.js does contain touch handling, because its camera helpers do, but the driving code never uses it.
There is a mouse driving mode, which surprises people. The input widget in the on-screen interface toggles between keyboard and mouse, and the game's own help panel for it notes (first-person camera recommended). In mouse mode, left click accelerates, right click brakes and reverses, and your horizontal cursor position across a band at least 640 pixels wide sets the steering angle. It sounds like something that might survive a finger. It does not, for three separate reasons. It reads mousemove continuously, and a tap gives the browser nothing to track between press and release. The steering band is half your window width or 640 pixels, whichever is larger, measured from the centre outward, so the control surface is wider than a phone. And mouse mode substitutes its own steering easing — a fixed 0.05 divided by the vehicle's steerInterval — which makes the wheel far more immediate than the keyboard's, then damps your input again by 1 - (speed / topSpeed) * 0.4 as you speed up. It is built around a pointing device that reports position continuously. Boost is also unavailable in mouse mode unless cruise control has a value set. Both schemes are broken down properly in the controls guide.
The override button, precisely
The button does exactly two things. It writes the key force-allow-mobile into localStorage, then reloads the page. On the next boot the game checks whether that key is absent; when it is present, the mobile gate is skipped and the game loads normally.
| What the button writes | force-allow-mobile = true |
|---|---|
| How it is checked | Only for absence, never for a value |
| When the check runs | Once, as the page loads |
| Touch controls added | None |
| To undo it | Delete that key, or clear site data for this domain |
Two details follow from that. Because the test is only for absence, the stored value is irrelevant: setting the key to the string false bypasses the block just as well as true does, which tells you it was written as a quick escape hatch rather than a real setting. And because the check runs once during load and is never re-evaluated, changing the key has no effect until the page reloads. That is why the button reloads for you.
The override genuinely works, and it is genuinely pointless on a phone. It does not add touch controls, because there are none to add. You will get the loading bar, the splash, and then a car you cannot steer, accelerate or reset. Pressing it on a phone buys you a slideshow of scenery and nothing else.
It exists for false positives. The detection is the familiar user-agent regular expression from detectmobile.js, testing navigator.userAgent against a long list of device substrings — android, iphone, ipad, blackberry, windows phone, silk and dozens more — with a second pass over just the first four characters of the string. User-agent sniffing has always been approximate. A desktop browser with an unusual user agent, a privacy extension that rewrites it, or a niche Linux browser can all trip that regex and lock a perfectly capable machine out of a game it would run at 60 fps. That is the case the button was written for, and for that case it is the right fix.
The reverse mistake is more common now than it was in 2022. An iPad running Safari in its default desktop-site mode does not report ipad in its user agent, so it sails past the check and loads the game without ever showing the notice. You then have a fully running copy of Slow Roads on a device with no keys. Unless a keyboard is attached, that is a scenic screensaver.
What does work
Anything with a real keyboard and a browser that can do WebGL:
- Laptops and desktops. The obvious case. Integrated graphics are fine with the settings turned down.
- Chromebooks. These work well, and they are one of the main reasons people go looking for a browser build at all. Chrome OS passes the user-agent check, the keyboard is real, and the game is plain static files with no
SharedArrayBuffer, no WebAssembly and no service worker, so nothing exotic is asked of the browser or the network. More on that in the unblocked guide. - Tablets in a keyboard case. The honest edge case. An iPad or Android tablet docked in a keyboard folio has hardware keys, and once past the gate the game reads physical key codes, so it plays. Expect to need the escape hatch on Android tablets, which usually do report as mobile. Performance on tablet-class GPUs is the bigger obstacle: drop render scale to
0.5and view distance tolowbefore concluding it does not work. - Small windows. Screen size is not the issue. No minimum window dimension is enforced anywhere in the code, though mouse mode assumes a steering band 640 pixels wide, so keyboard control suits a narrow window better.
If the game loads but runs badly on any of those, the three settings that matter most are render scale, view distance and environment detail, in that order. The performance guide covers what each one changes and which to sacrifice first.
What the override actually leaves you with
It is worth spelling out what a phone can still do after you press the button, because it is not nothing and it is not useful either. The game boots. Terrain generates. Weather and season can be changed, because those are widgets you tap rather than keys. The camera cannot be cycled, because that is C. Autodrive cannot be switched on, because that is F — which is the cruel part, since autodrive is the one mode that would genuinely work without a keyboard.
Mouse mode is the closest thing to an escape, and it fails on the detail above: a touch event never produces the continuous mousemove stream it steers from. Cruise control is a widget, so you can set a target speed by tapping, but with no accelerator input the car still will not move. You end up with a correctly rendered, correctly lit, completely stationary world.
If what you wanted was the scenery rather than the driving, that is a real use case and it is better served elsewhere. On a laptop, set autodrive with F, hide the interface with U, set the cycle timer to 15m and leave it. The scenes and seasons guide covers that setup, and the vehicle guide explains why the Coach is the right choice for it.
Controllers and racing wheels
Not in this build either. Neither bundle references navigator.getGamepads or the gamepadconnected event, which is the only route a browser game has to a controller. A pad, a wheel or a set of pedals will do nothing here, with one exception: if the device is configured at the operating-system level to emulate key presses, the game cannot tell the difference, because it reads physical key codes rather than typed characters. That same design decision is why the 1.0.1 changelog can claim AZERTY keyboards now supported with no remapping work at all — WASD sits at ZQSD on an AZERTY layout, the physical positions are identical, and it simply works.
The FAQ anslo shipped inside this bundle dates the situation exactly. Asked whether mobile, controllers and wheels would be supported, the answer reads:
Yes, hopefully - achieving good performance on mobiles might be difficult, but support for controllers and wheels is planned for the near future.
That was written in 2022. It was a statement of intent about the game's future, not a description of this build.
If you need mobile, go to the official game
We would rather say this plainly than let anyone waste an afternoon. The copy here is a preserved snapshot of the November 2022 web release. The official Slow Roads at slowroads.io has moved on a long way since, and anslo has kept developing it. If mobile play or controller support is what you need, that is where to look — not here, and not at any other mirror running an old bundle. Nothing on this site can add a feature that was never in the 2022 code.
What this build is good for is a fixed, unchanging version of the game that loads from plain static files, runs on modest hardware and behaves identically every time. If that is what you want, it is running here, and the rest of the guides cover seeds, seasons, vehicles and performance at the same level of detail. The about page explains what this snapshot is, where it came from, and what it is not.
The short version
- Phones: no. There are no touch controls in this build and no way to add them.
- The unsupported message is accurate rather than cautious. The game needs a hardware keyboard.
- The override writes
force-allow-mobileto localStorage and reloads. It works, and it changes nothing about input. - It exists for desktops wrongly flagged as mobile by a user-agent regex, which does happen.
- Laptops, desktops, Chromebooks and keyboard-equipped tablets are all fine.
- Controllers and wheels are unsupported, unless they emulate key presses at the OS level.
- For mobile or controller support, use the current official game at slowroads.io.
- If you specifically need a calm driving game that works on a phone today, the games like Slow Roads list names one that does.