What delay would the lockstep net turn have to be increased to to allow 32 players like FPS? Usually it's 200 ms, so if it's 1 sec, could it support 8 * 5 = 40 players?

How could casual drop-in be supported? I see two ways: downloading the whole game state, and a few catch-up net turn packets that happen while downloading, or sending all the net turn packets since the game started.

Why does the turn length have to be modified at all?

The turn length just has to be greater than the maximum latency between any player. If all the players have under 200 ping to each other, then everything is fine.

Usually with lock-step RTS networking, the amount of data being exchanged is so small, that it doesn't really have an impact on value chosen for the turn length.

FWIW planetary annihilation supports join-in-progress by using (FPS-like) client-server networking rather than lock-step

For drop in play with deterministic lockstep you might be able to

- take a "full world snapshot" on the server

- begin sending the world snapshot to the new joiner (could take a "long" time with 1000s of units, maybe a few whole seconds )

- at the same time start buffering all new input that happened since the snapshot was taken

- after the world snapshot has been sent start sending all the inputs that were missed

- on the client side, after receiving the snapshot you start playing back inputs as fast as you can (with no rendering) in order to catch up with real time.

- continue business as usual

??? just an idea

it occurs to me now that deterministic lockstep doesn't necessarily use a "server" really. just something that coordinates input. oh well

I guess the worry would be that with 32 players, the chances of someone with really crappy latency or a choppy connection ruining the experience for everyone is fairly high.

So if you're going with 32 player lockstep, I'd avoid the standard star topology where everyone sends their input to everyone else, and a single late input holds everything up. You could have it so that everyone sends their input actions to an arbitrarily chosen server machine (i.e. one of the peers, preferably one with a decent connection), who can forward the actions to everyone else. Then have it so that the server doesn't wait for everyone's input, it just gets pushed out by the server machine as soon as possible.

I'd see no reason that 200ms wouldn't be OK.

Also, it's not turn length that matters, it's turn length times number of turns delay. You can easily make your turn length 50 milliseconds, and send commands for 10 turns into the future, which lets you have 500 ms lag.

Join-in-progress requires a big state dump, which can be costly if there are lots of players and lots of terrain (and lots of scattered resources, like wood in Warcraft.)