Windows XP
Windows Vista
Windows 7
Windows Azure
Windows Server
Windows Phone
Windows Phone

Windows Phone 7 : Running XNA Projects in Windows (part 4) - Converting the Game Framework to Run on Windows

6/24/2013 11:24:36 AM

8. Converting the Game Framework to Run on Windows

To get our projects running both on the phone and on Windows, we will need to create a version of this library that works in Windows, too.

This turns out to be a simple process for the most part, and allows us to transfer the phone's projects into Windows without too much effort.

In this section we will look at the steps involved in getting GameFramework working in both environments.

8.1. Storing and Retrieving Game Settings

As mentioned in the "Isolated Storage" section a moment ago, there is no IsolatedStorageSettings class in the Windows version of XNA, so we will need to find an alternative method for Windows to use for storing settings in the GameFramework.SettingsManager class.

This functionality is not too tricky to replicate. First of all, when compiling for Windows, the class will provide a dictionary into which string values can be written. Two new functions are then provided that allow the contents of this dictionary to be translated into an XML document and written to disk, or to be read back from the XML and placed back into the dictionary.

The API for the class can remain identical across the two platforms, removing any need for the games using the class to have to cater separately for each target environment.

First there is the settings dictionary. This dictionary is declared as a class-level variable, as shown in Listing 6, set to compile only under Windows. Alongside it we declare a file name to use when reading and writing the settings. No path is specified, so this will be created in the same directory as the game's executable.

Example 6. Creating a Dictionary to store the game's settings
    // Declare a dictionary into which all of our settings will be written
    private Dictionary<string, string> _settings = new Dictionary<string, string>();
    // The name of the file in which the settings will be stored
    private const string FileName = "Settings.dat";


Following on from this is a minor change to the class constructor. So that any previously stored settings are available as soon as the class is queried, they must be reloaded. The constructor handles it to ensure that values are always available to the class. Listing 7 shows the new constructor; we will look at the LoadSettings function shortly.

Example 7. The modified SettingsManager class constructor
internal SettingsManager(GameHost game)
        // Store the game reference
        _game = game;

        // Load any existing stored settings

The next change that the class needs relates to putting values into the dictionary and getting them back out again. Although there are multiple overloads of SetValue and GetValue, only one overload for each function actually interacts with the settings, so this is the only one that we need to modify.

SetValue is enhanced as shown in Listing 8 so that it will work for both Windows Phone 7 games and Windows games. The Windows code is virtually identical to that of Windows Phone 7, except that it uses the class's _settings dictionary instead of IsolatedStorageSettings.

Example 8. Creating or updating settings values
public void SetValue(string settingName, string value)
        // Convert the setting name to lower case so that names are case-insensitive
        settingName = settingName.ToLower();

        // Does a setting with this name already exist?
        if (IsolatedStorageSettings.ApplicationSettings.Contains(settingName))
            // Yes, so update its value
            IsolatedStorageSettings.ApplicationSettings[settingName] = value;
            // No, so add it
            IsolatedStorageSettings.ApplicationSettings.Add(settingName, value);
        // Does this setting already exist in the dictionary?
        if (_settings.ContainsKey(settingName))
            // Update the setting's value
            _settings[settingName] = value;
            // Add the value
            _settings.Add(settingName, value);
        // Save the settings


One final change is present in this piece of code in addition to the change of dictionary, however: it makes a call to SaveSettings each time a value is updated. This ensures that the settings are always retained from the moment they are modified, mirroring the behavior on the phone. We will look at the SaveSettings function shortly.

The code for GetValue is similarly modified, reading from either the _settings dictionary or IsolatedStorageSettings as appropriate. This is repeated, too, for the ClearValues and DeleteValue functions, both of which also call SaveSettings to ensure that their changes are immediately reflected to the data file on disk.

Finally we arrive at SaveSettings and LoadSettings, whose responsibilities are to ensure that the data is stored for later use, and then read back in for subsequent interrogation. They operate using an XML file, into which all the defined values are placed.

The code within these functions is not particularly interesting, using exactly the same techniques that we used for saving and restoring the high scores inside the HighScores class, so please take a look in the project's source code if you want to see how they are implemented.

