What about using an open source engine?
They all use big dependencies, and it’s mostly back to square one for me at that point.
What would you call big dependencies? My game engine only depends on SDL2, and is open source. (You'll most likely not like it, as it's C++, and you have expressed your ... love ... for that a few times)
Sounds pretty good! Though it's RAII, templates, and pretty much most features beyond C++11 (including rvalues) that I don't appreciate (rvalue get the boot since RAII is booted).
I would consider libpng a big dependency. Here is my reasoning.
1. Their API is terrible. It takes about 30 lines of code to load a PNG, compared to 1 with stb_image.
2. It depends on zlib, with a nearly identically horrible API.
3. It's tons of code, absolutely tons of code. Going in and making modifications is absolutely not a possibility. And yes, I've needed to make modifications before, hence me writing my own png loader/saver.
If I go poking around in, for example, Love2D, I can see all their dependencies. I actually almost used Love2D for my own game. Here is their internal dependencies:
https://github.com/love2d/love/tree/master/src/libraries. Not too bad. However, once the source is opened up there are more internal dependencies hidden away where the source of those dependencies is included directly. This is a fairly big problem, since those internal dependencies can be "hidden" behind a Love wrapper in C++, thus hiding how big or small they are. This has a few different kinds of costs.
1. API erosion. As one API wraps another the one underneath is inevitably eroded. Little pieces of error messages are truncated or ignored. Optional parameters aren't properly exposed. Not all cases are handled. The list goes on. Erosion is a problem for code maturation over a long period of time.
2. Difficult to optimize or profile. Optimizing and interpreting profiler results requires an understanding of the dependencies. Understanding them is difficult when they are all in varying sizes from different authors with different styles and different paradigms.
3. Modifying, extending, or fixing bugs becomes a risk for each dependency due to difficulty in understanding the source.
So in the end its mostly about risk management and flexibility.
Of course, most people don't care about any of this stuff, so big dependencies don't really bother them. That's fine, but I personally really enjoy the freedom in engineering anything I need at any time without dependencies blocking my possibilities.
So in the end it's all just a preference.
Developer
