Day Rider: Keep the Wheels Moving

For about a day, this game was called Moto Rider in my own local commits before I settled on Day Rider. I don't even remember why the name changed — probably just that "moto" boxed me into thinking it had to be a motorcycle, and I hadn't actually committed to what the player was driving yet. Small thing, but it's a good reminder that a game's name usually gets picked before the game itself is finished being decided.

Two controls, on purpose

Day Rider's entire control scheme is accelerate, brake, and weave between lanes. That's it. No weapons, no pickups, no boost meter. I built this right after 60 Sec Survival, which already had jetpacks and dashes and shields stacked on top of each other, and I wanted to see if I could make something that felt just as replayable with a tenth of the input surface. The honest answer is: mostly yes, and the parts where it works are more interesting to me than the parts where a bigger game would've helped.

The whole design bet is that the challenge should come from reading traffic, not reacting to it. A car two lengths ahead of you isn't a problem yet — it's information. The game gives you that information for free, all the time, and the entire skill ceiling is how far ahead you choose to look instead of tunnel-visioning on the bumper directly in front of your car. That's not a mechanic I coded, it's just what happens once you remove everything except lanes and moving obstacles: your eyes either learn to scan ahead or they don't.

Day and night, for free

The road cycles between day and night as you play, and I want to be honest about why: it was cheap. A gradient shift and a few headlight sprites on the traffic cars bought a lot of visual variety for a game that otherwise has almost nothing to look at besides asphalt and other cars. It doesn't change the difficulty at all — traffic density and speed don't care what time it looks like — it's purely there so a five-minute run doesn't look like the exact same screenshot the whole way through. Sometimes the right call really is the cheap one, as long as you're honest with yourself about why you're doing it.

Where the actual difficulty lives

Speed climbs the longer a run goes, and that's the only escalation curve in the whole game — no phases, no named difficulty tiers like 60 Sec Survival got. I tuned it so the early stretch of a run is almost boringly easy on purpose. If the first fifteen seconds are already testing your reflexes, you never get the chance to build a rhythm, and reading-traffic-ahead is a rhythm skill more than a reaction skill. Give players a runway to get comfortable, then let rising speed be the entire antagonist. I went back and forth on whether that opening stretch was too long and boring, and landed on: a little boring beats too hard, because boring just means someone taps through it once and never thinks about it again, while too hard means they bounce off the game entirely.

What I didn't get right on the first pass was how punishing a late dodge should feel versus an early one. My first build let you swerve at almost the last possible pixel and still clear a car, which sounds forgiving but actually made the game worse — it meant there was no real cost to reading traffic badly, since you could always bail out of a bad read at the last second. Tightening that window is what actually made "look further ahead" a real skill instead of a nice suggestion. Now a late correction genuinely is more likely to clip something than an early one, which means the advice I'd give anyone playing this — small early corrections beat last-second dodges — is true because I made it true, not just because it sounds like sensible driving advice.

What I'm not sure about yet

There's no fixed end state here — no level 10, no boss, just your own best distance. I like that as a philosophy, but I genuinely don't know yet whether a game with literally nothing to unlock holds anyone's attention past a few runs. 60 Sec Survival at least has phases with names, something to look forward to reaching. Day Rider has a number that goes up. Whether that's enough on its own is something I won't know until it's actually out and I see whether anyone's coming back to it a second day.

For now, I'm treating it as the deliberately smaller, calmer sibling to the reflex-heavy stuff — something you can load in ten seconds and understand completely before your first crash. If that's not enough to make it stick, at least I'll have learned something real about how much a browser game actually needs beyond "the core loop is fun," instead of just assuming more systems is always the answer.

On-screen pedals were the annoying part

Keyboard controls for this were trivial — arrow keys for accelerate, brake, and lane changes, done in an afternoon. Getting the same feel on a phone took considerably longer. The obvious approach is on-screen pedal buttons, but a thumb resting on a physical accelerate button behaves differently than a key press: there's no natural "just tapping it" the way there is with a keyboard, so touch inputs needed their own tuning for how quickly a held pedal ramps speed up versus how a keyboard's binary key-down state does it. I ended up giving touch a slightly gentler ramp than keyboard, purely because thumbs are worse at split-second releases than fingers hovering over physical keys are, and the game shouldn't punish a control scheme for being a phone.

I also thought about whether the two input methods should even produce identical difficulty, and decided they don't have to. A leaderboard built around "your best distance" already accepts that people are playing on wildly different hardware, at different screen sizes, with different reaction latencies from their specific device. Chasing perfectly identical difficulty across keyboard and touch is a rabbit hole that doesn't actually improve the game — it just delays shipping something that's already good enough on both.