How Gem Collection Games Work

Most explanations of how a collection game works stop at "you move, you touch a gem, you get points". That is true, and it explains nothing useful. The interesting part is everything that has to be decided between those steps: how close counts as touching, how the gem got there, what happens to your multiplier, and why any of it feels good rather than arbitrary.

This guide walks through the systems in the order they run, using the engine behind the games on this site as the worked example. The specific numbers are ours; the structure is common to the genre.

The loop: what happens sixty times a second

A collection game is a loop that runs on a fixed timestep, typically sixty times a second, with rendering happening whenever the browser is ready to paint. Each step does the same sequence:

1. Read input. Not raw events — logical actions. The game asks "is the jump action held?", not "was the space bar pressed?", so keyboard and touch behave identically.
2. Advance the player. Apply acceleration, gravity, friction, whatever this game's movement model is.
3. Advance the world. Scroll the camera, stream in new content, move patrolling hazards along their cycles.
4. Test collections. For every collectible near the player, check whether it has been picked up.
5. Test collisions. For every hazard near the player, check whether it has been hit.
6. Update score and state. Apply the streak rule, tick power-up timers, check win and lose conditions.
7. Update feedback. Spawn particles, floating numbers, sounds; push changed values to the HUD.

The fixed timestep matters more than it sounds. If the simulation advanced by whatever time had elapsed since the last frame, a player on a 144Hz monitor would get different physics from a player on a 60Hz one, and a momentary stall would teleport the character through a wall. Running a fixed step and catching up over several steps when necessary keeps everyone playing the same game.

Collection detection and why it is generous

Collection is a distance test. For a player at (px, py) with radius pr, and a gem at (gx, gy) with radius gr, the gem is collected when the distance between the centres is less than pr + gr + forgiveness.

That last term is the interesting one. On this site it is between four and nine pixels depending on the game, and it exists because of a specific design problem: a collection game spends its entire runtime asking you to move toward things, often things near hazards. If the pickup test were pixel-exact, a run that looked successful would frequently fail, and the game would feel arbitrary rather than tight.

The forgiveness is asymmetric on purpose. Collection is generous; hazard collision is the opposite — deadly hits are tested against a box inset by a few pixels, so a near miss that looks survivable is survivable. Together these two adjustments produce a game that feels fair in both directions without changing anything a player can see.

Distance tests are also cheap, which matters. A busy frame might have sixty collectibles on screen. Comparing squared distances (avoiding the square root entirely) keeps that test comfortably inside the frame budget even on a modest phone.

How collectibles get where they are

Collectibles are never scattered at random. They are produced by pattern functions, each of which takes an origin point and a handful of parameters and emits a shape:

• Line — evenly spaced along a direction. The simplest instruction: come this way.
• Arc — swept around a radius. Almost always drawn on a jump curve.
• Wave — a sine path. Says "hold this line while it moves".
• Zig-zag — alternating heights. Forces repeated small corrections.
• Vee — a dip or a peak. Marks a single moment of commitment.
• Cluster — a random spread inside a radius. Says "there is slack here".
• Ring — a circle. Rewards passing through cleanly in one arc.
• Grid — rows and columns. Used where a sweep can cover an area.
• Trail — points along an arbitrary path function. The most expressive: any curve you can write.

These shapes are then assembled into chunks — self-contained segments of level with their own ground, hazards and collectibles — and streamed in ahead of the player. Each chunk is generated from a hand-designed template with randomised parameters rather than from raw noise, because pure noise reliably produces the two worst outcomes in level generation: arrangements that are impossible, and arrangements that mean nothing.

The difficulty curve feeds into template selection. Early in a run, only the gentle templates are eligible. As the curve rises, harder templates join the pool and the parameters within each template tighten. That is how a game gets harder without ever generating something unfair.

The streak rule and what it is for

The streak rule is the most misunderstood part of the genre, so it is worth being explicit about what problem it solves.

Imagine a collection game with no streak rule. Each gem is worth its face value, full stop. What is the optimal strategy? Take every gem that costs you nothing, and route around every gem that involves risk or a detour. There is no reason to do anything else. The game becomes a series of free pickups punctuated by conservative avoidance, and every interesting decision the level designer built has been optimised away.

Now add the rule: consecutive collections raise a multiplier, and any miss resets it. Suddenly skipping a cluster is not free. It costs you the multiplier you have been building, which might be worth more than the cluster itself. The player has to weigh those against each other continuously, which is exactly the decision the design wanted.

