Download

Passing loaded game data from server to client?

I have a multiplayer game that can be saved and reloaded. When the game is reloaded by the server (from a previously saved game), the server needs to pass the loaded game data to the clients so they can set up their world accordingly. To do this I have just been using a replicated variable, which is a struct that contains all the data from the saved game. The server loads the game, sets this variable and it auto replicates to the clients. The clients can then get to setting up their world.

This has worked great in testing. However I recently started setting up full size game levels (as opposed to my small test levels). As the size of the level increases so does the amount of data being saved and loaded. This has now obviously reached a level where it must be breaking the UE4 replication system. By breaking, I mean that the client just hangs and sits their indefinitely waiting for data the seemingly never arrives. If I make the level a little smaller, then it works fine. There seems to be some hard limit that I must be hitting. I ran the network profiler that comes with UE4 to have a look at what is going on. Now I don’t fully understand the profiler’s readings, but one thing that stood out to me was a spike in the transfer when the server starts the game and sets the replicated variable with the loaded game data. This spike seems to hit about 59Kb in size, which seems pretty small, but is obviously too big for a replicated variable to handle.

So I need to find a different solution. How can I transfer large amounts of data from the server to the client without it breaking?

Are RPC’s better for this sort of stuff or is there some other method?

Should I be trying to break the data up a bit across multiple replicated variables or multiple RPC calls with a chunk of data at a time or something?

I have since explored some other options and the best I’ve come up with so far is to break the save game data up into smaller chunks and then fire an RPC to the client with each chunk. The client then rebuilds the data on their end. This seems to work fine, however it seems it appears to delay all other network traffic for a while (about 10 seconds). So while the client is collecting all this data, the server continues with spawning various replicated actors for the map. The problem is that these actors then take about 10 seconds before they appear on the clients screen. I guess I could just have a loading screen and wait until all the actors are on the client before hiding it.

Alternatively, I could probably begin the transfer of the data in the lobby, before the player even get into the game. I could then just prevent the host from starting the game until all clients have received the data. Considering most people sit in the lobby for at least 10 seconds before starting the game, this shouldn’t be a big problem.

Anyone have any ideas on a better way to transfer a lot of data (such as the contents of a saved game) from the server to the client?

Maybe I shouldn’t be using UE4’s networking at all and something else entirely? I’m not sure.

Without considering your existing code, what I would do is handshake RPCs in chunks. Send a bit to the client with a Client RPC, let the client increment a loading bar, then have the client call a Server RPC to ask for more. You may also want to have some RPCs to tell everyone the state that everyone else is in (with regards to loading – think StarCraft II multiplayer loading screen).

I’d personally do this on BeginPlay(), and just cover the viewport with the loading screen. That said, and this is where “your existing code” could be a problem. If your game code assumes BeginPlay() is the start of the round, then you might not have time for this.

Have you tried using json ? If not check out varest plugin . I used it in a mmo type game to send and receive large amounts of data from a database using php and json .

Also you’re other thing about using a loading screen is something I think a lot of developers do to hide loading lag so it’s still a valid way of doing it