Search Unity

Object instantiation/management in persistant worlds

Discussion in 'Multiplayer' started by SixTimesNothing, Aug 4, 2008.

  1. SixTimesNothing

    SixTimesNothing

    Joined:
    Dec 26, 2007
    Posts:
    167
    I have a working multiplayer network set up for my game, but now I'm struggling a little trying to get my head around how to handle objects - or more specifically NetworkViews in a persistant world.

    The issue stems from the fact that, as the world is persistant, it isn't really feasible to use buffered RPCs, as a player logging in will be hit with an RPC for every player login/logout/death/respawn and every NPC death or respawn that has occured since the server was last booted. Hence I am currently tracking all player and server contolled units on the server side, and when a player logs in, they receive an RPC for each unit that is currently active in the game world telling their client to instantiate the appropriate unit (using Object.Instantiate) and assign it the correct NetworkViewID.

    I am running into two issues here:

    Firstly, I haven't set up network groups or scopes for NetworkViews properly yet (which is really my own fault :) ), which means that the new player is receiving state synchronisation for NetworkViews that don't exist in their scope yet, which causes a bunch of error messages to appear. I figure I should be able to fix this, and start to move towards a viable MMO network setup by dividing the world into areas and assigning a network group to each area, and when a new player joins I can tell them to ignore everything in every group except for one group which will be used solely for telling the client what to instantiate. Then, once the objects are Instantiated and assigned the correct NetworkViewIDs, I should be able to tell the client to start receiving data from the appropriate group(s) depending on their location in the world.

    I'm wondering if this all makes sense and whether I'm going about it the right way. It would be great to know if there's a better approach I can take before I implement all of that.

    On top of that, I have a second problem that I don't know how to fix - As I'm dealing with theoretically a large amount of network traffic I'm using ReliableDeltaCompressed from state synchronisation. When a new player or NPC unit is created, it syncs perfectly on the server, the client the created it (if applicable) as well as every client that was online at the time of the unit's creation. Players who log in after the unit was created get the instantiation RPC ok - with the up-to-date position, rotation, etc. but after that, the state synchronisation for that unit doesn't work - apparently because I'm not using Network.Instantiate, I get an error telling me that state synchronisation is failing because the object's original transform was never sent. Is there a way to allow the unit on the new client to be correctly synchronised without switching from ReliableDeltaCompressed to Unreliable?

    I hope that all made sense. Any help would be appreciated.
     
  2. SixTimesNothing

    SixTimesNothing

    Joined:
    Dec 26, 2007
    Posts:
    167
    I got it working. :)

    Blocking the network groups didn't work. I think this was because the client hadn't instantiated those network views locally yet, so the group IDs were essentially meaningless.

    I had to use NetworkView.SetScope for every unit in the game, which is a bit annoying. It would be good if there were functions that could just put everything out of scope, or everything in scope, rather than having to iterate through every unit in the entire game. but i think this might come in useful once i start breaking the game world down into regions and only send players RPCs and state synchronisation for nearby units, rather than everything in the game.

    on the bright side, the ReliableDeltaCompressed issue seemed to fix itself automagically once I stopped the initial NetworkView errors from occuring.