Game lag and Its solutions!

                                               WHAT IS GAME LAG!       


Lag is a common word meaning to fail to keep up or to fall behind. "Lag" is more commonly used to describe a slow internet connection or slow application on the computer, seen mostly on online mmorpg or multiplayer games. In real-time applications, the term is used when the application fails to respond in a timely fashion to inputs.
Lag is also often used in reference to video games to describe to the delay (or latency) between an action by a player and the reaction of the game.
In distributed applications, lag is often caused by communication latency, which is the time taken for a sent packet of data to be received at the other end. It includes the time to encode the packet for transmission and transmit it, the time for that data to traverse the network equipment between the nodes, and the time to receive and decode the data. This is also known as "one-way latency". A minimum bound on latency is determined by the distance between communicating devices and the speed at which the signal propagates in the circuits (typically 70–95% of the speed of light in vacuum). Actual latency is often much higher because of packet processing in networking equipment, and other traffic.
The term lag is often also used as a synonym for communication latency. This can be misleading because there can be other causes for the symptom.


Causes


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 while 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.
Hardware related issues causes lag due to the fundamental structure of the game architecture. Generally, games consists of a looped sequence of states, or "frames". During each frame, the game accepts user input, performs necessary calculations (AI, graphics etc.). When all processing is finished, the game will update the game state and produce an output, for example in the form of 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 hold 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 optimizing 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 network with sufficient bandwidth and no or little congestion. Instead, the latency involved in transmitting data between clients and server play 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 consequential 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.[1] 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. Although radio propagation through air is faster than light through 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. And, in the event of electromagnetic interference, transmitted packets may be lost, requiring a retransmission which also incurs latency.




Effects


The noticeable effects of lag vary depending on the exact cause, but also on any and all techniques for lag compensation that the game may implement (described below). As all clients experience some amount of 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 requires extensive use of compensation to be playable (most prevalent is probably the first-person shooter genre). Due to the various problems lag can cause, many players that have a lower speed Internet connection are often 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 caused by 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 for 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 causes various problems with hit- and collision detection. 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 & 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 (using a peer-to-peer architecture[citation needed]). 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 infeasible, 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 update it from the server, the main task of the client-side compensation is to render the virtual world as accurately as possible for the client. 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.
Incorrect prediction scenario for interpolation and extrapolation
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 a packet be lost or arrive too late, the client will have to freeze the object in position until a new packet arrives, or attempt to extrapolate the position instead. It may also result in an incorrect movement in certain cases, such as when an object makes a U-turn between two updates. This can be partially solved by increasing the sampling rate. Finally, as the world is rendered with a slight delay, it increases the need for some form of lag compensation for hit detection 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.
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 clients 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 clients predictions are very noticeably undone by the server. Sometimes, in the case of minor differences, they server may even allow "incorrect" changes to the state based on updates from the client.


Server-side


Unlike the clients, the server knows the exact current game state. As such, prediction is unnecessary, and the main purpose of server-side lag compensation is to provide accurate effects of client actions. This is important as players may, for example, heal themselves when they see their health is running low, while on the server, the player has already died. In these cases, it is important that the server can compensate for delays. 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.
One potential "solution" is to simply ignore it. A game may simply make players do their own predictions. For hit detection in first-person shooters, this means a player will have to lead their target, aiming at the position where the target will be by the time the shot reaches the server. With variable latency, this may be frustrating even under ideal conditions. With higher latency and random player movement, it may make playing virtually impossible.
Another way to address the issue is to let servers keep track of past game states and attempt to do a time shift when processing an action. Essentially, each action on a client will include a time stamp. When a client fires a weapon, the command and the time is sent to the server. By the time the update arrives, the game state will have changed and the target may have moved out of the way if the result of the shot is calculated based on the current state. Instead, the server will attempt to estimate the delay between the client's command and the command's arrival, including any inherent delay due to interpolation (see above), and look into the past in order to see what the shooting client saw at the time the shot was fired. Under ideal conditions, this will result in the server seeing the client firing at the target's old position and thus hitting, and the hit will be registered. This solution allows players to aim at what they are seeing, and the server will generally be able to compensate for delays well enough for the player to hit their targets without any leading required. It does however result in some inconsistencies, as the procedure may (to an extent) reverse events that have already happened. If, for example, the delay between the shooting client and the server is sufficiently high, by the time the shot command reaches the server, the server may already have commands from the target client indicating that the target had taken cover. In this case, the target would be under the impression that they were shot through cover. Even while the target had already taken cover, the shooter would still have seen them out in the open, and the server-side lag compensation would count it as a hit.




Some basic steps to reduce multiplayer lag




1. Download GAME BOOSTER
Gamebooster's are some of the best ways to reduce lag. They close programs that you dont need while your game is running. Use google to get a good and free one.


2. CLOSE ALL OF YOUR WEBPAGE'S 


This is the simplest of all ways to reduce lag. The internet can take make your game lag a lot if you watching some videos or 18+ stuff in the background.


3. DON'T DOWNLOAD! [Avoid uploding /torrent during game play]


If your downloading something while your playing CA, depending on the file it can create A LOT OF LAG. Wait for the download to finish or close it before you play!


4. OTHER PROGRAMS?!


Turn off all other programs like Xfire and Skype if your lagging like a [CENSORED]. It may just be that your comp can't take it while your going into the game. Also close teamviewer before you go in game!




5. CHECK YOUR CONNECTION!


Doing something as simple as going to your internet box and looking at the connection strength can help you......if its low then take out the wire, wait 10 to 20 seconds and then plug it back in. 




6. Switch to nearer server 


This will reduce your ping ! nd you will lag less


7. ARE YOU GETTING DDOS ATTACKED?


Well, do you believe that your getting DDOS attacked? if you are then try talking to your internet provider and get some help. If the attack is strong enough your internet could not even work.


8. Use CCleaner/tune up cleaner


Use programs like CCleaner to clean up your comp from cookies and a lot of other memory taking files.....this is help your system get faster and take of a lot of junk. 


9. Defragment C within 3 weeks
This will help to minimize unused space in harddisk and reduce game crash