Early on I decided to use Azure. First because I was using .NET and the tooling support is great. Second because I am a BizSpark member and have some free Azure resources. And third because I did not want to mess around withservers or other infrastructure but still wanted to know my game could scale on demand. Having decided to use Azure, I still needed to determine how to persist Scramble Legend’s data. Two solutions stood out: Azure Mobile Services and Azure Cloud Storage.

Azure Mobile Services provides a set of tools intended to address common app developer problems. For example, it has an API to authenticate players with Facebook, Microsoft, or Google. It also has an API to facilitate sending push notifications to Windows 8 computers. Loading and storing objects in Azure Mobile Services is very basic. You define a POCO and then use their API to perform CRUD operations. What’s more, Azure Mobile Services will only serialize basic types – no enums, no guid, and certainly no object relations. Finally, Azure Mobile Services allows you to write scripts to hook into CRUD events and do things like update other tables, send notifications, or log something. So what’s the downside? Cost and maturity. Azure Mobile Services is more expensive than the more basic Cloud Storage. It’s also much newer – still in beta as of writing this – and there are some rough edges.

Azure Mobile Services tries to solve common app developer problems
Azure Mobile Services tries to solve common app developer problems

Azure Cloud Storage is a collection of storage systems which allow you to load and store data. For our purposes there are two types of storage that are interesting: blobs and tables. Despite its name, table storage is non-relational. In practice using table storage is a lot like using Azure Mobile Service for persistence. Blob storage is more flexible as you are storing a binary array. In practice I have found blob storage to be much more useful. When used in conjunction with the DataContractSerializer it is easy to load and store objects or even object graphs. That said there is no connection between blobs except by your own convention, so going this route means you will have to do more work to support anything beyond reading and writing. In particular if you want to send push notifications, authenticate players, or any of the other things that Azure Mobile Services provides you will have to create your own service.

Azure Cloud Storage provides a cheap and easy way to load and store data
Azure Cloud Storage provides a cheap and easy way to load and store data

So which one is right for you? In my opinion, Azure Mobile Services is the better choice. Most game developers are not web developers, and most games need authentication, notifications at the very least. So if the choice is between spending a great deal of time reinventing the wheel with Azure Cloud Storage or paying a bit more for Azure Mobile Services I would recommend the later every time.

Continue reading my series on making games for Windows 8:
  1. Writing a Windows 8 Game Loop: Explores three ways to create a game loop
  2. XAML or MonoGame?: Examines the pros and cons for each option
  3. Storing Game Data in the Cloud: Azure Mobile Services or Cloud Storage?
  4. Animating Sprites with XAML: Cover the basics of animation for Windows 8
  5. Animating Spritesheets with XAML: Learn how to render a spritesheet using XAML and C#
  6. Persisting Game Data in Practice: One way to do it and some common pitfalls
  7. Keeping Game Data Consistent: How to maintain consistency in a NoSQL world