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.
Related
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 am working on a real time multi player using Play services. Just wanted to know how u guys handling below situations. And all only while real time match going on..
What if the user get a phone call
What if the user changes network
What if the user suspends the game/opens some other app and comes back after some time
Does the user still gets real time messages if the game inactive.. i mean the game runs in back ground
And are there any other complected situation that u gone through
Thanks....
What if the user get a phone call
The strategy in handling this scenario is to pause the game and then stores the state of the game using the bundle provided by the onSaveInstanceState(Bundle bundle) since we do not know if the OS will decide to kill the game in the background. So the moment your user(s) go back to the game; the previous data is restored and ready for continuation.
What if the user changes network
If the game doesn't require to use the Network then no need to worry on this aspect. But if ever you need to synchronize the data to the server while the connection is interrupted, Cache the data in your SQLite DB and when the network comes back thats the time you will upload that cache data.
What if the user suspends the game/opens some other app and comes back
after some time
The approach here is just similar above upon receiving phone calls.
Does the user still gets real time messages if the game inactive.. i
mean the game runs in back ground
Yes, you just answered your own question there.
And are there any other complected situation that u gone through
The most challenging thing in developing games is optimization. Basically how will you create a game that doesn't crush that much? A typical/medium intense game is memory hungry. How will you manage to reach 60 FPS without sacrificing flashy feature? Do you need security in your game like login information? Is it multiplayer or single player?
Another thing you need to consider is that Not all user speaks English. Does you game supports multiple language?
Those above guide questions can help you in your decision making!
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.)
I am working with one game which is basically a location based game. The duration of game is 5 mins. Everything is working fine. But the problem is on one device game is starting before the game is started on the other device.
Suppose User A has sent request, user b has accepted the request. then only game screen should appear. But in my case its not happening.
Can anybody help me to give me the logic to start the game between two devices at the same time without a second delay. I am using web service for sending the game requests.
Thanks
Just a thought:
You might use some sort of Mutex on the server side that tries to determine if both clients are ready.
This is assuming the game is run on a server as you described, and not peer to peer.
Hope this helps!
Maybe user B starts when the he accepts but user A hasn't actually received the response yet...or something in that scenario.
How about when user B accepts, take the time (server time to ensure same time) and start around X (10 or 15) seconds after? then send that time (time, not duration) to user A as well. In this case, both user A and user B will just be waiting for the appointed time and then start at the same time? Just an idea, implementation is all up to you :)
Hello
In my android application i would like to get Time since when the app is opened.
Initially what i tried was getting the time when the app is loaded from the server and then taking the difference with the current time from the device.But by doing that if the user changes the time then i willnot be getting the actual time.
Its not posiible to hit the server again for the same.
Is there any way to achieve this in android?
Please share your valuable suggestions.
Thanks in advance:)
Try the "SystemClock" class, "uptimeMillis()" method.
Store the result in a variable when the app starts.
Echoing what I said for your other question, you first need to become familiar with the activity lifecycle and understand the novel meanings (almost meaninglessness) of common words like "open" and "start" in the life of an android app.
There isn't any way you can prevent the user from changing the system time - you just don't have the right to do that to users. Normally this should be a rare event, unless you do something that makes them want to, such as lock them out of a free version of your app after so many minutes. (However if the phone is on a mobile network, presumably the mobile network occasionally adjusts its time to correct for errors in the device's oscillator, or administrative time changes)
What you can do is check the system time on every entry point to your application. If it ever goes backwards, well... something is going on. If the clock has been set back, you could assume no time between the calls with the negative time difference and resume your time meter from there, at least keeping all the previous used time in your record.
It may be that there are cpu cycle counters which you could query and correlate to system time, but this may be highly device specific and may in fact be resettable. And it may get weird if the cpu frequency is demand throttled.
You might be able to set a countdown timer as a bound on the maximum possible time between entry points at which you could meter. I don't know if these work reliably across system time changes or not - ideally they would. Testing or reading the source will reveal.
Use elapsedRealtime in your onCreate() store it. More reliable.