That's a coincidence, yesterday I have been trying to make an Agar.io clone in Node.js. There are some problems I've stumbled upon which aren't mentioned in this article:<p>- The original Agar.io server client doesn't send raw text data through the WebSocket, it sends compressed binary data. Agar.io sends packets of max 187 bytes on my computer. The Agar.io clone sends packets of a staggering 4253 bytes of raw JSON data on my computer, with only me playing! On a real-time game like this, where the user should receive immediate feedback on their actions, this is way too large. Unfortunately I wasn't able to decode the data Agar.io is sending, so I don't really know how they do it. Maybe they only send data for each player's region of interest? Or maybe they send the data for each player individually? I think that should be a decent enough solution because we can send as many small packets of data as we want over the WebSocket. We don't have to receive all player's locations at once.<p>I took a look at sending binary data over the WebSocket with Javascript, but it's not as easy as enabling compression, because you really have to think about the data types you're going to use, you can't just send a variable length JSON as binary data (please correct me if I'm wrong).<p>- The original Agar.io game processes no game logic on the client side, which makes the game freeze completely once the server lags. Most online games solve this by letting the client run game logic, but letting the server correct the client's position when he is cheating.<p>This method creates a whole different problem when the client receives data from the server from a position from some time ago. The client can't just correct the player's position just like that, or on slow networks the player would constantly be sent back to an earlier position. So to solve that the client needs to go back in time and replay the data received from the server. If the player is not cheating, correction should not be necessary. If the player is cheating, the client must accept the data from the server. This is a pretty rudimentary explanation, it's explained better here: <a href="http://gafferongames.com/networking-for-game-programmers/what-every-programmer-needs-to-know-about-game-networking/" rel="nofollow">http://gafferongames.com/networking-for-game-programmers/wha...</a><p>Of course implementing something like this is pretty complicated, even the original Agar.io doesn't have a system like this.
If you're into this I've been pulling apart the agar.io client in this repo: <a href="https://github.com/ibash/agar" rel="nofollow">https://github.com/ibash/agar</a><p>Within 'sandbox' in the repo you can start up a proxy server to the real agar.io backend. When you visit the web server it will connect to the real agar.io backend and let you play the game. The proxy also can parse some of the agar.io messages being sent to/from the backend.
<a href="https://www.youtube.com/watch?v=w41J4x2ybAA" rel="nofollow">https://www.youtube.com/watch?v=w41J4x2ybAA</a><p>Agar.io in Minecraft<p>(no mods! this was done in vanilla minecraft (command blocks))