Visual Studio offers a Windows Phone emulator to help test and debug your programs. Although it is essential to use a real device regularly during your application development process to ensure that everything works properly on actual hardware, being able to use the emulator for general coding and testing is extremely useful. A screenshot of the Windows Phone emulator is shown in Figure 1-1.

Figure 1.1. Windows Phone emulator

The emulator offers a full implementation of the physical device and is capable of running genuine Windows Phone applications. It offers access to a number of features of the device, including the ability to simulate networking, screen rotation, and touch screen input using the mouse cursor. (In fact, if you are developing on a Windows 7 computer with a touch-enabled screen, you can perform touch and multitouch operations on the emulator by touching your PC screen.)

Running your application in an emulator is as simple as can be: just select to use the emulator within the Visual Studio IDE and start your application. The emulator will appear, and your program will run.

When we fire up the emulator shortly, note that it takes a little while to initialize itself. This would get frustrating very quickly when you are in a repeat modify/compile/test cycle, but the emulator can be left running in the background when you stop your code from executing and will then resume much more quickly the next time you begin a debug session. When the emulator's Close button is clicked, it will prompt for confirmation that the emulator is really no longer required, which is very useful protection against accidentally closing the window without actually meaning to.

A fully featured page designer is available to lay out windows and controls for use within Silverlight programs. The designer goes as far as to display an image of the device around the edge of your page to help visualize its appearance.

Silverlight pages can be created and modified by either using the designer or by editing the underlying eXtensible Application Markup Language (XAML, which is generally pronounced "zammal"). We will look at XAML and the Silverlight page designer in a great deal more detail later in this book. Visual Studio will display both the designer and the XAML editor as side-by-side panels within the IDE, as shown in Figure 1-2, and any change made to either will be immediately reflected in the corresponding panel. This provides a very flexible mechanism for page design, allowing each panel to work together to perform their actions more efficiently.

Figure 1.2. The Silverlight page editor showing the designer and page source together

Another extremely useful tool is Visual Studio's breakpoint feature. No doubt familiar to any desktop developer, breakpoints are fully supported for Windows Phone development, too, and can be used both when running against the emulator and against a physical device. It can be extremely useful to break into your code, examine your variables, and step through the instructions while watching the results on a real device on the desk next to you.

Access to the Visual Studio Output window is available from Windows Phone applications running inside the IDE. Text can be written to the Output window at any time, allowing you to easily keep track of what your program is doing. Pairing this with the ability to have two independent screens (your PC screen and your mobile device screen) makes this tool particularly powerful.

To begin with, all Windows Phone devices will have a screen with a Wide VGA (WVGA) resolution (480 pixels across by 800 pixels tall), which will greatly simplify the task of ensuring that games and applications properly fit on the screen without having to stretch, shrink, or leave large areas of the screen unused.

Microsoft has stated that future devices might use a Half VGA (HVGA) resolution of 480 pixels by 320 pixels, but at the time of writing no such devices have been announced.

All Windows Phone7 devices will have capacitive touch screens. Capacitive screens tend to be much more durable than the resistive screens used in many older devices and tend to be more sensitive. They also offer support for multitouch input, which is generally not available on resistive devices. The main disadvantage of capacitive screens is that they require interaction from a conductive source (such as a finger) and they don't work with a stylus (although special capacitive styluses are available if you hunt around). The design of the Windows Phone operating system is based around touch input rather than stylus input, a decision that is consistent with most smartphone platforms and operating systems currently in production.

Windows Phone devices will support multitouch, with a minimum of four distinct points able to be tracked at once. This opens up some interesting possibilities for gaming, and we'll be looking at how to use multitouch in games later on in this book.

An important consideration when designing a game for a mobile platform is that the screen orientation can be rotated when compared to that of a desktop PC, resulting in a screen that is tall rather than wide. This benefits some types of games (Tetris-style games, for example), but can be problematic for others. Fortunately, Windows Phone 7 has extremely good support for rotating into landscape orientations, so you can take advantage of whichever screen layout best suits your game.

One of the details that Microsoft has been very strict about for devices running its new operating system is hardware buttons. All devices must have exactly three buttons on the front of the device: a Back button, a Windows button, and a Search button.

Having consistency over the available buttons is good for developers as it means that we don't have to worry about lots of combinations of control mechanisms. However, this limited set of buttons means that there will be no directional pad available, which is a pity because they are very useful as a game input device.

Instead we can use the touch screen for input, and there are lots of clever and creative ways that this can be done, from designing games that the user interacts with by touching objects on the screen to displaying movement buttons at the bottom of the screen for the user to press.

