DEV Community: NitroPlayer

Redesigning Solitaire for one thumb (and A/B testing where the deck goes)

NitroPlayer — Sun, 01 Nov 2026 19:38:39 +0000

Most of the people who play Solitaire on our site do it on a phone, held in one hand, often on the sofa in the evening. Many of them are over 60. Until this week our Klondike layout on phones was simply the desktop layout squeezed into a tall screen: the deck in the top corner, the buttons in a toolbar at the top, and the cards small.

On a 6.5" phone held in one hand, the top of the screen is the hardest place to reach. And the deck is the thing you tap most in Klondike. So we rebuilt the portrait layout around the thumb.

What changed

A bottom bar instead of a top toolbar. Settings, New game, Hint and Undo now sit in a bar at the bottom, as big icon buttons with a label under each one. Undo is on the right, where a right thumb rests. Time, moves and score stay in a slim strip at the top, because you read them but never tap them.

The deck can live at the bottom. In the settings sheet you can choose Deck position: Top / Bottom. At the bottom, the deck and the waste pile sit just above the bar, so drawing a card is a short thumb move instead of a stretch. A small badge shows how many cards are left in the deck.

Left or right hand. A Hand setting mirrors the deck and Undo to the other side. It's a small thing, but without it a left-handed player has to reach across the whole screen for every card.

Draw 1 or Draw 3, from the next deal. The choice used to be buried in a menu. It's now the first row of the settings sheet, and it applies from the next deal so a game in progress never changes under you.

Columns use the whole height. In portrait there's a lot of empty felt under the columns. Long columns now fan down into that space before the cards start to overlap more, and face-down cards squeeze first so the face-up ones stay readable.

Dragging feels lighter. While you drag, the card lifts slightly around your finger, every legal drop shows a soft glow, and the one under your finger glows stronger. Tapping a card still sends it to the best place, so dragging is optional.

Landscape and desktop keep the original layout. The whole portrait mode is one class on the body, so the CSS stays scoped and nothing else moves:

portraitLayout() {
  let on = false;
  try { on = matchMedia('(orientation: portrait) and (max-width: 700px)').matches; } catch (e) {}
  document.body.classList.toggle('np-sol-portrait', on);
  this._portrait = on;
}

Top or bottom? We don't know yet, so we're testing it

My guess was that the bottom deck is better. But players who have used Solitaire for 30 years expect the deck in the top corner, and "easier to reach" doesn't always mean "feels right".

So players who never touched the setting get one of the two positions at random, once, and keep it. An explicit choice in the settings always wins over the test:

let ab = null;
try { ab = localStorage.getItem('np-sol-ab'); } catch (e) {}
if (ab !== 'top' && ab !== 'bottom') {
  ab = Math.random() < 0.5 ? 'top' : 'bottom';
  try { localStorage.setItem('np-sol-ab', ab); } catch (e) {}
}
// logged once per player as an event, so we can compare the two groups

What we'll compare per variant: how many people leave in the first 10 seconds, how many games get finished, how many are won, play time, and how many come back the next day. Finished games matter more to us than taps: if the bottom deck makes people quit fewer games, that's the answer.

The test started today, so there are no results yet. I'll post a follow-up when there's enough data to say something honest.

Small things we learned on the way

Put a word under every icon. A gear or a lightbulb is obvious to us; it isn't to everyone. "Settings" and "Hint" cost a few pixels and remove the guessing.
Don't change the rules mid-game. Draw 1 / Draw 3 applies from the next deal, so a game in progress never changes under you, and daily puzzles and duels keep the rules everyone else plays with.
Keep the bar out of the system gesture area. On phones with a home indicator, the bar needs env(safe-area-inset-bottom) padding, or the Undo button fights with the swipe-home gesture.

If you want to try it, it's at nitroplayer.com/games/solitaire. It works best on a phone, held in one hand. I'd love to hear where you'd put the deck.

Multiplayer card and puzzle games with no WebSockets: a 6-letter link, a shared seed and a 1-second heartbeat

NitroPlayer — Sat, 24 Oct 2026 08:38:40 +0000

I build NitroPlayer, a site of classic browser games: Solitaire, Sudoku, Mahjong, FreeCell, Checkers, Hearts and so on. A lot of our players are 45+, and the feature they use most is not a fancy one. It's this: send a link to your sister, your grandson or a coworker, and you both play the same game at the same time.

No app, no account, no lobby to understand. Tap the link, play.

