Subscribe to GameFromScratch on YouTube Support GameFromScratch on Patreon
14. June 2015


Welcome to a brand new series on covering the MonoGame open source game framework.  Over the next several chapters we will cover almost every factor of using MonoGame for game development.  First we are going to start with a bit of a history lesson and introduction to MonoGame; we’ll talk about where it came from and why you should care.  Don’t worry, we will get to the code and the technical bits very soon!


For the more visually inclined there is also an HD video version covering mostly the same material we will discuss here.


So what exactly is MonoGame?  The simple answer is, it’s a cross platform, open source implementation of the XNA game libraries.   XNA in turn was Microsoft’s indie focused 2D/3D game library.  A more complex answer than that requires a bit of a history lesson.


A Brief History of XNA


XNA stands for XNA’s Not Acronymed, a recursive algorithm and very much on vogue at the time (think GNU or WINE).  Although the more likely reason for the name is X’s were really just quite cool at the time, XBox, X Games, XXX the Movie…  XNA was announced at the Game Developer Conference (GDC) in 2004 as a great and accessible way to bring game development to the masses.  At the time however, we instead got (what eventually became) MS Build and they open sourced the source code and all assets for the game MechCommander 2.  However two years later XNA Game Studio was finally released.


So what exactly was XNA Game Studio?  First off, it was a special version of Visual Studio for C# with an integrated pipeline for importing game assets.  On top of that, it was a collection of .NET libraries aimed at making games, covering facets like input handling, graphics, audio and networking.  Finally it was a special .NET runtime capable of running on PC, (eventually) Windows Phone and perhaps most importantly, XBox 360.  That was the big selling point…  XNA enabled basically anybody to make games for a game console.  Outside of the very limited edition ( and much more expensive ) Net Yaroze ( a special version of the PlayStation 1), nobody had ever done this.  You could argue that XNA more than any other single release, gave rise to the burgeoning indie development scene we have today.


What makes XNA even more impressive is realizing the world it was released in.  Game engines certainly existed, Unreal was AAA only and several million dollars per title, Unity was I believe still a Mac only product and several hundred dollars per seat.  Several of the prominent open source libraries of today simply didn’t exist back then.  Plus the IDE XNA itself was based on, Visual Studio,  cost a few thousand dollars.  XNA really did bring console game development to the masses and many of the “big” indie games, titles like Fez, Braid and Terraria were create using XNA.


It wasn’t all roses though, and even though Microsoft basically invented the indie developer market, it quickly pissed it away too.  XNA titles, without a publisher agreement, were confined to Xbox Indie Games channel as well as Windows Phone stores.  The Xbox IG channel quickly became a dumping ground, discovery became a huge factor and very few developers made money.  With the release of XBox One, it seems Sony stole Microsoft’s crown as the place for indie developers to shine.


Worse, and this is a story that could fill a book on it’s own, there was a shake up at Microsoft and several technologies ended up having their plug pulled.  XNA was one of them.  Sadly, in Oct 2011, with XNA Game Studio 4.0 refresh, XNA saw it’s final release. 


So then, a dead and unsupported technology… why the heck should we care?  Simple… XNA was… is good.  Very good.  Plus “unsupported” isn’t exactly the right word to used.  Enter…


A Brief History of MonoGame


So XNA became very popular very quickly.  There was a large and growing community, several books available on the subject and new versions being released.  Hands down the biggest limitation were the supported platforms, XNA was very much tied to Microsoft platforms and a limited subset at that.  This lead to twoimage different projects, SilverSprite and XNA Touch.  The first was an attempt to make a code compatible version of XNA (at least, the 2D bits) that could be run in the browser using Silverlight.  The other was a port of XNA to run on an OpenGL back end on mobile devices.  XNA Touch ended up using the 2D code from Silver Sprite and the two eventually emerged as MonoGame.


This was several years ago and since then MonoGame has grown into a nearly 100% complete implementation of XNA 4 that can be run on several platforms ( Windows DirectX, Windows OpenGL, Mac, Linux, Android, iOS, PlayStation Vita, PlayStation 4, OUYA and more ).  The biggest hanging point has always been the content pipeline.  Until recently you’ve needed to keep an old version ( and a PC ) Game Studio around to convert your assets into the binary XNB format.  However, near the end of 2014 the MonoGame team provided that final missing piece with the release of their own cross platform content pipeline tool.    It will be interesting to see what the future holds now that the MonoGame team have basically implemented 100% of XNA.  The future of XNA is now theirs to determine.



