Introducing Star Trail

5 October 2026

Star Trail is The Oregon Trail in space. You're the captain of a small ship a very long way from home. You have to get back across three sections of space, one jump at a time. Each section is bigger than the one before. You start in a corner and head for the gate on the far side.

Every square on the star chart holds something. It might be pirates, a derelict worth stripping for scrap, a trading outpost, a planet with a settlement looking for crew, or a black hole that might throw you somewhere you didn't plan to go. You're managing fuel, hull, scrap and morale the whole way. Usually you run out of fuel. Sometimes you run out of crew.

It's also an experiment. I didn't write the code for Star Trail. I vibe coded all of it.

What "vibe coded" means here

I directed the game in plain English with Claude Code, an AI coding agent, and it wrote the code. I said what I wanted, played the result, and said what felt wrong. I made the decisions about what the game should be. I didn't type the TypeScript.

The first commit landed on the morning of 3 October. The version you can play now is from the evening of 5 October. In between:

92 commits
About 22,600 lines of TypeScript, plus about 4,700 lines of tests
378 automated tests, all passing
25 encounters out in space and 120 crew events aboard the ship
A web build, plus iOS and Android builds that ship to TestFlight and Google Play internal testing on every push

I'm not giving you those numbers to brag. They're the point of the experiment. I wanted to find out how far one person can get with an agent doing the typing, and how it holds up when the game gets complicated.

How it came together

Day one was about the look. We started with a blank Vite + three.js project locked to portrait for phones. Then we ported two open-source generators I love. One was a procedural spaceship generator, so every ship in the game is built from a seed. The other was a pixel-art planet renderer. By the evening there was a galaxy map, random encounters and FTL-style choices, with animated jumps, laser fights, explosions and scans. Then came a scrap economy, a crew with names and morale, and a full retro pixel-art UI.

Day two was about depth. Chiptune sound effects and generative music, all synthesised in the browser with no audio files. A CI pipeline and store releases. Then the parts that make it feel like a story and not a slot machine:

Text that reads many ways. Every opening and outcome has several versions. Some of them nod to things that happened earlier in your run, like a choice you made, someone you lost, or how low the fuel is.
Crew who are characters. Each crew member has a hidden trait and sometimes a secret. You find them out through events, and they quietly shift the odds before you know them.
Stories over time. A choice can come back a few jumps later. Outcomes can mark the chart: a cache, a wormhole, a bounty hunter who's now tracking you.
Terrain that makes the route a decision. Nebulae hide you from pirates but burn extra fuel. Asteroid belts cut across the map. Lawless space is where both the danger and the salvage are.
The three-section journey home.

Day three was the crew game, and then a cleanup. I wanted the crew to feel like people with their own opinions, not just a number of bodies on board. So we wrote a design doc first and then built it in phases:

Everyone has their own opinion of you. Each crew member weighs your choices against their own values: courage, mercy, gain, openness and order. Attack the pirates and the hothead cheers while the careful one goes quiet.
The crew feel things about each other. Friendships, rivalries and grudges grow out of who agreed with whom. Every choice you make is remembered.
Hidden plots. A crew member who resents you, holds a grudge and has no friends aboard might start sabotaging the ship. The others will notice and accuse someone, and it's often the wrong person. You have to decide what to believe without knowing the truth.
A storyteller. It picks up threads, notices your favourites, tracks the promises you keep and break, and paces trouble against calm. Crew can ask for detours to go home or get married under a planet's rings, and that pulls at your route.

None of that is scripted as one story. It comes from a handful of rules applied to whoever happens to be aboard. Nothing is ever certain between two people, either: every choice involving two crew members can go more than one way.

Then I asked for a code review, and we spent the evening working through it. We fixed bugs, split up files that had grown too big, and added lint rules so it can't drift again. Then came a last round of polish: crew portraits down the side of the screen, fuel and hull bars, and jump gates with a ring station round them.

What I learned

You still have to design the game. The agent is fast, but it can't tell you whether something is fun. The time that mattered went into playing and noticing problems. For example: "don't pre-select a choice, it reads like a recommendation". Or: "don't show costs up front, let the outcome tell you". Or: "the sky has to match the encounter". Most of my contribution was taste and judgement. Very little of it was code.

Write the rules down. Early on we started a CLAUDE.md file in the repo. It holds the project's conventions, its architecture, and why things are the way they are. Every new session reads it first. That file is probably the most important thing in the project. It's how decisions from day one still hold on day three.

Tests are what make "vibe" safe. I can't review 22,000 lines of code I didn't write, but I can insist on things that check themselves. The game rules are pure and deterministic: the same seed and the same choices always give the same run. A content validator checks every encounter and event for typos, unreachable branches and missing follow-ups. Bots play thousands of simulated runs to measure balance, so the numbers aren't guesses. A careful bot gets home about half the time. A reckless one almost never does. Those checks are what let me say "yes, go" without reading every diff.

Structure matters more, not less. Code you didn't write rots fast if nothing holds it in shape. The biggest improvements on day three weren't features. They were refactors that kept the rules separate from the rendering, plus hard limits on file and function size.

It's not magic. Some things took several tries. Store signing and release pipelines were the usual pain. Some ideas looked good on paper and felt bad in play. But the loop from "I wish it did this" to "it does this" was minutes, not days, and that changes what's worth trying.

Standing on shoulders

Star Trail builds on some generous open-source work and great asset packs. Among them are a port of the SpaceshipGenerator algorithm, which is why every ship is unique, and Deep-Fold's PixelPlanets and PixelSpace, which make the planets and skies. Full credits are on the in-game Credits screen.

Play it

Star Trail runs in your browser on desktop or phone. It works best in portrait. startrail.greyden.games

Every run is seeded, so no two galaxies are the same. Your crew won't be either. Try to get them all home. Let me know how far you get, and who you lost along the way.