Sign In Register

How can we help you today?

Start a new topic

Mobile versioning using snapshots

Lets say we have game version 1.0 and 2.0 and the new version will need a snapshot update(for example but not limited to adding new items)

This will make game version 1.0 incompatible with the 2.0 snapshot 


Is there a way for the game version 1.0 to connect older snapshot or do i need to do versioning myself in the cloud code? This will be issue we cannot guarantee if the mobile users have updated the game.


3 people have this question

I want to further improve this question with Apple Validation process in mind, they require to test the new versions of games before they are released. In this scenario, the 2.0 would need to be out before users can even use it because Apple tests are done on production environment.


So I am also interested to see what the process should be to make it all work.

Hi Lasse,


It won't make 1.0 incompatible. It would however depend on the changes you are making to you game. If you keep a meta collection of the games version info a player can retrieve this on login and then store it in their scriptData. If you feel the changes from 1.0 to 2.0 are big enough to warrant them to have to go to the store to update the game you display a message when they log in after the 2.0 snapshot has been pushed to live. At this point you could direct them to the store to update their build. Does that make sense ?


Thanks,

Liam

Liam - What if a whole meta data collection is removed in snapshot 2.0. All game clients trying to read that data would crash. No problem forcing users to update, but the problem is during the review process that can take any time from a couple of days to weeks, and the build sent for review needs to connect to the 2.0 version which means it needs to be pushed to live stage before sending the new client build to Apple for review.


 Hey Kristofer,

In this case our customers would usually copy a snapshot and create a new review-copy of their game which is separate from the main build for the duration of the review.
You can then use the separate API key for the review copy. Once the game has been reviewed, you can push that snapshot to live.

Does that make sense?
Sean

I undestand what you are saying, but this means that the build sent to Apple for review is connected with another project (review-copy), so when the build pass apple review, we cant release this version to the public anyway. We would have to build another version connected with our main GS project(Live stage) and submit it for review again.


 


1 person likes this

I agree with Kristofer. The version submitted to AppleStore must be identical to the one what will be released in the store. You cannot change it after the Apple review.


The only way I can see right now to solve this issue is to have a routing config file that is hosted on an other service like Amazon S3 that will deliver the API key to the game based of the version number. This file can then be changed when the game is live to route to the correct server.

I have also looked at solutions involving having a config file stored on another server, but then again i think that this should be solved by GameSparks. It would be nice to be able to have two snapshots live at the same time, and we could setup on GS that client version 1.0.0 connects to Snapshot 1.0.0 and client version 1.0.1 connects to snapshot 1.0.1, after review we could then force 1.0.0 users to update to the new client.

 


3 people like this

I'm in the same boat: I must update a mobile game from v1 to v2 (to keep things simple). My favorite solution would be to have 2 snapshots live at the same time and to have my GS calls routed to the appropriate one depending on the a version number I'd send in the init.


I actually don't know how to plan for this in the future. The game will be ported to Steam soon and then Facebook. That's 4 platform that I'll need to update at the same time if I ever want to make a change. Which is all but impossible to do.


So right now, it appears I have 2 options: do my own routing via Cloud Code on GS or have each platform point to a different GameId. Neither is a good option. Way larger game than mine are using Game Sparks. How do they do it?

Login to post a comment