[sloopy543]

For context, it took me about a year of learning in my spare time to get to place where I could do my own cross-platform game engine, and some of that time was spent doing the code for the game itself.

What exactly is the expectation here? Would it have taken that much less time to learn the little nuances of Unity that folks here are complaining about?

Also for context, my full-time job is demanding, and I have a lot of outdoor hobbies like snowboarding and mountain biking. I bet if I were even more focused, I would have learned it faster.

It's not a big deal. You're already expending effort learning Unity/Unreal. It's only a little more effort to do your own thing. You might enjoy it

[johnnyanmac]

big difference is teams. If you're fine working by yourself, then an engine where you have 100% knowledge scope is great.

The moment you introduce another dev or artist or any individual that needs source access to work on your game, you'll probably have them hitting every pain point mentioned in the article and more. Why's your UI buggy (or does it even exist?), why's rendering this thing slow? So time is spent teaching them (and there's likely zero help on the internet unlike Unity/Unreal), or making tools/bugfixes to accomadate for them. i.e. less time on the actual game.

Hence the mantra: make games, not engines. If you like making engines, that's a good reason in and of itself to ignore that mantra. But if your goal is to make a game, then you shouldn't have to worry about the nitty gritty until it needs to be addressed.

[sloopy543]

It's funny because I have the same mantra. Make games not engines.

I focus on making the game, and the engine is the thing left over at the end.

But in so many ways, I have learned that a really productive game engine programmer should be spending his/her time building tools for the team. That's kind of the point.

You're making these tools that unlock the creativity of others, so they can help you with the team's creative vision.

I would expect any programmer I hire to be a problem solver, first and foremost, the kind of person who wouldn't need hand holding to modify the engine. I would hire people who I expect to make sensible decisions.

That's going to rule out a lot of people, and that's fine. When it comes to hiring, I select. I don't instruct.