What is an SPS ID?

Maybe you’ve gone to the MORE page from within Crush Crush and seen the SPS ID.  Or, perhaps you’ve e-mailed customer support and we’ve replied asking for your SPS ID.  Or perhaps you just seen the title of this blog post, and you too are wondering what an SPS ID is!  To arrive at the answer there is first a bit of history to unravel.

Some History

On February 9th, 2016, Sad Panda Studios launched its first game on Kongregate, Crush Crush.  We weren’t sure if the game would do well, and didn’t know how to service a game like Crush Crush.  A free to play game with new content, limited time events and frequent updates requires some infrastructure that a typical game.  For example, a typical game that you purchase a single time and play might never receive an update.  However, Crush Crush has been updated over 700 times, with major new content updates, bug fixes, events during holidays, and more.  To deliver this content efficiently, Crush Crush needs a connection to a server to get the latest art assets, events, etc.

With this knowledge in hand, and knowing that Crush Crush was a success, we took off to the 2016 Game Developers Conference in San Francisco.  Armed with his laptop, Programmer Panda approached several kiosks to discuss a solution to live servicing Crush Crush.  One kiosk stuck out, and that week Programmer Panda added PlayFab support to Crush Crush.  PlayFab allowed the Pandas to set news updates, store player sessions (important on the web!), hand out items to users, perform customer support, change store prices, set events, and more.

A typical player page in PlayFab

If you played Crush Crush around this time on Kongregate, you probably noticed the addition of a PlayFab ID on the MORE page.  Our customer support team would have asked for this information to restore a save file, etc.  PlayFab also supported the necessary server infrastructure for managing in-app purchases on Steam, which was helpful when we were scrambling to just keep up with content updates to Crush Crush.  Remember, we were only 3 people at the time, all of us with full-time jobs outside of Sad Panda Studios.

Migrating away from PlayFab

Over the months and years, PlayFab didn’t offer us all of the tools we needed to do our job.  It helped us when the game was new, but was now holding us back on the type of content and updates we could make.  We were already writing our own server software to support in-app purchases on platforms like Kongregate and Nutaku, and we had our own tools for customer support and save files at this time as well.  A decision was made to migrate away from PlayFab, starting in 2018.  Little by little, features that used to rely on PlayFab were relying on our own server software instead.  In 2018 both Crush Crush Kongregate and Steam dropped support for PlayFab entirely, and now work using our own server software.  In 2019, the Nutaku version of Crush Crush finally dropped PlayFab for user session storage, switching the last game over to our own server software exclusively.  Blush Blush, Hush Hush and Kitty Catsanova never used PlayFab, and have always used our own server software.

When you first install one of our games, a unique ID is assigned to your account.  That ID is your Sad Panda Studios ID (or SPS ID for short).  That ID will live with your account and should be the same ID across all of our games.  So, if you play both Blush Blush and Crush Crush on Steam, you should find that both games show the same SPS ID.  This allows us to enable features like the Panda Pass, which allows you to have inventory items across multiple game titles.  Cool!

A typical player page in our custom server solution

There are a lot of pros and cons when writing your own server software.  The obvious con is that any downtime is probably attributable to us.  It’s one extra thing we need to worry about, and something we need to plan for.  Maintenance?  That’s on us.  Server costs?  That’s on us too.  On the plus side, the server costs are much cheaper now that we have migrated away from PlayFab.  Another benefit is having full control of the data that we store.  We’re very keen on privacy, and we want to store only the information that is necessary for you to enjoy our games.  For this reason, we don’t log IP addresses, or associate your geographic information, IP, computer type, or any other personally identifiable information to your SPS account.  The only information we store is your account ID for whichever platform you are connecting on.  For example, if you connect on Steam, then we store your Steam ID so that we can link that to your SPS ID.

So, if anyone ever asks you about the SPS ID, you can confidently tell them that it’s a unique identifier used by Sad Panda to link your gaming account with your user data and inventory stored on Sad Panda servers.  It allows us to keep bringing you new content, new events and fun updates, hopefully for years to come!  Thanks for playing Sad Panda games, and we hope you enjoyed this blog post!

~Programmer Panda

How we deploy Crush Crush

This post was written by Programmer Panda!

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, and we normally start with something like 5% or 10% to ensure there are no major issues.

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!