XNA to MonoGame and beyond
As part of a new “Back to basics” series which extends on my original XNA Futures article some months ago, I am going to cover all the options I explained back then in more detail plus probably a few others which have come to light recently.
All of this is to show developers who have worked tirelessly on their XNA projects and newbies currently learning XNA as a gateway to game development that the knowledge they have gained will still stead them fast going forward.
Microsoft has still yet (*at time of writing with build around the corner) to make any announcement regarding XNA, it is still fully supported but we are unlikely to see any updates / fixes to it in the near / distant future.
I have had many calls to get off XNA and jump onto platform X, which I take on board but I am still a man of many hats, so I will still be looking into all those platforms and journaling the experienced coming from my XNA background, options, options, options.
So first out of the gate is MonoGame, This article will mainly focus on the new Windows 8 improvements but everything here should be applicable for other platforms as well (except the XAML stuff 
)
Background
MonoGame is an Open Source implementation of the Microsoft XNA 4 Framework. Its goal is to allow XNA developers on Xbox 360, Windows & Windows Phone to port their games to the iOS, Android, Mac OS X, Linux and Windows 8 Metro. They are also hoping to open up several other platforms in the future including PlayStation mobile.
Behind the scenes, MonoGame uses several other open source projects to deliver on this objective including:
- OpenTK – A OpenGL/CL/AL wrapper for low level graphics
- SharpDX – A Direct X wrapper for access to Direct3D/2D, audio and input
- LidGren – A Network library with facilities for UDP and TCP communications
As more contributors come on board I would expect this list to grow over time offering more out of the box solutions become available, I personally would like to see some easy Box2D or Bepu Physics options but there are already XNA implementations of those which are readily available.
MonoGame just released version 3.0 of its framework as a Beta which now offers full Windows 8 support.
Out of the Box
Inside we find the customary “Game1” class and from there it is like XNA never left the building, all you need to do is add content and off you go, to get your content in there are a couple of options:
- Create the “Content” folder structure in your project and add the XNB files as “Linked” references
- Manually copy the “Content” folder from your build project into the build folder in the subfolder of AppX. (e.g. “\MonoGameTest1\MonoGameTest1\bin\Debug\AppX” )
- Use a Post build process to copy the content at build time
Personally I do not like this “Copy” approach as you have no management / visibility of your assets plus if you clean up your project (delete the bin/obj) folders you will have to keep repeating this process over again AND every time you rebuild/change your assets.
The Post Process approach (suggested by the Sickhead Games team) is a good balanced approach, creating commands along the lines of the following:
rmdir /S /Q ..\Game\Content
xcopy $(TargetDir)\Content*.* ..\Game\Content\ /E /F /Y /V
Then call it as part of your post process build routing in your project settings (right click your project and select properties):
Additionally what the Sickhead guys do is manually edit the games “csproj” file and add the following line to ensure the content is included at build time:
<Content Include=”Content***.*”>
<CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
</Content>
So using option 2 you are keeping a clear separation between your content builds and you code builds
Option 1, in my view is a lot cleaner, however there are a few points to keep in mind:
- You need to create the base “Content” folder manually at first, just call it Content
*Example Structure
- The Folder structure needs to mimic your content projects folder structure exactly
- Only LINK your assets do not just add them, else when you rebuild your content it wo not be updated in your game
*Add XNB files as “Existing Items” as Links
- You need to set the “Build Action” of all your linked assets as “ CONTENT ”, this will ensure they are copied to the deployment folder when the project is run.
*Linked assets with “Build Action” set to “Content”
**Note, you do not have to change the “CopyTo” options for the assets, setting the build action s enough, changing the “CopyTo” option only copies the assets to the Build folder and not the APPX folder where they will be needed!!
MonoGame for Windows 8 XAML
MonoGame would be complete without a reference to the Awesome Guys over at Sickhead Games and their title “ARMED”, most do not know that they are the Main contributors to the Windows 8 branch of MonoGame!
So as I mentioned before this second variant of MonoGame is almost exactly the same as the Silverlight XNA integration (SilverXNA) on Windows Phone with only a few differences.
You can add XAML elements to your game pages and use data binding to manage them, use XAML for menus with 3D backgrounds, the list goes on. Only real difference I’ve seen is that you do not need to paint the XAML rendering, it is automatically on top, granted this may mean you might not be able to do any fancy like having post-processing on the XAML page (may be possible just not sure at this stage)
**Note
A word to the wise though is that the more XAML elements that you add to the page will have a downturn effect on 3D and general game performance because there are two separate graphics processes at work competing for time.
The advice from the MonoGame team guys is that you should use the XAML rendering for menus and other screens and only and use XAML elements in your main game view sparingly.
The other main difference which should be obvious is the project structure:
The project now has an “App.XAML” and “GamePage.XAML”. The “App.XAML” has been configured to act pretty much the same way the Basic MonoGame project works by instantiating the Game properly.
The “Game.XAML” is just an empty SwapChainBackgroundPanel (a Core element of the C++ XAML game projects):
As with the SilverXNA projects of the past all the XNA Graphics are run from the code behind and you are free to add XAML elements as you wish, only real difference is that they are ON by default. (Well unless you hide them)
The code behind just instantiates the “Game” class as usual and from there (again) XNA is back in the forefront but now can separate core game graphics from that pesky UI stuff.
I have also seen chatter about removing the “Game” class all together in this XAML version, not sure what the benefit of doing that would be at this point (unless it is old news) but it is also the route the Sickhead guys and other projects have taken so there may be some merit in it.
Core differences
MonoGame from my 3D starter tutorial.
They BOTH took a whopping 5 minutes each to port over with NO ISSUE (ok maybe 6, I did need a bite of pizza while the content is built), this just shows the power and flexibility of MonoGame as well as its 99% compatibility to XNA (I say 99% because it is still in beta and a few features are not 100% implemented and there are a few minor bugs which the team are actively working on)
With Titles such as “ARMED” and others there is certainly a lot to sell the MonoGame proposition at present.
Have fun XNA’ing