![image001.jpg]()
Introduction
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.
![image002.jpg]()
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.
Tombstoning
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.
![image003.jpg]()
Figure 2 - Artwork for Hold'em or Roll'em
Pricing
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.
Conclusion
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.