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 :)
Related
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!
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.
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 have an application that sends data to a server with a post request. This request can fail, and if it does I want it to retry until it's finally sent, something similar to WhatsApp: if u send a message when u are offline it stays as pendant and when you go online again the message is sent.
Since I don't know how WhatsApp internally works I have some doubts in how to implement that. I thought two ways:
1- Setting an AbstractThreadedSyncAdapter to be executed every X time (like 30 seconds) that checks if there is data to send and, if there is, it sends it to the server.
2- When the user clicks to send some data, I create a thread that tries to send it and, if it fails, it sleeps some seconds and try again.
I really don't like any of these options. The first one is going to increase the battery usage since the application is going to perform operations every X seconds even if it isn't needed. The second one is going to use a lot of battery if the request fails a lot of times.
Is there any better way to do it? It'd be awesome if there was an easy way to detect if the phone has connection to internet.
Thanks!
In your scenario 2, you can set an alarm when the initial post fails to trigger a re-sent some time later. If the send succeeds, you cancel the alarm (or don't schedule another one).
For getting noticed when the device goes online you may look at this answer: https://stackoverflow.com/a/11084311/100957
I have an android app that I'm building and it's based on a web app that lets users login and reserve a book (think library). Because you are able to reserve books it needs to have a valid session (cookie to be exact)
Here is my issue - how can I work with multitasking when I have this 20 minute constraint?
Do I keep a timer running the entire time the app is up (in the Application global object) -then on resume verify this timer is under the 20 min window and if so assume cookie is good - else ask them to login again.
Or do I blow away the activities loaded (in my app) on resume and start the app over each time the user clicks the icon from the home screen
Or something else? I simply avoided this in my iPhone version because I don't support multitasking currently (maybe I will if the android solution fits)
Thank you in advance!
Normally people handle this problem by assuming any cookie they have is valid and letting the server tell them if they need to login again. The client should have very little (read: none, if possible) intelligence about this aspect which they cannot control.
You have several options, and which one's the best will depend on the app specifics
You can set up a timer to log out after 20 mins, either as part of your Application or as a part of your Activity (although in the latter approach, it will be lost if the activity is restarted).
Can set an Alarm to fire an Intent to show the login screen after 20 min (if you want to force a re-log in) or to set a flag LOGGED_IN=false if not.
You can set a long field in your Application object and query it during onDraw(), or while fetching a new page, or whenever you deem fit: if it's past the 20 min point, logout.
If the app will be fetching the book from a server one page at a time or similar, then I would add a time token to the POST request and let the server decide whether to return the page or to send a 401 error. You would then handle the error by showing the log in screen and reposting if log in is successful