Unicorn Sugarworld

Post-mortem

Five games in a month without writing the code

Jesse Rogers · js13kGames 2026 · unicornsugarworld.com

What this is

Between 13 August and 13 September 2026 I made five games for js13kGames, a competition where every entry must fit in 13,312 bytes when zipped. The theme was Unicorns and Rainbows. The five games tell one story, in order, about a one-winged unicorn named Athena and a spider named Anansi who knows what is buried under her people's palace.

I did not write the code. I am not a coder, a writer, or an artist, and I did not pretend to be one for this project. I directed. An AI partner wrote every line, drew every shape, and composed every note. My job was deciding what each game was, what it should feel like, which ideas were wrong, and whether the result was good enough to put in front of strangers. If you use AI tools and you have wondered whether that job is real, this page is my answer.

Anything in bold is defined in the glossary at the end.

Models used for research, drafting, editing, and verification: Claude Fable 5.1, Claude Opus 5. The games were built across many sessions, usually dozens of conversations. That's too long and winding to share, so I asked Claude to generate this post mortem as its summary.

The numbers

GameWhat it isZipped size
Rainbow TilesTile puzzle with a small deck of tricks12,847 B
SugarwindDune-surfing arcade game, one minute per level11,993 B
Looking UpA negotiation with a spider, played in cards12,021 B
Unicorn ApocalypseRail game in a raymarched desert, plays in VR13,236 B
DeathballPhysics game about rolling a cage through a tomb11,876 B

Sizes are from my build script, packed with Roadroller, and the submitted zips may differ by a few bytes. The limit is 13,312. The largest entry finished with 76 bytes to spare, which is not a margin I would recommend, and the reason is in the bytes section below. Every one of these runs on a phone. One of them runs in a headset I do not own.

Who did what

The honest split changed during the month, and the change is the most useful thing I learned.

At the start I planned to write specs: documents describing each game's creative and technical decisions, which a cheaper model would then build. I wrote two of those. They were good documents. Then the model that wrote the specs read the existing code, said it was cleaner than expected, and offered to build the game itself instead of handing it off. I said yes, and from that point the work went faster and the results got better. The specs turned out to be worth writing anyway, because they forced me to make the decisions before anyone touched code, but the handoff step was waste.

What I actually did, every day:

What I did not do: write code, draw, compose, or tune numbers. When the model told me the ripe window on a drain was 0.55 seconds, I did not have an opinion about whether that was right. I had an opinion about whether the game felt right when I played it, which is a different thing, and it is the thing a director is for.

Story first

The single decision that made the batch work was made half awake on a Sunday morning, and it was about story, not technology.

Game four was supposed to be Athena flying home to defend her people from a swarm of bees. It was already built. It looked wonderful and played like a tech demo, because a rail game needs the sky full of targets and the story gave no reason for the sky to be full of anything. Then I realised who the enemy should be: unicorns. And who the player should be: the thing buried under the tombs, the thing that ate every unicorn that could not fly. The ones with strong wings escaped, and their descendants are Athena's people. The ones who stayed learned a lullaby and sealed it in.

That flip solved three problems at once. The sky could fill with unicorns because they were the enemy. The game had a reason to exist in a competition where every other entry would have a unicorn protagonist. And it gave the series its meaning: a seductive darkness that a society can suppress with norms and institutions but never destroy, and a princess who learns that her ancestors were the ones who ran.

The mechanic followed from the story. You do not shoot unicorns. You drain their colour, and if you let go at the moment they turn grey, they turn around and fly beside you. Hold too long and they break. That gave the game the one decision it had been missing, and it is on theme in a way a fifth kind of hornet could never be. The best design work of the month was a story note.

What went wrong

Looking Up, version three

The negotiation game had the best writing in the batch and nobody could get anything out of it. I asked for feedback from a second model instance, which guessed it would land somewhere between 40th and 80th and said the gameplay was the ceiling. It was right.

Version three had seven secrets, a mood system with three colour channels you had to push separately, a three-day clock, and an "audit" card you needed to hold at the same moment the mood was right and two keywords were paired. I had approved every one of those systems, one at a time, across several sessions. Together they were unplayable in the two minutes a judge gives you. Worse, the spider had picked up traits I never wanted: a stated age of nine hundred years, three thousand years of history, ninety-nine unicorns eaten before you. When I complained about hallucinated lore, the model traced each one back to something I had said in an earlier session and let it stand. It was not inventing. It was remembering me too well.

The rebuild replaced the colour channels with a ring of nine named moods. Every card names the mood it walks him toward, and the ring is drawn on screen as nine dots with him and the target marked. The audit card became a standing button. The three days became one. The first three topics he drifts to are fixed so every player reaches the first secret without luck. And after he speaks, nothing is playable until you tap the word he let slip, with Athena saying "he said something I should remember." That last one is the tap gate, and it did more for onboarding than any instruction text.

