WP7 - License to Print Money (Creating an App for the Windows Phone Marketplace)



Recently I had the opportunity to create a Windows Phone 7 Game (WP7).  I was excited by the challenge because it would give me a chance to really learn how to go from start to finish with an application.  I figured that once I learned the process, I could start submitting many of my ideas like crazy.  I had visions of making big bucks with each app I released, because being a Silverlight developer, I also figured I could create apps better than others trying to do the same thing.  This is probably the same thought process that went through the heads of the 3 or 4 developers that just left the Microsoft WP7 team to stake their claim in the new frontier of WP7 app and game development.

This article was written to give the developer community a realistic view of creating WP7 apps and my predictions on what they can achieve now and in the future.

Stage 1 - The Idea

The first step in writing a WP7 app is to come up with an app that would sell.  Games seem to be pretty popular, so a game was high on my list of choices.  I eventually entered into an arrangement with a game creator to put their game concept on the phone.  The name of the game is Hold'em or Roll'em, a poker dice game in which you roll 10 dice and arrange the dice in various combinations to score points.  Being a big poker fan, I was happy to take this original game and port it to the phone and roll the dice to try my luck in the Zune marketplace so to speak.  With game concept in hand,  I was ready to roll into the development process.

Stage 2 - Design of the Game

The game creator had some ideas for how the game should look and sent me a layout.  I had a few ideas of my own, and between the two of us, we came up with the playing screens and requirements spec.  The game layout changed along the way, but the general rules of the game stayed the same.  Because I'm a real MVVM fan, each screen of the game had a ViewModel behind it. There was a ViewModel for the Main Screen and a ViewModel for the Score Panel.  The game logic resided completely in the Main Screen's view model.  Looking back it probably would have been cleaner to take the game logic and refactor it into a GameManager class, hence putting the game logic in the Model where it belongs.  In my rush to get it to market, I left the code the way it was.  In case you're wondering, my game was not completely void of models.  There is a ScoreManager class that calculates all the score combinations for the dice.  So Hold'em or Roll'em is in fact an MVVM design and not just a VVM design.  Figure 1 illustrates the design for Hold'em or Roll'em color coded by MVVM component.  Models are in purple,  Views are in blue, and   ViewModels are in red.


Figure 1 - Partial Design of Hold'em or Roll'em Reverse Engineered using WithClass 2010

Stage 3 - Implementing the Game

So now we get down to the nitty-gritty, coding up the game.  Since it is a dice rolling game, I needed a way to represent dice and the action of rolling them on the screen.  I could have created 3D dice figures through projection, but instead I went with the simple 2D dice that could roll using projection in the Y plane.  The dice were creating using Expression Blend as well as the dice rolling animation.  A value converter in conjunction with six datatemplate was used to choose a die that could show any of the 6 die graphics available.  I also added a drag-and-drop behavior (from blend) onto each die, so you could drag them on the screen.

The rest of the game used pretty standard controls (i.e. buttons and items controls).  I leveraged the MVVM Light library for WP7 to do all the event handling for buttons and selections and bring the handler into the view model.   Buttons were used to initiate rolling, scoring and some screen navigation.

The Help Screen

This turned out to be trickier than I thought.  I wanted a way to just display an rtf or html document to the user to explain the rules of the game.  Without the rules, I think the user would find the game difficult to play, so we needed a way to show them.  I finally came across something in one of the WP7 help areas that said, "just uses the browser control".   Easier said than done, but luckily there was a code example on how to do it in that same forum.  I found after finally getting the browser control to show my html documentation, the graphics and text were too tiny to read.  I learned that you need to put special meta tags in the html document in order to display it on the phone, otherwise it doesn't work. 

<meta name="HandheldFriendly" content="true" >

<meta name="viewport" content="width=320 user-scalable=no, initial-scale=1.0">


As with learning any new technologies, it's the little challenges that always get you spinning your wheels.


You quickly learn that any windows phone app you create will not maintain state on its own when you switch to another application.  So before your application gets tombstoned through a button press on the phone, you need to save the state of your app.  Luckily, Microsoft foresaw this issue and give a starter example of how to deal with tombstoning. In MVVM, it's easiest to put a DataContract on every ViewModel and then serialize the ViewModel class itself to maintain its state.  I just noticed a cool solution lumped into a single class on C# Corner that uses reflection to save the state of your application.  Here are a few things to keep in mind that the documentation doesn't tell you.  It's not enough to save the state of the objects.  You need to hook the references to other objects inside the objects back together (at least I did).  Be careful not to mark any property as a DataMember in your ViewModel that you don't want to serialize, but not to miss anything that you do want to serialize.  Make sure you call any additional  necessary initialization steps in the app handler that reactivates your application.    All pages need to handle tombstoning, so if you are navigating back to a page other than your initial screen, that page needs to restore the state of the app as well. Tombstoning took up a good few days of my time as you can imagine.

Testing your  Game on the Phone

