DEV Community: Ahmed Moaz

How hard is 'hard'? Reading a trivia question's difficulty from the answer spread

Ahmed Moaz — Sat, 17 Oct 2026 06:25:39 +0000

A difficulty label is a guess made before anyone answers. The answers tell you whether the guess was right. Difficulty shows up in two places after each question: how many people got it right, and where the wrong answers went. In the trivia quiz I build, Boardit's Trivia Tavern, the reveal after every question shows for 6 seconds how many players chose each option (checked 8 October 2026). Here is how I read that spread, and why one table's result proves much less than it seems to.

The quarter you get for free

Take a standard four-option question. Someone who knows nothing at all still picks the right answer one time in four. That is the probability of guessing a multiple choice question blind, and it means a quarter of the table answering correctly is not "hard". It is what nobody knowing looks like.

Testing has a name for stripping that luck back out: the correction for guessing. Robert Frary's 1988 guide to formula scoring covers it for exams. For a quiz table, the rough version is simple:

share who knew ≈ (share right − 1/4) ÷ 3/4

Say three of six players get a question right. That is 50%, and the formula gives a third. So about two of the six actually knew, and the third right answer was probably luck.

So what percentage of people should get a trivia question right? There is no single answer, but a hard question should still sit clearly above a quarter. Anything near 25% tells you nobody knew it.

Six players, nobody knows: what luck does

Small tables make luck loud. Suppose six people face a question none of them knows, and all six guess. On average, 1.5 of them will be right. More usefully:

no right answers happens about 18% of the time;
exactly one, about 36%;
two or more, about 47%;
three or more, about 17%.

So nearly half the time, a question nobody knew still shows two right answers. One time in six it shows half the table right, which looks like a fair medium question. If you relabel from one night, you will move good questions for bad reasons.

Where the wrong answers went

The spread of wrong answers says more than the count of right ones. Testing calls this distractor analysis, and it is the useful half of multiple choice item analysis. These are the four shapes I look for:

Most right, wrong answers scattered thinly. The question is easy, whatever the label says.
The right answer and one wrong option splitting the table. This is a good hard question: the wrong option is a real belief, not a throwaway.
One wrong option beating the right answer. Either it is a strong trap, or the key is wrong. Check the source before you blame the table; a wrong answer key looks exactly like a brilliant trap.
Answers spread evenly over all four. Nobody knew. That is how to tell if a quiz question is too hard: not a low score, but a flat one.

The second shape is also the clearest lesson in how to write good distractors. A wrong option earns its place when people who half-know the subject choose it.

How many answers before you trust it?

A score from six people carries a wide margin. Using the Wilson score interval, which Edwin Wilson published in 1927, three right out of six gives a 95% range of roughly 19% to 81%. That range covers easy, medium and hard at once.

Pool ten tables, sixty answers, with thirty right, and the range narrows to about 38% to 62%. That is a small sample size still, but now it can tell an easy question from a hard one. Dozens of answers per question, not six, is the honest minimum.

Measuring trivia question difficulty at a live table

In my game the result stays up for 6 seconds after each question, showing the right answer and how many chose each option. Each player gets one answer per question, so every count is a person, not a second tap after a wrong first one. That makes the spread clean enough for the arithmetic above.

Six seconds is short, so jot down the counts for questions labelled hard and keep a running tally across nights. If you want to try this on real questions, Boardit, the free site where I run this online trivia quiz, is a reasonable place to start.

Relabel slowly

So how hard should trivia questions be? The labels matter less than the shapes. Easy medium hard trivia questions should each produce their own spread, and a hard one should split the table rather than flatten it.

This is a method, not a study. I have published no answer spreads from real tables, and the arithmetic above shows why one table could not settle a question's difficulty anyway. Groups differ too: a question that floors a mixed table can be easy for a table of fans.

At your next quiz with friends, write down the spread for every question labelled hard. Keep the ones that split the room, and check the key on any where a wrong option won.

Ahmed Moaz builds Boardit, a free browser game site.

Word choice in a drawing game: designing so no drawer gets an impossible word

Ahmed Moaz — Sat, 17 Oct 2026 06:10:49 +0000

Every drawing game design has to handle the same failure: a player is handed a word they cannot draw, and the turn dies. There are two ways to design word choice in a drawing game against that. You can curate the list until every word is drawable, or you can let the drawer choose from several. I build Draw and Guess, a drawing game, and it does both: a built-in list that is deliberately easy, and a choice of two to five words each turn. Here is the arithmetic for why the second layer matters, and what it costs.

Curating a drawing game word list only gets you so far

If you are working out how to build a word list for a drawing game, curation is the first layer. A curated list removes the words that are hard for nearly everyone, such as rare jargon or long phrases. It cannot remove words that are hard for this particular drawer. A famous app is easy for one player and meaningless to another. A local food is obvious in one country and a mystery in the next. Drawing games online played with friends from different countries meet this all the time.

Only the drawer knows their own gaps, and they know it in a second or two. That is the case for choice, and a general rule of player choice in game design: hand the last cut to the one person with the information.

How many words should a drawer choose from?

Suppose a share q of the list is unworkable for a given drawer, and words are dealt independently. The chance that every offered word is unworkable is q to the power of the number offered.

Words offered	q = 10%	q = 20%
1	10%	20%
2	1%	4%
3	0.1%	0.8%
5	0.001%	0.03%

These q values are assumptions, not measurements. Even so, the shape holds for any q. A single word leaves a fixed share of turns doomed. A second option cuts that share by a factor of 1/q, and each extra word helps less in absolute terms than the one before.

What choice costs: the word choice timer

Choosing is not free. Hick's law, from W. E. Hick's 1952 paper on choice reaction time, describes decision time growing with the logarithm of the number of options. Going from two options to five more than doubles the information to process, from 1 bit to about 2.3.

