This is exciting. I've always wanted to add proper networking support to my ioquake web port and now I have a good excuse: <a href="https://github.com/klaussilveira/ioquake3.js" rel="nofollow">https://github.com/klaussilveira/ioquake3.js</a><p>Quake 3 networking is much more efficient and would definitely shine here. For the curious:<p><a href="https://web.archive.org/web/20190316154729/trac.bookofhook.com/bookofhook/trac.cgi/wiki/Quake3Networking" rel="nofollow">https://web.archive.org/web/20190316154729/trac.bookofhook.c...</a><p><a href="https://fabiensanglard.net/quake3/network.php" rel="nofollow">https://fabiensanglard.net/quake3/network.php</a><p>Not only it allows me to prototype for cheap, it actually allows cost to grow along with the userbase. Compared to something like: <a href="https://github.com/HumbleNet/humblenet" rel="nofollow">https://github.com/HumbleNet/humblenet</a>
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?<p>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 <i>JavaScript object</i>, 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.<p>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").
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.