Devlog, Engineering
TinyTrack devlog: portrait-mode drift racing and the Blender car pipeline
Devlog for TinyTrack — why a 3D racing game in portrait orientation is worth the layout pain, how Rapier drives the drift model, and the Blender-to-game asset pipeline.
Indie game developer · Aarhus, Denmark
TinyTrack is a 3D time-trial drift racer played in portrait, with one thumb. That single sentence contains the entire design bet, most of the engineering pain, and the reason the game exists. Devlog time.
The bet: racing for how phones are actually held
Every mobile racing game asks you to rotate your phone and commit both hands, like a tiny console session. But phones live in one hand — on the bus, in the queue, in the last five minutes before sleep. Time-trial racing is the purest score-attack genre there is: no opponents, no rubber-banding, just you, the line, and a ghost 0.3 seconds ahead. It should fit in those moments. TinyTrack is the attempt to make it fit.
Portrait 3D racing is a real layout problem: the view is tall and narrow, so track ahead is scarce. The camera does constant quiet work — higher angle than a normal racer, subtle look-ahead into corners, field-of-view breathing with speed — so the next apex is always readable in a vertical slice of world.
Drift as a conversation, not a simulation
The car is a Rapier rigid body, but the handling model is deliberately arcade. Grip breaks loose predictably past a slip threshold; counter-steer always answers; a good exit visibly pays. I tune for conversation — input, response, correction — not for tire physics. The test is always the same: after forty attempts at the same lap, does the game still feel generous? Time-trial players don’t quit because a game is hard; they quit because it’s unfair.
Rendering is Three.js via React Three Fiber, state in Zustand, everything TypeScript — the same architecture as Ragnaroll, because sharing an architecture across games is a solo developer’s compound interest.
The Blender pipeline
Cars and tracks are modelled low-poly in Blender 4 and exported through a custom pipeline that bakes in everything the game needs:
- Visual mesh — low-poly, vertex-colored, cheap to light.
- Collision mesh — simplified hulls Rapier can eat at 60fps.
- Track metadata — start grid, checkpoints and racing-line hints exported as structured data, not hand-typed coordinates.
The contract is strict: a new track goes from Blender export to playable lap without touching game code. Content and engine stay divorced, which is the only way one person keeps shipping tracks after launch.
Web-first iteration
TinyTrack develops in the browser — tweak the grip curve, hot-reload, feel it in five seconds — and ships to iOS through Capacitor. Handling tune lives in a hot-reloadable config, and the difference that makes to iteration speed is embarrassing. Feel problems are solved by feeling, four hundred times a day.
Status: prototype with mature architecture, eating tracks as fast as I can model them. Follow the TinyTrack page — the first public time-trial ghost will be mine, briefly.