[hn_acc_2]

I definitely support making your own game engine if you enjoy it as a programmer.

But it shouldn't be a surprise that it's not the best choice for the most developers. Every moment you're debugging and improving the engine is another moment you could have been working on the game itself, because almost all engine improvements are orthogonal to improving the game experience.

So given a limited amount of time, you will always end up with a better and more complete game if you start with a batteries-included engine than if you roll your own.

Also the fact is most peoples' game ideas are very derivative and it would be overkill to reinvent the wheel by implementing your own engine for, say, a game that'd easily be made in Game Maker Studio

[sloopy543]

In my experience, it was easy... until I got to the part of my game that makes it unique. Then it went from easy to very very hard.

That's the thing about engines. They'll get you up and running quickly for basic stuff, but you'll be tearing out your hair when you need to do anything non-basic.

[megameter]

The way I put it is, "the engine isn't really done until the game is." So many polish features in games lead to new categories of assets, which in turn need new methods of rendering.

This is one of the multitude of reasons that so many older game devs reach for the C++ compiler; they don't know what the game will need, but they do know they can make the necessary modifications to ship if they approach it bottom-up.

[xsmasher]

Making your own game engine requires experience as well. If you've already used other engines, you'll have some idea of the "shape" that a UI library or texture loading system should take.

[sloopy543]

I had pretty much no experience when I started mine. "Shape" is an arbitrary thing. The shape of the tool should match the shape of your problem, and if you don't know what your problem is yet, you don't know what the best tool for it will look like.