If Microsoft hadn't killed XNA (what MonoGame is based on) a decade ago, they could be packaging it with Copilot right now as the ideal code-first AI-assisted game engine. Easy to use, easy to test, no visual editor where AI will struggle like with Unity/Unreal/Godot.
I am automating Unity with headless method invocation of agent authored editor scripts. I don't think "struggle" is the word I'd use to describe how GPT5.4 is currently performing.
I can tell the agent things like "iterate over all scenes. Wrap lightmap baking in a 5 minute timeout. Identify all scenes that exceed baking time. Inspect the scene objects and identify static geometry with poorly configured light map scale relative to their world space extents."
For Lazarus (an IDE with visual components similar to Delphi) I switched to code-first components and did away with the form files. You can probably do this with all of these frameworks.
We’re building an AI agent for Delphi — and a major part is it supporting visual form editing. It works. You can see the form change live in the designer as the AI does its stuff.
I used Monogame back when it was a proprietary framework called XNA developed at Microsoft.
You used to be able to use XNA to build Indie games for the Xbox 360, hard to believe, but this is going on 15 years ago at this point.
I built two indie games and made a couple of hundred bucks back when I was in High School. It's actually what got me into programming in the first place.
I'm happy to see that XNA became Monogame, it's one of the best frameworks I've ever used for gamedev.
Same here (minus the making any money). XNA is how I started learning graphics programming and started my interest in things like physics engines. Shawn Hargreaves had great blog posts on gamedev back then, too.
Just an FYI, Stride isn't related to MonoGame or XNA. Stride was originally Paradox (and then Xenko) made by Silicon Studio. They eventually open sourced it and let the community take over.
The lead architect (I think) of Xenko also wrote SharpDX which MonoGame used for a while though.
Haven’t used the engine specifically, but seems to be a cool project. I have used the Stride renderer which is embedded in VVVV, a live multimedia node-based language, which makes it interesting that you can extract and reuse such large components from the engine.
I built a full WinUI app with no visual editor, just XAML and code. The layout was entirely in my head. Now I do the same with terminal UIs on Linux, pure code with fluent builders.
Once you internalize the layout model, a visual editor mostly slows you down. Code-first gives you full control, clean diffs, and composability.
That said, for complex layouts you still need to run and visually review, no one gets nested grids pixel-perfect from memory alone.
There isn't really a comparison to be made between MonoGame and Godot. MonoGame is for programmers. Godot is for people who want to make games but don't care for programming and would rather use a GUI for development. Godot locks you into the Godot way of doing things. MonoGame is a thin cross-platform abstraction over platform APIs for sprite rendering, audio playback, input, and font, leaving you to build your game engine yourself however you like.
I think the greatest flaw in MonoGame, however, is that their cross-platform abstraction notably excludes web. Given how relatively thin MonoGame is, I think you're better off building your own framework that supports compiling to WASM as well, if you have any experience as a developer already. It is what I did and took some effort but was pretty well doable and didn't take all that long, and the payoff of being able to share your games instantly in the browser for anyone to play with just a click of a link is so worth it.
The other notable flaw in MonoGame is that the content pipeline thing it has is horrendous. When I tried it, I ended up simply bypassing using that pipeline at all. They are currently in the process of reworking it completely, I believe, but I'm not sure when that's supposed to release.
Maybe the value in MonoGame is that it does support consoles, though; I have no idea what developing for console is like, and only target web/computer/phone OS platforms myself.
> Godot is for people who want to make games but don't care for programming and would rather use a GUI for development.
You can write a lot of code when using Godot and mix that with capabilities provided by their editor.
You never have to use editor features, but can use them to avoid wasting time reinventing the wheel.
Your comment is like saying that game engines are used by people who don't care for programming and would rather make a call to handle physics interactions.
>Godot locks you into the Godot way of doing things. MonoGame is a thin cross-platform abstraction over platform APIs for sprite rendering, audio playback, input, and font, leaving you to build your game engine yourself however you like.
What are the capabilities needed for Stardew Valley? Drawing 2d sprites. Playing audio? That's a pretty low bar to reach. MonoGame doesn't even support animated sprites. You have to build support for them yourself. That sounds like a pretty low bar.
I am automating Unity with headless method invocation of agent authored editor scripts. I don't think "struggle" is the word I'd use to describe how GPT5.4 is currently performing.
I can tell the agent things like "iterate over all scenes. Wrap lightmap baking in a 5 minute timeout. Identify all scenes that exceed baking time. Inspect the scene objects and identify static geometry with poorly configured light map scale relative to their world space extents."
It’s not publicly available yet but has an active group of beta testers. https://www.remobjects.com/codebot/delphi.aspx
Never mind, found this in the docs: https://fna-xna.github.io/docs/appendix/Appendix-A%3A-Native...
MonoGame is trying to evolve XNA in small ways.
For a new project I would pick MonoGame.
I've been happy with monogame when I used it in the past. I'm pretty sure Celeste was made with FNA
It’s really good, also it was very cool as a junior developer to see the code for the methods I used.
You used to be able to use XNA to build Indie games for the Xbox 360, hard to believe, but this is going on 15 years ago at this point.
I built two indie games and made a couple of hundred bucks back when I was in High School. It's actually what got me into programming in the first place.
I'm happy to see that XNA became Monogame, it's one of the best frameworks I've ever used for gamedev.
The lead architect (I think) of Xenko also wrote SharpDX which MonoGame used for a while though.
I wonder how it compares, if at all, with Godot nowadays.
In fact RayLib has C# bindings so worth considering these two.
They exist at different abstraction layers, so not really directly comparable.
I think the greatest flaw in MonoGame, however, is that their cross-platform abstraction notably excludes web. Given how relatively thin MonoGame is, I think you're better off building your own framework that supports compiling to WASM as well, if you have any experience as a developer already. It is what I did and took some effort but was pretty well doable and didn't take all that long, and the payoff of being able to share your games instantly in the browser for anyone to play with just a click of a link is so worth it.
The other notable flaw in MonoGame is that the content pipeline thing it has is horrendous. When I tried it, I ended up simply bypassing using that pipeline at all. They are currently in the process of reworking it completely, I believe, but I'm not sure when that's supposed to release.
Maybe the value in MonoGame is that it does support consoles, though; I have no idea what developing for console is like, and only target web/computer/phone OS platforms myself.
You can write a lot of code when using Godot and mix that with capabilities provided by their editor.
You never have to use editor features, but can use them to avoid wasting time reinventing the wheel.
Your comment is like saying that game engines are used by people who don't care for programming and would rather make a call to handle physics interactions.
That might be changing: https://github.com/godotengine/godot/pull/110863
Besides, there's a lot of value Unity, Unreal and Godot provide besides just the GUI in ways similar to and different from MonoGame.
I've been using KNI but it's been a real headache getting my game to run on itch.io.
It doesn't. Godot is a 3D game engine and editor. Monogame is more like SDL or Raylib: just a library to make writing games from scratch easier.