In my game the choosing slice is fixed. At the shortest settings a turn takes at most 58 seconds: 12 to choose, 40 to draw and 6 for the result. Choice already costs about a fifth of that turn. Offering five words does not add seconds, but it fills the same seconds with more reading.

A fallback when a player times out

Any choice screen needs a rule for the drawer who doesn't decide in time. There are three common options: deal one of the offered words, deal a fresh word from the list, or skip the drawer. The first is the safest of the three, because it keeps the turn inside the offer. All three show why the curated list still matters. A drawer who freezes is protected only by how good the worst offered word is.

Easy vs hard words: difficulty levels or a flat list?

One common design tags words easy, medium and hard and pays more for the hard ones. My list has no tiers. The scoring pushes drawers towards easy words instead. Drawers are paid from how quickly their guessers answer, averaged over the rest of the table. So a sketch most of the table gets early pays at least as much as one only a single guesser cracks.

You can try that scoring on playboardit.com.

If you want to rate word difficulty with data rather than taste, there is a public dataset for it. Google Creative Lab's Quick, Draw! dataset holds 50 million drawings across 345 categories. Each drawing records whether the game recognised the word. A recognition rate per word is a rough difficulty score you can sort by, and the simplest way I know to test drawing words with data before players ever see them.

What I haven't measured about word choice in a drawing game

I have not measured which words drawers skip, or which drawings get guessed. I built the game on 15 September 2026, and my list was chosen by judgement, not by recognition data. The table above shows why choice helps. It does not show how often my players actually need it.

Ahmed Moaz builds Boardit, a free browser game site.

How long does a Ludo game last? 30,024 simulated games, counted in rounds

Ahmed Moaz — Sat, 17 Oct 2026 06:10:48 +0000

Minutes depend on your table: how fast people throw, how much they talk, whether someone gets up to make tea. So I counted something that doesn't depend on any of that.

In 30,024 computer-played games run through Boardit's live Ludo engine on 29 September 2026, the median game lasted 70 rounds with two players, 95 with three and 120 with four. I make Boardit, a small site of multiplayer board games that run in the browser, and these runs were made to test it. The site itself has no computer opponents; the scripted players exist only for testing.

What a "round" means here

The engine adds a round each time play wraps back past the opening seat, so by then every seat still playing has had one turn. This is the counter, trimmed from the code:

function nextTurn(s: LudoState): void {
  const count = s.players.length;
  for (let step = 1; step <= count; step += 1) {
    const index = (s.turn + step) % count;
    if (!stillPlaying(s.players[index])) continue;
    // Wrapping past the opening seat is one round.
    if (index <= s.turn) s.round += 1;
    s.turn = index;
    return;
  }
}

Two details matter. A finished player is skipped, so late rounds have fewer turns in them. And a turn can hold several throws, because a six, a capture or a piece reaching home earns another one.

The stopping rule matters too. A game ends only when one player is left unfinished, because the others play on for second and third. A two-player game stops when one player has all four pieces home. A four-player game runs until three have.

The obvious guess

A natural first guess is that the rounds stay roughly flat as players are added. Each player still has four pieces to walk round the same board, so each should need about the same number of their own turns. More players would mean more turns per round, not more rounds.

What the simulation measured

That guess is wrong. Here are the simulated results, 10,008 games at each table size:

Seats	Median rounds	Middle 80%	Mean rounds	Mean captures
2	70	56–88	71.6	4.4
3	95	76–117	95.9	14.1
4	120	99–147	121.8	30.0

Each added seat adds about 25 rounds to the median. The spread widens too: the middle 80% of four-player games covers 48 rounds, against 32 at two seats. In every case the mean sits a round or two above the median, so the distribution has a modest tail of long games.

A worked reading of the four-seat row: in ten simulated four-player games, expect about one to be over by round 99 and about one to run to round 147 or later. Half end by round 120. That long tail comes from the dice and the captures alone, because computer players are never slow to move. A human table adds its own pace on top.

Method, in one breath: every seat was a scripted player moving through the real rules engine with a seeded die. Most seats took a capture or a finish when one was available, otherwise brought a piece out, otherwise moved their furthest piece. One seat per game used a different scoring rule for a separate test that isn't about length. No game was cut short and no move was rejected.

Why the rounds grow

Two things push the count up.

The first is captures. The simulated games averaged 4.4 captures with two players and 30.0 with four. Per seat, that is about 2.2 captures a game at two players and 7.5 at four. Every capture sends a piece back to base, where it waits for a six and then walks the lap again. At two seats there is about one capture every 16 rounds; at four, one every 4.

The second is the stopping rule above. At four seats the count runs until three players are home, not one.

The data can't separate these two effects. The run recorded each game's total rounds, not the round when the first player finished.

The minutes, if you must

Rounds times seats gives an upper bound on turns: 140, 285 and 480 for the median game. Multiply by your own seconds per turn. An earlier, different test in August, with random moves on an older version of the rules, is why the Ludo card on my site changed from 20 minutes to 30–60. I have no measured human pace, so I won't print one.

Check it at your own table

Keep a tally: one mark each time the turn comes back to whoever went first. If your two-player games land far outside 56–88 rounds, look at your house rules first. Two dice, a one that also releases a piece, or a bounce-back finish could each move the count, and so could human choices. If you'd rather play the ruleset these numbers come from, Ludo on Boardit is the version I build, and you can keep the same tally there.

What the simulation cannot say

If you play Ludo online, the Ludo rules are the same as on a cardboard board, so these lengths are a fair guide when you plan an evening of Ludo with friends.

