You may not be looking for answer like this, but here goes anyway! My choice is to use custom tech in order to do these things:
- Less than 1 second compile time
- Run-time hot-reloading of code; push a button in game and recompile + see changes while playing
- High quality tools. If I am to spend 3 weeks learning how to use a level editor, parse its tile format, etc. I would rather just spend 3 weeks making a tool that solves exactly the problems I have. Odds are this custom tool is better, especially if it's a header-only library. These tools are often niche, esoteric, and one-off. But they bring high dev-efficiency and cut dev time down.
- Full control over everything. This is the most important one. Ability to create absolutely anything. This allows a truly special and unique game to emerge by opening up all tech possibilities.
- Fun. Personally I can't stand learning to use someone else's tool when something better can be made in equal time. My game will never be finished if I don't have fun while I make it.
To do this, personally
I make single-file header libraries. I have found that finishing a library to the point where another professional can use it means the library is more or less "finished". Finishing the library all at once in one go turns out super helpful! A problem arose when swapping between tasks, sometimes revisiting tasks one, two, or 6 months old. Getting a brain back into an old thoughtspace takes a lot of time and energy. The old problem context needs to be rebuilt. Too much time was sunk into regaining old knowledge. So finishing a lib all at once keeps all the details in the brain, and making sure another can use it forces the quality bar very high. High quality bar means chances of revisiting are very low. For example my sound header tinysound will never need to be touched again, even if my game is not released within 10 years. It's finished and feature complete, without bugs. Just knowing this code is locked down puts my mind at ease, and helps to focus on other unfinished tasks.
If the library is public and has a permissive license, if someone else finds it useful they may just make a contribution. Then it's like someone else donates something valuable to your own game engine. For example tinysound (in link above) used to not do any pitch shifting. Them someone guy (from tigsource!) came along and added in some real-time pitch shifting, and it does not even adjust the sound's play length. Amazing.
If a header is written in plain-ish C it becomes trivial to port to other languages, or create call bindings into other languages. Some of my open source physics stuff has been ported to languages like Java, C#, C, and some other uncommon languages I don't recall. This is another benefit that could potentially help your game engine; having some extra ports or bindings laying around
And now my personal engine is nearly complete thanks to some single-file header libraries. Things like loading/saving pngs, atlas creation, loading/playing/looping sounds, sending data over a network with UDP, or reliable messages over UDP, SIMD/math etc. The one thing that I found a little difficult to make into a header was OpenGL, and windowing stuff. Creating windows, managing OpenGL, these seem difficult to generalize. Everyone wants to do something different. I will applaud anyone who can come up with a good single-header lib for either of these tasks. I think
tigr came pretty close, but it's inactive for around a year now.
I was considering writing a blog post about "making a game engine in 2017" talking about the use of single-header libs to try and get more people to make more headers. Also hopefully this post inspires someone here to make one
After finishing up my netcode header I was thinking of making a tile collision header, then my engine will be complete.
Here are two resources for making single file headers:
https://github.com/nothings/stb/blob/master/docs/stb_howto.txt,
http://www.randygaul.net/2015/10/19/single-file-libraries-bundle-pl-incbin-pl/HEADER HYPE
Developer
