This seems to be a problem that has come from trying to use FPS networking mechanics in an RTS context.

Not really, this “problem” has come about from me seeking to reduce the latency that comes with lockstep. Ordinarily, when using lockstep, command latency is bound by packet frequency. I'm seeking to break this constraint.

Almost all games have a deterministic “input → simulation → output” process, but that is not what makes it lockstep - the lockstep aspect is that all simulations in the network apply the same input to the same simulation, and thereby get the same outputs.

I literally, right now, have a classic lockstep engine, as described in the OP, where all clients (and the server for that matter) have identical state, and an identical sequence of commands is executed on all of them. There is no rollback, because, as you say, it's not required.

However, I have spotted an opportunity to reduce command latency further by introducing rollback (as described in OP).

Normally RTS games are robust in the face of one client experiencing a bit of lag because it just means that their own input gets delayed slightly. No need for any prediction or rollback.

Yes, yes, this is exactly what I have now; however, the latency optimisation introduces the need for rollback.

So, in essence, I'm left with something that is exactly like a classic client-server lockstep i.e.
1) The latency of a command round trip (to the sever and back again) is masked by immediate local feedback
2) Large spikes in lag will result in a delay to the commands and the game “halting”
3) (Except in exceptional circumstances), no rollback is happening and all clients are executing an identical sequence of commands on identical world state

The difference is that:

1) I'll have shaved off 30-100ms off command latency. (Some might argue the price of implementing rollback is not worth it, but as a eSporter I disagree)
2) Rollback will occur when latency spikes happen. This may come with minor visual (a few frames at most) rubber banding before the client halts


I think I'm continuing to suffer being caught between two definitions.

james_lohr said:

I think I'm continuing to suffer being caught between two definitions.

Then ignore the semantics and get to the meat. As I was hinting at in my other reply, it really isn't an unsolved problem. Look at existing games, see how they do things, then ask targeted questions.

SC1/SC2 (and probably most RTS) seem to work only with known data (lag == pause). MOBAs, iirc, use prediction (lag == extrapolated movement). You can run through the steps of doing something different, but it's at least worth questioning why those decisions were made before reinventing the wheel. For an RTS, how does SC mask latency, despite working only with known data? What is the input delay? Does the input delay vary? etc etc

If you have a traditional deterministic lockstep implementation and it performs worse than existing RTS that seem to use the same approach, the next step would be to experimentally determine what they're doing better than you, not to start off in a separate direction. You could also question whether they are actually using a deterministic lockstep implementation, and see if you can find contrary evidence.

If you have a traditional deterministic lockstep implementation and it performs worse than existing RTS that seem to use the same approach, the next step would be to experimentally determine what they're doing better than you, not to start off in a separate direction. You could also question whether they are actually using a deterministic lockstep implementation, and see if you can find contrary evidence.

I was able to achieve similar performance to SC2/WC2 by upping my packet frequency from every 200ms to every 60ms.

However, I believe that I can achieve better performance (and less traffic) with option 2.). So, I'm now in the process of implementing it. We'll see what results I get. Perhaps it'll fall flat on its face.

SC1/SC2 (and probably most RTS) seem to work only with known data (lag == pause). MOBAs, iirc, use prediction (lag == extrapolated movement). You can run through the steps of doing something different, but it's at least worth questioning why those decisions were made before reinventing the wheel.

SC2/WC3 use lockstep because of the huge amount of state, and because the nature of the game (controlling many units, performing macro alongside micro, and queuing up actions) is such that a bit of extra latency is not a big deal.

The original MOBAs were lockstep (they were custom maps on SC1 and Wc3) so they used lockstep. Recent MOBAs probably use prediction because generally it provides:

1) Lower latency (you're controlling a single unit, so you really care a lot about latency)
2) Better security (can't map-hack)
3) Easier to implement (no need for strict determinism)

I'm basically going for a hybrid because I want the best of both worlds:
1) Lots of state
2) Low latency

Hi i am too interested in making a RTS game, tough i am totally newbie in multiplayer. Have read this tread so at least i know direction i should go but am also interested how your hybrid worked out so please share ?