Slingshot: The Game Boy Puzzler Where Collapse Is the Answer

GB Slingshot: The Game Boy Puzzle Where the Collapse Is the Answer

There is a moment in every good physics puzzle where you stop looking at the target and start looking at the thing holding it up. The level has been telling you the answer all along, and you have spent two shots hitting the wrong part of it.

GB Slingshot is built almost entirely out of that moment. It is a slingshot game for the original Game Boy: choose an angle, choose a power, fire, and bring the structure down before your shots run out. Fifty hand-built levels, four projectile types, star ratings saved to the cartridge. But what makes it more than a toy is how rarely the direct shot is the right one.

The arc goes through everything

The first thing you notice is the dotted arc, and the first thing worth knowing is that it is not an approximation. The preview replays the same flight function the real ball flies, so it cannot drift from the shot it is predicting.

The second thing you notice is that the arc does not know the level exists. It sails straight through towers, walls and targets as though the board were empty. That is deliberate — it is the clean trajectory, not a forecast. What happens when the ball meets the first piece of stone is your problem, and the shot will stop or slow there depending on what it hit.

Up and down set the angle from 5° to 80° in 5° steps; left and right set the power through eight steps. That sounds coarse, and for the first level or two it feels it. Then you notice the levels are built around exactly those steps, and the coarseness stops being a limitation and starts being the puzzle.

Materials, damage and cracks

Every cell is one of four materials, plus the ground, and each behaves differently:

Damage is decided by speed, so where in the flight the ball arrives matters as much as what it arrives at. A shot that has already punched through a wall turns up weaker than one that took a clean line.

The rule that gives the whole game its grammar is this: a hit that destroys a cell lets the ball carry on, a quarter slower, while a hit that only damages it stops the shot dead. Stone shrugs off half of what hits it. Ice shatters easily. And a damaged cell stays visibly cracked, so a chipped wall is a wall that one more solid impact will open.

The collapse is the game

After every shot, the board checks itself from the bottom up. A cell with nothing underneath falls a row. A cell with a solid neighbour on both sides can bridge the gap and stay put until one of those supports goes. A cell that falls two or more rows damages whatever it lands on and takes damage itself, a stack that falls together does not hurt itself, and a fall of three or more rows destroys a target outright.

That last rule is the one to keep in mind on every level. Targets are often too tough or too well covered to hit directly, but the tower above them is not. Break the keystone, let gravity do the work, and the level solves itself.

It also pays. Anything destroyed by a collapse scores double, and the HUD slides up for a moment to show the chain's value — free points that did not cost you a shot.

Four projectiles, one press each

Press B before firing and you cycle through four types. Every one of them flies like the standard shot; the difference is a single ability you can spend with a second A press while the ball is in the air.

Eighteen levels declare the type they are built around, and the level select shows NEEDS B or NEEDS C before you go in. The game's tests go further than the label: they brute-force every angle, power and type on those levels to prove that no standard shot wins them outright, and that the declared type does. The label is a fact, not a hint.

The budgets are measured, not guessed

Fifty levels, each a plain-text ASCII grid with a shot budget attached. The budgets were not eyeballed: a brute-force solver plays every level over every angle, power and projectile, and prints the minimum number of shots any search can win in. Most levels are set to that number plus one.

The result is a curve with almost no slack in it. Twenty-nine levels run on two shots, twenty on three, and one needs four. Finish a level with shots to spare and you get the stars for it — and restarting costs nothing, so a two-shot plan is always worth one more attempt.

Your best rating for each level is written to battery-backed cartridge RAM when you press START on the win splash. It survives a reset, and it is there the next time you boot the cart.

One honest gap

There is no in-game music. The sound effects are real — hits, breaks, collapses and screen shake all land — but they are one-shots written straight to the sound hardware, and there is no track running underneath them.

It is the one place where the game feels like a build in progress rather than a finished thing. Everything else about it is deliberate to the point of stubbornness, and the silence stands out precisely because nothing else does.

The border is a launch rig at dusk

On a Super Game Boy the screen sits inside a 256×224 border: a launch rig at dusk, framed in wood, with the game's name across a purple sky. It costs about 6 KB of the cartridge and it is generated, like the tiles, by a Python script.

The clever part is the transfer. The Game Boy copies the border into video memory, draws it in a known order, and the Super Game Boy reads the picture back — a round trip with its own test that compares the bytes the SGB receives against the generated tile data. On a plain Game Boy everything behind that check is skipped and the game boots exactly as it would have.

Under the hood

C and GBDK-2020, no engine, on a single 32 KB image with battery-backed RAM for the stars.

The simulation is one header file with no hardware calls in it at all, which is what lets the same code run under gcc on a desktop and SDCC on the Game Boy. The front end reads the pad, ticks the simulation, and draws the result. There is no floating point and no 32-bit arithmetic anywhere in the logic: positions are whole pixels plus a separate 8-bit fraction, because a 16-bit 8.8 value cannot hold 160 px.

The war story from the build is a compiler one. SDCC's Game Boy backend compiles a comparison and leaves a scratch register holding the difference rather than the field, while still believing it holds the field. Reuse that value and you get nonsense, and nothing in the C source shows it. It silently broke the win and lose splashes and the aim preview. The fix is a rule — a field compared more than once must be volatile — and there is a scan in the build that checks the generated assembly for the bug.

Testing runs in two layers. Host-side tests make more than 1,400 assertions and include a golden replay whose hash pins the outcome of three fixed shots. The emulator test then presses the same buttons on the real ROM in PyBoy and compares the grid hash, which is what catches a divergence between the desktop compiler and the Game Boy one. It also checks the level select, the HUD, both splashes, the falling sprites, the chain flash and the battery save across two sessions. For a slingshot game, that is a serious amount of paranoia, and it is why the rules above can be stated as facts.

How to play it

It runs in your browser on the hardware it was written for, with nothing to install: play GB Slingshot.

Click the screen to give the emulator keyboard focus. Arrow keys aim, X fires, Z cycles the projectile, Enter is START and C is SELECT. On the level screen, START restarts the level or loads the next one after a win, and SELECT takes you back to the level select.

Start with the direct shot if you like. Everyone does. Then look at what is holding the target up.

Fifty levels, and the last one took four shots to solve. We want to know how many it takes you — and whether you ever fired a shot that was not aimed at anything at all.