Why should I use MonoGame?


So, that was a bit of XNA history for you.  The biggest question you may have now is… “So what?  Why should I use XNA/MonoGame today?”


Sometimes it is often easier to start with why you shouldn’t use something.  The following are the biggest reasons I can think of not to use MonoGame.

  • You want a WYSIWYG environment or integrated game editor
  • You don’t like C#
  • You want a higher level programming experience
  • There is a price tag attached to support iOS and Android


Those are probably the biggest drawbacks of using XNA.  There is no world editor.  In fact, there are very few tools at all, except content importers.   Even the libraries themselves are fairly low level, leaving you to roll your own sprite and animation classes for example.  XNA is also not the easiest library to learn, especially compared to many scripting languages or all in one solutions like GameMaker or Construct.  That coding is done in C# ( or other Mono supported languages like F#, but 99% of examples are in C# ), so if you aren’t a fan of that language, you wont like MonoGame.  Finally, and perhaps worst, targeting iOS or Android requires a Xamarin license, and that costs money.


So that’s why you shouldn’t use MonoGame, now why you should.


First off, because XNA was and is just a great library!  It was well designed, very clean and works well.  Simply put, if you like working in C# ( and I do, very much ), working in XNA is just a very pleasant coding experience.  You work at a lower level of abstraction than many of todays game engines, but after being around for about a decade, there are a huge amount of code samples and libraries to fill those pieces.  The core though, those pieces every game needs, they are all provided.  If you are the type of person that likes to have maximum control, to dig in deep and get your finger nails dirty, you’ll feel right at home!


Also, MonoGame provides access to pretty much every single platform you’d want to target today.  One of the scary things about working with some open source game project is, you never know how well they will work in the real world.  Fortunately, MonoGame has an pretty impressive resume of shipped titles, such as:

  • Bastion
  • Fez
  • Infinite Flight
  • Skulls of the Shogun
  • Transistor

Some of the biggest selling indie game, from both the past and the present, prove that MonoGame is capable. 


So basically MonoGame is a battle proven cross platform indie friendly code focused C# based game engine built on the bones of Microsoft’s XNA.  Now, let’s jump into the technical aspects and you can see why I am such a big fan of the XNA libraries in the first place.  Along the way we will cover the way MonoGame does things differently, and look at some of the unique concerns that cross platform development bring.  Next however, let’s look at getting MonoGame up and running on your platform of choice.


The Book


While I am compiling this tutorial series on, I am also compiling the entire series for an e-book release.   In the end the tutorial series and the book will contain virtually identical content.  I will be compiling new WIP releases of the book as I go and those will be made available to Patreon backers as a thank you reward.  So if you enjoy this series but would prefer it offline or printed in a PDF or Kindle/Kobo friendly format, or if you simply wish to help support GameFromScratch (or both!), your support is certainly appreciated.  Once the series is “complete”, I will do a formal compilation with proper forward, index and table of contents and make this book available on popular book stores for purchase.  Basically I am publishing a book in the open, while I develop it.  Just instead of the traditional model, this one is available completely free and has a video tutorial series to go along with it!


As always, your feedback is appreciated.  If you have any requests, comments or suggestions, please let me know and I will see what I can do!


The Video


10. June 2015


This tutorial is a quick guide on getting MonoGame up and running on Windows OS.  The process is incredibly straight forward, with two options on how to proceed.


First you are going to need a development environment, of which two options are available.  Xamarin’s Xamarin Studio or Microsoft’s Visual Studio.  If you wish to go the Xamarin Studio route, be sure to check the MacOS guide, as the process will be virtually identical.  The rest of this tutorial assumes that you chose to install Visual Studio, the industry standard IDE for Windows development which is now thankfully available for free.


So first things first, download and install Visual Studio 2013 Community.  Be sure that you select Community and not one of the 90 trial editions.  The community install is a complete and full functioning version of Visual Studio, but with some limitations on the size of your company.


As of time of writing, this is the version you want.



If you want to talk a walk on the wild side, the release candidate of Visual Studio 2015 will also work.  Of course, it’s a release candidate… so buyer beware. 