These are computer players, not people. The opponents favoured captures, so the capture counts run higher than random play would give. The engine is the one live on 29 September 2026. The run doesn't speak to seat order, to strategy, or to how long your evening will feel.

Hosting Discord trivia for your server without writing a bot

Ahmed Moaz — Fri, 16 Oct 2026 09:45:52 +0000

The usual route to Discord trivia is a bot. Someone finds one, or writes one, adds it to the server, and trivia questions start appearing in a text channel. It works, but it asks more of a server than most event hosts expect. This is how to host trivia on Discord by the other route: a voice channel, a link to a browser quiz, and three people with clear jobs.

I build Boardit, whose trivia quiz is the one I use as the example, so weigh that as you read.

What a Discord trivia bot asks of a server

Start with permissions. Discord's help pages say that to add an app to a server, you must own the server or have the Manage Server permission. So how to add a bot to a Discord server is really a question about who holds that permission. On a community server, that is usually a short list of admins, and the event host may not be on it.

The bot also keeps whatever access it was granted until someone removes it. A bot you write yourself is a program that has to run somewhere, all the time, and someone has to keep it running.

Then there is the format. Many quiz bots post questions in a text channel, where answers are typed in the open. When the first correct reply takes the point, everyone else sees it the moment it lands, which rewards fast typists and watchers more than knowers.

A browser quiz in a voice channel

The alternative keeps Discord for what it does well: voice, faces and banter, the parts that make Discord voice channel games fun. The quiz runs in a browser tab, so you can play with friends in the call while each player answers privately on their own phone or computer. Nobody sees anyone else's answer until the reveal.

The setup is a link. Anyone who types the room code, or opens the invite link, takes a seat. That makes the link the door key. Post it in the voice channel's own text chat, not in an announcements channel the whole server can read.

Set the room to Private before people arrive, and check it once. Hosts often keep two tabs open, so one fix matters here: since 3 October 2026, on Boardit's quiz, an older lobby tab can no longer undo settings saved in the newer one.

The quiz's two scoring modes, and how a question ends once everyone has answered, are on its page at Boardit.

Three roles for a trivia night on Discord

A Discord game night built around a quiz runs better with three people than with one.

The host opens the room, sets it to private, picks the topics and posts the link in the voice channel's chat.
The announcer reads the scores aloud. The standings stay up for seven seconds between rounds, which is a fixed beat to call out the leaders and tease whoever is last.
The moderator watches the text chat, deletes any answers posted there, and handles anyone who arrives once the seats are full.

That last job matters. A room has a seat limit, shown on the game page, and a busy voice channel can hold more people than one quiz seats. Discord itself caps a voice channel at 25 once anyone turns a camera on. Plan a second host for overflow, or run the quiz again an hour later.

Rules to post before the first question

Pin these in the event channel so nobody argues later:

No answers in any channel while a question is open.
No searching. Phones are for answering only.
Ties stand as the game settles them; the host does not overrule the result.
Late arrivals wait for the next quiz rather than taking a seat mid-game.

Posted early, they keep an online trivia night fair to the quiet members as well as the loud ones. A quiz night for an online community lives or dies on that.

When a Discord trivia bot is still the right tool

A bot has real strengths, and a community game night is not always the right shape. A bot runs while people come and go, keeps a leaderboard across weeks, and can ask questions your members wrote. A browser room needs everyone online at once and holds fewer people than a big channel.

So pick by the event. For a weekly scheduled slot among your Discord server events, with a crowd in voice at the same time, the browser room is simpler. For an all-week, drop-in quiz in text, keep the bot. Either way, games to play in Discord voice chat work best when the talking is the fun and the scoring stays out of sight.

The Discord limits above come from its help pages as read on 8 October 2026, and they can change. Discord is a trademark of Discord Inc. This post is not affiliated with it.

Ahmed Moaz builds Boardit, a free browser game site.

Structuring a multiple-choice quiz bank: eight fields per question, and why each exists

Ahmed Moaz — Fri, 16 Oct 2026 06:11:26 +0000

I build Boardit, a free browser game site, and one of its six games is a live quiz called Trivia Tavern. As of 4 October 2026, its public pages describe a bank of nearly 4,000 checked questions across 38 topics, and the site's trivia hub prints 663 of them as samples on 17 topic pages. The bank was rebuilt on 26 and 27 September 2026.

This post is not a copy of our files. It is the structure I would hand anyone starting a question bank of their own, and where something Trivia Tavern does in public explains a field, I say so.

Keep one question per line

Store each question as one JSON object on its own line. The format is called JSON Lines, and its whole specification fits on one page at jsonlines.org. A broken record then breaks one line, not the whole file. A diff shows exactly which question changed. And counting the bank is a line count, not a guess.

Here is one record, written for this post. It is not from our bank:

{"id":"rivers-0001","difficulty":"easy","question":"Which river runs through Cairo?","answer":"Nile","wrong":["Danube","Thames","Volga"],"explain":"Cairo sits where the Nile Valley meets the Nile Delta.","sources":["https://en.wikipedia.org/wiki/Cairo"],"subject":"Nile"}

That is eight fields. The rest of this post gives the reason for each.

The id outlives every edit

An id is the only part of a question that survives being fixed. Correct a typo or relabel the difficulty and the id stays, so any answer history still points at the right question. Never give an old id to a new question.

Difficulty is a field because it changes the score

In Trivia Tavern an easy question is worth 100 points, a medium one 200 and a hard one 300, and that weighting is the same in every room. So a wrong label is a scoring bug, not a matter of taste: a "hard" question that everyone knows pays three times what it should.

Rounds also build. On the default Mixed setting, each round starts with questions nearly everyone knows and ends on a couple of hard ones. A dealer can only do that if difficulty is a field it can read.

