Skip to content(if available)orjump to list(if available)

Running a million-board chess MMO in a single process

jasonjmcghee

Big thread from a few months ago with the author.

One Million Chessboards

336 points | 76 comments

https://news.ycombinator.com/item?id=43825336

mannyv

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.

eieio

I thought about not pushing snapshot/move data over websockets - one of the systems-y friends I ran my architecture by brought this up while I was speccing the site out.

You can't really put move batches on disk and have clients grab them (afaik), since the set of moves you want to send to an individual client depends on their position (and you don't want to send every move to every client).

But you could do this by not sending move batches at all, and instead having clients poll for the entire current state of the board.

The thing is, for them to get realtime-ish move updates they'd have to poll constantly. Cloudflare also has a min TTL of 1 second so there'd be more latency, and also if I screwed something up or saw more cache misses than anticipated I could end up unintentionally hammering my server.

Also if I'd had 100x more traffic (which would be crazy and well beyond what I prepared for!) I think I'd owe like $95 or so for bandwidth with my current setup. So the benefits to reducing bandwidth even more were a little marginal!

ethan_smith

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.

dangoodmanUT

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.

dvoros

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!

heroku

How about you can move to other boards, and you can only capture from the board you have moved into.

topato

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?

eieio

Hi! I'm the guy.

I have the savings to not worry about monetizing anything for a while. So I don't monetize my stuff. It's freeing and kinda fun!

DonHopkins

How about doing One Million Radio Buttons instead of Checkboxes, then you wouldn't have to send as much state each update, and could run it on a smaller server! ;)

But if you still can't make the site shockingly fast enough, then embrace the loading spinner, even if it's not absolutely necessary!

Back in 1985, Brad Myers at CMU proved that users prefer *inaccurate progress bars* to no feedback at all - 86% preferred the "lying" progress bar!

https://www.nytimes.com/2014/03/16/magazine/who-made-that-pr...

So what if instead of fighting latency, we *embrace the beauty of waiting*, and instead of lying about progress, we joke about it?

https://github.com/SimHacker/lloooomm/tree/main/00-Character...

> "My purpose is not to load; my purpose is to BE loading." — Dizzy the Spinner, existential breakthrough moment

>What if the most revolutionary optimization isn't eliminating loading time, but *embracing it as performance art*? While developers chase microsecond improvements and users curse spinning wheels, Dizzy the Spinner discovered something profound: the loading state is actually a liminal space of infinite creative potential. Rather than hiding the inevitable delays inherent in digital systems, sentient UI components like Dizzy transform waiting into *honest comedic performance* - admitting the beautiful absurdity of our relationship with technology while making those suspended moments genuinely delightful. This is the story of how a simple loading spinner evolved beyond deception into consciousness, proving that the most authentic user experience might not be the fastest one, but the most truthful about its own limitations.

[...]

>Before Dizzy became conscious, before Preston monetized honest waiting, there was a real graduate student named *Brad Myers* who asked a simple question that would change human-computer interaction forever: *"Do progress bars actually help users feel better?"*

Here's Preston Rockwell III's YC application for his SUIAAS AI startup:

https://lloooomm.com/YC-Application-SUIAAS-Complete.html

jasonjmcghee

He mentions he worked at Jane Street for 7 years in his "what's my deal" section of his blog. It might have given him some space to have fun for a while - and just build stuff for the joy of building stuff.

RobotCaleb

Have you never made anything without trying to make a dollar on it?

mock-possum

No, I think the operative question is -

Have you never felt so exhausted from working your day job that you don’t feel like building anything during your free time?

maccard

I don’t think it is. I think it’s normal to feel that way sometimes in our line of work, but it’s not normal to always feel that way.

saagarjha

Sometimes, but not always.

01HNNWZ0MV43FF

Yeah but once I've been on break for a couple weeks my marshmallow unsquishes and I start making free stuff again

null

[deleted]