Sign In Register

How can we help you today?

Start a new topic

Player disconnected - configuring timeout period - what is minimum / frequency at which this is checked.

In the game I am working on, both players in a challenge need to be online for the full duration of the game (read: a started challenge). If a player stops communicating (ie, their internet goes down) I need to end the challenge within a reasonable period of time, considering that the other player is sitting there waiting. What is the prefered method for doing this? I looked into the player disconnected system event - but it seems to occur more like 5 minutes after you close the game - ideas?

2 people have this question

From what I have experienced, it's not possible to rely on the player disconnected system event. It's triggered sometimes immediately, sometimes very late (30mn), I didn"t succeed to handle it properly. 

Good luck, and tell us if you understand its behavior...

I was wondering the same. Did you come up with  a solution ?

Hi All, 

Essentially this comes down to the manner in which the disconnect occurs. A player that closes the App, or does a manual disconnect will cleanly close the socket. This will result in the System Player Disconnected script being called. 

In the event that a player loses connectivity the socket will not be closed cleanly. This means the Player Disconnect script will be triggered anywhere between 5 and 30 mins afterwards depending at which point it happens vs when the scheduled socket close will take place. 

In the turn event of your players cloud code, you can send a message to the other player. In the client, listen for this message and return a message or event. Thus indicating the player is still connected.

This is one of many potential workarounds.

Best Regards, Patrick. 

1 person likes this

@Mohamad Hindi

1. In cloud code, I hook into the player disconnected system event to get all challenges the player is participating in and leave/withdraw/surrender (depending on the state the challenge is in and if the player is the challenger or not, it isn't the same request).

2. In client code, when the app is closing I send the server the disconnect/shutdown/terminatesession.

3. When I reach a point in the gameplay where one player is waiting on the other to take an action (because my game is not strictly alternating turn-based) - the player who is waiting sends a custom challenge event to the server. When the server receives this message, I have cloud code which uses the scheduler to start a timeout of ~15 seconds. If the timeout expires the call it makes is to disconnect the player being waited on, hence hooking into the same scripts for removing the player from a challenge do to disconnection.

I suspect that there are going to be other aspects of my game, outside of gameplay, that will also need to know if some other given player is online or not - with a higher degree of fidelity than 30 min... so, this solution might need to become more general purpose than it currently is.

1 person likes this


Thank you for your reply. May you clarify more about these points:

1- What do you mean by manual disconnect? 

2- What are other potential workarounds?


Thanks, that looks like the solution ill be applying.

Btw what happens if user gets a call or moved from one app to another? I want to disconnect the user, whats the solution here?

Hello again,

I guess your game style is similar to i have a card game and both players must be online at same time.

I managed to communicate between players using scriptmessages.

My question is, how did you handle the case where one of the users either put the app in the phone background or received a call? Like this player should be considered as disconnected and the other should win the match. Did  you think of such scenario?

Thanks in advance

Actually your game sounds remarkably similar to my own '-) 

But, while we have plans to support iphone at some point, initially my focus is on ipad. I don't actually know anything about the behavior of gamesparks running on an iphone. 

The pertinent questions to ask yourself and/or research would probably be:

  • When the app is suspended does it immediately inform the gamesparks service and trigger the "Player Disconnected" cloud script? 
  • Is taking a call actually a "suspend" or does it continue executing game code? 
  • Does closing an app that is already in a suspended state execute any game code or does it just close it without a chance to 'shutdown' gamesparks? 
  • Can you intercept 'suspend' commands and show an OS dialog like "are you sure you want to suspend [game], you will surrender from the current challenge?"

Not knowing the answer to these questions (and not actually even asking them at this point, since i'm targeting ipad), I would nevertheless think the desired user experience would be...

  • Allow a user to take a call while playing, and continue to play the game at the same time. If they aren't using speaker-phone or a headset they won't actually physically be able to play at the same time, but so long as the game code is still being executed by the OS you can have the time-out occur client side and send in an empty move to the gamesparks service (this timeout just has to be shorter than the 'auto disconnect' timeout that occurs server-side).
  • Do you support resuming a game in progress if the app crashes, or the close and restart it? I would treat app suspension as the same thing as closing and restarting the app. For me, that is not something I support, at least not in the middle of playing another real-life-personal live.


Thank you for the insight! Im using unity actually and exporting to both iOS and android mobiles.

I need to check and test what happens in each case as you said. That looks a bit complicated but feasible :)

Btw since we are coding the same game style, how did you manage to synchronize messages being sent from Device A to device B ? 

I mean maybe Device A sent two messages withing 0.5 sec but at device B, it received the second then the first. In my code, device B listen to any message and do something accordingly.

What I thought is that you can add an index to each message, and at the receiver, it first stores the message in a list and device B first check if index is right, if not it waits till it received the right message.

Did you do something similar?

I guess I have not encountered this problem yet. The actions a player takes in my game do not occur so close together. 

Your proposed solution sounds fine to me. The only other idea I have... have the sender wait for a response or message back from the server or remote client indicating the first message was received before sending the next message... but your idea seems better.

Hey, hows ur game going so far? :)

Login to post a comment