Came across this thread and read (for God sake, please)
Is Blizzard doing something or making a fix on that input lag for FPS/TPS type of game?
Is it true, lots of FPS/TPS type of game right now are just sitting and waiting for Blizzard to fix this issue?
I'll be jumping like crazy if you guys answer yes.
No idea tbh. "fix" isnt the right term...as everything is working as it should for an "rts" game =P will they modify it to allow such controls...we all hope so.. but would require a rather large edition. Nothing we will see "soon(tm)" i think
Pretty much as Molsterr said, the lag is perfectly acceptable for an RTS and is actually a result of ensuring the RTS is consistent with each player but yah pretty bad for FPS or any sort of reactionary controls style game. Here's hoping that Blizzard will recognize the popularity of these types of games and give us a nice switch to flip the game's session from RTS to direct controls mode at our discretion as map publishers.
Considering one of Blizzard's own maps in Blizzcon '09 was a third-person shooter, I imagine they are aware of the impact of the lag created by device input events. As for if they're actually doing something about it...who knows. Might be fixed in a nearby patch, or they might wait until they've released both expansions.
Considering one of Blizzard's own maps in Blizzcon '09 was a third-person shooter, I imagine they are aware of the impact of the lag created by device input events. As for if they're actually doing something about it...who knows. Might be fixed in a nearby patch, or they might wait until they've released both expansions.
Yeah we wont see this added until at least the first exp is my "logical" guess. Changing how the server works with synchronizing msgs is not a fast task lol.
actually...I imagine its not much more then commenting out a section of code, specifically the synchronizing part :P Nah more specifically though there are loads of games out there that feature much lower latency, I'm almost under the impression blizzard artificially keeps that lag as part of their balancing act to appease the fanatics who'd otherwise being crying like little girls because their dial up connection can't let them compete with the smug jerks on T1s etc.
no, theres a rather big deal to go along with it, that cant "comment it out" they have to allow it to be switched. Also the server side scripting is 100% based on all action being synced. Itll take them a work around.
Then again, this is going off basic knowledge of programming, theres no telling how they set it up... maybe its already finished and they need to turn it on or the system was based around having it changeable at some point, who knows. BUT if they havnt touched it at all, it will take awhile ^_~ [not just becuase of programming, but cause of how everything is set-up im not talking about just scripts but the whole sha-bang. (testing, implementation, patch...ect)]
I"m actually pretty serious, I mean think about it: A sync is 2-3 hand shakes depending on their model, player A clicks->packet sent to bnet->packets sent to opponents->packets come back to bnet->one more burst of packets go back out saying its happening at 'x' time in the very near future.
Now I don't know about you but its hard for me to ping any reasonably hosted server in north america and get anything higher then about 30ms and that's a two way travel...so optimal conditions we have 60ms...nowhere near as high as our estimated 250ms lag on buttons and clicks currently on battle.net...it could be a *lot* lower is what I'm saying.
ED: Hell actually after so many of those three way shakes are achieved then bnet should be able to get a good average and start 'assuming' that the travel time will be x and ignore the second round of them except to occasionally re-poll for deviations.
I"m actually pretty serious, I mean think about it: A sync is 2-3 hand shakes depending on their model, player A clicks->packet sent to bnet->packets sent to opponents->packets come back to bnet->one more burst of packets go back out saying its happening at 'x' time in the very near future.
Now I don't know about you but its hard for me to ping any reasonably hosted server in north america and get anything higher then about 30ms and that's a two way travel...so optimal conditions we have 60ms...nowhere near as high as our estimated 250ms lag on buttons and clicks currently on battle.net...it could be a *lot* lower is what I'm saying.
ED: Hell actually after so many of those three way shakes are achieved then bnet should be able to get a good average and start 'assuming' that the travel time will be x and ignore the second round of them except to occasionally re-poll for deviations.
Ok I get what your saying, I think we were both looking at two different sides of the picture. Still something like this would take some testing time to make sure its all good and dandy...ect. Even if it were able to be done beforehand, I really dont see them pushing this still the expac.. I doubt it would be take that long you know? But thats just my opinion on when they would push it, I have no "facts" to prove why blizzard would wait to act till then.
Their system was based around permanent synchronization and if they just punch a hole into somewhere the entire ship (read: Sc2) will just sink faster than the titanic.
There are many games that don't have the problem, but that's just because it's been build differently.
In most normal FPS games:
You click a mouse button, your character shoots.
The game sends the information that you shot to the server.
Now it does all the things it needs to do: Make your gun go boom, create the projectile and let it loose.
Shortly after, the server gets the info that you shot, but it knows that the shot is already created and for how long. So it takes this into account and calculates where the bullet is now. (That's where the "skipping" comes from - players with a bad connection seem to teleport through the map. For them the game runs fine, but they don't send their info often enough so it skips for all others who have to calculate this player's position.)
Now the server sends this info to all the other players.
Shortly after, all other players get note that you shot. They also calculate where the bullet is now flying to.
In most RTS:
You click a mouse button, your character shoots.
The game sends the information that you shot to the server. Then your game waits.
The server gets the info that you shot, now he's sending this info to all other players.
All other players get info that you shot, including you. Your game takes this response as the affirmation that it can go ahead. (that's why RTS games have so long reaction times when you got a bad connection. But your units don't skip around or so.)
Now it does all the things it needs to do: Make your gun go boom, create the projectile and let it loose.
All other players' machines do the same. They know that they got the info at the same time as you got the confimation so they know it'll be synchronized.
After that they don't ever have to take care of that projectile again. Since everything is synchronized every player knows exactly what happens to this projectile.
These ways of communication are just so different that you can't just switch between them.
It's like having a car but wanting a plane. Of course you can strap wings to a car, but you'll have a hard time making it fly.
In addition to that Blizzard's battlenet has a minimum delay. It delays all packages for a certain amount of time, even if it could send them faster. I think they do this to make sure that they have relatively good latencies across the board. It uses this delay time to send other packages first.
I think that delay is 125 or 150 ms (shortly before the beta ended they said they're reduced the delay from 250 to 125 or 150, not sure what it was).
If they removed or reduced that it'd already help.
But they won't change their game architecture.
Dude I was joking about the commenting out :P But both of those models you explained can be done with way lower latency then 250ms, that's what I'm saying. I'm pretty sure Blizzard purposely keeps that latency that high more to even the playing field between players with crappy internet vs those of us with 21rst century tech driving our own. Ie its part of their 'same experience for everyone' that hobbles the game down to the lowest common denominator in every aspect so no one can complain about advantages and disadvantages depending on people's setup and connection.
For instance it'd have been real easy for them to adjust each session's sync lag to suite the connections of all involved, but instead they set the bar so high that no one should be tripping above it even on a 28K modem and a watery line several miles from the closest switching station.
(Disclosure: I'm a budding network tech and dealing with latency, synchronization and routing etc is kinda what I do :P)
(Disclosure: I'm a budding network tech and dealing with latency, synchronization and routing etc is kinda what I do :P)
Right, I'll call a couple of my marine buddies, some medics and a dropship.
We'll drop Blizzard's mainframe and protect you while you fix their servers.
Anybody who thinks that implementing client-side prediction is a matter of "commenting out" a few lines of code is ignorant beyond belief.
How about we stop making topics about this every week and put up a sticky somewhere saying yes WASD maps are going to lag, no there's nothing you can do about it, and no blizzard hasn't announced any plans to revamp the engine to better support action-style maps (nor is it likely they will as that would involve a significant rewrite of the engine.)
Right on now we're talking :) Unfortunately my programming background is pretty limited to doing a few projects in C about a decade back...but I could probably recognize any changes a programmer your team held hostage were doing what we want them to be doing :P
And again, its not actually that hard. The only unpredictable parts of the whole system are what the players are doing, clicks and keys. The 'keep same seed' editor preference proves that their engines know how to completely sync everything else ala how the ancient but highly cool Bungie gamse Myth & Myth 2 were infamous for.
Now let me explain why: Those projects happened to be real-time multi-user environments more commonly known as online games. So while I may no longer be up to speed on the modern languages and methods, I understand the design concepts and believe I have a firm enough handle on how blizzard has been making their RTS games to see why it'd be possible.
ED #2:
...and now that I've had a chance to go get a fresh beer let me explain my logic for supporting this theory:
Ever look at a save game(oops) replay file size? They're freakin tiny. What do you think they contain? I'll give you my thoughts: Init seed, player actions & system/network inconsistency corrections. That's it.
So, one can assume that using that information and the proper version of the assets used to create the session you can reproduce exactly what happened during a session, as often as you want. That means that Blizzard uses the alternate school of 'random' where its not really random at all and entirely based on that seed. I further think this is true because if you setup two computer AI opponents to fight each other but enforce that seed lock on the map...it will play it *exactly* the same every time, on battle net or not.
So the only things that each client can't predict are any player's actions and clients slowing down from over-working the GPUor CPU and network access issues. So there probably isn't really that much traffic flying around comparatively speaking, and even less when all the competitors are playing on machines that don't lag out or drop in clock rate below whatever threshold the engine beneath the graphics display is operating at.
This part is a total assumption though based upon the above theory:
So with so little traffic needed to be sent...well sending those bits of info in blocks every say 10ms and assuming a turn around time of let's give it a unhealthy slow for cable 100ms for two complete crossings (assuming TCP not UDP) with the central server playing monkey you have 110, and that's still pretty sloppy & open to deviations.
Since you guys are talking about this, do anyone else also find the two WASD tutorials we have in the tutorial page are both very outdated? Besides, the codes of deliverancelost's method is highly redundant. Basically, like Blizzard's Lost Viking map, you only need one periodic trigger to issue the movement order but deliverancelost's method do this for every direction, so when someone pressing W and D at the same time, trigger lines executed become double of that are needed. Though I'm not sure how much this will affect the actual performance. Someone should write a more up-to-date and precise tutorial about this.
I just use rrowland's library, its the first one I tried and I liked it because its very easy to setup and operate and at this point I think simplicity is about the only difference between any of them. You grab library, import library, tag it as instructed and then put three triggers in that reference the library's functions: One for key up, one for key down and one to bind a unit to those keys, repeat using whatever method you want for as many players as you want. I've built programmer's data method using his instructions and actually about an hour ago posted a video comparing it side by side with rrowland's and at least from my perspective they have identical response time, just they're off a little because I think rrowland's takes bigger steps per sequence.
during the beta, they reduced input lag from .25 to .125. It can be done, just they dont necesently "want" to. They may release it to where high-level scriptors could change the input lag, but I doubt it becomes anything mainstream. Otherwise server-side activities would sky-rocket from a .125 delay down to a .05 delay or something.
Rollback Post to RevisionRollBack
To post a comment, please login or register a new account.
Came across this thread and read (for God sake, please)
Is Blizzard doing something or making a fix on that input lag for FPS/TPS type of game? Is it true, lots of FPS/TPS type of game right now are just sitting and waiting for Blizzard to fix this issue?
I'll be jumping like crazy if you guys answer yes.
I really dont want to waste my TPS map.
No idea tbh. "fix" isnt the right term...as everything is working as it should for an "rts" game =P will they modify it to allow such controls...we all hope so.. but would require a rather large edition. Nothing we will see "soon(tm)" i think
Pretty much as Molsterr said, the lag is perfectly acceptable for an RTS and is actually a result of ensuring the RTS is consistent with each player but yah pretty bad for FPS or any sort of reactionary controls style game. Here's hoping that Blizzard will recognize the popularity of these types of games and give us a nice switch to flip the game's session from RTS to direct controls mode at our discretion as map publishers.
Considering one of Blizzard's own maps in Blizzcon '09 was a third-person shooter, I imagine they are aware of the impact of the lag created by device input events. As for if they're actually doing something about it...who knows. Might be fixed in a nearby patch, or they might wait until they've released both expansions.
Yeah we wont see this added until at least the first exp is my "logical" guess. Changing how the server works with synchronizing msgs is not a fast task lol.
@Molsterr: Go
actually...I imagine its not much more then commenting out a section of code, specifically the synchronizing part :P Nah more specifically though there are loads of games out there that feature much lower latency, I'm almost under the impression blizzard artificially keeps that lag as part of their balancing act to appease the fanatics who'd otherwise being crying like little girls because their dial up connection can't let them compete with the smug jerks on T1s etc.
@BumpInTheNight: Go
no, theres a rather big deal to go along with it, that cant "comment it out" they have to allow it to be switched. Also the server side scripting is 100% based on all action being synced. Itll take them a work around.
Then again, this is going off basic knowledge of programming, theres no telling how they set it up... maybe its already finished and they need to turn it on or the system was based around having it changeable at some point, who knows. BUT if they havnt touched it at all, it will take awhile ^_~ [not just becuase of programming, but cause of how everything is set-up im not talking about just scripts but the whole sha-bang. (testing, implementation, patch...ect)]
@Molsterr: Go
I"m actually pretty serious, I mean think about it: A sync is 2-3 hand shakes depending on their model, player A clicks->packet sent to bnet->packets sent to opponents->packets come back to bnet->one more burst of packets go back out saying its happening at 'x' time in the very near future.
Now I don't know about you but its hard for me to ping any reasonably hosted server in north america and get anything higher then about 30ms and that's a two way travel...so optimal conditions we have 60ms...nowhere near as high as our estimated 250ms lag on buttons and clicks currently on battle.net...it could be a *lot* lower is what I'm saying.
ED: Hell actually after so many of those three way shakes are achieved then bnet should be able to get a good average and start 'assuming' that the travel time will be x and ignore the second round of them except to occasionally re-poll for deviations.
Ok I get what your saying, I think we were both looking at two different sides of the picture. Still something like this would take some testing time to make sure its all good and dandy...ect. Even if it were able to be done beforehand, I really dont see them pushing this still the expac.. I doubt it would be take that long you know? But thats just my opinion on when they would push it, I have no "facts" to prove why blizzard would wait to act till then.
They just cant comment something out.
Their system was based around permanent synchronization and if they just punch a hole into somewhere the entire ship (read: Sc2) will just sink faster than the titanic.
There are many games that don't have the problem, but that's just because it's been build differently.
In most normal FPS games:
In most RTS:
These ways of communication are just so different that you can't just switch between them.
It's like having a car but wanting a plane. Of course you can strap wings to a car, but you'll have a hard time making it fly.
In addition to that Blizzard's battlenet has a minimum delay. It delays all packages for a certain amount of time, even if it could send them faster. I think they do this to make sure that they have relatively good latencies across the board. It uses this delay time to send other packages first.
I think that delay is 125 or 150 ms (shortly before the beta ended they said they're reduced the delay from 250 to 125 or 150, not sure what it was).
If they removed or reduced that it'd already help.
But they won't change their game architecture.
No you're not. I am.
Darn immitators!
@s3rius: Go
^ Exactly!. Thats what I was referring to [Why I said it would be an expact], I think bump was referring to just limiting the delay in the sync.
@s3rius: Go
Dude I was joking about the commenting out :P But both of those models you explained can be done with way lower latency then 250ms, that's what I'm saying. I'm pretty sure Blizzard purposely keeps that latency that high more to even the playing field between players with crappy internet vs those of us with 21rst century tech driving our own. Ie its part of their 'same experience for everyone' that hobbles the game down to the lowest common denominator in every aspect so no one can complain about advantages and disadvantages depending on people's setup and connection.
For instance it'd have been real easy for them to adjust each session's sync lag to suite the connections of all involved, but instead they set the bar so high that no one should be tripping above it even on a 28K modem and a watery line several miles from the closest switching station.
(Disclosure: I'm a budding network tech and dealing with latency, synchronization and routing etc is kinda what I do :P)
@BumpInTheNight: Go
Right - jokes are hard to identify in a post :P
Atten-shun! The next hiding joke will be shot on the spot!
Right, I'll call a couple of my marine buddies, some medics and a dropship.
We'll drop Blizzard's mainframe and protect you while you fix their servers.
Anybody who thinks that implementing client-side prediction is a matter of "commenting out" a few lines of code is ignorant beyond belief.
How about we stop making topics about this every week and put up a sticky somewhere saying yes WASD maps are going to lag, no there's nothing you can do about it, and no blizzard hasn't announced any plans to revamp the engine to better support action-style maps (nor is it likely they will as that would involve a significant rewrite of the engine.)
@s3rius: Go
Right on now we're talking :) Unfortunately my programming background is pretty limited to doing a few projects in C about a decade back...but I could probably recognize any changes a programmer your team held hostage were doing what we want them to be doing :P
@RileyStarcraft: Go
Again, joking about the commenting out :P
And again, its not actually that hard. The only unpredictable parts of the whole system are what the players are doing, clicks and keys. The 'keep same seed' editor preference proves that their engines know how to completely sync everything else ala how the ancient but highly cool Bungie gamse Myth & Myth 2 were infamous for.
http://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect
@RileyStarcraft: Go
That's uncalled for but utterly ironic. :)
Now let me explain why: Those projects happened to be real-time multi-user environments more commonly known as online games. So while I may no longer be up to speed on the modern languages and methods, I understand the design concepts and believe I have a firm enough handle on how blizzard has been making their RTS games to see why it'd be possible.
ED #2:
...and now that I've had a chance to go get a fresh beer let me explain my logic for supporting this theory:
Ever look at a
save game(oops) replay file size? They're freakin tiny. What do you think they contain? I'll give you my thoughts: Init seed, player actions & system/network inconsistency corrections. That's it.So, one can assume that using that information and the proper version of the assets used to create the session you can reproduce exactly what happened during a session, as often as you want. That means that Blizzard uses the alternate school of 'random' where its not really random at all and entirely based on that seed. I further think this is true because if you setup two computer AI opponents to fight each other but enforce that seed lock on the map...it will play it *exactly* the same every time, on battle net or not.
So the only things that each client can't predict are any player's actions and clients slowing down from over-working the GPUor CPU and network access issues. So there probably isn't really that much traffic flying around comparatively speaking, and even less when all the competitors are playing on machines that don't lag out or drop in clock rate below whatever threshold the engine beneath the graphics display is operating at.
This part is a total assumption though based upon the above theory:
So with so little traffic needed to be sent...well sending those bits of info in blocks every say 10ms and assuming a turn around time of let's give it a unhealthy slow for cable 100ms for two complete crossings (assuming TCP not UDP) with the central server playing monkey you have 110, and that's still pretty sloppy & open to deviations.
Now, am I still out to lunch?
Since you guys are talking about this, do anyone else also find the two WASD tutorials we have in the tutorial page are both very outdated? Besides, the codes of deliverancelost's method is highly redundant. Basically, like Blizzard's Lost Viking map, you only need one periodic trigger to issue the movement order but deliverancelost's method do this for every direction, so when someone pressing W and D at the same time, trigger lines executed become double of that are needed. Though I'm not sure how much this will affect the actual performance. Someone should write a more up-to-date and precise tutorial about this.
@Wakeman: Go
I just use rrowland's library, its the first one I tried and I liked it because its very easy to setup and operate and at this point I think simplicity is about the only difference between any of them. You grab library, import library, tag it as instructed and then put three triggers in that reference the library's functions: One for key up, one for key down and one to bind a unit to those keys, repeat using whatever method you want for as many players as you want. I've built programmer's data method using his instructions and actually about an hour ago posted a video comparing it side by side with rrowland's and at least from my perspective they have identical response time, just they're off a little because I think rrowland's takes bigger steps per sequence.
@BumpInTheNight: Go
during the beta, they reduced input lag from .25 to .125. It can be done, just they dont necesently "want" to. They may release it to where high-level scriptors could change the input lag, but I doubt it becomes anything mainstream. Otherwise server-side activities would sky-rocket from a .125 delay down to a .05 delay or something.