Google Play Game Services createAutoMatchCriteria MIN_OPPONENTS > 1 - android

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?

Related

Google Directions API returns zero results for TRANSIT, although I am clearly asking for a metro route

This is the call that I make:
https://maps.googleapis.com/maps/api/directions/json?alternatives=true&key=my_key&origin=52.370060,4.925040&destination=52.37913,4.90027&departure_time=1518168706&mode=transit
I This route, which should have atleast 3 metro's and some buses in between them, should find me results.
This is what I send as the departure_time to get that value:
(System.currentTimeMillis() / 1000
And sometimes it works, sometimes no. I tried using the same + 30 (adding 30 seconds to current time) but, again, sometimes I get results, sometimes just ZERO_RESULTS. Why?
I noticed that if I set the time to 5 minutes in the past, it works. but I need it to start at this moment. This makes no sense, why would the call return me results for the past, but not future, for planning
I am afraid your questions is a bit broad since the understanding of how google works internally is a mistery for most mortals, but there is a few cases where you can have zero_results.
The first one is that you use times that are already in the pasts. so always make sure the epoch time you use has not already passed.
Another could be that in the moment you requested the directions, there are no posible routes for your desire destinations, since google collects data from other sources like Live Traffic(for driving), etc.
What I found is that if this issue persist (that you keep getting zero_results) for a specific directions could be actually a Bug of the API, and you can report it in the issue tracker https://issuetracker.google.com/ since I found reported/accepted Bugs (like https://issuetracker.google.com/issues/63884989) related with your issue.
If I found more info I will update this answer.

FireBase - Two devices should be triggered at the same time

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.

Google fit Recording API delay

So I'm writing a fitness application for android. I'm using the Google fit API to count the steps.
I'm using the Recording API to count the steps when the app is in the background. Once the app is in the foreground I'm fetching the steps count with the History API to show it on the screen.
What happens is that the count is not correct. There is a delay until you get the correct and updated count.
To be more specific no data is being lost. I guess that the Recording API is updating with a specific time interval.
I'm also using the Sensors API to show the real count on my Activity when it is running. So what happens is that for example you see 300 steps in your screen (real time data). Close the app, open it again and then for the next minute you see 250 steps for example. And only after some time the History API catches the correct data and shows 300 again.
Has anyone found a way through this issue?
Thank you and sorry for the long text!
Your are right. Recording API takes some time for update. There is two way that came to my mind.
always get steps by History API. I mean when activity is running just increase the checking rate of History API. Advantage of this is though it is taking some time, user always the same count.
another way is bit more complex. store your Sensors Step count with time & apply some logic whether or not you need to add & show this to user.
Sorry for the long text.

Connectivity issues after the recent Google Play Services update

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.

Room Configuration did not work properly in google real time multiplayer services for android

i am trying to build a real time multi-player game and now i am exploring sample game provided by google for multi-player. Link is ...
https://github.com/playgameservices/android-samples/tree/master/ButtonClicker
issue is that when i change auto-match criteria configuration as per my requirement
void startQuickGame() {
final int MIN_OPPONENTS = 1, MAX_OPPONENTS = 3;
Bundle autoMatchCriteria = RoomConfig.createAutoMatchCriteria(MIN_OPPONENTS,
MAX_OPPONENTS, 0);
RoomConfig.Builder rtmConfigBuilder = RoomConfig.builder(this);
rtmConfigBuilder.setMessageReceivedListener(this);
rtmConfigBuilder.setAutoMatchCriteria(autoMatchCriteria);
rtmConfigBuilder.setRoomStatusUpdateListener(this);
getGamesClient().createRoom(rtmConfigBuilder.build());
}
then this code not wait for 3rd or 4rh player in room (as i set in MAX_OPPONENTS ) and game starts immediately with 2 player(1 opponent). i want to add timer here and game starts after that specified time.
and surprisingly after room creation MIN_PLAYER value dose'nt work at all in this code that is for default room UI.
final int MIN_PLAYERS = 2;
Intent i = getGamesClient().getRealTimeWaitingRoomIntent(room, MIN_PLAYERS);
// show waiting room UI
startActivityForResult(i, RC_WAITING_ROOM);
my requirement is that after room creation i want to wait for a specific time and then game starts with joined player. no matter they are 2 , 3 or 4.
The automatching algorithm doesn't try very hard to maximize the number of players in the match -- if you set min to 1 and max to 3, getting a 2 player game is possible.
What you should do in this case is set MIN_OPPONENTS and MAX_OPPONENTS to 3, and handle the game start logic from your code.
If you want to implement this timer logic, you can't use our built-in waiting room UI, because it doesn't support starting a game early based on time. So, instead, implement your own waiting room with this logic:
Start your timer.
Show the progress on screen as you see peers being connected or disconnected via onPeerConnected() and onPeerDisconnected(), and other callbacks. See RoomStatusListener and RoomStatusUpdateListener.
When the timer expires, decide what you're going to do. For example, if there are 2+ players connected, start the game. If not, wait longer, give up, etc.
Handle the case when someone joins the game late. This will happen if 2 players joined, the timer expired, the game started and then a 3rd or 4th player shows up. Make sure the experience is not terrible for them (don't just kick them out) :-) If you can't integrate them into the ongoing game, you could have them stay in "spectator mode" and join in the next round/match/etc.
Important: remember that the timers for different players won't be in sync in the logic above -- so you should send a real time reliable message to all peers when you decide to start the game, to let them know that the game is starting and that they should move to the game screen.
If the logic gets more complicated, it might make sense to elect a "server". You can do that, for example, by saying that the client with the lowest Participant ID (lexicographically) is the server. Saying "whoever created the game is the server" is no good, because when automatching, everyone thinks they created the game.
I hope this helped!
Just came across this excerpt from here that might be interesting to others regarding your issue:
The second parameter in getRealTimeWaitingRoomIntent() indicates the
number of players that must be connected in the room before the Start
playing option is displayed. In the example, we specify MAX_VALUE
which indicates that the Start playing option is never displayed.
Instead, the waiting room UI automatically exits when all players are
connected.
So if you don`t set a MAX_VALUE when using the built-in waiting room intent, you can leave up to the player if he will start the game with the minimum players, or wait for more people to join.

Categories

Resources