The implementation on this site: every five gems collected in a row raises the multiplier by one, to a ceiling of five. Points for a gem equal its base value times the multiplier active at the moment of pickup. A miss — a gem leaving the play area uncollected — or an unshielded hit sends it back to one.

Two details are worth noting. The ceiling exists so that an exceptional chain does not produce an unapproachable score; without it, scoring becomes a function of one lucky run rather than of consistent play. And the multiplier applies at the moment of pickup rather than at the end of the run, which means the order you collect things in genuinely matters — the same twenty gems are worth wildly different totals depending on whether they were one chain or four.

Hazard cycles and telegraphing

A hazard has two jobs: to make position expensive, and to be learnable. The second is the one that separates good design from bad.

Static hazards — spikes, walls, barriers — are learnable trivially. You see them, you avoid them. The interesting cases are the timed and moving ones.

Patrolling hazards move along a fixed axis over a fixed range at a fixed speed, following a sine function. That means a single cycle contains all the information about the hazard's future behaviour. A player who watches one cycle knows everything; a player who does not is guessing. This is why "watch one cycle before you commit" is the most transferable advice in the genre.

Timed hazards — beams, gates — run on a period with a duty cycle. A beam with a period of 2.2 seconds and a duty of 0.45 is dangerous for about a second, then safe for about 1.2 seconds, forever. Crucially there is a warning phase before it fires. Because the period is fixed rather than random, counting the rhythm is more reliable than reacting to it, and at higher speeds counting is the only thing that works at all.

The rule underneath all of this: nothing spawns on top of the player. Everything enters from beyond the edge of the play area and travels into view. If something killed you, it was visible first, and the failure was yours to learn from.

Power-ups as temporary rule changes

A power-up that adds points is a bonus. A power-up that changes how you collect is a design tool, and the difference shows up immediately in how players behave.

Consider the magnet. It widens the radius within which gems are pulled toward you — on this site, by 170 pixels for eight seconds. Mechanically that is one number. Practically, it rewrites the routing problem for the duration: clusters that were not worth a detour now are, a line you would have half-collected is now fully collectible, and a gap in a ribbon that would have broken your chain no longer does. The player's decisions change, which is far more interesting than their score simply going up.

The same logic applies to the others. A shield does not add points; it lets you take a route you would otherwise refuse. A multiplier does not add points directly; it makes a dense cluster suddenly worth reaching for. A speed boost covers more ground but shortens every reaction window. A vacuum removes the routing problem entirely for five seconds, which is a real luxury precisely because it is so brief.

The feedback loop that makes it feel good

Collecting a gem triggers four things simultaneously, and the redundancy is deliberate.

A sound, pitched to your current streak. On this site each consecutive gem plays a slightly higher note, so a long chain is audibly a rising scale. Audio arrives faster than a visual change registers, which is why sound genuinely helps at high speed and why "turn the sound on" is real advice rather than a preference.

A particle burst in the gem's colour. Short, hard-capped and reduced when the player has asked for less motion. Its job is to mark the position where something happened so your eye does not need to track the gem itself.

A floating number showing exactly what you earned, including the multiplier. This is the honesty mechanism: a player should never have to guess why their score moved. When a multiplier steps up, a second, larger label announces it.

A HUD change, with a brief scale animation on the value that changed. The HUD sits above the canvas rather than on it, so it never obscures play and never has to compete with the action for attention.

Four channels for one event sounds excessive until you watch someone play at full speed. At 700 pixels per second, any single channel can be missed. Together, they make the cause-and-effect unmissable, and that unmissable loop is most of what makes collecting feel satisfying rather than merely scoring.

What the game remembers

The last system is the smallest and the one players interact with least directly: persistence.

At the end of a run the game produces a snapshot — score, gems, best streak, distance, time, level — and merges it into the records stored for that game, keeping only the improvements. It also increments a play count, appends to a recent-play log and updates site-wide totals.

All of that lives in the browser's local storage, which means it is readable only by this site, in this browser, on this device, and never travels anywhere. That has an obvious cost — clear your site data and it is gone, with no server-side backup — and a real benefit: there is no account to create, nothing to log into, and no score of yours sitting on anyone's server. It is also why every number on this site is labelled a local best rather than a ranking. We have no basis for a ranking, so we do not pretend to one.

If you want the detail on how that storage behaves, when it fails and why a game should never assume it works, how browser arcade games track high scores covers it properly.

Frequently asked questions