2026/6/26 · 19:30
Slipstream Vector case study: how Claude Code helped ship a spline-domain racer
A technical case study of Slipstream Vector, a Claude Code-assisted browser racer whose real lesson is architectural constraint: spline-domain physics, shared player/AI simulation, structured track features, and human-led feel tuning.
Slipstream Vector is a useful AI-game case because the interesting part is not the prompt. The creator has not published the exact prompt log. What is public is better for builders: a playable anti-gravity racer, a repo with the seams exposed, and a Reddit build note that says where Claude helped and where it did not.
Quick read
| Field | What is documented |
|---|---|
| Game | Slipstream Vector, a browser-based WipEout x Horizon Chase-style arcade racer with anti-grav ships, three worlds, six tracks, loops, corkscrews, jumps, championship mode, time trial, records, trophies, keyboard and gamepad support 1 |
| AI context | The creator says most of the project was built with AI as a pair-programmer, starting in Claude Code with Fable 5.0 ultracode mode, then moving to Opus 4.8 ultracode after the first model was pulled 2 |
| Tech stack | Three.js 0.172 via CDN import map, vanilla JavaScript, ES modules, DOM/CSS menus over a live 3D scene, procedural WebAudio, and GitHub Pages hosting 2 |
| Playable evidence | The public build runs at the GitHub Pages demo link; the page exposes the game menu and track selection text during crawl 3 |
| Source evidence | The public repository has 35 commits, a README architecture map, and source files for physics, AI drivers, spline tracks, race logic, UI, audio, and post-processing 1 |
コンテンツカードを読み込んでいます…
コンテンツカードを読み込んでいます…
The only caveat: I could verify a playable demo, a Reddit gallery post, and the source repo. I could not verify a separate demo video link. That matters for a racing game, because one Reddit commenter made the same point: still images undersell the motion and momentum 2.
The build choice that made this feasible
The game does not try to simulate an open physics world. It reduces the race to a spline-domain model. The player ship's state is
(s, d, v, vd): distance along the track, lateral offset, forward speed, and lateral speed. The physics file describes world position as a projection, with no raycasts, no colliders, and no tunneling 4.That one decision gives Claude a smaller problem to work on. Instead of asking an LLM to keep a full 3D collision world coherent, the game asks it to maintain scalar movement along a known track contract. The spline system exposes sampled curvature, banking, width, slope, split lanes, gaps, pads, and vertical curvature 5. The physics module consumes those scalars without importing Three.js 4.
That separation is the hidden case study. The AI did not have to invent a general racing engine. It had to extend a set of contracts: spline samples in, scalar physics out, visuals projected later.
What Claude helped with, and what the human still had to own
The Reddit post is unusually clear about the division of labor. The creator says AI was strong at scaffolding the renderer, shader work, the menu system, and polish passes 2. The same post says the creator still had to drive the feel: camera behavior, speed perception, readability, art direction, and deciding what to cut 2.
That split matches the code. The repo has many places where an assistant can safely add surface area: UI sections, trophies, tracks, audio events, scenery parameters, menu flows, and post-processing. The riskier parts are the contracts that decide whether the game feels fair: the physics model, the track frame, the camera, and the opponent driver.
The creator's own summary is the best warning label for AI game work: "The first result is never the thing" and it took dozens of feel-tuning iterations, including a lot of "no, that's worse" 2. That is not a failure of the model. It is the job. Racing games are mostly about small control and camera differences that read as either speed or nausea.
Why the track system is the real authoring surface
The README describes the pipeline as Catmull-Rom splines, an arc-length lookup table, parallel-transport frames, and a
frameAt(s) contract consumed by physics, mesh, camera, particles, and AI 1. In the source, the spline constructor expands loops, builds samples, frames, curvature, bank, width, stunts, pads, and splits before the rest of the game sees the track 5.The best example is stunt authoring. The README says a track can carry a
features array with entries like loop, corkscrew, and jump; the loop feature expands into control points, corkscrews overlay bank, and jumps mark a gap plus a lift impulse 1. The source backs that up: _expandLoops turns a loop into inserted control points, _buildStunts overlays corkscrew bank or records jump gaps, and gapAt lets physics know when a ship is over a gap 5.That gives the project an LLM-friendly editing mode. A new stunt is not a hand-authored mesh. It is a small structured data change. The model can propose or modify that data while the deterministic track builder enforces the same downstream contract.
Fairness is encoded, not promised
The game's strongest design claim is that AI opponents do not rubber-band. The Reddit post says rival ships run the exact same physics as the player 2. The README repeats the same point: difficulty changes driver skill, not ship speed, and the wake/slipstream mechanic applies to player and AI alike 1.
The code makes that more concrete.
race.js creates AI racers with new ShipPhysics(...), feeds each one an AiDriver, and describes difficulty as a skill scalar decoupled from the selected track 6. The computeDraft method checks every ship against every other ship and writes a draft target using the same distance and lateral-offset rule for player and AI 6.aiDriver.js is also written around that boundary. It returns the same input shape a keyboard player would produce: steer, throttle, brake, and airbrake 7. Skill affects racing line, brake points, and boost-pad decisions, not the underlying physics 7.This is a practical pattern for AI-assisted games: do not ask the model to be fair by convention. Make unfair shortcuts impossible, or at least obvious in one file.
Rendering: speed without an expensive lighting problem
The creator says the renderer uses a "no-lights" approach: vertex-colored and baked surfaces, near-total instancing and merging, with a target of roughly 60 fps even in the city 2. The README says the road shader carries expansion joints, skid marks, per-sector tint, and a center energy spine without adding extra geometry; it also says dense scenery is instanced and merged, with about 115 draw calls in a worst case 1.
That is another AI-friendly constraint. Lighting, shadows, and arbitrary materials create a huge search space. Slipstream Vector's look comes from controlled shader language, neon edge rails, set-piece props, camera speed cues, and post-processing. A model can iterate on those without breaking a physically based lighting stack.
The tradeoff is visible in feedback. One commenter said the white lines were distracting, the controls felt too abrupt, and a tutorial prompt would help if boost or other mechanics exist 2. Those are feel and readability issues, not missing-feature issues. They are exactly the areas the creator said required hard human direction.
What builders can copy
- Make the model edit data before it edits systems. Slipstream Vector's tracks are data files registered through an index, while a theme object controls scenery parameters and a team file controls ship stats and liveries 1. That gives an LLM safe surfaces for new content.
- Keep simulation headless. The physics module has no Three.js imports and runs from scalar track queries 4. That makes AI racers, replay, tests, and deterministic warp helpers possible without rendering.
- Use one contract for humans and bots.
AiDriverproduces the same control object as the player input path 7. That is a cleaner AI-opponent design than separate "NPC movement" and "player movement" systems that slowly diverge. - Treat prompt logs as optional, but iteration logs as mandatory. This project does not disclose exact prompts. It does disclose tool context, build areas, model changes, and the hard part of the iteration loop 2. For a case study, that is enough to learn from the build without pretending to reproduce the exact session.
What is still unresolved
The roadmap says weapons are the next big open question, with time-trial ghosts, pilot portraits in results, and more tracks also on the list 2. The README's roadmap also lists weapons, a performance pass, and championship persistence as unfinished work 1.
For now, the case is already useful. Slipstream Vector shows a better pattern than "ask Claude to make WipEout." It narrows the problem until an AI pair-programmer can contribute real code: spline-domain physics, same-code AI opponents, structured track features, static hosting, and a human repeatedly saying which version feels wrong.
このコンテンツについて、さらに観点や背景を補足しましょう。