9. Trial Mode
XNA's trial mode does not function in Windows so it
cannot be used to allow the player to switch between an evaluation or
full copy of the game. You will need to implement this functionality
yourself.
The easiest way to do this by far is to create two
different versions of the game: one a trial version (with whichever
features are being excluded completely removed from the game), and the
second a full version with all the missing features restored. Your users
can then evaluate the trial version before purchasing, at which point
you provide them with the full version.
Without the Windows Phone Marketplace, you will need
to implement your own purchase system. One simple option is to use an
online credit card–processing service such as PayPal and to send out
full versions of the game each time you are notified of a purchase.
10. Distribution
The lack of a Windows Phone Marketplace equivalent
for Windows also means that you have no centralized channel through
which to distribute your game. Instead, you will need to create your own
channels via a web site or online software portal, for example.
One advantage of being in control of the distribution
yourself, however, is that you do not have to undergo any kind of
submission process before you can release your software. When you decide
that it is ready, you can distribute it immediately.
11. Revisiting Some Example Projects
Two of the more complex example projects have been
re-created for Windows to show how little effort is generally required
in getting them up and running.
11.1. The FireAndSmoke Project
Only one change was required during the conversion of
the project: to simply set a more appropriate default screen
resolution—1024 × 768 pixels instead of the phone's 800 × 480.
With this change made, the project runs very nicely under both Windows and Windows Phone 7.
11.2. The VaporTrailTS project
Three changes were required during the conversion of
the project. The first was to set a more appropriate default screen
resolution, just as we did for the FireAndSmoke project.
The second change, the only one of any substance, was to the way the camera mode is changed. On the phone, the TouchPanel class is used to detect taps to the screen, but in Windows we need to use the Mouse class instead. However, the Mouse
class only tells us whether the button is up or down, and doesn't
directly provide a way to tell whether the button has been pressed down
since the last update. As a result, simply checking the left button
state would cause the camera to constantly and rapidly cycle through all
the different modes when the button was held down, making it very
difficult for the user to simply move to the next mode.
We can replicate the "just pressed" behavior by
storing the state of the mouse from the previous update and comparing it
with the state for the current update. If it was up previously but is
down now, it has just been pressed, and we can move to the next camera
mode; otherwise, the camera mode is not altered.
Listing 9
shows the first part of this modification. It declares a class-level
variable to hold the mouse state from the previous update. We begin by
setting the current state into it, so there is always a valid set of
data contained within the variable even during the first call to Update.
Example 9. Storing the previous state of the mouse
#if WINDOWS
// Track the previous mouse state so we can tell when the button pressed state changes
private MouseState lastMouseState = Mouse.GetState();
#endif
|
The remainder of the code is shown in Listing 10.
It checks the current state of the left mouse button and compares it
with the previous state, indicating that the camera should be updated
only if the button has just been pressed.
Example 10. Checking to see whether the camera mode should be updated
bool toggleCamera = false;
#if WINDOWS_PHONE
// Has the user touched the screen?
TouchCollection tc = TouchPanel.GetState();
if (tc.Count == 1 && tc[0].State == TouchLocationState.Pressed) toggleCamera = true;
#else
// Was the mouse up last time, but is down now?
MouseState thisMouseState = Mouse.GetState();
if (lastMouseState.LeftButton == ButtonState.Released &&
thisMouseState.LeftButton == ButtonState.Pressed)
{
// Yes, so change camera
toggleCamera = true;
}
// Store the new mouse state for next time
lastMouseState = thisMouseState;
#endif
|
The final change to the project is a cosmetic one
that is present only to make the project look better. When we ran on the
phone, we instructed the PaperPlaneObject class to add a new
vapor particle only every three updates. This provided a reasonable
balance between display complexity and performance; adding more
particles caused the game to slow down when running on the device.
Windows PCs tend to have significantly more graphical
power than the phone, so we can happily add a particle every update.
This results in a much thicker and more voluminous vapor trail.
Everything else works as required without needing to be changed.
12. Developing Games for Windows Phone 7 and Windows
If you decide that you want to target both platforms,
you know now that it is a feasible goal. The primary piece of advice
that I can offer is to simply test your game in both environments as
often as you can throughout its development. The sooner you try things
out, the quicker you can spot problems and correct them before you build
too much additional complexity on top of them.
