As I've mentioned before, one of the big differences with making mobile games is that people expect them to be updated. I think this may just be a weird mindset thing, because DLC for console games is a pretty standard thing these days, but for a mobile game, you've pretty much got to plan for content updates. I just recently completed my release schedule with updates dropping almost a year into the future, and while I'm not ready to spoil any of the content coming in them, I wanted to talk a little about what I've done to ensure everything goes smoothly when it is time, from content creation all the way to pushing the release button again.
The simplest place to start is with my build checklist. When everything's ready to go in-Unity, I go down a special list on my Trello board that reminds me all of the test mode switches that need flipped, all the places a version number needs updated, and the ever-important Phone Build checkbox that switches input types. This list (along with everything else I'm going to talk about, but this list specifically) is to make sure I don't forget any of those things when I come back to the game after a month or more of not looking at it, just so my releases can be spaced out appropriately.
Each update will include two new levels and four new submarine skins. I have a Photoshop template document set up for each, making operations like the base color swapping very easy. And thanks to Unity's new prefab variants system, importing the assets and the new GameObjects is as easy as dragging in the new image references. Then, I've just got to drag those newly-created objects into the relevant list of the DarkMagician game controller, and things like the shop and level select menu will read from there and update automatically.
The biggest potential "gotcha" is when it comes to updating save data. A typical game's save data file would include things like a numbers for score and currency, Booleans for whether things are unlocked or not, and option data like sound settings or a preferred control scheme. If you start adding to the list of what you need saved after doing your first release, you can run into problems if the game tries to access something that doesn't exist in the file. Luckily, there are a couple of built-in callback methods that are triggered automatically during file deserialization, and they are specifically to solve synchronization problems like adding or removing data fields before converting to the most current version of the class object. It's pretty cool, but the thing is, it's not even necessary for my game.
As I said above, the only new things I'm planning to add with each update are subs and levels. In my SaveData class (and therefore the save file) currently, there is a list of Booleans for each: a true value at index number 3 means that sub number 3 has been unlocked by the player, and so forth. Now, because of the magic of C#, a list is a list is a list, regardless of size. So while the lists get longer with each update, my SaveData class doesn't need to change its structure. Instead, I have a helper method that checks to see the number of subs and levels the player knows about against the number the game controller says there are. If there's a discrepancy (the game controller will always have more), I update the player's lists with false entries - because any new-to-the-game content will not be unlocked to the player, at least until they buy it from the shop. Again, the beauty of this solution is that I never need to worry about my SaveData class changing, just the sizes of lists inside of it.
Finally, there's some work that needs to be done on the Google Play Console, specifically within the games services portal. Since I want each new level to have a corresponding leaderboard, those need to be set up. I don't require any custom functionality for mine, so it's as easy as giving each new one a name and then copying the generated JSON into the correct place in the Unity build settings, then allowing everything else to work automatically from there.
When you go to upload the new build, you'll need to pick the track (beta or release), and then give a changelog or updated description. Your new file will replace the old one, and be available to the public as soon as it's been reviewed. This whole process goes a lot smoother after you get the initial one out of the way.
With all that said, the next release of Undersea Odyssey is ready, but I'm going to hold off until everyone has had a chance to explore everything the game has to offer right now. And don't worry, I'll make sure to continue posting art previews and technical explanations of any new features I've created in the meantime. And it's also just about time to start dropping hints about my next project as well...