Link: https://bronzeandglory.fun/?ref=r34-webdev-pd

Disclosure: I'm the solo developer of Bronze & Glory, a free turn-based gladiator duel game in the browser. No ads, no download, no payments.

Stack: a static client in plain JavaScript ES modules, served by nginx. The game server is Node with SQLite. A separate small Node service counts players online from page heartbeats.

How the multiplayer sync works: there are no WebSockets. A duel is a server-side room; each client polls the room over HTTP and submits its move. The server runs the same rules engine module as the client (takeDuelTurn), so a client can't fake a result. Because it is turn-based, polling latency is hidden in the turn animation. Per-user rate limits (e.g. 60 moves/min per user) keep a misbehaving tab from flooding the server.

The empty-queue problem: a small game's online queue is empty most of the time. If nobody else is searching after a few seconds, a clearly labelled Practice Bot takes the seat (the server can also seat a ghost after 8 s). It is never counted as a player.

What I'd love feedback on: is HTTP polling a mistake at this scale, and where would you move to WebSockets/SSE?

Help me load-test the live server. Join now; group match at 01:20 UTC (30 minutes after posting). Can we get 4+ into one arena? Open the link, go to online duels (a free account: pick a username and password) and search for a quick match: you get paired with whoever else is searching.

Play: https://bronzeandglory.fun/?ref=r34-webdev-pd

Update: Load test #2 is Sun 25 Oct 19:00 UTC (15:00 EDT / 12:00 PDT / 20:00 CET): can we get 25 into one arena? https://bronzeandglory.fun/?ref=r35-return-webdev-pd

Is "no websockets" supposed to be an appealing factor?

That was my question. While I didn't get much about what the game is about, I do know it doesn't use websockets... Yet.

Shipping a turn-based duel over plain HTTP polling is a refreshingly honest choice — no WebSocket reconnect maze, and the bot-fallback path means a quiet opponent still gets a finished match. Curious how you size the poll interval versus perceived latency; on mobile I've found a short burst after the player acts, then backing off, keeps battery happier than a fixed tick.

Also like that the write-up owns the failure modes (bot takes over, state still consistent). That's the part most "I made a multiplayer game" posts skip.