I hope this will turn out to be a great resource for experienced programmers interested in graphics, real-time processing, and the like. I wish I had the time to go through it.
However if your goal is to make games my advice, and I'm not alone, is to make games and use an engine. Your users will not know if you developed it from scratch in C. They won't even care if you tell them. Only programmers and game developers care.
Lots of gamers can tell when a game is a "Unity" game for example (due to lots of built in shaders and effects). I'd agree using an engine is a wise choice but make the decision very carefully. It can save a ton of time, but you still have to put in a lot of work to not let the engine dictate too much about the look and feel of the game.
The point I was trying to make is that developing a game from scratch is a labor-intensive way to make a game. You have to consider file paths, resource management, texture packing, file formats, parsers, and hardware. You have to think about abstract things like event processing, concurrency, simulation, reacting to inputs, etc. A mountain of work goes into lighting up a pixel on the screen. Doing it from scratch is essentially inventing the universe from the atoms up.
I like this kind of stuff.
However there are projects where I'm more interested in game play mechanics, art, music, and experience. I can still write my own shaders. I still write all of my own behaviors, AI, and controllers. But with an engine I don't have to worry about animation blending, input control, hardware platform differences, asset tooling, etc, etc, etc, etc.
I don't want to discourage anyone who is curious. I just wanted to push back against some of the nostalgia in the video. It's not all glamorous. I've spent my share of my youth slavering over cryptic compiler errors. Developing games then wasn't as much fun as it is today, IMO. It was different and unique in its own way. But the tools we have today are far, far better.
Absolutely right. I've gone through the dark times of wondering how to get the linker to stop exploding on me. And when speaking about developing a game engine, it's not just the work required to create feature X, it's the entire ecosystem. Making a sound play or wiring up PhysX is not difficult. Making fifty modules work correctly with each other is the foundation and is not easy or quick. Then there are editor tools, with modern engines providing a full editor suite that would take a team years to make. In the case of Unity, you get correct play-in-editor as well as truly live editing, which allow for incredibly rapid iteration (part of the true secret of efficient game development is being able to go from your shower "ah ha!" moment to a working prototype as quickly as possible). Then there's their asset store with a proliferation of not only art and sound but valuable scripts and entire systems or engines. And while I'm making my game, the middleware company is making my tech better by fixing bugs and adding features, with nearly-push-button support for over a dozen modern hardware platforms to boot.
I can see lots of reasons to develop a game engine from scratch, but they become less compelling every year.
I hope this will turn out to be a great resource for experienced programmers interested in graphics, real-time processing, and the like. I wish I had the time to go through it.
However if your goal is to make games my advice, and I'm not alone, is to make games and use an engine. Your users will not know if you developed it from scratch in C. They won't even care if you tell them. Only programmers and game developers care.