4

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.

tshepang
  • 12,111
  • 21
  • 91
  • 136
Gapton
  • 2,044
  • 2
  • 20
  • 33
  • Well a fast and easy solution would be to deduct the coin after the game is played, instead of before. – Skyler Saleh Aug 15 '11 at 05:40
  • Seems to me that in that case, players play for free when: (1) they quit the app and it got killed by the system (2) they quit the app and kill it themselves in the multitasking bar (3) it crashes, which is fair enough.... – Gapton Aug 15 '11 at 08:00
  • well you have to ask yourself this, is it worth your time to prevent someone from possibly finding this and exploiting it for a couple of free rounds. – Skyler Saleh Aug 16 '11 at 00:18
  • Unfortunately, after thinking it through with my colleagues, we believe that a significant amount of users will choose not to pay especially when its just a double-tap away. So yes we intend to prevent this, by deducting the "coin" at the start of the game. – Gapton Aug 16 '11 at 03:53

2 Answers2

3

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.

SplinterReality
  • 3,400
  • 1
  • 23
  • 45
  • probably makes it too easy for the user to avoid paying for their rounds played in that case. – Coxy Aug 15 '11 at 06:41
  • Firstly thanks for your input. This would make programming easier, however this also opens up to the players an option to only pay for a round where they played exceptionally well. For users who just wanna play and have fun, they now have the option to not pay at all, not good for any developer trying to make a living with their programs. – Gapton Aug 15 '11 at 07:45
  • @Gapton That being the case, I don't see how you'd be able to avoid creating a game save. At that point, you'd need to enlist the help of a server to make sure changes aren't made to the save file. Either push the data off device, or push a hash code of the save file off device. – SplinterReality Aug 16 '11 at 02:18
  • @Gapton Wanted to add one last comment: There's a fine line between stopping cheating, and inconveniencing your customer. The cheaters are unlikely to be customers (at least for long) and so you really should put the needs of your customers above the needs of those who might try to game the system. I know some kinds of cheating can impact your paying customers, which is what you should probably focus on, and put other, lower priority items on the back burner. I suggest using a server, but if the user is offline, that fails obviously. Have fallbacks to protect your customers as the #1 priority. – SplinterReality Aug 16 '11 at 02:41
  • @Charles Chappell thanks for the advice, I understand what you mean. Dev usually think cheats/cracks are always their worst enemies, but it actually isnt that straightforward. Players who are willing to buy, players who may or may not buy, and players who will definitely not buy my game, can actually be 3 separate groups of people I should target. And yes, I understand that dev cannot squeeze money out of group #3 no matter how cheat-proof/crack-proof their software is. – Gapton Aug 16 '11 at 04:06
2

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!

msgambel
  • 7,320
  • 4
  • 46
  • 62
  • Thanks for the info ! This looks like something I can use. I will definitely read about it and see how it could fit into the game. Only worry is using it to save a big amount of complex objects.... – Gapton Aug 15 '11 at 07:59