Of the nine collectible pattern shapes, the trail is the one that does the most work for the least code. It is also the one most often built badly, because the function is trivial and the parameters are not.

Why trails work

A trail is the clearest instruction a collection game can give: follow this line and you will be rewarded for every second you manage it.

Compare it with a cluster. A cluster says "come to this region", which the player satisfies in an instant and then leaves. A trail is a sustained relationship — you are either on it or off it, continuously, for several seconds.

That produces two useful effects.

Trails build multipliers fast. Our runner trails are fourteen gems, which on its own takes a player from zero to a three-times multiplier. Two consecutive trails reach the five-times ceiling. That is the fastest multiplier ramp available, and it is why trail-based games are the right place to teach a new player what a sustained chain feels like.

Trails teach line-holding. A player following a trail is practising exactly the habit that raises scores everywhere else: reading a shape a second ahead and committing to it rather than reacting gem by gem.

Forest Gem Trail is built almost entirely from them for both reasons.

The path function

The implementation is a function from a normalised position along the trail to a world position:

field.pattern('trail', startX, baseY, {
  count: 14,
  type: 'crystal',
  path: function (t) {          // t runs 0 to 1
    return {
      x: startX + t * 620,
      y: baseY + Math.sin(t * Math.PI * 2) * amplitude
    };
  }
});

That is the whole mechanism. Everything expressive about trails comes from what you put in the function:

  • Sine — a smooth wave. The default, and the easiest to follow.
  • Sine with rising baseline — a wave that climbs, which pulls a player upward as they follow it.
  • Damped sine — a wave that flattens, useful for leading into a precise landing.
  • Arc — a single parabola, effectively a long jump drawn out.
  • Spiral — for games with full two-dimensional movement.
  • A recorded path — the route a moving object took, which produces trails that feel authored.

Amplitude, frequency and length

Three parameters decide whether a trail reads as a route or as noise.

Amplitude — how far the trail deviates from its baseline. This must fit inside what the player's movement can cover. In a jumping game the vertical amplitude has to fit within a jump arc, because a trail that goes higher than the player can jump is a trail that breaks itself. In a flyer, amplitude can span most of the screen, because vertical control is continuous.

Our forest trails use 50 to 110 pixels of amplitude against a jump that reaches around 150. That leaves margin for the player to be imperfect.

Frequency — how many oscillations the trail contains. This is the parameter most often set too high. A curve that changes direction faster than the player's movement model can respond is uncollectable no matter how generous the amplitude is. When a trail feels wrong, lower the frequency before touching anything else.

One to two and a half full cycles over the length of a trail is usually right. Beyond three, it stops reading as a line and starts reading as a zig-zag, which is a different pattern with a different meaning.

Length — how many collectibles and how far they span. Long enough to matter, short enough to end. Fourteen gems over about 620 pixels works well at our runner speeds: roughly two seconds of following, which is long enough to feel like a commitment and short enough that failing one does not feel like losing the run.

Spacing from speed

Spacing along a trail should be derived rather than chosen:

spacing = player speed × desired interval between pickups

A desired interval of 0.1 to 0.15 seconds keeps a chain feeling continuous without blurring individual pickups. At 400 pixels per second that gives 40 to 60 pixels.

Two things follow.

Spacing must scale with the difficulty curve. A trail spaced for 300 pixels per second, encountered at 700, delivers a pickup every 0.07 seconds — a blur rather than a chain. Either scale the spacing with speed, or use different trail parameters late in a run.

Spacing should be measured along the path, not along the axis. A sine trail measured by x-spacing bunches at the steep parts of the curve and spreads at the flat parts. For gentle curves the difference is small enough to ignore; for aggressive ones it is visible and worth correcting.

Matching the movement model

The same trail is a completely different problem for different movement models, and this is where most trail design goes wrong.

A jumping character cannot follow a continuous curve at all — it moves in arcs. A trail for a jumper should have its peaks where jump apexes fall, so that following it means making a series of correct jumps. Amplitude fits inside one jump; frequency matches the jump rhythm.

A flying character can follow a genuine curve. Amplitude can be large, frequency can be higher, and the trail can be a real path rather than an implied one.

A rolling character follows a curve but with momentum, so the trail must account for the fact that it cannot change direction quickly. Rolling Gem Quest uses 74-pixel spacing on its mid-chamber waves, tuned to a sphere at cruising speed — and the same wave at 42 pixels would be uncollectable without stopping, which is exactly what the game is designed to discourage.

The test is simple and worth running: can the player's movement model actually trace this curve? If not, the trail is decoration, and decoration that looks like an instruction is worse than no instruction at all.

Trail mistakes

Too high a frequency. The most common failure. The curve oscillates faster than the player can, and the trail becomes a series of near misses.

Amplitude beyond the movement range. A trail that goes where the player cannot follow breaks itself halfway through, which is worse than a shorter trail.

Spacing chosen by eye. Derive it from speed. A trail that looks right paused is frequently wrong in motion.

Trails everywhere. A trail is a sustained commitment and needs contrast around it. A level made entirely of trails has no moments of slack, and the player never gets to reposition or reassess.

Ignoring hazards. A trail that passes through a hazard is not a trail, it is a trap. If a hazard intersects the path, either move the hazard or break the trail cleanly around it — a trail with a deliberate gap reads as a choice, while one that runs into a cutter reads as a bug.

Key takeaways

  • A trail is a continuous instruction: follow this and you are rewarded for every second you manage it.
  • Any path function works — the craft is choosing amplitude and frequency the player's movement can actually follow.
  • Spacing comes from speed multiplied by the interval you want between pickups, typically 0.1 to 0.15 seconds.
  • A trail must match the movement model; a jumper and a flyer cannot follow the same curve.

Frequently asked questions

What is a gem trail?

A continuous line of collectibles placed along a path function rather than scattered. It is the most expressive pattern shape, because any curve you can express becomes a pattern.

How long should a trail be?

Long enough to matter. Our runner trails are thirteen or fourteen gems, which alone takes a player from zero to a three-times multiplier — the point at which following it feels worth doing.

How do I choose the amplitude?

From what the player can follow. In a jumping game the amplitude must fit inside a jump arc; in a flying game it can span most of the screen because vertical control is continuous.

Why do my trails feel uncollectable?

Usually the frequency is too high for the movement model — the curve changes direction faster than the player can. Lower the frequency before lowering the amplitude.

Put it into practice

Reading about collection routes only gets you so far. Pick a game and try one idea from this guide on your next run.

Written by Alex Morgan

Browser Games Editor & Interactive Gaming Content Specialist

Alex Morgan has spent more than eight years working with browser gaming content — writing about arcade mechanics, testing HTML5 games across devices, and breaking down why some collection systems feel satisfying while others feel hollow. Alex builds the test plan for every game we publish and writes the guides that explain the scoring underneath them.

Last reviewed on 16 August 2026.

Author profile · Editorial policy · Fact-checking policy