The lesson under the lesson

Every system in version three was reasonable on the day I approved it. Complexity does not arrive as a bad decision. It arrives as ten good ones that were never played together. The fix was not a better model. It was a rule: after any build, play it as a stranger with thirty seconds of patience, and if the first objective is not clear by then, cut a system.

Fighting for bytes

Unicorn Apocalypse started its rebuild at 18,260 bytes zipped. The limit is 13,312. The engine underneath it, a raymarched desert with a real angular rainbow in the sky, was worth keeping, so the five thousand bytes had to come from everywhere else.

The order things went, and what each cost:

  1. A build script that stripped comments and whitespace out of the shaders, renamed every shader variable to two letters, ran minification on the JavaScript, and folded the page's CSS and markup into the script so Roadroller could pack the whole thing as one stream. That alone found about four thousand bytes.
  2. Sound effects rewritten so five one-shot noises share one function with different numbers. This is data-driven design from the book, applied to audio.
  3. A second beam, a reticle, glittering sugar on the dunes, the spiral on the lollipop trees, per-explosion colours, speed surges on the rail, three volume sliders down to one. Each cut was small. Together they were the last thousand bytes.

Two things worth knowing if you try this. First, cuts should come from features nobody would miss in a two-minute play, never from the feel. The hit stop, screen shake, and haptics stayed to the end. Second, Roadroller is not free. It compresses harder than a zip, but the packed file is slow to load and impossible to read, so the readable file and the shipping file have to be separate, and the byte count you steer by has to come from the build script, not from looking at the file.

Accessibility as an edge

Judges play hundreds of entries in a few weeks, on whatever hardware they have. Most entries give them nothing to notice about comfort. All five of these do, and it was a deliberate choice rather than a courtesy.

None of this cost more than a few hundred bytes. All of it went in the entry descriptions, because a judge who does not know it is there cannot score it.

Testing without a browser

The model that built these could not open a browser. It could run code, but not look at it. That sounds like a fatal problem for game development and it turned out to be a solvable one.

For the conversation game, it loaded the page into jsdom, a fake browser that runs in a terminal, stubbed out the sound and drawing so they would not crash, and wrote a scripted player: a few lines that tap whatever pulses, pick the card labelled "closer," and ask when the mood is right. Then it ran that player through the game and printed every turn. That is how we know a player who follows the hints takes the first secret on turn three or four, rather than hoping they do. When the first run showed the tutorial firing on turn eight instead of turn three, the fix was one condition, found in a minute, that a hundred manual playtests might have missed.

For the statues in Deathball, which I had said were the weak art, it rendered the drawing code with node-canvas into an image, looked at the image, and redrew. Three passes: the first was a blob, the second was a slug with a horn, the third was a rearing warhorse in plate barding. I saw the previews before I saw the game.

My phone was still the only real playtest, and it caught things nothing else did: statue silhouettes, flute notches that were too faint to see, contrast that passed on a monitor and failed on glass in daylight. The scripted tests found logic bugs. Screenshots found taste.

VR without a headset

Unicorn Apocalypse is a WebXR entry and I have never worn a headset. The model built the VR path from the projection matrices the headset provides: each eye gets a slightly different, off-centre view, and the rail game's camera had to derive that offset per eye rather than assume a symmetric one. The right controller is the horn. The trigger drains, the squeeze makes the flock scream, and the screen shake that works on a flat screen is replaced by controller haptics, because shaking a headset user's whole world is a good way to end their session.

It has been tested in a browser emulator and not on hardware. The plan is a tester from the js13kGames Discord before the deadline. If you are reading this after judging, the results section says whether that plan worked.

What I would tell you

  1. Decide the story before the mechanics. My best technical result came from a story note.
  2. Write the spec even if you will not hand it off. It makes you decide.
  3. Ask for options with a recommendation, and let the recommendation stand when you have nothing to add. Silence was a valid answer more often than I expected.
  4. Play as a stranger with thirty seconds of patience, and cut systems until the first objective survives that.
  5. Send screenshots. A picture of the wrong thing is a better instruction than a paragraph about it.
  6. Say no to things that look fine. The statues looked fine. The notches looked fine. Fine is the enemy.
  7. Keep the readable file and the shipping file apart, and steer by the number from the build script.
  8. Get the model to test what it can test without you: scripted playthroughs, rendered previews, byte counts. Save your own time for taste.

Results

To be filled in after judging closes. Placement per entry, category mentions if any, whether the VR entry ran on hardware, and the honest comparison against the second model's guess of "40th to 80th" for Looking Up.

Glossary

