Lag (video games)

Last updated

In computers, lag is delay (latency) between the action of the user (input) and the reaction of the server supporting the task, which has to be sent back to the client.

Contents

The player's ability to tolerate lag depends on the type of game being played. For instance, a strategy game or a turn-based game with a slow pace may have a high threshold or even be mostly unaffected by high lag. A game with twitch gameplay such as a first-person shooter or a fighting game with a considerably faster pace may require a significantly lower lag to provide satisfying gameplay.

An in-game display of lag rate is sometimes called a lagometer. [1]

Ping time

Ping time is the network delay for a round trip between a player's client and the game server as measured with the ping utility or equivalent. Ping time is an average time measured in milliseconds (ms).[ citation needed ] The lower one's ping is, the lower the latency is and the less lag the player will experience. High ping and low ping are commonly used terms in online gaming, where high ping refers to a ping that causes a severe amount of lag; while any level of ping may cause lag, severe lag is usually indicated by a ping of over 100 ms. [2] This usage is a gaming cultural colloquialism and is not commonly found or used in professional computer networking circles. In games where timing is key, such as first-person shooter and real-time strategy games, a low ping is always desirable, as a low ping means smoother gameplay by allowing faster updates of game data between the players' clients and game server.

High latency can cause lag. Game servers may disconnect a client if the latency is too high and may pose a detriment to other players' gameplay. Similarly, client software will often mandate disconnection if the latency is too high. High ping may also cause servers to crash due to instability.

In some first-person shooter games, a high ping may cause the player to unintentionally gain unfair advantages, such as disappearing from one location and instantaneously reappearing in another, simulating the effect of teleportation, thus making it hard for other players to judge their character's position and subsequently making the player much more difficult to target. To counter this, many game servers automatically kick players with a ping higher than average. Conversely, a high ping can make it very difficult for the player to play the game due to negative effects occurring, making it difficult for the player to track other players and even move their character.

Rather than using the traditional ICMP echo request and reply network packets to determine ping times, video game programmers often build their own latency detection into existing game packets (usually based on the UDP protocol) instead.

Some factors that might 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. 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.

Causes

A simplified game architecture Gameloop.PNG
A simplified game architecture

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, they can be summarized as insufficient hardware in either the client or the server, or a poor connection between the client and server. [3]

Hardware related issues cause lag due to the fundamental structure of the game architecture. Generally, games consist of a looped sequence of states, or "frames". During each frame, the game accepts user input and performs necessary calculations (AI, graphics etc.). When all processing is finished, the game will update the game state and produce an output, such as a new image on the screen and/or a packet to be sent to the server. The frequency at which frames are generated is often referred to as the frame rate. As the central game state is located on the server, the updated information must be sent from the client to the server in order to take effect. In addition, the client must receive the necessary information from the server in order to fully update the state. Generating packets to send to the server and processing the received packets can only be done as often as the client is able to update its local state. Although packets could theoretically be generated and sent faster than this, it would only result in sending redundant data if the game state cannot be updated between each packet. A low frame rate would, therefore, make the game less responsive to updates and may force it to skip outdated data.

Conversely, the same holds true for the server. The frame rate (or tick rate) of the server determines how often it can process data from clients and send updates. This type of problem is difficult to predict and compensate for. Apart from enforcing minimum hardware requirements and attempting to optimize the game for better performance, there are no feasible ways to deal with it.

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. [4] In addition, insufficient bandwidth and congestion, even if not severe enough to cause losses, may cause additional delays regardless of distance. As with the hardware issues, packets that arrive slowly or not at all will make both the client and server unable to update the game state in a timely manner.

