41–50 of 76 posts
Earlier quoted context omitted.
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.
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
The lead architect (I think) of Xenko also wrote SharpDX which MonoGame used for a while though.
What would be a direct equivalent in C++?
If you are wondering about the capabilities, Stardew Valley was made in MonoGame. I wonder how it compares, if at all, with Godot nowadays.
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…
I've been using KNI but it's been a real headache getting my game to run on itch.io.
Earlier quoted context omitted.
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…
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.
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.
Earlier quoted context omitted.
> 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 gam…
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…
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.
If you are wondering about the capabilities, Stardew Valley was made in MonoGame. I wonder how it compares, if at all, with Godot nowadays.
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…
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.
Earlier quoted context omitted.
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…
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.
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.
Switched to Unity, best choice ever.
For a more actively maintained XNA implementation, also worth looking at Ethan Lee's FNA: https://fna-xna.github.io/
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?
MonoGame is trying to evolve XNA in small ways.
For a new project I would pick MonoGame.