IMHO, as another programmer (though not in games), I have similar thoughts to what @griffin1977 and @engineer_comp_geek said: If you’re just starting out and trying your hand at it, consider learning an engine instead of a language.
If you want a job in the industry, like in an existing, established company instead of being an indie dev, then chances are you’ll be using someone else’s engine anyway, not writing your own.
The big two are Unity and Unreal, and both are free for individuals (and very cheap/royalty-based for small indie devs) and have tons of examples, tutorials, and demo projects you can learn from. There are also some smaller ones like Godot (which saw a surge in popularity a few years back after a Unity pricing scandal), or simpler ones for the web like PixiJS and Phaser.
The thing is that game dev has come along way since the 80s and 90s, when “garage coder” was the norm (the book Jordan Mechner - The Making of Prince of Persia was a fun read about those days). These days everything is hyper-specialized and hyper-complicated and your average game team is bigger than a Hollywood blockbuster would have. Game dev is probably the hardest, most complicated kind of entertainment society makes nowadays, and it’s several orders of magnitude more complex than writing generic web and office apps.
At this level, you’re not just programming in a particular single language — any language. The engines encompass decades of research and work in game logic code, yes, but also graphics and shaders (a specialization unto itself), in-engine scripting systems, sound, physics, quest and dialogue trees, artificial intelligence, pathfinding, weapons, netcode, anti-cheat, level design, etc. There is “programming” in all of those aspects, but it’s almost never one single programmer writing exclusively in one language, but a big team of specialists.
The life of a shader programmer would be quite different from somebody writes quests or does character animations for a living, for example, which are again all different from a small team making an indie game.
If you learned C++ without the context of how it’s used in these engines, you’ll just be learning really primitive building blocks, the kind of thing people used to write by hand two decades ago but don’t usually do anymore. That’s great if you want to write your own engine, but if you imagine your passion to be “making a game” and not “making the software that people use to make games”, then the engines are what you want to learn and work with, not the raw code. It’s the difference between being a writer and being a word processor programmer.
Some indie devs do start out in the commercial industry, learning their ropes and networking and getting familiarized with the tooling etc. before starting their own small project and team. And there are occasionally people like the Dwarf Fortress brothers or the Tiny Glade duo who do it all from scratch as a multi-year passion project, but those are very much the exceptions. Most games aren’t made like that.
Starting from an engine (especially a big one like Unreal or Unity) will let you dip your toes into the various parts of game dev, and from there you can branch out or specialize further as you like. But I think that’d be a better starting point than learning C++ or C# by itself. You’ll naturally pick up one or the other anyway if you choose Unreal (C++) or Unity (C#), alongside their own in-engine scripting methods.
).
