Have you ever wondered how Crush Crush is built, how it gets uploaded for testing, and how it ultimately ends up on your device? Then this blog post is for you! Let’s follow a copy of Crush Crush from the Unity Editor all the way to Android devices all over the World.
Here’s Crush Crush for mobile within the Unity Editor:
Unity is a multi-platform game engine, and is what Sad Panda uses to make its games. A single project can be deployed to PC, Mac, Linux, Android, iOS, WebGL and many other platforms, with reasonably minimal code changes. The mobile build is a bit special, because it was made from the ground up to support a portrait orientation instead of a landscape orientation (the landscape orientation is still used on Steam, WebGL and Kongregate).
The first step is to prepare all of the asset bundles associated with this build. The asset bundles and most of the art assets are stored in a separate project, to reduce the number of art assets in the main project. This allows us to quickly switch between iOS, Android or WebGL platforms, which all share the same codebase. Here’s what the asset bundle project for mobile assets looks like:
Yup, it’s pretty boring. It’s just a bunch of art assets and a few scripts to build asset bundles. We very rarely open this project at all, since building these asset bundles is automated during the build process, but I wanted to show it for completeness. Here’s Unity building the asset bundles:
Now it’s time to go back to the Android project. The Android project has some editor scripts that will copy over the correct asset bundles from the mobile assets project, and place them in something called the ‘StreamingAssets’ folder. Anything located in ‘SteamingAssets’ is included with the final build. This means that any assets in ‘StreamingAssets’ will end in the final apk (the Android application) that is delivered to Google Play, and ultimately your phone. We only include the assets necessary to play the early parts of the game. Once you unlock some characters (such as Peanut) the game will download those asset bundles from our server instead of relying on the ‘StreamingAssets’. This allows us to keep the download size of the apk a bit smaller. Right now, the apk is around 50MiB, and we have plans to reduce this further to under 40MiB. Not bad!
Any assets not included with the ‘StreamingAssets’ folder are uploaded to our website, and are cached by our CDN (CloudFlare) so that they can be served quickly to anyone playing the game that needs them.
Once this is done, we can actually build the apks for the Android version of the game. Again, this is all automated on our build server, but I’ll show some pictures of how this looks running in my local copy of the Unity Editor. From the ‘Build Settings’ menu we make sure that Android is selected as the build target, and that the correct scenes are included. We have both landscape and portrait versions of the game, so the correct scene is very important!
Then we hit ‘Build’, and the waiting game begins. We build multiple versions of Crush Crush when targeting Android. One version targets 32 bit devices, and another version targets 64 bit devices. Unity allows you to either make a single universal apk (which has the code for both 32 and 64 bit devices), or you can export each device type separately. We choose to export them separately to keep file size lower, since including both copies of the code inflates the apk size by about 8MiB or so! This can make a big difference when you’re downloading the game over cellular data. We don’t want anyone to get a data overage charge because they wanted to play Crush Crush!
The build process takes about 5 minutes on my personal computer, and a little bit longer on the build server. Once the build is complete, we have a folder with two apk files, which are ready for upload to Google.
The Google Play dashboard has several options for managing the release of a new version of the game. There is an internal test track, a closed alpha track, an open beta track (where people can opt in to play a beta version of the game), and finally a production track (which is the version of the game that is live to everyone on Google Play). We start with the alpha track, which has a list of test users (mostly studio employees). Here we can upload the new apks we just created, and deploy them to our test users:
Normally, we’ll test this for several days. We want to make sure that the transition to a new build is as seamless as possible for our players. We have a full battery of tests we run against all of our builds before they go live, and Support Panda is in charge of signing off on those QA tests. Once we are happy with the build, we can set it live on the production track as well. Google does allow us to select a rollout percentage, so we could set the build live over the course of a few days, but so far we’ve opted for 100% rollout. It hasn’t caused a problem so far! (knocks on wood)
Then there’s nothing to do but watch the stats roll in (and sometimes to wait for Google to process the update, which can take up to 8 hours). We use Fabric (recently acquired by Google, of course) for crash diagnostics. Fabric allows us to see the deployment percentage of different versions of the app. We’re pretty impressed with how quick most people update their devices!
If we did everything properly, and tested everything well, then the update process should be stress free, with minimal issues for our players (and for us). The whole process takes about a week, and is similar(ish) for our other platforms. We have, in the past, been able to hot fix a bug on Steam in less than half an hour, but we don’t want to make a habit of it! Hopefully you enjoyed this look behind the scenes at Sad Panda Studios. Thanks for playing our games!