I'm currently developing a multiplayer card game (4 players) using Unity, and I'm using GPGS for multiplayer purpose.
One thing that I can't figure out is connection problem handling. For now I deployed a system that every five second each player send a message to other players telling them i'm online. If a player doesn't send any messages for 10 seconds, I'll consider him/her having connection issues.
My first question is: Is this the right way? I couldn't find anything other than OnPeerDisconnected in GPGS documentation, and I assume it's not related to this.
My second question is: Sometimes while playing the game, one or some of user(s)' gets timed out. In other words, they don't get any message and can't receive any. All my 4 devices are connected to the same network, and network quality is good. How's possible that one of four players encounter network problem?
My last question: I don't know when GPGS consider a player to be timed out? For testing purposes, one time before using the method I explained above, I disconnected one of players, and waited for 5 minutes. Nothing happened. Also I don't know if the user can come back to game (resume playing) after a long time (20-30 seconds) or not?
Thanks for your help. Sorry if anything is ambiguous.
Related
In a currently live game a few of the players get an error 6000 when trying to start a multiplayer game via auto-matching or inviting players.
The problem is that error 6000 is not documented anywhere I can see. Does someone know?
To repeat, for most players there are no problems with multiplayer. Only a small subset are affected. But once an account starts getting error 6000, they can't start games anymore at all. They can receive invitation still however.
In case anyone stumbles upon this later, error 6000 means
The user is not allowed to create a new multiplayer game at this time.
This could occur if the user has too many outstanding invitations
already.
It if from this reference page, which for some reason doesn't rank very high when Googling :-)
I have been looking into this for a while, and while there are threads on here that answer the question to an extent, I have not found something suitable to what I want to do.
I want to able to monitor that two devices are near one another multiple times within a 10 minute span. Nearby Messages has a detection distance setting that works perfectly for this, the setting is called DISTANCE_TYPE_EARSHOT.
The problem is that once a connection has been established between two devices, all subsequent communication occurs via the internet, for a period of 10 minutes.
Is there any way to cancel this link? This thread does mention that one could manually clear data on "Google Play Services" to un-pair devices. Is there any way to do this programmatically?
Alternatively, is there an API that would be able to do what I need?
For the last couple of days i'm stuck with what i call, overthinking :
FireBase is dedicated to be a "Real Time" communication platform. I'm trying to understand what is the right approach for the follow up situation.
In my PVP game, two users suppose to start the game at the same time. I'm already making a "pre check" to make this two events as close as possible(promote both of the users to click a button, observe specific value change, and only than start).
Yet, both of them starting with a small delay of 1-2 sec.
Even tho FireBase suppose to act as a "Real Time" platform, should i assume(/code) within this perspective? Or should i assume Delay is going to be a common issue?
2. Is there an avg delay/time, assuming FireBase works as he should and my code is efficient, for each listenValue "call"?
UPDATE
NOTE* Each user "listen" to the other device "ready" state, so when the "last" device click ready, the game will automatically start
Since as there is a small delay between player sync. Which I think I because when you attach your second player to the game it triggers must be starting the game as soon as second player is registered. I think you need a small delay between adding your second player to the game and starting the game. Posting some code might help a little more to understand the exact problem.
We have 3 games with real-time multiplayer based on Google Play Services. All 3 started to have problems since last Saturday (May 17), may be 1 day earlier. Right now players have problems with both connecting and playing 4-players games.
The situations we have seen:
As soon as 4 players are connected, 1 of them gets a message about Play Services crashed. It leaves the other 3 waiting for him, because they do not have any callbacks, for example about P2P disconnection.
Sometimes 3 players see that 4 players were auto-matched, but the 4th does not get any callbacks at all. So, 3 of them are trying to connect in vain.
Very often at least 1 player loses connection during the game. Being able to complete a 30-minutes game without losing P2P connections is a rarity now.
While we made minor updates in 2 games, 1 game was not updated since April 24, so it seems to be caused by the recent services update.
We have posted a bug to known issues database, but no response so far. And we get 100+ emails/day from unhappy players. Are we the only ones affected?
Judging by increasing amount of developers, who have starred that bug, the issue affects everyone, not only some game ids.
A known workaround is to reconnect GoogleApiClient after disconnecting from the room.
I am learning game developement and was thinking of creating a real time 2 player game for android. It needs to have simultanious game play of tow players on two android devices , the one like this: Gurrilla bob
Now I want to know is there some tutorial over what should be shared in real time between the two devices for the games running on each of them to be in sync ? I do not want to know the network implementation.
Is it that
The game runs on one main device and the screen is shared on the other device and it just reports input events to the main game.?
The two devices share Physical world details(position of bodies , forces on them , their positions) or something similar(I am just guessing)?
Or is it something totally different ?
The range of "data we share" really depends on the level of security you desire. In a massively multiplayer online game (Which is a bit different because it has a server between the players), the data shared could range between the following, from the most secure:
The user input itself. The client sends the server what the user does - he tapped the screen to shoot, he swiped the screen to move, etc... The server processes the input and decides whether to respond to it (If it's legal input) or not (If it has been modified, I.E hacks and cheats). This gives a lot of work to the server - All processing is done on it, and it has to report to all its client what happens and when. However, it blocks pretty much most if not all hacking/malicious input options, making your game very secure.
To the most insecure
The user input consequences: The client itself processes the input, and reports to the server what the input caused, its consequences. For example, if the user tapped the screen to shoot, the client calculates the bullet direction and sends to the server "I shot a bullet at this time and that direction". This allows clients to send misinformation - A client could send "I shot 100 bullets", which means you'll have to add many checks on the server, to make sure players don't cheat
Now, since you are neither talking about a MMO, nor about a game whose security is important (After all, it runs on an Android and few are those who know how to hack applications, and you weren't about to publish it anyway), I feel kinda stupid for writing that much when it's not necessary, but I hope you got some of it.
Back to your problem - When talking about 2-player game, especially on a phone, real-time and network efficiency are the most important factors. So we can wipe off the option of "Sharing screens" as streaming videos is not that fast or network efficient.
I think the best solution will be that both devices respond to input and send the consequences to each other. This way, users won't experience latency, or just very little. You'll have to handle special cases that latency may cause (For example, when talking about shooting games - If player A shot and killed player B, but player B lagged and took 5 seconds to receive that consequence, and meanwhile before his death he shot and killed player A, player A shouldn't die.)