|
Northern Ireland25468 Posts
On August 16 2025 09:29 ChillFlame wrote:Show nested quote +On August 16 2025 08:22 WombaT wrote:
I think there are probably 2 realistic possibilities as to why that choice was made, IMO.
1. It’s the next gen RTS, here’s our next gen tech, as a marketing angle.
2. If they were building an engine for future projects, or indeed licensing and figured they would aim high with an expectation of a combo of hardware improvements and their optimisation future-proofing it. Both are possible, the former is more likely, IMO. I don't understand the necessity of a 60Hz tick rate other than marketing. 3x tickrate is 3x CPU load (roughly) There are lots of SC2 pros with average APM over 400. Like Reynor. I've seen 600 average APM in his games. Does anyone know any serious cases of SC2 pros' complaints that the engine isn't responsive enough? I don't understand the necessity of rollback either. I play on the European server with ~20 ping. My units never jitter, and enemy units are never desynchronized. Why do I need a tech that will do nothing and increase my CPU load? To make it possible to play with the Oceania server? Thanks, I'm fine playing with 20 ping, I don't need 180 ping. It can't defy the speed of light and routing delay. So yeah, from the perspective of the average diamond player, I see no tangible benefit. Maybe someone more knowledgeable will explain why it is worth it.
I’ll confess I don’t know what the actual limits of rollback effectiveness are, but I think it has some legit use cases.
If you’re in EU, and theres tons of people playing there, great.
If you’re in Australia, or South America and there aren’t, then having better performance across servers is probably pretty nice.
|
The 60hz simulation part of Stormgate probably has no reason to be much more taxing than the simulation part of Rusted Warfare, an indie RTS developed by one person. Rusted Warefare also has 60 tickrate, likely because for the developer it's an easier way to make the game look smooth without separating rendering from simulation and relying on more complex technologies such as interpolation. Units in Rusted Warfare move in continuous 2D space, with 2D physics like acceleration and pushing, the same as Stormgate. The terrains except in some third party maps are generally more open than Stormgate's, which would makes pathfinding easier, but the game can have much higher unit and building counts without lagging. Units and buildings are obstacles to pathfinding too, and it seems unlikely that Stormgate would run much better on similar maps.
|
On August 16 2025 07:26 qwerty4w wrote:
Separation of rendering and simulation was a newer development for RTS games and didn't become widespread until late 2000s. For example, Tiberian Sun and Red Alert 2 have the same simulation rate as their rendering rate, according to C&C modding community (modenc.renegadeprojects.com/Game_Speed). Beyond All Reason has its unit animation being 30 FPS, the same as the game's tickrate, as a legacy of the engine it uses being an updated old engine and the full separation of simulation and rendering is still a work in process.
Historically it was after it became possible to make the graphics of an RTS more smooth than its simulation you started to see RTSs with really low tickrate, like Supreme Commander and AoE4.
Something to consider with Beyond All Reason. You often have games with 10k+ new objects (units, buildings) on the map and projectile tracking. Pathing does tank it when you have large movement at that stage though. For example a 300 unit fighter swarm getting an order. But lower than that it has no issues with performance. Heck it has run 160 player lobbies with lower unit limits (since engine has a max unit limit in how it is coded, not due to performance).
If tick rate scales roughly linearly with performance requirements, doubling tick rate should not result in the issues we see unless it is poorly built from the ground up. It could be that UE5 doesn't actually support this type of game well, in that case it is really at the bottom of the stack that issues occur.
If it is instead logarithmic increasing performance requirements they would have lowered tick rate to fix the issues.
|
On August 16 2025 09:44 WombaT wrote:
I’ll confess I don’t know what the actual limits of rollback effectiveness are, but I think it has some legit use cases.
If you’re in EU, and theres tons of people playing there, great.
If you’re in Australia, or South America and there aren’t, then having better performance across servers is probably pretty nice.
That's my point.
I don't need it, they do, but I also must use it because the game version is the same. So it worsens my experience for no benefit.
You could select the "no rollback" option when you launched SG, but I doubt this option was meant for release. More like a debug option, because a lot of people had trouble with it.
|
On August 16 2025 09:29 ChillFlame wrote:Show nested quote +On August 16 2025 08:22 WombaT wrote:
I think there are probably 2 realistic possibilities as to why that choice was made, IMO.
1. It’s the next gen RTS, here’s our next gen tech, as a marketing angle.
2. If they were building an engine for future projects, or indeed licensing and figured they would aim high with an expectation of a combo of hardware improvements and their optimisation future-proofing it. Both are possible, the former is more likely, IMO. I don't understand the necessity of a 60Hz tick rate other than marketing. 3x tickrate is 3x CPU load (roughly) There are lots of SC2 pros with average APM over 400. Like Reynor. I've seen 600 average APM in his games. Does anyone know any serious cases of SC2 pros' complaints that the engine isn't responsive enough? I don't understand the necessity of rollback either. I play on the European server with ~20 ping. My units never jitter, and enemy units are never desynchronized. Why do I need a tech that will do nothing and increase my CPU load? To make it possible to play with the Oceania server? Thanks, I'm fine playing with 20 ping, I don't need 180 ping. It can't defy the speed of light and routing delay. So yeah, from the perspective of the average diamond player, I see no tangible benefit. Maybe someone more knowledgeable will explain why it is worth it.
The rollback isn't true rollback and it is not fluid. Watching your units be unresponsive while you watch the game play out to 'resync' based on your previous input is absolutely terrible and infinitely more tilting than something like original overwatch kill feeds when you see your character dying after you were clearly out of line of sight for an extended period. (If it actually kept taking inputs until the point of resync then it would be fine, as of now it's a coin flip of "lol were you clicking toward or away?")
It's just a worse trade off versus letting the game play out organically and just only letting the player with poor ping or connection to the server take the L. How it is currently functioning would only be acceptable in some type of a-move auto battler.
If you look at fighting games for example there is only about a 3 frame buffer ever allotted for rollback purposes. This is about an 8-45ms range -- outside of this you'll see full pauses, stuttering, or the match terminating. While very annoying still it's generally pretty seemless and fluid in those parameters.
I've seen instances in stormgate where the correction easily exceeds up to 300ms. That's more than triple a 3 frame delay buffer plus 3 frames of rollback.
|
On August 16 2025 16:42 Agh wrote:
The rollback isn't true rollback and it is not fluid. Watching your units be unresponsive while you watch the game play out to 'resync' based on your previous input is absolutely terrible and infinitely more tilting than something like original overwatch kill feeds when you see your character dying after you were clearly out of line of sight for an extended period. (If it actually kept taking inputs until the point of resync then it would be fine, as of now it's a coin flip of "lol were you clicking toward or away?")
It's just a worse trade off versus letting the game play out organically and just only letting the player with poor ping or connection to the server take the L. How it is currently functioning would only be acceptable in some type of a-move auto battler.
If you look at fighting games for example there is only about a 3 frame buffer ever allotted for rollback purposes. This is about an 8-45ms range -- outside of this you'll see full pauses, stuttering, or the match terminating. While very annoying still it's generally pretty seemless and fluid in those parameters.
I've seen instances in stormgate where the correction easily exceeds up to 300ms. That's more than triple a 3 frame delay buffer plus 3 frames of rollback.
Maybe you can explain me.
Rollback is mostly used in fighting games.
Fighting games are built on precise player interactions. If the opponent presses his charged attack, I might have 20 frames to punish it. If I have 130 ping, and my enemy has 10, all my 20 frames are eaten by latency, and I can't punish at all. That's why they use roleback.
RTS games don't have such interactions. The closest thing I can think of is surround. But surrounds work perfectly in SC2.
Also, RTS can have hundreds of entities, while fighting games usually have just a few. That's why CPU load is much heavier.
My question is: why do we need rollback in RTS in the first place?
|
On August 17 2025 01:55 ChillFlame wrote:My question is: why do we need rollback in RTS in the first place? Because it sounds cool.
I can't see a reason why you need rollback in an RTS unless your trying to make a super micro intensive game where you have like a dozen units max and you need frame perfect counters to what your opponent is doing.
RTS games simply do not require the extreme low frame reaction speeds to warrant roll back net code.
|
On August 17 2025 01:55 ChillFlame wrote:Show nested quote +On August 16 2025 16:42 Agh wrote:
The rollback isn't true rollback and it is not fluid. Watching your units be unresponsive while you watch the game play out to 'resync' based on your previous input is absolutely terrible and infinitely more tilting than something like original overwatch kill feeds when you see your character dying after you were clearly out of line of sight for an extended period. (If it actually kept taking inputs until the point of resync then it would be fine, as of now it's a coin flip of "lol were you clicking toward or away?")
It's just a worse trade off versus letting the game play out organically and just only letting the player with poor ping or connection to the server take the L. How it is currently functioning would only be acceptable in some type of a-move auto battler.
If you look at fighting games for example there is only about a 3 frame buffer ever allotted for rollback purposes. This is about an 8-45ms range -- outside of this you'll see full pauses, stuttering, or the match terminating. While very annoying still it's generally pretty seemless and fluid in those parameters.
I've seen instances in stormgate where the correction easily exceeds up to 300ms. That's more than triple a 3 frame delay buffer plus 3 frames of rollback.
Maybe you can explain me. Rollback is mostly used in fighting games. Fighting games are built on precise player interactions. If the opponent presses his charged attack, I might have 20 frames to punish it. If I have 130 ping, and my enemy has 10, all my 20 frames are eaten by latency, and I can't punish at all. That's why they use roleback. RTS games don't have such interactions. The closest thing I can think of is surround. But surrounds work perfectly in SC2. Also, RTS can have hundreds of entities, while fighting games usually have just a few. That's why CPU load is much heavier. My question is: why do we need rollback in RTS in the first place?
No, rollback in fighting games only purpose is to prevent desyncs. Has nothing to do with innate latency, frames, etc.
Think of this as an example: Within the X frames of designated rollback both players do a move that would result in drastically different game states. Generally games code and collision interaction would take care of this but in the rare fall through cases that it does not that is what rollback is for, and is usually only triggered by lag spikes/inconsistencies from a player.
But aside from clearing that up to answer your question, No RTS does not need it. Especially not a poor implementation of it.
|
On August 17 2025 02:24 Agh wrote:Show nested quote +On August 17 2025 01:55 ChillFlame wrote:On August 16 2025 16:42 Agh wrote:
The rollback isn't true rollback and it is not fluid. Watching your units be unresponsive while you watch the game play out to 'resync' based on your previous input is absolutely terrible and infinitely more tilting than something like original overwatch kill feeds when you see your character dying after you were clearly out of line of sight for an extended period. (If it actually kept taking inputs until the point of resync then it would be fine, as of now it's a coin flip of "lol were you clicking toward or away?")
It's just a worse trade off versus letting the game play out organically and just only letting the player with poor ping or connection to the server take the L. How it is currently functioning would only be acceptable in some type of a-move auto battler.
If you look at fighting games for example there is only about a 3 frame buffer ever allotted for rollback purposes. This is about an 8-45ms range -- outside of this you'll see full pauses, stuttering, or the match terminating. While very annoying still it's generally pretty seemless and fluid in those parameters.
I've seen instances in stormgate where the correction easily exceeds up to 300ms. That's more than triple a 3 frame delay buffer plus 3 frames of rollback.
Maybe you can explain me. Rollback is mostly used in fighting games. Fighting games are built on precise player interactions. If the opponent presses his charged attack, I might have 20 frames to punish it. If I have 130 ping, and my enemy has 10, all my 20 frames are eaten by latency, and I can't punish at all. That's why they use roleback. RTS games don't have such interactions. The closest thing I can think of is surround. But surrounds work perfectly in SC2. Also, RTS can have hundreds of entities, while fighting games usually have just a few. That's why CPU load is much heavier. My question is: why do we need rollback in RTS in the first place? No, rollback in fighting games only purpose is to prevent desyncs. Has nothing to do with innate latency, frames, etc. Think of this as an example: Within the X frames of designated rollback both players do a move that would result in drastically different game states. Generally games code and collision interaction would take care of this but in the rare fall through cases that it does not that is what rollback is for, and is usually only triggered by lag spikes/inconsistencies from a player. But aside from clearing that up to answer your question, No RTS does not need it. Especially not a poor implementation of it.
You are insanely incorrect on this, to the point that I cannot believe you are stating this so confidently. Fighting games and RTS games both generally operate using lockstep networking, which means that each client simulates the game state resulting from player actions locally, and clients only transmit their actions to each other. This is in contrast to state-based synchronization that happens in things like FPS games (where clients often transmit actions to a server, and the server tells the client what the new states are, e.g. how much health someone has or what direction they are facing). RTS games prefer lockstep because transmitting state for all of the units/world can be expensive with lots of units, fighting games prefer it for different reasons, but the underlying concepts are the same.
In traditional lockstep networking (which we can refer to as delay-based), clients can only simulate the next turn once they have received the inputs/actions from all other players for the previous turn. If any of those inputs are missing, clients must wait until they receive them. That is, the game freezes and does not advance further. For very short delays this appears as stuttery gameplay that subtly affects the timing of your inputs, for longer delays this becomes completely unplayable with the game stopping for a very noticeable period of time.
Contrary to what you might believe, the internet is not fully reliable, even if you're on a wired connection with a quality ISP. Latencies can be somewhat variable during the course of a match, packets may randomly drop or be delayed depending on how overloaded the network infrastructure between you and your opponent is, etc. So even if you start a match well within the latency requirements to not have delays, there almost certainly will be some times within that match where you'll fall outside those bounds and a delay will happen.
Rollback attempts to solve this issue by recognizing that for a lot of the simulated turns, the inputs from other players are often empty (or basically empty), i.e. "keep doing the same thing I was doing last turn". So if we are missing a turn from a player, instead of waiting for those inputs to arrive, we can just predict that they are still doing the same thing as previously, and simulate forward with that predicted input. When we later receive their *actual* inputs for that turn, if they don't match what we predicted, we can rewind time to that turn, resimulate with the corrected inputs, and then resimulate all of the following turns as well to get us back to the present turn. When this happens, there is often some noticeable weirdness in the gameplay (e.g. a character suddenly switching animations, teleporting, etc.), but in a well implemented system with minimal rollback frames, these are often less disruptive than freezing the game to wait for inputs or using a higher delay time.
Rollback is broadly used and well-tested in fighting games, and I think obviously preferable to a purely delay-based system. It has nothing to do with "desync prevention", a desync is when the game simulations between 2 clients disagree. If that happens in a lockstep system, there is a bug in the game, full stop. You fix/prevent that by fixing the bug, not papering over it with netcode, and if you were to paper over it, rollback provides no benefits in this regard over delay-based lockstep.
For RTSes, rollback has never been tried before Stormgate, to my knowledge. There are almost certainly a lot of weird edges that would need to be tried and figured out, depending on how things feel (and this is a lot of the difficulty, you can't really logic your way through a lot of these things, you have to test them with real players and see how they react). I absolutely think this is a useful addition to RTS netcode, though. I run a 3rd party server for BW with custom netcode, and rollback is something we would like to add in the future. In the existing netcode, we see stuttering *all the time* across every sort of connection. A lot of times it is happening without people directly noticing it (which people sometimes call "microstutters"), because it is only delaying for a few milliseconds every second, but this definitely does affect people's gameplay. If you can instead simulate one turn ahead and correct things a few milliseconds later, you hit a sweet spot where the game never delays and the visual impact of rollback is probably not noticeable.
As far as Stormgate's implementation, I can't really speak on it. I'll say that lots of fighting games have had less-than-optimal implementations of rollback, and there are lots of details you need to get right for it to work well. So even if their implementation isn't working well right now, I think writing it off for the genre as a whole is definitely mistaken.
If you'd like a deeper explanation of rollback with lots of illustrations (although fighting-game-focused instead of RTS since this is all very new for RTS), this one is good: https://words.infil.net/w02-netcode.html
|
OpenRA (www.openra.net) has some limited implementation of rollback, so far it's probably only for UI reactions though. But full rollback is likely easier to implement for early RTS games with simpler game states.
|
seeing how well dow1 DE is doing, a sc2 remaster would just wipe SG out of existence
|
On August 17 2025 05:06 tec27 wrote:Show nested quote +On August 17 2025 02:24 Agh wrote:On August 17 2025 01:55 ChillFlame wrote:On August 16 2025 16:42 Agh wrote:
The rollback isn't true rollback and it is not fluid. Watching your units be unresponsive while you watch the game play out to 'resync' based on your previous input is absolutely terrible and infinitely more tilting than something like original overwatch kill feeds when you see your character dying after you were clearly out of line of sight for an extended period. (If it actually kept taking inputs until the point of resync then it would be fine, as of now it's a coin flip of "lol were you clicking toward or away?")
It's just a worse trade off versus letting the game play out organically and just only letting the player with poor ping or connection to the server take the L. How it is currently functioning would only be acceptable in some type of a-move auto battler.
If you look at fighting games for example there is only about a 3 frame buffer ever allotted for rollback purposes. This is about an 8-45ms range -- outside of this you'll see full pauses, stuttering, or the match terminating. While very annoying still it's generally pretty seemless and fluid in those parameters.
I've seen instances in stormgate where the correction easily exceeds up to 300ms. That's more than triple a 3 frame delay buffer plus 3 frames of rollback.
Maybe you can explain me. Rollback is mostly used in fighting games. Fighting games are built on precise player interactions. If the opponent presses his charged attack, I might have 20 frames to punish it. If I have 130 ping, and my enemy has 10, all my 20 frames are eaten by latency, and I can't punish at all. That's why they use roleback. RTS games don't have such interactions. The closest thing I can think of is surround. But surrounds work perfectly in SC2. Also, RTS can have hundreds of entities, while fighting games usually have just a few. That's why CPU load is much heavier. My question is: why do we need rollback in RTS in the first place? No, rollback in fighting games only purpose is to prevent desyncs. Has nothing to do with innate latency, frames, etc. Think of this as an example: Within the X frames of designated rollback both players do a move that would result in drastically different game states. Generally games code and collision interaction would take care of this but in the rare fall through cases that it does not that is what rollback is for, and is usually only triggered by lag spikes/inconsistencies from a player. But aside from clearing that up to answer your question, No RTS does not need it. Especially not a poor implementation of it. + Show Spoiler +You are insanely incorrect on this, to the point that I cannot believe you are stating this so confidently. Fighting games and RTS games both generally operate using lockstep networking, which means that each client simulates the game state resulting from player actions locally, and clients only transmit their actions to each other. This is in contrast to state-based synchronization that happens in things like FPS games (where clients often transmit actions to a server, and the server tells the client what the new states are, e.g. how much health someone has or what direction they are facing). RTS games prefer lockstep because transmitting state for all of the units/world can be expensive with lots of units, fighting games prefer it for different reasons, but the underlying concepts are the same. In traditional lockstep networking (which we can refer to as delay-based), clients can only simulate the next turn once they have received the inputs/actions from all other players for the previous turn. If any of those inputs are missing, clients must wait until they receive them. That is, the game freezes and does not advance further. For very short delays this appears as stuttery gameplay that subtly affects the timing of your inputs, for longer delays this becomes completely unplayable with the game stopping for a very noticeable period of time. Contrary to what you might believe, the internet is not fully reliable, even if you're on a wired connection with a quality ISP. Latencies can be somewhat variable during the course of a match, packets may randomly drop or be delayed depending on how overloaded the network infrastructure between you and your opponent is, etc. So even if you start a match well within the latency requirements to not have delays, there almost certainly will be some times within that match where you'll fall outside those bounds and a delay will happen. Rollback attempts to solve this issue by recognizing that for a lot of the simulated turns, the inputs from other players are often empty (or basically empty), i.e. "keep doing the same thing I was doing last turn". So if we are missing a turn from a player, instead of waiting for those inputs to arrive, we can just predict that they are still doing the same thing as previously, and simulate forward with that predicted input. When we later receive their *actual* inputs for that turn, if they don't match what we predicted, we can rewind time to that turn, resimulate with the corrected inputs, and then resimulate all of the following turns as well to get us back to the present turn. When this happens, there is often some noticeable weirdness in the gameplay (e.g. a character suddenly switching animations, teleporting, etc.), but in a well implemented system with minimal rollback frames, these are often less disruptive than freezing the game to wait for inputs or using a higher delay time. Rollback is broadly used and well-tested in fighting games, and I think obviously preferable to a purely delay-based system. It has nothing to do with "desync prevention", a desync is when the game simulations between 2 clients disagree. If that happens in a lockstep system, there is a bug in the game, full stop. You fix/prevent that by fixing the bug, not papering over it with netcode, and if you were to paper over it, rollback provides no benefits in this regard over delay-based lockstep. For RTSes, rollback has never been tried before Stormgate, to my knowledge. There are almost certainly a lot of weird edges that would need to be tried and figured out, depending on how things feel (and this is a lot of the difficulty, you can't really logic your way through a lot of these things, you have to test them with real players and see how they react). I absolutely think this is a useful addition to RTS netcode, though. I run a 3rd party server for BW with custom netcode, and rollback is something we would like to add in the future. In the existing netcode, we see stuttering *all the time* across every sort of connection. A lot of times it is happening without people directly noticing it (which people sometimes call "microstutters"), because it is only delaying for a few milliseconds every second, but this definitely does affect people's gameplay. If you can instead simulate one turn ahead and correct things a few milliseconds later, you hit a sweet spot where the game never delays and the visual impact of rollback is probably not noticeable. As far as Stormgate's implementation, I can't really speak on it. I'll say that lots of fighting games have had less-than-optimal implementations of rollback, and there are lots of details you need to get right for it to work well. So even if their implementation isn't working well right now, I think writing it off for the genre as a whole is definitely mistaken. If you'd like a deeper explanation of rollback with lots of illustrations (although fighting-game-focused instead of RTS since this is all very new for RTS), this one is good: https://words.infil.net/w02-netcode.html
Not really sure how I'm "insanely incorrect" giving him a concise and easy to follow answer, without spewing a wall of text that they don't care about. Apparently not-so-obvious hyperbole? Sure. Incorrect? Not really. The "simulation/prediction" meme text is why anyone even gets confused in the first place. While once sort of an apt description it's been ruined by marketing.
I'd take consistent micro stutters from delay based netcode any day of the week for RTS over stormgate's completely lost/ignored inputs & different game states. (looping last known inputs is asinine imo, which is what I can only imagine is happening in the especially bad instances with SG.)
Fighting games are love and hate for me. Stutters are infinitely more noticeable, to the point where anyone that has played with modern rollback on something like Tekken8/SF6 would be hard pressed to go back since it's just too fluid.
More to elaborate on the original question and confusion: the main thing to know is rollback is not going "back in time" or resetting in any facet. It's simply just repeating the game-state (or "ReSiMuLaTiNg") with the exact same inputs to produce the result.
|
On August 17 2025 05:06 tec27 wrote:Show nested quote +On August 17 2025 02:24 Agh wrote:On August 17 2025 01:55 ChillFlame wrote:On August 16 2025 16:42 Agh wrote:
The rollback isn't true rollback and it is not fluid. Watching your units be unresponsive while you watch the game play out to 'resync' based on your previous input is absolutely terrible and infinitely more tilting than something like original overwatch kill feeds when you see your character dying after you were clearly out of line of sight for an extended period. (If it actually kept taking inputs until the point of resync then it would be fine, as of now it's a coin flip of "lol were you clicking toward or away?")
It's just a worse trade off versus letting the game play out organically and just only letting the player with poor ping or connection to the server take the L. How it is currently functioning would only be acceptable in some type of a-move auto battler.
If you look at fighting games for example there is only about a 3 frame buffer ever allotted for rollback purposes. This is about an 8-45ms range -- outside of this you'll see full pauses, stuttering, or the match terminating. While very annoying still it's generally pretty seemless and fluid in those parameters.
I've seen instances in stormgate where the correction easily exceeds up to 300ms. That's more than triple a 3 frame delay buffer plus 3 frames of rollback.
Maybe you can explain me. Rollback is mostly used in fighting games. Fighting games are built on precise player interactions. If the opponent presses his charged attack, I might have 20 frames to punish it. If I have 130 ping, and my enemy has 10, all my 20 frames are eaten by latency, and I can't punish at all. That's why they use roleback. RTS games don't have such interactions. The closest thing I can think of is surround. But surrounds work perfectly in SC2. Also, RTS can have hundreds of entities, while fighting games usually have just a few. That's why CPU load is much heavier. My question is: why do we need rollback in RTS in the first place? No, rollback in fighting games only purpose is to prevent desyncs. Has nothing to do with innate latency, frames, etc. Think of this as an example: Within the X frames of designated rollback both players do a move that would result in drastically different game states. Generally games code and collision interaction would take care of this but in the rare fall through cases that it does not that is what rollback is for, and is usually only triggered by lag spikes/inconsistencies from a player. But aside from clearing that up to answer your question, No RTS does not need it. Especially not a poor implementation of it. You are insanely incorrect on this, to the point that I cannot believe you are stating this so confidently. Fighting games and RTS games both generally operate using lockstep networking, which means that each client simulates the game state resulting from player actions locally, and clients only transmit their actions to each other. This is in contrast to state-based synchronization that happens in things like FPS games (where clients often transmit actions to a server, and the server tells the client what the new states are, e.g. how much health someone has or what direction they are facing). RTS games prefer lockstep because transmitting state for all of the units/world can be expensive with lots of units, fighting games prefer it for different reasons, but the underlying concepts are the same. In traditional lockstep networking (which we can refer to as delay-based), clients can only simulate the next turn once they have received the inputs/actions from all other players for the previous turn. If any of those inputs are missing, clients must wait until they receive them. That is, the game freezes and does not advance further. For very short delays this appears as stuttery gameplay that subtly affects the timing of your inputs, for longer delays this becomes completely unplayable with the game stopping for a very noticeable period of time. Contrary to what you might believe, the internet is not fully reliable, even if you're on a wired connection with a quality ISP. Latencies can be somewhat variable during the course of a match, packets may randomly drop or be delayed depending on how overloaded the network infrastructure between you and your opponent is, etc. So even if you start a match well within the latency requirements to not have delays, there almost certainly will be some times within that match where you'll fall outside those bounds and a delay will happen. Rollback attempts to solve this issue by recognizing that for a lot of the simulated turns, the inputs from other players are often empty (or basically empty), i.e. "keep doing the same thing I was doing last turn". So if we are missing a turn from a player, instead of waiting for those inputs to arrive, we can just predict that they are still doing the same thing as previously, and simulate forward with that predicted input. When we later receive their *actual* inputs for that turn, if they don't match what we predicted, we can rewind time to that turn, resimulate with the corrected inputs, and then resimulate all of the following turns as well to get us back to the present turn. When this happens, there is often some noticeable weirdness in the gameplay (e.g. a character suddenly switching animations, teleporting, etc.), but in a well implemented system with minimal rollback frames, these are often less disruptive than freezing the game to wait for inputs or using a higher delay time. Rollback is broadly used and well-tested in fighting games, and I think obviously preferable to a purely delay-based system. It has nothing to do with "desync prevention", a desync is when the game simulations between 2 clients disagree. If that happens in a lockstep system, there is a bug in the game, full stop. You fix/prevent that by fixing the bug, not papering over it with netcode, and if you were to paper over it, rollback provides no benefits in this regard over delay-based lockstep. For RTSes, rollback has never been tried before Stormgate, to my knowledge. There are almost certainly a lot of weird edges that would need to be tried and figured out, depending on how things feel (and this is a lot of the difficulty, you can't really logic your way through a lot of these things, you have to test them with real players and see how they react). I absolutely think this is a useful addition to RTS netcode, though. I run a 3rd party server for BW with custom netcode, and rollback is something we would like to add in the future. In the existing netcode, we see stuttering *all the time* across every sort of connection. A lot of times it is happening without people directly noticing it (which people sometimes call "microstutters"), because it is only delaying for a few milliseconds every second, but this definitely does affect people's gameplay. If you can instead simulate one turn ahead and correct things a few milliseconds later, you hit a sweet spot where the game never delays and the visual impact of rollback is probably not noticeable. As far as Stormgate's implementation, I can't really speak on it. I'll say that lots of fighting games have had less-than-optimal implementations of rollback, and there are lots of details you need to get right for it to work well. So even if their implementation isn't working well right now, I think writing it off for the genre as a whole is definitely mistaken. If you'd like a deeper explanation of rollback with lots of illustrations (although fighting-game-focused instead of RTS since this is all very new for RTS), this one is good: https://words.infil.net/w02-netcode.html
Just wanted to chime in an thank you for your input. This is a real quality post.
|
On August 17 2025 15:27 Agh wrote:Show nested quote +On August 17 2025 05:06 tec27 wrote:On August 17 2025 02:24 Agh wrote:On August 17 2025 01:55 ChillFlame wrote:On August 16 2025 16:42 Agh wrote:
The rollback isn't true rollback and it is not fluid. Watching your units be unresponsive while you watch the game play out to 'resync' based on your previous input is absolutely terrible and infinitely more tilting than something like original overwatch kill feeds when you see your character dying after you were clearly out of line of sight for an extended period. (If it actually kept taking inputs until the point of resync then it would be fine, as of now it's a coin flip of "lol were you clicking toward or away?")
It's just a worse trade off versus letting the game play out organically and just only letting the player with poor ping or connection to the server take the L. How it is currently functioning would only be acceptable in some type of a-move auto battler.
If you look at fighting games for example there is only about a 3 frame buffer ever allotted for rollback purposes. This is about an 8-45ms range -- outside of this you'll see full pauses, stuttering, or the match terminating. While very annoying still it's generally pretty seemless and fluid in those parameters.
I've seen instances in stormgate where the correction easily exceeds up to 300ms. That's more than triple a 3 frame delay buffer plus 3 frames of rollback.
Maybe you can explain me. Rollback is mostly used in fighting games. Fighting games are built on precise player interactions. If the opponent presses his charged attack, I might have 20 frames to punish it. If I have 130 ping, and my enemy has 10, all my 20 frames are eaten by latency, and I can't punish at all. That's why they use roleback. RTS games don't have such interactions. The closest thing I can think of is surround. But surrounds work perfectly in SC2. Also, RTS can have hundreds of entities, while fighting games usually have just a few. That's why CPU load is much heavier. My question is: why do we need rollback in RTS in the first place? No, rollback in fighting games only purpose is to prevent desyncs. Has nothing to do with innate latency, frames, etc. Think of this as an example: Within the X frames of designated rollback both players do a move that would result in drastically different game states. Generally games code and collision interaction would take care of this but in the rare fall through cases that it does not that is what rollback is for, and is usually only triggered by lag spikes/inconsistencies from a player. But aside from clearing that up to answer your question, No RTS does not need it. Especially not a poor implementation of it. + Show Spoiler +You are insanely incorrect on this, to the point that I cannot believe you are stating this so confidently. Fighting games and RTS games both generally operate using lockstep networking, which means that each client simulates the game state resulting from player actions locally, and clients only transmit their actions to each other. This is in contrast to state-based synchronization that happens in things like FPS games (where clients often transmit actions to a server, and the server tells the client what the new states are, e.g. how much health someone has or what direction they are facing). RTS games prefer lockstep because transmitting state for all of the units/world can be expensive with lots of units, fighting games prefer it for different reasons, but the underlying concepts are the same. In traditional lockstep networking (which we can refer to as delay-based), clients can only simulate the next turn once they have received the inputs/actions from all other players for the previous turn. If any of those inputs are missing, clients must wait until they receive them. That is, the game freezes and does not advance further. For very short delays this appears as stuttery gameplay that subtly affects the timing of your inputs, for longer delays this becomes completely unplayable with the game stopping for a very noticeable period of time. Contrary to what you might believe, the internet is not fully reliable, even if you're on a wired connection with a quality ISP. Latencies can be somewhat variable during the course of a match, packets may randomly drop or be delayed depending on how overloaded the network infrastructure between you and your opponent is, etc. So even if you start a match well within the latency requirements to not have delays, there almost certainly will be some times within that match where you'll fall outside those bounds and a delay will happen. Rollback attempts to solve this issue by recognizing that for a lot of the simulated turns, the inputs from other players are often empty (or basically empty), i.e. "keep doing the same thing I was doing last turn". So if we are missing a turn from a player, instead of waiting for those inputs to arrive, we can just predict that they are still doing the same thing as previously, and simulate forward with that predicted input. When we later receive their *actual* inputs for that turn, if they don't match what we predicted, we can rewind time to that turn, resimulate with the corrected inputs, and then resimulate all of the following turns as well to get us back to the present turn. When this happens, there is often some noticeable weirdness in the gameplay (e.g. a character suddenly switching animations, teleporting, etc.), but in a well implemented system with minimal rollback frames, these are often less disruptive than freezing the game to wait for inputs or using a higher delay time. Rollback is broadly used and well-tested in fighting games, and I think obviously preferable to a purely delay-based system. It has nothing to do with "desync prevention", a desync is when the game simulations between 2 clients disagree. If that happens in a lockstep system, there is a bug in the game, full stop. You fix/prevent that by fixing the bug, not papering over it with netcode, and if you were to paper over it, rollback provides no benefits in this regard over delay-based lockstep. For RTSes, rollback has never been tried before Stormgate, to my knowledge. There are almost certainly a lot of weird edges that would need to be tried and figured out, depending on how things feel (and this is a lot of the difficulty, you can't really logic your way through a lot of these things, you have to test them with real players and see how they react). I absolutely think this is a useful addition to RTS netcode, though. I run a 3rd party server for BW with custom netcode, and rollback is something we would like to add in the future. In the existing netcode, we see stuttering *all the time* across every sort of connection. A lot of times it is happening without people directly noticing it (which people sometimes call "microstutters"), because it is only delaying for a few milliseconds every second, but this definitely does affect people's gameplay. If you can instead simulate one turn ahead and correct things a few milliseconds later, you hit a sweet spot where the game never delays and the visual impact of rollback is probably not noticeable. As far as Stormgate's implementation, I can't really speak on it. I'll say that lots of fighting games have had less-than-optimal implementations of rollback, and there are lots of details you need to get right for it to work well. So even if their implementation isn't working well right now, I think writing it off for the genre as a whole is definitely mistaken. If you'd like a deeper explanation of rollback with lots of illustrations (although fighting-game-focused instead of RTS since this is all very new for RTS), this one is good: https://words.infil.net/w02-netcode.html Not really sure how I'm "insanely incorrect" giving him a concise and easy to follow answer, without spewing a wall of text that they don't care about. The "simulation/prediction" meme text is why anyone even gets confused in the first place. While once sort of an apt description it's been ruined by marketing. I'd take consistent micro stutters from delay based netcode any day of the week for RTS over stormgate's completely lost/ignored inputs & different game states. (looping last known inputs is asinine imo, which is what I can only imagine is happening in the especially bad instances with SG.) Fighting games are love and hate for me. Stutters are infinitely more noticeable, to the point where anyone that has played with modern rollback on something like Tekken8/SF6 would be hard pressed to go back since it's just too fluid. More to elaborate on the original question and confusion: the main thing to know is rollback is not going "back in time" or resetting in any facet. It's simply just repeating the game-state (or "ReSiMuLaTiNg") with the exact same inputs to produce the result.
'exact same inputs' is more of a controller thing with continuous input (like holding down joystick in some direction) ; in rts games with distinct orders theres no repeating previous actions at all
the long playouts in stormgate also arent really rollback related its more about lacking a pause/lag screen when a player is far behind because of connection issues
as for the previous post yeah it as just completely wrong which is why tec wrote that ; the whole point of rollback is latency reduction it has nothing to do with desyncs
lockstep without rollback doesnt need to have microstutters anyway - there isnt in sc2 / wc3; only delay
|
|
|
|
|
|
EPT
