MonoGame is cool and all, but...

From time to time, not seeing any progress in my game development learning, moments of doubt creep in, questioning whether the chosen direction is correct or if it would be better to start anew.

Usually, in such moments, I think about going back to basics, reminding myself of what it's like to be a programmer, perhaps opting for something like Mono Game where everything is written instead of clicking and dragging. Ah, those were the days 😉

So I bought the ebook "Monogame Mastery," a kind of introduction to game development in the mentioned engine framework. I bought it out of curiosity, promising at the same time to share my insights.

It's good to understand how a game works. A decade of web development has made any mathematical proficiency evaporate from me.

Every time I go back to the basic tutorials of the Godot engine, things go well initially, but then everything slows down and becomes discouraging. Only recently did I realize that these materials are more for people considering switching to the Godot engine rather than for beginning game developers. Not to mention that they lack some bird's-eye view to grasp all (not just basic) building blocks for game creation. You read about Godot’s signals, and nodes - but have to dig deep to learn about resources.

To some extent, I see the attractiveness of Mono Game in this - you get a basic game loop, some content pipeline, and the rest you have to write yourself. Sure, you'll understand how the whole game works, and then you'll find out how much that "rest" is that you have to write yourself.

Yet, excellently written chapters on particles or collision detection proved to me that I was looking for something else - a comprehensively written introduction to these concepts to understand them. Or even learn about their existence.

Long story short: I'm going back to Godot because I don't want to write the entire game from scratch, including the engine 😉

---

One thing stuck in my memory - the phrase 'Every time programmers want to reuse a piece of code - a new engine is created.' It's a cliché; anyone who has ever been interested in how legendary engines were created will say that. But this time, I looked at it from the perspective of a framework like Mono Game.

And it led me to an idea for a game engine 😉

If we assume that we are creating an engine dedicated to 2D graphics and that all games are essentially composed of reusable components - camera, controls, asset pipeline - which are nothing more than pieces of code to be reused, we could create an ideal engine for advanced beginners!

The Game Engine Maker (we can call it GEM for short) would gather this information and compose the engine itself, skipping unnecessary elements during the final compilation of the game. I suppose it would have its limitations, but it would be a product closer to Super Mario Maker than Godot, as its goal would be to respond to ideas like 'top-down action-adventure' or 'side-scrolling platformer' or 'side-scrolling jet fighter', etc. (who knows, you could even incorporate AI for an even faster start).

I admit, that if I had more competences, this could be my next project.

But for now, I'll go back to learning Godot.

And I leave the idea above for someone else to take!