I'm doing similar, it'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'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've found out that it'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'll need it for client prediction.<p>- Prefer fixed entity speeds.<p>- Don'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'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'm considering adding an option to mine Monero in my next game. It'd probably be a flip-switch between ads and mining right there on the home screen, with some intelligent throttle/thread decisions depending on the kind of device game is running on. I'd appreciate any feedback regarding the sentiment on that.
Having worked on a commercial networked first person shooter, I can verify that making it smooth and coordinated is a massive pain in the ass. Having a game like World Of Tanks where the server makes all the decisions only works if the game entities are big and don't change much (i.e. tanks). There is a reason why none of the World games have people. Nothing is harder than trying to make a knife fight work over the internet without it looking spastic.
In case you haven't reached that point yet : also evaluate how much network badnwidth is going to cost you if you ever host your servers on aws or gcloud and encounter average success. You may be in for a (bad) surprise.<p>Now compare that to how much you'll gain from ads. And soon you'll realize one huge issue you're going to have is to maintain your own servers a little bit everywhere in the world.
This is a great write up. I've had similar experiences, and agree, have the server-side game state be the single source of truth.<p>I basically stuck some visuals on top of the example "counting" snippet on the Elm site (<a href="http://elm-lang.org/examples/buttons" rel="nofollow">http://elm-lang.org/examples/buttons</a>) and made it multiplayer. First player to count to 50 wins.<p>I didn't use a tick approach, instead the state of the game was only updated on an event sent from one of the clients. I then broadcast the new state of the game to the other clients.<p>This is what I made <a href="http://retrorace.neillyons.io/" rel="nofollow">http://retrorace.neillyons.io/</a> <a href="https://github.com/nwjlyons/retrorace" rel="nofollow">https://github.com/nwjlyons/retrorace</a>. Something is not quite right in the backend code. I think there are problems with waiting for the mutex to unlock. The game feels like it freezes sometimes, but it could also just be a latency issue. The server is in London and I've only tested it with people who are several hundred miles away.<p>I also had plans to build multiplayer snake but felt like latency would make the game too slow.
If you have problems with lag and conflicts resolution of state, take a look at this article, it may be useful.
<a href="https://0fps.net/2014/02/17/replication-in-networked-games-latency-part-2/" rel="nofollow">https://0fps.net/2014/02/17/replication-in-networked-games-l...</a>
On the topic of multiplayer HTML5 games, I've recently started playing with Lance[1] and its pretty good. Its main draw is that it largely does the networking and latency compensation (it has options for interpolation and extrapolation) for you. The only requirement is that you write your game (client and server) in javascript and run the server on node, so that the gameplay logic can be run both in server and client (game is simulated both on client and server, but the clients are periodically synced with the server, using interpolation to make it look smooth).<p>[1] <a href="http://lance.gg" rel="nofollow">http://lance.gg</a>
If you are writing a game server with web, mobile and desktop clients, is socket.io the way to go?<p>AFAIK, socket.io is a wrapper around websockets. This makes it unsuitable for some fast paced games with alot of players. Is there a library which abstracts away tcp and udp connections?<p>And what can you do about tcp attack vectors? Are lamers trying to take down servers a real threat? How do you prepare for this? I therefore advise against writing your own network stack if you intend to make the service available to the public. Or am I too cautious?
<a href="https://github.com/tinspin/fuse" rel="nofollow">https://github.com/tinspin/fuse</a><p>TLDR: Websockets are overengineered and waste CPU cycles doing nothing but marshalling. HTML is better than canvas because it can be GPU accelerated and you get components and z-order for free.
Any not so expensive hosting options for sockets-based apps? Heroku? Digital ocean? AWS?<p>Also, what are the limitations by the hosting provider regarding concurrent connections, data transfer, etc.<p>I am currently working on a poker app using free Heroku dynos but would like to have a budget in mind for when going live.
The author mentioned that using a control scheme with small acceleration leads to better synchronizing with the server. Another approach to this is control schemes where the client indicates to the server "I'm planning on being at this location at this future time."
I wrote something similar as a very simple demo multi-player tank game/simulator with socket.io and canvas: <a href="https://github.com/pdfernhout/TanksInYourBrowser" rel="nofollow">https://github.com/pdfernhout/TanksInYourBrowser</a>