We did a very similar thing with UltimateArcade (shut down long ago) where we optimized everything to be single threaded. We had a pretty intense updates/s rate from players, and that got pretty crazy pretty fast. Actor models with single threads made things easy because we could skip locks and play with contigious chunks of memory, which as the author found, is pretty fast.
Could you save even more bandwidth by updating static data and letting Cloudflare cache/serve it?
ie: put the batches on disk then have the clients grab it? It would be the equivalent of frame differencing, with the total board state being saved occasionally as a keyframe equivalent.
You're doing that dynamically anyway by sending batches and snapshots to the client.
Using the above you're basically making your game board into an interactive movie that's replaying moves from disk most of the time.
WebSockets with binary frames would likely be more efficient than HTTP polling for this use case, giving you real-time updates with less overhead than repeatedly fetching from disk via CDN.
I feel like I keep seeing one million checkboxes guy's experiments, and I wonder.... Where is the monetization? Is this just a FANGAM engineer with a lot of free time? Am I just beaten down by the SWE landscape of 2025?
A lot of people make small games just for fun, like any other creative hobby. Similar to: Making music, writing, drawing, 3d modeling, etc.
Actually, you can put all of those together and use them in a game. And the best part is that there's no target market, no KPIs to hit, so you can do anything!
Really-really nice article! I'm currently working on a single-process, in-memory, multiplayer game written in Golang. (: Happy and relieved to hear that it worked out for you and I might even borrow some ideas (e.g. I'm less worried about bandwidth, but Protobuf might still make sense). Thank you very much for sharing!
I don't understand how Rooklyn and Queens are indestructible structures? A rook can attack the structure and take pieces off the board if it's ok with sacking itself.
Edit: nevermind, the secret is revealed at the beginning of the paragraph
>I prevented pieces from capturing pieces on other boards.
so normally it's not an indestructible structure, but with that rule it is. Got it.
I love seeing efficient use of computing resources. As long as I've been coding, it's been sort of a mantra that "programmer time is more important than execution time" - leading to very inefficient implementations that waste not just processor time but user's time. I keep hoping that with the ongoing migration to "the cloud" that identifies the relationship between efficiency and real cost, there'll be a resurgence in proper optimization.
While you definately need rollback I wonder if it would have been easier, if a player got into a conflict position, to just dump their state and grab it a fresh copy from the server?
As long as you'd sent all their moves off to the server, they should see all the moves they've done which were valid (hmm.. there could be a race condition there). I wonder how often it's worth doing the more complex unwinding described? I may well be missing some complex case (which I imagine is often the case with rollback!)
Were there any bots that participated in One Million Chessboards? I remember people building some automation around One Million Checkboxes to do some crazy animation stuff, I wonder if that was attempted with One Million Chessboards.
Also, if One Million Chessboards started with some bots making moves, that could solve the cold-start problem mentioned under "a lack of awe", although I can also see how existence of bots might be a deterrent for some people.
15 comments
[ 3.1 ms ] story [ 43.6 ms ] threadOne Million Chessboards
336 points | 76 comments
https://news.ycombinator.com/item?id=43825336
ie: put the batches on disk then have the clients grab it? It would be the equivalent of frame differencing, with the total board state being saved occasionally as a keyframe equivalent.
You're doing that dynamically anyway by sending batches and snapshots to the client.
Using the above you're basically making your game board into an interactive movie that's replaying moves from disk most of the time.
Actually, you can put all of those together and use them in a game. And the best part is that there's no target market, no KPIs to hit, so you can do anything!
Not everything needs to make money. Some people build things for fun.
> Am I just beaten down by the SWE landscape of 2025?
Probably. Alternatively, I would ask if you ever enjoyed coding, or if it's purely been a job for you.
Edit: nevermind, the secret is revealed at the beginning of the paragraph
>I prevented pieces from capturing pieces on other boards.
so normally it's not an indestructible structure, but with that rule it is. Got it.
As long as you'd sent all their moves off to the server, they should see all the moves they've done which were valid (hmm.. there could be a race condition there). I wonder how often it's worth doing the more complex unwinding described? I may well be missing some complex case (which I imagine is often the case with rollback!)
Also, if One Million Chessboards started with some bots making moves, that could solve the cold-start problem mentioned under "a lack of awe", although I can also see how existence of bots might be a deterrent for some people.