|
Let's get real about Lag |
|
|
|
|
|
Monday, March 12, 2007
Let's get real about lag. We rely upon our game developers to create new and intricate worlds, add layers and layers of interesting interactions, and push their technical capabilities with custom, cutting edge effects layers. And while those are amazing feats, there are some things we don't ask developers to do, largely because they can't. We don't ask them to fix the 360's horrible d-pad. We don't demand they invent new business models for selling their particular title. We don't demand they find a way to fit more gaming into our schedules. And, unfortunately, we can't expect them to "fix" lax.
A little technical background. To communicate with a remote console, your machine plugs into the wall. That connection then jumps to your ISP, usually through your cable router, a local router near your house, and the ISP's router. Then it will probably be passed up to what's known as a "backbone" provider... the super large networks that nobody accesses directly, but that overall see most of the traffic on the internet. It then passes back down to the other player's ISP, then their home. Once the other player has recieved the packed, they send off a confirmation of their own to say, basically, "yes, I got this."
Now, lossy packet routing is part of the normal functioning of the internet. If California is experiencing one of its frequent power outages, you don't want your data to disappear into a black hole, do you? So this additional back-and-forth confirmation and chatter accounts for perhaps a full 2 3/rds of all network traffic.
Check your ping times, and you're likely to find them in the 50 to 100 ms range. That's a full 1/10th of a second behind what is happening. If you have one further packet to resolve conflicts, you're looking at about 1/4th of a second eaten up by lag. Additionally, some of those packets are going to get lost. It shouldn't be too many, but let's say 1 out of every 20.
That's not to say that all is lost, however, as most game styles can facilitate some degree of predictive play. Which is to say, the games assume your opponents are doing basically whatever it is they're doing. Racing games are the perfect example of this. As a vehicle driving along, it probably doesn't matter what the other vehicles around you are doing so long as you don't hit them. So most videogames just assume the second player has done what the game assumes the second player did, until they recieve the packet 1/4th second later that tells them what they actually did. If the players bump into eachother slightly differently than one or the other console thought, it's pretty easy to bump people back into line with where they would be going. And, by the nature of a crash, this jump is hardly ever noticed.
Now compare this to a fighting game, the worst case scenario on the other side. In a fighting game, not only do you have to have split-second reactions, everything you do after the initial action depends on what happened before. For an example, think of a card game where you see the right card, and slap your hand down upon it. Then depending on whether or not you got that card, you slap another card. If the average reaction time is 1/2 second, then everyone is going to slap down at roughly the same time. Certainly, people will slap down within the 1/4th second window. Then they each slap down on a different second card, thinking they won the initial slap match. As they're slapping down on the second card, the consoles decide amongst themselves who really won the initial card conflict. And while you may have been justly penalized for your first hit, you now are penalized for hitting the "wrong" second card, even though it was right in your frame of reference.
In a fighting game, another player might attack, and you might reverse the attack and go into a throw. But by the other console's frame of reference, they haven't yet recieved your packet that says "they reversed you," so they connect with the first hit and combo into a low juggle. Now you have a connundrum. Whose attack wins? Did the reversal happen? Maybe the other player had an easy throw counter handy, but because the reversal was counted, they've now taken extra damage for trying to do a low kick while being reversed. Or, maybe the consoles decide that the reversal didn't happen before the player began their juggle, so instead of blocking an easy air-juggle, the player is stammering trying to throw a character they don't have. Fighting games have the unfortunate distinction of requiring both this twitchy fast reaction times and interdependence upon resolution of player actions.
The turn-based combat in RPG's are particularly suited to this kind of irresolution. Ever seen a character in World of Warcraft run past you, only to see them run past you again? The game lost a packet or two, then caught up. In MMORPG's this looks weird, but almost never effects strategy. Same with RTS games, whereby any sort of "conflict" situation resolves over time (get shot for a minute) rather than having instantaneous consequences like in other games.
Players may moan about how it "should" be possible to make a lagless game, but unfortunately that doesn't make it possible. There have been several dozen teams making fighting games with online modes, and all of them have hit the same major, debilitating problem. They can't all be screwing it up. If you're planning on going online, design your game for longer conflict resolutions and less instantaneous dependencies and it will play fine. Design it with tightly interdependent frame-by-frame play, however, and it will be nearly unplayable online. Create for global strategy rather than instantaneous reactions.
Online games don't need to be devoid of play, but they do need to involve creative play setups to both be fun and avoid the spectre of lag.
- Chris 10:18 AM [+]
|
|
|
|
Post a Comment