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.)
Related
Background
The company I work for is creating an app that collects information from various device events and sensor data.
One of the things we would like to be able to do is use time to process the data when it gets to the server.
We would also like there to be an acceptable amount of "offline time" allowed, i.e., the app could be used for its purpose even while offline until the next server data update is required etc.
Problem
One issue is that the user can just change the device time.
We overlooked this, and have been able to successfully generate events for the previous day, which would mean that our app could be fooled in situations where device time is a factor, which is very uncomfortable.
Imagined solutions
Obviously I can ensure that the app is always sync'd to the server before it starts collecting important data, and then use server time and make all further time relative to that.
Another way might be to keep a reference to something like the last update time or even the app install time and work out time relative to that.
Questions
How do people get around this typically?
Are there any libraries out there that can be used to enforce real device time?
Thanks guys
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 got the idea of an app that could show you, after a telephone call, what percentage of the time you were speaking and what percentage of the time you're conversation partner was talking.
For this I had two conceptual approaches, and I was wondering which of the two was most suitable for this application.
Voice recognition - During/after the call the app analyses the audio. Based on the amount of your voice present in the conversation it calculates a percentage
Data recognition - I assume that when you talk the phone uploads more data then when you're silent. Based on the amount of kbps the talking distribution can be determined
You couldn't get access to the phone conversation data itself, but you can get the up/download statistics. There are a few apps available that track 3g data by other apps (most phonecalls now a day use 3g). You could start tracking this when a phone call comes in, filter the other app datatraffic out, and then end when the phone call ends. This way you can know the amount of traffic being send in & out. You would have to do some basic testing beforehand, as there will lot's of overhead data being transmitted besides the voices themself. You could do some testing to see if there is a correlation (and by what extend) between the amount of talking and data traffic (there should be).
I am a complete Android programming newbie.
I have completed some tutorial examples like HelloAndroid and the HelloViews/Layouts, but that is about the extent of my Android programming abilities.
I am not the programmer on this project, I am the tester(QA) for a company that is developing an Android application that will track company owned devices every 1 minute, and send the positions back once 5 or so are stored.(Limiting mobile network usage, to conserve battery.) My company bought and pays for the android devices, and the employees are aware they are being tracked, both for safety purposes of the employees as well as accountability. Behind making phone calls and some mild emailing, this is one of the most important functions/uses of our devices.
Our biggest problem is that our application can be killed at any time by the Android OS, for any number of reasons(device resources, etc.) Right now, we have an Android service that checks if our app is running every so often and if not, it starts it back up. Once our app is running it can be in the background and request positions using a service in the app itself, then send them to our server for processing and storage.
From everything I have read about Android Development practices, this does not seem to be the most Android "appropriate" way to do this. From what I can gather, and this is fairly limited, we should have an Android service that runs in the background and requests then sends positions, but even this can be killed without notice from the OS, right?
Any advice or suggestions anyone could provide that would point me in the right direction?
It might be worth mentioning that this will kill everyones battery extremely fast... but you pretty much have it right as far as the best way to do it. If the OS does kill your app in the background, your service can just restart it.
What are your concerns, that the OS will repeatedly kill it and not allow it to do its job?
Or that the GPS locations wont be accurate? Location.getAccuracy() could help you figure out if the location is worth saving
http://developer.android.com/reference/android/location/Location.html