With these changes in place, the class operates identically (from the client's perspective) under both environments. If you scan through the code for the class, the conditional compilation statements scattered throughout do make the code harder to read, but the overall functionality is worth that increase in complexity if you want to be able to target both platforms.

8.2. Application Life Cycle Events

Although in Windows Phone 7 we need to deal with the Launching, Closing, Deactivated, and Activated events, in Windows, we don't particularly need to worry about any of these as there is no application life cycle as such.

It is likely that you will have taken advantage of the Launching event to initialize your game, however, so it is important that its event still fires when running under Windows so that the initialization still completes properly.

Instead of setting up the event handlers, the GameHost class constructor simply calls into the virtual GameLaunching function when running under Windows. This is the same path that a newly launched game would take on the phone, resulting in the same startup behavior.

All the rest of the life cycle code can be excluded from this class as it is not needed in Windows.

8.3. High Scores

A small and simple change is required to the HighScores class to instruct it to read and write its score data to a file using the System.IO namespace instead of using isolated storage. As the class already stores its content in an XML document, no additional modifications are necessary.

8.4. Everything Else

There are no other changes required to the game framework. The rest of the project works identically in both environments.

The biggest changes that you will find you need to make when getting your games running for Windows will almost certainly be in the area of the organization of your display (taking the Windows display orientation and screen resolutions into account) and input (using Mouse and Keyboard instead of TouchPanel). You should find that the rest of your game will work as expected without any changes being required.

Other -----------------
- Windows Phone 8 : Developing for the Phone - The Phone Experience (part 4) - Understanding Idle Detection, The Tilt Effect
- Windows Phone 8 : Developing for the Phone - The Phone Experience (part 3) - Application Client Area, Application Bar
- Windows Phone 8 : Developing for the Phone - The Phone Experience (part 2) - Designing for Touch
- Windows Phone 8 : Developing for the Phone - The Phone Experience (part 1) - Orientation
- Windows Phone 8 : Developing for the Phone - Application Lifecycle (part 3) - Tombstoning
- Windows Phone 8 : Developing for the Phone - Application Lifecycle (part 2) - Navigation
- Windows Phone 8 : Developing for the Phone - Application Lifecycle (part 1)
- Windows Phone 8 : Designing for the Phone - Implementing the Look and Feel of the Phone
- Windows Phone 8 : Designing for the Phone - Designing with Visual Studio
- Windows Phone 7 : 3D Game Development (part 4) - Rendering 3D Models
- First look: Apple Watch

- 10 Amazing Tools You Should Be Using with Dropbox
- How to create your first Swimlane Diagram or Cross-Functional Flowchart Diagram by using Microsoft Visio 2010 (Part 1)

- How to create your first Swimlane Diagram or Cross-Functional Flowchart Diagram by using Microsoft Visio 2010 (Part 2)

- How to create your first Swimlane Diagram or Cross-Functional Flowchart Diagram by using Microsoft Visio 2010 (Part 3)
Popular tags
Microsoft Access Microsoft Excel Microsoft OneNote Microsoft PowerPoint Microsoft Project Microsoft Visio Microsoft Word Active Directory Biztalk Exchange Server Microsoft LynC Server Microsoft Dynamic Sharepoint Sql Server Windows Server 2008 Windows Server 2012 Windows 7 Windows 8 Adobe Indesign Adobe Flash Professional Dreamweaver Adobe Illustrator Adobe After Effects Adobe Photoshop Adobe Fireworks Adobe Flash Catalyst Corel Painter X CorelDRAW X5 CorelDraw 10 QuarkXPress 8 windows Phone 7 windows Phone 8 BlackBerry Android Ipad Iphone iOS
Popular keywords
HOW TO Swimlane in Visio Visio sort key Pen and Touch Creating groups in Windows Server Raid in Windows Server Exchange 2010 maintenance Exchange server mail enabled groups Debugging Tools Collaborating
Top 10
- Microsoft Excel : How to Use the VLookUp Function
- Fix and Tweak Graphics and Video (part 3) : How to Fix : My Screen Is Sluggish - Adjust Hardware Acceleration
- Fix and Tweak Graphics and Video (part 2) : How to Fix : Text on My Screen Is Too Small
- Fix and Tweak Graphics and Video (part 1) : How to Fix : Adjust the Resolution
- Windows Phone 8 Apps : Camera (part 4) - Adjusting Video Settings, Using the Video Light
- Windows Phone 8 Apps : Camera (part 3) - Using the Front Camera, Activating Video Mode
- Windows Phone 8 Apps : Camera (part 2) - Controlling the Camera’s Flash, Changing the Camera’s Behavior with Lenses
- Windows Phone 8 Apps : Camera (part 1) - Adjusting Photo Settings
- MDT's Client Wizard : Package Properties
- MDT's Client Wizard : Driver Properties
Windows XP
Windows Vista
Windows 7
Windows Azure
Windows Server
Windows Phone
2015 Camaro