Features of the Protocol in IO games
Suppose you want to create a IO-game. Something similar to agar.io slither.io thousands of them.
Many people know that in such games use websocket. And it's not complicated to create your own Protocol over it. I thought so when about a year ago we started the project space shooter in this style.
Now I don't think so.
the
The main problem that must be solved for all developers of multiplayer games — achieving "simultaneity" of the events.
Naive approach: let's I'm going to move your character, sending these movements to the server, and the server will send them to my opponents — not working. If you do so, your character will live in real-time, and his rivals in the past. Their movements will lag by about two to ping the server. For example, if the ping is 100ms, you'll see where the opponents 200ms ago. Accordingly, play would be impossible.
the
There is a two-dimensional room in which you fly, following the mouse pointer, space ships.
You need to create a Protocol so that:
the
Disclaimer:
The final result is very simple.
But try for purity of experiment to come up with your own version before reading the article below when writing reviews to avoid the effect of hindsight.
the
Let each client when rendering each frame sends to the server the position of mouse cursor.
And the server receives it immediately considers the current coordinates of the ship and sends them to all clients (including the person who passed the mouse coordinates).
It's simple. The simultaneity is achieved here.
And it even works while we have the server locally, and customers quite a bit.
In conditions close to reality this approach provided three things: crazy traffic (which is way higher than the traffic of the same agar.io), the periodic "jumping" ships (instead of a smooth flight) and wild lag, which usually began within 3-5 minutes, and then were not and have never been "treated" only a restart of the browser.
the
The first edit was obvious: it is wrong to send move the ship immediately after receiving the control command from the client.
If you do so, the periodicity of receipt of the commands to the clients from the server depends on three things:
the
There are too many variables. Measurements showed that the teams that are in the idea are sent every 20ms come with a random interval of 5 to 90 milliseconds.
The solution to this problem was simple — instead of immediately sending a command to the client is done sending, timer — one team in 20ms.
"Jumping" ships decreased markedly...
the
... but not gone.
At some point, obeying the network lag, another package came with a great delay. Not through 20 MS, and after 100, for example.
Accordingly, the ship is first slowed, and then abruptly took off and "teleported" a few pixels.
And then there was a weird idea: let's in the event of such delays are going to move the boat in the same direction in which he was flying earlier.
Maybe the picture will become smoother? This idea didn't work, but it was a step in the direction of the correct solution.
And so, the ship on the client all the time now (i.e. every frame) flies with its constant speed.
Come from the server team to change this speed, and the corrections for the coordinates of the ship.
The result? Rare is jumping on the long haul our boats began to make a series of diyachkov short distances.
It turned out that from the client's point of view the ship is in one place, and from the point of view of the server in the other.
Sent from the server "amendments" and led to micropascal.
The future may serve as an example as the two -retarded not really a good idea, implemented consistently, can give an unexpected result:
And let's send a correction a little and see what happens!
Nothing good, of course, not out — jumping again become more rare and long.
But I noticed that the management of the boat becomes less responsive even when magnification of the interval between the sending of the amendment.
the
But that means I have absolutely nothing mixed two characteristic quantities: FPS — the need to move the boat through the screen 60 times per second, and sending a control signal from the mouse.
The control signal can be sent much less often because it correlates not with the peculiarities of human vision, and with the speed of human reactions.
And it is about 200-250ms!
Based on the ping to the server (about 100 MS), this meant that the control signals can be sent approximately every 100-150мс, and smooth movement is to provide the client.
In the end, the fourth version of the Protocol was as follows:
the
The bonus of this version is a sharp decrease in traffic. He was now the same as on agar (I think Matheus Valadares knew something!).
But most importantly — automatically solved the problem of severe lag, coming every 3-5 minutes and is incurable by anything.
(After a few days I got here this article and it became clear what happened there).
Now remained only one problem — small prygocki ships during synchronization.
the
If the synchronization is not to do or do it rarely, the location of ships on the server and the clients were different, which of course was unacceptable.
But to endure prygocki, which turned into downright full hops in any network delay, we didn't want.
Initial idea looked like this: what if we "smudge" the timing? That will not immediately move the boat to the desired point, and tell him to move there for 7-8 frames?
— True, but this additional delay...
And by the way, we're changing the speed of the boat only once in 120ms. So we know where he will be in 120ms!
— From this place more!
Thus was born a simple (while discussing it in hindsight) idea: instead of synchronization, the server sends the client the coordinates of the ship on which it should be 120ms.
And the whole Protocol was:
the
This Protocol has solved all the problems. It is resistant to packet delay.
Even if for some reason upon receiving the new target ship has not reached (or overshot) the former, it would have no impact on ride — only slightly adjust the speed.
Now we are satisfied with the Protocol. The result can be seen here: https://spacewar.io
Article based on information from habrahabr.ru
What is IO-game
the name assigned to the browser-based, client-server multiplayer games in real time.
The mechanics of these games are usually relatively simple and interest is achieved through epic battles between a large number of real players.
The founder of the genre is agar.io
The mechanics of these games are usually relatively simple and interest is achieved through epic battles between a large number of real players.
The founder of the genre is agar.io
Many people know that in such games use websocket. And it's not complicated to create your own Protocol over it. I thought so when about a year ago we started the project space shooter in this style.
Now I don't think so.
the
the problem
The main problem that must be solved for all developers of multiplayer games — achieving "simultaneity" of the events.
Naive approach: let's I'm going to move your character, sending these movements to the server, and the server will send them to my opponents — not working. If you do so, your character will live in real-time, and his rivals in the past. Their movements will lag by about two to ping the server. For example, if the ping is 100ms, you'll see where the opponents 200ms ago. Accordingly, play would be impossible.
the
problem Statement
There is a two-dimensional room in which you fly, following the mouse pointer, space ships.
You need to create a Protocol so that:
the
- all "pilots" the picture was the same and displayed all the ships at any one time
the move was smooth the
Disclaimer:
The final result is very simple.
But try for purity of experiment to come up with your own version before reading the article below when writing reviews to avoid the effect of hindsight.
the
First solution
Let each client when rendering each frame sends to the server the position of mouse cursor.
And the server receives it immediately considers the current coordinates of the ship and sends them to all clients (including the person who passed the mouse coordinates).
It's simple. The simultaneity is achieved here.
And it even works while we have the server locally, and customers quite a bit.
In conditions close to reality this approach provided three things: crazy traffic (which is way higher than the traffic of the same agar.io), the periodic "jumping" ships (instead of a smooth flight) and wild lag, which usually began within 3-5 minutes, and then were not and have never been "treated" only a restart of the browser.
the
the Second version of the Protocol
The first edit was obvious: it is wrong to send move the ship immediately after receiving the control command from the client.
If you do so, the periodicity of receipt of the commands to the clients from the server depends on three things:
the
-
the
- the frequency of their sending a ship to the server the
- load feed from boat to server the
- and load channels from the server to other clients
There are too many variables. Measurements showed that the teams that are in the idea are sent every 20ms come with a random interval of 5 to 90 milliseconds.
The solution to this problem was simple — instead of immediately sending a command to the client is done sending, timer — one team in 20ms.
"Jumping" ships decreased markedly...
the
Third version
... but not gone.
At some point, obeying the network lag, another package came with a great delay. Not through 20 MS, and after 100, for example.
Accordingly, the ship is first slowed, and then abruptly took off and "teleported" a few pixels.
And then there was a weird idea: let's in the event of such delays are going to move the boat in the same direction in which he was flying earlier.
Maybe the picture will become smoother? This idea didn't work, but it was a step in the direction of the correct solution.
And so, the ship on the client all the time now (i.e. every frame) flies with its constant speed.
Come from the server team to change this speed, and the corrections for the coordinates of the ship.
The result? Rare is jumping on the long haul our boats began to make a series of diyachkov short distances.
It turned out that from the client's point of view the ship is in one place, and from the point of view of the server in the other.
Sent from the server "amendments" and led to micropascal.
The future may serve as an example as the two -
And let's send a correction a little and see what happens!
Nothing good, of course, not out — jumping again become more rare and long.
But I noticed that the management of the boat becomes less responsive even when magnification of the interval between the sending of the amendment.
the
Fourth version
But that means I have absolutely nothing mixed two characteristic quantities: FPS — the need to move the boat through the screen 60 times per second, and sending a control signal from the mouse.
The control signal can be sent much less often because it correlates not with the peculiarities of human vision, and with the speed of human reactions.
And it is about 200-250ms!
Based on the ping to the server (about 100 MS), this meant that the control signals can be sent approximately every 100-150мс, and smooth movement is to provide the client.
In the end, the fourth version of the Protocol was as follows:
the
- upon receiving this control command, the server counted the coordinates of the ship the
- asynchronously, on the server working thread, which is exactly once in the same 120ms sent the coordinates and speed for customers the
- after receiving the coordinates, the clients moved the ships in this new point and the speed used for smooth motion of the ship with the aim of achieving acceptable FPS
the client sent to the server the mouse position once in 120ms the
The bonus of this version is a sharp decrease in traffic. He was now the same as on agar (I think Matheus Valadares knew something!).
But most importantly — automatically solved the problem of severe lag, coming every 3-5 minutes and is incurable by anything.
(After a few days I got here this article and it became clear what happened there).
Now remained only one problem — small prygocki ships during synchronization.
the
Version of the fifth — end
If the synchronization is not to do or do it rarely, the location of ships on the server and the clients were different, which of course was unacceptable.
But to endure prygocki, which turned into downright full hops in any network delay, we didn't want.
Initial idea looked like this: what if we "smudge" the timing? That will not immediately move the boat to the desired point, and tell him to move there for 7-8 frames?
— True, but this additional delay...
And by the way, we're changing the speed of the boat only once in 120ms. So we know where he will be in 120ms!
— From this place more!
Thus was born a simple (while discussing it in hindsight) idea: instead of synchronization, the server sends the client the coordinates of the ship on which it should be 120ms.
And the whole Protocol was:
the
-
the
- the client sends to the server the mouse position once in 120ms the
- upon receiving this control command, the server recalculates the coordinates of the ship the
- asynchronously, the server runs a thread that exactly once in the same 120ms sends to clients the location where the ship should be by the end of next 120ms
This Protocol has solved all the problems. It is resistant to packet delay.
Even if for some reason upon receiving the new target ship has not reached (or overshot) the former, it would have no impact on ride — only slightly adjust the speed.
Now we are satisfied with the Protocol. The result can be seen here: https://spacewar.io
Комментарии
Отправить комментарий