Search Unity

How to handle multiplayer in large environments or worlds

Discussion in 'Multiplayer' started by jc_lvngstn, Oct 26, 2011.

  1. jc_lvngstn

    jc_lvngstn

    Joined:
    Jul 19, 2006
    Posts:
    1,508
    I'm looking for suggestions on how to handle this situation:
    Multiplayer (obviously)
    Players may be in different regions of the "world"

    I've currently got one terrain/zone, and basic networking going. I can connect two players and have them see each other running around.
    The server is authoritative, and handles collisions and everything else. I'm using Unity's built in collision handling.

    So, here is the question:
    Setup this way, the game environment has to be running on the server. But the server (and Unity) can only handle so big of a world, using Unity's default way of handling scenes. If the world size were made up of 100x100 "terrains" stitched together, I don't believe Unity could (or should) handle having all of those loaded up on the server.

    Option 1: Server is authoritative, uses custom collision handling, does everything.
    Totally ditches Unity's colliders. The server uses the heightmap to determine character position on the terrain, and does its own bounds checking against things like trees and such.

    Another options...is go non-authoritative for some movement and collision detection, but authoritative for other actions like attacking, building, whatever.
    Server sends terrain and other environment data to the clients (or they load it from local resources). This will be terrain, and any structures, buildings, whatever.
    Clients generate terrain. Possibly a custom terrain gen. I'd like to use Unity's...but the terrain api is pretty hackish and lacking in some features.
    Clients control movement and collision handling, and report their positions to the server, which sends out the results to other clients. The good part about this...it lets the clients use Unity's built in collision handling and such, physics, etc.
    For all other client actions (attacking, etc), the clients send the command to the server, and the server handles this in an authoritative fashion.

    Any thoughts on this, suggestions, etc?
    Thanks!
     
  2. Shaneburk89

    Shaneburk89

    Joined:
    Apr 4, 2012
    Posts:
    3
    Don't load the maps at all. Load the vector points for each tile and each time a player moves a certain number of tiles send the positions of that number of tiles outside the players visible distance to the client from the server.

    All these points can be stored on a database and pulled by the server as people need them. (as people move)

    When a player is teraforming you could consider multiplexing the packets to change the terrain for all around to reduce bandwidth as well.

    On top of this I would make a separate program (server) for terraforming and separate for all game logic to reduce lag (both separate program and database dependent on how cpu intensive your checks and other functions will be)

    In short don't actually load the whole map slowly make it shorten one side and extend another with new vector points. This should save on cpu and in the end give you better server performance.

    I have little knowledge of unity and am not the best programmer in the world either but I hope my input helps.
     
  3. UnLogick

    UnLogick

    Joined:
    Jun 11, 2011
    Posts:
    1,745
    If you want to build a massive world with many players that has the entire world collision map loaded. I would guess you could run into a few problems. The first one coming to mind would be floating point precision. The second would be that there is only support for 32 collision layers so you can't really split the world into small enough pieces. Even in its optimized state it would be unfair to feed the physX engine with all the collision meshes of houses, fence and tree in a 1km square and check for collision each time a player moves 10cm. The only thing that might work was toggling the layers of the game objects really fast, but even if this is fast enough I wouldn't recommend it.

    Unity doesn't pride itself with being a mmo server. While you can build an mmo server inside Unity I would not recommend it. I plan to break down the collision into a height map and some very simple probably tile aligned collision blocks. And when it comes to the server being authorative on movement I would instead make it more simple than mesh collision. Say if there is a fence between tile X and X+1, the check could be simply that height was 50cm or more... if the client allows him to move through something is very wrong.

    I guess the real rub is distributed servers or central servers. If players are allowed to host their own servers you really need to consider memory. If you aim to host the servers yourself, another suggestion would be that memory is cheap, and it will only get cheaper. Make sure to write a 64 bit server and don't worry about using 20gb memory or more on keeping the world loaded. If you mean to unload stuff if no player is around make sure its a large enough block to matter... CPU usage when checking this and and IO usage for load/save can be more important than memory.

    That will be 2 cents, please.

    Cheers,
    UnLogick