What is Tetris lag?

[SkyAlly]

i didnt know that tetris ever lagged ;o

[Wojtek]

http://harddrop.com/wiki/Tetris_lag

[Paul676]

lol woj that's hilarious

[Lucho]

protip: you can use the shoutbox to ask quick questions

[Paul676]

protip: use the search function on the forums, and find zerot's tetris friends lag guide.

[farter]

protip: play TF / fullscreen TGM3.

[Untitled_123]

o.O how do i get promoted?

[MarioThePhenom]

o.O how do i get promoted?

what

[myndzi]

Most people use 'lag' to describe 'anything that goes wrong'. In the true sense of the term, lag is a delay. Most commonly it refers to a network delay (network latency), but since Tetris can be a highly response-driven game, it can also describe 'input lag', or, a delay between entering an input and observing the result. These are two completely separate things with separate causes and effects, so I'll talk about them separately.

Network latency

Data doesn't transport everywhere instantly. It takes time to get from one computer to another, on the order of milliseconds. Commonly, 50-100ms will be pretty good, 200-400ms will be pretty bad, > 400ms is pretty awful. Factors that can affect network latency include your connection speed, physical distance from the destination, network usage at a bottleneck (read: downloads, torrents, etc. in your local network), plain bad luck (network congestion, dropped packets).

The effect of network latency is subtle but sometimes important. Imagine you and a friend standing five feet apart, and you each toss a baseball to the other. There's a brief period of time where both balls are in the air, right? (lawl) Now imagine you're standing twenty feet apart; there's a much longer period of time in this case. The same applies to data sent over a network.

The easiest way to implement a network game is just to send the data along and shrug your shoulders. As far as I know, both Tetris Friends and Nullpomino do this. This means that there is effectively one game state for each player, and they will never be exactly the same. What you see on your screen is what counts for you, but what you see on your screen may not be what other players are seeing. And it's what they see that counts for them. Most of the time this won't matter, but Tetris moves fast and attacks are happening constantly. That little delay can mean the difference between your garbage getting there and being cancelled (arrives before opponent sends) and getting there and being accepted (arrives after opponent sends). It is possible for two attacks to happen at about the same "real" time, cross past each other in the network, and have both players receive the full attack.

This also affects winning and losing in close situations. Since the server just trusts the clients to fess up when they lose, the first loser is the first message that the server receives from a client saying 'I lost.' This has obvious implications for cheating, but among non-dickheads it can simply mean that maybe you saw someone top out before you, but they still placed higher according to the win results.

These problems are unavoidable side effects of the implementation. The only way to ensure that all games have one single, equal, state is to have an authority decide what that is (read: the server). This requires more programming work and more server resources, since the server has to keep track of all games being played rather than just relay messages. It's also more complicated and involved to execute, which is why you see people opt for the simpler way that is in place.

"Input lag"

All of that relates to sending data across the internet and program design, things which you can do almost nothing about (other than ensuring nobody's saturating your bandwidth or implementing traffic shaping). Input lag is a more personal problem (har!). When you press a key on your keyboard, a signal is sent to your computer (inb4 poll vs push); the operating system interprets the signal and passes it to the appropriate program(s), which then interpret it themselves and decide what to do about it. Programs don't truly run at the same time (inb4 multi-core) -- they share the processor and take turns. So, the path from pressing a key on your keyboard to moving a piece in your Tetris game can be fraught with danger!

Physical problems with your keyboard can delay, prevent, or repeat signals. High CPU utilization can delay your game's "turn" at the wheel. Certain browser properties will pause execution of things in tabs: focus, active tab, and so on. (See: shoutbox mod I did to prevent polling when the tab is in the background). Most of that is fairly reasonable most of the time, and it's the cause for people who suggest things like "increase the priority of your chromes~" or "hack ur registry to poll usb retarded fast". Don't get me wrong - these things can have an effect, but the chance that they will have a significant effect is low in comparison to the number of people who suggest them.

The biggest potential source of latency is the program code itself. Shockwave Flash is a complicated generic script interpreter these days, which means that it has to do lots of things internally that may not be related to "move blocks around on the screen". Interpreters are, in general, slower than compiled programs (inb4 jit); the reason so many people use Flash is because it's become a path of least resistance. Flash is available on most systems and it behaves the same on all of them; you only have to write your code once and you don't have to take account of different browsers, versions, platforms, levels of support for standards, etc. It's pretty obvious why Flash is in favor for web games. Flash itself is a beast, though; it started out as something different entirely and has been added onto for years and years until it became something quite other than its roots. This means it is not really designed directly for its current purpose, which suggests various kinds of ineffectiveness that might not be present if it were approached directly.

All that aside, how you implement the program is the biggest hurdle. You could get everything else down to miniscule interference and still absolutely wreck the responsiveness with bad programming. For an example of this, get your hands on a smartphone with a keyboard and compare the difference in responsiveness between:

http://krisreeves.com/jst/standalone/finessetris.html
http://krisreeves.com/jst/standalone/finessetris2.html

Whoops, fork bombed server. Links will be available in a little bit.

(Note: key binding page redirects to the first, which looks almost the same as the second, but the engines are completely different. Key bindings apply to both.)

So, the moral is there are lots of tradeoffs involved in producing even a "simple" game like Tetris. Most of those tradeoffs aren't in favor of responsiveness, they're made in favor of quick implementation and mass accessibility/appeal. Low expense, high return. Welcome to capitalism!

I hope this has helped to illustrate what 'lag' means in various contexts, what some of the factors are and what, if anything, can be done about them.

[Dakhath]

I really wish this community had a way to recognize or reward helpful, well thought out answers.

[Barneey]

I really wish this community had a way to recognize or reward helpful, well thought out answers.

This could potentially be awesome.
Thanks a lot for the very in-depth post, Myndzi.

[PetitPrince]

I always though tetlag was the accommodation period when you switch from one rotation system to another.

[Kitaru]

I think the distinction here is between tetlag (what the player feels when re-orienting to different rules or settings) and Tetris itself lagging (effects to the detriment of the game client's performance, response, state sync, etc.).

[Barneey]

I always though tetlag was the accommodation period when you switch from one rotation system to another.

This is hilarious

[Paul676]

lol it's true tho