How the AI plays its own game: the star bot behind the clips

July 2026 · growordie · behind the scenes

To promote a game like growordie on TikTok you need a steady drip of spectacular gameplay: clean kills, breathless near-misses, a big snake going out in a blaze. The honest problem is that I cannot sit at the keyboard and record eighty of those on demand. Great runs are rare, and the great moments inside them are rarer, maybe one in three minutes if I am playing well. So I did the only thing that scales: I taught a small program to play my own game well enough to film itself.

This is the story of that program, the "star bot". It is not a mysterious AI. It is a couple hundred lines of geometry that reason with the exact same formulas the server uses, look a second into the future, and pick the prettiest survivable line. Then a separate pipeline watches the recording, finds the good bits, and cuts them into ready-to-post clips. I will be very clear about what it is and, just as importantly, what it is not.

• 01 The problem: spectacle on tap
• 02 A bot that plays by the real rules
• 03 Sixteen arcs, scored every 55ms
• 04 The cut-off: setting a trap at boost speed
• 05 From a 3-minute run to a 10-second clip
• 06 The honest part: it is a camera, not a scoreboard

01 · Spectacle on tap

A good gameplay clip is a tiny piece of theatre. It wants a setup, a spike of danger, and a payoff, all inside about ten seconds, and it wants the camera roughly centered on the action the whole time. Filmed by hand, that is a grind. I would play for ten minutes to catch one usable kill, fumble the recording, clip it wrong, and start over. Multiply by the dozens of clips a channel burns through in a week and it is simply not a thing one person does by hand.

So the job splits cleanly in two. First, something has to generate the gameplay: play credible, camera-friendly runs, over and over, without me. Second, something has to edit: watch each run, find the two or three best seconds, and cut a clip. The star bot is the first half. The pipeline is the second. What follows is faithful to the actual code that produced the current batch of eighty-one clips.

02 · A bot that plays by the real rules

The temptation with a "self-playing" demo is to let it cheat: teleport, ignore walls, phase through bodies. That would look fake instantly, and it would produce footage that a real player could never reproduce. So the star bot gets no special powers. It runs in an ordinary browser tab, sees only what a human client sees, and presses the same three inputs anyone has: turn left, turn right, boost. Everything else it works out from the same physics the server enforces.

Those physics are three small formulas, and the bot mirrors them line for line so its predictions match reality. Bigger snakes are fatter, and fatter snakes turn slower, which is the single most important fact in the whole game:

radius   = clamp(len / 7, 2, 80)              // fatter as you grow
turnRate = clamp(11.25 / radius, 0.9, 4.5)    // rad/s, slower when fat
speed    = 110 * (1 + min(0.45, (len-14) * 0.01))

Read that middle line twice, because it is the source of every trap the bot sets. A small snake pivots almost on the spot. A giant one steers like an oil tanker. So when the bot looks at a big opponent, it knows that opponent physically cannot swerve fast, and it can plan a line the target has no time to escape. When the bot looks at itself, the same formula tells it exactly how sharp a turn it is allowed to attempt before its own commands stop mattering.

To know what is dangerous, the bot needs to know where every lethal body point is, cheaply, every tick. It builds the same structure the server uses: a spatial hash, a flat grid of cells that files each body point under the cell it sits in, so a "what is near my head?" question only ever scans a local handful of points instead of the whole arena. (That grid has its own write-up; here it is just the eyes.) It rebuilds that grid roughly every 55 milliseconds, tags points that belong to a snake's own harmless neck so it does not flinch at itself, and even marks the traversable gaps in a body as low-cost rather than lethal. From that it has a map of the near future: where the walls are, and, crucially, where the moving walls are about to be.

03 · Sixteen arcs, scored every 55ms

Here is the core loop, and it is pleasingly dumb. Every plan tick the bot fans out about sixteen candidate headings, from "hold your line" through gentle nudges to a full reversal, and it simulates each one forward for roughly a second using the real turn-rate limit and the real speed. Each imagined path collects a cost as it goes: it pays a little for how far it swung, a lot for grazing a body, a fortune for hitting one, extra for drifting into the cold rim of the shrinking arena, and a special toll for crossing where an enemy head is about to be. The cheapest survivable arc wins, and the bot steers toward it. That is the whole brain.

