Why a game engine is best for new game developers

A few weeks ago I set out on an adventure to create the game I have always wanted to play (sound familiar? me and every indie game developer, basically).

As someone who has absolutely 0 game and platform development experience, it was a big task.

My journey here has been an interesting one. Believe it or not, I actually started my career in games. I was doing a Bachelor of Games and Interactive Entertainment at QUT in Brisbane, and about 80% of the way through that course I said games development wasn't for me.

I had my reasons, but the biggest one was the amount of effort and time it took to build a video game, only to have it launch and flop, which has happened for so many.

I mean think about it, to make a game, you need an incredible amount of talent and knowledge to build it, or you need a team.

You need:

• Art
• Sounds
• Lore, and story-telling
• Programming
• And more.

That to me, is a big ask if you're looking for a career to fulfill your livelihood.

That brings me to now, where I have a stable job, and I have found myself wanting to make a game for no commercial reason, but as a hobby and a game, I can one day play.

I think if this reason is the reason you find yourself wanting to make a game, then that's awesome.

Okay, so let's recap the last 2 weeks, and why I'm adjusting what I'm doing.

Learning C#

C# is one of the biggest languages for game development. Mostly because it is a predecessor to C++ and C. It eliminates a huge workload on the developer because we do not have to worry about memory management as much.

C# is used by quite a lot of the biggest game engines, like Unity, Unreal Engine, etc. Game Engines like Godot are making big noise, especially since it is open-source, but my issue with Godot is that it primarily uses it's own scripting language.

I personally do not want to learn a specific language for a general use. Specific language: GD Script, general use: game development.

This would basically mean, if for whatever reason I gave up web development (which will probably never happen), I'd then only know GD script and would need to find a job in Godot.

C# has many real world uses, outside of game development, so if I were to learn it purely for game development, at least I'd feel secure in knowing it's not a loss of memory if it wasn't something I wanted to continue.

C# is far different from the likes of PHP, which is to be expected. So it's proving to not really be a challenge, but when paired with my next point, is definitely a challenge.

MonoGame

MonoGame is an open-source framework inspired by Microsoft’s XNA, and it has a strong reputation for flexibility and power. It allows you to build games with minimal input from anyone else, which means you get full control over how things like rendering, input, and asset management are handled.

As someone who loves understanding how things work under the hood, MonoGame felt like a natural choice.

On paper, it sounded perfect: no hidden magic, no bloated editors, just pure code-driven development. I’d be able to implement my own systems, optimize performance to the last byte, and create something truly my own.

But here’s the problem: game development is a vastly different beast from traditional software development.

The Steep Learning Curve

MonoGame provides only the bare bones of what you need to create a game. Things like physics, animation, UI, and scene management have to be built from scratch or integrated from third-party libraries.

As a newcomer to game development, I quickly realized that while I understood the programming side, I lacked the specific knowledge needed to implement these systems.

Reinventing the Wheel

Many of the problems I encountered had already been solved in other engines. While building my own tools and systems sounded exciting at first, it became a massive time sink. Every hour spent debugging my custom movement system was an hour I wasn’t spending on the actual gameplay.

The issue that has plagued me for the last 2 days? The fact that I click on the middle of the tile, but the code moves me to the bottom right of the square, which to the player, is not where I asked for the character to move.

Instead of working on the skill system, adding experience, nice animations, etc, I instead found myself debugging code I did not even truly understand.

Time vs. Passion

Building a game is a marathon, not a sprint. The additional overhead of using MonoGame made me lose sight of what I was trying to achieve: creating a fun and engaging game. Instead of focusing on gameplay mechanics or narrative, I was buried in low-level details.

What now?

I've made the call to now switch to Unity. I do want to say though, MonoGame is a great framework and I will return to it in due time.

For now, I just need to spend less time learning how to build the basics of game development (camera, movement, physics) and let an engine do that for me while I can focus on learning how to build features and gameplay, while also learning C#.

I just don't want to have to deal with the small things that should not be hard, but they are due to my lack of knowledge and game experience.

Like why should loading a map/tilemap/tileset be hard? Why do I need to use a program called Tiled, which then exports into xml/json, which I then have to load into my project using a JSON parser, to then have an issue because Tiled has some itenegers that go beyond the 32 bit limit?

It shouldn't and I shouldn't. I'd rather just place the tiles on the map, and then press play. That way I can focus on letting you touch the objects and not dealing and parsing different layers.

Anyway, just thought I'd write this down incase it sheds some light on my alpha decision to code a game from scratch, only to realise I am not experience enough in game development to do that...