Thanks for the thoughts, but for the record, I use the word 'engine' very loosely to encompass frameworks like love2d and craftyjs, and APIs such as SDL, GLEW, and so on.
With that in mind, I'll make an educated disagreement, because think about it: if you do decide to create an engine for yourself using something relatively low level like the aforementioned (or even lower if you're a masochist), unless you've written down every idea you have beforehand and know exactly how everything is going to work without making
any significant changes down the line, how do you know that this engine is going to satisfy your needs? It sounds easy on paper, but it's incredibly difficult to predict your future habits and organization style. You could simply change parts in your engine to fit the current game. Yes, this works, but then you're not focusing on creating the game. This is where the problem lies.
I feel as though I failed to stress this, because this is a
very important thing to realize:
a small toolkit or a couple of scripts one would use to avoid rewriting code is
far different from a full-blown engine. I'm talking about just spending days, weeks, maybe months on your own rendering system, realistic physics, networking, a level editor, and so on, vomiting in a bunch of garbage your future games may not even need, while possibly even missing some important bits your game
will need.
I'll also say that, again, the general population of game development won't nearly respect you as much for making your own engine, than if you spent the time working on that engine making games. Imagine if every post in this thread about an engine was instead a gif or screenshot about a different game? Wouldn't that make you much more exited for the creativity and progress coming out of the thread?
And I won't deny it: a game engine can be a fun little thing to work on as a hobby, and very much as a learning experience. But I personally believe that, what you learn from making a game engine, you'll learn eventually as you make more games, and that the knowledge you obtain isn't any more useful than just trivia. The most you'll usually need to know in technical terms is how to make a game loop, and a good bit of knowledge on
design patterns in game development. There's also stuff like memory management and efficiency, but if you aren't brain dead and/or loving handicapped (e.g. loading an image on every update, having 500,000 dynamic objects on-screen) low-level issues like this shouldn't be a problem, as most engines(/APIs/frameworks) handle this for you, or at least allow you to easily handle it on your own.
Continuing from my last point, in game design, the last thing you should be worrying about is the underlying technology behind your game. Depending on your needs, a good goal to aim for is 60 frames per second and cross-platform compatibility. At this point, it's fast and efficient enough, and the gameplay experience won't have changed for the end user who just wants a fun game, regardless of what you've used. You also need to think about the actual mechanics of the game, how to make it fair and balanced, difficult but not colossally impossible, visually appealing, depending on your graphical style, and
juice. Creating an engine almost always distracts from this.
On the subject of employment, I feel like this topic is somewhat irrelevant, but it's apparently not as obvious as it seems that game companies will value games more than game engines, because they can tell you understand how to create engaging interactive experiences, but a basic understanding of a game loop won't impress anyone. Games like Dust: An Elysian Tail, Freedom Planet, and Distance (racing game from refract) are what get people hired. The engines and tech behind these has to be massive (even in Distance's use case, Unity) but just showing off the tech itself instead of what you can really do with it, you won't get very far. On the flip side, if you're being hired because of your work on engines and/or game architecture, you simply aren't a game developer, and your end goal isn't to create games. There are some special cases, but I won't go into detail.
I'll end this post off on this, and by now, I hope I will have made myself clear. Keep in mind that this is in the perspective of game development, and nothing more. The goal here is to create games. The engines(/APIs/frameworks) available allow you to do this and have given every tool you need to express your creativity in any language or environment you please. When the goal here is to create games, making an engine is, in my opinion, simply a complete waste of time. If there's some sort of quirk in the current engine(/API/framework), or some licensing issue, or just something under the hood that simply does not allow to use it, move to another, there are plenty available. Plus, the more tools you learn to use, the more tools you'll know how to learn and pick up quickly. Search and explore, because there are hella options out there.
With this in mind, I really,
really recommend you watch
this video, because it's incredibly insightful, informative, and eye-opening in some ways, and I gained a lot of my personal principles from this video and other similar resources.
