Melon Cascade Tips: Stack Fruit and Reach the Watermelon (2026)

1. Aim a column, not a gap

The jar is 240 px wide and the held fruit is a preview, not a physics body: it touches nothing until you drop it. Aiming moves the centre of the held fruit, and clampAim keeps the fruit's edge 2 px inside the wall, so the widest fruit (watermelon, radius 62) can only be centred between 184 and 296. That means the last few tiers cannot be dropped at the extreme sides at all; plan the late game around the columns you can still reach.

A drop leaves the held fruit with a downward velocity of 5 and the next fruit does not spawn for 320 ms. Use that window to read where the pile landed instead of queuing the next tap. The NEXT panel shows the fruit after the one you are holding, so you always know two drops ahead.

2. Build two stacks and keep a channel open

The pile grows upward and the danger line sits at y = 70, only 38 px below the drop height. A single tall column in the middle reaches the danger line fastest, because every new fruit lands on top of it. Split the jar into two working columns near the left and right walls and keep a vertical channel between them: the channel is where a fruit can fall all the way to the ground when one side is full, and it is also where the largest fruit has room to settle without pushing a neighbour over the line.

Avoid dropping the same tier twice in a row into the same spot. Two matching fruits merge as soon as they touch, so a second identical fruit placed on top of the first becomes the next tier immediately and the column height jumps by a whole radius step. If you want height, drop different tiers; if you want to score, drop matching tiers deliberately into a gap where both can move.

3. Merge math: small merges early, big merges late

Merging tier n scores (n + 1) x (n + 2) / 2 points, so the ladder runs 1, 3, 6, 10, 15, 21, 28, 36, 45, 55 and a pair of watermelons cancels for 100. The big numbers only appear at the top, and reaching the top costs eleven merges in a single chain. Early play is therefore about clearing small fruits to make room, not about chasing score: a cherry-to-strawberry merge is worth 1 point but it removes a body from the jar and frees a slot.

The first watermelon you create triggers the win event, but the run does not stop there. Treat that moment as a milestone, not a finish: the jar is now carrying the largest body it can hold, and every further drop has to fit around it.

4. Two watermelons cancel, so do not merge them by accident

When two watermelons touch they do not become a thirteenth tier. They cancel each other and add 100 points, which is the single largest score in the game and the reason to keep two watermelons in the jar at once. The catch is geometry: two radius-62 bodies occupy most of the 240 px jar, so they have to be on opposite sides with a clear path between them, and both have to be resting before the merge guard (100 ms) and the collision check can fire.

A watermelon that is still sliding after a drop carries sideways velocity, and the jar walls are deliberately frictionless, so it can roll a long way. Wait for it to settle before you drop the second one, or you will create a watermelon that drifts into the other one at the wrong angle and pushes a neighbour over the danger line.

5. Read the guards, do not fight them

Three timers decide when things count, and all three come from the build:

• A freshly merged fruit cannot merge again for 100 ms (MERGE_GUARD_MS). If two matching fruits touch and nothing happens, wait; the pair is being held and the merge will fire on the next collision pass. Do not drop a third fruit on top to "help" — it usually creates a worse pile.
• A freshly dropped fruit is not considered "resting" for 900 ms (REST_GUARD_MS). A fruit that crosses the danger line during those 900 ms does not end the run, because the game only checks fruit that has stopped moving. This is why a drop that bounces near the top is not automatically game over.
• Drops are limited to one every 320 ms (DROP_COOLDOWN_MS). The build enforces this with a timeout, so mashing the button does not speed up play.

The physics step also caps vertical speed at 9 px per frame (TERMINAL_VY) and applies rolling resistance every frame (horizontal velocity x0.93, angular velocity x0.9). Fruit therefore stops quickly on the floor but keeps a little sideways drift, which is why a pile can creep sideways even after you stop dropping.

6. The danger line is not the end of the jar