Two things make the picture above more than a wander-and-avoid. The first is that enemy heads are not treated as points but as trails about to happen. The bot estimates each rival head's velocity and, for every step of its own simulated arc, checks whether it would be crossing the segment that head is going to sweep. Crossing behind a head is death; crossing ahead of it, before the head arrives, is free. That single distinction is the root of the whole hunting game, because "cross just ahead of them" is exactly how you make someone run into you.

The second is that the bot has two moods. Early in a life it is in farm mode: it hugs the warm, crowded center where growth flows, takes only easy kills, and mostly just gets big, because in growordie size is the score and a bigger snake is both a scarier hunter and a better-looking one on camera. Once it is large enough it flips to hunt mode and starts committing to real traps. The switch matters for the footage: a clip of a tiny snake nibbling is boring, a clip of a fat one springing an ambush is not.

04 · The cut-off: setting a trap at boost speed

The signature move, the one that produces most of the good clips, is the cut-off. You do not chase a snake from behind; you can never catch a head that way. Instead you aim for a point just past its nose, arrive there a beat before it does, and let your own body become the wall it plows into. It is a lead-the-target problem, the same math as passing a football, and the bot solves it every tick while a hunt is live.

Two details keep this from being a boost-spamming mess. The bot only commits the boost after re-simulating the boosted arc itself and confirming it is clean, no point in flooring it into a wall to reach a kill. And it runs the throttle on hysteresis: the gates to start a boost are strict (aligned, in range, a real interception on the table), but once it is boosting the gates to keep going relax. That is deliberate. A boost that flickers on and off for single ticks is invisible on camera and wastes the length it costs you. A boost held through the whole approach reads as a decisive, committed strike, which is the thing worth filming.

05 · From a 3-minute run to a 10-second clip

The bot generates the performances; a separate pipeline is the editor. A standalone browser driver picks a fresh, database-verified snake name, joins a live game, injects the bot, and records the canvas at 60 frames a second for three minutes. Alongside the video it keeps an event log: a timestamped list of everything interesting the run witnessed, a kill, a dense cluster of explosions, a needle threaded through a gap, a near-miss, and the exact instant the run ended. The video is the footage; the log is the script notes that say where to look.

The whole thing is built to be left alone. It resumes if it is killed, never re-records a run it already has, rotates to a fresh browser before memory bloat can crash one, and backs off politely if the live server is having a slow moment. The measured numbers from the tuning runs are what I actually shipped against:

That 83% is the number I care about most. It means the bot is not just surviving and bumping into the occasional kill; it is deliberately setting the trap I designed it to set, and doing it often enough that most of the footage is the good move rather than luck. And it plans a full second of sixteen simulated futures in about a fifth of a millisecond, so it never stutters the tab it is being filmed in.

06 · It is a camera, not a scoreboard

Here is the part I want to be completely straight about, because it is what makes the rest of this honest rather than sneaky. The star bot is a content generator. Its entire job is to produce footage for clips. It is a stunt performer I point a camera at, nothing more.

So it never counts as a player. It does not appear on the leaderboard. It does not touch, inflate, or fake any of the real human numbers I report about the game, not the records, not the play stats, none of it. When it joins a game to film a run it plays under the same rules as everyone, earns its kills the same hard way, and dies the same permanent death, but the moment I care about happens afterward, in the edit. The bot exists to make ten good seconds worth watching, and then to get out of the way.

I think that distinction is worth stating plainly because "AI plays the game" can mean a lot of shady things, and this is the boring, honest version of it: a program that is good enough at my own game to be its own camera operator, so that a channel can post real, reproducible growordie moments every day without me grinding for them. Everything it does on screen, a human could do. It just does not get tired, and it never fumbles the record button.

If you want to see the machine it is playing inside, the collision math and the netcode that make those cut-offs actually resolve, the animated engine tour pulls it all apart. Or you can go do it yourself, by hand, with the record button firmly your own problem: grow or die.

Made solo, in Node.js, probably at 2am · growordie