Liza Bhadana

Posted on Aug 5

Two players, one keyboard: the multiplayer a phone cannot run

#gamedev #webdev #javascript #a11y

Somewhere in your game there is a line that reads Player 1: WASD. Player 2: arrow keys.

It is the cheapest multiplayer anyone has ever shipped — no server, no netcode, no accounts, no matchmaking, no lobby that sits empty at 3am. One running copy of the game, one input device, two people.

It is also the only common game mode that a phone cannot run at all, because there is no keyboard to cut in half.

This article is about what that trade actually costs, measured across a real 200-game catalogue, and about a smaller, more annoying discovery: the part of your control text that explains the second player is the part most likely to never reach a player.

The short version: 13 of 200 games in our catalogue document two people on one device. 9 of those hand out two separate key sets with no touch alternative in our copy of the text. Exactly 1 of the 9 is filed under "2 Player". Nine control lists in the catalogue are cut off mid-sentence between 250 and 259 characters, and what the cut removes is the mobile section or the second player's keys. And when we checked one of the nine against its publisher's own public page, the mobile controls were there all along — our copy had dropped them. That last one is a correction to our own article from this morning.

What we measured, and what these numbers are not

Every number below is a count of documentation: the control text a developer or publisher wrote about their own game, as it sits in SlowDen's game registry, plus what the publisher's own public page says. It is not a count of behaviour.

No game in this article is described as broken, or as working. We cannot tell you that from where we are sitting, and it is worth saying why, because the reason is a trap other people will hit too. These games run inside a cross-origin frame, drawing to a WebGL canvas we cannot see into. Screen captures of that region come back solid black even when the game is running perfectly, and a script asking the host page how many canvases exist gets the answer zero, because the canvas is not in the host document. We learned that the expensive way. So when this article says a game "is documented as" something, that phrasing is doing real work, and it is the strongest claim the evidence supports.

Two other honest limits. The registry holds 200 games in our source, of which 120 are on the live site today — our deploys are a manual step and the source runs ahead. Every game named below is labelled live or staged. And this is one catalogue of partner games, not a survey of the web.

Finding 1: 13 games document two people on one device

Of the 200 entries, 155 carry a documented control list and 45 carry none at all. Reading all 155, sixteen entries describe a second player. They split three ways:

Group	Count	What the control text says
A. Two players, one keyboard	9	Two separate key sets, and no touch or mobile input mentioned anywhere in our copy of the text
B. Two players, touch documented	4	Two key sets and an on-screen or mobile path spelled out
C. A second player, no keys	3	"with a friend", "for one or two players" — and no input list at all

Group A is the interesting one. Here it is in full, with each game credited to its studio. All are Playgama partner titles; none was made by SlowDen.

Game	Studio	Category	On slowden.com
Basket Random	RHM Interactive	Sports	live
Soccer Random	RHM Interactive	Sports	live
Rolling Balls Sea Race	gameVgames	2 Player	live
Stickman Kombat 2D	Ernar (Tempo Play)	Funny	live
Kick Lucky Blocks Online	Cursora Labs	Block & Sandbox	live
Lucky Brainrot Blocks Online	Cursora Labs	Block & Sandbox	staged, not live
Escape School Duel	gameVgames	Block & Sandbox	staged, not live
Catch a Fish Obby	gameVgames	Block & Sandbox	staged, not live
GT Cars Mega Ramps	gameVgames	Racing	staged, not live

Five are live; the other four are in our source and not on the site yet, so they are named rather than linked to a page that would return a 404.

There is close to a standard here. Five of the nine document WASD for one player and the arrow keys for the other — a convention old enough to predate the browser as a games platform, and one that survives because it is the only way to give two people non-overlapping keys on a keyboard neither of them chose. Two more take the opposite route and reduce each player to a single key. That detail matters later.

Finding 2: local co-op is not in the "2 Player" category

If you were a player looking for something to play with the person next to you, you would open the 2 Player category. Here is what is actually in it.

On the live site the category holds 8 games, and 6 of the 8 are chess, checkers, backgammon or sudoku — turn-based board games, where "two player" means taking turns with one mouse or one finger, and where the second player is often the computer or an online opponent. 4 of the 8 carry no documented controls at all. Only Rolling Balls Sea Race is a simultaneous shared-keyboard game.

Meanwhile the nine games that genuinely need two people pressing keys at the same moment are scattered: 4 in block-and-sandbox, 2 in Sports, 1 in Racing, 1 in Funny, and 1 in 2 Player.

This is not anyone's mistake. A category describes what a game is about. Basket Random is about basketball; it is filed under Sports, correctly. The problem is that "how many people can play this, on what device" is a completely different axis from genre, and almost every browser-game portal — ours included — only has the genre one. A player who wants couch co-op has no way to ask for it, and a developer who built couch co-op has no way to say so.

