Asteroid Dodge: No Shooting, On Purpose

There's no shooting in this game, and I want to lead with that because it was the one rule I set for myself before writing a single line of it. Every space-survival game I could think of eventually hands you a weapon, and the moment it does, the actual challenge quietly shifts from "don't get hit" to "clear a path before it hits you," which is a different game wearing the same visual skin. I wanted something that stayed purely about spatial reading under pressure, with absolutely nothing to do but move.

Removing offense meant the field had to do more work

Take away the ability to shoot, and the entire difficulty curve has to come from how the asteroid field itself is generated — density, gap size, and how much warning you get before a cluster arrives. That's a harder generation problem than it sounds like, because a field that's purely random tends to occasionally produce genuinely impossible gaps by chance, which feels like the game cheating rather than the game being hard. I had to bias the generator away from truly uniform randomness, guaranteeing some minimum navigable path exists across the field at any given moment, while still letting the overall density climb as a run goes on. Fair and hard aren't the same axis, and a pure-dodging game lives or dies on getting that specific balance right, since there's no weapon to bail you out of an unlucky spawn.

Power-ups had to stay a detour, never a requirement

Power-ups drift through the field alongside the asteroids, and the deliberate design rule is that grabbing one should always cost you something — a slightly riskier line than the safe path you'd otherwise take. If a power-up were free to collect, it stops being a decision and becomes a checklist item, and the whole game would lose the moment-to- moment tension of choosing between playing it safe and reaching for something extra. I tuned power-up placement to specifically favor positions adjacent to denser asteroid clusters rather than open space, so that grabbing one is a genuine bet you're making about your own piloting, not a freebie sitting in a clear lane.

Mouse and drag had to feel like the same game

Desktop uses direct mouse-position tracking — the ship goes wherever the cursor is. Mobile uses a drag gesture instead, and getting those to feel equivalent rather than like two different control schemes bolted onto the same game took real tuning. A 1-to-1 cursor mapping translated naively to a touch drag feels twitchy and over-sensitive on a phone screen, because a mouse has far more precise positional resolution than a fingertip does. Touch input got its own sensitivity curve rather than reusing the desktop mapping directly, specifically so a careful drag on a phone produces the same kind of fine-grained control a steady mouse hand gets on desktop, instead of feeling like a worse version of the same input.

Reading the field a few rows ahead, not the nearest rock

The instinct for a new player is to react to whatever asteroid is closest, and that's actually the losing strategy once the field gets dense. By the time the nearest rock is a genuine problem, the gap you'd need to reach safety was often decided two or three rows earlier, by asteroids that were still comfortably far away when the decision actually needed to be made. I didn't build any explicit mechanic to force players toward reading further ahead — it emerged naturally from how the field scrolls, and it's the same lesson Day Rider's traffic patterns teach in a completely different genre. Reading ahead instead of reacting late seems to be a recurring theme across everything I build in this general shape of game, whether it's asteroids, traffic, or trap clusters.

I did add one small piece of support for this without breaking the no-assists rule I set for myself: the field renders far enough ahead of the ship that a careful player genuinely has time to plan a route two or three rows out, rather than the game only revealing danger at the last possible moment. That's not a hint system, it's just render distance, but it's the difference between a game that rewards forward planning and one that's secretly only rewarding fast reflexes while pretending otherwise.

What I'm watching for after launch

The thing I genuinely don't know yet is whether "no shooting, ever" holds up as a satisfying rule over dozens of runs, or whether it starts to feel like something's missing once the early novelty wears off. Pure dodging games can go either way — some stay compelling purely on tension and reflexes, others start to feel incomplete once a player's mastered the basic movement and there's no additional system to engage with. I'm fairly confident in the generation and controls at this point. Whether the core rule itself was the right call is something only real, repeated play is actually going to answer.

Visually, I kept the field intentionally restrained — muted rock tones against dark space, no particle-heavy effects, since nothing here ever explodes or gets destroyed. That restraint was deliberate too. A dense field already asks a lot of a player's attention just to track gaps between shapes; layering bright, busy effects on top of that would compete directly with the information a player actually needs to parse correctly in the moment. Sometimes the right amount of visual polish for a reflex game is less than feels satisfying to build, because attention is the scarce resource here, and every bit of it spent admiring a flourish is a bit not spent reading the field. If the core loop earns its keep, there's plenty of room to add atmosphere later without ever touching the part that actually matters, and I'd rather add it once I know the loop deserves the investment than guess at it now. It's a quieter, calmer launch than some of the other games I've shipped, and given that this one is entirely about staying calm under a screen full of moving rocks, that quietness feels like the right note to end on rather than a gap to apologize for.