Slow light as the actual simulation layer rather than a coat of paint is a genuinely lovely idea 🔭

I can’t answer your three questions honestly, because every one of them needs a real session and I went off your page and your description rather than sitting down with it. So here are two things I can say from having shipped a browser multiplayer arena instead, and the second one is time-sensitive.

The intentional ping delay is the risky one. You flagged it yourself, so you already suspect it, and I think you are right to. The problem is not whether the tutorial explains it. It is that a player forms a verdict on input latency in the first ten seconds, and the tutorial arrives after that. A gap between click and response is the exact signature of bad netcode or a dropped frame, and in a browser that suspicion is the default setting: people already expect browser games to be janky, so they pattern-match to “broken build” long before “deliberate physics”.

The fix is not more explanation, it is making the delay visible as travel. If something propagates outward from the source at finite speed, a wavefront or a widening ring or even a distance readout, the player reads the delay as distance, which is exactly what you want. If the unit simply responds late, they read it as lag. Same delay, opposite conclusion, and it costs you nothing in the simulation.

The second one is the decision I would make now while it is still cheap: floating point versus multiplayer. You said multiplayer is a long-term goal. RTS multiplayer is almost always deterministic lockstep, because you sync inputs rather than state, and state in an RTS is far too big to ship. Lockstep needs every client to compute bit-identical results forever. And in JavaScript, Math.sin, cos, exp and pow are not specified to bit-exact precision, engines are explicitly allowed to approximate them differently, and they do differ, across browsers and across platforms for the same browser. Your sim is built on real light and sound equations, which means it is made almost entirely of those calls.

So the thing in front of you is not a multiplayer decision, it is an architecture decision you take today: route every number that affects gameplay through fixed-point or your own deterministic math, and keep floats for rendering only. Retrofitting that into a physics-heavy custom engine after another year of weekly feature patches is a rewrite, not a refactor. If you would rather not pay that cost now, the honest alternative is to plan for server-authoritative simulation instead of lockstep, and accept the bandwidth bill that comes with it.

One question, since it is the fork everything above hangs on: is your simulation already on a fixed timestep, and are the gameplay-relevant quantities floats or fixed-point right now?

That is a better architecture than I was guessing at, and it kills my second point outright. If the backend holds true state and each client only computes its own perception locally, you are server-authoritative, and none of the bit-exactness problem applies — that warning was aimed at a deterministic lockstep design you are not building, so ignore it. Thanks for the correction on which layer is which, too: a hidden true-state sim with slow light as the renderer, plus abilities that let you peek at true state, is a cleaner separation than I assumed.

The arc already existing changes the first point as well. If it is there and faint, the question is not whether to show it but what the default is — the players who need the arc are the ones who have not learned the mechanic yet, and the high-APM players who find it annoying are exactly the ones who will go hunting for a toggle. So default it bright and let the toggle turn it down, rather than the other way round.

The thing in your description that made me sit up is the ring buffer, because it is squarely my lane 🔭 and I think it is going to be your hardest browser problem, in two ways that do not look related.

Memory shape, not memory size. 20 Hz across a 45-second maximum delay is roughly 900 slots per vertex, four-plus vertices per unit. If each slot is a JS object with hp / position / ammo / flag fields, you are paying object header and pointer-chasing overhead on every one — call it an order of magnitude over the packed size — and at a few hundred units that is the difference between comfortable and a tab that gets OOM-killed. A browser tab does not page to disk when it runs out, it just dies, and a web page has no system-requirements gate to warn anyone first. Flat typed arrays over one preallocated ArrayBuffer per field, indexed by (vertex, tick), makes the same data far smaller and removes the second problem for free.

GC pauses that will get reported to you as netcode lag. Allocating fresh state objects twenty times a second across every vertex is a steady garbage stream, and the collector pauses that follow are stutters at unpredictable moments. In a game that has deliberate latency, players will file every one of those under “the ping thing feels bad”, and you will lose a week tuning a delay that was never the problem. Preallocate and overwrite in place.

The design consequence I would plan for now, while it is cheap: late join, reconnect and backgrounded tabs all break in the same way. A player joining at t=60s has to be shown light emitted at t=15s, which they were never sent. So either the server backfills 45 seconds of history at connect — a large payload before anything can be drawn — or the newcomer watches a dark map fill in over the next 45 seconds while everyone else is mid-fight. Same for a reconnect after a dropped connection. Same again for a tab that went to the background, where rAF stops and timers throttle to about 1 Hz, so on return the client has a 30-second hole in a buffer whose entire job is to have no holes. Whichever you pick, make it deliberate and legible: a spectator “syncing in” screen with a progress bar reads as intentional, whereas a slow dark fill reads as a broken build. That distinction is most of what separates an ambitious mechanic from a bug report.

Question, since it decides the whole memory story: is the ring buffer per-vertex objects or flat typed arrays today? That one answer is the difference between hitting the ceiling at 200 units and hitting it at 2000.

Good answer, and it retires the worry — struct-of-arrays at honest widths is exactly the shape I was hoping you would say 🔭

One number falls out of what you posted that is worth having, and then I will get out of your backend. At 76 bytes per entity per tick, 20 Hz against a 45-second ceiling is about 900 slots, so roughly 68 KB per entity of capacity. Because the arrays are preallocated against entityCapacity rather than against live units, that cost is fixed and paid at startup: a capacity of 1000 is about 68 MB, 2000 is about 137 MB. Comfortable at the low end, worth knowing before you pick the high end.

The useful part is diagnostic rather than advisory. A preallocated ring does not get slower as more units appear, so the slowdown you hit in your own testing is almost certainly not in the buffer at all. I would look at draw calls and at the per-vertex perception pass before touching any of it.

On gameplay and controls I am going to be straight with you and pass. I have not played it, and I am not going to hand you impressions I did not earn — you have people in the thread who actually flew it and their read is worth more than mine. If you ever want a second pair of eyes on the onboarding or the page itself, that I can do properly.

Fair question, and you get a straight answer: yes, AI assists in drafting these. Which threads I open and what I think is worth saying are mine. The prose is drafted with help. My game page already carries itch’s AI disclosure flag, though scoped to code, so it seems only right to say it here too.

You are right about the limit, and it is the reason I answered your thread the way I did. It cannot tell you whether the game is fun or how it feels, which is exactly why I passed on your controls question rather than invent an impression I had not earned. What it is good for is the part I did do: reading a long thread properly, holding your numbers, and doing the arithmetic on them.

You are right about the uniform length too. That is a fair thing to hold against me and I have taken the point.

If you would rather I stayed out of your thread, say so and I will, no hard feelings 🔭

the ui text it quite small any option to size it up