Finding 3: the second player's keys are the first thing to get cut

While reading all 155 control lists, nine of them stopped mid-sentence with an ellipsis. Their lengths: 250, 253, 253, 254, 254, 256, 257, 258 and 259 characters. The longest control list in the catalogue that is not cut runs to 507 characters, so this is not a site-wide limit — it is something that happened to those nine entries on their way in.

What the cut removes is never random, because text has an order. Developers write the desktop keys first, then the second player, then the mobile section. So the truncation lands on exactly the two things this article is about:

What the ellipsis ate	Entries
The second player's key list	3
The mobile / touch section	6

Three concrete examples, quoted from our own registry exactly as they end:

stickman-kombat-2d   … Player 2: IJKL + : (colon) (attack), " (quote)…

gt-cars-mega-ramps   … Player2 Arrow keys = move  N = NOS  L = reset car position  U =…

animal-evolution-simulator
                     … Mouse wheel - zoom in/out of the camera  Smartphone controls: Left…

The third one is the clearest. A player on a phone reaches the words "Smartphone controls:" and then the sentence stops.

So we went and looked at where the text came from. The publisher's own public page for that game carries the whole thing, with no ellipsis anywhere: a Mobile section listing a left joystick to move, a jump button, an attack button, a swipe on the left side of the screen for the camera, and taps for buttons. The information was never missing. It exists, it is public, and our copy of it stops one word into the sentence that a phone player needs. The same is true of GT Cars Mega Ramps, whose publisher page carries a complete control description and a plain statement that its two-player mode is split-screen on one keyboard.

We have not seen the data payload in between, so we are not going to name a mechanism we did not observe. What is measured is this: the full text exists upstream, and the version we show is incomplete. That is our defect to fix, and the fix is on our list rather than in this paragraph pretending to be already done.

Finding 4: a correction to our own article from this morning

Earlier today we published an audit of touch support across this same catalogue, and it put these nine games in a group described as documenting no touch input. Tonight we checked that claim against a source we had not used: each game's own public page on the publisher's site.

One of the nine does document touch, and we were the ones losing it. Basket Random's publisher page lists three controls, not two:

W: Jump and Throw (Player 1)
Up Arrow: Jump and Throw (Player 2)
Virtual Buttons: Jump and Throw (Mobile)

Our registry entry for the same game carries the first two and not the third. Nothing was truncated here — the text is short and ends cleanly. It is simply a shorter rewrite that dropped the mobile line.

We checked the remaining eight the same way, reading the controls section of each publisher page by hand. Eight of the nine document no touch path upstream either, so the finding holds for those, and the one that does not has been corrected here and in the earlier article's record. Notably Soccer Random — the same studio, the same one-key-per-player design as Basket Random — carries no mobile line on its publisher page at all. We are not going to guess why two sibling games differ.

Why print this rather than quietly edit a number. The correction changes 9 to 8 on one row of one table. It is small. But a reader deciding whether to trust the rest of the measurements has no way to check them, and the only evidence we can offer is how we behave when we find one of our own numbers wrong within a day of publishing it. So: found, checked against a second source, corrected in public, cause named.

Finding 5: how much room two players would actually get

Say you decided to port a shared-keyboard game to touch. How much screen is there to work with? We measured the embed box on a live SlowDen game page — /games/basket-random/, one of the nine — at five viewport widths, using same-origin frames.

Viewport	Game box	Share of viewport area	Split side by side	Split top and bottom
360 × 740	301 × 188	21.2%	150 × 188 each	301 × 94 each
390 × 844	331 × 207	20.8%	166 × 207 each	331 × 104 each
412 × 915	353 × 221	20.6%	176 × 221 each	353 × 110 each
430 × 932	371 × 232	21.5%	186 × 232 each	371 × 116 each
768 × 1024	709 × 443	39.9%	354 × 443 each	709 × 222 each

The box holds at roughly a fifth of the screen's area across every phone width and roughly doubles on a tablet, which is what you would expect from a fixed aspect ratio inside a fixed page padding. We measured a different game page on a different run last time and got the same numbers to within a couple of pixels, which is how you know it is the template and not the game.

Now the useful part. WCAG 2.2 Success Criterion 2.5.8, Level AA, asks for pointer targets of at least 24 by 24 CSS pixels. A 166 by 207 half is nearly seven times that in each direction. So the question is never "is there room for a button". It is how many buttons each player needs:

One input per player — Basket Random and Soccer Random both give each player a single key that jumps, blocks and shoots. Each player's half becomes one enormous tap zone. This is a small change, not a rewrite.
Two or three inputs per player — still workable in a 166 by 207 half, if you are willing to design rather than decorate.
Move, jump, sprint, interact, camera, plus a shop and an inventory — which is what four of the nine actually document. Two of those side by side on a phone is not a layout problem you can solve with a smaller button.

