What 'Top Score' Even Means Across a Dozen Different Games
Per-game leaderboard configuration instead of one rigid schema, because a lower number is the better score in at least one game on the site.
High-score submission just went live across most of the site's games, and the deceptively hard part wasn't the leaderboard display itself — it was accepting that "top score" doesn't mean the same thing twice across a site with this many genuinely different games on it.
"Highest number" isn't a universal definition of winning
60 Sec Survival's meaningful metric is how many seconds you lasted. Perfect Time's meaningful metric is how close to zero your timing error was, which means a *lower* number is the better score, the opposite direction from almost every other game on the site. Chess measures wins against the computer opponent, not points. A single leaderboard system that assumed "bigger number wins" universally would have quietly been wrong for a real chunk of the site's own games. Building per-game leaderboard configuration — what the actual metric is, which sort direction counts as better — rather than one rigid schema applied uniformly everywhere, was the only way to make "top score" mean something true for every single game instead of being subtly wrong for the ones that don't fit the common case.
Client-submitted scores have an obvious, real trust problem
Every score submission originates from the player's own browser, which means it's technically possible for someone to submit a fabricated score directly, bypassing actually playing the game at all. I want to be honest that this first version doesn't solve that completely — full server-side replay verification, where the server independently confirms a submitted score against an actual recorded play session, is a much bigger project than shipping leaderboards at all. What this version does do is basic sanity bounds per game, rejecting scores that are structurally impossible given how that specific game's scoring actually works, which catches obviously fabricated submissions without requiring the full verification infrastructure a completely tamper-proof system would need.
Rank had to update the moment a score landed, not on a delay
Submitting a new personal best needed to show your updated rank immediately, not after some batch process runs later, because the entire emotional payoff of beating your own record is seeing exactly where that puts you against everyone else right now. A leaderboard that updates on a delay turns a genuine achievement into something you have to come back and check later to fully appreciate, which drains most of the immediate satisfaction out of the moment it actually happened. That meant the rank calculation had to run efficiently enough to compute on submission itself, not as a background job that catches up eventually.
Ties needed a tiebreaker before anyone actually hit one
Two players landing the exact same score is inevitable once enough people are submitting to the same leaderboard, and I had to decide how rank resolves that before it actually happened rather than improvising an answer under pressure once a real tie showed up in production. Whoever submitted the tying score first keeps the higher rank, which is a simple, defensible rule — first to reach a given score earned that position first, chronologically, and a later identical score doesn't retroactively displace them. It's a small rule that's easy to overlook entirely until the first real tie occurs, at which point an undefined tiebreaker turns into a visible, confusing bug rather than a quiet non-issue.
Profile icons on the leaderboard turned a number into a person
Showing a player's chosen profile icon next to their leaderboard entry, not just a username and a number, was a small addition that changed how the whole leaderboard feels to look at. A plain list of names and scores reads as a spreadsheet. The same list with a small recognizable icon next to each entry reads as an actual roster of people who've played this game, which matters more than it sounds like it should for something whose entire job is motivating someone to come back and improve their position among real people, not just abstract numbers.
Batching reads mattered once every game tile started asking for a rank
The games lobby shows a rating and rank indicator on every tile at once, which means loading that page can't mean firing off a separate database read per game just to populate one small badge on each tile. With leaderboards now live across most games simultaneously, that per-tile-query approach would mean dozens of individual reads on a single page load, which is slow and needlessly expensive against the database. I built the lobby to fetch every game's relevant leaderboard data in one batched read per page load instead, then distribute the results across all the tiles client-side. It's the kind of backend detail nobody visiting the site will ever notice directly, but it's the difference between the games lobby loading instantly and it visibly stalling while dozens of individual score lookups trickle in one at a time.
What "most games" means, and why not all of them yet
This launched across most games, not literally every one, and that gap is deliberate rather than an oversight. A few games don't have a scoring model that maps cleanly onto a competitive leaderboard at all — some are closer to creative or exploratory experiences than competitive ones, and forcing a leaderboard onto a game that isn't fundamentally about scoring would be adding a system nobody actually asked the game to have. I'd rather leave leaderboards out entirely for a game that doesn't need one than bolt on a shallow, meaningless score metric just so every single tile in the games lobby has a matching leaderboard icon.
This is infrastructure that every future game now has to consider from its own first day — does this need a leaderboard, and if so, what actually counts as winning here. That's a genuinely useful question to be asking earlier in a game's design now rather than retrofitting the answer in after the fact, the way today's launch had to for every game that already existed before this system did, which is a much better position for the site to be in going forward.
More from the Devlog