Building a Cross Platform 2D Game with MonoGame (Part 1)

March 12, 2015


Ever since Microsoft ditched the XNA framework (for whatever reason), it didn’t provide any viable alternative for .NET developers. Microsoft attempted to encourage developers to switch to native DirectX to do game development (and other apps that would otherwise benefit from XNA).

But DirectX is not a real alternative “out of the box” for .NET (and even C++) developers; DirectX is very low-level, and it’s almost impractical to create a full-fledged game with DirectX directly; DirectX is a great base for game engines. For writing an actual game, developers typically use some framework that sits on top of DirectX.

In any case – using native C++ to work with DirectX for .NET developers is too painful and too difficult to be a viable option.

Several .NET libraries were created to fill the void. SharpDX is one that provides a thin wrapper over the native DirectX interfaces. Although it does provide a “toolkit” with some higher level abstractions, I still consider it as being too low level.

MonoGame is an interesting port of the XNA framework API for creating apps/games on Windows and even non-Windows systems. It uses SharpDX as its lower layer, but exposes practically the same XNA API that we know and love.

A few years back I did a 14-part post series on 2D game development with XNA. I want to do a similar series (although much shorter!) for MonoGame, creating a simple, yet pretty complete 2D game, while showing some of the differences from classic XNA. MonoGame is cross platform, and works on Windows desktop, Windows store, Windows phone, Linux, iOS, Android (the latter three thanks to the Mono platform) and a few others.

MonoGame implements the XNA 3D API as well, but I will not discuss 3D games in this series. Also, note that there are other libraries that use MonoGame and SharpDX such as Cocos2d-XNA, a port of the popular Cocos2D iOS game library, which is interesting as well, but will not be discussed here.

Installing MonoGame

I assume you’ll be using Visual Studio 2013 with Update 4 (or later) if you want to follow along.

Installing MonoGame for use with Visual Studio is a simple enough process. Just go to the MonoGame download page and download MonoGame for Visual Studio. Run the installer and you’re good to go. Opening Visual Studio shows a MonoGame node under Visual C# with several project options:


As can be seen from the screenshot, there are many projects to choose from, certainly not just Windows.

For the purpose of this series, I’ll go for the Universal project, targeting Windows 8.1 and Windows Phone 8.1. The idea behind all these projects is that most of the code and all assets can be shared, with code differences in app startup and such. So adding another game based on (say) Android shouldn’t be difficult. Most of the files just need to be added (as links) to the Android project.

Let’s create a Universal game project named Invaders, which will NOT be a space invaders clone, but I thought I’d make something more like a Galaxian style game.

Once OK is clicked we’ll get the following solution view:


We can see the standard projects for Windows 8.1 and Windows Phone 8.1 along with the “Shared” project, where most of our code will go. Currently, the main page for the game, the application class, and the Game class.

The Page and the Game

The GamePage.xaml file seems to be the main window for the game, but it has a twist. Its type is not based on the Page class, but rather on SwapChainBackgroundPanel (which derives from Grid). This class is essentially the interop layer to the underlying DirectX surface (managed by the lower SharpDX layer). Since this is an element like any other, we have the nice option of mixing traditional XAML and DirectX content. For example, showing the player’s score, level, lives, etc. can be done more easily with XAML (although MonoGame can display text).

Note that the recommendation is to use the newer SwapChainPanel rather SwapChainBackgroundPanel (it has fewer restrictions, such as being able to appear anywhere in the visual tree), but MonoGame has not yet been updated to use SwapChainPanel.

The GamePage constructor has a single line of interesting code that creates the Game object and sores it in an instance field:

_game = XamlGame<Game1>.Create(launchArguments, Window.Current.CoreWindow, this);

The Game class itself is the more interesting stuff and should look familiar to XNA developers. The most important methods are Update and Draw. Both are called for every frame – Update should execute the game logic, while Draw should – well – draw the scene. The code generated by the wizard has an empty Update method but the Draw method draws and rotates a 3D cube, which can view by running the application. We’ll remove most of this code in the next part.

The game assets

One essential part in any game is the various assets (textures, 3D model, audio files, etc.). In XNA this was dealt with something known as the content pipeline, where various file types had “processors” that converted them to a format the ContentManager in XNA knows how to load.

In the solution tree there is an “Assets” folder, but this is not what we want. This one contains the icons related to the tile of the app, which is a standard component of every Store app. The game’s real assets are under the “Content” folder. There is a single file there called Content.mgcb. This file is actually textual (and linked to a single file under the “Shared” project) that describes the various assets. These assets should reside in the same folder (and subfolders if desired) starting at the location of the Content.mgcb file.

Double-clicking the file in Solution Explorer will probably open a textual view of the file. But MonoGame provides a graphical tool to more easily manage the assets that should be processed by the tool to prepare them for usage by the MonoGame engine. To get this tool to automatically open with these kinds of files, right-click the file in Solution Explorer and select “Edit With…”. You’ll be presented with the following dialog. Select the “Pipeline” option and set it to be the default:


Clicking OK will open the MonoGame Pipeline tool (which by the way also opens automatically if that file is clicked in Windows Explorer):


There are currently no game assets, but we’ll start adding some in the next part of the series and see how to load and use them.

That’s it for part 1, see you in part 2!

Add comment
facebook linkedin twitter email

Leave a Reply

Your email address will not be published.

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>



  1. Pingback: Building a Cross Platform Game with MonoGame – Part 2 | Pavel's Blog

  2. damianJuly 26, 2015 ב 09:18

    so would I be able to use the SwapChainPanel and the something equivalent to System.Windows.Markup ( to load an XAML canvas with vector assets like paths and curves) at runtime, on say Android or iOS? . My game does not use sprite assets, it generates those form Vector graphics and it can have deep zooming. like Flash, Silverlight.

    I mean if I target only Universal app for windows 8.1 I dont need Xamarin at all..

    im now using Silverlight but may want to see my XAML assets run on Android or iOS..