One framework for creating powerful cross-platform games.



One framework for creating powerful cross-platform games. The spiritual successor to XNA with thousands of titles shipped across desktop, mobile, and console platforms. MonoGame is a fully managed .NET open source game framework without any black boxes. Create, develop and distribute your games your way.

Join the chat at Join the chat at

Build Status

Our build server builds, tests, and packages the latest MonoGame changes. The table below shows the current build status for the develop branch.

Name Status
Build Windows, Web, and Android Build Status
Build Mac, iOS, and Linux Build Status
Windows Tests Build Status
Mac Tests Build Status

Supported Platforms

We support a growing list of platforms across the desktop, mobile, and console space. If there is a platform we don't support, please make a request or come help us add it.

  • Desktop PCs
    • Windows 10 Store Apps (UWP)
    • Windows Win32 (OpenGL & DirectX)
    • Linux (OpenGL)
    • Mac OS X (OpenGL)
  • Mobile/Tablet Devices
    • Android (OpenGL)
    • iPhone/iPad (OpenGL)
    • Windows Phone 10 (UWP)
  • Consoles (for registered developers)
    • PlayStation 4
    • PlayStation 5
    • Xbox One (both UWP and XDK)
    • Nintendo Switch
    • Google Stadia
  • Other
    • tvOS (OpenGL)

Support and Contributions

If you think you have found a bug or have a feature request, use our issue tracker. Before opening a new issue, please search to see if your problem has already been reported. Try to be as detailed as possible in your issue reports.

If you need help using MonoGame or have other questions we suggest you post on our community forums. Please do not use the GitHub issue tracker for personal support requests.

If you are interested in contributing fixes or features to MonoGame, please read our contributors guide first.


If you'd like to help the project by supporting us financially, consider supporting us via a subscription for the price of a monthly coffee.

Money goes towards hosting, new hardware and if enough people subscribe a dedicated developer.

There are several options on our Donation Page.

Source Code

The full source code is available here from GitHub:

  • Clone the source: git clone
  • Set up the submodules: git submodule update --init
  • Open the solution for your target platform to build the game framework.
  • Open the Tools solution for your development platform to build the pipeline and content tools.

For the prerequisites for building from source, please look at the Requirements file.

A high level breakdown of the components of the framework:

Helpful Links


