Game Engine Black Book

The centerpiece of Sanglard's technical account is a structure called the binary space partitioning tree — a BSP tree. The problem it solves is ancient in computer graphics: when you look at a scene, some surfaces are in front of others, and you must draw them in the right order so the near ones cover the far ones. Doing that comparison for every wall, every frame, was far too slow for a 386. The BSP tree let the engine do most of that work once, ahead of time, and then reuse it.

The idea, which id adapted from earlier academic work, is to slice a level into pieces along the planes of its walls and store those pieces in a tree. Because the slicing is fixed, the engine can walk the tree from any viewpoint and instantly produce the surfaces in the correct front-to-back order. The expensive geometry was computed when the level was built, not while the player was running through it. Sanglard shows how this shifted the cost from the player's machine, which had none to spare, to the level designer's machine, which could take its time.

Doom is remembered as much for how people played it together as for how it looked, and Sanglard gives the networking its own careful treatment. The engine could connect several machines so that players moved through the same level at the same time — either shooting monsters cooperatively or, more famously, shooting each other in what the game called deathmatch. On the office networks of the mid-nineties, this was the feature that turned a game into a social event and, quietly, into a problem for IT departments.

The technical approach was blunt and effective. Rather than have one machine act as the authority, every copy of the game ran the same simulation, and the machines exchanged only the players' inputs — which way each person was moving, when they fired. Because every machine ran identical code on identical inputs, they stayed in step without shipping the whole world back and forth across a slow connection. Sanglard shows why this demanded absolute determinism: the same input had to produce exactly the same result on every machine, or the games would silently drift apart.

What makes id Tech 1 unusual, in Sanglard's telling, is that it stopped being tied to Doom at all. id had learned this lesson with Wolfenstein and pushed it further: the engine and the content were separable. The game was data — maps, textures, monster behavior — fed into a general machine that knew how to render and simulate. Once that separation is clean, the machine can run other games entirely, and it did. id licensed the engine to other studios, who shipped their own titles on it while id moved on to build the next one.

This is the deeper subject of the book. A rendering engine is normally invisible infrastructure, thrown away when the next hardware generation arrives. id Tech 1 instead became a durable, reusable artifact — something with a life independent of any single product. When id released the source code in the late nineties, that life extended again: hobbyists ported it to hardware it was never meant to touch, fixed and extended it, kept it running long after the machines it targeted had gone to landfill. Sanglard's own book exists because that code was made public and could be read.

The file that overwhelmed a Wisconsin server in December 1993 contained a game, but Sanglard's book insists on looking past it to the machine underneath — the memory manager that never waited, the BSP tree that decided what to skip, the lockstep networking that let two office computers share a room. Each was an answer to a hard limit, and the limits were what forced the answers to be so clean. Doom was the occasion; the engine was the achievement, and it is the engine the book restores to view.