Terms marked with a star are the standard vocabulary of this competition and carry their usual meanings. The rest are particular to this project.

Analytic intersection
Working out exactly where a ray meets a simple shape (a sphere, an ellipsoid) with a formula instead of stepping toward it. The unicorns in Apocalypse are built from a few of these, so they are cheap and correct in both eyes.
Asymmetric projection
A camera view that is not centred on the eye. VR headsets use one per eye. The game derives the offset from the projection matrix the headset provides rather than guessing.
Build script
A small program that turns the readable game file into the shipping file: strips, minifies, packs, zips, and prints the byte count.
Chromatic aberration ★
Separating the red and blue channels slightly, suggesting a camera lens.
Comfort vignette
A darkening at the edges of the view that closes in when motion is intense, to reduce motion sickness.
Data-driven design ★
Behaviour defined by a table of numbers rather than by separate code for each case. The three unicorn factions and the five sound effects are tables.
Deflate ★
The compression method used by zip files. Rewards repetition, punishes randomness.
Drain window
The short moment after a unicorn turns grey when releasing converts it. Hold past it and it breaks. The one decision the whole rail game runs on.
Dynamic resolution
Rendering at a lower resolution when frames take too long, then scaling up. Insurance for judges on weak hardware.
Fractal noise (fbm) ★
Several layers of noise at different scales added together, producing detail at every distance. The dunes.
Fragment shader ★
A program deciding the colour of each pixel. The whole desert is one of these.
Haptics
Controller vibration. Replaces screen shake in VR.
Hit stop ★
Briefly freezing the game on impact to convey weight.
jsdom
A fake browser that runs in a terminal, used to run a game's logic without a screen.
Juice ★
Small feedback effects that make actions feel good.
Karplus-Strong
A way of making a plucked-string sound from a short burst of noise fed back through a delay. Every bell, flute, and pluck in these games is this, in a few lines.
Luminance cap
A ceiling on how bright any pixel can get, applied in the final pass, so no frame can flash dangerously.
Minification ★
Automatically shortening code by removing spaces and renaming variables. Happens at build time, never by hand.
Mood ring
Looking Up's model of Anansi: nine named moods arranged in a circle by emotional closeness. Every card moves him one step.
node-canvas
A drawing library that runs in a terminal, used to render a game's shapes to an image so they can be checked without a browser.
Noise ★
In graphics, smoothly varying randomness. In audio, the sound of all frequencies at once.
Octave ★
One layer of a fractal noise stack.
Palette ★
A small named list of colours that everything refers to. Each game in the series has one, and the title screens share a structure while the palettes differ.
Post-processing ★
A shader applied to the finished image. The vignette, the aberration, the luminance cap, and the fade to white all live there.
Procedural generation ★
Producing content from a formula instead of storing it. Nothing in these games is stored.
Ray marching ★
Finding what a pixel sees by stepping along a line through a mathematically described space. Beautiful, expensive. The desert.
Roadroller ★
A JavaScript packer built for this competition that compresses harder than a zip alone, at a cost in loading time.
Scripted player
A few lines of code that play a game by simple rules, so a whole run can be checked in seconds.
Screen shake ★
Offsetting the view by a few random pixels, decaying over a fraction of a second.
Seeded RNG ★
A random number generator that produces the same sequence every time from the same starting number. Not used in this batch; it is here because the book leans on it and you will want it for anything with levels worth sharing.
Shader ★
A small program that runs on the graphics card.
Signed distance function
A formula that says how far a point is from a surface, and whether it is inside or outside. Ray marching steps by that distance. The terrain is one.
Silhouette ★
An object's outline shape. What players read first, and what generated art most often gets wrong. The statues were rebuilt three times for this reason.
Spec
A document of creative and technical decisions written before code. Worth writing even when nobody else reads it.
Sphere tracing ★
The safe-stepping method that makes ray marching practical, using distance to decide step size.
Stereo panning
Placing a sound left or right by where it happens on screen. Cheap, and it makes a small game feel spatial.
Tap gate
An onboarding device: nothing else is playable until the player taps the thing they need to learn about. Looking Up uses it on every keyword.
Twelve-pulse timeline
A twelve-slot rhythm grid shared by three of the games. Slots fill as the player progresses, so the music grows with the state of play instead of looping under it.
Typewriter reveal
Showing text a few characters at a time. Used for both speakers in Looking Up, at different speeds, so they read as different voices.
Vignette ★
Darkening toward the edges of the screen.
WCAG
The Web Content Accessibility Guidelines. Level AA is the usual bar; AAA asks for higher contrast, roughly 7 to 1 between text and background.
Web Audio API ★
The browser's built-in sound synthesis system.
WebXR
The browser's built-in support for headsets and controllers. A page can ask for a VR session, and if the device says yes, draw one view per eye.