Is the Udp Server Too Slow?

So, I do MMO, I progressed a lot, 6 months programmed this thing. The problem is that I tested my game offline, today I have a brilliant idea to port my server and make it online, I knew that it would be a little slower, but it's awful! too much lag !!! the game is unplayable. Im running my packages so ...

The player wants to move up, the client sends movePacket to the server, the server receives it, moves the player to the server and sends a new position to all clients ... Each time a monster moves, the server sends a new position to all clients ...

I thought I switched to sending packets, but I only test it with the movement of the player ... it looks like it has a significant delay to receive the packet and send it to the client .... Im I doing all this wrong?

+4
source share
1 answer

Lag is always a problem with online games. Although your current method is the standard way to do something, since your lag detection becomes unbearable (a common problem in 1990 games and early 2000). The best approach is the same approach as almost all modern games that make as much as you can on the client side and use only your authoritative server to eliminate the differences between the forecasts made by clients. Here are some useful ways to reduce perceived lag:

  • Client side forecast
    For an MMO, this may be all you need. The main idea of ​​client-side forecasting is to locally figure out what to do. In your game, when a player wants to move up, he sends a packet that says [request: 1 content: moveup], then, before receiving a response from the server, the client displays the Player moving alone (if you can’t already say that such a move is invalid, i.e. moving up would mean running into the wall). If your server is really slow, the player can also move right before receiving a response, so your next packet package may look like [request: 2 content: moveright], at this point you are showing the player on the right. Keep in mind that at this moment the player has already moved up and right before the server even confirmed that moving up is an acceptable step. Now, if the server replies that the new position of the player after package 1 should be raised, and the position after package 2 should be right, everything is fine. However, if it can be said that the steps of another player are greater than Player, then the server can respond with the player in a new place. At this point, the player will "teleport" to where the server tells him what he should be. This does not happen often, but when it happens, it can be extremely noticeable (you probably noticed this in commercial fps games).

  • Interpolation
    At the moment, yours is probably well suited for an MMO game, but if it is not (or for a future reference), then your next step will be interpolation. The idea here is to send more data on the bets at which the values ​​change in order to make the movement of other players smoother. This is the same concept as using a series of tiles in mathematics to predict values ​​for a function. In this case, you can send a position, as well as speed and, possibly, acceleration data for all objects in the game. Thus, the new position can be calculated as x = x + v * t + 0.5 * att, where t is the frame rate. Again, you show the predicted position of the player before the server really confirms that this is the correct position. When the next packet comes from the server, you will inevitably be mistaken most of the time, but the more data about the transmission speed you send, the less you will be disconnected and, therefore, the less teleportation of other objects.

If you want a more detailed description of how to deal with the delay in online games, read the mini-bible in multiplayer games: http://www.gabrielgambetta.com/fast_paced_multiplayer.html

+4
source

All Articles