I counted the labels on one public sample page on 4 October 2026, the landmarks topic: 39 questions, of which 16 are easy, 15 medium and 8 hard. That is about 41%, 38% and 21%.

Settle one thing before anyone labels anything. With four options, a blind guess is right one time in four. If difficulty means the share of a casual table who get it right, lucky guesses included, no label can honestly sit below 25%.

Wrong answers get their own list

Store the right answer and the three wrong ones apart, and do not store a letter. Every Trivia Tavern question has four options, with no lifelines and no passing, and options in any quiz like this should be shuffled each time a question is shown. A stored "C" is wrong the moment you shuffle.

A separate wrong list also lets you review the wrong options on their own, which is where weak questions hide. For what makes a good wrong option, start with Haladyna, Downing and Rodriguez's review of 31 item-writing guidelines (Applied Measurement in Education, 2002). Two of its plainest rules: keep the options alike in kind and length, and avoid "all of the above".

An explanation, and where the fact came from

When Trivia Tavern reveals an answer, the result stays up for six seconds and shows how many people chose each option. A table that has just got something wrong wants to know why, and one explain sentence gives a reveal something to say. Make it a new fact, not the answer said again.

sources is a list because one link is not enough for anything a player could argue with. Our changelog calls the rebuilt questions "checked", and a check needs something to check against, kept next to the question rather than in someone's head.

Topic and subject are not the same field

A topic is what a host picks: football, flags, the ancient world. In Trivia Tavern a match left on Mixed gives every category an equal share, and most topics hold about a hundred questions, with more for football and for food and drink. Keep the topic in the file name, so moving a file moves its questions.

A subject is narrower: the one thing a question is about, such as a river or a person. With it, a dealer can avoid asking two questions about the same thing in one match, where the first tends to give the second away. Spell subjects one fixed way, such as an encyclopedia article title.

What no format can check

A schema checks shape. It can refuse a record with two wrong options or no source. It cannot tell you that a fact is true, that a subject is famous enough for your table, or that "easy" really is easy. A second reader can catch the first two. Only real answers, collected over time, settle the third.

The same fields work for trivia questions written for a pub or a classroom, and for a trivia quiz you run as trivia online with friends.

Trivia Tavern does not take questions written by players, so all of this is for people building a quiz of their own. If you want to see a finished bank from the player's side, the quiz is one of the games on Boardit.

Ahmed Moaz builds Boardit, a free browser game site, from Egypt.

Scoring a drawing game fairly: speed points, a shrinking share, and a paid drawer

Ahmed Moaz — Sat, 03 Oct 2026 06:58:37 +0000

When I built the scoring for a draw and guess game, the first version was the obvious one: the faster you guess, the more you get. It took one test table to show why that is not enough.

Step one: speed points

A correct guess earns points on a straight line from the clock. A guess as the timer hits zero is worth 100, and one at the very start is worth 500, so the range is 100 plus up to 400 across the whole drawing time. The values are rounded to the nearest 5.

const GUESS_FLOOR = 100;
const GUESS_RANGE = 400;

function speedPoints(secondsLeft: number, drawSeconds: number) {
  const total = Math.max(1, drawSeconds);
  const left = Math.min(total, Math.max(0, secondsLeft));
  return round5(GUESS_FLOOR + (GUESS_RANGE * left) / total);
}

The clamp matters. A clock read a hair outside its bounds must not pay more than 500 or less than 100.

Step two: a shrinking share

If three people read a good drawing in the same second, they should not all take the full amount. Each correct guess is its speed points multiplied by an order share of 1 / (1 + 0.8 x earlier correct guesses). The first guesser keeps 100%, the second about 56%, the third about 38%, and no one ever drops below 20%. At 450 speed points that pays 450, 250, 175, 130, 105 and 90.

Step three: pay the drawer on what the table actually scored

The drawer takes the points the other players scored this turn, as shown on the result screen after the order cut, divided by everyone at the table: the drawer and any player who did not answer count in the divisor. Rounded to a multiple of five. In a two-player room the drawer gets half of the guess. With four players and three guesses worth 450, 250 and 175, the drawer gets 875 / 4, about 220. If nobody guesses, the drawer gets nothing.

I changed this after the first version. An earlier rule divided by the number of guessers, so a drawing only one person read could pay the drawer as much as one the whole table read. Dividing by the whole table means every extra right answer adds to what the drawer earns.

Hints without giving it away

The dashes show how long each word is, and letters fill in one at a time as the clock runs down. A guess that is one letter off tells only that player they are close, and a right guess is hidden from the table so nobody copies it.

The takeaway

When you design scoring for a multiplayer game, test it with a table that behaves badly: simultaneous guesses, no guesses, and one very good drawing. Most of the fairness bugs show up there.

If you want to see it running, the game is a free draw and guess game for two to twelve players on Boardit: a drawing game with friends in the browser, with no download. It is not just for friends, because Quick match seats you at an open table with other players.

Keeping multiplayer board game rules honest: pure reducers on the server

Ahmed Moaz — Sat, 03 Oct 2026 06:51:37 +0000

In a multiplayer board game, the dangerous bug is not a crash. It's two players seeing different boards, or one player doing something the rules don't allow. The fix that has worked best for me is boring: put the rules in pure functions, and run them only on the server.

One shape for every game

Each game's rules live in a reducer: given the current state and an action ("roll", "buy", "vote"), it returns the next state or an error. It doesn't read the clock, call the network or touch the database. A thin layer around it loads the state, calls the reducer, and saves the result.

function reduce(state: State, action: Action, player: PlayerId): State | Error {
  // validate that it's this player's turn, the action is legal,
  // then return a new state. No side effects.
}

Why that pays off