These rigid requirements don't rule out the possibility of a device manufacturer including a hardware keyboard with the device, however, and this is likely to be a common feature among Windows Phone 7 devices. Keyboards can be implemented either as a slide-out panel behind the screen or below the screen in a similar style to BlackBerry devices. The presence of a keyboard opens up the opportunities for the player to control your game, but in most cases it would be sensible to avoid making this a necessity for your game to avoid excluding a large proportion of your audience.

The Windows Phone 7 platform specification states that all devices must be equipped with at least a 1GHz processor. This should result in excellent performance across all devices.

You should expect processor speeds to increase as the platform evolves, so it is important to cater for devices that are running at faster speeds than this, but as a minimum it does mean that a significant amount of processing power will be available on all devices.

One of the problems that developers on the Windows Mobile platform faced was in the choice of a graphics application programming interface (API). It was uncommon for Windows Mobile devices to have hardware acceleration, which meant that the only graphics API available across all devices was the Graphics Device Interface (GDI), which was very lacking both in terms of features and performance.

This problem can be put firmly in the past with Windows Phone. The graphics API for high-performance games is XNA, a powerful library based around the DirectX technology that has been powering desktop PC games for the last decade. The phone implementation isn't quite as powerful as on the desktop, but it still has very impressive capabilities for a mobile device.

Alongside the API is hardware graphics acceleration, which the phone needs to create fast-moving, complex two-dimensional and three-dimensional scenes without bringing the device to its knees. Because it will be included as standard in all devices, the opportunities for gaming are immense.

Also standard on all devices will be an accelerometer and a Global Positioning System (GPS) receiver.

The accelerometer can be very useful for game developers. It allows the device to detect which way up it is being held and can sense in detail any movement that results in the device being rotated. This provides an excellent input control mechanism, allowing players to influence what is happening on the screen by physically moving their phones.

Probably of less interest for gaming is the GPS functionality. When appropriate line-of-sight reception has been established with the GPS satellites, the device can detect where in the world it is located. This opens opportunities for making games that revolve around the player's whereabouts, but the scope for this in gaming is likely to be limited.

Let's not forget an extremely important fact: your game is running on other people's phones and personal organizers. They will place more importance on tasks such as answering a phone call or responding to a calendar reminder alert than in continuing to play your game.

Running applications have limited control over what happens when other features of the device become active. An application that loses focus will be closed down, regardless of whether the user was finished with it.

These terminated applications can be resumed at a later time, and the operating system will indicate that they are being relaunched rather than restarted from scratch. To ensure that users don't lose their progress in a game, we can take care to behave nicely under these conditions: we can save the game state to the device prior to exiting so that it can be automatically restored the next time the game starts and automatically pause when the game resumes to allow the user time to adjust to what is going on. People will appreciate details like these.

This kind of feature often becomes invisible when it works well but is much more likely to be very visible when it doesn't work. Make sure that you take these unexpected interactions into consideration.

A number of different templates are provided by Visual Studio for your new project. Each of these will result in a different initial project for you to start working on, as follows:

It is not possible to change the project type once the project has been created. If you find that you need to change the project once you have started developing it, you will need to create a new project of the required type and copy in all of the existing code files.

Before you can deploy applications to a device, you must first have a Windows Phone developer account. These accounts are not free, though they are relatively inexpensive (currently priced at $99 per year, though this might change in the future). You will need this account before you can publish any of your finished games into the Windows Phone Marketplace, anyway, so there is not really any way to avoid this charge, even if you develop entirely on the emulator.

You can sign up for an account at the http://create.msdn.com web site. You will be required to prove your identity to Microsoft as part of this process and will receive e-mail notification telling you how to do this. The process might take a couple of days from start to finish.

Besides providing your personal details, you will also be able to provide banking details so that you can be paid for applications that you create and sell in the Marketplace.

Once your account is registered and active, the next step is to set the device up to connect to your PC. First, plug the device in and allow Windows to set up its drivers. This should be a completely automatic process.

Next you will need to install the latest Zune client software. An up-to-date version of this software is essential, so if you have an older version already installed, you will need to upgrade. This application is used for all data transfer and synchronization between the phone and your PC, and will need to be running all the time that you are working with the device. Without this, you will receive an error from Visual Studio when you attempt to deploy.

Once the Zune software has launched, you have to sign in to your Marketplace account, which allows the software to identify that you have registered for development and will unlock the deployment facility that Visual Studio needs to use to transfer your games and applications to the device. The device confirmation screens then appear, as shown in Figure 1-8, allowing you to set up the device for use with your PC.

Figure 1.8. Configuring the device inside the Zune software for use with the PC

The final step in setting up the device is to run the Windows Phone Developer Registration application on the PC. This is part of the Windows Phone Software Development Kit, and can be found in the Start menu inside All Programs/Windows Phone Developer Tools. When launched, the application displays a screen like the one shown in Figure 1-9.

