Game Engine Black Book: Doom [pdf]
fabiensanglard.net
fabiensanglard.net
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.
(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.)
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.
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 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.
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.
And of course Skyrim is "dated", but it's not because of loading screens! The game is like 12 years old!
> it is a travesty that game developers are frequently the lowest-paid programmers.
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.
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.
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
There's also a book for Wolf3D: https://fabiensanglard.net/gebb/ and the CP-System: https://fabiensanglard.net/cpsb/
Besides, the PDF is now optimized and weights only 15miB instead of the 300 original MiB. So it does not kill my bandwidth budget :)!
I don't mind.
https://github.com/amroibrahim/DIYDoom
they also have a community forum, diyidtech, at https://discord.gg/a8n4Y2z
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).
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.
Truly appreciated. 'Continue comme ça Fabien'!