How our games are balanced and protected
Behind a three-minute run there are settings that were written down, argued over and tested. This guide lifts the lid on three of them: the way difficulty climbs, the way a score is checked, and the guarantee that the puzzle you are handed can always be solved.
Updated on
Settings written down in black and white
Every game has its own balance file, kept apart from the code that drives the screen. In it you find, each one named, every value that decides how the game feels: the speed of a projectile, how long a pick-up lasts, the moment pressure steps up a notch. So when a game feels unfair, we know which value to look at, and the reason for every change is written down right next to the value itself.
Second principle: the mechanic is kept separate from the display. The computation that decides whether three bubbles pop or whether a puzzle is solved depends on no screen and no image — which is exactly what lets us check it automatically, without launching a run.
Tuning a difficulty curve
An arcade game has to welcome a beginner on the first run and still feel tense on the tenth. That rarely happens through “stronger” enemies: what we tighten is the time you have to react. Two of our games go about it in opposite ways.
In Néon Bubble you fire bubbles at a ceiling that regularly pushes a new row towards you. What gets harder is not the row, it is the gap between two descents. At the start you have eight shots to line up your play; after two descents, seven; two descents later, six; and so on down to a floor of three shots, reached after ten descents. That floor is never crossed: the run gets very tense, never absurd. Nothing else moves — it still takes three bubbles of the same shade to pop them, and five shades are in circulation.
Why the board never narrows down to two colours
A player told us that by methodically clearing shades, a run would end up offering only two of them, recycled forever. The draw now guarantees that at least three distinct shades stay available as long as bubbles remain: below that threshold, missing colours are put back into play.
Néon Assault takes the opposite route. A wave there is a formation seven columns wide and five rows deep — thirty-five enemies sweeping the screen and dropping a notch at each edge. It starts slowly, at forty-eight pixels per second, and speeds up in two ways: by eighteen pixels per second for every wave you clear, which you would expect, and by 1.8 pixels per second for every enemy you destroy.
In other words: the better you play, the harder the current wave becomes. The last survivors move markedly faster than the first ones did, because you removed their neighbours yourself. No hidden timer or rubber-banding is needed to make the end of a wave nervy: the tension comes out of your own performance.
That climb is capped everywhere. The formation stops accelerating at three hundred and eighty pixels per second. Enemy fire, roughly a second and a half apart on the first wave, then closes up without ever going below four hundred and twenty thousandths of a second. A difficulty curve with no ceiling is not a challenge, it is a closed door.
What happens when you send a score
A leaderboard is only worth what it turns away. Here the browser ranks nothing on its own: it proposes a score, and the server decides. That decision starts before the run. The moment you press “play”, the server issues a game token — a sealed proof recording which game was launched, at what instant, and by whom if you are signed in. The seal is made with a key only the server holds: the token can be read, but not altered without the tampering being obvious.
When your score arrives, the start time written into that token is compared to the arrival time. The duration of your run is therefore never a value your browser announces: it is a value the server computes. The three checks that follow all depend on it.
Every game is calibrated separately on three questions:
- Did the run last long enough? Below a plausible minimum duration, the announced score could not have been obtained by playing. A puzzle “solved” in a fraction of a second is turned away.
- Does the score stay within the game’s limits? Every ceiling is computed from the real scoring scale, often estimated by simulating a very long run, with a margin that avoids turning away a legitimate feat.
- Did the points arrive at a reachable rate? The score over the duration gives a rate, compared to the game’s plausible peak. A credible total obtained in a tenth of the time it takes is turned away on that criterion alone.
Those three thresholds are specific to each title and are not published — a posted scale would mostly be an instruction manual for anyone trying to slip through. They are never sent to your browser, and they are calibrated wide: the point is not to catch the player who improves fast, it is to keep out submissions that bear no relation to a run that was actually played.
One token, one run
Every token carries a unique random identifier, accepted only once. Sending the same run twice therefore does not produce a second score. The token also has a limited lifetime: long enough for a long run, not long enough to be kept and replayed the next day.
Some games offer several difficulty levels, with trophies of their own on the hardest. Since the level you picked is announced by the browser, a time floor specific to that level is added on top: announcing an expert grid solved in a few seconds unlocks nothing, that time being incompatible with the real size of the grid.
A puzzle that always has a solution
On a thinking game, nothing is more discouraging than suspecting the grid itself. Our generators make that suspicion impossible, each in its own way.
Slide Puzzle Néon is the simplest case. On a four-by-four grid — fifteen tiles and one empty square — half of all imaginable arrangements are impossible to solve: that is a known mathematical property of the puzzle, not a flaw. So we never shuffle the tiles at random. We start from the solved grid and play a hundred and twenty random legal moves, avoiding undoing the previous one. A sequence of legal moves can always be walked back: the grid you are given is solvable by construction, and an automatic check re-verifies it on a hundred shuffles every time the tests run.
Néon Nonogram asks for more: it is not enough for a solution to exist, it has to be the only one, otherwise you would have to guess at some point — and guessing is not playing. Every candidate grid is therefore put in front of a solver that reasons by deduction alone, exactly as you do: it reads the clues row by row and column by column, fills a square only when no other arrangement is possible, and starts over as long as it keeps making progress. If a single square stays undecided, the grid is thrown out and another one is drawn. What you are given is always fully deducible, in all three offered sizes: five by five, seven by seven and ten by ten.
The step between two sizes was filed down
The nonogram’s middle level used to be a ten-by-ten grid, a hundred squares right after an easy level of twenty-five: a cliff rather than a step. It moved to seven by seven, forty-nine squares — so the size roughly doubles at each tier instead of quadrupling.
Néon Lights, finally, rests on an elegant trick. On this five-by-five grid, pressing a square flips that square and its four direct neighbours, and the goal is to switch everything off. Since pressing the same spot twice amounts to doing nothing, we build the grid starting from a dark screen and pressing eight different squares: replaying those eight presses, in any order, necessarily brings the blackout back. The grid is therefore solvable, and we know it can be solved in eight moves at most — which makes the matching trophy genuinely reachable rather than theoretical. If the draw happens to produce an already dark grid, it is regenerated.
Why we are telling you all this
These three jobs — the curve, the check, the solvability — are invisible when they work. You only notice the opposite: the unfair run, the dubious leaderboard, the puzzle that stalls for no reason.
The values quoted here are the ones in force at this guide’s update date, and several are already a second or third version. They will move again. What does not move is the method: a named value, a written reason next to it, and an automatic check keeping an eye on it.