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:
- 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.
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).
- 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.
When doing binary communication in javascript, I usually use protocol buffers. https://github.com/dcodeIO/ProtoBuf.js/ is a nice protocol buffer library for javascript that also works in the browser.
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.
I see a split icon when playing on a mobile device, but I agree that control is really really hard. I even have a hard time on a touch pad--just seems more natural with a mouse.
- 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.
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).
- 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.