Testing is cheap. A reducer is a function, so a test is "start here, do this, expect that". The project now runs close to a thousand such tests in seconds, and many of them are rules a player would argue about.
The client can't cheat. The browser sends an intent ("I roll"), never a result. The server rolls the dice.
Secret information stays secret. In a hidden-role game, the secret word never reaches anyone it shouldn't, because the part of the code that picks it only runs on the server and isn't imported by any browser code. A test fails if that ever changes.

Where it still gets hard

Timers are the awkward part. A turn clock isn't a pure input, so I pass the current time in as part of the action and let the server decide when an action like "time out" is sent. Reconnection is the other: a player who drops and returns should get the authoritative state, not replay missed events.

If you build a turn-based multiplayer board game, start with the reducer before the UI. The UI is the part you'll rewrite anyway. My own project is Boardit, a set of free multiplayer board games online that run in the browser. You can play with friends by sharing a room code, and it isn't only for friends: open tables and Quick match seat you with other players.

Why a five-character room code beats accounts for a party game

Ahmed Moaz — Fri, 02 Oct 2026 21:51:24 +0000

When I started building a site for playing board games with friends, the obvious design was accounts: sign up, add friends, send invites. I dropped almost all of it for a five-character room code. Here is why, and what it cost me.

The problem with accounts for a one-evening game

A party game is a short-lived thing. Four people want to play for forty minutes. Every extra step before the first move loses someone: an email form, a verification link, a username that's already taken. The people most likely to quit are the ones you invited, not the host.

A room code is the opposite deal. One person opens a table and reads out five characters. Everyone else types them in, picks a name and sits down. Guests don't need an account at all.

What the code has to be

Short enough to read aloud across a video call. Five characters is about the limit before people start mishearing.
Unambiguous. No characters that look alike. If you read "O" and "0" to someone, you've already lost a minute.
Hard to guess. It is effectively a password to the table, so it can't be sequential and can't be listed anywhere public.

The cost: the code is now a credential

That last point changed more than I expected. Because the code is the only thing keeping strangers out of a table:

Room pages are excluded from search indexing and from the sitemap.
The code never goes into analytics, URLs sent to third parties, or logs.
Any script I didn't write, like an ads script, simply doesn't load on room pages, because I can't redact what it reads from the address bar.

What I'd tell someone considering the same design

Use a code when the session is short and everyone is in a hurry. Use accounts when people return across weeks. And whichever you pick, write down early where the identifier can leak, because a "harmless" ID in a URL ends up in places you didn't plan.

This is how it works in Boardit, a free browser site with six multiplayer board and party games. I'd like to hear where you'd draw the line between codes and accounts.

Three bugs I hit building a multiplayer board game site on Supabase and Cloudflare Workers

Ahmed Moaz — Fri, 02 Oct 2026 19:15:52 +0000

I've been building Boardit, a free site where friends play board and party games in the browser. One person opens a table, shares a five-character room code, and everyone else joins from their own phone or laptop. It runs on Next.js (App Router), Supabase and Cloudflare Workers, and it has six games so far: Property Rush, Trivia Tavern, Ludo, Who's the Spy, Snakes & Ladders and Draw and Guess.

Most of the game logic was the easy part. These three bugs cost me the most time, and none of them showed an error.

1. `void query` never sends anything

I had a heartbeat that updates a row so the room list knows a room is still alive. It looked like this:

void supabase.from('rooms').update({ last_seen: now }).eq('id', roomId);

It did nothing. No error in the console, no failed request, no row in the network tab. The reason: a Supabase (PostgREST) query builder is a lazy thenable. It only sends the HTTP request when something calls .then() on it. void doesn't, and neither does just building it.

The fix is to actually run it:

void (async () => {
  await supabase.from('rooms').update({ last_seen: now }).eq('id', roomId);
})();

The lesson I took: when a write "isn't happening" and nothing is failing, patch window.fetch and look for the request before you read any more code.

2. Realtime row changes were slow, so I nudged over broadcast

Every live feature (game state, chat, the drawing board) subscribed to postgres_changes and also polled. On my project I measured it on 16 September 2026: a row written to a chat table reached a subscribed browser through postgres_changes after about 5 seconds. A broadcast message on the same connection arrived in about 310 ms. Mine isn't a general benchmark, just my setup, but it explained why the games felt like they were catching up: the polls were doing all the real work.

What worked: after a write, the database sends a contentless "look again" message on a private broadcast topic (realtime.send() from a trigger), and each client refetches through its own row-level security policy. Because the message carries no data, nothing secret rides the broadcast, and Postgres still decides who can see which rows. I kept a slow poll as a backstop for a dropped socket.

3. The room code is a credential, so analytics had to be locked down

In Boardit, anyone with the code can sit at the table, so the code is effectively a password. That made normal analytics settings dangerous:

Autocapture sends the text of whatever was clicked. The lobby shows the code as a "copy" button, so the code would have gone to the analytics vendor.
URLs such as /room/AB3XK/table contain it, including inside redirect parameters.
Heatmaps key their data by URL, which turns the code into a property name that a "clean the values" filter walks straight past.

What I ended up with: autocapture, session replay, heatmaps and dead-click capture are off in code (not just in the dashboard, because the dashboard setting can switch itself back on from remote config), room paths are rewritten to /room/[code] before anything is sent, and every event property goes through a scrubber. Third-party scripts like ads simply don't load on room pages, because you can't redact a script you didn't write.

What I'd do differently

Write the "no code in analytics" test before the first analytics event, not after the first leak. And treat any Supabase write that isn't awaited as a bug until proven otherwise.

If you want to see how it plays, it's here: playboardit.com. I'd be glad to hear what you'd build differently, especially around realtime on Supabase.

Keeping a secret word secret in a realtime drawing game

Ahmed Moaz — Sun, 27 Sep 2026 17:35:06 +0000

