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."
No. Not yet, anyways. I maintain autonomy over source control at the moment. Headless activity is verified in a separate unity editor instance before I push any commits. I might look into source control tools once I get through perspective and orthographic screenshot tools. Giving the agent a way to see the final composed scene seems much more valuable than SCM automation right now.
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.
Right, good that you've got that going, congratulations to you and your team. Design time does make human development much easier, since you are able to see the working prototype run as you design it, not sure what the point is if AI is doing that, since the value is in making the development cycle shorter, which the AI has no use for.
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.
It's always funny to me that this metaphor is used to indicate a bad thing, but re-inventing the wheel is actually very valuable. Note that our vehicles do not run on stone wheels. Thank goodness we kept re-inventing wheels that were more suitable for our specific use cases! This metaphor is, therefore, exactly apt for describing off-the-shelf game engines. All of the big open game engines are heavy and make a ton of decisions for you that will not be optimal for your specific game, because they make generalized decisions necessary to support all kinds of games. This does save you time, and you can absolutely make games that are good enough with them, but it's ridiculous to me to describe making your own engine as wasting time. It's spending time to gain a benefit, which is a trade-off that is worth it for some and not necessary for others.
Are you going writing your own programming language as well? Can we call it Tolkien? Because you're making a game like J.R.R. Tolkien wrote books, and there's a reason nobody writes books the way he wrote his.
Writing your own engine is great if you want to learn how to write a game engine. Knowing how to make a game engine can be helpful when making a game, but it's not necessary to make a game. Further, if you want to learn how to make a game, it might be more worth your time to simply use an engine that already does all the things you need. That way your time and energy can be focused on making the game, which is what your goal is.
Being condescending or dismissive of tools that do everything your tools you're going out of your way to construct will have to do is... weird logic. Because the same argument goes all the way down. Why wouldn't you make your own text editor? Why wouldn't you make your own compiler? Why wouldn't you make your own kernel? Why wouldn't you make your own architecture? "If you wish to make a pie from scratch, you must first invent the universe."
The answer is: because we're human beings with limited lifespans. We must stand on the shoulders of giants to see further.
One person wrote books like JRR Tolkien. His name was JRR Tolkien, and those books are widely celebrated by millions of people as classics.
I don’t have any issue with people using an engine like Godot or Unity or RPG Maker or Unreal or anything else, but I do think that there can be value in “owning the entire stack” of a project, even if that means “reinventing the wheel”.
When I do a project involving HTTP, I could reach for Rails or something, it’s a valid enough and I certainly have done that plenty of times, but I often will work with a lower level protocol. Depending on the language I will use a more simple HTTP server thing like Axum with Rust, and other times I will go full epoll/Selector with a raw socket.
I do this for a variety of reasons, but the main one is that I can build my own framework that works in a way that I think and I don’t pull in a bunch of extra crap I don’t need. I can optimize the “hot paths” of my particular project without worrying about a one-size-fits-all you get for generic frameworks, I don’t have to worry as much about leaky abstractions, and I am intimately familiar with a much larger percentage of the codebase.
Tolkien was exceptional and dedicated his entire life to it. 99.99+% of all people do not possess such a combination of talent and focus and therefore end up having to use “shortcuts”.
> and there's a reason nobody writes books the way he wrote his
And there's a reason nobody came even close to his grandiose.
> Being condescending or dismissive of tools that do everything your tools you're going out of your way to construct will have to do is... weird logic.
They've merely pointed out that there's nothing wrong with reinventing tools, you're the one attacking them.
It sounds like you don't like programming. I am in the process of writing my own language/IDE/compiler on the side of making games, and have already written a dialect of C# with a compiler that transpiles it to legal C# for use in the meantime. I would, in fact, love to write my own OS if not for the fact that proprietary hardware vendors make it virtually impossible for anybody to create a new OS that runs on consumer hardware in the year 2026. If you gave me a trillion dollars with which to build a CPU factory, I'd jump at the chance to learn that too.
People who don't like programming, who wish to abstract it all away and "stand on the shoulders of giants"[1] without understanding anything about the giants, seem to view low-level code as a bogeyman. It doesn't take a lifetime to understand. To the contrary, I would argue that low-level code is easier to work with than working only with high-level code, because you can reason about it. The more you rely on abstractions you don't understand, the more impossible it becomes to effectively reason about anything, because your reasoning is glossing over the details that make things work. But reasoning about primitives, and the things built out of those primitives that you understand, is not actually nearly as hard as the people who just want to plop Javascript libraries together and stop thinking about it would believe.
In particular, when it comes to games, especially 2D games (which are what Godot and MonoGame are typically used for), it's really not that hard. Windows has an API for doing X, Y and Z with graphics. Linux has an API for doing X, Y, and Z for graphics. You write a wrapper that your game code calls that passes through calls to each of those APIs with an #if statement filtering for which OS you're running on. Rinse and repeat the other set of platforms, with a bit of extra finangling for API limitations on web and phone OSes. Rinse and repeat for audio, input, and font handling. It took less than a month of work for me to get a polished cross-platform system working on five platforms. Not because I'm a genius, but because it's seriously just not hard. There are a thousand tutorials and books you could pick from that will give you a rundown of exactly how to do it.
Then, for example, writing your own rudimentary 2D GUI map editor can literally be done in a day. Presumably you know how to code a main menu. Add an option to the main menu that changes the gamestate to State.MapEditor when selected. Set a keybind on this state where your arrow keys increment or decrement X/Y coordinates, a keybind to place tiles/objects, a keybind to cycle which object ID is selected, and a keybind that calls a function which serializes your map state to text and saves it to a file. A little bit more work for a moving camera viewport, but it's not that hard. Want more features, polish it more. When you fully understand the primitives your system is built with, adding new features can be done quickly and easily, because it's so easy to reason about compared to reasoning about code you've never read built with primitives you don't understand.
3D does up the difficulty level, but it's by no means unachievable, either. The content creator Tsoding is currently doing a semi-weekly challenge to build his own 3D game engine from scratch on video, and he's making great progress despite not spending that much time on it, a side project that gets a few hours a week.
The end result of all this is a codebase that is more performant, lightweight, easy to read, and very easy to extend. I think developing your own engine can actually save time in the long run (if you're willing to forego the instant gratification), because it's so easy to fix bugs and add new features when you have a complete mental map of your codebase and the primitives used to construct it. For example, I have a friend who used Godot to develop a game, and they've been plagued for months with a low percentage chance of fatal crashes on a boss that they are completely unable to identify and fix, and it's because they don't have a mental map of the engine code. It's simply not even possible for them to reason about what in the engine could be going wrong because they don't even know what the engine is actually doing.
[1] Another metaphor that is grossly mis-invoked, in my view. Do you think Isaac Newton did not understand the work of those that came before him? The great thing about giants is that by doing the hard work of exploring new concepts, they make it easier for everyone who comes after them to learn them. I think it's a bit intellectually lazy to put off the work of giants as something that should not, or even can not, be learned.
[2] "like J.R.R. Tolkien wrote books, and there's a reason nobody writes books the way he wrote his." It's a real shame more people don't, considering there has never been a fantasy work rivalling his in the nearly century since.
It sounds like you're talking about making an equivalent of Super Mario from the 80s, but modern games are in fact much more complex.
And no, just because people in the 80s enjoyed Super Mario doesn't mean it's the pinnacle of game design, and that there's no need to create anything more complex.
> It took less than a month of work for me to get a polished cross-platform system working on five platforms.
You simply don't know where the bugs and performance pitfalls are because you haven't encountered them, yet. That is especially true regarding consoles with their custom hardware and mobile devices with their abundance of cheap, often not well engineered hardware and sketchy drivers.
"Modern games" span a wide range of things. I develop solely 2D games, because I prefer 2D games over 3D games. I think that even today 2D games are more enjoyable than 3D games. That doesn't mean Super Mario Bros. That can mean Europa Universalis IV, it can mean Stardew Valley, it can mean Magic the Gathering Online, it can mean Hollow Knight, it can mean Slay the Spire, it can mean a huge variety of interesting and engaging games, none of which require 3D graphics. 2D games can be as complex as you'd like them to be, far more complex in game logic than a 3D shooter even. The more complex you'd like them to be, the easier it gets to implement them if you understand the primitives you're implementing them with. Imagine trying to optimize your data structures when you don't even know what an int32 is? There are real game developers in the world who don't know even that much. It is a great thing that off-the-shelf game engines provide a level of accessibility to allow anyone to develop games, but they do not represent the pinnacle of what can be achieved in software engineering. They are the exact opposite of it, in fact.
> You simply don't know where the bugs and performance pitfalls are because you haven't encountered them, yet.
What is your point? I profile my games and have detailed logging systems. If I or my users run into performance issues, I address them as I come across them. Understanding my codebase at a low level makes it significantly easier to dig into problems and investigate underlying root causes than anyone on Unity will ever be able to. If you use Unity, you are putting your complete faith that Unity has perfectly optimized X low-level problem away at the engine level. If they haven't, and you run into that issue in your game, you are completely fucked. I love being solely responsible for the defects in my games. That means I can fix them myself. The worst thing in the world in software development is when somebody else's fuck-up becomes your problem, and you can't fix it, so you have to implement some hacky workaround, if you can even figure out why the closed-source engine code you didn't write and can't read is behaving incorrectly to work around it in the first place. Sometimes that still happens anyways -- our hardware-OS stacks are built with tens or hundreds of millions of line of dogshit code, and you can't get around it if you want to create software for platforms people use, but you can at least remove as many dependencies on bad code you have no understanding of as possible.
You're already too late at that point, and you probably lost some players, that wanted to try your game and maybe would've even liked it.
And I'm not talking about gameplay logic bugs - I'm talking about issues caused by bad drivers or by not having intimate knowledge about the hardware.
> If you use Unity, you are putting your complete faith that Unity has perfectly optimized X low-level problem away at the engine level
Most major engines allow to bypass high-level abstractions either through scripts that access low-level systems (Unity) or by directly letting people modify the source code (Unreal Engine, Godot).
> I love being solely responsible for the defects in my games.
> by directly letting people modify the source code (Unreal Engine, Godot).
Unreal is not open source, and while Godot is, I would wager 90% of its users never even look at the source code. It very specifically attracts people who want an easy way to make games without prior expertise.
> Players do not care about that.
Users don't care about much when it comes to software quality, honestly. They accept 20 FPS, slow loading, bug-riddled games that consume +20gb ram and +100gb more disk space than necessary. They may complain about a game if it gets bad enough, but they still buy and play those games. My games are significantly more optimized than most. They aren't perfect, but they don't need to be. They don't even need to be as optimized as I have made them, it's mostly just a point of pride and making the kind of software I want to see in the world. I think the only way you lose a player on technical points is if they literally cannot boot your game, but those issues plague engine games too. I had driver issues myself crashing on boot with an UE5 game two weeks ago.
>Note that our vehicles do not run on stone wheels. Thank goodness we kept re-inventing wheels that were more suitable for our specific use cases!
Improving a wheel design does not require reinventing it. The people who designed the car wheel were able to look at previous designs of wheels instead of needing to invent the wheel themselves.
So too with game engine design, where you have dozens of designs and hundreds of tutorials to learn from in the building of your own. It is seriously funny that no matter how you try to contort the metaphor, it continues to fit perfectly in a way that indicates it is not actually a bad thing.
>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.
To be clear, the framework I built is independent of the MonoGame framework. As for how it was built, it's relatively straightforward. There are three layers: platform layer, framework layer, and the game layer. On the platform layer, I started by implementing a basic hello world-tier game loop using Win32 window/messaging APIs, OpenGL for graphics rendering, and OpenAL for audio playback. Then I wrote tidy wrapper layer functions for calling into the platform layer, with better ergonomics/readability, which the game layer calls. Then, I began adding WASM APIs at the platform layer, with branching #if statements in the framework layer that control whether src\platform\win32 or src\platform\wasm functions are called based on build target. In this way, the game code remained unchanged but support for web was seamlessly added (with some pain in adjusting the wrapper APIs to handle the large differences in Win32 and web APIs). Then repeated this process for each additional platform. The primary csproj is set up to branch into different csprojs per build target, with one using the Microsoft.NET.Sdk.WebAssembly project SDK, etc. Over time, I expanded features of the platform layer and wrapper layer as they were needed.
For the game I had already made progress on when trying MonoGame, I had already written a wrapper layer over the MonoGame APIs even before I had started on my own framework. My new framework wrapper layer was designed as similarly as possible, so transitioning my game code to the new framework was mostly painless, and only required adjusting the shape of some rendering/audio/input calls here and there.
I’m not the commenter that you asked, but I have also built a cross platform game framework with backends for SDLGPU and WebGL. The answer to your question is pretty basic. AI did it for me.
I asked it to create a canvas-like API, noting that it should create platform independent code. The canvas API populates arrays for vertices, indices, and other relevant things relating to draw batches. My game is built on top of this platform independent canvas code, and is itself platform independent.
Then you have the platform code, which simply reads the memory of those arrays and does what it needs to do to draw it in its environment. I have barely looked at the platform code but it seems to just work, and it is really performant. It around 1000 lines of code for the web target. The key is to use shared memory as the bridge between the compiled WASM code and the platform code for draw calls. As I said, it’s mostly just arrays of vertices, texture ids, and indices.
It took me some thinking on how to define textures in a platform independent way, but it all ended up working well. I bounced some ideas with the AI to come up with a solution just using ids.
From there I just kept adding more features, FMOD support, shaders, etc.
Edit: Oops, I misread that your comment was referring specifically to getting Monogame on web. I thought I’d leave it here anyway though because it might help you. The key insight for me was that the canvas API (and Monogame as well) is just batching up vertices, indices, into draw calls, before the platform specific stuff happens. I realised this after investigating how the Spine animation software was able to achieve so much cross platform support (it’s just providing triangles with texture ids to platform code). You don’t need any concept of a platform to represent the entirety of your games as triangles associated with texture ids in memory.
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’m old enough to remember and toy with the now long-dead XNA. It was lots of fun, and gave a lot of us students versed with C# a sort of first-hand exposure with the .NET. If only (the old) Microsoft wasn’t so stupid, short-sighted, and selfish at the time.
It is kind of nice for indie games, unfortunately it is kind of stuck in what XNA 4.0 had as API surface.
And it used to be there was still some dependency on old XNA plugins for assets pipeline on Visual Studio.
No idea where this stands now.
However it was yet another example of community standing up for the anti-.NET sentiment at Windows/XBox teams, when the persons involved left XBox team, XNA was quickly replaced by DirectX TK.
We used Monogame at a previous company and it's a nightmare to be productive in it. The lack of any kind of an editor makes any kind of dev a nightmare: 3d adjustments? Good luck, guess it.. UI adjustments: good luck, try it 300 times until you get it right.
This comment makes less sense if you are familiar with CSS. Web developers don't have to guess 300 times to make UI adjustments, despite having no direct editor. If this was a problem you should have programmed in better layout primitives.
Dev tools in the browser are a direct editor, sure you can't drag things around with the mouse, but you can edit values live and see them change. Big difference from recompiling to see changes.
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.
> 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."
That's fair. I suppose instead of saying "struggle" re the others I should have said "be even more effective" re XNA.
Quite curious about this. Does the agent gets its own repo and deliver with commits?
No. Not yet, anyways. I maintain autonomy over source control at the moment. Headless activity is verified in a separate unity editor instance before I push any commits. I might look into source control tools once I get through perspective and orthographic screenshot tools. Giving the agent a way to see the final composed scene seems much more valuable than SCM automation right now.
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.
It’s not publicly available yet but has an active group of beta testers. https://www.remobjects.com/codebot/delphi.aspx
Right, good that you've got that going, congratulations to you and your team. Design time does make human development much easier, since you are able to see the working prototype run as you design it, not sure what the point is if AI is doing that, since the value is in making the development cycle shorter, which the AI has no use for.
If they hadn't killed it, it would have a visual editor by now. Or worse, dominated by Maya integrations.
Microsoft's head died long time ago. Corpo parasite took control of the body completely.
For a more actively maintained XNA implementation, also worth looking at Ethan Lee's FNA: https://fna-xna.github.io/
How well does it support Linux + NativeAOT? Thanks in advance.
Never mind, found this in the docs: https://fna-xna.github.io/docs/appendix/Appendix-A%3A-Native...
I was trying to compare the two. At first glance, MonoGame has far more stars and recent commits. Or is it just in maintenance mode?
FNA is for porting /supporting XNA games with minimal changes.
MonoGame is trying to evolve XNA in small ways.
For a new project I would pick MonoGame.
I believe FNA is trying to be more loyal to the original XNA while my monogame tends to introduce new features.
I've been happy with monogame when I used it in the past. I'm pretty sure Celeste was made with FNA
You might be mistaken, the Monogame Github README cites Celeste as an example made with it.
Ah weird. Did a bit of searching and it looks like maybe it targeted multiple frameworks with the xna API. Including xna itself
https://www.pcgamingwiki.com/wiki/Celeste https://celeste.ink/wiki/Version_history
Several games used to target Monogame for consoles but XNA for PC, and later FNA for PC.
Monogame on PC used to be somewhat buggy in my hobbyist experience.
Oh interesting. I never hit any walls personally but I guess I didn't push that hard.
XNA was originally designed for XBox Live Arcade indie titles.
I used MonoGame to port my XNA games to other platforms.
It’s really good, also it was very cool as a junior developer to see the code for the methods I used.
I did the same. It was cool seeing some of the games I came up with back in the 360 days running on iPhone and Android devices.
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.
Always nostalgic for Cornflower Blue :)
Java equivalent: https://github.com/libgdx/libgdx
Also check out Stride3d https://github.com/stride3d/stride, which is a more full featured engine built on (i believe) Monogame. Runs on .net 10
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.
If you are wondering about the capabilities, Stardew Valley was made in MonoGame.
I wonder how it compares, if at all, with Godot nowadays.
MonoGame is more like a library than a game engine (a very loaded term nowadays). It's too different from Godot to make a comparison.
You can compare the idea of trying to make a game with a framework versus an engine rather than compare MonoGame and Godot directly.
Yep. MonoGame is closer to RayLib than Godot.
In fact RayLib has C# bindings so worth considering these two.
Monogames is closer to something like SDL, or Raylib, than Godot (which is more like unity/unreal engine, but thinner and lighter weight).
They exist at different abstraction layers, so not really directly comparable.
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.
> wasting time reinventing the wheel
It's always funny to me that this metaphor is used to indicate a bad thing, but re-inventing the wheel is actually very valuable. Note that our vehicles do not run on stone wheels. Thank goodness we kept re-inventing wheels that were more suitable for our specific use cases! This metaphor is, therefore, exactly apt for describing off-the-shelf game engines. All of the big open game engines are heavy and make a ton of decisions for you that will not be optimal for your specific game, because they make generalized decisions necessary to support all kinds of games. This does save you time, and you can absolutely make games that are good enough with them, but it's ridiculous to me to describe making your own engine as wasting time. It's spending time to gain a benefit, which is a trade-off that is worth it for some and not necessary for others.
Are you going writing your own programming language as well? Can we call it Tolkien? Because you're making a game like J.R.R. Tolkien wrote books, and there's a reason nobody writes books the way he wrote his.
Writing your own engine is great if you want to learn how to write a game engine. Knowing how to make a game engine can be helpful when making a game, but it's not necessary to make a game. Further, if you want to learn how to make a game, it might be more worth your time to simply use an engine that already does all the things you need. That way your time and energy can be focused on making the game, which is what your goal is.
Being condescending or dismissive of tools that do everything your tools you're going out of your way to construct will have to do is... weird logic. Because the same argument goes all the way down. Why wouldn't you make your own text editor? Why wouldn't you make your own compiler? Why wouldn't you make your own kernel? Why wouldn't you make your own architecture? "If you wish to make a pie from scratch, you must first invent the universe."
The answer is: because we're human beings with limited lifespans. We must stand on the shoulders of giants to see further.
One person wrote books like JRR Tolkien. His name was JRR Tolkien, and those books are widely celebrated by millions of people as classics.
I don’t have any issue with people using an engine like Godot or Unity or RPG Maker or Unreal or anything else, but I do think that there can be value in “owning the entire stack” of a project, even if that means “reinventing the wheel”.
When I do a project involving HTTP, I could reach for Rails or something, it’s a valid enough and I certainly have done that plenty of times, but I often will work with a lower level protocol. Depending on the language I will use a more simple HTTP server thing like Axum with Rust, and other times I will go full epoll/Selector with a raw socket.
I do this for a variety of reasons, but the main one is that I can build my own framework that works in a way that I think and I don’t pull in a bunch of extra crap I don’t need. I can optimize the “hot paths” of my particular project without worrying about a one-size-fits-all you get for generic frameworks, I don’t have to worry as much about leaky abstractions, and I am intimately familiar with a much larger percentage of the codebase.
There is value in both approaches.
Tolkien was exceptional and dedicated his entire life to it. 99.99+% of all people do not possess such a combination of talent and focus and therefore end up having to use “shortcuts”.
> and there's a reason nobody writes books the way he wrote his
And there's a reason nobody came even close to his grandiose.
> Being condescending or dismissive of tools that do everything your tools you're going out of your way to construct will have to do is... weird logic.
They've merely pointed out that there's nothing wrong with reinventing tools, you're the one attacking them.
Make your own programming language? Penny's Big Breakaway was created using a new programming language named Beef.
It sounds like you don't like programming. I am in the process of writing my own language/IDE/compiler on the side of making games, and have already written a dialect of C# with a compiler that transpiles it to legal C# for use in the meantime. I would, in fact, love to write my own OS if not for the fact that proprietary hardware vendors make it virtually impossible for anybody to create a new OS that runs on consumer hardware in the year 2026. If you gave me a trillion dollars with which to build a CPU factory, I'd jump at the chance to learn that too.
People who don't like programming, who wish to abstract it all away and "stand on the shoulders of giants"[1] without understanding anything about the giants, seem to view low-level code as a bogeyman. It doesn't take a lifetime to understand. To the contrary, I would argue that low-level code is easier to work with than working only with high-level code, because you can reason about it. The more you rely on abstractions you don't understand, the more impossible it becomes to effectively reason about anything, because your reasoning is glossing over the details that make things work. But reasoning about primitives, and the things built out of those primitives that you understand, is not actually nearly as hard as the people who just want to plop Javascript libraries together and stop thinking about it would believe.
In particular, when it comes to games, especially 2D games (which are what Godot and MonoGame are typically used for), it's really not that hard. Windows has an API for doing X, Y and Z with graphics. Linux has an API for doing X, Y, and Z for graphics. You write a wrapper that your game code calls that passes through calls to each of those APIs with an #if statement filtering for which OS you're running on. Rinse and repeat the other set of platforms, with a bit of extra finangling for API limitations on web and phone OSes. Rinse and repeat for audio, input, and font handling. It took less than a month of work for me to get a polished cross-platform system working on five platforms. Not because I'm a genius, but because it's seriously just not hard. There are a thousand tutorials and books you could pick from that will give you a rundown of exactly how to do it.
Then, for example, writing your own rudimentary 2D GUI map editor can literally be done in a day. Presumably you know how to code a main menu. Add an option to the main menu that changes the gamestate to State.MapEditor when selected. Set a keybind on this state where your arrow keys increment or decrement X/Y coordinates, a keybind to place tiles/objects, a keybind to cycle which object ID is selected, and a keybind that calls a function which serializes your map state to text and saves it to a file. A little bit more work for a moving camera viewport, but it's not that hard. Want more features, polish it more. When you fully understand the primitives your system is built with, adding new features can be done quickly and easily, because it's so easy to reason about compared to reasoning about code you've never read built with primitives you don't understand.
3D does up the difficulty level, but it's by no means unachievable, either. The content creator Tsoding is currently doing a semi-weekly challenge to build his own 3D game engine from scratch on video, and he's making great progress despite not spending that much time on it, a side project that gets a few hours a week.
The end result of all this is a codebase that is more performant, lightweight, easy to read, and very easy to extend. I think developing your own engine can actually save time in the long run (if you're willing to forego the instant gratification), because it's so easy to fix bugs and add new features when you have a complete mental map of your codebase and the primitives used to construct it. For example, I have a friend who used Godot to develop a game, and they've been plagued for months with a low percentage chance of fatal crashes on a boss that they are completely unable to identify and fix, and it's because they don't have a mental map of the engine code. It's simply not even possible for them to reason about what in the engine could be going wrong because they don't even know what the engine is actually doing.
[1] Another metaphor that is grossly mis-invoked, in my view. Do you think Isaac Newton did not understand the work of those that came before him? The great thing about giants is that by doing the hard work of exploring new concepts, they make it easier for everyone who comes after them to learn them. I think it's a bit intellectually lazy to put off the work of giants as something that should not, or even can not, be learned.
[2] "like J.R.R. Tolkien wrote books, and there's a reason nobody writes books the way he wrote his." It's a real shame more people don't, considering there has never been a fantasy work rivalling his in the nearly century since.
It sounds like you're talking about making an equivalent of Super Mario from the 80s, but modern games are in fact much more complex.
And no, just because people in the 80s enjoyed Super Mario doesn't mean it's the pinnacle of game design, and that there's no need to create anything more complex.
> It took less than a month of work for me to get a polished cross-platform system working on five platforms.
You simply don't know where the bugs and performance pitfalls are because you haven't encountered them, yet. That is especially true regarding consoles with their custom hardware and mobile devices with their abundance of cheap, often not well engineered hardware and sketchy drivers.
"Modern games" span a wide range of things. I develop solely 2D games, because I prefer 2D games over 3D games. I think that even today 2D games are more enjoyable than 3D games. That doesn't mean Super Mario Bros. That can mean Europa Universalis IV, it can mean Stardew Valley, it can mean Magic the Gathering Online, it can mean Hollow Knight, it can mean Slay the Spire, it can mean a huge variety of interesting and engaging games, none of which require 3D graphics. 2D games can be as complex as you'd like them to be, far more complex in game logic than a 3D shooter even. The more complex you'd like them to be, the easier it gets to implement them if you understand the primitives you're implementing them with. Imagine trying to optimize your data structures when you don't even know what an int32 is? There are real game developers in the world who don't know even that much. It is a great thing that off-the-shelf game engines provide a level of accessibility to allow anyone to develop games, but they do not represent the pinnacle of what can be achieved in software engineering. They are the exact opposite of it, in fact.
> You simply don't know where the bugs and performance pitfalls are because you haven't encountered them, yet.
What is your point? I profile my games and have detailed logging systems. If I or my users run into performance issues, I address them as I come across them. Understanding my codebase at a low level makes it significantly easier to dig into problems and investigate underlying root causes than anyone on Unity will ever be able to. If you use Unity, you are putting your complete faith that Unity has perfectly optimized X low-level problem away at the engine level. If they haven't, and you run into that issue in your game, you are completely fucked. I love being solely responsible for the defects in my games. That means I can fix them myself. The worst thing in the world in software development is when somebody else's fuck-up becomes your problem, and you can't fix it, so you have to implement some hacky workaround, if you can even figure out why the closed-source engine code you didn't write and can't read is behaving incorrectly to work around it in the first place. Sometimes that still happens anyways -- our hardware-OS stacks are built with tens or hundreds of millions of line of dogshit code, and you can't get around it if you want to create software for platforms people use, but you can at least remove as many dependencies on bad code you have no understanding of as possible.
> I address them as I come across them
You're already too late at that point, and you probably lost some players, that wanted to try your game and maybe would've even liked it.
And I'm not talking about gameplay logic bugs - I'm talking about issues caused by bad drivers or by not having intimate knowledge about the hardware.
> If you use Unity, you are putting your complete faith that Unity has perfectly optimized X low-level problem away at the engine level
Most major engines allow to bypass high-level abstractions either through scripts that access low-level systems (Unity) or by directly letting people modify the source code (Unreal Engine, Godot).
> I love being solely responsible for the defects in my games.
Players do not care about that.
> by directly letting people modify the source code (Unreal Engine, Godot).
Unreal is not open source, and while Godot is, I would wager 90% of its users never even look at the source code. It very specifically attracts people who want an easy way to make games without prior expertise.
> Players do not care about that.
Users don't care about much when it comes to software quality, honestly. They accept 20 FPS, slow loading, bug-riddled games that consume +20gb ram and +100gb more disk space than necessary. They may complain about a game if it gets bad enough, but they still buy and play those games. My games are significantly more optimized than most. They aren't perfect, but they don't need to be. They don't even need to be as optimized as I have made them, it's mostly just a point of pride and making the kind of software I want to see in the world. I think the only way you lose a player on technical points is if they literally cannot boot your game, but those issues plague engine games too. I had driver issues myself crashing on boot with an UE5 game two weeks ago.
>Note that our vehicles do not run on stone wheels. Thank goodness we kept re-inventing wheels that were more suitable for our specific use cases!
Improving a wheel design does not require reinventing it. The people who designed the car wheel were able to look at previous designs of wheels instead of needing to invent the wheel themselves.
So too with game engine design, where you have dozens of designs and hundreds of tutorials to learn from in the building of your own. It is seriously funny that no matter how you try to contort the metaphor, it continues to fit perfectly in a way that indicates it is not actually a bad thing.
I agree, but the strategy for building a new engine is different from the build vs buy strategy when you want to make a new game.
>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.
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.
Could you elaborate in how you've built your own framework for making your monogame project available in web?
I've been using KNI but it's been a real headache getting my game to run on itch.io.
To be clear, the framework I built is independent of the MonoGame framework. As for how it was built, it's relatively straightforward. There are three layers: platform layer, framework layer, and the game layer. On the platform layer, I started by implementing a basic hello world-tier game loop using Win32 window/messaging APIs, OpenGL for graphics rendering, and OpenAL for audio playback. Then I wrote tidy wrapper layer functions for calling into the platform layer, with better ergonomics/readability, which the game layer calls. Then, I began adding WASM APIs at the platform layer, with branching #if statements in the framework layer that control whether src\platform\win32 or src\platform\wasm functions are called based on build target. In this way, the game code remained unchanged but support for web was seamlessly added (with some pain in adjusting the wrapper APIs to handle the large differences in Win32 and web APIs). Then repeated this process for each additional platform. The primary csproj is set up to branch into different csprojs per build target, with one using the Microsoft.NET.Sdk.WebAssembly project SDK, etc. Over time, I expanded features of the platform layer and wrapper layer as they were needed.
For the game I had already made progress on when trying MonoGame, I had already written a wrapper layer over the MonoGame APIs even before I had started on my own framework. My new framework wrapper layer was designed as similarly as possible, so transitioning my game code to the new framework was mostly painless, and only required adjusting the shape of some rendering/audio/input calls here and there.
I’m not the commenter that you asked, but I have also built a cross platform game framework with backends for SDLGPU and WebGL. The answer to your question is pretty basic. AI did it for me.
I asked it to create a canvas-like API, noting that it should create platform independent code. The canvas API populates arrays for vertices, indices, and other relevant things relating to draw batches. My game is built on top of this platform independent canvas code, and is itself platform independent.
Then you have the platform code, which simply reads the memory of those arrays and does what it needs to do to draw it in its environment. I have barely looked at the platform code but it seems to just work, and it is really performant. It around 1000 lines of code for the web target. The key is to use shared memory as the bridge between the compiled WASM code and the platform code for draw calls. As I said, it’s mostly just arrays of vertices, texture ids, and indices.
It took me some thinking on how to define textures in a platform independent way, but it all ended up working well. I bounced some ideas with the AI to come up with a solution just using ids.
From there I just kept adding more features, FMOD support, shaders, etc.
Edit: Oops, I misread that your comment was referring specifically to getting Monogame on web. I thought I’d leave it here anyway though because it might help you. The key insight for me was that the canvas API (and Monogame as well) is just batching up vertices, indices, into draw calls, before the platform specific stuff happens. I realised this after investigating how the Spine animation software was able to achieve so much cross platform support (it’s just providing triangles with texture ids to platform code). You don’t need any concept of a platform to represent the entirety of your games as triangles associated with texture ids in memory.
> wonder how it compares, if at all, with Godot nowadays.
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.
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’m old enough to remember and toy with the now long-dead XNA. It was lots of fun, and gave a lot of us students versed with C# a sort of first-hand exposure with the .NET. If only (the old) Microsoft wasn’t so stupid, short-sighted, and selfish at the time.
This is a weird coincidence.
Yesterday I looked into Monogame, FNA and Raylib. Just always surprises me how reading something somewhere makes people do similar things.
It is kind of nice for indie games, unfortunately it is kind of stuck in what XNA 4.0 had as API surface.
And it used to be there was still some dependency on old XNA plugins for assets pipeline on Visual Studio.
No idea where this stands now.
However it was yet another example of community standing up for the anti-.NET sentiment at Windows/XBox teams, when the persons involved left XBox team, XNA was quickly replaced by DirectX TK.
"The billion dollar decision that launched XNA"
https://youtu.be/wJY8RhPHmUQ?is=jwDBVae8AhBH-ANB
https://walbourn.github.io/directxtk/
OpenBSD ran tons of MonoGame indie games thanks to it, it even had a wrapper in ports.
What would be a direct equivalent in C++?
SDL and Raylib are probably the closest C(++) analogues. Or SFML if you strictly want a library written in C++, I suppose.
And what would be an equivalent for Monogame-Extended utilities, which turns MonoGame really into a game engine (without an editor)?
DirectX TK, Microsoft's replacement to XNA, naturally it only does Windows and XBox.
We used Monogame at a previous company and it's a nightmare to be productive in it. The lack of any kind of an editor makes any kind of dev a nightmare: 3d adjustments? Good luck, guess it.. UI adjustments: good luck, try it 300 times until you get it right.
Switched to Unity, best choice ever.
This comment makes less sense if you are familiar with CSS. Web developers don't have to guess 300 times to make UI adjustments, despite having no direct editor. If this was a problem you should have programmed in better layout primitives.
Dev tools in the browser are a direct editor, sure you can't drag things around with the mouse, but you can edit values live and see them change. Big difference from recompiling to see changes.
You can but good CSS devs don't have to. They know pretty accurately what it will look like in code
With MonoGame you are supposed to use an editor for creating assets that you then load into the engine built by MonoGame.
Or you build your own editor using MonoGame.
MonoGame is quite different from editor-centric system like Unity and not a good fit for all teams / projects.
[dead]
[dead]