Figure 1.9. The Windows Phone Developer Registration application

You need to enter the username and password of your developer account and then click the Register button. After a few seconds, you should be notified that the phone was successfully registered. At this point you are finally ready to begin working with your phone in Visual Studio.

These steps only need to be performed once for each device that you use.

Now we are ready to deploy our project to the device from inside Visual Studio.

First, with the Zune software running in the background on your PC, connect your device to the PC and ensure that it is recognized by Windows. Once everything is ready, choose to deploy your application to the device rather than the emulator. This is done by dropping down the Device combo box in the toolbar and selecting Windows Phone 7 Device, as shown in Figure 1-10. When you next start your program, Visual Studio will connect to the device and then install and launch the application executable.

Figure 1.10. Choosing to launch the application on a physical device

Unsurprisingly, the project running on the phone looks and behaves just as it did in the emulator. Congratulations, you have written and deployed your first Windows Phone application!

First, try setting a breakpoint on the line of code containing the MessageBox function call. Launch the program (on a real device or the emulator), and click the button within the page. As you would expect, the breakpoint triggers just as it would on a desktop application.

From here, you can explore all the usual attributes of your application: the call stack, object property windows, visualizers, and immediate window commands. Everything is present and working.

The one useful feature that is not available, however, is "edit and continue." Unfortunately, because the application is actually running outside of Visual Studio's controlled environment, such changes cannot be applied at runtime and will need to be held back until the IDE returns to edit mode.

At any stage within your application you can display text in Visual Studio's Output window. This is done in just the same way as for a desktop application—by using the System.Diagnostics.Debug object. To test this, modify the button click handler as shown in Listing 1-2.

private void button1_Click(object sender, RoutedEventArgs e)
{
    System.Diagnostics.Debug.WriteLine("Debug text");
    MessageBox.Show("Hello Windows Phone!", "Testing", MessageBoxButton.OK);
}

Each time you click the button, you will now see your debug text appear within the IDE, as shown in Figure 1-11.

Figure 1.11. Debug text appearing in the Debug Output window

As you would expect from one of Microsoft's products, comprehensive and detailed documentation is available for all aspects of Windows Phone development and the .NET CF. Provided you have it installed, MSDN is an excellent source of help and is never farther away than a quick press of the F1 key.

The Web is, as ever, an indispensible fountain of information. When searching, try to accompany your search phrase with "windows phone" or "windows phone 7" (including the quotation marks).

The Developer Center can be found at the following URL:

http://create.msdn.com/

The site hosts a large variety of articles, development tips, frequently asked questions, and code samples. Also of particular interest is the Forums link, which leads to a number of very active message forums. There's a good chance that someone will be able to offer you some assistance.

Some excellent community sites have built up around the XNA and Silverlight technologies used on Windows Phone 7, and they are a good place to read and ask questions if you need assistance.

For XNA, you can visit http://creators.xna.com for one such community. For Silverlight, http://www.silverlight.net provides similar resources. Besides their forums, both sites are packed with information and downloads, and are well worth visiting.

XNA is the framework of choice for anything involving 3D graphics, full-screen graphical effects, or large numbers of moving objects. The graphical approach of XNA relies on completely redrawing the whole screen every frame (30 times per second or more), and it's just as easy to redraw things in different positions as it is to redraw them unmoved.

The whole architecture of an XNA game application is based around rapid and continuous updates of the graphics onscreen. We have full access to all the device features, including the use of the multitouch screen, accelerometer, and sound and music output.

For games that require a little less graphical grunt, Silverlight is a very capable environment for game development. Ideal for puzzle games and other games that don't require dozens of constantly moving objects, Silverlight's graphical capabilities still provide features such as transparency, scaling, and rotation of graphics—all of which are very useful for games.

Games that require a rich graphical user interface (GUI) are likely to be obvious candidates for Silverlight. Its page design capabilities are highly flexible, offering everything from labels to fully working web browser controls—unlike XNA, which has no built-in user interface features at all and requires everything to be manually programmed.

As with XNA, the device features are all available in Silverlight, including the multitouch display and accelerometer. Unlike XNA, Silverlight is event-driven, so your coding model will generally be responding to event calls rather than polling the device state.

Silverlight is also much better at displaying text than XNA. Whereas XNA relies on bitmap representations of fonts (which become blocky and are distorted if they are drawn too large), Silverlight uses vector-based fonts, allowing them to be zoomed without any such distortion.

A nice side effect of developing for Silverlight is that games can, with some work, be converted to run on a PC within a web browser. This can be very useful for helping to promote your game—instead of just telling your audience about it, you can actually let them play it immediately at the click of a button.