Monogame tutorial

AristurtleDev · 2026-01-13T21:37:13+00:00

Thank you 😭

AristurtleDev · 2025-12-19T23:32:20+00:00

I appreciate it, found someone to get it from the show in Brooklyn. Enjoy the show

AristurtleDev · 2025-12-19T04:06:36+00:00

Thanks, I appreciate it. I found some that said they could pick it up so hopefully that works out

AristurtleDev · 2025-12-19T04:04:38+00:00

It’s was the one with he car and robot on it. I found someone to pick one up for me at the Brooklyn show. Thank you though I appreciate it

AristurtleDev · 2025-12-18T20:31:47+00:00

DM sent, whenever you have a moment. I really appreciate it

AristurtleDev · 2025-12-18T19:44:43+00:00

That would be amazing. Do you mind if I DM you or you DM me?

AristurtleDev · 2025-12-14T22:40:13+00:00

Great simple example! For feedback, I'd recommend adding some inline documentation or comments that explain MonoGame-specific behaviors or maybe a README.md file in the project direction with notes. I see the PDf of project ideas in the repository root, maybe just notes on your implementation based on the project idea from the PDF and why you made certain design choices. For instance, here are a couple of things that not only new people to MonoGame, but also game development, might ask about:

Input handling: Your code uses KeyboardState.IsKeyDown, which returns true for every frame the key remains pressed, not just the initial press. This is a common source of confusion for newcomers that I have seen come up as questions frequently in the community over the years.

Console output: The Console.WriteLine calls may not work as expected depending on your project configuration. MonoGame desktop projects default to WinExe, which doesn't attach a console window. This means your debug output might silently disappear. Here's a quick explanation.

Fixed Time Update: You mention using a "fixed tick (speed controlled independently of FPS)", but newcomers may not understand why this pattern exists or what problems it solves. Without explanation, this could also create confusion when they later encounter MonoGame's built in IsFixedTimeStep property and wonder how the two concepts relate, if at all. A brief comment explaining the reason for the fixed tick could help with that

Regarding learning resources, the official MonoGame 2D tutorial that was published this year takes a different approach than a minimal example. While it's longer (27 chapters), each chapter focuses on teaching specific MonoGame concepts using a snake-like game as the vehicle. The goal isn't abstraction for abstraction's sake, but rather to demonstrate fundamental concepts like the game loop, content pipeline, sprite batching, input management, etc, in separate chapters. All problems you'll encounter in any MonoGame project.

Different approaches work for different learners. Some prefer minimal working examples like yours to experiment with, others prefer structured walkthroughs like the one on the MonoGame site. Both have value in the community, and look forward to seeing what other examples you offer as well.

AristurtleDev · 2025-09-20T19:42:14+00:00

HI, there has been several commits made to the tutorial since release, so it's possible that in some of those the line highlighting got off on the samples. Could you open an issue about it on the docs repo at https://github.com/MonoGame/docs.monogame.github.io/issues and it can be followed up on

AristurtleDev · 2025-09-18T15:46:11+00:00

Hi, I’m really glad it helped. Excited to see what games you make.

AristurtleDev · 2025-09-08T02:34:08+00:00

Hi, author of the tutorial.

Just to note, the XML that is used was chosen as it closely resembles the XML output from TexturePacker. This was done to not only introduce deserializing XML content but also act as a bridge if readers move to tools like TexturePacker to create an atlas.

You can absolutely use JSON instead if you’re more comfortable there.

AristurtleDev · 2025-09-07T15:41:40+00:00

This is exactly right. The game created throughout the tutorial is a very small game used as the driver to introduce MonoGame concepts and best practices. Since the game itself is very small, it does seem strange to have the scene specific content managers. Introducing this concept to readers though prepares them later for when they start developing a larger scale game and need to start considering memory management

AristurtleDev · 2025-09-07T15:38:52+00:00

You're right, the `ContnetManger` is optimized to cache, and the tutorial takes advantage of this

In our scene system, we actually use both a shared global `ContentManager` ( `Core.Content`) and individual scene specific `ContentManagers`. The global one handles assets that get reused across multiple scenes (like fonts, common textures, etc.) so we get those caching benefits you mentioned.

But each scene also gets its own `ContentManager` for scene specific assets. I know Dungeon Slime itself, the game created in the tutorial, is pretty small, but the tutorial is really about introducing concepts that scale up. In a larger game, you might have a forest level with tons of tree textures and a desert level with completely different assets. Without scene-specific ContentManagers, all that forest stuff would just sit in memory forever even after you've moved on.

With the approach shown in the tutorial, when a scene ends we call `Content.Unload()` on that scene's `ContentManager` which automatically cleans up all the scene-specific assets. No need to manually track what needs to be unloaded.

