Why I Don't Use Game Engines
This article is a response to the recent-ish news going on with the Unity game engine and them charging developers per game install. Of course, the common response for a FOSS advocate would say is "This is why you should be using Godot instead". Sure Godot is a better choice than Unity or Unreal and I suspect many Unity devs would switch to Godot over Unreal only because Godot actually supports C#, (Unity's scripting language) while Unreal only supports C++, UnrealScript, and Blueprints, but I think there is a deeper issue in this, just like with web development, modern game programmers only have a high-level knowledge of the inner workings of a game. Modern games are bloated and a huge contributing factor to that can be attributed to game engines. Modern game engines are complex because they are designed to be used for almost any game. This means unnecessary, bloated code. This is why even indie games may still struggle on older or lower-end computers. In worse cases, you have 2D games running on engines made for AAA 3D games. I personally believe that if a game looks like it runs on a potato than it SHOULD run on a potato.
It wasn't too long ago that game programmers were considered the best programmers because game programming involves a lot of aspects of programming such as graphics, audio, networking, file system management, AI, parsing, virtual machines, etc. This made it possible for a game programmer to branch out to other fields in programming. Now, many game programmers are limited to programming game mechanics as engines can take care of the rest. So, we end up with the same problem that we see in modern websites in that they rely on general purpose frameworks that try to do everything inlcuding functionality that the game isn't using so it results in bloat. Compare that with a game that is written from the ground up and does what it needs to do. It has a much smaller foot-print and can run on weaker hardware.
The Problems With Game Engines
Most Engines Are Proprietary
Of course there are FOSS engines like Godot, but the vast majority of engines out there are proprietary, and using these engines mean that you are at the whim of the engine's developers. They can restrict what kind of games you make either through EULAs or DRM. Some of these engines may restrict the kind of content your game has or how you distribute your game (e.g prohibiting commercial use unless you have a premium license). None of the issues going on with Unity right now would happen if the engine is FOSS. Not relying on a proprietary engine (or a pre-made engine at all) means that you have more control over your game. The game you make is yours and you aren't restricted through EULAs or proprietary code that you didn't write.
Too Many Codebases Too Keep Track Of
Modern engines use a lot of third-party libraries which make it hard to keep track of, even if all libraries and the engine are FOSS. Let's say you have a bug. Is the bug relating to your code, the engine, the graphics library, the physics library? What if these libraries are written in different languages and you can't read every single codebase? The more dependencies you have the harder it is to keep track of this. Also, additional libraries just mean more bloat in your code. If you write more stuff by hand, you know how everything works automatically, so it is easier to tweak it yourself. If you wrote the physics library, you have full control over it. Same with anything else.
Being Limited By The Features/Performance Of The Engine Itself
Using a premade engine means that you are limited by the features and performance of the game engine itself. Sure, if the engine is FOSS or you are able to obtain a license for the source code, you can modify the engine to suit your needs. Case in point, the developers Cities Skylines had to obtain a license to Unity's source code and modify the engine to handle a simulation of a metropolis. Modifying an engine to suit your needs can be done, but that requires going through a huge chunk of code that you didn't write and this also assumes that the engine was written in a language that you understand and uses libraries/APIs that you are familar with.
Jack Of All Trades Master Of None
And finally the biggest reason why I don't use game engines is that they are all trying to be general-purpose engines meaning that they are designed for games of any genre, but as a consequence they aren't optimized for a single genre. It's better just to have a tool that does one job right. If I write an RPG, I would write a game engine solely designed for RPGs and that can build and run RPGs well and it would run better than if it was written in any pre-made engine (most of which were originally designed for first-person shooters). It would also be less bloated since there would be a lot less unused code. It will have all the code it needs to run and nothing more.
Why Game/Multimedia Frameworks Are Better
There are plenty of multimedia frameworks that can be used to create any video game or multimedia application. These frameworks include SDL, SFML, Allegro, GLFW, Pygame, MonoGame, Love2D, and LWJGL. These aren't full engines. They only contain functionality for graphics, audio, input, etc, and you are responsible for implementing the rest like levels, AI, physics, etc. If you need help there are additional libraries available for things like physics, tiling, etc. This means that you have a lot more control over your game's code. All the other code is just for display graphics and stuff like that, stuff that every game needs. Therefore, your game's code is tailor made for that game and will have a much smaller footprint as a result.
Also, not using a premade engine means that you implement everything, so you aren't limited to the choices that a premade engine would provide. You get to choose what file formats to use, you get to choose what scripting language for the game, you get to choose what type of rendering your game has, etc. Want to use voxels instead of polygons? You are free to do so. Want to use SVGs instead of raster sprites? Go right ahead. Want to store levels as bitmap images. How about storing levels in a SQL database? Why not?
Now I know that the common objection to this is that using a game engine is simply easier. I understand, but I really think people overestimate the difficulty of just using a multimedia framework, especially if they are only making 2D games. For 2D games, you really just need a basic understanding of Algebra, Geometry, and Trigonometry. These are all high school level math. 3D is probably a bit harder, requiring some Linear Algebra and Calculus knowledge. It's probably more excusable to use an existing engine for 3D, especially for first-person shooters since most of them were designed for them, but the transition to 3D shouldn't be hard after mastering 2D. Of course there are plenty of tutorials and documentation on any algorithm you can think of so you're not completely re-inventing the wheel.