Building multiplayer games with Socket.io and HTML5 Canvas
I&#x27;m doing similar, it&#x27;s so much fun, and here are my takeaways:<p>- Ignore socket.io, do pure binary websocket<p>- <i>Do not</i> serialize JSON, or use msgpack or protobuf - write your own protocol.<p>- Write tests for protocol, you need fast iteration. It&#x27;s super easy to write tests for codec.<p>- Quadtrees are kinda lousy compared to r-trees.<p>- Measure everything with realistic load - i.e. I&#x27;ve found out that it&#x27;s more costly to calculate world entity deltas to send to client, than to send everything in his view.<p>- Keep client updates under MTU payload. This is basically impossible with JSON.<p>- Mutability is the way to go for performance.<p>- Share code with backend and frontend, you&#x27;ll need it for client prediction.<p>- Prefer fixed entity speeds.<p>- Don&#x27;t log per-frame in production, journalctl will eat up your memory.<p>- Write game bots to test your load non-synthetically.<p>- Test on your VPS, you&#x27;ll be surprised how underperforming CPUs are in most providers. Neighbours are probably serving some CRUD and are very likely not to be as noisy as you are.<p>Now, all this might not apply depending on exact gameplay mechanics you have, but it works for me. I have Node.js serving 200 clients and 10k entities with vision (can run at or from you) at 20 frames per second that keeps under 100MB RAM with no hiccups. I think I could use something like Golang for some more advanced physics though.<p>A question to all reading - I&#x27;m considering adding an option to mine Monero in my next game. It&#x27;d probably be a flip-switch between ads and mining right there on the home screen, with some intelligent throttle&#x2F;thread decisions depending on the kind of device game is running on. I&#x27;d appreciate any feedback regarding the sentiment on that.