Introduction
Invasion is an open-source, 2D casual shooter game that has been around for almost 12 years. In July 2011, I ported Invasion from Managed-DirectX for Windows to XNA for Windows Phone 7. The latest version targeting WP7 runs just fine on Windows Phone 8, but the WP7 code won't build with VS2012 and the WP8 SDK because Microsoft doesn't support XNA development with them. So it is time to port Invasion once again and while I considered porting it to DirectX, Unity, or Cocos2d-X, I instead chose to first give MonoGame a try, because its API is closest to XNA's.
MonoGame is still in development and you have to keep that in mind when porting your game. Some XNA APIs are missing, others are quirky, and one class is rather problematic. But if you can work around those issues, MonoGame is a good option for porting your XNA WP7 games to WP8 and for building cross-platform games in general. This article explains what I did to port Invasion to MonoGame for WP8, what's changed in this version of the Invasion, and what still needs work - both in Invasion and MonoGame. I hope this article and the source code will help other developers more easily port their XNA/WP7 games to MonoGame/WP8 and get started creating new games with MonoGame for Windows Phone.
Please remember to rate this article and if you Install Invasion from the Windows Phone Store, please Rate & Review Invasion there too - Thanks!
Background
In January 2002, Mauricio Ritter posted his "Invasion" UFO-shooter 2D game on CodeProject. It was originally written in C++/DirectX 6 and he ported it to DirectX 7 (using DirectDraw) for his CodeProject article. In 2003, Steve Maier ported Invasion to C# and Managed DirectX, the managed game SDK which Microsoft would cancel in 2005. Both of these legacy versions of Invasion ran on Windows XP.
In 2011, I ported Invasion to Windows Phone 7 with XNA 4 and wrote my first CodeProject article in hope of helping others wishing to begin XNA game development for Windows Phone. Since publishing the game and that article, Invasion has been downloaded over 8,000 times on the Windows Phone Store, the article has been viewed 38,143 times, and the source code 5,157 times.
The CodeProject articles for those first three versions of Invasion are linked below:
In 2012 Microsoft stopped XNA development, disbanded the XNA team, and released both Windows Phone 8 and Windows 8 without an XNA roadmap. Devs could still target the Windows Phone 7 SDK with XNA and run those apps on WP8, but XNA couldn't use the new WP8 SDK APIs or publish XNA games to the Windows Store. Despite it being a favorite of Indie Game Developers for creating WP7 and Xbox 360 games, it seems that Microsoft has been quietly killing off XNA.
Fortunately, the MonoGame Team is single-handedly keeping XNA alive - adhering to nearly all of XNA's APIs and expanding its reach by making it open-source & cross-platform.
MonoGame can target Windows Phone 8, Windows 8, iOS, Android, PS Vita, and other operating systems! MonoGame integrates with Visual Studio 2010/2012, MonoDevelop 3.0, and Xamarin Studio. In this article, only MonoGame for Visual Studio 2012 is discussed.
Using the Code
Invasion 1.8 was created with the Windows Phone 8 SDK, MonoGame 3.0.1 SDK, and a small patch that I made to MonoGame's gesture-processing code. You will need that software, along with Visual Studio 2012, installed in order to build and run the source code accompanying this article.
To port your own games from VS2010/WP7/XNA to VS2012/WP8/MonoGame, you will want to keep your VS2010/WP7/XNA development environment intact, because you will need it to create XNB and WMA formatted Content files that are used by MonoGame. The "Getting Started with MonoGame for WP8" section below provides a list of links to software that you should install before starting game development with MonoGame.
Getting Started with MonoGame for WP8 Game Dev
These are the steps that I followed to start porting Invasion to MonoGame. All referenced software is hyperlinked to where you can download/purchase it if needed.
- Install Windows 8 Pro (or Windows 8.1 Pro)
- Install Visual Studio 2010 with latest Service Pack, Windows Phone 7.1 SDK, Windows Phone 7.8 SDK, and any other SDKs (e.g. pubCenter Advertising SDK, AdDuplex, and AdRotator) that you need to build your current XNA game.
Please note that XNA Game Studio 4 for WP7.1 is included in the Windows Phone 7.1 SDK and you will need it to create the .xnb files for graphics, sound-effects, music, and fonts that will be used in your MonoGame projects.
- Install Visual Studio 2012 with the latest Service Pack, the Windows Phone 8 SDK, which now includes Microsoft's Advertising SDK, and the Windows Phone 8 SDK Update.
- Install the MonoGame 3.0.1 SDK for Visual Studio 2010/2012 from CodePlex.com.
- Install Paint.net and the XNB plug-in for Paint.net from CodePlex. This lets you edit uncompressed XNB files and save them as PNG files, which XNA Game Studio 4 can then build back into XNB files.
- Install Audacity for converting the format of SoundEffects to one that MonoGame can play.
- Copy the MonoGame solution template and sample game from Marios Karagiannis to a new folder. Build and run the jumping Monster demo that's included to verify that it works. Then strip out the Monster demo code from the sample and rename the solution and project names as desired.
Alternatively, you could create a new MonoGame solution from a template in VS2012 that was installed with the MonoGame SDK in step 4.
- Update the fields in Assembly.cs and WMAppManifest.xml with your data and change the App.xaml and GamePage.xaml files.
- Apply My Patch for MonoGame's TouchPanel Gesture Processing code.
- Create any folders in Visual Studio's solution explorer that are needed by your project and copy your code and content files into them.
You will notice that I did not recommend "going to github and cloning the latest MonoGame and SharpDX repositories" above, and that was intentional. Unless you are familiar with github and MonoGame and want to help develop the MonoGame SDK, I really don't suggest doing that. I originally started there and wasted a lot of time because of that choice.
Porting Notes
This section explains code and content changes that will be needed in order to port an XNA/WP7 game to MonoGame for WP8.
Game Project Properties
In the Visual Studio 2012 (VS2012) Solution Explorer panel, right-click the game project name, open the Properties page and select Application from the menu on the left side of the page. This will allow you to change the default namespace, Assembly info, .xap filename, Startup object, and supported cultures. Note that if you game's namespace or class name later, you will need to return here to update the Startup object.
WMAppManifest.xml File
The WMAppManifest.xml file will open in designer view, so you no longer need to edit the XML code directly. I normally use VS2012 with the Dark theme (settable from Tools/Options/Environment/General), but the WMAppManifest.xml file is best viewed with the Light theme because VS2012 has a bug where it doesn't show checkboxes correctly with the Dark Theme. In the Application UI tab, make sure you have checked all three screen resolutions, checked "Support for large Tiles", and set the App Tile images.
Note that the Textbox just below "Support for large Tiles" is the "Tile Title" name. If you don't want a Tile Title to display on your game's app-tile when it's pinned to the phone's Start Screen, then clear this textbox.
Use the Capabilities tab to set ID_CAP_MEDIALIB_AUDIO & ID_CAP_MEDIALIB_PLAYBACK if your game plays music, ID_CAP_NETWORKING if it connects to the Internet for any reason (to show ads, display the Windows Phone Store review page, etc.), ID_CAP_SENSORS if it uses the accelerometer, and ID_CAP_WEBBROWSERCOMPONENT if it launches a browser.
Use the Requirements tab to indicate any phone-optional devices that are *required* by your game (e.g. NFC, cameras, gyroscope, magnetometer). Only check these devices if they are in fact required, because the Windows Phone Store will not show your app on phones that don't have the required hardware.
App.xaml
MonoGame is like a hybrid Silverlight+XNA game - it uses XAML to host your XNA game. Because of this, XNA's Program.cs file gets replaced by App.xaml and App.xaml.cs and it also contains App event-handlers (e.g. App Activated/Deactivated) and Properties (e.g. disabling UserIdleDetectionMode) that XNA devs would normally find in their XNA Game class. If you change your game's namespace, you will want to insure that the "Application x:Class" tag is set accordingly at the top of the App.xaml file.
GamePage.xaml
GamePage.xaml file is the XAML page that specifies the UI layout and orientation of your game screens and the Drawing Surface element that will display your game. The related partial GamePage class in the GamePage.xaml.cs will contain your game class object. In the GamePage.xaml file:
- Similar to the App.xaml file, insure that GamePage.xaml's "
phone:PhoneApplicationPage x:Class" tag's value specifies the correct namespace for your GamePage class.
- Set the
shell:SystemTray.IsVisible to "False" to prevent the system tray from obscuring your game screen.
- Set the
SupportedOrientations and Orientation elements to either "Portrait" or "Landscape" and note that MonoGame 3.0 does not yet support "PortraitOrLandscape" for these fields.
- Set up the drawing surface (more on this topic below).
The Drawing Surface
There are two choices for creating a drawing surface on GamePage.xaml's phone:PhoneApplicationPage:
DrawingSurface DrawingSurfaceBackgroundGrid
To simplify this choice, consider them "the easy way" and "the harder way" respectively. As a general rule, you should always choose the easy way unless there's a good enough reason not to.
With DrawingSurface, you can quickly set up scaling & translation transforms on the drawing surface to fit your game to any screen-size and then easily use existing WP7 XNA game code to draw on and receive touch-input from those screens without rewriting code or translating each referenced point in software.
DrawingSurfaceBackgroundGrid is the harder way. Set a scale or translation transform on a DrawingSurfaceBackgroundGrid and it will have no effect (as of MonoGame 3.0.1). So you will need to find another way to scale the screen to other phone resolutions and separately translate touch-points to their scaled screen positions. Someone probably has code to help you do that, but that's beyond the scope of this article.
When I first started using DrawingSurface for the Invasion port, some devs who were using DrawingSurfaceBackgroundGrid warned me that DrawingSurface was not as performant as DrawingSurfaceBackgroundGrid - and that's true - DrawingSurface is estimated to be 5% to 7% slower. But I stuck with DrawingSurface and I'm glad that I did, because it has more than adequate performance for my 2.5D Invasion game. Even on Invasion's Level 3, where there are about 30 UFOs spinning, the Starship flying, lasers & photons firing, and explosions happening simultaneously all over the screen, DrawingSurface still pumps out 30-fps on my device.
So it's a tradeoff of performance for convenience, and unless your are doing highly intensive 3D rendering and require "pedal-to-the-metal" speed, I suggest choosing convenience and going with DrawingSurface. You can read more about this topic on StackOverflow.
To use DrawingSurface in Invasion, I replaced Marios' Monster sample's DrawingSurfaceBackgroundGrid code-block with the following Grid and DrawingSurface.
<Grid x:Name="LayoutRoot">
<MediaElement/>
<DrawingSurface x:Name="XnaSurface"/>
</Grid>
Auto-Scaling WVGA Games to WXGA and 720P Screen Resolutions
WP7 phone screens have WVGA screen resolutions (800x480). XNA games built for WP7, when run on WP8 devices, run fine on WVGA phones and will automatically scale to fill 720P (1280x720) and WXGA (1280x768) phone screens. When porting these WVGA games to MonoGame for WP8, we need to scale the drawing surface to fit larger screen sizes ourselves. Fortunately, doing this with
DrawingSurface is very easy, and I blogged about "
Auto-Scaling WVGA Games to WXGA and 720P Screen Resolutions" in July and
summarized it with code snippets on Nokia's Developer Wiki.
Using the method provided there, the screen will auto-scale full-screen on WXGA devices (because WXGA and WVGA both have a 1.667 aspect-ratio), and scale to 1200x720 with "black-bar" letterboxing on either side of the centered viewport (This is done to maintain the 1.667 WVGA aspect-ratio because 720P's aspect-ratio is 1.778). This method not only properly scales the screen graphics, it also scales and translates the touch-points. Easy peasy!
In the Invasion game, screen auto-scaling is implemented in InvasionGame.cs's InvasionGame.SetupScreenAutoScaling() function. Note that there are limitations to this implementation. I purposefully designed this solution to auto-scale "up" from WVGA to higher resolutions - very useful for porting games from WP7 to WP8. But if you're creating a new WP8 game with MonoGame and want to start with WXGA and scale down to 720P and WVGA, you'll need to tweak some code. Ideally, I should have written this code to handle auto-scaling up and down, and if you are so inclined to do that, feel free to send me your code and I'll appreciatively include it here and give you full credit.
Handling Screen Orientation Changes
Whereas XNA defaults games to Landscape orientation, MonoGame defaults them to Portrait. To create a game in Landscape orientation, you must:
- In GamePage.xaml, set these
phone:PhoneApplicationPage elements:
SupportedOrientations="Landscape" Orientation="Landscape"
- Handle the
GamePage.OnOrientationChanged event:
static internal PageOrientation PageOrientation = PageOrientation.Portrait;
protected override void OnOrientationChanged(OrientationChangedEventArgs e) {
PageOrientation = e.Orientation;
base.OnOrientationChanged(e);
}
- Use
GamePage.PageOrientation instead of DisplayOrientation:
Because the screen automatically rotates between LandscapeLeft and LandscapeRight orientations, it may seem as if the game shouldn't need to handle OnOrientationChanged because the screen size remains unchanged, but Invasion needs the DisplayOrientation in order to properly handle accelerometer input direction.
Game Content
In XNA, your game solution's Content Project is used to build your content (graphics, sound effects, fonts, and music) into a library of .xnb formatted files that XNA understands how to process. So while you put .png, .wav, .spritefont, and .mp3 files into this Content project, the XNA Content Pipeline converts them into the .xnb format in the Build process, which XNA then uses at runtime.
At the time of this writing, MonoGame 3.0 does not have a Content Pipeline, although a content pipeline is currently in development. Because of this, the simple workaround for getting your XNA game's content into your MonoGame project is to build your existing XNA game with Visual Studio 2010 and the WP7 SDK. That will produce the .xnb files that MonoGame will use. For new MonoGame projects, you will need to create a VS2010 WP7 project just to build your Content into .xnb files.
Unlike XNA game solutions, in MonoGame there is no need to create another Visual Studio project for your game's content. Instead, create a folder called "Content" and put your .xnb files in it. Organize the content into subfolders if you wish, just like you would do with XNA.
Playing Legacy SoundEffects
When I first started porting Invasion to MonoGame, I found that it was unable to play most of the SoundEffects from the "Invasion with XNA for WP7" project. In order to get them to play, I used Audacity to reformat them and blogged about this in my "Getting Legacy DirectX & XNA SoundEffects to Play in MonoGame for WP8" article.
Playing Music
MonoGame will play your existing XNA game's music files, but you have to set up the music files a little differently in MonoGame. In XNA, you put your .mp3 music file in your Content folder and the content pipeline converted it into two files - a .xnb file and a .wma file. In MonoGame, you simply replace the .mp3 file in your Content folder with both of these files. The .xnb file internally references the .wma file to be loaded, so be sure to include both of them.
Note that there is currently a MediaPlayer bug in MonoGame in which the MediaPlayer object is not properly initialized when the game is started if the user is currently playing music and this prevents the game from stopping the user's music. Windows Phone Store requires that if the user is playing music when the game starts, the game should ask the user if it's OK to stop the playing music in order to let the game play its own music. With this bug, your game can query the user, but it won't be able to stop the music when the user says that it may. This bug has been reported to the MonoGame project team on Github here: https://github.com/mono/MonoGame/issues/2075[^]
MonoGame's MediaPlayer bug could cause games that play background music to fail Microsoft's certification testing and so it needs to be resolved ASAP. One way around this may be to use Microsoft's real Microsoft.Xna.Framework.Media library in your WP8 game. Microsoft allows this scenario, as pointed out here: http://msdn.microsoft.com/en-us/library/windowsphone/develop/jj207003(v=vs.105).aspx[^].
Vibration API Difference
MonoGame supports the Microsoft.Devices.VibrateController to vibrate the phone for some period of time, but it doesn't implement the Microsoft.Xna.Framework.Input.GamePad.SetVibration function for adjusting the vibration intensity. So while the XNA version of Invasion vibrated the phone when the player's StarShip was hit by a UFO's photon torpedo and adjusted the vibration intensity based on the amount of StarShip shield damage, the MonoGame version of Invasion still vibrates the phone but the intensity is not based on shield damage. The missing API was reported to the MonoGame project team on Github here: https://github.com/mono/MonoGame/issues/2079[^]
MonoGame's Gesture Processing Bugs
The reason that I didn't release Invasion v1.8 earlier this year, even though I had already ported the game to MonoGame, was because of a nasty bug in MonoGame's gesture processing code. While many other devs told me that their ported games were working fine and they had published them on the WP Store already, Invasion was behaving very badly under MonoGame - sometimes:
- Not allowing any further taps or other gestures to be processed
- Locking up the game's UI and not restarting properly after this happened
- Locking up the Windows Phone OS, not responding to reboots, & requiring a battery pull
I have seen #1 and #2 occur while in the debugger. #1 is easily repeatable and #2 happens less frequently. #3 happened to me only twice this summer and I fortunately was using a Lumia 620 as a test device which allowed me to easily pop open the case and pull the battery. If I had been using a phone that can't be opened, it would not have been a good day! I have never seen any of these problems happen with the XNA/WP7 version of the game.
So, why did Invasion expose this problem when other games didn't? I don't really know, but it could be that Invasion was using gestures for Taps, Horizontal Drags, Flicks, and Holds, whereas these other games only were using Taps, or weren't using gestures at all - for example, using raw Touch input to handle taps. It could also be that Invasion's ScreenManager and Input State Management aren't exactly the greatest examples of how to implement these things - and that was contributing to the problem.
I have reported this problem to the MonoGame project team on Github here: https://github.com/mono/MonoGame/issues/2076[^]
There is another place in TouchPanel.cs where a messed-up TouchPanel state causes Tap gesture events to not be processed. I believe this only occurs when other gestures are configured as well, such as Flicks, Holds, and HorizontalDrags. But because I wasn't able to find a workable patch for that, I decided to stop using gestures to handle Taps on the Gameplay Screen, and instead use raw Touch input. Invasion v1.8 no longer uses the Hold gesture - now only requiring HorizontalDrag and Flick gestures on the Gameplay Screen.
MonoGame's Gesture Processing Patches
Fortunately, I was able to make a small patch to MonoGame that apparently prevents the resulting bad-behaviors from occurring when MonoGame's gesture processing state gets messed up. So while it's a "patch", it shouldn't be considered a "fix", because it's just responding to the messed-up state rather than keeping the state from getting messed-up in the first place.
Patch 1: In TouchPanel.cs, change IsGestureAvailable to the following:
public static bool IsGestureAvailable {
get {
while (_gestureEvents.Count > 0) {
int count = _gestureEvents.Count;
var stateChanged = RefreshState(true, _gestureState, _gestureEvents);
UpdateGestures(stateChanged);
if (count == _gestureEvents.Count) {
TouchLocationState unprocdState = _gestureEvents[0].State;
if (_dragGestureStarted == GestureType.HorizontalDrag &&
unprocdState == TouchLocationState.Moved) {
}
else
_gestureEvents.RemoveAt(0);
}
}
return GestureList.Count > 0;
}
}
Nothing fancy there. I have found that sometimes gestures don't get processed, and if they're left on the List and never get processed, the while-loop goes infinite and the UI locks up. By removing items from the list that don't get processed, we get rid of the scenario where the loop becomes infinite. This patch isn't ideal, but it seems to work.
Patch 2: After applying Patch 1 to the Invasion 1.8 code, I noticed that another developer recommended a simpler patch that seemed to prevent MonoGame's TouchPanel State from becoming corrupted in the first place. This new patch is described here: https://github.com/nickdarnell/MonoGame/commit/84016f8c4c59d0fcf6b78d83bba6c7fa13ddc3d7[^]
The Problem with Patches 1 & 2: I liked the Patch 2 idea so much that I replaced Patch 1 with it in the Invasion 1.9 source code, but you should not consider either of these solutions a "fix" fro the problem. Patch 1 tries cleaning up the TouchPanel state after it gets messed up - not a good strategy. Patch 2 tries to prevent the state from getting messed up, but other devs have reported that this may not work in all cases. Also, because of slight differences between the behavior of Patch 2 with how XNA works, the MonoGame Team is still looking for a different "better XNA matching" solution to this problem, so this issue is far from being resolved.
Other Ideas: A game-dev told me today that Patch 2 isn't working for his game, so he's going to try using both patches together. But there is another solution that should be investigated because it solves all of these gesture processing problems on WP8: using the real Microsoft.Xna.Framework.Input.Touch software in MonoGame on WP8. Microsoft allows this scenario, as pointed out here: http://msdn.microsoft.com/en-us/library/windowsphone/develop/jj207003(v=vs.105).aspx[^].
Points of Interest
Pinning the Game to the Start Screen without a Tile Title
In XNA, removing the Tile Title from an App Tile on the Start Screen was rather tricky. Fortunately with XAML-based apps, such as MonoGame apps, removing the App's Tile Title is as easy as clearing the Tile Title textbox in the WMAppManifest.xml file.
Getting App Version # from WMAppManifest.xml
In some of my other apps, I get the version number for the Main Menu and About screens from the WMAppManifest.xml file. This eliminates the need to hardcode the version number in C#. Invasion v1.8 now does this too in the Invasion.cs LoadContent function, like this:
System.Version Version;
var version = System.Xml.Linq.XDocument.Load(
"WMAppManifest.xml").Root.Element("App").Attribute("Version");
if (version != null && !string.IsNullOrEmpty(version.Value))
Version.TryParse(version.Value, out Version);
else
Version = new Version("0.0.0.0");
Displaying a "Request Review" Message Box
Guide.BeginShowMessageBox can still be used to display message boxes in MonoGame, but with MonoGame, you can also display message boxes with System.Windows.MessageBox.Show, as any XAML-based app can. In the Invasion with MonoGame app, I have implemented messages boxes both ways in order to show you the difference in how they're called and what they can do.
One thing I like about Guide.BeginShowMessageBox is that you can specify the text on the buttons, so instead of being confined to "OK" and "Cancel", your buttons can say "Yes" and "No", or "Buy This Now!". You also don't have to worry about cross-thread UI exceptions when calling it.
System.Windows.MessageBox.Show has fewer parameters to fill in when calling it and that's good news if you just have a simple "OK" message box to pop-up. But it does restrict you to "OK" or "OK/Cancel" buttons and requires you to call it with Deployment.Current.Dispatcher.BeginInvoke, otherwise a cross-thread UI exception is thrown. For example:
Deployment.Current.Dispatcher.BeginInvoke(() => {
MessageBox.Show(
"Thanks for trying to Rate & Review Invasion, but your phone doesn't currently have " +
"an Internet connection. Please try again when your phone is online.",
"No Internet Connection", MessageBoxButton.OK);
});
Accelerometer Input
I haven't looked at the Accelerometer code in a while, but I am aware that the emulator's accelerometer input has no effect on the player's StarShip - and should! Fortunately, the accelerometer input works just fine when Invasion is run on a device.
Persistent Settings
Invasion v1.8 is the first version where the game's settings (scoreboard position, game music, difficulty level, and auto-select weapon) are persisted between runs. So if you prefer the scoreboard on the left side of the screen, or the music to be off, Invasion now remembers. Managing game settings like this is easy using IsolatedStorageSettings.ApplicationSettings from the System.IO.IsolatedStorage namespace. Find the implementation in the Settings.cs file.
Handling Unhandled Exceptions
In XNA for WP7, you could theoretically handle "unhandled exceptions", and sometimes it actually worked. Sometimes an XNA game could crash before you had a chance to set up the handler, but even when it did work, your game always was terminated. With XAML-based apps on WP8, I've noticed that the apps stay alive when App.Current.UnhandledException gets handled.
Building Your Game
Building and debugging your XNA game was very easy in VS2010. You chose whether to build a Release or Debug version and whether to target the Emulator or a Device, and when you hit F5, everything just worked. Emulator code was built targeting x86 and Device code was built targeting ARM - of course.
Unfortunately, that's not currently the case with MonoGame. Because of a build issue with a library that MonoGame uses (SharpDX), auto-selecting the target processor doesn't happen - so you need to open the Build's Configuration Manager and choose either ARM or x86 every time you switch between Device and Emulator. Because of a little bug in VS2012, you should change the target processor in Configuration Manager before selecting the target Device/Emulator, because VS2012 resets that field whenever the target processor changes.
Debugging
Debugging works just fine in the emulator, but debugging (with Debugger attached) on a device often degrades the performance of a MonoGame app until the game becomes unusable. It will be obvious when this happens - the frame rate will drop to 1 or 2 frames per second and touch-input won't get processed for many seconds, if at all. Some devs have said they can get this behavior to go away by deactivating the game (via Windows button) and re-entering it (with the Back button), but that hasn't worked for me.
Thoughts on MonoGame
MonoGame 3.0.1 is functional, but it's currently in development and there's still a lot of work to do on it. The MonoGame Team readily admits that they could use some help - so if you have the time, knowledge, and desire, please download the latest MonoGame bits from Github and get in touch with them. If you don't plan to help develop MonoGame though, then I suggest staying away from the MonoGame & SharpDX repositories and instead take the steps that are suggested in this article.
While most of MonoGame 3.0.1 seems very stable, I have serious concerns about the implementation and stability of MonoGame's TouchPanel class. My kludgey patch to prevent it from locking up the UI just goes to show that this class should be completely rewritten. That particular class is not "version 3" quality - it's beta-quality at best. Correctly re-implementing the TouchPanel class will not be a simple task and it is extremely important to get it right.
I believe that MonoGame will be successful and lasting in the end, but SDK progress seems to be going more slowly than I expected. The 3.0 Beta was released in October 2012 (1 year ago!), and the latest 3.0.1 stable-release arrived 7 months ago. I was really expecting a new stable release by now, but nobody really knows when it will come. To me, this looks like a resource problem - not enough funding or SDK developers to make it go faster.
Over these past 7 months, Microsoft has helped make Unity and Cocos2d-x SDKs available for Windows 8 and Windows Phone - a great strategy for bringing iOS and Android developers to Microsoft's mobile app platforms.
Microsoft could likewise help MonoGame progress at lightning speed if it took any proprietary code out of XNA and open-sourced the rest of it under MS-PL license on CodePlex. MonoGame could quickly implement a bulletproof TouchPanel class, full-featured Content Pipeline, and whatever else is still needed. XNA developers would sing Microsoft's praises once more! So, how about it Microsoft?
Looking forward, MonoGame's cross-platform goal has the potential to make XNA a bigger deal than it could have been under Microsoft's Microsoft-only approach. This is important for game developers who would much prefer to make a game once and be able to publish it on all popular platforms.
Game Changes in Invasion v1.8
Invasion 1.8 isn't just a straight port of the XNA version for Windows Phone 7.1. While I had the chance, I changed some things:
- "Options" are now called "Settings" and are preserved in isolated storage
- Settings Screen now has an on-screen "back" button
- Settings Screen now allows moving the Scoreboard position during game-play
- Tapping the new Settings-icon on the game-play screen navigates to Settings Screen
- Holding the Scoreboard during game-play no longer navigates to the Settings Screen - it was a bad idea (sorry!)
- Player gets more points for blasting UFOs!
- Added a "Rate & Review" message-box nag (sooner or later, we all need one)
- Main Menu now includes "RATE + REVIEW" instead of "EXIT"
- Replaced most of the Invasion solution's projects with simple folders
- Added all 3 sizes of App Tiles to WMAppManifest.xml (needed for submitting game to DVLUP)
- Made Red-UFO waves more challenging.
- Added wobble animations to represent UFO damage.
- Bug Fix: Accelerometer input is reversed for Landscape-Right screen orientation
- Bug Fix: Back button on Level Transition screen should open Pause Screen
- Bug Fix: Music plays even when Music Manager is disable
- Bug Fix: Many Update & Draw calls are happening twice, degrades performance.
- Bug Fix: Red UFOs accelerating when exiting left of screen.
Future Invasion Game Improvements
Here are some improvements that Invasion could use. If you'd like to help with any of them, please let me know.
- Better Screen Manager code
- High Scores (Local and/or Global)
- Ability to Save the Game & Load it later
- Accelerometer Input with the Emulator
- Shaped-Based Collision Detection
- Add UFO Artificial Intelligence & More Attack Strategies
- Use Content Pipeline when MonoGame gets one
- Let StarShip move up & down too
- Create higher-resolution UFOs, Starship, & Explosions
- Replace static background image with parallax starfield
- Add more weapons, bonus power-ups, and UFO types
- Fonts that would support Internationalization
Article History
- 1.0 (8-Oct-2013) - Initial Port from XNA/WP7 to MonoGame/WP8 (Invasion v1.8)
- 1.1 (14-Oct-2013) - Many bug fixes, cleaned up more code and improved variable names, made red-UFO waves more challenging in Medium & Hard difficulty levels, added wobble animations to represent damaged UFOs in waves 2+. Game code updated to v1.9.
