Releasing games for multiple platforms

Today is a big day, I finally released my company's 3D puzzle game, Shatter Crash, for Android on the Google Play Store.  I'm pretty happy about this release, it's something I've wanted to do awhile now, especially considering Shatter Crash originally came out for iPad in July of 2012.

Took long enough....

Actually there is a story as to why it took so long for the Shatter Crash Android version to come out, but that's something for another blog post.  It wasn't a technical reason though.

Since this is all fresh in my mind, I wanted to share a couple tips on stuff to think about when you do a multi-platform game.  This is more oriented for iOS and Android stuff, but will work for any other platforms as well

1. Port your game to the new platform.  This is pretty obvious. I use Unity3D which handles 99% of the stuff for all the different platforms.
2. You should look at the new platform and learn if there are a particular nuances of the platform you should try to handle.  One example, on Android hitting the back button on the main menu generally pops up a quit dialogue giving the user an ability to cleaning quit the app, not just put it into the background
3. Handling product/app store links for the new platform.  For Shatter Crash I added a 'Rate' button so users can rate the app.  On iOS this takes the user to the iOS ttore list, for Android it takes the user to the Google Play listing.  Ideally you can take advantage of a mechanism so the app uses the proper links automatically depending on the platform.
4. Handling UI layouts for different platforms. The iOS devices are pretty nice because you only have a handful of UI resolutions and aspect ratios.  All iPads are 4:3 aspect ratio, and iPhones/iPods are either 3:2 or 16:9.  Android obviously has a lot of different aspect ratios.  Ideally your UI can automatically handle scaling and moving widgets to take advantage of the screen for particular device it's running on, rather then you manually placing the widgets for every possible screen size
5. Way to direct users to the different store pages - When you go from 1 platform to many, you need to make it as easy as possible for people to find the version of the game relevant to them.  One idea here is make a page on you website with links to the different stores you game is on; then make sure to SEO the hell out of said page so it's highly placed on search engines.  
6. Achievement/Leaderboard/etc. - Competitive features like leaderboards and challenges, plus achievements for the collector-mentality players, are definitely nice to have in your game.  Different platforms generally have different implementations of these, which can be annoying to manage.  I created an internal API which my games use for handling leaderboards/achievements/challenges updates and unlocks.  That API in turn works with a binding layer responsible for interacting with the platform-specific system.  In this way I can build in support for all those features, then the platform binding layer handles how the nuances of converting that to the platform game system format 

Those are the ones off the top of my head, would love to hear more on this anyone had more suggestions.

And if you're looking for a fun 3D puzzle game, please do check out Shatter Crash on Google Play or iOS App Store!

Fixing Long Load Times in Shatter Crash

Development on Shatter Crash is moving along pretty well, we are currently working on polishing, UI and bug fixing.  One of the things I decided to tackle today was the long load times we were seeing when traveling from our game play scene back to the main menu scene.  This was especially bad on the iPad's, where we could see load times between 10 and 15 seconds.

The first thing I did was use Unity's cool profiler tool to get a sense of where time was being spent by running the game on my computer. However this ended up failing horribly because the editor continually stalled or crashed while I did deep profiling, probably because the call trees were incredibly deep.  Doing regular, non-deep profiling, didn't flag anything that jumped out as problematic, so I began to suspect the issue had to do with asset loading. As a note, as far as I know Unity's profiler doesn't give much details about asset loading/unloading, so this was simply a theory. (As a note, I didn't have wifi access at the time, so was unable to directly profile the game running on the device.)

I began to suspect the extended load times had to do with our GUI solution forcing Unity to pull in a lot of textures and create a number of object hierarchies.  I tested this by creating an iPad build with most of the UI ripped out to see how much faster the main menu loaded.  To my surprise, it only dropped the load time from ~15 seconds to ~14 seconds...looks like the GUI isn't to blame. I eventually resorted to brute force debugging by removing objects from the scene and pushing a new build to the device to see if things got better.  This certainly wasn't an ideal debug flow, but it did work.

I eventually found the cause of the load time spikes was related to how we referenced the puzzle data for Shatter Crash's game levels.  Our puzzle data is stored in ScriptableObjects for convenience, and each 'level' contains lists with hundreds, or thousands, of entries which define each piece on a puzzle board. For simplicity, I had created a script and prefab which directly referenced each of these puzzle ScriptableObjects (about 30), and this prefab was referenced in the main menu.  Removing the reference to this puzzle container prefab dropped our load times from ~15 to ~3 seconds...sweet problem found!  It seems Unity was taking a long time to load the main menu because it was loading and parsing all the list data in each of the puzzle data files.

Now that I knew the cause of the problem, the fix was fairly straightforward, although a bit tedious.  I changed the puzzle loading system to use Resources.Load to dynamically load the puzzle data we needed on-demand.  I generally shy away from using the Resources.Load() much because it's a real pain in the butt to keep asset paths up-to-date, and when I do I generally write unit tests to validate the existing paths are good.  While I was copy pasting strings, I came up with an idea for a new tool to automatically create Resource paths, hopefully I'll have a chance to create it in the near future

*UPDATE* - The game described here was ultimately released as 'Shatter Crash'.  I edited several places where I referenced it by its old name 'Access Point' to refer to the new name