In the mid-1990s, while most teenagers were playing video games, Ken Silverman was building the technology that powered them. At just 18 years old, Silverman delivered the Build engine to 3D Realms — a revolutionary 2.5D rendering system that would go on to drive some of the most iconic first-person shooters ever made, including Duke Nukem 3D, Blood, and Shadow Warrior. Working largely alone from his family home in Rhode Island, Silverman wrote an engine that rivaled the work of entire development teams, introducing features like room-over-room rendering, destructible environments, and a real-time level editor that forever changed how games were built. His story is one of raw programming talent, relentless curiosity, and a deep understanding of hardware constraints — the kind of engineering that defined an era of PC gaming.
Early Life and Education
Kenneth Silverman was born on March 3, 1976, in Providence, Rhode Island. He grew up in a household that encouraged intellectual curiosity, and his fascination with computers began early. By the time he was in middle school, Silverman was already programming on a variety of systems, teaching himself the intricacies of x86 assembly language and low-level graphics programming — skills that most professional developers of the era had only begun to explore.
Silverman attended classical high school in Providence, where he continued to sharpen his programming abilities. Unlike many of his contemporaries who focused on high-level languages, Silverman dove straight into the metal of the machine. He understood that in the DOS era, performance meant everything, and performance came from knowing exactly how the CPU, memory bus, and VGA hardware interacted. This was a time before hardware-accelerated 3D graphics, when every pixel had to be calculated and placed by the programmer’s own code.
He went on to attend Brown University, studying computer science. But Silverman’s real education happened in front of his monitor, where he built increasingly sophisticated rendering engines. By the time he was a freshman in college, he had already completed the core of what would become the Build engine — a feat that John Carmack, the legendary programmer behind Doom and Quake, openly respected. Where Carmack had the resources of id Software, Silverman was essentially a solo act, writing tens of thousands of lines of optimized assembly and C code on his own.
Career and Technical Contributions
Silverman’s career as a game engine programmer began remarkably early. In 1993, at just 17, he started developing what would become the Build engine. The project was born out of his earlier experiments with raycasting and sector-based rendering — techniques that had been popularized by Wolfenstein 3D and Doom but which Silverman approached from his own angle. He had been writing his own rendering engines since he was 14 or 15, and by the time he connected with 3D Realms (then Apogee Software), he had a functional prototype that impressed the company enough to secure a licensing deal.
The Build engine was completed and first used commercially in 1995 with the game Witchaven, though it achieved its greatest fame with Duke Nukem 3D in January 1996. The engine went on to power a remarkable roster of games: Blood by Monolith Productions, Shadow Warrior by 3D Realms, Redneck Rampage by Xatrix Entertainment, PowerSlave (Exhumed) by Lobotomy Software, and several others. Each of these titles pushed the Build engine in different directions, showcasing its flexibility and Silverman’s forward-thinking architecture.
Technical Innovation
The Build engine represented a fascinating middle ground in game engine history. While it was technically a 2.5D engine — using a sector-based approach similar to Doom’s BSP tree renderer — it introduced capabilities that made its worlds feel genuinely three-dimensional. The engine used a portal-based rendering system with sectors defined by walls, floors, and ceilings, but Silverman’s implementation allowed features that were simply impossible in the Doom engine.
One of the most impressive innovations was the concept of room-over-room (ROR) rendering. While the Doom engine could not stack rooms vertically (you could never have a true second floor above a first floor), Silverman devised clever portal techniques that allowed Build engine games to simulate multi-story structures. This was achieved through sector linking and teleportation-based rendering tricks that were invisible to the player. The technique was so effective that many players of Duke Nukem 3D never realized the engine had any such limitation.
Another groundbreaking feature was destructible environments. Build engine games allowed players to blow holes in walls, shatter glass, and interact with the world in ways that made environments feel alive. This wasn’t just visual trickery — the engine actually modified sector geometry in real time, allowing new gameplay possibilities that Tim Sweeney’s early Unreal Engine and even Carmack’s Quake engine did not offer at launch.
The Build engine also featured a sophisticated sprite system that went well beyond what competitors offered. Sprites in the Build engine could be floor-aligned, wall-aligned, or face the player (billboard-style), and they supported translucency and animation. Silverman implemented voxel support as well, which allowed certain objects to be rendered as true 3D volumetric shapes rather than flat sprites — a feature ahead of its time that foreshadowed his later work.
Here is a simplified example of how Build engine sector definitions worked, showing the data structure that defined the interconnected spaces of a game level:
/* Build engine sector structure (simplified from build.h) */
typedef struct {
short wallptr; /* index to first wall in sector */
short wallnum; /* number of walls in sector */
long ceilingz; /* ceiling height (z-coordinate * 16) */
long floorz; /* floor height (z-coordinate * 16) */
short ceilingstat; /* ceiling rendering flags */
short floorstat; /* floor rendering flags */
short ceilingpicnum; /* ceiling texture index */
short floorpicnum; /* floor texture index */
signed char ceilingshade; /* ceiling light level */
signed char floorshade; /* floor light level */
char ceilingpal; /* ceiling palette lookup */
char floorpal; /* floor palette lookup */
char visibility; /* sector fog/distance shading */
short lotag; /* game-specific trigger tag */
short hitag; /* game-specific identifier tag */
short extra; /* game-specific extra data */
} sectortype;
/* Walls connect sectors via nextsector pointers,
forming the portal graph that drives rendering */
typedef struct {
long x, y; /* wall vertex position */
short point2; /* index to next wall vertex */
short nextwall; /* adjoining wall index (-1 if solid) */
short nextsector; /* adjoining sector index (-1 if solid) */
short cstat; /* wall rendering flags */
short picnum; /* wall texture index */
signed char shade; /* wall light level */
short lotag, hitag;
short extra;
} walltype;This sector-wall-portal architecture was what gave Build engine levels their distinctive interconnected feel. Level designers could create complex, non-linear spaces by linking sectors through shared walls — a design that the engine’s built-in editor, BUILD.EXE, made remarkably intuitive to work with.
Why It Mattered
The Build engine mattered for several reasons beyond its raw technical capabilities. First, it demonstrated that a single, extraordinarily talented programmer could compete with well-funded development teams. While Carmack at id Software had a full team of engineers and artists supporting him, Silverman wrote the Build engine essentially alone. This was a testament to what focused, deep technical expertise could achieve — a principle that resonated with the hacker ethos of the early PC gaming era.
Second, the Build engine’s integrated level editor was revolutionary. BUILD.EXE shipped with the engine and allowed developers — and eventually modders — to create and test levels in real time with a 2D overhead view and instant 3D preview. This was years before tools like UnrealEd became standard. The editor’s accessibility helped spawn a massive modding community around Duke Nukem 3D, extending the game’s life well beyond its commercial peak. Level designers could draw sectors, raise and lower floors, apply textures, and place sprites all within a single application. This approach to integrated tooling influenced how game studios thought about level design workflows for years afterward.
Third, the engine proved that clever software engineering could extract extraordinary results from modest hardware. In an era when many developers were racing toward true 3D polygon rendering, Silverman showed that a well-optimized 2.5D approach could deliver more interactive, more immersive worlds than early polygon engines. Duke Nukem 3D’s interactive environments — working security cameras, shrink rays, pool tables, functioning toilets — created a sense of place that pure tech demos could not match. This philosophy aligned with what Chris Sawyer would later demonstrate with RollerCoaster Tycoon: that hand-optimized code written close to the hardware could outperform engines built on layers of abstraction.
Other Notable Contributions
After the Build engine era, Silverman did not rest. He went on to create Voxlap, a voxel-based rendering engine that could display and manipulate volumetric worlds in real time. Voxlap was a technical marvel that demonstrated real-time terrain deformation, destructible voxel environments, and physics-based interactions — concepts that would not become mainstream in gaming until titles like Minecraft (2011) and Teardown (2020) popularized voxel-based gameplay more than a decade later.
Voxlap rendered worlds composed of tiny cubes (voxels) rather than polygons. The engine used sophisticated raycasting algorithms to render these voxel worlds at interactive frame rates on the hardware of the early 2000s. Silverman released the source code for Voxlap and its companion game Voxlap5, which featured fully destructible terrain where players could carve tunnels, topple structures, and reshape the world dynamically. Here is a snippet showing the core voxel rendering concept:
/* Voxlap raycasting pseudocode — rendering a column of voxels */
void render_voxel_column(int screen_x, float ray_dx, float ray_dy, float ray_dz)
{
float cx = camera_x, cy = camera_y, cz = camera_z;
int last_drawn_y = SCREEN_HEIGHT;
/* Step along the ray through the voxel grid */
for (float t = 0.0f; t < MAX_DIST; t += step_size)
{
int vx = (int)cx;
int vy = (int)cy;
int vz = (int)cz;
if (voxel_is_solid(vx, vy, vz))
{
/* Project voxel top/bottom to screen Y coordinates */
int screen_top = project_z(vz, t);
int screen_bot = project_z(vz + 1, t);
/* Draw the visible portion of this voxel slice */
if (screen_top < last_drawn_y) {
draw_column_slice(screen_x, screen_top,
min(screen_bot, last_drawn_y),
get_voxel_color(vx, vy, vz));
last_drawn_y = screen_top;
}
}
cx += ray_dx * step_size;
cy += ray_dy * step_size;
cz += ray_dz * step_size;
}
}Silverman also contributed to PNGOUT, a PNG image compression optimizer that became widely used among web developers and digital artists. PNGOUT applies exhaustive search algorithms to find the optimal compression parameters for PNG files, often achieving significantly smaller file sizes than standard tools — reflecting Silverman's lifelong obsession with optimization and squeezing every last bit of performance from algorithms.
He additionally created Evaldraw, a programmable graphics environment that allowed users to write small C-like programs to generate real-time 3D graphics, raytracers, and mathematical visualizations. Evaldraw served as both a creative tool and a teaching platform, embodying Silverman's belief that graphics programming should be accessible to anyone willing to learn. His approach to making powerful tools freely available anticipated the open-source ethos that pioneers of the games industry had always championed: that sharing knowledge multiplies its value.
Philosophy and Key Principles
Ken Silverman's approach to programming is defined by a few core principles that permeate all of his work.
Optimize relentlessly, but for the right reasons. Silverman never optimized for the sake of benchmarks. His optimizations served the player experience — smoother frame rates, more interactive worlds, more responsive editors. Every cycle saved in the rendering pipeline translated into a richer game world. This philosophy contrasted with the industry trend toward brute-force approaches that relied on ever-faster hardware. Where others waited for Moore's Law to solve their problems, Silverman solved them with code. This mindset parallels what Jensen Huang would later champion at NVIDIA — the idea that performance gains come from architectural ingenuity, not just bigger transistor budgets.
Build tools alongside the product. The BUILD editor wasn't an afterthought — it was integral to the engine's design from the start. Silverman understood that the quality of a game's content pipeline directly determines the quality of the final product. By making the editor fast, intuitive, and integrated, he empowered level designers to iterate rapidly and experiment freely. Modern game development, with its emphasis on editor-driven workflows in engines like Unity and Unreal, owes a philosophical debt to this approach.
Work at the lowest possible level of abstraction. Silverman wrote critical code in x86 assembly because he needed absolute control over rendering performance. He understood the VGA hardware at the register level, knew exactly how the CPU cache behaved, and structured his data to minimize memory stalls. This deep hardware knowledge was not an indulgence — it was a necessity in an era when a single wasted cycle per pixel could halve your frame rate. Today, as tools like Taskee help development teams manage complex projects with many moving parts, the underlying principle remains the same: understanding the fundamentals of your tools gives you leverage that no amount of abstraction can replace.
Share your work openly. Silverman eventually released the Build engine source code, and he made Voxlap, Evaldraw, and PNGOUT freely available. He maintained a personal website full of technical documentation, source code, and detailed explanations of his algorithms. In an industry that often guards proprietary technology fiercely, Silverman's openness helped educate an entire generation of game programmers. His willingness to share echoed the values of Ivan Sutherland, whose pioneering work on Sketchpad demonstrated that sharing foundational research accelerates progress for everyone.
Legacy and Impact
Ken Silverman's legacy is felt across multiple dimensions of the game industry and computer graphics. The Build engine directly powered at least 11 commercially released games between 1995 and 1999, generating hundreds of millions of dollars in revenue. Duke Nukem 3D alone sold over 3.5 million copies and remains one of the most influential first-person shooters ever made. Its interactive environments, irreverent humor, and expansive modding community set standards that the genre followed for years.
The Build engine's source code release in 2000 catalyzed a wave of community projects. Source ports like EDuke32 and BuildGDX modernized the engine for contemporary hardware, adding hardware-accelerated rendering, high-resolution texture support, and modern input handling while preserving the original gameplay. The EDuke32 project, in particular, evolved into a sophisticated platform that enabled entirely new games built on the Build engine's foundations — a testament to the engine's clean, well-structured codebase.
Silverman's Voxlap engine, while never used in a major commercial title, proved enormously influential in demonstrating that voxel-based rendering could be practical for real-time applications. The concepts Silverman explored — real-time terrain deformation, volumetric destruction, raycasting through sparse voxel data — anticipated techniques that are now central to modern rendering research. When teams build tools for project coordination and technical execution — as platforms like Toimi do for web agencies today — they benefit from the same principle Silverman proved: that well-designed technical foundations enable creative work that would otherwise be impossible.
Perhaps most importantly, Silverman proved that age and resources are no barrier to creating world-class technology. He began the Build engine as a teenager, completed it before he was 20, and created work that stood alongside the output of the best-funded studios in the industry. His story has inspired countless young programmers to pursue ambitious projects, reinforcing the idea that deep technical knowledge and relentless dedication can overcome any disadvantage in tooling or team size. In the same way that Roberta Williams pioneered graphic adventure games from her home, Silverman showed that groundbreaking game technology could emerge from a single desk in Providence, Rhode Island.
Key Facts
| Detail | Information |
|---|---|
| Full Name | Kenneth Silverman |
| Born | March 3, 1976, Providence, Rhode Island, USA |
| Education | Brown University, Computer Science |
| Known For | Build engine, Voxlap voxel engine, PNGOUT, Evaldraw |
| Build Engine Started | 1993 (age 17) |
| Build Engine First Commercial Use | 1995 (Witchaven) |
| Most Famous Build Game | Duke Nukem 3D (1996) |
| Games Powered by Build | 11+ (Duke Nukem 3D, Blood, Shadow Warrior, Redneck Rampage, PowerSlave, others) |
| Build Source Code Released | 2000 |
| Key Innovation | Room-over-room rendering, real-time destructible environments, integrated level editor |
| Voxlap Engine | Real-time voxel rendering with destructible terrain (early 2000s) |
| Programming Languages | x86 Assembly, C |
Frequently Asked Questions
What is the Build engine and why was it significant?
The Build engine is a 2.5D game engine created by Ken Silverman between 1993 and 1995. It used a sector-and-portal rendering approach to create immersive first-person environments. The engine was significant because it introduced features like room-over-room rendering, destructible environments, and a powerful integrated level editor (BUILD.EXE) that were ahead of their time. It powered major commercial titles including Duke Nukem 3D, Blood, and Shadow Warrior, and its source code release in 2000 spawned a lasting community of modders and engine porters.
How did Ken Silverman's Build engine compare to John Carmack's Doom and Quake engines?
The Build engine and id Software's engines represented different philosophies. Carmack's Doom engine (1993) used BSP trees for rendering, while the Build engine used a portal-based sector system that allowed more environmental interactivity — destructible walls, swimmable water, and multi-floor structures via room-over-room tricks. Carmack's Quake engine (1996) moved to true 3D polygon rendering, while the Build engine stayed with the 2.5D approach but maximized what that approach could deliver. The Build engine games were often praised for their richer world interaction, while Quake pushed raw 3D technology forward. Silverman accomplished his work largely alone, whereas id Software operated as a full development team.
What is the Voxlap engine and how does it relate to modern voxel games?
Voxlap is a voxel rendering engine created by Silverman in the early 2000s that renders worlds made of volumetric pixels (voxels) rather than polygons. It featured fully destructible terrain, real-time physics, and raycasting-based rendering. While Voxlap was never used in a major commercial game, its concepts directly anticipated the voxel-based gameplay that became hugely popular with Minecraft (2011) and later titles like Teardown (2020). Silverman released the Voxlap source code, and its techniques influenced subsequent voxel engine research and development.
Can you still play Build engine games today?
Yes. Thanks to the Build engine source code release in 2000 and the efforts of community source ports, all major Build engine games are playable on modern systems. EDuke32 is the most popular source port for Duke Nukem 3D, offering hardware-accelerated rendering, high-resolution support, and modern control schemes. NBlood provides a similar experience for Blood, and VoidSW does the same for Shadow Warrior. BuildGDX is a Java-based port that supports multiple Build engine games in a single application. The original games are available for purchase on platforms like Steam and GOG.com.