A code-grounded look at server-held answers, narrow responses, and why a realtime room should not receive every private value.

A realtime game has a deceptively simple privacy problem: every player needs the shared board, but not every player should receive the answer. If the server broadcasts one complete state object to the whole room, a player can inspect the network response or browser state and read information the interface tried to hide.

In Boardit’s Draw and Guess implementation, the answer is treated as server-held game data. The public game state tells the room what phase and turn it is in; a guesser’s response does not contain the answer. The server checks a submitted guess and returns only the result appropriate for that player. The drawer has a different view because the drawer is the one drawing the answer. The key idea is not “hide it with CSS.” It is “do not send the private value to a client that has no reason to know it.”

This is a description of the repository implementation, not a general claim that every realtime product uses the same design.

Model visibility before designing the screen

Start by writing down what each actor is allowed to know. In a drawing round, that may look like this:

Actor	Needs to know	Should not receive
Drawer	The answer for the active turn	Other turns’ private answers
Guesser	The drawing, timing, and whether their own guess is correct or close	The answer before the round reveals it
Room observer	The shared board and round progress	Any private answer payload
Server	The answer and enough state to validate actions	Nothing beyond the game’s required data

The precise table varies by game, but making it explicit reveals the common mistake: storing a private answer in an object that is serialized to every connected browser, then merely hiding the text in the UI. If a browser receives a value, it is generally available to the person using that browser.

Keep the secret out of the broadcast state

Boardit stores Draw and Guess secrets separately from the shared room state. The repository’s build notes describe the word bank as server-only and the active turn’s selected word as data held outside the guest-facing HTML. A client component does not import the server word bank. That separation limits accidental exposure through a client bundle.

The distinction matters because a module imported by browser code can be included in the delivered JavaScript even when a component never visibly renders the full data. Hiding a list behind a conditional is not access control. Keeping the list on the server and exposing only a narrow action boundary is much easier to reason about.

In implementation terms, this means the browser asks to act; it does not submit a replacement authoritative board. The server loads the room state, checks the requested action against the rules, and decides what result to return. That also avoids trusting a modified client to mark its own guess correct.

Return the smallest useful answer

A guesser needs feedback, not the answer itself. A response can say “right,” “close,” or “not yet,” while the server compares the submitted text against the stored answer. In Boardit’s implementation, the guess action returns a role and a nullable word field; the guesser receives the word only when the guess was already correct. That is a small interface, but it expresses a strong boundary: the response shape is designed around what the caller is allowed to see.

This is also why “the UI does not display it” is not an adequate privacy test. Inspect the action response and the state received by another room member. Check the serialized payload, not just the pixels. A private value can leak in a hidden DOM node, a debug object, a log row, a source map, or an analytics event even if the main game screen looks correct.

Keep authorization beside the data fetch

The secret-handling pattern only works if the server checks who is asking. Boardit’s separate Who’s the Spy implementation makes that boundary especially visible: a multi-device player requests their own card, while the pass-one-device mode allows the host to request only the card for the slot currently being revealed. The shared game state is not used as a channel for everybody’s private role.

That repository example is useful because it shows how access rules change with the device model. In a shared-phone game, one browser acts for different local players, so the server checks the host and current reveal index. In a multi-device game, it checks the authenticated player. The correct permission check depends on the interaction, but it belongs on the server next to the data access.

Treat realtime and persistence as separate questions

A value can be absent from the room’s broadcast and still leak through a database table, event log, analytics property, or error response. Ask four separate questions:

Where is the secret stored?
Which table or channel is broadcast to all room members?
What exact fields does each server action return?
Could logs, telemetry, or error messages include the secret or private URL data?

For a game-state update, write shared state to the channel that every player needs, and keep private data in storage with tighter access. When an action creates both a public state change and a private write, consider ordering and concurrency. The Spy action path in this repository updates the shared game state under a version check, then writes associated secret changes after that compare-and-swap succeeds. That reduces the chance of attaching secret data to a state transition that lost a race.

Test the boundary, not just the happy path

Useful checks should fail if the secret crosses a boundary. Boardit’s Spy word-bank tests scan application, component, and library source to ensure the full word-bank binding is not imported outside the server-side game directory and never appears in a client component. The implementation also has reducer tests for state transitions. Those checks complement one another: one guards module reachability, another guards game behavior.

For a drawing game, the equivalent tests should inspect action results and serialized state. As a guesser, submit a wrong guess and assert the response does not contain the answer. As another room member, inspect the broadcast payload. Build the production client and search for server-only data. Test errors and retry paths as well as the normal turn.

The guiding rule is simple: define who may know each value, keep private values on the server until needed, and make each response contain only the caller’s authorized view. Realtime speed does not require broadcasting every piece of state to every player.

The game is available at Boardit and its Draw and Guess page. Repository-specific claims above come from the Draw and Guess and Spy action files, docs/draw-and-guess-build.md, and lib/games/spy/words.test.ts.

Disclosure: I’m Ahmed Moaz, the solo developer of Boardit. This article describes implementation details from my own project.

Six Multiplayer Browser Games on Cloudflare Workers and Supabase: What Broke

Ahmed Moaz — Sun, 27 Sep 2026 12:54:00 +0000

When I started putting multiplayer games into one browser app, I expected the hard part to be implementing six sets of rules. It turned out that the rules were often the cleanest part. The harder questions were about which copy of the board to trust, what happens when a socket goes quiet, how to keep a private word private when a whole database row is broadcast, and whether a perfectly good app would fit in the hosting plan I wanted.

I’m Ahmed Moaz, a solo developer in Egypt, and I build Boardit, a browser table for six multiplayer games. The stack is Next.js App Router, Supabase Auth/Postgres/Realtime, and Cloudflare Workers. Here are a few design decisions that came from actual failures rather than a diagram that looked tidy.

