Do you persist a per-user game state?

Forums Programming cocos2d support (graphics engine) Do you persist a per-user game state?

This topic contains 7 replies, has 5 voices, and was last updated by  HiRez 1 year, 5 months ago.

Viewing 8 posts - 1 through 8 (of 8 total)
Author Posts
Author Posts
November 10, 2012 at 7:43 pm #245242

lummis
Participant
@lummis

Apple documentation talks about the possibility that more than one user can use the same device so if you use game center you should authenticate the player every time the game becomes active. Think of two children who play your game on their mother’s iPhone (one at a time). So if your game uses Game Center you have to force a game center logout & login every time your game becomes active. You also have to persist the game state for each user separately and switch states depending on which user logged in. I’m thinking of a game with game center leaderboards and achievements — Julie wouldn’t want to make an achievement and have it credited to her brother Josh.

I have lots of games on my devices and I don’t think I’ve ever seen one that does this. But maybe I didn’t notice. Do you do some kind of per-user switch like this? Or do you assume that only one person will be playing your game?

November 10, 2012 at 10:19 pm #391913

jyoung
Participant
@jyoung

I thought about having multiple user profiles, but it’s not something I’m going to implement for the first version of my current game. What I do now is save the game center ID the user has when saving the game (can also ask if they want to use the current game center ID with the current save game before associating it), and before I post scores or achievements, check that the ID saved matches the current game center ID logged in. If not, I archive them to resubmit the next time the original player was logged in. This would work with multiple profiles/save game files.

That said, you’re right, most games don’t support multiple user profiles. I suppose one could argue that most iDevices are pretty personal, the exception maybe being iPads and the like.

November 11, 2012 at 11:59 am #391914

cybergreg
Participant
@cybergreg

‘you have to force a game center logout & login every time your game becomes active’

That is the wrong approach, while correct that you need to track gkplayerID’s, you do this by hooking into the “authenticationDidChange” notification. In this way you are notified when something changes and can take the required / appropriate actions.

:)

Oh and my first turn-based GC game I also did not track stuff for multiple players, however I did track and manage the turns and matches so in more than one player could play on one device, the matchID + playerID worked good for that.

I also remember playing tiny tower and it only allowed or tracked the first userID it got, if you changed it popped an alert telling you that stuff wouldn’t be tracked or reported until “UserX” signed in <- a less than desired user experience.

November 11, 2012 at 7:22 pm #391915

jyoung
Participant
@jyoung

Agreed, popups saying things won’t be sent to game center does not lead to the best user experience. Asking once up front, Do you want to use game center with this game? is better, but I don’t even like doing that. I also don’t like assuming that the user wants to use the currently signed in game center account.

November 11, 2012 at 7:39 pm #391916

cybergreg
Participant
@cybergreg

Here’s an approach that uses (yuk) nsuserdefaults…

https://github.com/anton-nikan/iOS-Game-Center-Cache

November 12, 2012 at 2:17 am #391917

lummis
Participant
@lummis

Thanks for your responses.

cybergreg: Of course you’re right about using authenticationDidChange. Thanks for that.

This issue is a real headache for me. I’ve already worked on my first game far too long (I won’t say how long- it’s too embarrassing) without thinking about multiple players. In the beginning I was just having fun trying different things without worrying about finishing the app but now I’m trying hard to wrap it up and get it submitted and I just recently realized the full significance of multiple users on one device. The design of my game really doesn’t lend itself to multiple users so rather than go back and redo a lot of stuff I just have to accept it as a shortcoming. It’s not the only one. I’ll say that it’s restricted to a single game center account and verify each time that the player is the same as the first one who played and logged into game center. If the player is different I won’t send scores and achievements and I’ll put up an alert to inform the user.

jyoung: I agree with you that this isn’t the best user experience but my game is so wonderful nobody will mind. :-)

For a while I worried that my game would be rejected if I don’t handle multiple players but I’ve confirmed that very few games in the App store do. Also I just confirmed that two popular books that game developers follow (Itterheim & Loew, and Strougo & Wenderlich) don’t handle multiple players. Also Richter’s book, which is devoted specifically to Game Center and Game Kit, mentions user changes but doesn’t talk about how to handle them and his sample code ignores multiple users. So I’m pretty sure Apple isn’t rejecting for that reason. If anybody knows this to be wrong, please reply.

November 12, 2012 at 2:55 pm #391918

razvan_b
Participant
@razvan_b

i did that in my first game! i do not recommend it. To much of a head ache for too little of a result.

November 12, 2012 at 6:05 pm #391919

HiRez
Participant
@hirez

I just save a dictionary of game settings to iCloud (and fall back to NSUserDefaults if it’s not available). That dictionary contains sub-dictionaries of each player’s game settings, with the keys being each player’s Game Center ID. There is one additional entry I create for “Unauthenticated” user, in case they’re not using Game Center, but in this case only one can be used per device. So then just authenticate the user on startup, use that ID to pull the appropriate dictionary, and load the settings.

Viewing 8 posts - 1 through 8 (of 8 total)

You must be logged in to reply to this topic.