135 replies to this topic

[Mazgazine1]

Quote

State Re-winding’ for those not familiar with the term State Re-winding means that when you shoot at a Mech rather than check the shot against the Mechs current hit box location we rewind the Mechs state to the time in the past when the shot was fired and check the shot against the hit box position at that time.

Matthew Craig

I have never heard this term used before for any online/offline games I have played. Have any other games employed this method of hit detection? It sounds like it would work really well, but I imagine there is a massive ton of network acrobatics to get it to work in realtime.

Is this why mechs bounce/stutter through eachother? The hit detection is seeing the collision from two different time frames and attempting to work it out?

Edit: ARGH! Title of post spelling fail...

Edited by Mazgazine1, 15 January 2013 - 09:21 AM.

[Kunae]

Mazgazine1, on 15 January 2013 - 09:16 AM, said:

Is this why mechs bounce/stutter through eachother? The hit detection is seeing the collision from two different time frames and attempting to work it out?

Pretty much, yep.

[cyberFluke]

When you factor in the other major cause of player teleporting, Player Movement Prediction, yeah.

PMP essentially makes an intelligent guess as the where the player will be next frame and draws them in that position. Sometimes it's wrong and a player will suddenly teleport as the server gets the actual position data from the client. Intentional, constant delay in the client sending position data is what you may have heard referred to as a "lag switch". The effect this has on different games is quite varied, in Planetside 2 for example, the player flickers in and out of existence or "slides" around in all 3 dimensions.

[Thomas Dziegielewski]

Nothing really to do with movement. So no it does not cause the stutter.

But you hit the nail on the head. The Physics state rewind moves all physics object back in time in order to do traces for weapons when they occurred on clients.

I'm sure other titles have done this.

[Vassago Rain]

Thomas Dziegielewski, on 15 January 2013 - 09:29 AM, said:

Nothing really to do with movement. So no it does not cause the stutter.

But you hit the nail on the head. The Physics state rewind moves all physics object back in time in order to do traces for weapons when they occurred on clients.

I'm sure other titles have done this.

A lot of them have, but I've never heard the system itself referred to with any kind of name.

[Hawkwings]

Many modern online multiplayer games do this, ones that have server-side hit detection at least. I know the Call of Duty games do this, which is why on there you can spray bullets at someone on your screen, kill them, and be called a hacker because the person (on their screen) was behind cover. What's happening is that when you send the "fire" command to the server, the server checks that fire command against the server state at the time that your computer thinks its at. The server keeps a log of the last few seconds of what happened, so you can lag behind the official server time a bit but still play as if there was minimal lag. However, since movement is client-side, your computer may think its in one location, but due to lag you are actually in another location according to the server. This other location is sent to all the other players, meaning that when they shoot, they are aiming at killing you at your true serverside location, not the location that your client thinks.

This is more of a problem in fast twitchy games. Of course if you desync too badly then the server forces you to reset, but in a slower game like MWO this is a sound way to combat lag.

[Bagheera]

Whoah.

This thread is way above my pay grade.

[Ilwrath]

Mazgazine1, on 15 January 2013 - 09:16 AM, said:

I have never heard this term used before for any online/offline games I have played.

I think this is why you sometimes becomes Mech of the North Star and can count down to 3 before the enemy mech, that is now safe behind cover and out of sight, explodes in a fountain of mechparts and lubricant oil. Granting you a kill.

[Vassago Rain]

Ilwrath, on 15 January 2013 - 09:38 AM, said:

I think this is why you sometimes becomes Mech of the North Star and can count down to 3 before the enemy mech, that is now safe behind cover and out of sight, explodes in a fountain of mechparts and lubricant oil. Granting you a kill.

That's sometimes ammo explosions, too.

[stjobe]

It's important to realize that this state rewinding is for hit calculation purposes only, it has no bearing at all on where your 'mech is or seems to be in the game, nor where your target is or seems to be.

Basically, as others have said, when you pull the trigger and send a "fire!" command to the server, it checks where you and your target was at the time of firing and whether your shot would hit. AFAICT it doesn't move either you or your enemy around at all, that's another piece of code that's responsible for that.

Edited by stjobe, 15 January 2013 - 09:42 AM.

[Hawkwings]

If you are interested in this topic, I would highly recommend reading this article: https://developer.va...nd_Optimization

For a CoD perspective on this, try here: http://forums.xbox.c...152/766801.aspx