Online game systems utilizing a wireless network may be subject to significant lag, depending on the architecture of the wireless network and local electromagnetic interference impacting that network. Electromagnetic interference (e.g. from a microwave oven) can cause transmitted packets to be lost, requiring a retransmission which incurs latency. Although radio propagation through the air is faster than light through an optical fiber, wireless systems are often shared among many users and may suffer from latency incurred due to network congestion, or due to network protocols that introduce latency.

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. [5] 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. [6] If the low update rate is caused by a low frame rate (as opposed to a setting on the client, as some games allow), these problems are usually overshadowed by numerous problems related to the client-side processing itself. Both the display and controls will be sluggish and unresponsive. While this may increase the perceived lag, it is important to note that it is of a different kind than network-related delays. In comparison, the same problem on the server may cause significant problems for all clients involved. If the server is unable or unwilling to accept packets from clients fast enough and process these in a timely manner, client actions may never be registered. When the server then sends out updates to the clients, they may experience freezing (unresponsive game) and/or rollbacks, depending on what types of lag compensation, if any, the game uses.

Lag due to network delay is, in contrast, often less of a problem. Though more common, the actual effects are generally smaller, and it is possible to compensate for these types of delays. Without any form of lag compensation, the clients will notice that the game responds only a short time after an action is performed. This is especially problematic in first-person shooters, where enemies are likely to move as a player attempts to shoot them and the margin for errors is often small.

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. [7]

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. [8] For example, the client can state exactly at what position a player's character is or who the character 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 on 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. [8]

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.

Often, in order to allow smooth gameplay, the client is allowed to do soft changes to the game state. While the server may ultimately keep track of ammunition, health, position, etc., the client may be allowed to predict the new server-side game state based on the player's actions, such as allowing a player to start moving before the server has responded to the command. These changes will generally be accepted under normal conditions and make delay mostly transparent. Problems will arise only in the case of high delays or losses, when the client's predictions are very noticeably undone by the server. Sometimes, in the case of minor differences, the server may even allow "incorrect" changes to the state based on updates from the client.

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. [9] 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. [8] 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". [8]

One design issue that arises from rewinding is whether to stop rewinding a dead player's lagged commands as soon as they die on the server, or to continue running them until they "catch up" to the time of death. Cutting compensation off immediately prevents victims from posthumously attacking their killers, which meets expectations, but preserves the natural advantage of moving players who round a corner, acquire a target and kill them in less time than a round trip to the stationary victim's client.

Rewinding can be criticized for allowing the high latency of one player to negatively affect the experience of low-latency players. Servers with lag compensation will sometimes reduce the length of player history stored, or enforce ping limits, to reduce this problem.

Trust clients

It is possible for clients to tell the server what they are doing and for the server to trust the data it receives. This method is avoided if at all possible due to its susceptibility to cheating: it is a simple matter to route network data through a second computer which inserts fabricated hit messages or modifies existing ones, a technique which cannot be detected by anti-cheat tools. [8]

However, the sheer scale of some games makes computationally expensive solutions like rewinding impossible. In Battlefield 3 , for example, a "hybrid hit detection" system is used where clients tell the server that they hit and the server performs only a vague test of plausibility before accepting the claim. [10]

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. [11] 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. [12]

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. [4] [13] 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. [14] 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.

Related Research Articles

Latency, from a general point of view, is a time delay between the cause and the effect of some physical change in the system being observed. Lag, as it is known in gaming circles, refers to the latency between the input to a simulation and the visual or auditory response, often occurring because of network delay in online games.

In telecommunications, round-trip delay (RTD) or round-trip time (RTT) is the amount of time it takes for a signal to be sent plus the amount of time it takes for acknowledgement of that signal having been received. This time delay includes propagation times for the paths between the two communication endpoints. In the context of computer networks, the signal is typically a data packet. RTT is also known as ping time, and can be determined with the ping command.

A multiplayer video game is a video game in which more than one person can play in the same game environment at the same time, either locally on the same computing system, on different computing systems via a local area network, or via a wide area network, most commonly the Internet. Multiplayer games usually require players to share a single game system or use networking technology to play together over a greater distance; players may compete against one or more human contestants, work cooperatively with a human partner to achieve a common goal, or supervise other players' activity. Due to multiplayer games allowing players to interact with other individuals, they provide an element of social communication absent from single-player games.

<i>SubSpace</i> (video game) 1997 video game

SubSpace is a 2D space shooter video game created in 1995 and released in 1997 by Virgin Interactive which was a finalist for the Academy of Interactive Arts & Sciences Online Game of the Year Award in 1998. SubSpace incorporates quasi-realistic zero-friction physics into a massively multiplayer online game.