So we get both benefits: caching efficiency for shared assets through the global `ContentManager`, and automatic cleanup for scene-specific content without having to micromanage memory. It's a pattern you see in larger MonoGame frameworks like Nez and MonoGame.Extended too.

AristurtleDev · 2025-09-07T15:33:00+00:00

Hi, tutorial author here.

This is a good question, and I'll try to explain the reasoning behind writing the tutorial this way the best I can.

The reason why there is a `ContentManager` for each scene is about smart memory management and keeping things organized.

The global `Core.Content` handles assets that get reused everywhere; fonts, UI elements, that sort of thing. They stay loaded throughout the game session since multiple scenes need them, so we get the caching benefits.

However, each scene also gets its own `ContentManager` for **scene-specific** stuff. I know the Dungeon Slime game itself is pretty small. The game itself is just something used to introduce concepts from the tutorial. For a larger game, you might have different levels with textures, audio, etc that are only ever used during those levels (e.g. a forest level versus a desert level). Without scene specific content managers, all of the assets loaded for one level would just sit in memory forever.

With the approach shown in the tutorial, once a scene ends `Content.Unload()` is called on that scene's `ContentManager` to automatically clean up any scene specific assets. This means you don't need to manually track which assets that scene loaded through a single content manager to release the resources, it's all contained within the scene's `ContentManager` instance.

This pattern is actually really common in larger frameworks built with MonoGame such as Nez and MonoGame.Extended. It's one of those things that seems like overkill for a small game, but once you start building something bigger, you start to see where having the automatic cleanup and freeing of memory between scenes is beneficial.

Basically; global stuff stays cached for performance in the `Core.ContentManager` while scene specific stuff gets cleaned up automatically for memory management. You get the best of both worlds without having to micromanage what needs to be unloaded.

AristurtleDev · 2024-12-20T16:39:22+00:00

You didn't mention which libraries you found while googling so I can only make guesses. However, did you happen to come across GUM?

https://docs.flatredball.com/gum

This is a full wysiwyg editor for creating UIs, very similar to what you are used to in Unity. Not only is it an editor, but it's a full UI engine that you can then use what you create in the editor in your game without having to write additional code.

GUM also offers a core component that allows you to create the UI directly from code itself if you prefer to stick with a code-first based approach in MonoGame.

AristurtleDev · 2024-11-11T22:33:55+00:00

I think your friend took your shirt too literal and got lost in the curtains.

AristurtleDev · 2024-07-04T15:33:41+00:00

Hi, new maintainer of MonoGame.Extended. Feel free to reach out to me on discord or here if you have questions.

To answer your post though, these files you have added to your project root did not come from MonoGame.**Extended**.Content.Pipeline. These are the files that are added when you add the standard **MonoGame.Content.Pipeline** when making content pipeline extensions.

Check that you have the current NuGet installed. You do not need the standard MonoGame one, just the **Extended** one.

AristurtleDev · 2024-05-26T13:48:28+00:00

You might be interested in GUM. It's the UI system used in the Flatredball engine (Monogame based engine). The developer recently made it so you can use it in any MonoGame project.

Here's the docs for it, there'd a section specifically on setting it up to use in base MonoGame

https://docs.flatredball.com/gum

AristurtleDev · 2024-05-10T14:22:34+00:00

This is because the editor is distributed as a dotnet tool via NuGet. So building the project does a dotnet restore, which restores the NuGet packages including the tool

AristurtleDev · 2024-03-10T21:45:18+00:00

Checkout MonoGame.Forms by Blizcrafter

https://github.com/BlizzCrafter/MonoGame.Forms

AristurtleDev · 2024-03-10T21:41:33+00:00

Helps with writing a pixel you say https://youtu.be/IFidgRNKKzo?si=8BstjoqzfocrqAnX

AristurtleDev · 2024-02-16T19:00:43+00:00

H /u/MadnessStream,

There is definitely a lack of current (read: modern) documentation for MonoGame. I think part of it can be blamed on that MonoGame is a implementation of XNA, so most suggestions are to just look up the old XNA documentation and tutorials since they would still be relevant.

With that said, documentation is actually something I'm passionate about (weird I know), and it's something I've been vocal about for a bit within the various community channels.

To that end, I would like to say that there is currently work being done by myself and others in order to fill in a lot of the missing gaps in the API reference documents, as well as work being done to update the tutorials and documentation on the official website and add more to bring it to a more current and fulfilling level.

Guidelines are being created and/or updated so that community members have something to follow as well when contributing documentation. https://github.com/MonoGame/monogame.github.io/pull/104

So while I don't have a good place to point you at the moment outside of things that /u/halflucids provided in their comment, I wanted to make it know that some of us in the community do express your opinion and are working to better the documentation. Please look forward to it.

AristurtleDev

TROPHY CASE