The pattern worth noticing: the games that would be easiest to port are the ones already closest to it. A one-button-per-player design is not a limitation to apologise for. It is the thing that makes two people on one phone a real possibility instead of a joke.

And then there is what our own page says

Here is the live page for Basket Random today, quoted exactly. It opens with:

Play Basket Random free online on SlowDen — no download, no sign-up.
Press play and enjoy this Sports browser game instantly.

Then, under "How to play":

2. Click or tap inside the game window to start.
3. Follow the in-game prompts — controls are listed below.

Controls
• Player 1: W   Player 2: UP ARROW

So the page tells a visitor to tap, and then tells them the game needs two people at a keyboard. Across the five live pages in group A, the word "touch" and the words "swipe", "joystick" and "on-screen" appear zero times, on any of them. The word "instantly" appears four times in each page's HTML.

That is our template, on our site, and it is the least flattering paragraph in this article, which is the main reason it is here. The replacement is written and sitting in our source, unshipped, because our deploys are manual and the site is frozen this month. It reads:

⌨ Two players, one keyboard

Built for a keyboard — and for two people at one. Basket Random is
documented as two players sharing a single keyboard, so it is made for
a computer rather than one phone. No touch alternative is listed.
That is what its control list says, not a test result.

We are not claiming credit for a fix a visitor cannot see yet. As of the time this was published, the live page still reads the way it is quoted above.

Six things worth doing

In rough order of how much they return for the effort.

Write the device answer first in your controls text. Not last. Every downstream system that reformats, shortens or truncates your description cuts from the end, and we have nine measured examples where the end was the mobile section or the second player. A first line reading "Two players, one keyboard — desktop only" survives everything.
If your game has one action per player, ship touch. You are one pair of tap zones away. Split the canvas down the middle, treat a tap on either half as that player's key, and leave the keyboard bindings in place for desktop. It is the single cheapest way to turn a desktop-only game into one that works on the device half your visitors are holding.
Say when two-player is desktop-only, on the page, in words. One game in our catalogue does this and it is the best-documented entry we found: "On Mobile Devices: Only 1 Player mode is enabled on mobile devices. Tap left and right on the screen to move." (Snow Rush 3D, by gameVgames — in our source, not yet on the live site.) A player who reads that is never disappointed. Compare it to a page that just says "tap to start".
Make single-player complete on touch, and let co-op be the extra. This is the version of the trade that costs you nothing. The mistake is not building shared-keyboard co-op — it is building it as the only way in.
Document desktop and mobile as two separate lists, not one blended paragraph. The clearest entry in our whole catalogue does exactly that: Master Chess (CodeThisLab) lists click a piece / click a square for desktop and tap a piece / tap a square for mobile, as four separate lines. It takes thirty seconds to write and it answers the only question a phone player has.
Do not rely on a category to communicate your input model. Genre and device are different axes, and portals mostly only have the genre one. Put it in your own text, where it travels with the game.

Where the numbers came from, and what they cannot tell you

All figures measured on 5 August 2026, in Chrome on Windows.
The catalogue audit reads the game registry directly. 200 entries in source, 120 live; 155 with a control list, 45 without.
The regex used to find candidate entries produced one false positive, which is worth naming because it is the kind that looks like a finding: the pattern friend matched the ordinary phrase "user-friendly" and pulled in an entry that mentions no second player at all. Every one of the sixteen was read by hand before it was counted, and the hand count is what is published.
Publisher pages were read directly for the nine group-A games plus two of the truncated entries. Only the controls section of each was used.
Geometry was measured on a live page in same-origin frames at five viewport sizes. These are layout measurements at phone widths, not tests on phone hardware — the machine reports zero touch points, so no claim here is based on a real touch device.
The accessibility figure is from the W3C recommendation, read this run. No other platform guideline is quoted, because the two we tried to verify would not render their own text to a fetch, and an unverified number is worse than a missing one.
What this cannot tell you: whether any specific game plays well, or at all, with two people or one, on any device. Documentation is not behaviour. Nothing here is a review.

If you make browser games

SlowDen lists browser games and takes submissions from developers. If you have a playable web build you can send it to us — and if two people need to share a keyboard for it, say so, because we would rather put that on the page than let someone find out on a bus.

Slow Cook is our creative challenge for developers: pick a challenge, build a small game around it, and submit it before the round closes on 31 August 2026. Selected entries may receive a shoutout on SlowDen's social accounts and a chance to be featured — nothing is guaranteed, and every entry is read by a person.

DEV Community