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.
Top comments (0)