Game over fires only when a resting fruit's top edge is below y = 70 and its speed is under 0.35 px per frame. The warning line is at y = 92 and turns the dashed line red when any non-held fruit's top edge is above it. Between those two lines you are in the danger zone: a fruit that is still moving fast enough (speed above 0.6) is ignored, but the moment it settles the run ends.

So the practical rule is: stop dropping when the pile's highest point is around the warning line, and use the 900 ms rest guard to let a borderline fruit settle before you decide. The game over screen reads "No room left" and offers Play again, which clears every fruit, resets score and queue, and fires the restart event.

7. Drill specific situations with the URL parameters

The build accepts two query parameters, both verified in the shipped code:

• ?seed=123 pins the random sequence, so the same drop order repeats every load. Use it to practise a layout you could not solve, or to compare two strategies on identical fruit.
• ?tier=0..10 forces every drop to that tier. ?tier=0 drills cherry stacking and small merges; ?tier=9 drills placing melons next to each other without overflowing. An out-of-range value is ignored and the normal random pool is used.

The seed is a 32-bit unsigned integer drawn through the build's own generator, and the drop pool is [0, 0, 0, 1, 1, 2], so even with no seed the first fruit is a cherry three times out of six.

FAQ

How is this different from the rules on the game page?

The game page explains how to operate: move the pointer or drag on a touchscreen to aim, tap or click to drop, use the left and right arrows or A and D to move the aim 12 px, Space/Enter/down arrow to drop, and click Play again on the game over screen. This guide assumes you know that and plays the layer above it: which column to build, when to merge, how the two-watermelon cancel works, what the three guards do, and when the danger line actually ends the run.

Why did two matching fruits touch and not merge?

The merge guard blocks a fruit from merging within 100 ms of being created, and the build registers both collisionStart and collisionActive, so the pair is re-offered every physics step until the guard expires. Wait a fraction of a second. If they still do not merge, one of them is probably still inside its 900 ms rest window or has a speed above the threshold the danger check uses; either way, dropping a third fruit on top makes it worse.

Can the run end even if nothing looks over the line?

Only when a resting fruit's top edge is below y = 70 with speed under 0.35. A fruit that is still bouncing or sliding is ignored, and a fruit dropped less than 900 ms ago is not checked at all. So the screen can look full while the game waits for the pile to settle, and then end suddenly. That is the intended reading of the warning line at y = 92: treat it as the last moment to stop dropping.

What does the NEXT panel actually show?

The queue holds two tiers: the one you are about to drop and the next one. When a fruit spawns, the first tier is removed from the queue and the second becomes the preview. The drop pool is three cherries, two strawberries and one grape, so the preview is always one of those three tiers.

Is there a way to practice without the random drops?

Yes. Use ?seed= to replay a sequence, or ?tier= to force every drop to one tier. Both are read from the URL by the build itself; an invalid value is ignored. Your best score is stored only in this browser under pn_melon_cascade_best, and the page publishes no average score or comparison with other players.

Where can I play it?

Right on this site's Melon Cascade page. The mechanic — drop fruit into a jar and merge two matching fruits into the next tier up to a watermelon — is sold under a registered brand name elsewhere, so this build is written from scratch by Playnesta with no byte-reused game files: the tier table, jar geometry, merge rule, danger line, HUD, input handling and renderer (melon_cascade.js), the stylesheet (cascade_style.css), the analytics bridge and the touch shim are all Playnesta-original (MIT, see LICENSE.txt in the package). The only upstream code shipped is the physics engine matter-js 0.19.0 (MIT, commit 07aec9ff5ed7e09da6106c73587716d7a1165125), vendored byte-identical as vendor/matter.min.js (sha256 bdf68e297d6c4ec85b8dd693b8781d99db0090449c9a3ba69948eede08c9275a) with its licence at vendor/matter.LICENSE.txt; it supplies rigid-body physics only, no rendering, no input and no game logic. Every fruit is drawn at runtime from canvas primitives plus a system emoji glyph, so no bitmap, icon font, audio or webfont is shipped or fetched, and no runtime request leaves the page. Playnesta Games is the developer and publisher of this web implementation.