Cloud Zone is brought to you in partnership with:

G. Andrew Duthie, aka devhammer, is a Technical Evangelist for Microsoft's Mid-Atlantic States district, where he provides support and education for developers working with the Microsoft development platform. In addition to his work with Microsoft, Andrew is the author of several books on ASP.NET and web development, and has spoken at numerous industry conferences from VSLive! and ASP.NET Connections, to Microsoft's Professional Developer Conference (PDC) and Tech-Ed. G. Andrew is a DZone MVB and is not an employee of DZone and has posted 41 posts at DZone. You can read more from them at their website. View Full User Profile

Building Cloud Data and Services for Windows 8 Apps

10.07.2012
| 3059 views |
  • submit to reddit

Introduction

In this post, I'm going to kick off a series in which I'll walk through the creation of a back-end service for a Windows 8 app. This first post will provide an overview of the series, and introduce a couple of potential technologies you can use to build your back-end services.

The Challenge

As an example of a scenario that might merit a nicely abstracted back-end service, I'm going to create a simple leaderboard service that can store and retrieve high scores and win/loss/tie stats for a variety of games. Since it's where I've spent the majority of my time lately, I'm going to focus on games built with HTML and Javascript, but the platform choices I'm going to describe will work just as well for games and apps build with C# or VB and XAML.

While there are many possibilities in terms of tools you can use to build and host back-end services, I'm going to focus for now on two:

  1. SQL Azure, Entity Framework, and WCF Data Services, hosted in a Windows Azure web role
  2. The recently-annouced Windows Azure Mobile Services


I will discuss the capabilities, advantages, and disadvantages of each platform, as well as some of the basics of my solution design. In subsequent posts, I'll dig deeper into each individual platform, and show how my solution using them can be easily integrated into a couple of games written by my peers.

The Games

The games I will be using in my examples were created by two of my fellow technical evangelists, Chris Bowen, and David Isbitski.

Catapult Wars

The first game I'm planning to use is the result of a nice 4-part series from Chris on creating a game for Windows 8 in HTML and JavaScript, and shows how you can port the XNA sample game Catapult Wars to Windows 8, with the help of neat libraries like Create.js. His series includes end-to-end instructions, from reusing game assets such as graphics and sounds, to supporting user input and more. The end result looks something like this:

screenshot_09132012_150046

Catapult Wars game screen

Catapult Wars is a win or lose game...you are the red catapult, and the game AI is the blue catapult, and you play until one player has no lives left. This allows me to track a leaderboard based on Win/Lose record.

Space Cadet

The second game I'll be using is Dave's Space Cadet, a simple space-based tap-to-shoot game that demonstrates a number of features of the Windows 8 HTML/JavaScript platform. Here's a shot of Space Cadet running:

SpaceCadet

Space Cadet game screen

Space Cadet, as it exists on Codeplex at the time of this writing, is an open-ended game with the action getting faster and faster with each score level, until the player gives up. In order to make the game work for my leaderboard scenario, I'm making some tweaks to introduce a game timer, so players will see how many ships they can destroy within a set time. This allows me to track a leaderboard by high score.

In both cases, my goal is to make the leaderboard code as non-intrusive as possible, so the goal will be to include all the code necessary to communicate with the service in a single JavaScript file, with the leaderboard display code contained in a separate set of HTML/JavaScript/CSS files.

The Schema

To help focus on the most pertinent aspects of building a back-end service, I'm keeping my data schema pretty simple. Here's what I'll be tracking:

  • ID - managed by the persistence mechanism, the unique ID for a given record
  • Game - name of the game for a given record
  • Player - name of the player for a given record
  • Score - the high score, if applicable, for a given record
  • Wins - the number of wins for a given player/game, if applicable
  • Losses - the number of losses for a given player/game, if applicable
  • Ties - the number of ties for a given player/game, if applicable

With the above information, we can track either high scores or win/loss/tie records for a variety of players across a variety of games.

Now let's look at our contenders for the role of back-end service...

SQL Azure, Entity Framework, and WCF Data Services

If your goal is to implement this kind of back-end service right now, a good choice would be to build an OData service on top of an Entity Framework model with a SQL Server back-end. Conveniently, you can do all this in the cloud with SQL Azure and Windows Azure. For this version of the leaderboard service, I'll be utilizing a SQL Azure database for storing my data, building a model on top of the data with Entity Framework, and exposing that data as an OData service using WCF Data Services. This will make it easy to access the data using simple WinJS.xhr requests (WinJS.xhr is a wrapper around the XmlHttpRequest object that adds support for asynchronous calling via Promises).

Here are the advantages and disadvantages of this stack for my leaderboard service:

Advantages

  • Comparatively mature platform
  • Can return data in XML (ATOM-PUB) or JSON format
  • Familiar environment for developers used to SQL Server
  • Easily create and expose custom logic using .NET code

Disadvantages

  • More complex to implement than Windows Azure Mobile Services
  • Currently no official client library for Windows Store apps (there are a couple of open-source JavaScript clients for OData, including datajs)

Windows Azure Mobile Services

The new kid on the block is Windows Azure Mobile Services. Announced in August 2012, Windows Azure Mobile Services is designed to make it simple and fast to create a back end for your mobile apps, including data storage and retrieval, push notifications, and authentication services. There's a tutorial available that walks you through creating your first Windows Azure Mobile Service, and it takes about 10 minutes to complete, and includes a sample Windows Store app project for download that implements the client end of the service (you can download either a C# or JavaScript version of the app), or instructions for adding support for the service to an existing app.

Here are the advantages and disadvantages of Windows Azure Mobile Services for my leaderboard service:

Advantages

  • Very simple to use...just create a table, reference the client library, and write my queries
  • Also provides push notification and authentication support
  • Free during preview period

Disadvantages

  • Windows Azure Mobile Services is currently a preview release, so it would be wise to wait for the final release to implement in a production app
  • Fewer customization points compared to SQL/EF/WCF Data Services stack
  • Client can create columns dynamically via code...so typos can get interesting (more on this in a future post)

Conclusion

In this post, I've outlined the challenge I'm looking to solve with a back-end service in the cloud, namely hosting a leaderboard for one or more games that I might want to release for Windows 8, or other platforms. I've discussed the two games I plan to use to demonstrate the integration of my leaderboard service, and I've described the two stacks on which I will implement the leaderboard service.

In my next post, I'll walk you through the process of creating the leaderboard back-end using Windows Azure Mobile Services, and creating a simple JavaScript library that can be easily integrated into a variety of Windows 8 games.

 

Published at DZone with permission of G. Andrew Duthie, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)