- 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.
- 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.
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: http://gafferongames.com/networking-for-game-programmers/wha...
Of course implementing something like this is pretty complicated, even the original Agar.io doesn't have a system like this.
This was all for fun, and there aren't many comments, so reach out if you have questions.
> 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.
> Of course implementing something like this is pretty complicated, even the original Agar.io doesn't have a system like this.
Not entirely true, the original agar.io client plays ahead the position up to a limit.
Yes you're right. We realized that using binary data would help speed up the connection a lot. But it's really hard to improve. SocketIO already supported binary data but its core was built for transfer JSON data at first.
I'm starting a new project and still considering using Node/SocketIO or C++ for my server. Writing WebSocket server in C++ is not so popular and there will be a lot of problem if we're out there with it and need help.
I've read about the client-side logic and server-side correction solution, but it's too much complicate for a clone like this :D But thanks for a great direction, I will need this for my next production project.
Blog post regarding the basics of binary data + websockets:
Damn it :-), you got it first.
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.
Agar.io in Minecraft
(no mods! this was done in vanilla minecraft (command blocks))