Ken Silverman and the Build Engine

**Ken Silverman** is an American software engineer best known for writing the **Build engine** — a mid-1990s 3D game engine that powered a generation of influential first-person shooters and demonstrated what disciplined low-level engineering could extract from limited hardware. ## The Build engine Developed 1993-1995 while Silverman was in his early 20s, licensed to 3D Realms and used to ship: - **Duke Nukem 3D** (1996) — the most commercially successful Build-engine game. - **Shadow Warrior** (1997). - **Blood** (1997) — still cited for best gunfeel in the genre. - **Redneck Rampage** (1997). - **NAM** / **Xatrix** titles. - A dozen smaller commercial and shareware games. ## Why it mattered Build pushed the envelope on what 2.5D / 'portal-based' 3D engines could do on 1995-1996 PC hardware: - **Sloped floors and ceilings**: id Tech 1 (Doom, 1993) couldn't do these. Build could. - **Variable-height sectors** and proper stair geometry. - **Room-over-room** construction via clever sector duplication — two rooms could appear stacked vertically, enabling lifts, multi-level interiors, and underwater areas with real surface boundaries. This was remarkable for 1996. - **Destructible environments** — walls could be shot out and alter geometry dynamically. - **Voxel objects** — items and detail objects could be rendered as voxel sprites rather than flat billboards, adding depth even without true 3D models. - **Sliding doors, rotating platforms, swinging objects** — moving map geometry that Doom couldn't represent. - **Portal rendering** — the engine represented 3D space via 2D sectors connected by portals, which was computationally cheap but allowed 3D-looking worlds. All of this at 320x200 or 640x480 on a 486DX or Pentium 60 — hardware that 'shouldn't' have been able to render that much geometry in real time. Silverman's engine used tightly hand-tuned assembly, clever data structures, and intimate understanding of the CPU cache and memory bus. ## Engineering ethos The Build era is routinely cited as an example of what hand-tuned low-level engineering can accomplish on constrained hardware. Similar cultural touchstones: - The Original 80KB Windows Task Manager (Dave Plummer era) — constraint-driven efficiency. - **id Tech 1** (John Carmack) — parallel efforts, same era, different approach. - **.kkrieger** (2004) — 96 KB demo of a full 3D FPS. The common theme: skilled developers can extract 10-100x more performance from fixed hardware than average code, *when they care to*. Most software doesn't care to (see Wirth's Law), but the existence proofs persist. ## Post-Build work After Build, Silverman: - Worked on **voxel rendering** engines (Voxlap, Ken's Lab). - Released his code publicly, including the Build engine source (mid-2000s). - Contributed to retro-gaming preservation. - Joined **Voxon Photonics** in early 2013 as Chief Computer Scientist. ## Voxon VX2 graphics engine At Voxon, Silverman built the rendering pipeline for the Voxon VX2 Volumetric Display. The engineering challenge: - USB 3.0 bandwidth (~4-5 Gbps real-world) - 7,200+ LED panel updates per second required (30 fps × 480 slices × 2 panels) - 8 million voxels per volume, 30 volumes per second Without extreme efficiency in the voxel pipeline — data compression, slice scheduling, pre-computation — the display would stutter or fail. Voxon's literature explicitly credits Silverman's engine as the enabling component. The skill transfer from Build to VX2 is direct: get more performance out of less bandwidth, ship 3D rendering at throughput the hardware shouldn't allow. The domain is different (spinning voxel display vs 2.5D portal-based FPS), but the engineering mindset is the same. ## Cultural legacy Duke Nukem 3D and other Build-engine games remain actively played, modded, and speedrun in 2026. The EDuke32 source port (based on Silverman's released code) keeps the engine modern, runs Build games on Linux/macOS/Windows with modern rendering features, and hosts a substantial modding community. Silverman's engineering style — publicly released source, thorough documentation, long-lived personal website — has made his work more durable than many commercial contemporaries. His site at advsys.net/ken remains active as of 2026, with ongoing code releases and retrospectives.