# MonoGame: the open-source successor to Microsoft's discontinued XNA Framework > A .NET game framework that ports the XNA programming model to C# across desktop, mobile and registered console targets, and ships as a framework library rather than an editor. **MonoGame/MonoGame** — One framework for creating powerful cross-platform games. - Repository: https://github.com/MonoGame/MonoGame - Website: http://www.monogame.net - Stars: 14,495 · Forks: 3,117 - Language: C# - License: NOASSERTION - Published: 2026-10-06 · Updated: 2026-10-06 · Language: en - Canonical page: https://hysenlabs.com/projects/monogame-monogame ## What XNA left behind and what MonoGame rebuilt MonoGame describes itself as an open-source re-implementation of Microsoft's XNA Framework, and that single sentence is the most useful thing in the README because it defines both the opportunity and the ceiling. XNA gave hobbyists and small studios a managed game stack with a fixed content pipeline, a sprite batcher and a component model that did not require a native engine. Microsoft discontinued it, and MonoGame's job has been to keep that API surface compiling against modern .NET on hardware that did not exist when XNA shipped. The proof the README offers is a list of shipped commercial games: Streets of Rage 4, Carrion, Celeste and Stardew Valley, with a longer list on the project's showcase page. Those are not hobby projects, which matters because it answers the question a new user asks first, whether this is a real dependency or a weekend experiment. A commercial title running on an abstraction means the API can survive contact with a production schedule. The flip side is visible in the repository topics, which include `xna`. MonoGame is deliberately a port, so its API will always resemble a Microsoft product from the late 2000s rather than a design from the present. Code written against it looks like XNA code because that is what it is. ## One repository, seven platform solutions The tree is the clearest documentation in this project. There is no single engine folder; there are separate solutions per target, which tells you the platform backends are separate assemblies with separate build requirements rather than one binary that abstracts over everything. ```bash MonoGame.Framework.DesktopGL.sln MonoGame.Framework.WindowsDX.sln MonoGame.Framework.Android.sln MonoGame.Framework.iOS.sln MonoGame.Framework.Native.sln ``` `Build.sln` sits alongside those, along with three Tools solutions split by host: `MonoGame.Tools.Linux.sln`, `MonoGame.Tools.Mac.sln` and `MonoGame.Tools.Windows.sln`. The naming convention is the practical takeaway. A framework that has to abstract across OpenGL, DirectX, Android and iOS cannot hide its backends entirely, and instead it ships one solution per backend and lets you pick. The README's source instructions reflect that structure. There is a recursive clone, because the repository carries submodules, and then you open the solution matching your target platform and the Tools solution matching your development platform: ```bash git clone --recurse-submodules https://github.com/MonoGame/MonoGame.git git submodule update --init ``` Both commands come from the README. The repository also ships `build.sh`, `build.ps1` and `MonoGame.props` at the top level, so scripting a build is a supported path rather than something you assemble yourself. Prerequisites are not in the README; they are pointed at `REQUIREMENTS.md`, which is the file to read before attempting a source build. ## The platform matrix, including the parts that cost money The README lists supported platforms with real version floors, which is more informative than most engine documentation. Desktop covers Windows 10 at 22H2 or newer with OpenGL and DirectX 10, Linux with OpenGL, and macOS 13 Ventura or newer with OpenGL. The Linux requirement is stated precisely: glibc 2.27 or newer, which the README maps to SteamOS 3.0, Ubuntu 22.04, Debian 12 and CentOS 9. Mobile covers Android 6 at API 23 and iOS and iPadOS 12.2. Consoles are the part worth reading twice, because they are gated in a way the other platforms are not. The README lists PlayStation 4, PlayStation 5, Xbox across GDKX and XDK, and Nintendo Switch 1 and 2, but links them to a console access page and marks them as available for registered developers. That is a licensing boundary, not an engineering one. The code targets those machines; the permission to ship on them comes from the platform holder. Graphics backends are also mid-migration. The README carries a note that Vulkan and DirectX 12 support is being added in preview for 3.8.5, and the footnotes qualify both as experimental implementations available to source code users. So the shipping story for desktop is OpenGL, with DirectX 10 as the Windows alternative, and the newer backends exist but are not what the packaged framework gives you by default. Designing around that is straightforward as long as you know it in advance. ## No editor: the content pipeline is the workflow MonoGame has no integrated development environment and no built-in art or audio tooling. The repository makes the shape of the work explicit: `MonoGame.Framework.Content.Pipeline/` is its own project, and the release notes for v3.8.5 show it getting real attention. That release includes a fix for a build error where the Effect Compiler referenced the pipeline wrongly, plus a change adding a version to the mgcb output and a fix to the usage name output. A `mgcb` file is the content build description, and getting its version stamped correctly matters because that file is how your assets are compiled. This is the single biggest difference from Unity or Godot for someone arriving cold. There is no drag an asset into a scene workflow. Content is described in a project file, compiled by the pipeline tool, and loaded at runtime. The AutoPong sample is described in the README as a short sample project making the classic game of pong with generated sound effects in about 300 lines of code, which is a reasonable way to see the whole loop without committing to a large codebase. The rest of the official sample set covers the common genres: Platformer2D pulled from the original XNA samples and upgraded, NeonShooter as a graphically intensive twin-stick shooter with particle effects and save data, and ShipGame as a 3D Descent clone from the XNA archives. These live in the separate MonoGame.Samples repository and are pinned to the 3.8.2 branch, so the samples trail the framework by a patch or two. That is normal and mostly harmless, but it does mean the samples are not always running the exact version you install. ## Where the 3.8.5 release line actually went The release history says something specific about where the project is spending its effort. Three tags appear near the top: v3.8.5-preview.7, v3.8.5 on 2026-07-15, and v3.8.5.1 on 2026-08-14. The presence of numbered previews before a stable tag is a sign of a release process that tests its platform builds before declaring them done. The v3.8.5 changelog lists DirectX 12 support, native framework .NET Standard 2.1 support, and a Mojo fix. Alongside those are the small ones that tell you about the shape of the codebase: a `NO_AUDIO` switch to build without the audio subsystem, improvements to `WineHelper.cs`, and an SDL mapping added for Key 35, which is the 102-key backslash or UK pound key. Someone hit a keyboard that the mapping table did not describe, and it got fixed. That is what a mature input layer looks like in a changelog. The default branch is `develop`, not `main`, and the last push was on 2026-09-21, which is recent. The repository is not archived. It carries `CHANGELOG.md`, `CONTRIBUTING.md`, `CODESTYLE.md`, `Tests/` and `CI` configuration in `.github/`, plus `AGENTS.MD` and `CLAUDE.md`, which are unusual files to find in a game engine and suggest a deliberate approach to automated contribution. There is also `THIRD-PARTY-NOTICES.txt`, which matters because native backends pull in platform SDKs. ## The licensing question the README does not answer The repository contains `LICENSE.txt`, but GitHub does not classify the project under a recognised licence identifier for this repository, so the specifics of what you may ship are not settled by the README. That is a real gap for anyone planning a commercial release, and the sensible move is to read `LICENSE.txt` and `THIRD-PARTY-NOTICES.txt` directly rather than assume a permissive default. Consoles add their own terms on top regardless of the framework licence, which is why the README routes console access through a registration page. The comparison people actually search for is against Unity and Godot, and the honest framing is that these are not the same category of tool. Unity and Godot are editors plus engines, with asset stores, visual scene construction and built-in build targets. MonoGame is the framework layer: you get a window, a sprite batcher, content compilation and input, and you assemble everything above that yourself. In exchange you keep control of your build pipeline and your project format, and you write C# rather than learning a new scripting language. That trade suits a team with existing C# skill and a preference for owning its pipeline. It does not suit someone whose goal is to open an editor and have a character on screen this afternoon. The `Templates/` directory in the tree suggests the project offers starting points rather than a visual editor, which is the same conclusion from a different direction. ## Conclusion MonoGame makes sense for a specific kind of team: C# developers who already know the XNA style of API, who want to own their build pipeline, and who are willing to own content compilation and platform provisioning themselves. Celeste and Stardew Valley are the proof that the abstraction can carry a commercial release, and the last push on 2026-09-21 shows the 3.8.5 line is still moving. What you give up going this route is the editor, the asset store and the console self-service: PlayStation, Xbox and Switch access sits behind registration, and content is built by a separate pipeline tool rather than imported in an IDE. Start with the AutoPong sample, which the README describes as about 300 lines, then read REQUIREMENTS.md and the per-platform solution files before committing a project to it. ## FAQ ### Is MonoGame better than Unity? They sit at different layers. Unity bundles an editor, an engine, an asset store and managed build targets for every platform, whereas MonoGame is a framework library that gives you a window, input, a sprite batcher and a content pipeline, and leaves scene construction and project assembly to you. MonoGame suits a team that already writes C# and wants to own its build pipeline; Unity suits a team that wants visual tooling. ### Is MonoGame better than Godot? The real difference is language and tooling. Godot ships its own editor and GDScript, with C# available as an option, while MonoGame has no editor at all and expects C# throughout, with content compiled through the separate MonoGame.Framework.Content.Pipeline project. If you want a visual editor and rapid iteration, Godot is the closer fit; if you want a code-first C# framework you build from source, MonoGame is. ### Which games use MonoGame? The README names Streets of Rage 4, Carrion, Celeste and Stardew Valley as games built with MonoGame, and points to a longer showcase list on the project site. It also credits the Platformer2D, ShipGame and AutoPong sample projects as derived from the original XNA sample collection. ### What is MonoGame exactly, and is it good for beginners? MonoGame is an open-source .NET framework in C#, reimplementing Microsoft's discontinued XNA Framework, for desktop, mobile and registered console targets. Beginners get official samples such as AutoPong, which the README describes as about 300 lines of code, plus platform-specific getting started guides, but there is no editor, so the first real step is learning how the content pipeline project compiles your assets. ## Sources - [Issues](https://github.com/MonoGame/MonoGame/issues) - [MonoGame/MonoGame on GitHub](https://github.com/MonoGame/MonoGame) - [Project website](http://www.monogame.net) - [README](https://github.com/MonoGame/MonoGame/blob/develop/README.md) - [Releases](https://github.com/MonoGame/MonoGame/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/monogame-monogame