Installing either with the minimal recommendations or better will get you all that you need installed.


Install using the Installer


By far the easiest option, simply download and run the installer available here.  Be sure to shut down Visual Studio before installing.

Click Next, then agree to the EULA… after you read it and submit it to your lawyer for approval of course…

Next you will be prompted for the features you want installed.  The defaults are pretty solid, click Install:




Install using NuGet

Visual Studio integrates a package manager called NuGet.  This offers a few (potential) benefits over using the library’s standalone installer.

  • dependency resolution.  If it depends on other libraries, NuGet can handle those dependencies
  • package updating abilities.  Keep yourself up to date easier

Actually, that’s about it.  Basically if you want to be kept up to date on updates, this is the route to go.  The install process is certainly more complicated though, at least initially.

First of course you need the NuGet package manager installed.  It’s getting more and more common in use, so you will probably have it installed or need it installed shortly.   It is available as a Visual Studio extension or command line utility.

To install with NuGet, Launch Visual Studio, on first run you may have to make some configuration choices, don’t worry, most of these can be revisited later on.  Once configured, select the menu Tools->NuGet Package Manager->Package Manager Console:


Now you simply install the packages you want.  Unlike the installer you download the various packages independently.   The list of packages are available here.  Assuming you are going to develop initially on Windows, you probably want to start with the DirectX Windows version.  To install that in the Package Manager Console type:

Install-Package MonoGame.Framework.WindowsDX

This will download and install all the required files and dependencies.  For more details on the MonoGame NuGet packages please read this post on StackOverflow by the maintainer.


Your First Project

Now that you’ve got MonoGame installed let’s create our first project.  If not already done, load up Visual Studio.


Select File->New Project



In the resulting dialog, on the left hand side under installed templates, select Visual C#->MonoGame, then on the right hand side select MonoGame Windows Project, pick a location, a project name, if you want source control, then click OK.



As you can see, MonoGame ships out of the box with templates for a number of different targets and a few above may require a bit of an explanation.  The MonoGame Windows Project targets Windows desktop using Direct X for the backend.  The OpenGL project is another Windows target, but instead using OpenGL as the backend.  As DirectX is Windows, XBox and WinPhone only, you may find using the GL backend the most consistent if targeting Mac, Linux, Android and/or iOS, as those all use OpenGL on the back end.  A Windows 8.1 Universal project is an application that supports both Win 8 desktop and mobile targets with one code base, and if I am honest, with the announcement of Windows 10, is probably a complete dead end.


Ideally you will write most of your code as libraries, with only the platform specific portions in their own corresponding project file.  We will look at this process closer down the road.  For now we will KISS (Keep It Simple Stupid) and just target the platform we are developing on.


Once you click OK, the following simple project will be created:

using Microsoft.Xna.Framework;
using Microsoft.Xna.Framework.Graphics;
using Microsoft.Xna.Framework.Input;

