A devlog by Neeraj Kotwani, who builds every game on Elipar.
Every game on this site reports its score the same way: when a run ends, it posts a message up to the page around it. The page stores a personal best, shows a badge, and fires an analytics event. One line, same shape everywhere.
I ran an audit across all forty-four game folders — play counts, ratings, ninety days of analytics, and a static sweep for that one line.
Two games had zero of them. Not a malformed call, not a call in an unreachable branch. Nothing anywhere in the folder.
Checking the detector before trusting the count
A regex returning zero hits is exactly what a broken regex returns, so the first thing was a control: the daily word game, which demonstrably reports, came back with three hits. The sweep worked. Marble Maze and the ludo game had none.
That explained an analytics result I had previously mis-read. Marble Maze: six sessions, zero completions. The ludo game: thirty-seven sessions, zero completions. I had read those as "nobody finishes these" — a gameplay or difficulty problem.
It was not. People were finishing. Finishing emitted nothing, so the completion could not be counted, the personal-best badge could never appear, and the games were ineligible for a leaderboard by construction.
The ludo game is the second most-played game in the entire catalogue. It had been invisible for its whole life.
A zero in an analytics funnel can mean the event does not exist rather than that the behaviour does not happen. Worth checking which before designing a fix for the wrong problem.
What a one-ending game can rank on
Marble Maze is a tilt maze: guide a ball through a 3D maze to a goal. There is exactly one ending — you reach the goal — and no fail state at all. You cannot lose it.
That constrains the score completely. Completion is binary, so it carries no information. The only thing separating two runs is how long they took.
So the score is a base figure minus eight points per second elapsed, with a floor so a very slow run still records something. A fast run pays around 900, a slow one around 500, and a genuinely meandering one bottoms out at 50.
The thing I like about that shape is that it is unreachable without actually finishing — idling only ever costs you, and there is no way to farm it. The same reasoning as the nine-hole golf game here, which scores against par rather than on completion.
The ludo game needed the opposite treatment. It is dice-driven, so turn count is mostly luck and scoring it would add noise rather than skill. What a player actually controls is which token to move — so it scores pawns brought home, captures landed on opponents, and a flat bonus for winning. CPU captures are explicitly excluded.
And the capture term is capped, which is load-bearing rather than decoration: without the cap, a long lucky losing game could out-score a win. The cap guarantees the best possible loss stays below the worst possible win, and that is asserted directly, including a seeded twenty-capture loss landing exactly on the ceiling.
Reporting at the end was the catalogue's biggest killer
That audit turned up a pattern worth more than either individual fix.
Games that report per run were healthy — six completions per session on the endless runner, nearly three on the block stacker. Games that only reported after a whole campaign sat at essentially zero: nine holes of golf, five racing stages, ten puzzle boards, a full football match. Each at zero or one completion across ten to twenty-two sessions.
Those games were not broken. The score just fired at a point almost nobody reached, so nearly every real session recorded nothing.
Four games now bank a cumulative total at each milestone instead. That is safe because the site keeps the highest figure it is ever sent: a longer run can only raise your best, and quitting early can never inflate it. Every full run still scores exactly what it did before, which is asserted per game against the old formula rather than eyeballed.
The test bug that looked like four failures
One from that work, because it was instructive. The function that activates a button de-duplicates any second activation inside 400 milliseconds, treating it as a double tap.
My test clicked "next hole" faster than that. So it sank five holes while believing it had done nine, producing a par total that did not match, and reported a confident failure against entirely correct code.
I found it by tracing which hole index each report actually came from — 0, 1, 1, 2, 2, 3, 3, 4, 4 — rather than re-deriving the arithmetic for a third time. When a test's expected value disagrees with a game's, ask the game what it actually did instead of recomputing what it should have done.
Marble Maze is free in a browser, no account, no download. Reaching the goal is worth something now.