Search Unity

Ad Hoc Networking Question

Discussion in 'Multiplayer' started by marty, Jul 31, 2008.

  1. marty

    marty

    Joined:
    Apr 27, 2005
    Posts:
    1,170
    In Unity peer-to-peer (ad hoc) networking, when the player who starts a game (as server) leaves that game, the game ends abrudptly for all players who have joined.

    Is thre a way to avoid this? Say, to hand the server role off to one of the clients?
     
  2. jashan

    jashan

    Joined:
    Mar 9, 2007
    Posts:
    3,307
    I don't think that is possible "out of the box", but you could probably implement a mechanism that does this. Basically, each client "simply" would need to handle Network.OnDisconnectedFromServer(...) properly.

    "Properly", however, probably means you'll need a lot of careful planning to do this and it will very likely touch most of your game systems. One of the "non-trivial issues" involved with this is deciding who will be the next server and then letting everyone know who it is. Another funky issue with this is authority: Who will decide what's the true current state (well, probably the new server ;-) ).

    So - no matter how you do it, it won't be "seamless". It's very likely that you'd have to stop the game for a moment. But it should be possible.

    Sunny regards,
    Jashan
     
  3. marty

    marty

    Joined:
    Apr 27, 2005
    Posts:
    1,170
    Thanks, J.

    Yup, that's what I figured.

    Plus, any solution is probably going to potentially introduce a chance for people to "scam" the game.
     
  4. zumwalt

    zumwalt

    Joined:
    Apr 18, 2007
    Posts:
    2,287
    Client that acts like the server (and all players), needs to have a queue.
    Ok, here is how you accomplish this task.
    4 Players
    A,B,C,D

    Server is Player A
    Server information is given to B,C, and D
    All players pass back there IP to the connection pool list of players.
    This document per say, contains the IP address and player info along with who is currently the server.

    Ok, now the fun begins, that was the easy part.
    Player B,C and D all also have a "silent server" started on each machine.
    In a peer to peer game, all machines know about all objects in play and information about those objects.

    Player A spills vodka on there keyboard, the cat gets drunk from drinking the vodka from the keyboard and craps on the machine, so the machine dies.

    Player B was the next computer in line to be a master server.
    Game pauses for 're-synch state"
    Players B,C and D connect to player B's silent server, player B's machine then announces all of player B's known information about all game pieces to all players, all players are now again in synch and reconnected to player B's computer.

    Game resumes, with pretty much everything as it was prior to player A passing out with his Vodka.

    If player A wants to get back into the game, the game has to look through a list of last known servers (aka B,C and D's IP's stored in a flat file for retrieval when the game loads, some temporary file)

    Player A's machine sees that Player B's server is active, checks a server state if it is the master, if so, then joins back into the game, where as Player B's machine tells player A everything that happened and it then rejoins and player A's server is in silent mode.

    Thats pretty much how all of the peer to peer games I have played work.
    All of the server running on them in a silent fashion and pretty much handle failover this way, because that is what you want, failover.
     
  5. marty

    marty

    Joined:
    Apr 27, 2005
    Posts:
    1,170
    Gotcha.

    So, it's pretty much what Jashan described but with the added preemptive element of having "silent server" running on every client and a queue of their IPs on each, ready for the hand-off, as needed.

    Man, I wonder if anyone who has done this is filled with an overwhelming desire to share a project file with the community?

    Or perhaps, maybe, one of the Unity Gods in Denmark or SF, USA are willing to give it a try?

    There's no way this wouldn't be a useful demo for us to have. ;-)