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.

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

Thumbs up but I really like checking out games made without an off-the-shelf engine.

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

swiftcoder said:
OpenGL

OpenGL is the place that thing come from not where they are going. I think Microsoft has learned its lesson after Quake 2 (and Voodoo)

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

Consider this analogy:

• Has movie making become less newbie friendly?

On the one hand, everyone now carries a video camera in their pocket; video editing software (even the software used by professionals) is available for subscription for twenty bucks a month; several market places that reach literally billions of people let you upload and host your movie for free, with a simple toggle to start making money on them if you actually get traction.

On the other hand, a cinematic theater release now isn't taken seriously if the budget is under a hunny ($100 million,) and because the scarcest resource is people-eyeball-time, why would someone watch your home-made movie when they can watch The Witcher on their Netflix subscription?

So, “making movies” is easier, but “making money from movies” is harder.

So, has game making become less newbie friendly?

I think games are the same. You can make newbie games in Scratch, or RPG Maker, or climb the engine ladder of Godot / Unity / Unreal. You can publish your games for free on the internet, or easily get access to Steam and Humble and Itch and other platforms. I don't understand the suggestion that “using a game engine is like walking a narrow labyrinth with a spear” – they explicitly let you avoid having to think too hard about the lower-level details if you don't want to. If you like C++, or just wiring things in a graph, and 3D games, try Unreal Engine. If you like scripting, and 2D games, try Godot.

“Making games” is easier, but “making money from games” is harder.

• the main problem of current times games: the focus is exclusively on technical nuances, the idea of ​​the game remains minimal or zero. That's why games are falling in popularity, and are trying to hide them by using "gaming bots."

frob said:
You can easily make the games that could be made easily two decades ago

It`s actually easier today to make the genres of the past.