While you are coding up the game, you can test the UI stages of the game through the emulator that comes with the Windows 7 Phone developer tools.   The emulator mimics the phone fairly well for things that don't require any special sensor data.  You are, however, using a mouse control on the emulator to navigate the screen instead of your finger like you would on the phone.  In order to run the app on the phone, you need to first of all buy a phone.  I bought my windows 7 phone at the AT&T app store.  At the time, they were offering the phone for $199 with a service plan.  I think now the phone is even less.  The service plan is a bit expensive (around $75/mo.)  Luckily there are other providers to choose from (like T-Mobil for $55/month), or you can get a family plan for a lot less.  I'm fairly happy with the AT&T Service and Samsung Focus Phone that they sold me; I just wish they would drop the price on their service.   Now that I had a phone, I needed a way to get my application onto the phone for testing.   I soon learned that there is a $99 fee to be an application developer for the Windows Phone.  Loosely translated, cough up the $99 and you can test your app on the phone.   A company called Chevron had a Jailbreak for the WP7, but I'm fairly sure Microsoft put the kibosh on this.  You can read all about it on Chevron's blog. To make a long story short, I signed up for a developer license.  I looked at it as a business expenditure that might pay itself back, so no real sweat.  Once I paid my hundred bucks, I thought I could just go right ahead and start cranking out games, but there was a catch.  GeoCode has to vet the license before you can get started.  I suppose they want to make sure that you are not some virus generating teenage hacker who wants to take over the world.  Either way, in my case it just made my wait just that much longer before I could start porting my game to the phone.  After some back and forth conversations with live web help from GeoCode, I soon made it through their vetting process, and Microsoft approved me almost instantly after.  I could start to see the light at the end of the tunnel.  I was able to register the phone with Microsoft and my phone was unlocked to all my wonderful ideas.  I was able to deploy my application with a deployment app that comes with the WP7 developer tools and appears on the start menu after install.  Keep in mind that if you try to use the deployment application without getting an application license, it won't work, so don't waste your time.

I was happy to finally have my app on the phone which has a real back button and real finger control.  Soon I was dragging the dice around the screen and playing the game as I hope thousands of other Window Phone users all over the world will do.  After two weeks more of testing on the phone, I was ready to submit my application for certification.

Going through the Certification Process

Once you are a developer on the Zune Marketplace, you have a dashboard that allows you to submit your game to be certified by Microsoft.   Certification requires that you obey certain rules and if you don't heed any one of them, you will fail certification.  If you are curious about what those rules entail, here is a link.  I wish I had read the rules before I entered the app to be certified, but for some stupid reason, I assumed that the  Silverlight development environment would just enforce all these rules naturally, and I wouldn't have to think about them.  Bad assumption. Upon submitting my app through the app hub, after 2 days, I failed on three rules.  The first rule I failed on was that the app has to be viewable in both light and dark themes.  The fact that my phone had a light theme was certainly news to me.  Sure enough, when I switched to a light theme, I couldn't play the game.  I had to go back and force the background color on the game to black as well as bind some of the windows phone standard styles to buttons and other controls.  The second rule I failed on was my game didn't include a tech support email and version number visible in the application.  This one was an easier one to fix, I just put the information in the help screen.  The final rule I failed on was that my application didn't dismiss dialogs when I hit the back button.  This rule I would never have guessed in a million years.  I was using popups in my Silverlight App for dialogs, so I needed to intercept the back button event handler, cancel the event, and close the popup programmatically.

Upon fixing these problems, I was able to pass certification and submit my app into the marketplace.  One thing I did notice is that the turnaround time from submitting your app for certification to getting an approval (or failure) was only a few days.  I was pretty amazed since I suspect hundreds of people are submitting apps every day to be tested.  I had a picture in my mind of 100 testers standing in a room banging away on the phone 24/7 going through the list of certification rules that looks something like a page out of a law school book.

Adding Artwork

There are a few other things you need to add when submitting your app to the marketplace.  Although some of these things are optional, it behooves you to add them all.  First of all, you need to add artwork in various sizes.  Below is a screen shot of Hold'em or Roll'em's artwork.  Microsoft is very specific on the pixel dimensions for each piece of artwork, so you need to adhere to that.  I used a tool called Paint.NET to help me with most of my artwork.  It's free and allows you to do some cool effects on your art.  Most importantly it helps you get the sizing correct.


Figure 2 - Artwork for Hold'em or Roll'em


Pricing is a tricky part of submitting the application.   Most applications are priced at $.99 or they are free.  You can price your app as high as $499 if you want, but currently the highest price I've seen in the marketplace is about $6.99.  Microsoft limits the number of free applications you can submit to the marketplace under your developer license, so eventually you have to start charging.  With a free application, you can opt for advertising to be placed inside your app which also generates some revenue.  How much revenue is probably too soon to say.  There is a thread in the community where developers are starting to share their sales numbers.  The Indie games aren't making anyone wealthy yet, but  its still early in the game for the windows phone.  Microsoft needs to increase their marketshare of the phone relative to the iPhone and Android phone, before anyone is going to see any significant numbers.


As of this writing, I have not yet gotten a revenue report for Hold'em and Roll'em, but expect to see one in a few days.  When I do, I'll append it to this article.  You may be asking yourself, if Android and iPhone have such a large part of the market, why would I write an application for the windows phone?  An iPhone developer once told me that Windows developers are spoiled because they have by far the best IDE  for developing applications, so they expect that experience from other development environments.   From a productivity standpoint, you can write more applications in a shorter period of time for the Windows 7 Phone using Visual Studio and Expression Blend then you can for the Android in Eclipse or the iPhone in Cocoa Touch and XCode.  Also,  if you are already a Silverlight C# (or VB.NET) developer, the learning curve to develop on the Windows Phone is a lot less.   Now let's just hope that Microsoft can market the platform like they did Windows 3.0 so it is worth our while.