MadeOfMetal
Kenshi Srubtastic,Cyrax, Special Forces Mains
I make this thread in hopes that all of us can bond together to help devise a plan to rid MKX of lag between Clients and Servers if at all possible!
lets start with the Basics...
Netcode is a blanket term for anything that somehow relates to networking in online games; netcode is a term most commonly used by gamers when discussing synchronization issues between clients and servers. The actual elements of a game engine that can cause so-called "netcode issues" include, among other things, latency, lag compensation or the lack thereof, simulation errors, and network issues between the client and server that are completely out of the game's hands.
Potential causes of netcode issues:
Ideas: posted by others:
this could be similar to BF4's fix or League of Legends PBE
i think this in time could fix before the tournament scene is over... maybe make mkx playable for years, im interested what others think about flipping this to NRS?
now with all this said, What can we all do or suggest to NRS/WB to get this Netcode issue solved?
i say we should try an open beta environment or something along those lines, could work but may not solve all problems, maybe in time, i would really like MKX or MK11 to benefit from this before it's to late.
post your solution/idea below!
@WidowPuppy
@Temjiin
@KHAOTIC True Grave
@kabelfritz
@Bombardier777
@sub_on_dubs
@The Slaj Jazz
@Wetdoba
@LaidbackOne
@Houndovhell
@Marbledecker
@Eldriken
@Afk Skinny
@beepboop
@Death
@I GOT HANDS
tag anyone i forgot!
lets start with the Basics...
Netcode is a blanket term for anything that somehow relates to networking in online games; netcode is a term most commonly used by gamers when discussing synchronization issues between clients and servers. The actual elements of a game engine that can cause so-called "netcode issues" include, among other things, latency, lag compensation or the lack thereof, simulation errors, and network issues between the client and server that are completely out of the game's hands.
Potential causes of netcode issues:
-
Latency is an unavoidable fact of online games, caused by not only network latency, which is largely out of a game's control, but also latency inherent in the way game simulations are run. There are several lag compensation methods used to disguise, reduce, or cope with latency, however their feasibility varies by application.
-
Tickrate: A single update of a game simulation is known as a tick. The rate at which the simulation is run on a server is referred often to as the server's tickrate; this is essentially the server equivalent of a client's frame rate, absent any rendering system. Tickrate is limited by the length of time it takes to run the simulation, and is often intentionally limited further to reduce instability introduced by a fluctuating tickrate, and to reduce CPU and data transmission costs. A lower tickrate increases latency in the synchronization of the game simulation between the server and clients. Tickrate can vary from 60 ticks per seconds, to 30 ticks per seconds. A lower tickrate also naturally reduces the precision of the simulation, which itself might cause problems if taken too far, or if the client and server simulations are running at significantly different rates. Games may limit the number of times per second that updates are sent to a particular client, and/or are sent about particular objects in the game's world. Because of limitations in the amount of bandwidth available, and the CPU time that's taken by network communication, some games prioritize certain critical communication while limiting the frequency and priority of less important information. As with the tickrate, this effectively increases the synchronization latency. Game engines may also reduce the precision of some values sent over the network to help with bandwidth use; this lack of precision may in some instances be noticeable. Various simulation synchronization errors between machines can also fall under the "netcode issues" blanket. These may include bugs which cause the simulation to proceed differently on one machine than on another, or which cause some things to not be communicated when the user perceives that they ought to be. Traditionally, real-time strategy games have used lock-step peer-to-peer networking models where it is assumed the simulation will run exactly the same on all clients; if, however, one client falls out of step for any reason, the desynchronization may compound and be unrecoverable.
-
Transport layer protocol and communication code: A game's choice of transport layer protocol can also affect perceived networking issues. Should the game use TCP, networking will have a high overhead cost and increased latency. Should it use UDP, the game engine may need to implement its own networking code to handle error conditions and other things that are handled by TCP; this increases the engine's complexity and might itself lead to issues.
Solutions and lag compensation:
There are various methods for reducing or disguising delays, though many of these have their drawbacks and may not be applicable in all cases. If synchronization is not possible by the game itself, the clients themselves may be able to choose to play on servers in geographical proximity to themselves in order to reduce latencies, or the servers may simply opt to drop clients with high latencies in order to avoid having to deal with the resulting problems. However, these are hardly optimal solutions. Instead, games will often be designed with lag compensation in mind.
Many problems can be solved simply by allowing the clients to keep track of their own state and send absolute states to the server or directly to other clients. For example, the client can state exactly at what position it is or who they shot. This solution works and will all but eliminate most problems related to lag. Unfortunately, it also relies on the assumption that the client is honest. There is nothing that prevents a player from modifying the data they send, directly at the client or indirectly via a proxy, in order to ensure they will always hit their targets. In online games, the risk of cheating may make this solution unfeasible, and clients will be limited to sending relative states (i.e. which vector it moved or shot in).
There are various methods for reducing or disguising delays, though many of these have their drawbacks and may not be applicable in all cases. If synchronization is not possible by the game itself, the clients themselves may be able to choose to play on servers in geographical proximity to themselves in order to reduce latencies, or the servers may simply opt to drop clients with high latencies in order to avoid having to deal with the resulting problems. However, these are hardly optimal solutions. Instead, games will often be designed with lag compensation in mind.
Many problems can be solved simply by allowing the clients to keep track of their own state and send absolute states to the server or directly to other clients. For example, the client can state exactly at what position it is or who they shot. This solution works and will all but eliminate most problems related to lag. Unfortunately, it also relies on the assumption that the client is honest. There is nothing that prevents a player from modifying the data they send, directly at the client or indirectly via a proxy, in order to ensure they will always hit their targets. In online games, the risk of cheating may make this solution unfeasible, and clients will be limited to sending relative states (i.e. which vector it moved or shot in).
Client-side:
As clients are normally not allowed to define the main game state, but rather receive it from the server, the main task of the client-side compensation is to render the virtual world as accurately as possible. As updates come with a delay and may even be dropped, it is sometimes necessary for the client to predict the flow of the game. Since the state is updated in discrete steps, the client must be able to estimate a movement based on available samples. Two basic methods can be used to accomplish this; extrapolation and interpolation.
Extrapolation is an attempt to estimate a future game state. As soon as a packet from the server is received, the position of an object is updated to the new position. Awaiting the next update, the next position is extrapolated based on the current position and the movement at the time of the update. Essentially, the client will assume that a moving object will continue in the same direction. When a new packet is received, the position may be corrected slightly.
Interpolation works by essentially buffering a game state and rendering the game state to the player with a slight, constant delay. When a packet from the server arrives, instead of updating the position of an object immediately, the client will start to interpolate the position, starting from the last known position. Over an interpolation interval, the object will be rendered moving smoothly between the two positions. Ideally this interval should exactly match the delay between packets, but due to loss and variable delay, this is rarely the case.
Both methods have advantages and drawbacks.
As clients are normally not allowed to define the main game state, but rather receive it from the server, the main task of the client-side compensation is to render the virtual world as accurately as possible. As updates come with a delay and may even be dropped, it is sometimes necessary for the client to predict the flow of the game. Since the state is updated in discrete steps, the client must be able to estimate a movement based on available samples. Two basic methods can be used to accomplish this; extrapolation and interpolation.
Extrapolation is an attempt to estimate a future game state. As soon as a packet from the server is received, the position of an object is updated to the new position. Awaiting the next update, the next position is extrapolated based on the current position and the movement at the time of the update. Essentially, the client will assume that a moving object will continue in the same direction. When a new packet is received, the position may be corrected slightly.
Interpolation works by essentially buffering a game state and rendering the game state to the player with a slight, constant delay. When a packet from the server arrives, instead of updating the position of an object immediately, the client will start to interpolate the position, starting from the last known position. Over an interpolation interval, the object will be rendered moving smoothly between the two positions. Ideally this interval should exactly match the delay between packets, but due to loss and variable delay, this is rarely the case.
Both methods have advantages and drawbacks.
- Interpolation ensures that objects will move between valid positions only and will produce good results with constant delay and no loss. Should dropped or out-of-order packets overflow the interpolation buffer the client will have to either freeze the object in position until a new packet arrives, or fall back on extrapolation instead. The downside of interpolation is that it causes the world to be rendered with additional latency, increasing the need for some form of lag compensation to be implemented.
- The problem with extrapolating positions is fairly obvious: it is impossible to accurately predict the future. It will render movement correctly only if the movement is constant, but this will not always be the case. Players may change both speed and direction at random. This may result in a small amount of "warping" as new updates arrive and the estimated positions are corrected, and also cause problems for hit detection as players may be rendered in positions they are not actually in.
Server-side:
Unlike clients, the server knows the exact current game state, and as such prediction is unnecessary. The main purpose of server-side lag compensation is instead to provide accurate effects of client actions. This is important because by the time a player's command has arrived time will have moved on, and the world will no longer be in the state that the player saw when issuing their command. A very explicit example of this is hit detection for weapons fired in first-person shooters, where margins are small and can potentially cause significant problems if not properly handled.
Unlike clients, the server knows the exact current game state, and as such prediction is unnecessary. The main purpose of server-side lag compensation is instead to provide accurate effects of client actions. This is important because by the time a player's command has arrived time will have moved on, and the world will no longer be in the state that the player saw when issuing their command. A very explicit example of this is hit detection for weapons fired in first-person shooters, where margins are small and can potentially cause significant problems if not properly handled.
Design:
It is possible to reduce the perception of lag through game design. Techniques include playing client-side animations as if the action took place immediately, reducing/removing built-in timers on the host machine, and using camera transitions to hide warping.
It is possible to reduce the perception of lag through game design. Techniques include playing client-side animations as if the action took place immediately, reducing/removing built-in timers on the host machine, and using camera transitions to hide warping.
Ideas: posted by others:
and i feel this could be the open beta solution what does everyone else think?
this could be similar to BF4's fix or League of Legends PBE
i think this in time could fix before the tournament scene is over... maybe make mkx playable for years, im interested what others think about flipping this to NRS?
now with all this said, What can we all do or suggest to NRS/WB to get this Netcode issue solved?
i say we should try an open beta environment or something along those lines, could work but may not solve all problems, maybe in time, i would really like MKX or MK11 to benefit from this before it's to late.
post your solution/idea below!
@WidowPuppy
@Temjiin
@KHAOTIC True Grave
@kabelfritz
@Bombardier777
@sub_on_dubs
@The Slaj Jazz
@Wetdoba
@LaidbackOne
@Houndovhell
@Marbledecker
@Eldriken
@Afk Skinny
@beepboop
@Death
@I GOT HANDS
tag anyone i forgot!
Last edited:
