0
submitted 1 day ago* (last edited 1 day ago) by BronzeAndGlory_Dev@on200.com to c/programming@programming.dev

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.

12 seconds of a real campaign bout

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-programming-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-programming-pd

top 1 comments
sorted by: hot top new old
[-] CGTRocketX@programming.dev 2 points 1 day ago

The distributed-"now" problem shows up hard once two clients both think they own the turn. Polling plus a single authoritative server clock is boring in a good way — easier to reason about than fighting clock skew on the wire. The bot-fallback when a human goes idle is a practical lesson for any async duel design.

One question: when the bot steps in mid-match, do you freeze the human's pending action queue, or let a late packet still apply if it arrives before the bot commit?

this post was submitted on 25 Oct 2026
0 points (50.0% liked)

Programming

28976 readers
169 users here now

Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!

Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.

Hope you enjoy the instance!

Rules

Rules

  • Follow the programming.dev instance rules
  • Keep content related to programming in some way
  • If you're posting long videos try to add in some form of tldr for those who don't want to watch videos

Wormhole

Follow the wormhole through a path of communities !webdev@programming.dev



founded 3 years ago
MODERATORS