Cheery Chimp

A 1983 game with one very strange idea: you steer the character, but not the camera — and the camera is trying to kill you.

Splat Chimp is built on a mechanic borrowed from Splat!, written by Ian Andrew and Ian Morgan and published by Incentive Software of Reading in 1983 for the ZX Spectrum. In the original you control Zippy, an X-shaped sprite in a top-down maze, and the thing that makes it unlike anything else is that the view scrolls on its own — randomly left, right, up or down, faster as the levels go on. Touch the edge of the window and you are dead. So is touching the water, or the spikes.

There are collectibles too: plums and clumps of grass, and some of them are never on screen when you would like them to be. (It also said "Yippee!" out loud when you finished a level, which in 1983 on a Spectrum was close to witchcraft.)

I wanted that mechanic in a chimp suit, so: coconuts instead of plums, spiders patrolling, water you cannot cross, and a window that will not stay still.

Why the scroll is the whole game

Most games give you a camera that follows you. This one gives you a camera with opinions, and the walls of the world are wherever it happens to be looking.

That single inversion produces a tension nothing else quite reproduces. You are not only solving the maze, you are managing your position inside a moving frame — staying near the middle when you can afford to, gambling on a dash to the edge when there is something worth having out there, and doing mental arithmetic about how long you can stay out on a limb before the window lurches and squashes you against its own border.

It also means the player and the level are never negotiating directly. There is a third party in the room, and it is indifferent.

Twelve out of twenty

And then I played it, properly, for a while, and kept getting stuck on twelve coconuts out of twenty.

Not because the last eight were hard to reach. Because I never saw them. A camera that picks a direction at random does a poor job of visiting a playfield: it wanders, doubles back on itself, and spends most of its life in the middle, which is exactly where you have already been. The corners barely get looked at. The original had the same property, and got away with it partly because it was a survival game first and a collection game second.

Mine was leaning on collection, which made "you cannot finish because the camera never went there" a design fault rather than a quirk. The player is doing everything right and failing anyway, which is the one kind of difficulty worth removing.

Biased locally, fair globally

The obvious fix is to make the scroll head for the coconuts. It is also the wrong one, because a camera that visibly hunts your objectives stops being an antagonist and starts being an assistant, and the tension I described above goes with it.

What it does instead is subtler and, I think, better. The scroll picks a wandering target — somewhere in the world to drift toward — and then biases its direction choice four to one toward directions that make progress. Not a straight line to the target: a drunkard's walk with a slight preference. And the targets themselves are chosen near the edges of the camera's range about two thirds of the time, because that is where the camera reveals tiles it has not shown before.

Neither of those things knows where the coconuts are. It just stops the camera loitering in the middle of a field it has already shown you.

The effect, measured rather than assumed: about a quarter more visits to coconut tiles than before. And the property that makes it acceptable — over a couple of thousand scrolls the directions still come out very nearly uniform. The bias is local. Globally it cancels, because the targets eventually point everywhere. The camera has not become predictable; it has just stopped being pointlessly repetitive.

Determinism survived too, which matters because there is a daily run — the same world for everybody on a given date. A scroll that consulted the world state to decide where to go would be much harder to keep reproducible. This one consults only its own seeded stream.

Measuring instead of guessing

None of the previous section would be worth writing if I had judged it by feel, because "it seems better now" is what everybody says about the change they just made.

So there are small scripts that run the systems headlessly, thousands of times, and print numbers: how much of the playfield the scroll reveals over a given number of moves; how the direction choices actually distribute; whether the spiders' patrol really does ping-pong the way the code claims. They are not tests in the pass-or-fail sense. They are instruments, and the reason they earn their place is that every one of them has at some point told me a thing I believed was wrong.

A button that had to stop being a game object

The end-of-run screen has a share button, which copies your result to the clipboard. It did nothing, on some devices, sometimes.

Two separate causes, stacked, which is why it took a while.

The first was inside the game framework: the full-screen background behind the results panel was itself interactive, and it was swallowing the press before it reached the button drawn on top of it. Ordinary z-order confusion, easy to fix once seen.

The second was not fixable that way at all. The clipboard API requires a genuine user activation — a real click from a real element — and a callback fired by a game engine's own input system does not always qualify. Browsers are strict about this, and strictest exactly where it hurt: on mobile, and inside an iframe.

So the share button is not a game object any more. It is a real HTML <button>, positioned over the canvas, handling a real DOM click. That solves both problems at once, and it is a good reminder that a canvas game is a rectangle on a web page rather than a world unto itself. When the platform demands a real element, it means it.

Three beeps, always

Each run starts with a countdown — beeps timed to a grace period before the maze comes alive.

The beeps were generated to fill the grace period, which sounds sensible and produced a bug you could hear: practice mode has a longer grace period than the other modes, so practice got four beeps while everything else got three. Nobody would fail to notice that, and I did, for a while.

The fix was not to scale the beeps more cleverly. It was to stop scaling them: always three, moved to the end of the longer grace period, so the rhythm immediately before the start is identical everywhere and the extra time is simply silence at the front. A countdown is a promise about when the thing begins. It should sound the same every time regardless of how long you have been waiting.

The pause that would not let go

One more worth recording. The menu button stopped working — but only sometimes, and only after certain sequences.

Pausing set a flag. Various transitions cleared it. One of them did not, so the game could arrive at a screen already believing it was paused, and the input that should have taken you to the menu was being swallowed by a pause handler for a pause that was no longer visible.

The fix was to stop having many places that each remember to clear it, and have one that always does: a single function for going to the menu, which clears the flag first and transitions second. Any bug whose description includes "only after certain sequences" is usually a piece of state that several paths are each responsible for tidying up, and the answer is almost always to reduce the number of paths rather than to fix the one you found.

Three small things I would do again

Haptics only where they exist. The buzz on collecting a coconut is a nice touch on a phone and meaningless on a laptop. The toggle for it is only shown on devices that actually support vibration — a setting that does nothing is worse than no setting, because it makes the player wonder whether their phone is broken.

A check instead of a fallback. The game needs hardware-accelerated graphics. It used to quietly fall back to software rendering, where it ran badly enough to look broken. It now checks up front and shows a clear explanation instead. A degraded experience that looks like a bug is worse than an honest refusal.

Debug instruments that are not shipped. The on-screen developer statistics are behind a build-time flag, so they are removed from the production bundle entirely rather than hidden at runtime. Nobody downloads them, and there is no chance of a keystroke revealing them to a player.

Credit where it is due

There is a file in the repository crediting the 1983 original, its authors and its publisher, and I would encourage anyone building on an old idea to write one.

The mechanic here is not mine. What is mine is a chimp, some spiders, a daily seed, and a camera that has learned to wander somewhere useful. The idea that the window itself can kill you belongs to two people in Reading in 1983, and it was good enough that it is still interesting forty-odd years later — which is more than most mechanics invented since can claim.