<span class="mw-page-title-main">Cheating in online games</span> Practice of subverting video game rules or mechanics to gain an unfair advantage

On online games, cheating subverts the rules or mechanics of the games to gain an unfair advantage over other players, generally with the use of third-party software. What constitutes cheating is dependent on the game in question, its rules, and consensus opinion as to whether a particular activity is considered to be cheating.

Client-side prediction is a network programming technique used in video games intended to conceal negative effects of high latency connections. The technique attempts to make the player's input feel more instantaneous while governing the player's actions on a remote server.

Nagle's algorithm is a means of improving the efficiency of TCP/IP networks by reducing the number of packets that need to be sent over the network. It was defined by John Nagle while working for Ford Aerospace. It was published in 1984 as a Request for Comments (RFC) with title Congestion Control in IP/TCP Internetworks in RFC 896.

An Internet chess server (ICS) is an external server that provides the facility to play, discuss, and view the board game of chess over the Internet. The term specifically refers to facilities for connecting players through a variety of graphical chess clients located on each user's computer.

Packet loss occurs when one or more packets of data travelling across a computer network fail to reach their destination. Packet loss is either caused by errors in data transmission, typically across wireless networks, or network congestion. Packet loss is measured as a percentage of packets lost with respect to packets sent.

A game server is a server which is the authoritative source of events in a multiplayer video game. The server transmits enough data about its internal state to allow its connected clients to maintain their own accurate version of the game world for display to players. They also receive and process each player's input.

Capacity management's goal is to ensure that information technology resources are sufficient to meet upcoming business requirements cost-effectively. One common interpretation of capacity management is described in the ITIL framework. ITIL version 3 views capacity management as comprising three sub-processes: business capacity management, service capacity management, and component capacity management.

The lockstep protocol is a partial solution to the look-ahead cheating problem in peer-to-peer architecture multiplayer games, in which a cheating client delays their own actions to await the messages of other players. A client can do so by acting as if they're suffering from high latency; the outgoing packet is forged by attaching a time stamp that is prior to the actual moment the packet is sent.

Deflection shooting is a technique of shooting ahead of a moving target, also known as leading the target, so that the projectile will "intercept" and collide with the target at a predicted point. This technique is only necessary when the target will have significantly displaced its position during the time the projectile would take to reach the target, which can become the case over very long distances, due to fast moving targets, or while using relatively slow projectiles.

Display lag is a phenomenon associated with most types of liquid crystal displays (LCDs) like smartphones and computers and nearly all types of high-definition televisions (HDTVs). It refers to latency, or lag between when the signal is sent to the display and when the display starts to show that signal. This lag time has been measured as high as 68 ms, or the equivalent of 3-4 frames on a 60 Hz display. Display lag is not to be confused with pixel response time, which is the amount of time it takes for a pixel to change from one brightness value to another. Currently the majority of manufacturers quote the pixel response time, but neglect to report display lag.

<span class="mw-page-title-main">OnLive</span> Company offering a cloud gaming platform

OnLive was a provider of cloud virtualization technologies based in Mountain View, California. OnLive's flagship product was its cloud gaming service, which allowed subscribers to rent or demo computer games without installing them. Games were delivered as streaming video rendered by the service's servers, rather than running on the local device. This setup allowed the games to run on computers and devices that would normally be unable to run them due to insufficient hardware. OnLive also enabled other features such as the ability for players to record gameplay and to spectate.

Delta time or delta timing is a concept used amongst programmers in relation to hardware and network responsiveness. In graphics programming, the term is usually used for variably updating scenery based on the elapsed time since the game last updated, which will vary depending on the speed of the computer, and how much work needs to be done in the program at any given time. This also allows graphics to be calculated separately if graphics are being multi-threaded.

Bufferbloat is a cause of high latency and jitter in packet-switched networks caused by excess buffering of packets. Bufferbloat can also cause packet delay variation, as well as reduce the overall network throughput. When a router or switch is configured to use excessively large buffers, even very high-speed networks can become practically unusable for many interactive applications like voice over IP (VoIP), audio streaming, online gaming, and even ordinary web browsing.

