I've always said: in terms of software complexity, video games are second only to OSs.
This book describes Doom (1993), and already goes from low-level hardware descriptions (caching, pipelining) to describing 2D and 3D computer graphics (even including a discussion on perspective-correct texture mapping), collision detection, audio and I/O architecture, to the enemy AI. Little wonder that people like John Carmack and Chris Sawyer are absolute legends.
Modern video games ramp this complexity up to a wholly new level: at 144 Hz, games have to accurately output frames in 7 milliseconds or less; a single stutter to 30+ ms is noticeable. Add in the complexity of managing CPU-GPU data transfers, audio and networking, and now hardware ray-tracing. Open-world games have to seamlessly stream data to keep the illusion going (Skyrim is already considered antiquated because of loading screens between even outdoors areas—famously, the gate to Whiterun—not to mention loading screens between indoors and outdoors). They also manage gigantic state machines of NPCs movements and reactions, enemy actions, player data and quest progression, and other miscellanea like day/night time cycles. Players also now expect non-linear, branching storylines, and straightforward moddability.
Multiplayer games have to seamlessly send and synchronise user input and responses between dozens of players networked across the world, within tens to hundreds of milliseconds—a 100 ms ping is unacceptable in competitive CS:GO. A website is allowed to take several seconds to load, but that I fired a headshot at that other player's character and that it registered on that player's computer within a hundred milliseconds is stupefying.
In graphics we now have ML-based upscaling techniques like DLSS and FSR that are barely distinguishable from full-resolution rendering. Just 5 years ago we had to make do with painfully intensive Sinc/Lanczos algorithms, or blurry bi/trilerp. We have temporal anti-aliasing techniques, and rasterisation hacks that are so impressive that they look photorealistic (see Red Dead Redemption 2. Find a bright light source at night when it's raining, and look at the droplets: they refract the light from the light). I've already mentioned hardware ray-tracing that now allows real-time effects we could only have dreamed of just half a decade ago.
I would unabashedly say video games are the zenith of what modern computers and modern software development are capable of.
Given this, it is a travesty that game developers are frequently the lowest-paid programmers.
I absolutely agree that game dev is some of the most nasty programming that's out there.
Mid-tier game programmers are worse than mid-tier webdevs, though, having bounced between the two subfields a lot. The most difficult stuff is more difficult in games, which is why the 99% people there are actually better than the 99%ers elsewhere, but the median work is meh, and that makes up the bulk of the work. And the devs...the median in games is not very good, the big companies employ a lot of extremely mediocre devs who desperately need the 99%ers closely managing them to get even passable work out of them.
The pay difference is just because it's a more desirable job than doing boring webdev, and young programmers think of it as awesome because they imagine they'll be doing the stuff that Carmack does. But that's what the top folks do. In reality most are going to be writing UI integration code and content-reviewing and fixing up busted PRs from artists.
> Enthusiastic artists always get fucked over and exploited by self-serving business people, that is the way things have been since the dawn of time
I tend to think of this in terms of the economics of supply and demand - if the job is cool and fun, it likely increases supply of people wanting to do that job, driving prices down. It applies to plenty of other jobs as well, e.g. people working in zoos don't tend to get paid all that much.
they don't need to pay more, talented people love the work and will do it at a lower price.
Sit in a cube doing beige business-logic day after day in a tie...that sounds much less exciting...obviously it'll pay more because given the choice everyone is choosing game development.
Yes, getting away with it. If there were 100x fewer people who could do those roles, the fact that they still loved doing them had nothing to do with how much they were paid. Simply adding more candidates to the job pool does not magically make each person's contribution to the company worth less, they're still doing the same work. It's just that the business can get away with paying less since there are more people available, some number of which are willing to accept that lower amount.
Again, there's no law of the universe that say more applicants = lower pay, or more pleasant working condition = lower pay. That is a choice businesses make. One made for the benefit of the company at the expense of its employees.
I think this should be more specifically referred as game engine programming (although, this is certainly a gray area).
Engines (for example, the Unreal Engine) take care of the really hard part for the vast majority of the games, leaving the devs to take care of the rest. This also supports the theory of a sibling post, that mid-tier game programmers are worse than mid-tier webdevs.
> in terms of software complexity, video games are second only to OSs.
In these days it should be "game ENGINES are second only to OSs."
There are so many good game engines out there; Unity, Unreal, Godot etc. etc., and it's crazy easy to create a game these days.
What's more interesting, though, is that how much "game programming" differs from "traditional programming" in regards to patterns used. Sure, there are lots of similarities, mostly based on the game engine used, but there are some interesting differences.
It's "crazy easy" from a programming perspective, since the engine mostly does that for you, but it still takes lots and lots of effort to create the assets for a AAA-level game (detailed 3D models and textures for characters and environment, motion capture, NPC behaviour etc.), followed by putting everything together and testing it.
It’s part of the advances in computers - early games had no OS to speak of and had to do all the I/O and memory management themselves.
By the time of some of that was done by the OS but not much - now the OS handles quite a bit and the game engines are also “pre developed” for many things.
A warning: once you do your hobby as your day job, it stops being as fun and rewarding as it was when it was a hobby. You sort of lose the hobby: after 40 hours of work, it is far less appealing to work on your game side project
It is probably a good plan to just keep a normal high paying software job and do game jams on the side, maybe work on your side project over the years. That way you won’t lose the joy.
If you do work in games full time though, your game dev skills will grow far faster though
One of the first books on programming I read made this argument too. Why learn programmin by making games? It's one of the most difficult kinds of programs to make successfully, so if you can master that you can do anything.
(It also had a rant about how Atari had a "gaming" reputation so people didn't buy them for office work. They would hypothetically have been great for it because video games are more demanding than word processing.)
Well, in some ways. Those neat home gaming associated computers of the early 80s typically couldn't do 80 columns text, and businesses really wanted that.
I think you are mostly correct but there are other fields that would give video games a run for their money in being the zenith. I'm thinking fast trading, machine learning for example. But thanks for the shout out!
that is true but unreal really lowered the bar and with unrealengine 5 we even seen major studios with their own engine state that they were moving to unreal
I can recommend the black art of 3d game programming, don’t remember by who, it’s this muscle guy :) and the series called “code on the cob”, by Chris Hargrove, while he was working at 3d realms
He has written several popular books in the 90s. His first (major, I believe) book was "Tricks of the Game-Programming Gurus", which revolved around Wolfenstein 3D (ray casting). In reality, it was an overrated and ultimately terrible book (amonth the other things, the book project was not an actual game, and his approach to optimization was to use assembly instead of better algorithms).
"Black Art of 3D game programming" is a good book instead, and also relatively relevant today, for those who want to understand the basics of 3d. It also goes in detail in explaining BSP trees, whose implementation is considerably more complex than one would imagine by reading "Game Engine Black Book - Doom" (nothing wrong with that, it's just a matter of page budget).
Teach Yourself Game Programming in 21 Days https://a.co/d/bYPxBpw was an earlier book of his and it was a really good introduction the concepts necessary to build 2D games. I doubt I'd be half the programmer I am today if I hadn't pored over it. I still remember fixing some of the bugs in his transparent sprite rendering code .
A few years ago I wrote to the author to express gratitude for them writing this book (I also purchased a hard copy to express an additional $0.77 worth of gratitude). One thing I notice hasn't been mentioned yet which is cool is that the entire source code for the book is on GitHub: https://github.com/fabiensanglard/gebbdoom
77 cents profit per copy sold? Is this normal for authors? I understand this book has high production costs, but that doesn't mean the author shouldn't get paid...
It is a sad well know fact that one cannot live alone from selling books, in technical domains they mostly serve as means to sell one's credentials in a specific domain, for conferences, freelancing, ....
The author stated somewhere he wasn’t out to make money on the books on Amazon or such, and if you sell via print on demand with Amazon it is really hard to get a price that works worldwide and doesn’t give you at least “some” profit somewhere.
I sometimes play Doom when I have five minutes to kill to the next (remote) meeting. I'm still incredibly impressed by what these people accomplished. It was pretty much the first fast-paced, full 3D world you could immerse yourself in.
Sometimes I feel like it's a shame they wasted the potential on a monster shooter, when they could have made an open world adventure (with monster shooter elements) or something seriously ambitious.
But then again, I guess that became the ambition but it turned out to be too ambitious, so they probably hit the sweetspot with semi-open level design and smashing gameplay instead of slow story.
This book describes Doom (1993), and already goes from low-level hardware descriptions (caching, pipelining) to describing 2D and 3D computer graphics (even including a discussion on perspective-correct texture mapping), collision detection, audio and I/O architecture, to the enemy AI. Little wonder that people like John Carmack and Chris Sawyer are absolute legends.
Modern video games ramp this complexity up to a wholly new level: at 144 Hz, games have to accurately output frames in 7 milliseconds or less; a single stutter to 30+ ms is noticeable. Add in the complexity of managing CPU-GPU data transfers, audio and networking, and now hardware ray-tracing. Open-world games have to seamlessly stream data to keep the illusion going (Skyrim is already considered antiquated because of loading screens between even outdoors areas—famously, the gate to Whiterun—not to mention loading screens between indoors and outdoors). They also manage gigantic state machines of NPCs movements and reactions, enemy actions, player data and quest progression, and other miscellanea like day/night time cycles. Players also now expect non-linear, branching storylines, and straightforward moddability.
Multiplayer games have to seamlessly send and synchronise user input and responses between dozens of players networked across the world, within tens to hundreds of milliseconds—a 100 ms ping is unacceptable in competitive CS:GO. A website is allowed to take several seconds to load, but that I fired a headshot at that other player's character and that it registered on that player's computer within a hundred milliseconds is stupefying.
In graphics we now have ML-based upscaling techniques like DLSS and FSR that are barely distinguishable from full-resolution rendering. Just 5 years ago we had to make do with painfully intensive Sinc/Lanczos algorithms, or blurry bi/trilerp. We have temporal anti-aliasing techniques, and rasterisation hacks that are so impressive that they look photorealistic (see Red Dead Redemption 2. Find a bright light source at night when it's raining, and look at the droplets: they refract the light from the light). I've already mentioned hardware ray-tracing that now allows real-time effects we could only have dreamed of just half a decade ago.
I would unabashedly say video games are the zenith of what modern computers and modern software development are capable of.
Given this, it is a travesty that game developers are frequently the lowest-paid programmers.