Lag (video games)

While a single-player game maintains the main game state on the local machine, an online game requires it to be maintained on a central server in order to avoid inconsistencies between individual clients. As such, the client has no direct control over the central game state and may only send change requests to the server, and can only update the local game state by receiving updates from the server. This need to communicate causes a delay between the clients and the server, and is the fundamental cause behind lag. While there may be numerous underlying reasons for why a player experiences lag, most common reasons are poor connection between the client and server, or insufficient processing in either the client or the server. Connection Perhaps the most common type of lag is caused by network performance problems. Losses, corruption or jitter (an outdated packet is in effect a loss) may all cause problems, but these problems are relatively rare in a network with sufficient bandwidth and no or little congestion. Instead, the latency involved in transmitting data between clients and server plays a significant role. Latency varies depending on a number of factors, such as the physical distance between the end-systems, as a longer distance means additional transmission length and routing required and therefore higher latency. Routing over the Internet may be extremely indirect, resulting in far more transmission length (and consequent latency) than a direct route, although the cloud gaming service OnLive has developed a solution to this issue by establishing peering relationships with multiple Tier 1 network Internet Service Providers and choosing an optimal route between server and user. This usage is a gaming cultural colloquialism and is not commonly found or used in professional computer networking circles. Some factors that might particularly affect ping include: communication protocol used, Internet throughput (connection speed), the quality of a user's Internet service provider and the configuration of firewalls. Ping is also affected by geographical location. For instance, if someone is in India, playing on a server located in the United States, the distance between the two is greater than it would be for players located within the US, and therefore it takes longer for data to be transmitted, resulting at 20,000 km (halfway around the Earth) in a ping of 133 ms. However, the amount of packet-switching and network hardware in between the two computers is often more significant. For instance, wireless network interface cards must modulate digital signals into radio signals, which is often more costly than the time it takes an electrical signal to traverse a typical span of cable. As such, lower ping can result in faster Internet download and upload rates. Interface Input-lag Input-lag or input latency is the lag produced by the input device, such as a mouse, keyboard or other controller, and its connection. Wireless devices are particularly affected by this kind of lag. Some people claim to notice extra lag when using a wireless controller, while other people claim that the 4–8 milliseconds of lag is negligible. The refresh rate is a type or part of input-lag that is the rate of a display to produce distinct picture, measured in Hz (e.g. 60, 240 or 360, that is 16.7, 4.2 or 2.8 ms respectively). Display lag This is the lag caused by the television or monitor (also called output lag). In addition to the latency imposed by the screen's pixel response time, any image processing (such as upscaling, motion smoothing, or edge smoothing) takes time and therefore adds more input lag. An input lag below 30 ms is generally considered unnoticeable in a television. Once the frame has been processed, the final step is the updating the pixels to display the correct color for the new frame. The time this takes is called the pixel response time. == Effects ==

