How does streaming work in multiplayer (co-op)?

[Lisethinew]

Trying to get a better understanding of udk and its workings and I was wondering if anyone knows how streaming works in multiplayer? Is it a problem if each player is in a different area than the others and the computer is having to run say 4 of the areas at once?
Would I have to use a system like in borderlands where everyone agrees to go to the next area and then there's a loading screen or is it possible to have a streaming transition between areas when playing co-operatively over the internet?
Thanks for the help!

[Jetfire]

You can stream during gameplay but it will cause a hitch dependent on their pc's power and how heavy a level you're trying to bring in

Also, last I knew, streaming is done server-side, so you can't stream in stuff on a per-client basis, if something is loaded for one, it is loaded for all.

[ambershee]

I'd personally recommend using a system more like Borderlands, since level streaming in a multiplayer environment can be a real can of worms.

[Blade[UG]]

From what I've heard, you need to do a lot of stuff to make sure that both clients and server have everything streamed in when they need it.

[Chosker]

Also, last I knew, streaming is done server-side, so you can't stream in stuff on a per-client basis, if something is loaded for one, it is loaded for all.

does this mean if I have 5 players running around on totally opposite sides of the world (on a different streamed level each), everyone and the server have the 5 levels in memory?
some distance culling could do the trick for rendering but I can see CPU and memory are going to be slow so easily

[Lisethinew]

Thanks for the replies everyone, you've been lots of help.

[Bellbird Creative]

My question would be... If I have an output from On Level Loaded & Visible does it wait for that to be true for everyone? I'll find out soon enough :O

[Graylord]

does this mean if I have 5 players running around on totally opposite sides of the world (on a different streamed level each), everyone and the server have the 5 levels in memory?
some distance culling could do the trick for rendering but I can see CPU and memory are going to be slow so easily

No, I believe it would mean every player would have to be on the same level.

[UnspoiledWalnut]

Why is it done on the server side? That seems really weird to me....

[Wyldhunt]

Let me see if I can clear some of this up...
When any game is multiplayer, there will be a few basic options for every function call in the script.

• You can set the function to only run on the client.
• You can set the function to only call on the server.
• You can set the function to run on the client and the server.
• You can have the server update all of the clients based upon the servers results.

Every game works that way. There is no difference in the basic model of data transfer on the base level.

Why it works this way:
I'll give a few examples.

1. A player casts an Invisibility spell in an RPG game.
   • A function runs on the players’ client computer that increases the transparency of his character so that the player can still see himself but has the impression of being invisible. This only needs to run on the local client
   • A function runs on the server that sets a variable which the AI uses to react as though they cannot see the player. This only needs to run on the server.
   • A function runs on all non local clients which makes the character 100% transparent (or sometimes unloads the mesh entirely). This only needs to run on external client computers. The server will trigger the changes to be made on the client computers the following tick.
2. A player destroys a destructible mesh
   • A function will run on server and all client computers so that all players and the AI will react to the modified terrain.
3. A player touches a trigger that spawns an enemy in the next room
   • A function will run on only the server to spawn the new enemy. There is no need to run anything on a client computer since that will be handled when the enemy first interacts with a player (Any player. Not only the one who spawned it.)

Because the server has to control the locations of everything in order to update clients’ computers with the new locations of other players and dynamic objects, it becomes necessary to keep the area in memory. The AI often depends upon knowing what terrain is nearby in order to react and make a decision. Since AI must be handled primarily on the server, that info must be made available. UDK uses streamlined pathfinding maps or waypoints to prevent the need of keeping every static mesh in active memory. However, it may still need to load them for the sake of raycasts or anything that may react to static meshes that run on the server. That's a good reason to avoid running that kind of check on the server. If you have 64 players in 64 different streaming levels, then the server can attempt to keep all of the information that it needs for all 64 levels in active memory so that it can continue to update the AI and client computers as needed. Obviously, this would require a serious server with a blazing fast connection. It does not mean that every client PC will have every map loaded in memory. The client and server computers can and will have different things loaded into memory at any given time. I don't know if UDK is programmed to have all streamed content loaded on all clients and the server or not, but there's really no need to have it all on every client computer. More likely, any lag is caused by the server lagging as it tries to track it all. Levels streaming in cause lag spikes locally because of the huge amount of shadows and meshes that it has to generate in a single call. That can be avoided by keeping your streaming levels as small and simple as possible.

Massively Multiplayer games manage to have all of that info loaded at once by using server clusters and modified servers that can communicate on countless ports at once.

As a result, these games can have a stack of servers which do nothing except update players’ health in the database. Or, a single server can have a map area loaded. All other servers reference that server for any immediate needs that they have related to location and surroundings.

You can learn more about free server clusters here: http://www.mysql.com/products/cluster/
Because UDK is not programmed to access/use the modified server architecture of clusters (or even databases in general), all of the data and processing for all of the players must happen on a single server with a strict packet size, and all variable information must be kept in active memory. That is why there is a 64 player limit in UDK.

There's a lot more to it than that. But, that's fairly accurate as a 'mile high view' of the techniques and exactly what UDK is doing.

Most of the function calls that happen are provided in uscript. And, we can choose when/where/how each function happens via uscript. So, we can fine tune quite a bit. Only the parts that are assumed to be required are hardcoded.

My question would be... If I have an output from On Level Loaded & Visible does it wait for that to be true for everyone? I'll find out soon enough :O

I don't use Kismet very much but I do know that the difference between the All Players variable and the Single Player variable is exactly that. If you use All Players, it will update on all client computers (And on the server so that the server can update the other clients). If you use the Single Player option, it will only run on the local client.

[Wyldhunt]

From what I've heard, you need to do a lot of stuff to make sure that both clients and server have everything streamed in when they need it.

And, yes. Blade is entirely correct. Making sure that every function call in the entire game is updating when they need to and only sending the information that they need to while making sure that the server will be able to respond properly to the information sent while keeping the amount of data transfered as small as possible can be a real PITA.