What a collectible is

Stripped to essentials, a collectible in an arcade game is a small record: a position, a size, a value, a type, and a flag for whether it has been collected. Everything else - animation, magnetism, orbit, risk marking - is an optional extra on top of those five fields.

The actual shape of one

Our collectibles carry: x and y position, width and height, a radius, a kind (one of nine types), a value from one to five, a magnetizable flag, a hazard flag, an animation phase, a bob amplitude, and optional fields for orbit, velocity, risk multiplier and hidden state.

Most instances use about half of those. A candy drop in a platformer uses position, size, kind, value and bob amplitude, and leaves the rest at defaults.

The reason to keep the record small is quantity. A busy collection game has dozens on screen and churns through hundreds per minute, so every field costs memory and every allocation costs a small amount of garbage-collection pressure later.

Pooling, and why it matters on phones

Creating a fresh object for every collectible and discarding it on collection produces a steady stream of garbage. On a desktop this is invisible. On a mid-range phone it produces periodic stutter as the collector runs, which in a timing-sensitive game is worse than a slightly lower frame rate.

The fix is a pool: keep discarded objects in a free list and reuse them instead of allocating. Our pool holds up to 256 spare entities, which is comfortably more than any game here needs on screen at once. Collection marks an entity dead, a sweep at the end of each frame compacts the active list and returns dead entries to the free list.

This is invisible when it works and obvious when it does not, which makes it easy to skip during development on a fast machine.

Advertising keeps Candy Arcade free. Ads never cover gameplay or controls.

Values and the hierarchy

Each type has a base value from one to five, and those values are identical across all thirty games. The specific numbers matter less than the consistency: a player who learns in one game that sugar crystals are worth a detour arrives at the next already knowing how to read it.

TypeValueSilhouette
Candy drop1Circle with a lighter core
Gummy2Rounded block with a highlight band
Marshmallow2Soft rounded rectangle, two-tone
Lollipop3Swirled disc on a stick
Chocolate3Scored rectangle
Ice cream3Scoops on a cone
Cupcake4Fluted base with domed frosting
Donut4Ring with an icing arc
Sugar crystal5Six-pointed star with a glow

The value is then multiplied by the game's base scale, your combo tier, any active power-up multiplier and any situational bonus. A gummy is never worth two points; it is worth two times whatever the rest of your state says.

Why silhouette matters more than colour

Every type has a distinct outline, and that is not decoration. Roughly one in twelve men has some form of colour vision deficiency, so a game that distinguishes collectibles from hazards by colour alone is unplayable for a meaningful share of its audience.

There is a second reason that applies to everyone: at twelve pixels across and moving quickly, colour is much harder to resolve than shape. A six-pointed star reads as different from a circle at sizes where distinguishing two mid-saturation hues is unreliable.

Our bitter drop - the universal hazard marker - is the clearest case. It is a spiky seven-pointed shape in a matte desaturated green, where all candy is glossy and saturated. It differs in shape, in finish and in palette family, so it remains identifiable in greyscale, at small size, and at speed.

Drawing rather than loading

Every collectible on this site is drawn with canvas path operations at runtime rather than loaded as an image. There are no sprite sheets anywhere in the project.

  • No decode time and no loading state.
  • No texture memory and no resolution variants to ship.
  • Sharp at any size and any device pixel ratio, including at 3x.
  • Colours can be varied per instance for free, so the same routine produces a whole palette family.
  • No licensing questions, because nothing was sourced from anywhere.

The cost is CPU per frame, and at the visual complexity an arcade game needs that is an easy trade. A lollipop is a filled circle, three arc wedges and a stroked outline: about a dozen path operations, several thousand times cheaper than the frame budget.

Collection detection

Collection is an overlap test between the player's box and each collectible's box, padded outward by a few units. The padding is deliberate: at speed, a near miss that the player believed connected feels like a bug, and there is no upside to precision on collection.

For very fast movers - falling candy at high belt speed, a projectile in the cannon game - a simple per-frame overlap test can tunnel straight through a target between frames. Those cases use a swept test instead, sampling along the path from the previous position to the current one, which costs a few extra comparisons and removes a whole class of missed pickups.

The asymmetry is worth stating: collection hitboxes are padded outward and hazard hitboxes are inset. Both errors are in the player's favour, and nobody has ever noticed either one.

Animation, and the smallest one that matters

Most collectibles bob: a small vertical sine-wave oscillation of a few pixels, with a per-instance phase offset so a row does not move in lockstep.

This exists for one reason. A static object on a canvas can read as scenery, and a few pixels of movement makes it unambiguously interactive. It costs one line of code and removes a real category of confusion, which is about the best return available anywhere in game presentation.

Higher-value types get more: sugar crystals rotate and pulse a glow, which is how the most valuable item in the game announces itself without needing a label. Risk-marked collectibles get a pulsing ring, which turns a dangerous placement from a trap into an explicit offer.

Common mistakes

  • Allocating a new object per collectibleProduces garbage-collection stutter on phones, which is invisible during desktop development.
  • Distinguishing types by colour aloneFails for colour-blind players and fails for everyone at small sizes and high speed.
  • Using precise hitboxes for collectionA near miss the player thought connected reads as a bug. Pad outward.
  • Per-frame overlap tests for fast moversA collectible moving further than its own size in one frame can be tunnelled straight through. Use a swept test.
  • Leaving collectibles completely staticThey read as scenery. A few pixels of bob is enough to fix it.

Practical tips

  • Learn the nine silhouettes; they are consistent across all thirty games.
  • Bitter drops are matte, spiky and desaturated - the one universal 'do not touch' on the site.
  • A pulsing ring means risk candy: worth more, placed somewhere uncomfortable, offered rather than hidden.
  • A glowing rotating star is a sugar crystal, the most valuable collectible and the most exposed.
  • Bobbing means collectible and static means scenery, everywhere here.

Key takeaways

  • A collectible is a position, a size, a value, a type and a collected flag; everything else is optional.
  • Pooling prevents garbage-collection stutter that only shows up on phones.
  • Values one to five are identical across all games, so knowledge transfers.
  • Silhouette beats colour for legibility at small size, at speed and for colour-blind players.
  • Drawing from code removes decode time, texture memory and resolution variants.
  • Collection hitboxes are padded and hazard hitboxes are inset - both errors favour the player.

Frequently Asked Questions

What is a collectible in game code?

A small record holding a position, a size, a value, a type and a collected flag. Animation, magnetism and risk marking are optional extras on top.

Why do all the candy types have different shapes?

Because colour alone fails for colour-blind players and fails for everyone at twelve pixels and high speed. Shape resolves reliably where hue does not.

Are the collectibles images or drawings?

Drawings. Every one is drawn with canvas path operations at runtime, so there are no sprite sheets, no decode time and no blurriness at any resolution.

Why are collection hitboxes bigger than they look?

Because a near miss the player believed connected feels like a bug, and there is no upside to precision on collection. Hazard hitboxes are inset for the same reason, in the other direction.

Why do collectibles bob up and down?

To make them unambiguously interactive rather than scenery. It costs one line of code and removes a genuine source of confusion.