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.
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'm fiddling with the GPGS Android API for the first time and am having some problems getting auto match to work as I'd expect. I've been using the ButtonClicker sample, which seems to work great as is - when choosing a "Quick game" the waiting room appears and I can connect two players and all of the callbacks are firing as expected.
If I make one change so that createAutoMatchCriteria is called with min_opponents = 2, max_opponents = 2 instead of 1, the waiting room launches and shows placeholders for 2 opponents, however I cannot get any players to connect - onPeerJoined is never called and the two devices just continue to wait as if neither knows the other is available.
Is there something more that needs to happen to enable a 3 player game? I'm not sure this sample would support actual game play of more than 2 players, but it seems the waiting room piece should attempt to build a room with 3 participants. Anybody know what I'm doing wrong?
Thanks!
Apparently this is a known issue:
https://github.com/playgameservices/android-basic-samples/issues/9
The callbacks fire when the minimum is met, but not one at a time as players are being added.
As a workaround, I tried I saving the Room object that is returned in onRoomCreated and polling to see if the participants in that room change as players are added, but it does not update. Anybody know a way to work around this issue and figure out when players are added one at a time?
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.
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?
Google Analytics (using iOS SDK version 3.14 and it's built in sessions tracking) is reporting a significant percentage of app sessions as 1 second.
Maybe users are launching an app to view a page and (effectively) then instantly leaving the app, but that seems unlikely (that it should continue as the top use case. You think such users would stop using or uninstall.)
Initially I suspected this was related to "background fetch" but when I look at a prior incarnation of the application (that did not have background fetch enabled or used) I still see these (seemingly) bogus sessions also. That application (pre iOS9) had no universal links.
The (obvious) reason I don't want to see these sessions (especially if from automated action not user action) is it removes all value of "user behavior"; i.e. loyalty, recency and skews "average session length". These are the main reasons I want to use GA, i.e. to see if folks are using it more/valuing it more.
My questions:
What might these sessions be caused by? Are they bogus?
If bogus, how can I stop them?
Can I ensure new "background fetch" code doesn't somehow trigger them?
Some things I've considered / looked into:
I am seeing a similarly large set of "short sessions" on an Android application (this application's peer) and again with extremely high numbers. I've been wondering if this was a result of a web searches & site links, with those site links automatically loading the app, and the a (very) quick user "move on". (Universal linking is something the new iOS application is working towards, but doesn't see much of yet.) Given it is not that on iOS I am starting to doubt that it is that on Android.
There is a "optOut" option on GA. That feels like a sledgehammer solution to this walnut problem. It is also a persistent setting, which feels risky to use for a transient situation. I could attempt to toggle it at applicationDidEnterBackground / applicationDidBecomeActive (and will if it is deemed the solution) but worry it could have negative side-effects.
One can have multiple trackers. I am planning to attempt one for human foreground activity and one for background operations (which might allow time /event tracking when in background, w/o impacting human user tracking numbers. That said, I don't know / believe this is the cause of the bogus sessions. )
One can manage sessions manually and also customize the sessions interval timeout, but I don't see why this application should need any custom behavior. It is a normal application.
The application isn't reporting crash totals to match these numbers; it is a generally well liked 4/5 star app w/ few crashes.
Google Analytics measures duration as the time between interactions.
This means that in order to be able to measure duration, Google Analytics needs a minimum of two interactions to measure between. But they still need to collect data on one-interaction Sessions, and from the reporting perspective, every session starts the same - with an interaction. It's just that some don't go any further. To account for this, Google Analytics keeps a running total of Session duration.
When a user first interacts, that total is set to 0.
31 seconds later, they interact again. That total is updated to 31 seconds.
10 seconds later, they interact a third time. Total is now 41 seconds.
35 seconds later, they quit. This is not measurable, and hence not an interaction. Google Analytics waits faithfully for 30 minutes, before deciding that they aren't coming back.
Your total Session Duration is recorded as 41 seconds, as that was the last point at which you checked in. There's no way of knowing that you stuck around an extra 35 seconds.
This isn't an issue if you looked at 4 or 5 pages, but if you had only looked at 1 page, we would have been left with a Session Duration of 0. This is what happens with every 'Bounce'; every Session with only one interaction is measured '0' seconds long.
Throw into that a handful of people who interacted 8 or 9 seconds later, and you have an average of 1 second for the '0 - 10' category.
Turns out the problem was inside the Google Analytics SDK. A new version has been posted:
[Google Analytics SDK issue with short sessions][1]