When I started, I assumed this needed WebSockets and a realtime server. It turned out it didn't. Here's the setup that has been running in production, on ordinary PHP + MySQL hosting, with no cron jobs and no socket server.

1. The invite is a 6-character code

A private match is a row in a table with a short code. The link is just /games/sudoku/?race=K7MXQ2.

function match_code(): string {
    // no 0/O, 1/I/L: people read these codes out loud on the phone
    $abc = 'ABCDEFGHJKLMNPQRSTUVWXYZ23456789';
    $s = '';
    for ($i = 0; $i < 6; $i++) $s .= $abc[random_int(0, strlen($abc) - 1)];
    return $s;
}

32 characters, 6 positions: about a billion codes, which is plenty when matches expire after a few minutes. Dropping the look-alike characters mattered more than I expected. Grandparents do read the code to each other over the phone.

2. Both players get the same game from a seed

For "race" games (who finishes the Sudoku first, who clears the Solitaire deal in fewer moves) the fairness rule is simple: same puzzle for both. The server picks a random seed when the match is created and stores it with the match. Each browser generates the deal locally from that seed.

// any small seeded PRNG works; what matters is that both clients run the same code
function rng(seed) {
  return function () {
    seed |= 0; seed = (seed + 0x6D2B79F5) | 0;
    let t = Math.imul(seed ^ (seed >>> 15), 1 | seed);
    t = (t + Math.imul(t ^ (t >>> 7), 61 | t)) ^ t;
    return ((t ^ (t >>> 14)) >>> 0) / 4294967296;
  };
}
const deck = shuffle(fullDeck(), rng(match.seed)); // identical on both screens

The server mostly sends one integer (plus the puzzle itself for the few games where generating one on the client would be slow). That keeps payloads tiny, and the game code is the same as in solo mode: while a match runs, the game's random source is simply seeded. The daily puzzle works the same way, keyed to the date, so everyone gets the same Sudoku today and the leaderboard is fair.

3. A 1-second heartbeat instead of a socket

Each client posts its progress about once a second: cells filled, cards moved, "I finished". The response carries the opponent's progress back.

POST /api/duel.php  { action: "tick", code: "K7MXQ2", progress: 41, done: false }
→ { opponent: { name: "Mia", progress: 37 }, clock: 83.4, state: "playing" }

For a race to finish a puzzle, one second of latency is invisible. You see your friend's progress bar move, you feel the pressure, that's the game. For turn-based games (Checkers, Reversi, Hearts) the same request returns the last move, and a turn simply arrives within a second. Nobody playing Checkers with their grandson has ever complained about 800 ms.

What we gained by not running a socket server:

It runs on the same PHP-FPM pool as the rest of the site. Nothing extra to deploy, monitor or restart.
Phones going to sleep, switching apps and changing networks just work. The next request picks up where things stand. No reconnect logic.
Every request is stateless and cacheable in the usual places, and a broken client can't hold a connection open.

4. The server owns the clock and the result

The client is never trusted with the outcome. The match row stores started_at with millisecond precision, and the elapsed time is computed in SQL on every request:

SELECT m.*, TIMESTAMPDIFF(MICROSECOND, m.started_at, NOW(3)) / 1000000 AS elapsed
FROM duel_matches m WHERE m.code = ?

When a client says "done", the server checks it against the seed and against a minimum plausible time for that game. A Sudoku "solved" in 3 seconds isn't recorded. The result is written once, inside a transaction with the match row locked (SELECT ... FOR UPDATE), so two simultaneous "I won!" requests can't both win.

5. Housekeeping happens lazily, inside requests

There's no cron. Countdown, time-up, "your friend left" and cleanup all run as a side effect of the next request that touches the match:

The countdown ends when NOW() passes started_at. Nothing needs to "fire".
If one player hasn't sent a heartbeat for ~45 seconds, the next request from the other one marks them as gone and closes the match.
An invite nobody opened just expires: the row knows its age, and the next request that reads it treats it as gone.

This felt hacky at first. In practice it's the most reliable part of the system, because there's no second process that can be down.

What I'd tell someone building something similar

Ask what latency your game actually needs. For card and puzzle games, a 1-second poll is a feature, not a compromise.
Send seeds, not boards. Same code path as solo play, tiny payloads, and replays come for free.
Make the link the whole UX. Our biggest jump in people actually playing together came from removing steps (no sign-up, no "create room" screen), not from adding features.
Design codes for humans who will read them aloud.

If you want to see it working, open any game on NitroPlayer, choose "Play with a friend" and send the link to a second device. Happy to answer questions about the setup in the comments.