Make the rules boring: pure reducers

Each game has its own engine under lib/games/<game>/engine/. An action goes in with the current state and an explicit context; the reducer returns a result. The context supplies things that would otherwise make the function unpredictable, especially time and randomness. That means a test can say exactly what time it is and exactly what the die rolled.

In Ludo, for example, the reducer checks the phase before acting. It won’t accept a move before a roll, a second roll during the same turn, or a pawn destination that the die did not permit. It clones and hydrates state, applies the action, and returns the next state and events. No network request or database write belongs inside that rule function.

export function applyAction(state: LudoState, action: Action, ctx: Ctx): ApplyResult {
  const next = structuredClone(state);
  hydrate(next);
  const events: GameEvent[] = [];
  const log: Log = (kind, text, playerId) => {
    next.seq += 1;
    events.push({ seq: next.seq, kind, text, playerId });
  };
  const error = route(next, action, ctx, log);
  if (error) return { error };
  return { state: next, events };
}

The same separation exists for Property Rush, Trivia Tavern, Snakes & Ladders, Who’s the Spy, and Draw and Guess. Each engine has reducer tests beside it. That makes the tests fast and lets them cover edge cases that are awkward to reproduce through a live room: a tied vote, a timeout, a simultaneous correct guess, a rematch, or a malformed older state. The tests do not prove that the browser and database agree; they prove the rules do what the rules say when given a specific state and action.

The boundary matters. A pure reducer is not a security boundary by itself. The server action still has to decide who may send an action, supply trusted randomness and time, and persist the result safely. But it gives me one small place to reason about game rules without also debugging Supabase or React.

A room code is a credential

Joining a private room with a short code is convenient, but a code that seats someone is a bearer credential. Anyone who has it can try to enter. I treat it more like a temporary password than a harmless label.

The application checks room membership through the session-bound Supabase client before a game action proceeds. Row Level Security is part of that check: the membership-scoped room lookup must return a room for the caller. Server-side actions then use the privileged database path only where the game needs it. Random choices come from server-side cryptographic randomness rather than from a browser that a player can inspect or modify.

The same assumption changes what I log and broadcast. Room codes do not belong in analytics, screenshots, public URLs, or debugging output. The route can contain one because it is how a player gets to the room; that does not make it safe to send to a third-party analytics service. Boardit’s analytics code redacts the room path and strips code-like properties, and room identity in events uses an internal UUID instead.

It is also why a database row is not automatically safe just because it is in a private game. Supabase Realtime can deliver an updated row to subscribers who are allowed to read it. For Draw and Guess, the shared board state must not contain the word: the secret word and choices live in a separate, restricted table, and only the drawer gets them from their own server action. In Who’s the Spy, roles and words receive the same scrutiny. A useful review question is: “If every authorized player receives this whole object, is every field in it meant for every player?”

Realtime is a hint, not the source of truth

The first version of “multiplayer” in my head was simple: write a row, subscribe to changes, update the screen. The production behavior was less simple. On this Supabase project, some postgres_changes updates took around five seconds to reach a subscriber. That is a long pause after a die roll, and a silent WebSocket failure is worse: the UI can look connected while the board stops moving.

For the shared board hook, I kept Postgres Changes for the quick update and added a two-second fetch of the authoritative state as a reconciliation path. The hook orders deliveries by a monotonically increasing version so an older payload cannot rewind the board. It also has a special case for version zero: a rematch starts a new board at zero, but a late duplicate of the previous game’s opening state can also arrive late. In that ambiguous case, the client asks the database for the current row instead of guessing.

const POLL_MS = 2000;

if (next.version !== 0 && next.version < versionRef.current) return;
versionRef.current = next.version;
setState(next);

Polling is a trade-off. It creates a small, regular read load and means “disconnected” may take a moment to become visible. In exchange, one dropped socket does not leave a turn-based game frozen indefinitely. The poll is not the game engine and does not invent a move; it simply asks the database what state is current.

For Draw and Guess, I added a different fast path after seeing the delay. A database trigger sends a Supabase Broadcast “nudge” when relevant state, event, or chat rows change. The nudge says only what changed at a high level; it carries no game secret or board contents. The client then fetches the authorized data. Broadcast avoids the slower write-ahead-log path in this setup: the migration notes measured delivery in tens of milliseconds for the drawing channel. Trivia later adopted the same idea; its migration records roughly 300 ms versus about five seconds for the old row-change path. Those are observations from this project, not latency guarantees from Supabase.

The distinction is deliberate: the database row is authoritative, Realtime tells the client to look sooner, and polling repairs the view if the message never arrives. For some games the subscribed row itself is still the fast path; for Draw and Guess and Trivia, the nudge shortens the wait without broadcasting the sensitive payload.

A timeout should preserve the game

“Skip the absent player” sounds reasonable until the game’s rules make skipping destructive. In Ludo, a player may need to roll a six to get a pawn out of base. A skipped turn can mean that pawn never enters the game, while the rest of the table spends every round waiting for a clock that keeps expiring.

Ludo and Snakes & Ladders use 30-second turn clocks. When Ludo expires, the server checks the deadline and rolls and chooses an obvious legal move on the player’s behalf. It favors a capture, then a pawn getting home, then getting a pawn out of base, then progress with the pawn furthest along. Nobody is removed just for being slow. Any client can request the expiration action, but the server checks the deadline against its own clock, so the player’s browser does not get to declare a turn over early.

