Slipspire

A small game with a very personal beginning

My wife is head over heels for small, self-contained games: the kind you can understand quickly, play in a spare moment, and still find surprisingly hard to put down. I wanted to make one for her.

The idea reached further back, too. As a kid I loved the frozen-floor and ice-gym puzzles in the Pokémon games I grew up with—FireRed, LeafGreen, Sapphire, Emerald, and Diamond. You chose a direction, committed to it, and kept sliding until the environment stopped you. A tiny rule turned a small room into something you had to read, plan, and mentally rehearse.

That mechanic stayed with me. It is one of the reasons game design fascinated me, and game design was the original reason I found my way into computer science.

Slipspire is my attempt to recover that feeling in an original, compact puzzle game designed around a phone. It is inspired by the broader ice-sliding puzzle tradition, not a recreation of a Pokémon map, character, world, or story. The levels, name, visual identity, mascot, progression, and supporting systems are Slipspire’s own.

The rule I wanted to preserve

The core interaction is deliberately small: choose one of four directions and commit to the glide. The character continues over ice until a wall, crystal, boundary, or another mechanic changes the result. Reaching the goal ends the move immediately.

The interesting part is not steering while moving. It is recognising where you can stop.

That makes every crystal useful in two different ways: it may block the direct route, but it may also be exactly the brake needed to line up the next one. Good courses ask the player to move away from the goal, find a better stopping point, and construct a route one landing at a time.

On mobile, that maps naturally to a swipe. A confident drag previews the route and stopping point before release; blocked directions show that they will fail; and optional direction buttons provide another way to play.

A development-renderer capture of the first course: preview the stopping point, commit to the swipe, then clear the course. The static gameplay image is shown when reduced motion is preferred.

A creative reset after Communiti Labs

Slipspire arrived at a very particular moment. After winding down Communiti Labs and taking time off, I wanted to stretch parts of my imagination that had spent years behind product strategy, customer work, fundraising, and company-building.

I did not want the next thing I made to begin with a market map. I wanted to follow curiosity, obsess over how a rule feels, and make something joyful simply because I could imagine it.

Building a game has given me that space. I can move between puzzle design, interaction, illustration, animation, sound, progression, and the small details that make a tap or collision feel satisfying. It has been a reminder that software can be expressive—not only useful.

The current Home destination establishes the frozen-spire world while keeping the next action immediate.

The 12-course Foundation Campaign teaches the base movement vocabulary before the preview chapters add new rules.

Where the build is now

Slipspire is currently a playable, unreleased 0.2.0-dev build in Godot. The first shipping boundary is a 12-course Foundation Campaign that grows from a one-move introduction to longer boards with deceptive lines and 15-move target routes.

The surrounding product loop is in place: Home, chapter and course selection, gameplay, completion, settings, hints, undo, restart, progression, local saves, and three medals for clearing, matching the target, and completing a clean attempt without undo or reset.

Behind that release-sized campaign is a separate developer-preview curriculum. Six chapters contain 33 more courses exploring Powder that stops a slide, one-way ridges, turning currents, movable blocks, fragile ice, pressure and persistent switches, gates, runes, goal seals, and optional post-clear Whiteout.

Those chapters are useful for discovering what Slipspire could become. They are deliberately kept out of the first release path until playtesting shows which mechanics are legible, enjoyable, and worth carrying forward.

White Horizon is the twelfth Foundation course: a larger board built entirely from the base ice-and-stopping-point vocabulary.

Completion makes three different kinds of mastery visible without turning the small game into a live service.

Designing a mechanic ladder, not a bag of tricks

Adding mechanics is easy. Teaching them without losing the game’s identity is harder.

The preview curriculum therefore follows a ladder. A chapter begins with one unfamiliar rule in a small, readable course. Later courses ask the player to combine it with already-understood geometry. Capstones can bring two established ideas together, but the goal is never to maximise the number of symbols on the board.

The full game state is deterministic. Player position, blocks, fractures, switches, gates, runes, and the goal requirements are resolved in the model before animation presents the outcome. The same rules drive play, preview, undo, failure, validation, and the breadth-first solver used to verify every recorded target route.

That separation lets me experiment with presentation without quietly changing the puzzle. It also lets an offline level factory generate and rank candidates, while keeping publication a human decision. A solver can prove that a course is possible; it cannot prove that the course is understandable or fun.

Powder changes the stopping rule: entering it ends the current glide, creating a softer and more flexible kind of brake.

Clockwork Vault combines the preview system’s pressure plates, switches, gates, runes, and sealed goal in one compact capstone.

Using AI to explore a world I could not have drawn alone

AI-generated imagery has widened the creative surface area of this project. I have used it to explore environments, board materials, sprites, mechanic states, interface textures, chapter concepts, mascot poses, and the application icon.

The useful work is not accepting the first attractive image. It is directing a coherent visual language, preserving the mascot’s identity, rejecting details that imply the wrong gameplay rule, processing assets for runtime use, and keeping text, state, routes, focus, motion, and accessibility in live code.

One early ice texture, for example, looked beautiful but contained a fracture network that could be mistaken for breakable ice. I rejected it and directed a new surface without cracks or route-like lines. In a puzzle, decoration cannot be allowed to lie about the rules.

The repository records the prompts, selected versions, runtime roles, and retired prototypes. AI helps me reach visual territory I could not have produced by hand at this pace; art direction, game semantics, implementation, and the decision about what belongs remain deliberate parts of the craft.

A generated Powder chapter concept helped establish the scale, palette, and sense of ascent for the wider world.

The current generated icon preserves the same mascot and palette in a silhouette designed to remain readable at launcher size.

Not in the App Store—yet

The current build is substantial, but it is not a released mobile game. An iOS developer-preview project and Foundation-only release path are prepared, while signing, installation on physical devices, touch and safe-area validation, unfamiliar-player sessions, final support and privacy URLs, and store submission still remain.

Android is part of the eventual ambition, but the present release work is intentionally focused on proving one mobile path first. The screenshots and animation on this page come from the real Godot Mobile renderer; they are development captures, not evidence that those remaining device and store gates are complete.

There is therefore no App Store or Google Play link to share yet. For now, the source, development history, release boundary, tests, and art provenance live in the Slipspire GitHub repository.

Why this project matters to me

Slipspire is small by design, but it has reconnected several parts of me that had drifted apart: the kid sketching game mechanics, the student who chose computer science because software could create worlds, the engineer who wants rules to be testable, and the founder learning how to make again after a company chapter ended.

I began with a mechanic I remembered fondly and a game I wanted my wife to enjoy. What has grown around it is a reminder of why I started building software in the first place: imagination can become something another person can touch, understand, and play.