The noticeable effects of lag vary not only depending on the exact cause, but also on all techniques for lag compensation that the game may implement (described below). As all clients experience some delay, implementing these methods to minimize the effect on players is important for smooth gameplay. Lag causes numerous problems for issues such as accurate rendering of the game state and hit detection. In many games, lag is often frowned upon because it disrupts normal gameplay. The severity of lag depends on the type of game and its inherent tolerance for lag. Some games with a slower pace can tolerate significant delays without any need to compensate at all, whereas others with a faster pace are considerably more sensitive and require extensive use of compensation to be playable (such as the first-person shooter genre). Due to the various problems lag can cause, players that have an insufficiently fast Internet connection are sometimes not permitted, or discouraged from playing with other players or servers that have a distant server host or have high latency to one another. Extreme cases of lag may result in extensive desynchronization of the game state. Lag due to an insufficient update rate between client and server can cause some problems, but these are generally limited to the client itself. Other players may notice jerky movement and similar problems with the player associated with the affected client, but the real problem lies with the client itself. If the client cannot update the game state at a quick enough pace, the player may be shown outdated renditions of the game, which in turn cause various problems with hit- and collision detection. Testing has found that overall input lag (from human input to visible response) times of approximately are distracting to the user. It also appears that (excluding the monitor/television display lag) is an average response time and the most sensitive games (fighting games, first person shooters and rhythm games) achieve response times of (excluding display lag). == 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 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. 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. Rewind time Another way to address the issue is to store past game states for a certain length of time, then rewind player locations when processing a command. The server uses the latency of the player (including any inherent delay due to interpolation; see above) to rewind time by an appropriate amount in order to determine what the shooting client saw at the time the shot was fired. This will usually result in the server seeing the client firing at the target's old position and thus hitting. In the worst case, a player will be so far behind that the server runs out of historical data and they have to start leading their targets. This is a WYSIWYG solution that allows players to aim directly at what they are seeing. But the price is an aggravation of the effects of latency when a player is under fire: not only does their own latency play a part, but their attacker's too. In many situations, this is not noticeable, but players who have just taken cover will notice that they carry on receiving damage/death messages from the server for longer than their own latency can justify. This can lead more often to the (false) impression that they were shot through cover and the (not entirely inaccurate) impression of "laggy hitboxes". Trusting a client's results otherwise has the same advantages and disadvantages as rewinding. Make clients extrapolate A less common lag solution is to do nothing on the server and to have each client extrapolate (see above) to cover its latency. This produces incorrect results unless remote players maintain a constant velocity, granting an advantage to those who dodge back and forth or simply start/stop moving. Extended extrapolation also results in remote players becoming visible (though not vulnerable) when they should not be: for example if a remote player sprints up to a corner then stops abruptly at the edge, other clients will render them sprinting onward, into the open, for the duration of their own latency. On the other side of this problem, clients have to give remote players who just started moving an extra burst of speed in order to push them into a theoretically accurate predicted location. 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. == Cloud gaming ==

Cloud gaming is a type of online gaming where the entire game is hosted on a game server in a data center, and the user is only running a thin client locally that forwards game controller actions upstream to the game server. The game server then renders the next frame of the game video which is compressed using low-lag video compression and is sent downstream and decompressed by the thin client. For the cloud gaming experience to be acceptable, the round-trip lag of all elements of the cloud gaming system (the thin client, the Internet and/or LAN connection the game server, the game execution on the game server, the video and audio compression and decompression, and the display of the video on a display device) must be low enough that the user perception is that the game is running locally. Because of such tight lag requirements, distance considerations of the speed of light through optical fiber come into play, currently limiting the distance between a user and a cloud gaming game server to approximately 1000 miles, according to OnLive. There is also much controversy about the lag associated with cloud gaming. In multiplayer games using a client/server network architecture, the player's computer renders the game's graphics locally and only information about the player's in-game actions are sent to the server. For example, when the player presses a button, the character on-screen instantly performs the corresponding action. However, the consequences of the action such as an enemy being killed are only seen after a short delay due to the time taken for the action to reach the server. This is only acceptable as long as the response to the player's input is fast enough. When using cloud gaming, inputs by the player can lead to short delays until a response can be seen by them. Inputs must first be transmitted to the remote server, then the server must start rendering the graphics of the action being performed and stream the video back to the player over the network, taking additional time. Thus, the player experiences a noticeable delay between pressing a button and seeing something happen on-screen. Depending on the skill and experience of the player, this can cause disorientation and confusion similar to Delayed Auditory Feedback and hampers navigation and aiming in the game world. When rapidly inputting a long combination move, the on-screen character will not be synchronized with the button presses. This usually causes severe confusion in the player resulting in the failure of the combination move. The extra input lag can also make it very difficult to play certain single player games. For example, if an enemy takes a swing at the player and the player is expected to block, then by the time the player's screen shows that the enemy has commenced attacking, the enemy would have already struck and killed the player on the server. ==Special Use==

"Ka le" In Dota 2 Ka le or Kale, , is a gaming slang and Internet phrase referring to lag. It is from Chinese phrase () and was first used in Dota 2 Asia Championships 2015, when some Chinese players typed it in chat to complain about their annoying game lags and request to pause. As the Chinese Dota 2 scene became popular, this expression became known as well. Many western players, professionals and amateurs alike, often type "kale" instead of "lag" in in-game chat and Twitch. == See also ==