Is it just me, or is open source picking up more steam than it's had for a while? Very happy to see all the initiatives, funding, and people & companies embracing it
From what I gather, Unity has recently made moves to lose the trust of all of their customers, and there is a massive exodus towards other game dev software/frameworks/etc.
Kind of, until they realize what Unity (or Unreal) offers, doesn't come only from late nights, and someone has to put money in for feature parity.
Anyway I really appreciate MonoGame folks carry on the XNA flag, after the people responsible for it on Microsoft lost to the DirectX/C++ group, hence DirectXTK as its replacement.
The biggest advantage Unity has over alternatives like Godot and MonoGame is the ecosystem around the engine, not the engine itself. Things like the asset store and the wealth of tutorials out there. It will take time for the ecosystems around open source engines to match or exceed that of Unity, but the more people leave Unity the faster that will happen.
An engine that also targets consoles and VR headsets, uses C# as the main language, has an AOT toolchain for it, thanks to HPC# subset also allows for low level engine code in C#, and naturally the graphical debugging tools for profiling and GPU.
It might be somewhat related but Unity and Monogame target very different developer experiences. Monogame is an alternative to low level frameworks like SDL/SFML/etc for C++. It's not a game engine.
The difference is that you get to code most of the engine as opposed to mostly coding gameplay. That's of course a significant trade-off. If you like being low level and understanding how things work and learning a ton then Monogame is the tool to use. If you strictly want to make a game and don't mind ramping on someone else's toolset to "go slow to go fast later" then Unity/Unreal/Godot are the tools.
Monogame shines when it comes to 2D games since 2D games require less specialized engine tools and most of the editors can be made quite easily for a 2D game and will teach you a lot. Don't get me wrong, it's capable of 3D but the experience will be much harder and unstable. You'll be much more at the mercy of outdated open source libraries for things like importing animations from your favorite 3D editor. Conversely, writing a library to import and load your own 2D animations can be done in an afternoon.
The showcase of games built in Monogame echo this with lots of heavy hitters and well-known 2D games and very few well-known 3D games.
This was a result of the MonoGame community having nervous feelings about the state of affairs around Unity and just changing ToS and charging installation fees. MonoGame always wanted to have a foundation to steer direction but didn't feel it was warranted until now. Until now, the community mostly agreed on what was needed and what was superficial. Just provide an XNA-compatible API that works on all platforms. Nothing more.
I remember playing Atom Zombie Smasherhttps://en.wikipedia.org/wiki/Atom_Zombie_Smasher more than 10 years ago and being slightly surprised that it was developed using .NET/Mono (not with MonoGame though). Nice to see game development with Mono is still going strong...
There's nothing to "support". That's why it's a standard. Mono will run MonoGame builds on platforms where Roslyn/Core won't. I can think of a couple. PS4 for example.
And you can build your game for Linux or MacOS too! There are some quirks with naming (i.e. you may have a few issues with case sensitive asset names), but it works surprisingly well. The former build option is also natively compatible with the Steam Deck.
Just to be clear, MonoGame has existed and been open source for a really long time now, and it's a mostly compatible successor to Microsoft's XNA; it's more of a platform abstraction library than a game engine, although it fills a really sweet spot between using engine and starting from scratch, IMO.
There's also FNA, which is more focused on being an accurate reimplementation of the original XNA on top of exclusively OSS libraries and open APIs, although you can use it to make new games as well. Some games have actually used both to target different platforms in the past, as MonoGame is arguably buggier.
I had a project I started in XNA, and I was surprised at how little effort it took to migrate to Monogame. Hardest part was really switching the build process.
Just note if you wrote it in XNA 3.x, you might need a guide as the modern version is more akin to v4.
Assuming you at one point upgraded to XNA4, it's not that hard. About 3 years ago I decided to see how hard it would be to get a game I released on Xbox Live Indie Games running on Monogame, and I had it building and showing the main menu in about 2 evenings of work, and worked out most of things that needed to be changed (namely storage and some Xbox Gamerprofile stuff, I believe) after about a week.
Had I known it would be that easy I would have done it years ago. Actually lead to me remaking the game in 3D and turning it into a proper sequel (which I'm still working on).
Yeah if you have an old XNA project in a folder, you can trivially port it to FNA usually in an hour or two. FNA is able to load all the .xnb files that were built by your project initially so you won't have to mess with content builders or anything.
Not sure about MonoGame. Way back when XNA was released it was a great step forward for indie development - a framework using an easy-to-use language that allowed publishing even for the Xbox 360 - that was a great step forward. It included solutions for every problem that tended to come up in gamedev - from audio to graphics, font rendering etc.
But it had a fair bit of downsides too - it had to have all content compiled into a proprietary format using a Visual Studio plug. The font rendering was blurry and had poor support for internationalization. And the ergonomics of its APIs left something to be desired.
MonoGame has essentially replicated XNA 4 wart for wart including the content pipeline. Development has been really slow on new features.
It definitely has its warts. I've been making a game using it and I've been annoyed how difficult certain things have been. 3D and cross-platform support in general isn't great (it's technically there, but any platform outside of Windows has a lot of hoops to jump through, at least in my experience).
But it's also one of the more lightweight and code-centric game development frameworks out there currently, and I do prefer that to working with a heavy bloated editor like Unity (which I've used professionally in the past). And as long as my game takes the warts into consideration, 95% or more of my time is just spent coding, not figuring things out the quirks of the framework or engine.
Like I had some issues getting some animations to import properly from Blender the other day (there's some video with like 100 views of someone who got something a bit different sort of kind of working, but I didn't feel like figuring out how to decode what they're doing and transpile that over to my needs), and just decided "Okay, I guess I'm not going to bother with making animations in Blender and only use static models instead. What I wanted it for isn't really that necessary anyway." And I'm only targeting Windows for now. I'll try to get other platforms working later, if ever (got it working on Steamdeck, at least).
It was also pretty disheartening to see almost zero development on Monogame over the past year (judging by its Github activity).
I have been considering giving Godot or Defold a try for my next game (Godot I was highly considering since it has XR support, and I've really wanted to make a VR-compatible game for a while now), but I'm hoping I can at some point jump back into Monogame once this Foundation gets into gear.
> But it's also one of the more lightweight and code-centric game development frameworks out there currently, and I do prefer that to working with a heavy bloated editor like Unity
I also started with XNA, and I quite enjoyed it. But this was back in 2012, and I felt the shift happening. I used Unity for several years, and always felt a sense of confusion when looking at someone else's implementation: should I look at the code? The scripts? How is the project structured? It can be quite a task.
In the last 6 months (shortly before the infamous Unity debacle) I started using Godot with C#. Like many, I can say that I quite like it. Related to your comment though, I tried going back to a code-first approach, and so far I have to say, it's going great. I have managed to create most of my scenes with scripts alone, and as far as I can tell, Godot is made for this. Everything that can be done in the editor can be done in code.
That's great to hear. Way back in the day I played around with libgdx and xna and they made sense to me.
The shift to unity killed any desire I had to try to make indie game experiments. The UI was confusing and I couldn't grok it. It just felt so alien to me.
Awesome to hear that you can use godot in a code first way. I might have to try and pick it up at some point when I have free time.
> And as long as my game takes the warts into consideration, 95% or more of my time is just spent coding, not figuring things out the quirks of the framework or engine.
Of course you don't spend time on warts if you know where they are and how to avoid them. The problem is learning that, which you apparently have, but then again, this can be said for any cumbersome tool.
It’s not included in the announcement post, so I’ll leave this here: MonoGame is one, open source framework for creating powerful cross-platform games.
Anyone who's interested in any XNA successors I'd highly recommend checking out FNA instead. It uses exclusively FOSS libraries, the maintainers are actively anti content pipeline (MonoGame actively invested time and resources into building their own version), and FNA's just all around more stable.
39 comments
[ 3.3 ms ] story [ 59.5 ms ] threadAnyway I really appreciate MonoGame folks carry on the XNA flag, after the people responsible for it on Microsoft lost to the DirectX/C++ group, hence DirectXTK as its replacement.
The difference is that you get to code most of the engine as opposed to mostly coding gameplay. That's of course a significant trade-off. If you like being low level and understanding how things work and learning a ton then Monogame is the tool to use. If you strictly want to make a game and don't mind ramping on someone else's toolset to "go slow to go fast later" then Unity/Unreal/Godot are the tools.
Monogame shines when it comes to 2D games since 2D games require less specialized engine tools and most of the editors can be made quite easily for a 2D game and will teach you a lot. Don't get me wrong, it's capable of 3D but the experience will be much harder and unstable. You'll be much more at the mercy of outdated open source libraries for things like importing animations from your favorite 3D editor. Conversely, writing a library to import and load your own 2D animations can be done in an afternoon.
The showcase of games built in Monogame echo this with lots of heavy hitters and well-known 2D games and very few well-known 3D games.
Glad to see it.
Thats pretty neat that its opensource.
Between this and Godot, I think indie developers and smaller professional studios will have options to choose from in the future.
[0]: https://monogame.net/showcase.html
There's also FNA, which is more focused on being an accurate reimplementation of the original XNA on top of exclusively OSS libraries and open APIs, although you can use it to make new games as well. Some games have actually used both to target different platforms in the past, as MonoGame is arguably buggier.
Just note if you wrote it in XNA 3.x, you might need a guide as the modern version is more akin to v4.
Had I known it would be that easy I would have done it years ago. Actually lead to me remaking the game in 3D and turning it into a proper sequel (which I'm still working on).
But it had a fair bit of downsides too - it had to have all content compiled into a proprietary format using a Visual Studio plug. The font rendering was blurry and had poor support for internationalization. And the ergonomics of its APIs left something to be desired.
MonoGame has essentially replicated XNA 4 wart for wart including the content pipeline. Development has been really slow on new features.
You can also run the content pipeline as a .NET tool outside of Visual Studio. It works on Linux too!
But it's also one of the more lightweight and code-centric game development frameworks out there currently, and I do prefer that to working with a heavy bloated editor like Unity (which I've used professionally in the past). And as long as my game takes the warts into consideration, 95% or more of my time is just spent coding, not figuring things out the quirks of the framework or engine.
Like I had some issues getting some animations to import properly from Blender the other day (there's some video with like 100 views of someone who got something a bit different sort of kind of working, but I didn't feel like figuring out how to decode what they're doing and transpile that over to my needs), and just decided "Okay, I guess I'm not going to bother with making animations in Blender and only use static models instead. What I wanted it for isn't really that necessary anyway." And I'm only targeting Windows for now. I'll try to get other platforms working later, if ever (got it working on Steamdeck, at least).
It was also pretty disheartening to see almost zero development on Monogame over the past year (judging by its Github activity).
I have been considering giving Godot or Defold a try for my next game (Godot I was highly considering since it has XR support, and I've really wanted to make a VR-compatible game for a while now), but I'm hoping I can at some point jump back into Monogame once this Foundation gets into gear.
I also started with XNA, and I quite enjoyed it. But this was back in 2012, and I felt the shift happening. I used Unity for several years, and always felt a sense of confusion when looking at someone else's implementation: should I look at the code? The scripts? How is the project structured? It can be quite a task.
In the last 6 months (shortly before the infamous Unity debacle) I started using Godot with C#. Like many, I can say that I quite like it. Related to your comment though, I tried going back to a code-first approach, and so far I have to say, it's going great. I have managed to create most of my scenes with scripts alone, and as far as I can tell, Godot is made for this. Everything that can be done in the editor can be done in code.
The shift to unity killed any desire I had to try to make indie game experiments. The UI was confusing and I couldn't grok it. It just felt so alien to me.
Awesome to hear that you can use godot in a code first way. I might have to try and pick it up at some point when I have free time.
Of course you don't spend time on warts if you know where they are and how to avoid them. The problem is learning that, which you apparently have, but then again, this can be said for any cumbersome tool.
This was intentional and beneficial in some aspects. So games could be ported easily. And existing team expertise could be leveraged.