This list includes terms used in video games and the video game industry, as well as slang used by players.

Netcode is a blanket term most commonly used by gamers relating to networking in online games, often referring to synchronization issues between clients and servers. Players often infer "bad netcodes" when they experience lag or when their inputs are dropped. Common causes of such issues include high latency between server and client, packet loss, network congestion, and external factors independent to network quality such as frame rendering time or inconsistent frame rates. Netcodes may be designed to uphold a synchronous and seamless experience between users despite these networking challenges.

<span class="mw-page-title-main">Jamulus</span> Live music collaboration software

Jamulus is open source (GPL) networked music performance software that enables live rehearsing, jamming and performing with musicians located anywhere on the internet. Jamulus is written by Volker Fischer and contributors using C++. The Software is based on the Qt framework and uses the OPUS audio codec. It was known as "llcon" until 2013.

References

  1. "Optimize XP for Multiplayer Mayhem". Maximum PC. Vol. Summer. Future US, Inc. 2004. p. 49.
  2. "How to Get Rid of Lag | GeForce". www.geforce.com. Archived from the original on 2018-09-13. Retrieved 2018-09-13.
  3. Cronin, Eric; Filstrup, Burton; Anthony, Kurc. "A Distributed Multiplayer Game Server System" (PDF). University of Michigan. Archived (PDF) from the original on 4 August 2016. Retrieved 16 July 2014.
  4. 1 2 "The Process of Invention: OnLive Video Game Service". The FU Foundation School of Engineering & Applied Science (Columbia University). Archived from the original on 2012-12-20. Retrieved 2010-01-23.
  5. Smith, Joshua. "Distributed Game Architecture To Overcome System Latency" (PDF). United States Patent. Archived (PDF) from the original on 28 October 2017. Retrieved 16 July 2014.
  6. Claypool, Mark; Claypool, Kajal. "Latency Can Kill: Precision and Deadline in Online Games". Archived from the original on 29 June 2014. Retrieved 16 July 2014.
  7. Roelofs, Gregory. "Compensating For Network Latency In A Multi-Player Game" (PDF). United States Patent. Archived (PDF) from the original on 28 April 2016. Retrieved 16 July 2014.
  8. 1 2 3 4 5 Bernier, Yahn (2001). "Latency Compensating Methods in Client/Server In-game Protocol Design and Optimization". Valve. Archived from the original on 30 June 2019. Retrieved 17 September 2011.
  9. Kahn, Adam S.; Williams, Dmitri (June 2016). "We're All in This (Game) Together: Transactive Memory Systems, Social Presence, and Team Structure in Multiplayer Online Battle Arenas". Communication Research. 43 (4): 487–517. doi:10.1177/0093650215617504. ISSN   0093-6502. S2CID   29776927.
  10. Kertz, Alan (December 11, 2011). "Re: We need someone to create a guide for the new Network Interpolation Setting slider". Archived from the original on 14 March 2017. Retrieved 4 November 2013. BF3's hit model uses a combined client server model, a Hybrid Hit Detection. The client says to the server "Hey, I shot him!" and the server does a check against the position of the two targets and determines if the player could reasonably have hit that target and then applies the damage.
  11. Gibson, John (5 December 2010). "Re: Will HoS present the netcode disadvantages of UE3?". Tripwire Interactive. Archived from the original on 10 March 2016. Retrieved 18 September 2011.
  12. Aldridge, David (2011). "I Shot You First: Networking the Gameplay of HALO: REACH". Game Developers Conference 2011. GDC Vault. Archived from the original on 2019-05-19. Retrieved 2014-07-14.
  13. "D8 Video:OnLive demoed on iPad, PC, Mac, Console, iPhone". Wall Street Journal. 2010-08-09. Archived from the original on 2011-02-12. Retrieved 2010-08-19.
  14. "Beta Testing at the Speed of Light". OnLive. 2010-01-21. Archived from the original on 2012-12-16. Retrieved 2010-01-23.