namespace Game1
    /// <summary>
    /// This is the main type for your game.
    /// </summary>
    public class Game1 : Game
        GraphicsDeviceManager graphics;
        SpriteBatch spriteBatch;

        public Game1()
            graphics = new GraphicsDeviceManager(this);
            Content.RootDirectory = "Content";

        /// <summary>
        /// Allows the game to perform any initialization it needs to 
        before starting to run.
        /// This is where it can query for any required services and 
        load any non-graphic
        /// related content.  Calling base.Initialize will enumerate 
        through any components
        /// and initialize them as well.
        /// </summary>
        protected override void Initialize()
            // TODO: Add your initialization logic here


        /// <summary>
        /// LoadContent will be called once per game and is the place 
        to load
        /// all of your content.
        /// </summary>
        protected override void LoadContent()
            // Create a new SpriteBatch, which can be used to draw 
            spriteBatch = new SpriteBatch(GraphicsDevice);

            // TODO: use this.Content to load your game content here

        /// <summary>
        /// UnloadContent will be called once per game and is the 
        place to unload
        /// game-specific content.
        /// </summary>
        protected override void UnloadContent()
            // TODO: Unload any non ContentManager content here

        /// <summary>
        /// Allows the game to run logic such as updating the world,
        /// checking for collisions, gathering input, and playing 
        /// </summary>
        /// <param name="gameTime">Provides a snapshot of timing 
        protected override void Update(GameTime gameTime)
            if (GamePad.GetState(PlayerIndex.One).Buttons.Back == 
                ButtonState.Pressed || Keyboard.GetState().IsKeyDown(

            // TODO: Add your update logic here


        /// <summary>
        /// This is called when the game should draw itself.
        /// </summary>
        /// <param name="gameTime">Provides a snapshot of timing 
        protected override void Draw(GameTime gameTime)

            // TODO: Add your drawing code here



Don’t concern yourself overly with the code, we will explain it all shortly.  We just want to make sure that your MonoGame install is up and running.  To run your game hit F5 or press:


Assuming all went well, you should see a window drawn in CornFlower blue:


Congratulations, you’ve just created your first ever MonoGame application!


Let’s talk briefly about the Content Pipeline.  This is the way you get content into your MonoGame application.  If you look in the Solution Explorer, you will see a file named Content.mgcb.



Double click it, and the MonoGame Content Pipeline tool will open:



Let’s quickly add a texture to our project.  Select Edit->Add->Existing Item, navigate to an existing image file somewhere on your computer.



Next you will be prompted for how you want the file to be added, copied or linked, I chose copy to break the connection with the source image.  This means updates to the original image will not be propagated, nor will deleting it have any effect.



The image will be added to your content bundle, as as you can see with it selected, there are a number of properties exposed for how the image should be processed when building content:


There are several Import processors available for various different file types:



Each one exposes different parameters you can modify.  For images some of the key properties exposed are the option to automatically resize the image to a power of 2 dimension, to change the texture compression settings (TextureFormat) or setting the color key value used for transparencies.

Now select the Content root node and you will see the property details have changed:


The key setting here is Platform.  Each different platform can have slightly different requirements and the Content Pipeline takes care of that for you.  In this case we already have Windows set for the pipeline, so there is nothing that needs to be changed.


Now Build your content using the Buld->Build menu option, or by hitting F6.



Now back in Visual Studio, confirm that the build action on your Content.mgcb file is set correctly.  Right click the file and select Properties:



Make sure that Build Action is set to MonoGameContentReference.



This will enable you to use the content as if it was installed locally, making switching between platform versions trivial.


Now actually using content in code is as simple as:

 protected override void LoadContent()
            spriteBatch = new SpriteBatch(GraphicsDevice);
            var myImage = this.Content.Load<Texture2D>("SBO6h0Gk");

Don't worry, we will cover this process in more detail later. Just note that the file extension is not used.

Behind the scenes, you may notice that the Content Pipeline tool created the following xnb file in the /bin/Windows subdirectory of Content:



9. June 2015


In this tutorial we are going to look at getting a MonoGame development environment up and running on MacOS, create and run our first MonoGame application and finally take a quick look at the Content Pipeline tool.


For those that prefer video, there is a video version of this tutorial available here or embedded below.


The Installation Process

In order to get up and running there are a couple things you need to install, Mono itself then MonoGame.  We will also be installing Xamarin Platform, which includes Xamarin’s cross platform Mono based IDE Xamarin Studio.  It is not strictly required, but will make your life a great deal simpler.


The process is as straight forward as installs can get, simple download an run each installer.  There is not ambiguity to the install, however the install order is extremely important.  Download the following in this order.  In each case be sure to install the most recent version if given an option.

As I said earlier, there should be nothing complicated about any of those installs, except the order.  If you install out of order the proper templates for MonoGame won’t get added to Xamarin Studio.

Our First Project

Now let’s fire up Xamarin Studio and create our first application.  Once Xamarin loads, select New Solution...
In the resulting dialog, next select the project template to get started.  Along the left hand side scroll down and locate Other->Miscellaneous. On the right hand side you should see a number of preconfigured MonoGame templates.  For this example we are going to target only Mac OS using Xamarin’s Mac libraries, so select MonoGame Mac Application (Xamarin.Mac), then click Next.
All that remains is to pick a location and name for your application as well as if you want Git control or not.  When ready click Create.
This should create a simple application for us with the following code:
#region Using Statements
using System;

using Microsoft.Xna.Framework;
using Microsoft.Xna.Framework.Graphics;
using Microsoft.Xna.Framework.Storage;
using Microsoft.Xna.Framework.Input;


namespace HelloMonoGame
  /// <summary>
  /// This is the main type for your game.
  /// </summary>
  public class Game1 : Game
    GraphicsDeviceManager graphics;
    SpriteBatch spriteBatch;

    public Game1 ()
      graphics = new GraphicsDeviceManager (this);
      Content.RootDirectory = "Content";
      graphics.IsFullScreen = true;

    /// <summary>
    /// Allows the game to perform any initialization it needs to 
    before starting to run.
    /// This is where it can query for any required services and load 
    any non-graphic
    /// related content. Calling base.Initialize will enumerate 
    through any components
    /// and initialize them as well.
    /// </summary>
    protected override void Initialize ()
      // TODO: Add your initialization logic here
      base.Initialize ();

    /// <summary>
    /// LoadContent will be called once per game and is the place to 
    /// all of your content.
    /// </summary>
    protected override void LoadContent ()
      // Create a new SpriteBatch, which can be used to draw textures.
      spriteBatch = new SpriteBatch (GraphicsDevice);

      //TODO: use this.Content to load your game content here 

    /// <summary>
    /// Allows the game to run logic such as updating the world,
    /// checking for collisions, gathering input, and playing audio.
    /// </summary>
    /// <param name="gameTime">Provides a snapshot of timing values.<
    protected override void Update (GameTime gameTime)
      // For Mobile devices, this logic will close the Game when the 
      Back button is pressed
      // Exit() is obsolete on iOS
      #if !__IOS__
      if (GamePad.GetState (PlayerIndex.One).Buttons.Back == 
          ButtonState.Pressed ||
          Keyboard.GetState ().IsKeyDown (Keys.Escape)) {
        Exit ();
      // TODO: Add your update logic here 
      base.Update (gameTime);

    /// <summary>
    /// This is called when the game should draw itself.
    /// </summary>
    /// <param name="gameTime">Provides a snapshot of timing values.<
    protected override void Draw (GameTime gameTime)
      graphics.GraphicsDevice.Clear (Color.CornflowerBlue);
      //TODO: Add your drawing code here
      base.Draw (gameTime);

We aren’t going to go into any specifics of what this code does, not yet anyways, but we will make sure that it runs.  Hit the Play icon in the top control bar:
You should now see a full screen cornflower blue window.  If so, congratulations, you just successfully made your first Monogame application!

The Content Pipeline


The content pipeline was a major component missing from MonoGame, but they have recently implemented one.  The Content Pipeline takes external assets for your game, be them videos, textures, sounds, fonts, etc…  converts them for your platform of choice, generating a XNB file, a binary format that XNA used internally.  Let’s take a look at the process in MonoGame.


If you look under the Content folder of your Solution, you will see a file called Content.mgcb. 



Double click this and the Content Pipeline tool will load:



This is the tool you use to assemble the assets your game is going to use.  Let’s take a quick example of importing a texture.


First select Edit->Add->Existing Item...



Browse to the image you wish to import as a texture then select OK.

Screen Shot 2015 06 09 at 12 35 35 PM


Now you will be asked how you wish to import the file.  I want a copy to be made so the original is unaffected.

Screen Shot 2015 06 09 at 12 36 41 PM


Your texture should now be added:

Screen Shot 2015 06 09 at 12 37 09 PM


You now have a few options about how the content will be processed on import.  With the image selected, notice the options available below it:

Screen Shot 2015 06 09 at 12 38 17 PM


Each different importer has a different set of parameters you can modify.  Here you can set the automatic generation of mip maps, resize to power of 2 dimensions, change the compression settings, etc.


By selecting the Importer drop down you can get an idea of the various type of assets supported by the Content Pipeline:

Screen Shot 2015 06 09 at 12 40 04 PM


Now select the Content node and the properties available will change again.  This time we simply want to change the target platform to MacOS:

Screen Shot 2015 06 09 at 12 41 11 PM


You can have the Content Pipeline automatically process content for a variety of different platforms.  Now that this task is done let’s actually build our content.  Simply select Build->Build or hit F6:

Screen Shot 2015 06 09 at 12 42 08 PM


In the directory [Content]/bin/MacOSX there will now be an XNB file available for use.  Let’s add it to our project.


In Xamarin Studio, right click the Content folder and select Add->Add Files...

Screen Shot 2015 06 09 at 12 44 15 PM


Navigate to the XNB file in Content/bin/MacOSX that you just created and select it.  Then select Override Build action and choose ‘Content'

Screen Shot 2015 06 09 at 12 46 11 PM


This time when prompted how to add the file, choose the Link option:

Screen Shot 2015 06 09 at 12 47 57 PM


Congratulations, you have now added an asset to your game.  In future tutorials we will look at using them in more detail.

The Video Version

17. March 2015


MonoGame, the popular cross platform spin-off the now dead XNA framework has just released version 3.3.


For the official release notes:


This is a short summary of all the changes in this release:

  • Support for vertex texture fetch on Windows.
  • New modern classes for KeyboardInput and MessageBox.
  • Added more validation to draw calls and render states.
  • Cleaned up usage of statics to support multiple GraphicsDevice instances.
  • Support Window.Position on WindowsGL platform.
  • Reduction of redundant OpenGL calls.
  • Fullscreen support for Windows DX platform.
  • Implemented Texture2D SaveAsPng and SaveAsJpeg for Android.
  • Improved GamePad deadzone calculations.
  • We now use FFmpeg for audio content building.
  • BoundingSphere fixes and optimizations.
  • Many improvements to Linux platform.
  • Various fixes to FontTextureProcessor.
  • New Windows Universal App template for Windows Store and Windows Phone support.
  • Many fixes to reduce garbage generation during runtime.
  • Adding support for TextureFormatOptions to FontDescriptionProcessor.
  • XNA compatibility improvements to FontDescriptionProcessor.
  • Resuscitated the unit test framework with 100s of additional unit tests.
  • BoundingFrustum fixes and optimizations.
  • Added VS2013 project templates.
  • Moved to new MonoGame logo.
  • Added MSAA render target support for OpenGL platforms.
  • Added optional content compression support to content pipeline and runtime.
  • TextureCube content reader and GetData fixes.
  • New OpenAL software implementation for Android.
  • Xact compatibility improvements.
  • Lots of Android fixes and improvements.
  • Added MediaLibrary implementation for Android, iOS, Windows Phone, and Windows Store.
  • Added ReflectiveWriter implementation to content pipeline.
  • Fixes to Texture2D.GetData on DirectX platforms.
  • SpriteFont rendering performance optimizations.
  • Huge refactor of ModelProcessor to be more compatible with XNA.
  • Moved NET and GamerServices into its own MonoGame.Framework.Net assembly.
  • Runtime support for ETC1 textures for Androud.
  • Improved compatibility for FBXImporter and XImporter.
  • Multiple SpritBatch compatibility fixes.
  • We now use FreeImage in TextureImporter to support many more input formats.
  • MGFX parsing and render state improvements.
  • New Pipeline GUI tool for managing content projects for Windows, Mac, and Linux desktops.
  • New implementation of content pipeline IntermediateSerializer.
  • All tools and content pipeline built for 64-bit.
  • New documentation system.
  • Implement web platform (JSIL) stubs.
  • Lots of fixes to PSM.
  • Added Protobuild support for project generation.
  • Major refactor of internals to better separate platform specific code.
  • Added MGCB command line tool to Windows installer.


Monogame runs on Windows, Mac and Linux and is available for download here.  They have also announced that they are going to a more frequent release schedule, something I always view as a good move.


24. October 2014


On a daily basis I use dozens of different programming languages.  Some languages are certainly better than other languages at certain tasks, while other languages truly shine on certain platforms.  Some languages are more portable than others, others are more customizable while some can be faster.  All that said, when all other things are equal and I need to just pick a language, the one I go to is generally C#.  C# just strikes that right balance for me, straddling the line between low level and productivity, convenience and speed, functional and procedural, for me at least.  This news then is welcome, for me at least. :)


Xamarin, the maker’s of Mono, a cross platform open source version of the .NET runtime and framework (Perhaps most famously known as the language technology that underpins Unity)  have announced they are bringing it to Unreal Engine.  Here are some of the features and benefits of Mono for Unity:


Hot Reload


We fully support Unreal Engine's Hot Reload functionality.

This means that whenever you rebuild your C# code in Xamarin Studio, your changes are immediately reloated into the Unreal Editor. The changes are also reflected with running games in the editor, so you can quickly iterate on your design.

On fast machines, the process of rebuilding the C# code and reloading it live takes less than a second. It feel instantaneous.


Xamarin Studio

While hard core hackers are happy editing their game code with vi or emacs and have the hot reload functionality do all the work for them, we have also provided a nice integration with the MonoDevelop (and Xamarin's branded version, Xamarin Studio).

It provides a first-class IDE with rich, accurate code completion, and powerful refactoring and analysis tools.



Full support for C# debugging is included. Simply launch your game from Xamarin Studio as a standalone editor or mobile preview process, and it will connect to the runtime debug engine, giving you full access to a rich suite of abilities to inspect and debug your code.

Seamless Blueprint and Editor Integration

Your C# classes that are exposed to Unreal Engine are fully accessible from Blueprint and the Unreal Editor, just like Blueprint-accessible C++ classes.

You can continue using Blueprint for simple logic and use C# when things get more complicated.

And you can consume your C# classes from Blueprint.


Mixed C#/C++/Blueprint Solutions

The same tool that we use to generate bindings to Blueprint-exposed Unreal Engine APIs is integrated into Unreal Build Tool, and will automatically generate bindings to all of your Blueprint-exposed C++ gameplay code and engine modifications.


Native Access

In addition to the automatically generated bindings to Blueprint-exposed Unreal C++ code, the Mono runtime allows accessing any native APIs, including custom C/C++ code and the native platform API.

You can manually bind C APIs using Platform Invoke services, or use CppSharp to generate bindings to C++ APIs.


Async Programming

The Getting Started tutorial shows the low-level approach to defining behaviors, but this approach can become cumbersome when defining more complex behaviors and AI. Luckily, this task can be simplified with async programming, a C# compiler feature that rewrites what appears to be linear code into a state machine.

For more details about how this helps writing complex gameplay logic, see our overview of async programming.


API Profile

The Mono Mobile Profile is the core API profile in the support for Unreal Engine.

The Mono Mobile Profile removes a number of bloated .NET features including System.Configuration support from the Base Class Libraries. This is the same API profile used by Xamarin's Android, iOS and Mac products.

Note: The Mobile Profile is not ABI compatible with existing assemblies compiled for a different profile (like the .NET desktop, Silverlight or Windows Phone). You mustrecompile your source code to generate assemblies targeting the Mobile profile.

A full list of the assemblies in our Mobile framework profile can be found here.


Portable Class Libraries

You can use Portable Class Libraries with Xamarin's Unreal Engine support. This allows the same binary library to be shared across a wide range of platforms without code modifications.

To learn more about using Portable Class Libraries with Xamarin, read our Introduction to Portable Class Libraries document.


There are a couple limitations.  It’s based on .NET up to 4.5, with a smattering of .NET 5 features.  Well, anync, which is frankly the .NET 5 feature.  Perhaps the biggest limitation is it only has access to code from the Blueprint API.  Given that the Blueprint API has access to just about everything C++ does, this isn’t perhaps the limitation it sounds like.  If you want to make more C++ accessible to .NET you need to use CppSharp.  Additionally, Unreal AND Mono need to be available on the targeted platform, although frankly, Mono is available just about everywhere these days.  However, right now only Windows and Mac are supported, with other platforms under development.


Oh yeah, there is of course one other big side effect… money.


To redistribute code written with Mono for Unreal Engine, you must have a commercial license to the Mono runtime. These licenses are available from Xamarin for Mac, Android and iOS online, and you can request Windows licenses through support.


This of course is completely reasonable.  People make their money selling software, so obviously they have to sell their software.  That said, I’ve always found Xamarian’s licensing to be a bit awful.  There are almost unique in the development world for not offering a (real) free version for non-commercial development and this is a huge mistake IMHO.  The lack of a free edition makes open source software around their tools pretty much non-existent.  Of course you can open source work made with Xamarian tools, but good luck building a community around a commercial only development product.


That said, this is still an interesting development and one more feather in Unreal Engine’s cap.  Given that Unity is moving away from Mono and developing their own runtime, it’s not entirely shocking that Xamarin made this move.  It is somewhat ironic that the Unreal Engine .NET runtime will be substantially newer and more complete than Unity’s!


GFS On YouTube

See More Tutorials on!

Month List