Freeze prevention on MP download/join

[markheloking]

Hi dev's and fellow fans, I have an idea about making the game (especially multiplayer) more smooth in terms of uninterrupted gameplay.

Current situation:
When someone joins a multiplayer server, right now all the clients (including server) save the "current" gamestate and put it up for download to the new joining client (either P2P or direct download from server depending on the settings). The game freezes (and depending on the settings the users may or may not even see a notification/dialog at all: more on that in the sidenotes later on) while the new client is downloading the map, which can take a long (I've seen 10+ minutes) while if the map is big (30MB+) and the client has a slow connection. During this time no gameplay (not even looking around the map) is possible, only zooming is allowed. When the download is finished everyone syncs up and the game resumes.

In short:

• Player requests join

• All clients/server freeze

• Player downloads map

• Game resumes

New situation:
In the new situation all the clients/server agree on the same state and save it. They then offer that state up for download to the new joining client, while also keeping track of/saving the heartbeats in the mean time. When the joining client has the whole state all the missed heartbeats are offered up as download until the client is in sync at which point he joins the game.

In short:

• Player requests join

• All clients/server agree on the same state, save it and keep track of the heartbeats in the mean time

• Player downloads mentioned state

• Player has the whole state, now downloads all missed heartbeats

• Once player is in sync he joins the game

Discussion:
Pros:

• Uninterrupted gameplay for players in a multiplayer server even if the joining player has problems joining (finally)

Cons:

• Disfavors people with slow connections (joining takes longer since there's more to download)

• People with too slow connections won't be able to catch up with the heartbeats at all (but this seems like an advantage to me since those connections will be so bad that they will cause too much lagg anyway)

• More upload traffic on the server if a lot of people are trying to join and P2P is disabled (making joining impossible because the server's network isn't fast enough)

[FeepingCreature]

Easier: just have the new client buffer packets, then fast-forward when it finishes the download.

[markheloking]

I don't think that would work since the clients connection is already clogged up by downloading the full state/map so it'll miss (some) heartbeats.

[MF-]

The clog situation needs to be fixed anyway.


I think that buffering at the connecting client could work well,
while buffering at the client would complicate the game loop
and lead to more corner cases with more clients joining at once.

[ratchetfreak]

Easier: just have the new client buffer packets, then fast-forward when it finishes the download.

"fast forward" won't work if the map is already lagging below 60 ups

no what would help is splitting up the download into various stages depending on how static the data is.

First download terrain

then static entity locations and types

Then freeze gameplay and sync mobile entity state and the more fluid entity state (inventories and progress bars)

[markheloking]

Isn't it possible to get much higher UPS if there's no GUI/frames to be rendered? The whole framesyncing stuff can be omitted in that part of trying to catch up as far as I know. Might be quite a code change, but should at least be possible. The real question would be whether that would speed it up enough.

I really like the splitting the "save" up in parts and then serving it to the new client in a static first, most dynamic last kind of fashion. Seems logical, although I'm not sure whether that would help enough.

[TuckJohn]

Good idea, but I would like the devs to rather spend their time making new features

[ssilk]

TuckJohn: Please don't break into a discussion by only reading the first post.