A devlog by Neeraj Kotwani, who builds every game on Elipar.
Neon Dodge is about as small as a game gets: you are a dot, shards fly in from the edges, survive. Orbs appear occasionally and are worth points.
There are exactly two decisions in it that matter, and both are about restraint.
Your finger moves a target, not the ship
The obvious implementation is to set the ship's position to the pointer. One line, perfectly responsive, and it ruins the game.
If the ship is the cursor, dodging is free. A shard comes at you, you move your finger, the ship is already elsewhere. There is no skill in it because there is no commitment — nothing you do can be too late, because position is instantaneous.
So the pointer sets a target, and the ship eases toward that target every frame at a fixed rate. It always lags a little, more the further the target is, and it overshoots nothing because it is an exponential approach rather than a velocity.
That lag is the entire game. It means a dodge has to be started early, which means reading the shards rather than reacting to them. It means a long flick across the screen costs real time, so a panicked big movement is punished and a small early adjustment is rewarded. And it gives the dot a sense of weight that a cursor-locked dot cannot have at any frame rate.
One easing constant, and it converts a reaction test into a positioning game.
Keyboard writes to the same target
The second decision falls out of the first. Arrow keys do not move the ship either — they move the target, at a fixed speed.
Which means there is exactly one movement code path. The follow logic does not know or care whether the target came from a finger, a mouse or a key, and the physics is identical on all three.
That matters more than it sounds. The common failure in a browser game with two input methods is that they are implemented separately and drift: a tweak lands in the pointer path, the keyboard path keeps the old behaviour, and a desktop player and a phone player are playing measurably different games. Since roughly half the players here are on phones, that is a real risk rather than a tidy-code preference.
It is the same convention the platformer here uses — one named flag per intent, every input source writing to it — and it makes the game scriptable for free, since a test can set a target and step frames.
Two difficulty dials, both capped
Shards get faster with elapsed time and spawn more often. Both ramps have a ceiling: speed stops climbing at a fixed cap, and the spawn interval bottoms out rather than approaching zero.
An uncapped ramp in a survival game does not make it hard, it makes it end at a predictable time. Everybody converges on roughly the same score, because past a certain density the screen is unsurvivable regardless of skill and the run is over within a second or two of that point. The caps are what keep the difference between a good player and a lucky one visible.
The score is survival time plus a bonus per orb, so the orbs are the only real decision in the game: an orb is usually somewhere inconvenient, and going for it means committing the ship to a path while the lag is working against you. Risk, in a game with one mechanic.
What it deliberately does not have
No power-ups, no lives, no levels, no upgrade shop. One hit ends the run.
That is a category decision rather than a scope cut. This site has a runner with a persistent coin wallet and a shop, a football game with Mario-Strikers-style power-ups, and a five-stage racing championship. What it was missing was something you can understand in one second and restart in less than that — the kind of game where the loop is tap, die, tap again, and the only thing that improves is you.
Adding a power-up to this would make it a worse version of a game that already exists here.
Neon Dodge is free in a browser, no account, no download. The ship catches up with your finger, eventually.