Dice Merge

The problem

The app already had a physics-backed dice stack, a set of polyhedral meshes, and a corner tray where dice sit and can be flicked. The question was whether any of that could carry an actual game, and a fruit-drop puzzle is the cleanest test: it is nothing but contact resolution, a growth ladder, and a fail state.

The catch is that a fruit-drop game is built around circles in two dimensions. Circles are rotationally symmetric, so orientation is free. Dice are neither, and a d20 that lands on a vertex is not the same object as a d20 that lands on a face.

Three decisions that made it a different world

1. Size had to become meaningful

Every die in the codebase is normalised to the same circumradius, 0.85 world units, so a d4 and a d20 read as one matched set on a table. That is correct everywhere else in the product and exactly wrong here. The entire read of a fruit-drop game is that the thing you are climbing toward is visibly bigger than what you started with.

So the ladder grows about 1.2 times per rung, from a small d4 to a d100 roughly three times its radius, and each rung scales its collider along with its mesh. Getting only one of those right produces dice that overlap or dice that float, and both look like a bug rather than a game.

2. The camera had to stand up

The corner fidget tray uses a near-overhead camera, because dice there spread across a floor. A pile growing toward a line has to be seen from the side, so this stands up its own straight-on orthographic view. Same scene builder, different projection.

3. Two dimensions in translation, three in rotation

Every die has its Z translation locked, so the pile stays exactly one die deep and nothing ever drifts behind anything else. Rotation stays completely free, which sounds like the matching half of the same decision and is not.

Contact, and why there is no impact threshold

In the corner fidget tray, two dice of the same kind touching is nothing. Here it is the whole game, which inverts a rule the existing dice code had already settled.

The merge deliberately has no impact threshold. Two dice resting quietly against each other combine, because a player who nudges a d8 into another d8 and watches nothing happen has been told the game is broken. Contacts accrue over frames instead of firing on a single collision event, which keeps a jittering solver from producing a merge the player did not intend, and a pending-progress read drives the visual feedback while the pair is still deciding.

The top of the ladder is the percentile die: a d10 body wearing the 00 to 90 tens labels, which is what a physical d100 actually is. Two of them do not combine into anything. They sit in the jar taking up room, and that accumulating dead space is the pressure that eventually ends the run.

Keeping the rules out of the renderer

The entire rule set lives in a module that imports nothing from React, Three.js, or Rapier. The chain, the points per rung, the sizes, the spawn weighting, the combo multiplier, and the best-score storage are all pure functions over plain data.

That split is why the game has a test suite at all. A Node test can import the rules directly and assert that the ladder terminates, that a d20 pays ten and the last step doubles, and that spawn weighting stays inside its bounds, none of which needs a browser or a canvas. The component that needs a physics world and a renderer is then only the part that genuinely needs one.

• Route-level isolation. Its own route, no campaign row, no store reads, guests welcome, device-local persistence. Same shape as the first quick game.
• Zero shared-bundle cost. The match component is dynamically imported with server rendering off, so the game and the 3D stack behind it add nothing to the bundle every other page pays for.
• A colour per rung. The ladder is colour-coded along the bottom of the board, so the thing you are working toward is legible without counting sides.