The MonoGame project is under the Microsoft Public License except for a few portions of the code. See the LICENSE.txt file for more details. Third-party libraries used by MonoGame are under their own licenses. Please refer to those libraries for details on the license they use.

  • Replacing OpenTK

    Replacing OpenTK

    This stems from a discussion started in another PR:

    It has been over 3 years since we initially investigated sticking with OpenTK in MonoGame. The OpenTK team at that time promised fixes and renewed development of the library.

    Since then there have been improvements, but we still suffer problems with OpenTK functionality and need per-platform work arounds at times.

    Is it finally time to give up on OpenTK?

    Do we proceed with our own custom binding for SDL2 and OpenGL?

    What happens to platforms like iOS and Android where we depend on the Xamarin fork of OpenTK for OpenGL access?

    OpenGL Design 
    opened by tomspilman 214
  • Technical assessment of OpenTK revival vs. switching to SDL2

    Technical assessment of OpenTK revival vs. switching to SDL2

    So I and others have been advocating reviving OpenTK several times and I'm happy to hear that the MonoGame core team is making good progress on that front (

    Now I hear @flibitijibibo has been working on porting MonoGame to SDL2 with apparently good results. From what he says on Twitter (I hope I'm not misrepresenting what he meant), SDL2 is well maintained and works great on all desktop platforms.

    Apparently he mentioned his fork a couple times around here but it wasn't seriously considered because it's a huge change and the perceived cost of merging seems high while the benefits haven't been made obvious

    I'm opening this issue hoping that we can discuss the technical & community merits of switching to SDL2 vs. marching forward with the on-going revival on OpenTK.

    @flibitijibibo care to point us to your fork, detail what state it's in and how it compares in terms of features/bugs to the current MonoGame?

    cc @tomspilman @dellis1972 @CartBlanche

    opened by elisee 182
  • Improving The Platform Extension System

    Improving The Platform Extension System

    I'd like to start discussing how we can further improve the system by which different platforms are added in MonoGame.

    IMO the idealistic goal moving forward should be that we can add additional platforms (like PS4 for instance) without needing to make platform specific modifications to existing files in the public repo. Ideally merging in a platform like XB1, PS4, or WiiU would be as simple as copying a folder of files into the root of the public repo and executing Protobuild.

    About a year ago we took two big steps...

    Moved to using Protobuild for project generation

    The Protobuild change now means zero project file maintenance, new non-platform specific code is quick to add, and no more project file conflicts.

    The problem with Protobuild is that all the platform specific info is centralized in one file. This means that if we have a closed source platform like we do with PS4... we have to maintain a patched version of that definition file with additional .ps4.cs files and other platform specific details.

    Ideally there should be a way to optionally include additional platform files/settings from the main Protobuild .definition file. @hach-que ??

    Partial classes and "Platform" methods

    Also a lot of MonoGame platform code is now done with partial classes and "Platform" methods. This is great as most of the platform code is just adding in various .platform.cs and editing the protobuild config file to include them.

    We still have big classes like GraphicsDeviceManager that are a #if spaghetti. We should prioritize converting classes like that into platform partial classes.

    In places where we smaller #if blocks that are enabling some feature for multiple platforms we should look at add a feature specific #if. For example this case here:

    ... we probably need a #if NO_EXIT instead of naming specific platforms. This allows the feature to be toggled on other platforms by changing the Protobuild config.

    Extending The Pipeline

    A big area where we need to design a new abstraction is within the content pipeline. There are cases where there are platform specific formats and processing that we want to be able to plug into the pipeline instead of being hard coded into the public repo.

    In this case I started a separate issue for this (see but it is something that needs consideration.

    Feature Request Design 
    opened by tomspilman 152
  • [Mac] Upgrade Protobuild, Allow MacOS to target newer Xamarin APIs, etc.

    [Mac] Upgrade Protobuild, Allow MacOS to target newer Xamarin APIs, etc.

    This PR addresses multiple issues at once because they're all dependent on one another:

    • Upgrades Protobuild: Throughout the course of this PR I had to make changes to Protobuild to support the newer APIs and fix various issues across platforms, so that is updated here.
    • Remove old XSLTs: With the Windows Universal and tvOS platforms upstreamed into Protobuild, there's no need for MonoGame to keep it's own copies of the XSLT files any more. This PR removes them in favour of the built-in ones. This will assist with #4218.
    • Mac now supports the Xamarin.Mac Unified API: It supports both the MonoMac API, XamMac API and newer Xamarin.Mac API (unified). The older APIs are supported by #ifdef'ing namespaces with the PLATFORM_MACOS_LEGACY define. This resolves #4275, but should also fix bugs like #4278.
    • WindowsUAP is now WindowsUniversal: This brings the MonoGame platform name inline with the platform name being used in upstream. See for the name change reasoning.
    opened by hach-que 142
  • MonoGame.Portable returns - now with Piranah's

    MonoGame.Portable returns - now with Piranah's

    Right, so I've been working with @dellis1972 on the PCL generator project and it looks like it is close to being done. It now uses a PCL generator solution based on Mono.Cecil called Piranah (which Dean has also updated to run on a Mac) Generator branch for MG can be found here:

    The generator only uses the WindowsGL build as a template, which seems sufficient for the PCL to be used in a "Bait and Switch" style PCL as a core platform. Platform specific code should always remain in a Platform project (like iOS), where as all common "core" code should be used in the PCL.

    Question is now how to provide this framework back in to the MonoGame project so it can be run in an automated fashion. In the branch above (using Protobuild as a template) I've created a new ThirdParty folder for Piranah and put the runtime exe and Dll's in there. There is a commandline file to generate the project manually for test at the moment (need both the WindowsGL project built and an output folder in MonoGame.Framework/bin/PCL created first)

    I've also started on a new MonoGame.Portable NuGet package, which is still a work in progress. In testing it needs more platform targets to work effectively.

    So next steps?

    opened by SimonDarksideJ 138
  • [Maintenance] Generate Visual Studio and Xamarin Studio templates from a common source

    [Maintenance] Generate Visual Studio and Xamarin Studio templates from a common source

    Right now MonoGame has the following project templates for various different IDEs:

    • ProjectTemplates\VisualStudio2010\Android
    • ProjectTemplates\VisualStudio2010\Linux
    • ProjectTemplates\VisualStudio2010\OUYA
    • ProjectTemplates\VisualStudio2010\Windows
    • ProjectTemplates\VisualStudio2010\WindowsGL
    • ProjectTemplates\VisualStudio2012\WindowsPhone
    • ProjectTemplates\VisualStudio2012\WindowsStore
    • ProjectTemplates\VisualStudio2012\WindowsStoreXaml
    • ProjectTemplates\VisualStudio2013\WindowsPhone
    • ProjectTemplates\VisualStudio2013\WindowsPhone8.1
    • ProjectTemplates\VisualStudio2013\WindowsStore
    • ProjectTemplates\VisualStudio2013\WindowsStoreXaml
    • ProjectTemplates\VisualStudio2013\WindowsUniversal
    • ProjectTemplates\VisualStudio2013\WindowsUAP
    • IDE\MonoDevelop\ (and all the various template files under here)

    We can probably make it easier to maintain all of these variants if we generate them - this would have the added bonus that if we want to quickly test the current version of MonoGame that we're working on as an actual app, we can just create a new project from those templates rather than having to actually install the templates into Visual Studio / Xamarin Studio first (especially since all this really is is just fancy text replacement).

    opened by hach-que 131
  • Automate NuGet Packaging And Publish

    Automate NuGet Packaging And Publish

    With TeamCity we have some powerful NuGet features, including the ability to both package and publish to any feed.

    First we need to figure out:

    • What builds will we make available thru NuGet?
    • How often should these builds be updated?

    Then we can begin to setup the build server to support building and publishing them.

    opened by tomspilman 106
  • Pipeline dotnet tool

    Pipeline dotnet tool

    I don't believe there's been much discussion of the design of the Pipeline dotnet global tool. I'm interested in helping with that next, as I think that's the last piece that need to be nugetized.

    Open Questions

    1. Future of Pipeline tool. [EDIT] Resolved: Pipeline is here to stay, while cra0zy is working on his own alternative.

      @Jjagg I am in process of writing something custom for the content builder, among the other stuff, so I'm leaving this to you. I really don't wanna touch MGCB/Pipeline Tool anymore.

      Originally posted by @cra0zy in

      Should we be expecting something to replace the current tooling, or is that just personal preference or maybe an alternative option? (I assume the latter)

    2. Name. [EDIT] Resolved: MGCB Editor is currently the top contender, with commands like dotnet tool run mgcb-editor

      As a public package, "Pipeline" is too generic. What name should be used for the package and the command? (Note: our other tools are dotnet-mgcb and dotnet-2mgfx.) For example:

      • Tool: dotnet-mgpipeline
      • Global command: mgpipeline
      • Local command: dotnet tool run mgpipeline
    3. Structure. [EDIT] Resolved: The platform packages can't be unified, because we want native UI controls on Windows. We can, however, package them together and have a cross-platform launcher so the experience is seamless across all platforms.

      Should we package platform-specific Pipeline tools, or unify them? Is UI the only thing preventing these from being unified? Presumably shaders can just continue to not compile on non-Windows for now.

      • Platform-specific would be easiest since it would keep the same structure and Eto dependencies. We can publish dotnet-mgpipeline-windows, dotnet-mgpipeline-mac, dotnet-mgpipeline-linux, but this is clearly not ideal.
      • We can switch to a new cross-platform .NET Core UI framework and publish a single cross-platform tool. The most popular appears to be Avalonia.
      • We can use MonoGame.DesktopGL itself for the UI -- either a 3rd party UI framework, or maintain an extremely slim set of controls just for the tools (not a part of the MG framework).
    4. MGCB dependency. [EDIT] Resolved: MGCB will be packaged directly into MGCB Editor. The duplicated files aren't too large and shouldn't be much concern for devs.

      How should the MGCB dependency be handled?

      • Just package MGCB binaries into the Pipeline tool as well? Then users who use the Pipeline tool and build with the MonoGame.Content.Builder package (#6905) would have a handful of files duplicated, but it's not a big issue. Is there a concern about the two versions needing to be manually kept in sync?
      • Package MGCB binaries into the Pipeline tool, but don't additionally required the MGCB tool when using the Pipeline tool. Instead use MGCB out of the Pipeline tool. See the Usage option below for more details.
      • Have the Pipeline tool depend on the MGCB dotnet tool. This would be difficult, because if the Pipeline tool is installed globally, then it would have to also install the MGCB tool globally, which is an option we decided to avoid with MonoGame.Content.Builder. This could also be difficult to run locally out of the MonoGame repo, because the Pipeline tool would need to be able to either depend on the MGCB dotnet tool or use the local MGCB project.
    5. Usage. [EDIT] Resolved: /register and /unregister CLI commands will be available to associate the app with the .mgcb extension by running pipeline /register (global) or dotnet tool run pipeline /register (local).

      I expect a common scenario to be installing as a global tool, but can we enable more options?

      • As an additional option, I was thinking about being able to specify an option in the MonoGame.Content.Builder package (#6905) to restore the Pipeline tool instead of MGCB. This would make it easier for content designers to just clone a repo and automatically get the recommended tooling. And obviously this wouldn't have to compromise any of the core MonoGame.Content.Builder functionality.
      • Will we need to give up associating the .mgcb file extension with the tool? This doesn't seem like a good option anymore since dotnet tools can be installed globally or locally. Following the potential usage option above, in my own repos I plan to change my Pipeline extensions project into a netcoreapp that can simply call dotnet tool run pipeline on the correct .mgcb file.
    opened by jnoyola 102
  • 2MGFX does not work on non-Windows platforms

    2MGFX does not work on non-Windows platforms

    I'm assuming that 2MGFX is not meant to compile under Linux. Are there any intentions to change this in the future so that compilation can be done on non-Windows platforms?

    opened by hach-que 93
  • Finalize Coding Style Guide

    Finalize Coding Style Guide

    We need to finalize the coding style guidelines in this document:

    This is a required step before we can do #1511.

    Lets keep all discussion in this thread before any PRs are submitted to change the guide.

    opened by tomspilman 88
  • [iOS] Disappearing SoundEffects

    [iOS] Disappearing SoundEffects

    There is one thing with the iOS version of MonoGame that always annoyed me and I never really knew why it happened: SoundEffects randomly disappear.

    We have a dozen of sound effects in our game, loaded using a single content manager. There are a number of instances created from every effect. When the game is launched, some of the sound effects won't play. For example, I launch the game and the "Click" sound doesn't play (all the instances of it). Then I close it, launch it again and the "Bell" sound doesn't play. Sometimes multiple effects disappear, sometimes none of them.

    It may or may not be related, but when the game loads, I get a number of these on the application output:

    Failed to get buffer attributes: 

    It seems that I don't get any of these when all the sound effects work, but I get many of some of them don't.

    opened by Nezz 85
  • Disabling linker crashes application on startup on iPad

    Disabling linker crashes application on startup on iPad

    Steps to reproduce:

    1. Create a blank application using the MonoGame iOS template
    2. Open project properties, set iOS / Build / Linker behavior to Don't link
    3. Run the app on iPad

    Expected result: Application starts

    Actual result: Application crashes immediately at startup, the debugger hangs and needs to be manually terminated

    Surprisingly, it only reproduces on the iPad: running the same app on iPhone with linker disabled works fine. I cannot avoid setting this property because otherwise SpriteFonts do not work at all.

    Minimal repro code:

    What version of MonoGame does the bug occur on:

    • MonoGame

    What operating system are you using:

    • Windows

    What MonoGame platform are you using:

    • iOS

    P.S. This is the fourth (!) iOS-related showstopper bug in a row that I'm running into in a single week:

    1. SpriteFonts do not work
    2. Content is missing
    3. Music doesn't play
    opened by impworks 5
  • Set Nullable project property in project templates

    Set Nullable project property in project templates

    After compiling a MonoGame Library project into a .dll, I could not add it as a reference, always showing a dialog with the message "A task was cancelled." and failing to add. image

    After trying a lot of things I found the solution to be changing the project property for the new nullable context into anything other than its default state (empty, not set to anything). image

    After doing that I was able to add the .dll with no problems to my project. I do not know how the project templates work but I'd like to suggest setting this value to something by default could prevent some headaches in the future for anyone creating libraries (or just projects, as the property is also empty on the other templates).

    What version of MonoGame does the bug occur on:

    • MonoGame 3.8.1

    What operating system are you using:

    • Windows

    What MonoGame platform are you using:

    • Library
    opened by WhistleWiz 1
  • Moving window from one screen to other resizes window

    Moving window from one screen to other resizes window

    I created a project in visual studio with desktop application. My setup has two monitors :

    • internal laptop display 1920x1080
      • external monitor 1920x1080 (bigger in size so DPI is different)

    Application starts on the internal display. When I drag window from internal to external window scales (correctly as per DPI) but once I cross the boundary of screens the window increases in size up to the point where it's much bigger than the screen. Window continues to resize only when dragging on the other screen. Once I drag the window back is to the internal display it stops resizing (but remains bigger in pixels). Same happens when I try to drag it again to the external display.

    Reproducible every time. It would be more convenient to develop on the bigger monitor but for now I have to continue with the window being on the smaller screen.

    What version of MonoGame does the bug occur on:

    • MonoGame 3.8.1

    What operating system are you using:

    • Windows 11

    What MonoGame platform are you using:


    opened by pgrudzien12 2
  • VSInputTxVc Color and TexCoord swap.

    VSInputTxVc Color and TexCoord swap.

    Swapped VSInputTxVc Color and TexCoord to match VertexPositionColorTexture layout. Some platforms require them to be in the same order, otherwise you get garbled textures/colors when using texture and colors without normals.

    opened by HouseOfPandas 0
  • Support DescriptionAttribute or DisplayAttribute in MGCB Edtior

    Support DescriptionAttribute or DisplayAttribute in MGCB Edtior

    It does not appear that the MGCB Editor supports the DescriptionAttribute or the DisplayAttribute for processor parameters. Looking through the source, it seems to only pull the DisplayNameAttribute here for setting the visual name of the parameter in the property window.

    When developing custom pipeline extensions for others to consume, it could be useful to have hover tooltips for the processing parameters to further clarify what the parameter is affecting. For example, I have a boolean parameter for enabling/disabling premultiply alpha when importing an Aseprite file. Aseprite does not store the color values as premultiplied in the file and MonoGame's SpriteBatch.Begin() uses BlendMode.AlphaBlend if no blend mode is set. So the default expectation should be that the color values be premultiplied for any user using my importer. However I have the option to disable that for those that are aware of what affect it may have and are handling it in code themselves.

    In a situation like this, it would be advantageous to have a hover tooltip over the processing parameter to give a description of what the parameter is doing and also provide a note or warning on why they might want to leave it on the default setting. Outside of specific situations like this, it would be nice in general just to be able to provide description details about the parameter.

    I think for ease of implementation, the DisplayNameAttribute could be swapped out for the DisplayAttributewhich provides both a DisplayAttribute.Name and DisplayAttribute.Description property.

    What version of MonoGame does the bug occur on:

    • MonoGame 3.8.1

    What operating system are you using:

    • Windows & Mac

    What MonoGame platform are you using:

    • DesktopGL
    opened by AristurtleDev 0
  • 3d game white washed and laggy after 3.8.1 upgrade

    3d game white washed and laggy after 3.8.1 upgrade

    I've just upgraded my 3d maze game to the latest MonoGame but this resulted in some strange issues:

    First of all all colors are way lighter now, original: image

    new: image

    Secondly my game feels way more stuttery and laggy after the upgrade.

    Here's the sourcecode:

    What version of MonoGame does the bug occur on:

    • MonoGame

    What operating system are you using:

    • Windows

    What MonoGame platform are you using:

    • DesktopGL
    opened by devedse 2
One framework for creating powerful cross-platform games.
Powerful, mature open-source cross-platform game engine for Python and C++, developed by Disney and CMU

Panda3D Panda3D is a game engine, a framework for 3D rendering and game development for Python and C++ programs. Panda3D is open-source and free for a

Panda3D 3.5k Sep 16, 2022
A powerful free cross-platform RTS game engine

Spring RTS game engine README Spring (formerly TASpring) is an Open Source Real Time Strategy game engine. Visit our project homepage for help, sugges

Spring RTS 2.8k Sep 17, 2022
YYToolkit is a tool for creating mods and altering GameMaker games.

YYToolkit is a tool for creating mods and altering GameMaker games.

Archie 31 Aug 10, 2022
TrenchBroom is a modern cross-platform level editor for Quake-engine based games.

TrenchBroom is a modern cross-platform level editor for Quake-engine based games.

TrenchBroom 1.2k Sep 16, 2022
VERY simple cross-platform C++ analytics for games (using Google Analytics)

Tiniest Analytics is a very simple to use, cross-platform (tested on win/osx/linux/ios/android) and basically very tiny analytics system written in C++ (less than 100 lines of code), made specifically for games. It uses libcurl to post events to your Google Analytics account.

Mihai Gosa 96 Sep 9, 2022
Cute Framework (CF for short) is the cutest framework available for making 2D games in C/C++

Cute Framework (CF for short) is the cutest framework available for making 2D games in C/C++. CF comprises of different features, where the various features avoid inter-dependencies. In this way using CF is about picking and choosing which pieces are needed for your game

null 249 Sep 12, 2022
After a few loose attempts at porting Source-games; here comes my first real one!

StanleyParable-Vita After a few loose attempts at porting Source-games; here comes my first real one! (For anyone who wonders what happened to the HL2

Sleppo04 4 Sep 21, 2021
This is a list of different open-source video games and commercial video games open-source remakes.

This is a list of different open-source video games and commercial video games open-source remakes.

Ivan Bobev 103 Sep 12, 2022
CRYENGINE is a powerful real-time game development platform created by Crytek.

CRYENGINE This repository houses the source code for CRYENGINE. Instructions on getting started with git can be found here, along with details on work

Crytek 931 May 10, 2022
Polycode is a cross-platform framework for creative code.

Polycode is a cross-platform framework for creative code. You can use it as a C++ API or as a standalone scripting language to get easy and simple acc

Ivan Safrin 2.4k Sep 21, 2022
A Framework for developing Unity games with Lua

UnityLua A Framework for developing Unity games with Lua Warning: This is not finished, I don't suggest using this until it is complete or you may run

Down 7 Jul 13, 2022
Creating Unreal Engine infinite landscapes/oceans using the editor shader graph and rendering them using Geometry ClipMap. It also allows to spawn mesh on landscape surface. UE5 required

Procedural Landscapes and Oceans in Unreal Engine 5 using Editor Shader Graph Latest version of this project is available as a plugin for UE 4.26+ on

Maxime Dupart 10 Oct 4, 2021
KlayGE is a cross-platform open source game engine with plugin-based architecture.

KlayGE KlayGE is a cross-platform open source game engine with plugin-based architecture. It's started since 2003. The explicit goal of KlayGE is: to

Minmin Gong 1.8k Sep 20, 2022
A cross-platform 2D game engine

nCine nCine is a cross-platform 2D game engine. It is released under the MIT License, Copyright (c) 2011-2021 Angelo Theodorou. For additional informa

nCine 745 Sep 15, 2022
Cross-platform, sophisticated frontend for the libretro API. Licensed GPLv3.

RetroArch RetroArch is the reference frontend for the libretro API. Popular examples of implementations for this API includes video game system emulat

null 7k Sep 17, 2022
MAZE (My AmaZing Engine) - 🎮 Personal open-source cross-platform game engine

MAZE (My AmaZing Engine) is the self-written open-source cross-platform game engine in the active development stage. At the moment it is my main pet project, developed for the purpose of learning and preserving different game dev technologies.

Dmitriy Nosov 11 Jan 9, 2022
Cross-platform version of Heboris C7EX using a hardware-accelerated SDL 2.0 renderer

Heboris C7EX - unofficial version (YGS2K EX) This version contains the source code for Heboris C7EX. It requires a C compiler, SDL 2.0, SDL 2.0 mixer,

Brandon McGriff 10 Aug 31, 2022
CSEngine is a cross-platform 3D game engine.

CSEngine - Cross Platform C++ Game Engine CSEngine is a cross-platform 3D game engine. ?? As it is under development, it is not yet suitable for pract

ounols 50 Sep 18, 2022
Intrinsic is a Vulkan based cross-platform game and rendering engine

Intrinsic is a Vulkan based cross-platform game and rendering engine

Benjamin Wrensch 1k Sep 10, 2022