Hold empty room open to re-join?

Options
Ikik
edited October 2012 in Photon Server
I'm working on getting my game setup so that if both players disconnect, they can get back into the game within aprox a 5m window. If their game closes on the ipad, they get disconnected and if they're the last player in the game, the room gets removed. I have it partially working to get players back in, but it's not clean or working very well.

Has anyone on here done this before, and if so are there any examples?

Thanks

Comments

  • dreamora
    Options
    I doubt it as room based games normally are explicitely meant to cleanup after the last user left.

    My approach to the problem would be a database connection which replicates the persistent data of the session and has a timestamp. if either of them returns within the desired timeframe, then I would restore the session, otherwise I would inform them that they are too late basically and are going to start a new round.
  • Tobias
    Options
    Unless you want to change the server logic to support this, you will need to make the clients remember the state and replicate it in case they (both) return.
    To re-connect, simply try to join the game by name. If it doesn't exist, create it. In worst case, the other player created the game just after you tried to join and the create might fail, too. In that (rare) care, just join again.
    Once both players are in the room (new or old), one has to replicate the state and both need some event to go on playing. This is more or less up to you. Keep in mind that the Master Client might change when you leave and join games (or create new ones).
  • I modified the server to hold my spot and not close the game for a few minutes even if the last player leaves.
    I'm able to get back in and my gameobjects are re-instantiated, but the photonviewID is different so the RPCs all error out w/ an invalid viewID.

    The ViewIDs start around 1000-1050 when I get in the game the first time.
    When I re-join, all of the photonviews have id's between 1-50.

    Haven't been able to get these viewIDs to be correct yet, was hoping you may have some insight?

    Thanks!
  • dreamora
    Options
    you will need to modify how the viewids are generated and make them dependant on the users login information or something else thats persistent across connections
  • Tobias
    Options
    The origin of this problem is that view IDs are a "composed" number and include the ID of the player who sends the Instantiate / RPC event.
    Usually, the events sent previously should keep their originating player ID. But there's no idea of a returning player in the default Room implementation and everyone gets a new actorNumber on join.
    You could change this and implement the ability to re-claim an actor number on the server. Alternatively it should be possible to change the (purely) client side view ID system to something that fits your needs. But I didn't think this through...