Property Rush needed a different rule. A fixed turn timer penalized a player who had already made a move and was waiting for others during a long auction. Its clock measures inactivity since that player’s last move, gives a 30-second grace period, then shows a warning before the 150-second deadline. The auction pauses the deadline; on expiry, the quiet player leaves the table. That is more state to carry and test, but it measures the behavior the table is trying to discourage: leaving everyone waiting without taking an action.

Timeout policy is game design, not just a setTimeout. The reducer needs an explicit expiry action, the server must validate it, and the automatic choice should keep the game playable rather than punish someone by making a valid strategy impossible.

Guests make the first click easier—and identity harder

People can enter a display name and play as a guest. Under the hood, that is still a Supabase anonymous auth session, not an untracked browser pretending to be a user. The session gives the server a stable user ID for room membership and RLS while avoiding an email, password, or account form before the first game.

That is a good onboarding trade: fewer steps before the table, more work around guest cleanup, account boundaries, and what happens when someone returns on another device. Anonymous does not mean authorization can be skipped. The server still checks that session’s membership for each protected action, and the app has to distinguish a guest session from a full account in its navigation and account flows.

The hosting limit that was 12 KiB away

I tried the Cloudflare Workers free tier and measured the generated Worker at 3,084 KiB gzipped against a 3,072 KiB limit. Twelve kibibytes over meant a deploy rejection. The surprising part was how much of the budget was supporting things the app did not need at runtime.

The social share image was rendered dynamically with Next’s image tooling, which pulled roughly 1.5 MB of WebAssembly into the Worker to make one image that never changes. Replacing it with a pre-rendered 1200×630 public/og.png removed about 279 KiB from the bundle. I also replaced a server analytics SDK used for one JSON request with fetch, removing another 94 KiB, and removed an unused icon package. These cuts were worthwhile even before they made the size fit.

The app now runs on Workers Paid, whose documented limit for this setup is 10 MiB, so the free-tier overage is historical context rather than the current deployment ceiling. The exercise still changed how I think about server bundles: inspect what the adapter actually includes, and ask whether a thing that never changes needs to execute in the request runtime at all. Static assets are often the right place for static work.

There is another useful boundary here: Supabase Realtime is a browser-to-Supabase WebSocket. Gameplay subscriptions do not pass through the Worker, so they do not use its WebSocket connection budget. The Worker handles server rendering and trusted actions; Supabase handles the live database channel.

What I would keep

The architecture has costs. A server action and database write add a round trip to a move. Polling adds reads. A single JSON state document makes versioned updates simple, but it demands care when a whole row is broadcast. Anonymous sessions are easy to start and harder to reconcile across devices. A Worker can be a tight fit when a framework adapter bundles more runtime than the app itself appears to use.

I would keep the pure reducers, the server membership check, and the separation between authoritative state and delivery hints. They make failures easier to isolate. A slow board update can be traced to transport or reconciliation without rewriting the rules. A leaked secret is less likely when private information never enters the broadcast row. A weird timeout can be reproduced with a fixed context and a reducer test.

The best multiplayer feeling is not a clever subscription. It is that a player can take an action, see it settle, and trust that everyone else will converge on the same board—even when a socket is slow, a player disappears, or a deployment has a budget measured in kibibytes.

If you want to see the finished table and how the six games fit together, visit Boardit.

DEV Community: Ahmed Moaz

How hard is 'hard'? Reading a trivia question's difficulty from the answer spread

The quarter you get for free

Six players, nobody knows: what luck does

Where the wrong answers went

How many answers before you trust it?

Measuring trivia question difficulty at a live table

Relabel slowly

Word choice in a drawing game: designing so no drawer gets an impossible word

Curating a drawing game word list only gets you so far

How many words should a drawer choose from?

What choice costs: the word choice timer

A fallback when a player times out

Easy vs hard words: difficulty levels or a flat list?

What I haven't measured about word choice in a drawing game

How long does a Ludo game last? 30,024 simulated games, counted in rounds

What a "round" means here

The obvious guess

What the simulation measured

Why the rounds grow

The minutes, if you must

Check it at your own table

What the simulation cannot say

Hosting Discord trivia for your server without writing a bot

What a Discord trivia bot asks of a server

A browser quiz in a voice channel

Three roles for a trivia night on Discord

Rules to post before the first question

When a Discord trivia bot is still the right tool

Structuring a multiple-choice quiz bank: eight fields per question, and why each exists

Keep one question per line

The id outlives every edit

Difficulty is a field because it changes the score

Wrong answers get their own list

An explanation, and where the fact came from

Topic and subject are not the same field

What no format can check

Scoring a drawing game fairly: speed points, a shrinking share, and a paid drawer

Step one: speed points

Step two: a shrinking share

Step three: pay the drawer on what the table actually scored

Hints without giving it away

The takeaway

Keeping multiplayer board game rules honest: pure reducers on the server

One shape for every game

Why that pays off

Where it still gets hard

Why a five-character room code beats accounts for a party game

The problem with accounts for a one-evening game

What the code has to be

The cost: the code is now a credential

What I'd tell someone considering the same design

Three bugs I hit building a multiplayer board game site on Supabase and Cloudflare Workers

1. void query never sends anything

2. Realtime row changes were slow, so I nudged over broadcast

3. The room code is a credential, so analytics had to be locked down

What I'd do differently

Keeping a secret word secret in a realtime drawing game

Model visibility before designing the screen

Keep the secret out of the broadcast state

Return the smallest useful answer

Keep authorization beside the data fetch

Treat realtime and persistence as separate questions

Test the boundary, not just the happy path

Six Multiplayer Browser Games on Cloudflare Workers and Supabase: What Broke

Make the rules boring: pure reducers

A room code is a credential

Realtime is a hint, not the source of truth

A timeout should preserve the game

Guests make the first click easier—and identity harder

The hosting limit that was 12 KiB away

What I would keep

1. `void query` never sends anything