Windows 8 Project Types

There are currently three methods in MonoGame for creating an Windows 8 application.

GameFrameworkViewSource

This method was the first one developed. It works like this...

static void Main()
{
   var factory = new MonoGame.Framework.GameFrameworkViewSource<MyGameClass>();
   Windows.ApplicationModel.Core.CoreApplication.Run(factory);
}

... this works very similar to how initialization is done on XNA for Windows or Xbox. The main trouble with this technique is it creates its own WinRT application framework which cannot host XAML content. XAML support is required for using the software keyboard and Microsoft Advertising.

The Silverlight Method

This next method was created to get XAML support via mimicking how XNA+Silverlight apps work on WP7. It is a more low level technique which has the user create a SharedGraphicsDeviceManager and GameTimer objects...

_manager = SharedGraphicsDeviceManager();
_manager.PreferredBackBufferWidth = (int)((XamlSwapChainPanel.Width * (dpi / 96.0)) + 0.5);
_manager.PreferredBackBufferHeight = (int)((XamlSwapChainPanel.Height * (dpi / 96.0)) + 0.5);
_manager.SwapChainPanel = XamlSwapChainPanel;
_manager.ApplyChanges();

_timer = new GameTimer();
_timer.UpdateInterval = TimeSpan.Zero;
_timer.Update += (o, a) => Update(new GameTime(a.TotalTime, a.ElapsedTime));
_timer.Draw += (o, a) => Draw(new GameTime(a.TotalTime, a.ElapsedTime));
_timer.Start();

While this method is what some Windows Phone 7 developers have used it suffers from one major flaw... you lose use of the Game and GameComponent classes.

At first this doesn't seem like a big loss... but soon you realize it is a huge one. You will find all sorts of 3rd-party XNA libraries that depend on GameComponent or Game which you either need to modify or rewrite. Worse the Game class provided major abstractions to platform specific events and state which becomes a huge burden when targeting multiple platforms.

XamlGame

This new method in this pull request offers the best of both techniques. You get the Game classes as well as use of XAML. The usage is very simple...

_game = XamlGame<MyGameClass>.Create(launchArguments, coreWindow, swapChainBackgroundPanel);

... this code typically goes into your App.xaml.cs or your main GamePanel classes.

You can freely call into your Game class from XAML code or have your Game class call XAML code itself. You can use all the normal Game class features and events like Game.Window.ClientSizeChanged, Game.Content, Game.IsMouseVisible, etc.

We stopped short of supporting more esoteric scenarios like multiple Game classes in one XAML app or changing the SwapChainBackgroundPanel during gameplay. If we find users have a need for more flexibility it can be added in a later release of MonoGame.

The 3-Way

While we should strive to keep down complexity, we are currently keeping all three techniques. Not only would it be disruptive to people shipping games for Windows 8 launch to remove any of them, but really depending on your goals you might want one over another.

Later we will evaluate the usage of the different methods and either find ways to merge functionality or remove one or more of them.

To-dos

There are a few things we still need to do related to these changes:

• Fill out this document a bit more once people have experience is using all three project types.
• We need to implement VS2012 templates for the Silverlight-style method.
• Need to port some samples to use these techniques.