I am working on a casual game with some improvement over time, much like TinyTower.
But the biggest flaw in TinyTower (and all respect, its a cute game) is that cheating is too easy. The game relies on the device time, so when it says that "this is done in eight hours" you just set your clock eight hours ahead, get the thing, and then turn it back.
Now, I need to make sure that this isnt a way people can win in my game. I had one idea that i could crossreference the system time with the server time, but I can't rely on the connection being open, since offline play is an option.
I could also set up a sensor indicating if the OS time suddently was before last-played-time, you would earn an invisible cheat-suspicion counter. Three of these, and the game would reset, and mark you as a cheater.
The final option was to simply not care, let cheaters be cheaters. But if I am to have a competative element, with hoghscores and such, i really need this to work.
So... The question is this:
Does anyone know a safe reliable way of detecting how much time has passed since last time a user last had the app open?
A few ideas:
1) Have the app always keep track of current-time vs. last-closed-time. When you see it go backwards, increment a counter in all current saved games, and reject high scores from games where this counter has a sufficiently high value.
2) When submitting high scores, submit the device's current time. If that's sufficiently ahead of the server time, reject the high score.
3) When starting a game, check the time against the time at which the current version of the game was released. If the user is supposedly starting a game before the game was released, complain.
The app delegate is notified of significant time changes. You can catch these calls to applicationSignificantTimeChange: and watch for significant forward or backward time jumps.
Of course, that only catches changes that take place while the app is running. You can also save the time last run in the NSUserDefaults and check it next time you start up for significant backwards time jumps.
About all those solutions, what if the user goes to another country and the timezone changes and goes into the past or future?
Related
There are two decisions to make timers, with "update:" and with actions.
But i need a timer that could continue even if the player close the game.
So when player comes back to game after a certain time, his progress could be saved. Could i use CFAbsoluteTime to make this?
You should look at the Date/Time instead of in-app timers for this purpose.
Essentially, you need to track the time passed between launches of the app. You can do this via storing the Date in the user defaults when the app is closed, and comparing it to the current Date when the app is openened the next time to figure out how much time has passed.
You may want to look at using an external clock, like grabbing the time from a website, this will prevent people from simply changing there clocks to alter time. (This will not however prevent people from altering the DNS to go to there own web servers, but will most people go through that trouble for a simple game)
I want to run a specific task in the background. This task takes few seconds to complete (it writes some GPS location data to a file). This task should run once every 1 hour.
As I understand from the SDK, I do not have a way to INITIATE something in the background unless I run Location Services forever. When this service runs, it gives me an event from time to time, and I'm able to run my code during these calls. I tried it, and even with the minimal precision possible, my battery goes down very quickly.
So, I'm looking for a way to run Location Services for few seconds every hour. All the rest of the time I do NOT want to run Location Services and I do NOT want to use the battery.
Can you help here please?
Thanks,
Gena
What do you actually want to know every hour? Are you trying to determine the location accurately, or just determine if the phone has moved significantly? startMonitoringSignificantLocationChanges will notify you when the phone moves "significantly" (which generally means changing cell towers). In cities this can happen quite often. startMonitoringForRegion:desiredAccuracy: will only notify you when you move outside of a given radius.
startMonitoringSignificantLocationChanges is pretty cheap. It mostly relies on the cell antenna, which is generally on anyway. If it fires more than once an hour, you could always just skip processing and return. But there's no guarantee that you'll be called once an hour, particularly in rural areas.
If you are a VoIP app, then you may register a periodic "checkin" interval when you may run code. But you cannot do this for location apps.
Have you profiled your code using the Energy Diagnostics instrument? What's actually eating time and power? Are you chewing on the radio, the CPU, the disk?
EDIT
When the app dies, Significant Changes still continue to run and leave a small direction arrow icon next to the percentage on the top toolbar of the iPhone. My users complain that the icons remains after killing the app
After the app dies, if you were registered for significant changes, you would expect to be relaunched in response to them. If you want to unregister in cases where you are terminated, you can add stopMonitoring... to your applicationWillTerminate: method. This isn't guaranteed to be called, but it is a good thing to do, and I believe it will be called if the user terminates you directly and you were not suspended (haven't tested that).
Again, significant location changes should be extremely cheap in terms of battery life as long as there is cell coverage. They should not force the GPS to stay on.
Your best bet is to use significant location changes ... here are some links you can get help from -
http://developer.apple.com/library/ios/#documentation/CoreLocation/Reference/CLLocationManager_Class/CLLocationManager/CLLocationManager.html
http://www.switchonthecode.com/tutorials/getting-your-location-in-an-iphone-application
http://longweekendmobile.com/2010/07/22/iphone-background-gps-accurate-to-500-meters-not-enough-for-foot-traffic/#more-480
A common exploit in casual games is to artificially advance the system clock to jump ahead in gameplay. How can such user clock advancement be detected by an app on an iOS device?
Must not involve network communication
Must not assume app is open (running or suspended) while clock is advanced
Must detect clock advancement, detecting clock rollback is not sufficient
Ideally, the solution would be robust against reboots, but that is not a requirement.
CACurrentMediaTime & mach_absolute_time
Take a look at this questions:
iOS: How to measure passed time, independent of clock and time zone changes?
Calculating number of seconds between two points in time, in Cocoa, even when system clock has changed mid-way
CACurrentMediaTime uses mach_absolute_time:
http://developer.apple.com/library/mac/#documentation/Cocoa/Reference/CoreAnimation_functions/Reference/reference.html
Here you have an example on how to use CACurrentMediaTime:
http://www.informit.com/blogs/blog.aspx?b=02b4e309-308c-468a-bab1-cebb1404be6a
Here you have a more information on mach_absolute_time:
http://developer.apple.com/library/mac/#qa/qa1398/_index.html
http://shiftedbits.org/2008/10/01/mach_absolute_time-on-the-iphone/
I was thinking about the fact that the CoreLocation stuff could do this if that part of the GPS data was exposed to you. However that got me thinking.
My only (far fetched) suggestion is to put something into background processing - which has to be for one of a small specific set of reasons, for example to track location in the background. As a side effect of that, try to detect a clock change on a regular timer. Apple might reject it as it may be clear that its not using the location information and its just a reason to exploit background processing.
Any solution not involving networking is so much harder to implement, I wonder why you're not using it.
Whilst I don't think it's possible to reliably determine whether or not a user has manually turned their clock forward without network access, you can of course reliably determine if they've travelled back in time. And since we know this to be physically impossible it can therefore be assumed they have manipulated their clock to cheat.
What I mean by this is, isn't the usual process to trigger some action in-app that requires a period of waiting, exit the app and turn the clock forward, re-launch the app to gain whatever they were waiting for and then reset the clock back to the actual time?
If this is indeed the case, then to build on the suggestion by #smgambel, you could store the physical time and current time-zone on each launch and compare with the previously stored time and time-zone. If the time is behind the previously stored time, and the time-zone of the device hasn't changed then you can safely assume the user has manipulated the clock.
Allow me to describe my situation:
I want to develop a game, that is round-base, and pay-to-play. That means you pay one coin, for one round of game, like Pinball etc.
The problem is, when there is interruption, ideally the game should pause, and resume whenever the user desires. Implementing that seems to be a challenge. Say my game was put into background, I would save the game state in ApplicationDidEnterBackground. However the game may or may not get terminated while in the background. So the next launch could be a "fresh start" , or, a "resume from last saved state".
If the app is left in the background long enough, say 1 week, its almost certain that other apps fighting for memory will cause the game to be terminated at some point. When the user starts my app again, they would be playing from a new round, meaning that the previously unfinished game, is gone.
From a customer point of view, this is unfair.
What I can think of is, to implement it so that whenever my app is brought to the foreground, I would go check if there was a saved game. If there was, I shall resume it instead. This poses a security issue:
Saved game, either in most primitive plist format or other formats, are persisted, and poses security problems. (What if players edit the game state and score 10 million points as top score... etc)
Are there any recommended ways to tackle these problems?
I see some Apps simply give up on saving the game, and a new round will be started on resume. Those are not paid to play games, otherwise I can imagine users getting very angry.
I have seen some Apps that saves the game state for a while, but when it got terminated, when next launched, it will start a fresh round. Which seems just as unacceptable in the case where players actually paid money for the round.
And when taken into account the possibility of crashes, I cannot come up with a good solution that ensure paying customer will get to play a full round of game. It would really help me if someone with relevant experience could share their thoughts, and how they make their decisions.
Why not tie the round finishing to the payment? If the round doesn't finish, no payment is taken. If the user's credits are insufficient at the time the round finishes, you could give them the option to purchase more credits immediately (via in-app purchase) to finish the current round.
That simplifies your task as a developer, and also provides a way to prompt the user for additional payment in a non-obnoxious way.
Here's a great tutorial on using NSCoding to save game states. It won't have any problem with the player going in a editing the file, as it is done in NSCoding. If a user REALLY wants to figure out how to un-encode the file and change the contents, which is crazy, you could do some kind of encryption on the data BEFORE you write it to file, so there would be no way the user could change it. Hope that helps!
we are creating a location-enabled app where users use this app to record certain events in the field.
The important part of the event data is when an event happened. This is no issue when user is online, but we also support situations when user is offline (by remembering & later syncing events).
There could be situations when users are offline and they change the time on the phone, so that event times are wrongly recorded.
So, what would be the best way to ensure we get a correct time, independent of user actions, given that device could be offline. Some ideas:
GPS time. Is it possible to acquire it?
Tracking system time changes made by user?
Any other idea?
Note: time does need second accuracy, approximately minute accuracy would be ok.
Note2: we are creating mobile apps for Android and iPhone, so I'm interested for generic solutions and also solutions that are specific to any of those two platforms.
I, personally, wouldn't worry so much about this scenario. The liklihood of someone intentionally changing the time on their Android (which periodically throughout the day syncs to a time server automatically) while offline seems low to me. That being said, the only way I could see compensating for this is to keep a service running in the background that keeps a running tally of the seconds passed since recording the location data offline. Once uploaded to your servers you could use the elapsed seconds to calculate a time offset from current UTC time. It's an awful lot to go through, but it would work.
GPS time is an interesting idea, but Android allows users of the SDK to send mock locations to their devices. I'm not sure you could reliably track changes to system time either, and even if you could you'd be capturing them after the fact without the current real time as context.
We use GPS times in our app for very similar reasons. Since our users are in different time zones and we want local times, we define from our server what time zone they are in at installation time (they don't move very far). Hadn't thought of the mock GPS locations, but you would need to be a fairly advanced user to do that.