>Nobody wants to be the one who does the backend code that actually makes the game work.
This is only true for a certain class of games that rely on multiplayer. Many games are singleplayer where the meat exists on the game engine. There's two sub sections of this as well. Real time and non-real time.
Realtime means streaming updates from all users. Games like fortnight or pubg are like this. Non-realtime means like checkers or multiplayer chess. If you are doing the later rather then the former I would say you're still in traditional web development where shit is still relatively easy because an HTTP server is good enough.
The former is what is really hard, and that kind of thing is what I would refer to as backend game development. If you are doing that, then likely you're not a traditional web developer anymore.
Typically in both cases Backend as a role will refer more to people creating and running services like server orchestration, matchmaking and so on. So the real-time/non-real-time distinction doesn’t really matter. The engine level role is usually Multiplayer or Networking Engineer and the actually making the game role is Gameplay Engineer.
It does matter. For real-time the person will likely need a custom solution. That means coding the entire server in C++ or some other zero cost language with custom protocols.
For the non-real-time, it means using a pre-existing backend server.
Many backend engineers don't know how to write a custom real time server from scratch. It's two completely different levels of skill. If you are hiring for this role and put out of job ad for typical backend engineers you won't get the right people for the role because, again, backend engineers typically don't have this skill.
Right that’s what I’m saying, the game server and associated protocols will be designed and written by the engine team in close collaboration with the gameplay team that will be making the game.
God of war, Cyberpunk 2077, witcher 3, skyrim, fallout, Zelda, Tomb Raider, Metal Gear, Final Fantasy (not the mmorpgs), Assasins Creed, there's tons.
I wouldn't say they are billion dollar game franchises but I would say billions and billions of dollars in total are part of games where multiplayer is not the central aspect. This sector is huge.
I think games with a huge online component tend to be bigger franchises but fewer in number. Overall online gaming as an industry is bigger then single player gaming but they are both huge enough in size that they are comparable.
Witcher 3 shot CDPR from under a billion to over 8 billions market value. So yeah, that game single-handedly made that, up to the point when CDPR dropped the ball with the buggy release of Cyberpunk 2077 - but nowadays they released a nice update for CP2077 which is what should've been the actual game launch 2 years ago.
But in the context of career advice, it still seems like a decent bet that the online gaming industry is and will remain pretty robust. Especially for people transitioning from traditional 'enterprise' programming jobs.
Why specifically the focus on online gaming vs. gaming in general? I would imagine the "safety" of both travel in lock step. And I wouldn't think gaming is "safer" then other fields of programming.
In fact even in good times, I feel gaming is less safe.
That was the point of contention upthread. Someone said doing backends for online games was a good transition for a general programmer, which intuitively seems plausible. The concern was whether that was too niche but the size of that market implies otherwise to me, however much bigger the whole pie might be.
This is only true for a certain class of games that rely on multiplayer. Many games are singleplayer where the meat exists on the game engine. There's two sub sections of this as well. Real time and non-real time.
Realtime means streaming updates from all users. Games like fortnight or pubg are like this. Non-realtime means like checkers or multiplayer chess. If you are doing the later rather then the former I would say you're still in traditional web development where shit is still relatively easy because an HTTP server is good enough.
The former is what is really hard, and that kind of thing is what I would refer to as backend game development. If you are doing that, then likely you're not a traditional web developer anymore.