Multiplayer Doom on Cloudflare Workers | Hacker News Reader

Multiplayer Doom on Cloudflare Workers

blog.cloudflare.com

76 pointsCrLf9 comments

This is exciting. I've always wanted to add proper networking support to my ioquake web port and now I have a good excuse: https://github.com/klaussilveira/ioquake3.js

Quake 3 networking is much more efficient and would definitely shine here. For the curious:

https://web.archive.org/web/20190316154729/trac.bookofhook.c...

https://fabiensanglard.net/quake3/network.php

Not only it allows me to prototype for cheap, it actually allows cost to grow along with the userbase. Compared to something like: https://github.com/HumbleNet/humblenet

Let me know if you need any help. We actually thought about using Quake3 instead of Doom but ended up going for the classic :)

How is the communication between workers handled? Their blog post about websocket support only advertised the possibility persist state via their key/value store, but here the workers handling different clients need to communicate with each other in real time. How is this done?

edit: Their "Router" class is a "Durable Object". There is no trace of this in their code, this is configured separately when creating the worker. A durable object is a durable JavaScript object, unrelated to K/V storage; it seems to essentially be a class whose instances act like service workers and can respond to requests using their persistent state. I guess there is special support for WebSocket endpoints in their Durable Object system so that a WebSocket endpoint can be sent to/from the Durable Object.

Their docs are really not optimal, with many different iterations of the syntax mixed together (e.g. some thing only work with the "Module syntax" but every single example is written with the "addEventListener syntax").

The router code is here: https://github.com/cloudflare/doom-workers/blob/main/router/...

Introduction to Durable Objects here: https://blog.cloudflare.com/introducing-workers-durable-obje...

It has since gone into open beta.

> some thing only work with the "Module syntax" but every single example is written with the "addEventListener syntax"

The new modules syntax is still beta -- it'll eventually be the official recommendation for all Workers, but we're not there yet. But it is indeed required for Durable Objects, which is also beta, because we didn't want to come up with an old-style syntax for Durable Objects that would just be deprecated immediately anyway. It does unfortunately leave things in a confusing state at the moment, but it should get better soon.

In short: the vendor (Cloudflare) handles it, not you. Cloudflare has to quickly disseminate a lot of things to their data centers all the time (new files, routing rules, cache invalidations, etc.) and Durable Objects piggybacks on that same infrastructure.

From the client's point of view, all the network I/O is to a "centralized" server and not peer-to-peer, except in this case the "centralized" endpoint is actually a cluster of data centers that all talk to each other behind the scenes.

Client --> nearest Cloudflare node --> all the other nodes via their phat pipes, not yours

Edit: their global stateful serverless chatroom demo more clearly demonstrates how it works: https://github.com/cloudflare/workers-chat-demo

Really cool experiment!

I wish they had included a detailed costs breakdown, as it seems like it might cost too much to be viable.

Wouldn't it be better to use WebRTC data channels for communication between instances of the game? If I'm not mistaken, that's even based on UDP. Of course, that wouldn't show off the new Cloudflare features nearly as much, though I guess Workers and Durable Objects could still be used to help the clients establish the WebRTC connection.

For Doom specifically, which uses a P2P networking model, yes, that probably would have been technically superior. It would have taken more work, though -- this demo was thrown together pretty fast. Durable Objects could still have been used for setup, yes.

Most modern games use a client/server model, in which case the possible role of Durable Objects is a lot clearer.

Reply on news.ycombinator.com