Snake, Before It Needed a Reason to Exist

No sky rails, no passengers, no robobirds — just a snake, a grid, and a pellet that makes it grow every time it eats one. This is the plain, honest version of the oldest arcade format there is, and I built it exactly that straightforward on purpose. Sometimes the right move with a classic format is proving you can implement it cleanly before deciding whether it deserves a reskin, a twist, or anything else layered on top.

Grid movement is simple until you hit input buffering

Snake's movement looks trivial — the snake advances one grid cell per tick in whatever direction it's currently facing — and the part that actually needed care is handling rapid direction changes between ticks. A player pressing down then left in quick succession, both before the next tick actually processes, has a clear intent, but a naive implementation that only tracks the single most recent keypress can drop the first input entirely or, worse, let a player reverse directly into their own body because the two rapid inputs got collapsed into one. I built a small input queue that holds onto a short sequence of pending direction changes and applies them one tick at a time, rather than overwriting the current direction on every keypress, specifically to respect fast, deliberate input instead of losing it to timing.

Self-collision needed a precise definition of "too late"

The game ends when the snake's head enters a cell already occupied by its own body, and the exact moment that check happens matters more than it sounds like it should. Check too early in the tick's update cycle, before the tail has moved out of the cell it's vacating, and a perfectly legal move where the head follows directly behind where the tail just was gets incorrectly flagged as a collision. Check too late, after the snake has already visually overlapped itself on screen, and the game feels like it's cheating the player out of a save that should have counted. Getting the order of operations right — move the tail first, then check the head's new position against the body's new state — was a small but easy detail to get backwards, and getting it backwards would have made basic, correct play feel randomly unfair.

Pellet placement can't ever be impossible to reach

Randomly placing the next pellet needs one guarantee that's easy to overlook: it can never spawn on a cell the snake's body currently occupies. That sounds obvious, but as the snake grows longer and occupies more of the grid, the pool of genuinely open cells shrinks, and a naive "pick any random cell" approach starts wasting more and more attempts re-rolling onto occupied space the longer a run goes. I built pellet placement to sample only from the actual set of currently open cells rather than retrying random guesses against the full grid, which keeps placement instant regardless of how long the snake has grown, instead of quietly slowing down exactly when a run is at its longest and most exciting.

Speed had to increase without breaking the input queue

Tick speed increases as the snake grows, which is the classic way this format escalates difficulty, and it interacts directly with the input queue I mentioned earlier. A queue depth that feels perfectly responsive at a slow starting tick rate can feel laggy and unresponsive once the tick rate speeds up significantly, because the same queue depth now represents a much shorter real-world time window. I ended up tying the queue's effective responsiveness to the current tick rate rather than using one fixed queue size throughout a run, so input handling feels consistent whether the snake is crawling at the start of a run or racing near the end of a long one.

Touch controls needed their own honest interpretation of "direction"

A keyboard gives you four discrete direction keys, which maps naturally onto grid movement. A touch swipe is continuous and imprecise by comparison, and translating a swipe gesture into one of four grid directions means picking a threshold for how much a swipe has to deviate from perfectly horizontal or vertical before it counts as a diagonal-leaning swipe versus a clean cardinal direction. Too strict a threshold and slightly imprecise swipes register as the wrong direction constantly; too loose and the game feels unresponsive to genuinely intended diagonal-ish swipes that should clearly resolve to one direction. I tuned this by swiping on my own phone dozens of times until the threshold stopped feeling like it was fighting my thumb.

Why I'm not calling this finished

This is about as complete a Snake implementation as the format needs, and I mean that as a genuine statement rather than a hedge. There's nothing else the core loop is missing. Whether it stays exactly this plain, or whether it eventually earns a visual theme and some new mechanics layered carefully on top of what's already a correct foundation, isn't something I've decided yet. For today, getting the fundamentals — movement, collision, pellet placement, escalating speed — completely right felt like the actual job, with any reskin decision left for whenever there's a real reason to make it rather than because a plain snake game feels like it needs an excuse to exist.

There's a small irony in spending this much of a devlog post on a game this simple, and I think that's exactly the point worth making. The format is ancient and the rules fit in two sentences, and it still took real, deliberate attention to input queuing, collision timing, and pellet placement to make it feel right rather than just technically functional. Simple formats don't get a pass on care just because they're simple, and a plain implementation done carefully is worth more than an elaborate one built on a foundation nobody bothered to get right first. That's a lesson worth keeping in mind for whatever this game eventually becomes, reskinned or otherwise, since none of that future work matters if the foundation underneath it isn't solid today.