With the recent release of new iPhones and iOS 8, we found ourselves in the position where we had to update our iOS games.  If we didn’t, our apps would crash on boot, and even if they did run, we wanted to make sure we custom laid everything out for the new iPhone screen sizes.  We had wanted to release updates for Cally’s Caves and Cally’s Caves 2 for a long time, but held off because we weren’t 100% sure how to do it, and updating player save data was intimidating.  Faced with the prospect of having our apps pulled, we buckled down and got our updates done.  Our process was probably unconventional, but we thought we would share how we did our updates for iOS without losing players’ save games in the process.  So, let’s begin.

Saves

The way we handled saving variables across play sessions in Cally’s Caves and Cally’s Caves 2 was the most basic way you can save things using Gamemaker: Studio.  We created an .ini file and had the game save variables that we wanted to keep saved in the file.  For example, say the player levels Cally up and increases her max hitpoints to four.  We don’t want that player to come back for their next play session and have their max hitpoints be three, right?  So after they level up, we open the .ini document in a line of code, save that variable (global.maxhp = 4), and then close the .ini document.  The next time the player starts the game, the global.maxhp value is read from the .ini document, so they will start with 4 max HP.  It’s a really simple system that you can find in the GM:S help.

In order to initialize and save values across multiple play sessions, the first time the game is run it will check to see if an .ini file exists, and if it does, it reads all of the save variables from it.  If no .ini file exists, the game creates the .ini file, sets all the save values to their defaults, and then closes the .ini file.

Note: Some developers don’t like using the .ini save system because players can access that data really easily on PC and hack the save values.  On iOS, hacking an .ini takes a bit more work so we decided not to pursue encryption-based saves.

The Problem

When we were working on the updates, we knew that they would involve new save values.  We were adding bonus levels to Cally’s Caves 2, as well as a new tutorial.  So, if you think about how we save variables, and how variables are read at the start of the game, the problem we ran into appears.  If we were to just add new lines of code into our existing save code (such as, global.bonuslevel1visited = 0), the games would try to read the new save values from an existing .ini file.  For a player who is installing the app for the first time, this is no problem.  The game will simply see that no .ini file exists and then set all the save values to their default.  For a player that is updating their app and already has a save file, the game will see that the original .ini file exists, not initialize the new variables, and then crash because it can’t find the new variables in the pre-update save file.  The prospect of this happening was terrifying, especially considering that there is a delay in the time between submitting an update and when it is released.

The Solution

After banging our heads off a wall for a couple of days, and searching for resources on how an .ini file would be handled by iOS through an update, we finally decided to try the simplest possible solution.  We decided that we would simply make a new save file (called “savefile2.ini”) for the update values.  This way, even though all of the prior values are set in “savefile.ini”, the game will still see that there is no .ini file for the new values, and initialize them.  It was the simplest and most obvious solution, but we found ourselves chasing a way to update the first save file without any crashes.  If we had just taken a step back and looked at it from a different perspective, we would have seen the solution sooner.

The Rest of the Process

After we had our save system worked out for the updates, we finished the new content and prepared for the update.  We created a new version of the app in Itunes Connect, uploaded video trailers (a new feature), implemented a new icon, translated patch notes, and created a new build the same way we always have through Xcode.  After that, all we had to do was wait and see if players had any problems with the game after updating.  Fortunately, we had multiple confirmations that the update was fine, and that no players had lost any of their original save data!  It simply picked up their save game where they left off, and all of the new values were initialized correctly.

This was the way we approached updating our app for iOS, and we are in no way trying to say that it is the best way.  We simply want to share a way that worked for us, so that if you are googling this exact problem right now, you can find some resources.  If you have any input, feedback, or a suggestion on how we could have done it better, please leave a comment and we would love to hear about it!