swiftcoder said:
I think people tend to forget that the old SDL+OpenGL path still works just fine. You can build a game that way in the year 2020, and still address the entire PC market. In some ways it's even improved - wrappers like ANGLE allow you to avoid all the OpenGL driver issues of years past.

Sure, using the up to date version of SDL and OpenGL, that is basically what I mean. Not using some ancient D3D8/9 or old OpenGL (e.g. glBegin/glEnd and glNewList/glEndList/glCallList display lists) with ancient example code. If I search for an up to date SDL+OGL guide, it doesn't even mention a lot of the old API, so just use the modern ones.

How long since Windows XP or pre-D3D9 hardware (D3D11 supports D3D9 hardware levels, but is Vista+) or pre-OpenGL 3 was a major PC market?

And yeah sure you need the very basic shaders (vertex transform + coloured/textured fragments) but those are basically handed to you.

Back then you can get away making indie games with minimal low-effort now low-quality indie-games are being scrub off by the community. This doesn't mean you can't make low-effort games and make a profit. The point is don't make crappy/copy or emulating previous games because people and market are ever changing and of-course new features in game-engines are also evolving for Unreal Engine 4, Unity, CryEngine, Godot, Etc… so newer “lessons” are changing the learning curves just a bit and that's where you and I need to find them and create an even unique games.

Example:

You could make a game that has Overwatch's mechanic with mixture of Counter Strike and Mortal Kombat fighting elements. And yes, there are tutorials you just have to find them and learn what you can base on your basic interpretation.

Gamedev has never been more newbie-friendly than the current times. There is an abundance in tools, tutorials and other development material all for free, and millions of experienced people to ask questions.

Back in the day we had to figure out everything by ourselves, using lousy tools without documentation. No internet. It wasn't friendly at all and required a lot of stubbornness.

If you are just about making games remember that nobody cares if your game was made in Unity, Unreal or handcrafted assembly.

No one mentioned yet but our hardware has changed too and it is not just the programming side but also the requirements of the hardware that increased. Modern hardware is manadtory using Shaders because it is how it works. Gone the days when you draw every pixel to the screen by your own and hello multicore processing with hundrets of GPU cores and several processing steps.

You have to know how Shader works because it is part of the render pipeline today, even if you use GLs fixed function pipeline, it emulates a basic Shader

I think most of it depends on your targets.

You can easily make the games that could be made easily two decades ago. You can create "guess the number" games, tic tac toe, and similar. Those were always simple games to make, and they remain so.

Long gone are the 1980s where games were hand-coded in assembly, every instruction evaluated and carefully considered in terms of CPU timings. Long gone are coding directly to graphics registers, coding directly to audio cards, or requiring gamers to choose which SoundBlaster variant they had, entering DMA channels and specify which IRQ values, nor program for various VESA compatibility modes. We don't need to write different versions of the game for CGA, EGA, and VGA graphics modes, writing directly to different video memory addresses. We don't need to create different communications streams for Hayes modems, for Robocom modems, for USRobotics modems. And GOOD RIDDANCE to that era. It was incredibly difficult to get even the simplest tasks done.

We also no longer use sprite-based hardware in game consoles, games that attempt to emulate the old sprite style of rendering will struggle on modern hardware. Games that attempt to draw individual sprites the same way that was done in the 1980s on sprite-based hardware tend to suffer extreme graphics rendering problems.

2020's graphics hardware is designed around 3D point clouds. If you want to use older interfaces, DirectDraw from 15 years ago, or DirectX 5, or OpenGL 1.2, you'll need to get hardware from 15 years ago and an operating system from 15 years ago. Those tools don't match today's hardware. Learning them is a historical exercise.

Just like a mechanic can learn about car engines from the early 1900s if they want, learn how the Model T worked, learn how the old air-cooled 1950's VW Beetle worked, but they shouldn't expect it to be much good when someone drives into the shop with a modern Explorer or RAV4. You can learn about the old stuff, but recognize you're learning old stuff.

If you're looking to use 2020's techniques and tools, I think engines and libraries today are more approachable than ever. Vulkan and D3D12 are the current systems. Yes, they are complex, and yes, they have tremendous learning curves, but that's the nature of the system being used. BUT YOU DON'T NEED TO WRITE THEM. Download Unity, download Unreal, download GameMaker:Studio or RPG Maker, and use those to make your game. The tools do that work, there is no need to re-invent the rendering engine, there is no need to re-invent file loading, there is no need to re-invent audio mixing, there is no need to re-invent math libraries, there is no need to write pathfinding code, there is no need to write physics code, there is no need to write particle effects processors, there is no need to write network infrastructure and low-level port management. Reuse what is already written and debugged. Leverage these tremendous libraries.

With the modern tools, one can follow an online tutorial and have a network-enabled physics-based 3D shooter game taking advantage of all the modern HDR graphics, 5.1 audio (or 7.2 or even 11.2 audio support), and advanced network capabilities. Another few hours and they project is filled with interactive, animated, scripted objects driven by AI that can handle advanced pathfinding. And they can create all this before writing a single line of code themselves. When the person finally reaches the point they need to write code, it does take some understanding for how to integrate with the various systems, but it is far easier than trying to write hand-crafted assembly and getting CPU instruction timings correct so you don't get ‘snow’ on the screen or other problems from decades past.

If you want to learn some specific aspect, such as learning how to write a Vulkan renderer, or learning how to implement matrix operations using AVX-512 instructions, you're free to do that. But recognize that in modern games, those are considered tiny building blocks, akin to learning how to pour concrete or lay stone while others are using architectural tools to build skyscrapers. There is still a need to know those details, but it has become specialty work