Five Lessons I Learned After Using Monogame for Over a Year

These are the five most important lessons I learned after using Monogame for over a year, creating three video games with it and some side projects.

[@JDoucette]

I always add code to force a slowdown syndrome effect where no Update is called without a Draw. The natural Draw skip assumes the slowdown is from graphics. XNA didn't consider most indie programmers would make slow CPU code and the GPU would eat up anything they could throw at the Xbox 360 or PC. This causes a feedback loop where you miss more and more Draw calls until it reaches the lowest limit of 2 frames per second, and then the game jumps ahead with a Draw call for dozens of Update. Your character is now on the other side of the screen suddenly. 😊

[@embergamedev]

Thanks for this video! Diving into Monogame after using Unity since 2015. Before that I first started learning programming with XNA (had no clue what I was doing back then). It's really neat to jump back into a framework with a ton more experience over a decade later. But wanted to lookup some pitfalls to avoid early on and this video was perfect for that!

[@realrickyshea]

Good info. #5 is one I learned programming games in general, but the other four were new. I'm gonna have to look into state machines now.

[@computerhobbyists3070]

Thanks! The Monogame Mastery book uses a state machine in the video game it shows you how to build.

[@computersciencestudentriverbat]

Great info for beginners and experts alike. Learning Monogame/C# is full little "gotchas" that require a keen eye in your code and your design overall.

[@formidogames]

Some good lessons overall, Layer Depth defo helps organise sprites better. I've found that rule 3 can't always be strictly followed depending on the complexity of your game. For example you can't change the Effect/Shader you pass to the renderer without calling additional .Begin() + .End().

[@computerhobbyists3070]

Thanks! I haven't played with effects or shaders much, so I didn't think of that.

[@ar_xiv]

Unsure if you can change the Wrap or Filter modes either...

[@bnooper]

Great tips. By the way, separating logic code from drawing code is not only recommend for the reason you mentioned. It's also recommend in cases when drawing is unnecessary (like on a server where there's not point to draw as you just need to receive input from the clients) in order to reduce GPU strain.

[@computerhobbyists3070]

Thanks!

[@clarencesmith2060]

I happen to be obsessive when it comes to lesson #6. It might be a good a thing generally speaking. But having an unfixed bug will often prevent me from going to sleep. It's rather annoying.

[@computerhobbyists3070]

Same here.

[@alexale5488]

Here's a seventh one from me :
Stop searching for comparisons between programming languages or frameworks day and night !
Just pick one.
I say this because I was obsessed with finding the most performant and pleasant technology to work with but such this doesn't exist. Each framework or programming language has flaws and ups.

[@Yogesh55554]

Where you find monogame tutorial

[@computerhobbyists3070]

docs.monogame.net/articles/tutorials.html

[@ChaoslichtShadow]

Nice. Thanks for sharing your lessons :D

[@computerhobbyists3070]

You're welcome!

[@LeonardoTx1000]

Well, separating different systems inside different Draw batches is not really a bad thing, for example: you could separate game rendering inside a Begin()+End() and the game UI inside a different one... As long as you draw stuff in batches you should be gtg

[@genarponik4680]

Cool. Also have you ever heard of OpenTK?

[@computerhobbyists3070]

I've heard of it, but haven't used it. It sounds interesting though.

[@NitrosS]

2:05 The book man of game mastery??? Can you tell me the name of that book??

[@computerhobbyists3070]

The book is called Monogame Mastery.

[@sergesolkatt]

❤