[Mazgazine1]

From what I have seen of COD, I'm pretty sure it doesn't. If you watch COD replays, you can tell it has none of the "state re-winding" mentioned here. Otherwise the replay's would look a lot better even in an extremely laggy situation.

If your sides showing you coming up the corner, and they see you already around it and fire AND kill you, even before your around the corner - its client side prediction. The server isn't correct the discrepancy.

I want to know why its always been very hard to Mechwarrior games to have good networking?

Its always been this strange "fire at the ghost in front of the moving thor/summoner" for MW4/3/2 .. People would regularly use fast cycle weapons to find where to shoot, then unload the rest of the weapons. Or just use streaks or something.

MWO is a big improvement, but it still feels like it has some of this heritage, despite being technically unrelated.

[Aym]

Mazgazine1, on 15 January 2013 - 09:16 AM, said:

I have never heard this term used before for any online/offline games I have played. Have any other games employed this method of hit detection? It sounds like it would work really well, but I imagine there is a massive ton of network acrobatics to get it to work in realtime.

Is this why mechs bounce/stutter through eachother? The hit detection is seeing the collision from two different time frames and attempting to work it out?

Edit: ARGH! Title of post spelling fail...

Pretty much every PvP game.

[Ilwrath]

Vassago Rain, on 15 January 2013 - 09:40 AM, said:

That's sometimes ammo explosions, too.

Do they happen when the mech is not under fire at all? At first I was thinking that they where overheating somehow.

[Hawkwings]

Mazgazine1, on 15 January 2013 - 09:43 AM, said:

From what I have seen of COD, I'm pretty sure it doesn't. If you watch COD replays, you can tell it has none of the "state re-winding" mentioned here. Otherwise the replay's would look a lot better even in an extremely laggy situation.

Apart from the fact that the second link I posted where a Black Ops developer talks about how the anti-lag rewind works.

Ammo cookoffs take a few seconds to fully explode, meaning that if you crit ammo, a few seconds will pass before the mech blows up.

[Jasen]

I'm a bit curious about prediction in this game. I mean, it used to work out pretty well with everyone having 300+ pings in a much faster paced game back in 1997-1998...

Take a look at current counter-strikes or such... much faster paced, much better hit detection.

You'd think with these big lumbering machines it wouldn't be that hard....

[Matthew Craig]

Thontor, on 15 January 2013 - 09:36 AM, said:

I wonder if it might go by different names? Hard to find anything online about it.

It's also called lag compensation here's a good article for those interested by some guys who know a thing or two

https://developer.va...ag_compensation

[Hawkwings]

I would encourage everyone who wants to seriously discuss netcode and lag issues to read that ENTIRE article.

EDIT: OK, both of these articles are good:
https://developer.va...nd_Optimization
and
https://developer.va...ayer_Networking

Edited by Hawkwings, 15 January 2013 - 09:58 AM.

[Vassago Rain]

Jasen, on 15 January 2013 - 09:52 AM, said:

I'm a bit curious about prediction in this game. I mean, it used to work out pretty well with everyone having 300+ pings in a much faster paced game back in 1997-1998...

Take a look at current counter-strikes or such... much faster paced, much better hit detection.

You'd think with these big lumbering machines it wouldn't be that hard....

Original counter-strike/half-life in general used to have what we called flamethrowers, and a bunch of other lag problems. There was immense rubberbanding up until the retail version, 1.0.

Sometimes, you could cap a guy, and the game would progress as normal for a second, then you'd see the headshot blood spray, THEN you'd get the kill, and only after this would the target finally 'die' on your screen.

[Jasen]

Vassago Rain, on 15 January 2013 - 10:02 AM, said:

Original counter-strike/half-life in general used to have what we called flamethrowers, and a bunch of other lag problems. There was immense rubberbanding up until the retail version, 1.0.

Sometimes, you could cap a guy, and the game would progress as normal for a second, then you'd see the headshot blood spray, THEN you'd get the kill, and only after this would the target finally 'die' on your screen.

I remember when the QuakeWorld client came out for Quake 1... which made all the difference in the world. and even then... with everyone on 28.8kbps modems we could play competent competitive high-speed games. MWO is a turtle compared to the pace of that game. (furthermore that lag scenario you described is pretty overblown and obviously serious lag).

Something is fundamentally broken with a netcode when it is always running like your previously described lag spike.