1
This is my first time designing an exp/leveling system though so I'm not 100% sure how to approach the database design. Is it best practice to store both exp and level? Or is it better to store only exp and derive level?
The latter sounds potentially nicer if I want to adjust the level curve later, although that implies that all users could see their level change hm...
As the title implies, I want to make a mobile app for the site. I was looking into React Native at first, but then learned about webviews from this great blog post by Puzzmo[0]. Webviews seems appealing because I would be able to reuse many existing components (though I am aware of next.js related challenges from having to export a static build) and be able to stay comfortable and productive™ in a webdev context. I don't mind losing that "native" mobile UX goodness either since the tradeoff of better DX seems worth it given that I'm working on this alone. There also seems to be some neat tooling for webviews to streamline the development process e.g. Capacitor by Ionic[1].
Anyone have any opinions/insights/horror stories on all this?
[0] https://blog.puzzmo.com/posts/2025/06/01/ios-app-architecture/
[1] https://capacitorjs.com/
I thought I might've introduced a regression in the application layer, but the pattern I saw was strange. The latency would only spike on weekdays from around 8am-6pm PST i.e. peak hours. Note that the site is still a WIP and has 0 real-user traffic.
After some digging I've confirmed the issue isn't happening at the application layer, but rather at the network/Cloudflare level. When I check `mydomain.com/cdn-cgi/trace` during peak hours, the Cloudflare data centre processing the request is very far from both me and the origin server (e.g. LHR London). And then it changes to something closer during off-hours. I've also confirmed latencies returns to normal when I disable Cloudflare proxying.
Some Cloudflare community members have described that the issue is actually a business problem with ISP-Cloudflare peering agreements rather than a technical problem: https://community.cloudflare.com/t/very-slow-server-response-time/611853/3 . But they say the fix is to go from a free plan to a pro plan, and I've tried that but the latency still persists...
I'm not really sure where to go from here. Has anyone gone through anything similar before? Am I missing anything obvious? I would prefer not to remove Cloudflare, but if the user experience is at the whims of Cloudflare's ISP agreements (which seemed to be fine a month ago!), then I'm seriously considering to just handle security on my own.
Matchmaking uses a round-robin sharding approach: each room is always handled by the same backend instance, letting me keep game state in memory and scale horizontally without Redis.
Here’s the issue: At ~500 concurrent players across ~60 rooms (max 8 players/room), I see low CPU usage but high event loop lag. One feature in my game is typing during a player's turn - each throttled keystroke is broadcast to the other players in real-time. If I remove this logic, I can handle 1000+ players without issue.
Scaling out backend instances on my single-server doesn't help. I expected less load per backend instance to help, but I still hit the same limit around 500 players. This suggests to me that the bottleneck isn’t CPU or app logic, but something deeper in the stack. But I’m not sure what.
Some server metrics at 500 players:
- CPU: 25% per core (according to htop)
- PPS: ~3000 in / ~3000 out
- Bandwidth: ~100KBps in / ~800KBps out
Could 500 concurrent players just be a realistic upper bound for my single-server setup, or is something misconfigured? I know scaling out with new servers should fix the issue, but I wanted to check in with the internet first to see if I'm missing anything. I’m new to multiplayer architecture so any insight would be greatly appreciated.
Right now my main concern is how to handle continuous deployments without interrupting ongoing games (amongst other WebSocket challenges[2]). I was planning to deploy via Coolify, but am considering other options given that their zero downtime deploys still needs some love[3].
How would you approach building a turn-based multiplayer browser game in 2025?
[0] https://www.npmjs.com/package/ws
[1] https://www.npmjs.com/package/socket.io
[2] https://news.ycombinator.com/item?id=42816359
[3] https://news.ycombinator.com/item?id=43589794