Hubbry Logo
Build (game engine)Build (game engine)Main
Open search
Build (game engine)
Community hub
Build (game engine)
logo
8 pages, 0 posts
0 subscribers
Be the first to start a discussion here.
Be the first to start a discussion here.
Build (game engine)
Build (game engine)
Build (game engine)
View on Wikipedia
from Wikipedia
Build Engine
DeveloperKen Silverman
Initial releaseSeptember 30, 1995; 30 years ago (1995-09-30)
Repositoryadvsys.net/ken/buildsrc/
SuccessorBuild 2
LicenseSource-available[1]
Websiteadvsys.net/ken/build.htm

The Build Engine is a first-person shooter engine created by Ken Silverman, author of Ken's Labyrinth, for 3D Realms. Like the Doom engine, the Build Engine represents its world on a two-dimensional grid using closed 2D shapes called sectors, and uses simple flat objects called sprites to populate the world geometry with objects.

The Build Engine is generally considered to be a 2.5D engine, as the basic world geometry is two-dimensional with an added height component, allowing each sector to have a different ceiling height and floor height. Some floors can be lower and some can be higher; the same is true with ceilings (in relation to each other). Floors and ceilings can hinge along one of the sector's walls, resulting in a slope. With this information, the Build Engine renders the world in a way that looks three-dimensional, unlike modern game engines that create actual 3D environments.

Though the Build Engine achieved most of its fame from powering the 1996 first-person shooter Duke Nukem 3D, it was also used for many other games.

Technical features

[edit]

Sectors

[edit]

Sectors are the building blocks of a level's layout, consisting of a two-dimensional polygonal outline when viewed from above, with the top and bottom faces of the sector given separate altitudes to create a three-dimensional space.[2] Hence, all walls are perfectly vertical—anything appearing otherwise is technically a sloped floor or ceiling. The word room can be used as a loose substitute to aid understanding, though one room in the game world can consist of many sectors, and parallaxed skies can give the illusion of being outdoors. Sectors can be manipulated in real-time; all of their attributes such as shape, height, and slope could be modified "on-the-fly" by games, unlike the earlier Doom engine. This allowed games to have destructible environments, such as those seen in Blood.[2] This technique is similar to the use of push walls in the earlier Apogee Software title Rise of the Triad which featured similar dynamic environments.

Developers of games based on the engine used special reserved "sprites" (game objects), often called "sector effectors [sic]", that, when given special tags (numbers with defined meanings), would allow the level designer to construct a dynamic world; similar tag information could be given to the sector walls and floor area to give a sector special characteristics. For example, a particular sector effector may let players fall through the floor if they walk over it and teleport them to another sector; in practice, this could be used to create the effect of falling down a hole to a bigger room or creating a body of water that could be jumped into to explore underwater. A sector could be given a tag that made it behave like an elevator or lift.

Sectors could overlap one another, provided they could not be seen at the same time (if two overlapping sectors were seen at the same time, a hall of mirrors effect resulted).[3] This allowed the designers to create, for instance, air ducts that appeared to extend across the top of another room (however, doing so could be tricky for designers due to the 2D viewpoint used for much of the editing process). This allowed the designers to create worlds that would be physically impossible (e.g. a doorway of a small building could lead into a network of rooms larger than the building itself). While all these made the games using the engine appear to be 3D, it wouldn't be until later first-person shooters, such as Quake, which used the Quake engine, that the engine actually stored the world geometry as true 3D information, making the creation of one area stacked atop another area in a single map very feasible.

Voxels

[edit]

Later versions of Ken Silverman's Build Engine allowed game selected art tiles to be replaced by 3D objects made of voxels. This feature appeared too late to be used in Duke Nukem 3D, but was seen in some of the later Build Engine games. Blood uses voxels for weapon and ammo pickups, power-ups, and eye-candy (such as the tombstones in the "Cradle to Grave" level, some chairs, and a crystal ball in "Dark Carnival"). Shadow Warrior makes even more advanced use of the technology, with voxels that can be placed on walls (all of the game's switches and buttons are voxels).

For several years, Ken worked on a modern engine based entirely on voxels, known as Voxlap.

Room over room

[edit]

One limitation of the Build Engine is that its level geometry is only capable of representing one connection between sectors for any given wall. Due to this, a structure as simple as a shelf with space both above and below it is impossible, though sometimes sprites or voxels can be substituted. Buildings with several floors are technically possible, but it is not possible for such a building to contain an external window directly above or below another window. In addition, some liberties will need to be taken with the staircases, elevators, and other methods of access for each floor.

Several Build Engine games (namely Shadow Warrior, Blood, and Redneck Rampage) worked around this by displaying a "viewport" to another sector through an additional rendering pass. This technique, called room-over-room (ROR), appears seamless to the player. In addition to an expanded range of vertical construction, ROR was often used to give bodies of water translucent surfaces. ROR was never a feature of the Build Engine itself, but rather a "trick" that was created by game developers. A trick used in Duke Nukem 3D to get around this, as in the case of its opaque underwater sections, was to simply transport the player quickly to another region of the map made to mimic it, similar to the elevators from Rise of the Triad.

In 2011, a feature was added to EDuke32 called true room over room (TROR), which allows multiple sectors to be stacked vertically so that each sector's wall has its own connection, enabling vertically-unrestricted structures. The difference between ROR and TROR is that TROR sectors physically overlap in the map data and editor (allowing for easy creation and visualization), rather than being drawn from separate locations using view portals, hence true room over room. TROR is a feature of the EDuke32 source port, not a game feature or trick.

List of Build Engine games

[edit]

Games that are built directly on the Build Engine

[edit]
Year Title Developer Notes
1994 Rock'n Shaolin: Legend of Seven Paladins 3D Accend Inc. Illegally used an earlier version of the engine, only released in Taiwan and South Korea.[4][5]
1995 Witchaven[2] Capstone Software
William Shatner's TekWar[2]
1996 Duke Nukem 3D[6] 3D Realms Also Plutonium PAK, Atomic Edition, Duke!ZONE II, Xtreme, Duke it Out in D.C., Life's a Beach and Nuclear Winter expansions.
PowerSlave Lobotomy Software
Witchaven II: Blood Vengeance Capstone Software
1997 Blood[6] Monolith Productions Also Plasma Pak and Cryptic Passage expansions.
Shadow Warrior[6] 3D Realms Also Twin Dragon and Wanton Destruction expansions.
2024 Skilander Hackers and Hiihtoliitto Released at the Revision 2024 gamedev competition.[7][8]

Games that are based on the Duke Nukem 3D code

[edit]
Year Title Developer Notes
1997 Redneck Rampage Xatrix Entertainment Also Suckin' Grits on Route 66 expansion.
1998 Redneck Rampage Rides Again
Redneck Deer Huntin'
Extreme PaintBrawl Creative Carnage
NAM TNT Team
Liquidator[9] Akella Illegally used the engine, only released in Russia.
1999 WWII GI TNT Team Also WWII GI: Platoon Leader expansion.
2019 Ion Fury Voidpoint via EDuke32.
2022 A.W.O.L.[10] Shotspark Studios

Unreleased Build Engine games

[edit]
  • Fate (unfinished, only a demo exists)
  • Corridor 8: Galactic Wars (unfinished, source code is available)

Development

[edit]

The Build Engine was essentially a one-man project for Ken Silverman, though he consulted John Carmack for guidance early in the project.[3] Silverman was hired by 3D Realms on the basis of his demo for Build. Though he continued to refine the engine after becoming employed at 3D Realms, according to Silverman he never teamed with any other 3D Realms employees on the project and was never directed to tailor the engine towards any particular game.[2]

Source release and further developments

[edit]

On June 20, 2000 (according to his website) Ken Silverman released the Build Engine source code under a proprietary non-commercial license.[11][1] Silverman explained that after id Software set a precedent by releasing the source code for the Doom engine, fans had been pressuring him to release the source code for the Build Engine.[2]

Early days

[edit]

Version 2.0 of EDuke, a project to improve Duke Nukem 3D for modders by Matt Saettler (Matteus), was sent to 3D Realms for packaging shortly after the release of the Build source, leaving Duke Nukem 3D the pre-built libraries that 3D Realms had used with the original Duke. (Both Duke Nukem 3D and EDuke were still closed-source at this point.)

With the 2.1 private betas, Saettler worked towards integrating Silverman's build source into the Duke source code, but the project fizzled out before producing anything more than some very buggy private betas. A few total conversion teams for Build games decided to work from Silverman's Build code directly, and an enhanced version of the Build editor known as Mapster was also developed.

It was claimed at the time by many on the 3D Realms forums that it would be impossible to port Build to a multitasking operating system, as it needed a large contiguous block of memory that wouldn't be available in a multitasking environment. This statement did not hold up to scrutiny, as all modern operating systems use virtual memory which allows apps to get contiguous logical memory without using contiguous physical memory, but conventional wisdom of the time was that porting Build to such an OS was unfeasible.

Duke Nukem 3D source release

[edit]

On April 1, 2003, after several years of claims to the contrary, 3D Realms released the source code to Duke Nukem 3D under the GPL-2.0-or-later license.[12] Not long afterwards, both Ryan C. Gordon (icculus) and Jonathon Fowler (JonoF) created and released source ports of the game, including the Build Engine. It was possible to play Duke Nukem 3D well on the NT line of Windows (including Windows 2000/XP) and on Linux and other Unix operating systems, and interest in the source ports soared.

icculus.org port

[edit]

Ryan C. Gordon (icculus), with the help of others, made the first port of the engine using SDL. The port was first to Linux, then to Cygwin, and finally to a native Windows build using the Watcom C++ compiler, which was the compiler used for the original DOS build (despite being compiled with Watcom C++, Build is plain C.)[13] There was some talk of Matt Saettler using this to port EDuke to Windows, but nothing came of it. A port of Duke Nukem 3D was later produced after the source was released.[14] This was also forked by David Koenig (Rancidmeat) as Duke3d_w32 which was in turned forked into the multiplayer focused xDuke, hDuke, nDuke and rDuke.

JonoF port

[edit]

A second source port was made to Windows, and later to Linux and Mac OS X, by Jonathon Fowler (JonoF). This port, JFDuke3D, initially did not have network game support, though this was added later in development. After a long period of dormancy it was put on GitHub in 2020 and received updates in 2021 and 2024.[15][16][17] He also ported the Ken-Build test game.[18]

Polymost

[edit]

The task of updating the Build Engine to a true 3D renderer was taken on by Silverman himself. In the release notes for Polymost, he wrote: "When 3D Realms released the Duke Nukem 3D source code, I thought somebody would do a OpenGL or Direct3D port. Well, after a few months passed, I saw no sign of somebody working on a true hardware-accelerated port of Build, just people saying it wasn't possible. Eventually, I realized the only way this was going to happen was for me to do it myself."[19]

The Polymost renderer allowed for 3D hardware-accelerated graphics using OpenGL. It also introduced "hightile", a feature that made it possible to replace the game's original textures with high-resolution replacements in a variety of formats. Polymost has been utilized in Jonathon Fowler's JFBuild, JFDuke3D, JFShadowWarrior, and source ports derived from their code bases.

EDuke32

[edit]

A month after the game code, the source for EDuke 2.0 was also released,[20] followed by the source for the last private beta of EDuke 2.1 (which never made it to a release version). Richard Gobeille (TerminX) merged the EDuke 2.0 source with JFDuke3D to make EDuke32. Another port, Wineduke, based on the icculus code, has since died off, leaving EDuke32 the only EDuke port still in development.[21]

EDuke32 also supports the games NAM and WWII GI, as EDuke was based on the code to those games.

Polymer

[edit]

On April 1, 2009, an OpenGL shader model 3.0 renderer was revealed to have been developed for EDuke32, named Polymer to distinguish from Ken Silverman's Polymost. At first it was thought to be an April Fools' joke, but the renderer was later made public. It allows for more modern effects such as real-time dynamic colored lighting and shadow mapping, specular and normal mapping, and other shader-based features in addition to most of the features added to Polymost over the years. Although Polymer is completely usable, it is technically incomplete and unoptimised, and is still in development. The developers of EDuke32 have stated that once Polymer has been rewritten for speed, it will supplant Polymost completely, as it is a superior renderer, and can be made to look identical to Polymost.

Other game ports

[edit]
BuildGDX
DeveloperAlexander "[M210]" Makarov
Initial releaseJanuary 12, 2018; 7 years ago (2018-01-12)
Stable release
1.17 / August 23, 2024; 14 months ago (2024-08-23)
Repositorygitlab.com/m210/BuildEngine
PlatformJava
SuccessorNuBuildGDX
TypeGame engine
LicenseSource-available, GNU GPL v2
Websitem210.duke4.net

The Shadow Warrior source code was released on April 1, 2005 under the GPL-2.0-or-later license, and JonoF released a source port of it, JFShadowWarrior, on April 2, 2005.[22] However, he admitted that he had access to the Shadow Warrior source code about a week before its release.[23] The port was left in a partially incomplete state, before being put on GitHub in 2020 and receiving updates in 2021 and 2024. The earlier version was later forked by Ben Smit (ProASM) for the SWP port.[24] An icculus port of Shadow Warrior was started, but remained alpha.[25] A VoidSW port by the Ion Fury and EDuke32 developers entered public beta on May 21, 2020.[26] A fork from an earlier version, called IcedSW, by Justin Marshall (IceColdDuke) also exists.[27]

The Transfusion project aimed to re-create Blood in the DarkPlaces engine,[28] but as of 2007, this project was far from complete, though it has playable deathmatch multiplayer; a similar project is BloodCM which recreates all of the Monolith made single player levels for Blood on top of EDuke32,[29] as well as ZBlood which ports some Blood assets and levels onto ZDoom.[30] The eRampage project attempted to create a total conversion of Redneck Rampage for EDuke32.[31] Meanwhile DN3DooM,[32][33][34] Shadow Warrior TC,[35] Doomed Redneck,[36] Re-Blood,[37] Re-PowerSlave,[38] VietDoom,[39][40][41][42] and Fatedoom[43] adapts those games onto GZDoom.

The source code of Witchaven, Witchaven II: Blood Vengeance, William Shatner's TekWar, and Corridor 8: Galactic Wars also surfaced in 2007 from developer Les Bird.[44] The legal status of these, however, is unclear, though the derived EGwhaven patches for Witchaven were included in the game's Steam and GOG.com re-releases.[45] JonoF released ports for Witchaven and TekWar on March 3, 2024;[46] with derived ETekWar and EWitchaven ports also prototyped.[47] The full source code for various alpha versions of Blood have also leaked over time.[48]

This was then used as a reference for an otherwise reverse engineered port to Java using LibGDX called BloodGDX in May 2017 by Alexander Makarov (M210), the previous author of BloodCM.[49] This followed from the author's previous port of TekWar released in January 2016,[50] and has been followed up by ports for Witchaven,[51] Redneck Rampage,[52] Duke Nukem 3D, PowerSlave, Legends of the Seven Paladins and Shadow Warrior, now all collectively called BuildGDX.[53] DukeGDX also supports the files from the 20th Anniversary World Tour edition of Duke Nukem 3D.[54]

A further port of Blood, called NBlood, was released in January 2019 by Alexey Khokholov (Nuke.YKT) based on EDuke32,[55] and the creator's previous Rednukem port for Redneck Rampage (which also supports Duke Nukem 3D and Duke Nukem 64).[56][57] An EDuke32 port for PowerSlave, called PCExhumed, was released on November 21, 2019 by Barry Duncan (sirlemonhead) with help from Nuke.YKT.[58] The source port Raze forks various Build engine ports, including JFDuke3D, SWP, NBlood, Rednukem, and PCExhumed, and ties it to a new underlying backend based on the developers' own GZDoom.[59] NBlood and PCExhumed have also been backported to JFBuild for the purpose of adapting it to platforms such as the Amiga, PlayStation Vita and Nintendo 3DS.[60]

Successor

[edit]

After multiple attempts to design a successor to Build, Silverman again began experimenting with such an idea in 2006. He used this work - now called Build 2 - while teaching 3D game programming to children at a summer camp from 2007 until 2009, and work continued until 2011 when he lost interest in the project. It features a more advanced lighting system, voxel rendering for entities and true room-over-room 3D spaces, and at least in part retained backwards compatibility with the original Build. Silverman released his drafts to the public on March 7, 2018.[61][62] The source code was published under a proprietary non-commercial license on June 8, 2019.[63]

References

[edit]
[edit]
Revisions and contributorsEdit on WikipediaRead on Wikipedia

Build (game engine)

View on Grokipedia
from Grokipedia
The Build engine is a sector-based game engine developed by starting in 1993 and licensed to in 1993 for commercial use. It employs a rendering system that models environments as interconnected sectors and portals, allowing for advanced indoor architecture such as sloping floors and ceilings, mirrors, skyboxes, and destructible sprites—features that surpassed the limitations of contemporary engines like id Tech 1. Originally created as a technical experiment inspired by , Build evolved through Silverman's personal projects, including his 1993 shareware game , before being adapted for multiplayer networking and asset management in professional titles. Build gained prominence in the mid-1990s for powering several landmark PC games, most notably Duke Nukem 3D (1996, developed by 3D Realms), Shadow Warrior (1997, developed by 3D Realms), and Blood (1997, developed by Monolith Productions). Additional notable releases include Redneck Rampage (1997, Xatrix Entertainment), Witchaven (1995, Capstone Software), TekWar (1995, Capstone Software), and Extreme Paintbrawl (1998, Creative Carnage), showcasing the engine's flexibility for varied gameplay styles from horror to humor. Key technical strengths include precise collision detection, voxel support for low-polygon models, and built-in tools for level editing via a 2D map editor, which facilitated rapid prototyping and modding. On June 20, 2000, Silverman publicly released the engine's under a custom permissive license requiring attribution, enabling community-driven enhancements and ports to modern platforms like Windows, , and consoles. This openness spurred projects such as Jonathon Fowler's JFBuild port (first released in 2003) and the EDuke32 source port, which added features like high-resolution textures and room-over-room rendering. The engine's legacy endures in retro gaming and indie development, with contemporary titles like (2019, Voidpoint) utilizing enhanced versions of Build to evoke 1990s aesthetics while supporting modern hardware, alongside ongoing community efforts such as the 2024 release of historical engine snapshots.

History and development

Origins at 3D Realms

Ken , an independent programmer and teenage coding prodigy who had previously released the 1993 game using a custom 3D engine, began developing the Build engine in late 1993. After contacting (then operating as part of Apogee Software) with a demo of his work, entered a partnership with the company to license the engine as a binary library for upcoming titles, while retaining ownership of the source code. consulted of for technical guidance early in the project. This collaboration marked a shift for toward advanced 3D capabilities, building on their success with earlier 2D titles like . The engine earned its name "Build" from Silverman's choice of a thesaurus synonym for "construction," inspired by the intuitive sector-editing tool that allowed designers to assemble levels in a manner akin to constructing architectural structures. This editor became a hallmark of the engine, enabling rapid iteration on complex environments through a grid-based interface for defining walls, floors, ceilings, and portals. At , artist and programmer Todd Replogle contributed to early adaptations, including the design of file formats like .CON for asset integration in prototypes. The primary motivation behind the engine was to develop a versatile rendering system for first-person shooters that exceeded the architectural limitations of id Software's , permitting intricate level designs such as multi-story structures and dynamic without the computational overhead of true 3D polygonal models. Optimized specifically for the platform on 386 and 486 processors equipped with VGA graphics cards, it targeted the dominant consumer hardware of the mid-1990s, ensuring smooth performance at 320x200 resolution with 256-color palettes. This focus on efficiency allowed for innovative features like sector-based portals, which were referenced in early documentation as a core advancement for immersive, non-linear spaces. By early 1994, Silverman delivered the first internal prototype, which underwent rigorous testing at to validate its rendering stability and editing workflow before integration into initial project pipelines. This milestone paved the way for the engine's application in shareware-driven development cycles, aligning with Apogee's model of episodic releases to maximize market reach on period-appropriate PCs.

Evolution through the 1990s

The Build engine, developed by in collaboration with , achieved its first major commercial milestone bundled with on January 29, 1996. During late 1995, as the engine neared completion, key enhancements were implemented to address performance and rendering challenges, including the addition of slope support for floors and ceilings on August 29, 1995, which enabled more dynamic level geometry without sacrificing frame rates on period hardware. These updates built on the engine's sector-based foundation, optimizing it for larger, more complex environments typical of mid-1990s first-person shooters. Subsequent iterations in 1996 and 1997 focused on refining compatibility and multimedia integration to support broader hardware adoption. For instance, enhanced palette handling ensured robust 256-color VGA output, allowing developers to leverage full-color textures and sprites while maintaining compatibility with standard PC displays. Sound integration was also improved, with native support for cards for digital effects and for MIDI music, enabling richer audio experiences in games like without requiring additional middleware. A caching system using LRU/MRU algorithms, introduced on September 14, 1995, further boosted performance by efficiently managing texture and sector data for expansive levels. Commercial success drove further tweaks, particularly for multiplayer functionality and expansion content. The engine powered Shadow Warrior, released on May 13, 1997, which incorporated network play optimizations to handle up to eight players, influencing subsequent patches for latency reduction and synchronization. Similarly, Blood, launched on March 7, 1997, prompted refinements in sprite handling and particle effects to support its horror-themed visuals and expansion packs like Cryptic Passage later that year. These adaptations addressed bottlenecks in level size and enemy density, allowing for more ambitious designs while staying within the constraints of 486 and early Pentium processors. By 1997, with titles like Redneck Rampage (April 30 release), the engine had powered several notable games. Official development wound down around 1998, as 3D Realms and licensees shifted toward more advanced engines like Unreal, though the Build engine's iterative updates had solidified its role in defining 2.5D shooter design.

Technical features

Sector-based rendering

The Build engine structures levels as collections of two-dimensional polygonal sectors, each defined by a sequence of walls that form closed shapes, with specific walls designated as portals to connect to neighboring sectors. This sector-based architecture projects all geometry onto a 2D plane, simulating three-dimensional space without true 3D modeling, which limits complex overhanging structures but optimizes performance for hardware of the era. Portals serve as visibility gateways, allowing the engine to traverse and render interconnected spaces dynamically. During rendering, the engine employs raycasting from the player's viewpoint, projecting rays across the screen resolution to intersect with sector boundaries, thereby determining visible portions of walls, floors, and ceilings. For each visible column, the engine calculates distances and heights to apply textures, with support for sloped floors and ceilings achieved through optimized raytracing routines that handle variable elevations within sectors. Unsloped surfaces are texture-mapped horizontally for efficiency, as noted in engine code comments by creator , converting vertical spans to horizontal ones to reduce computational overhead. Visibility is handled by flooding through portals within a 90-degree , using a stack to process "bunches" of walls from nearest to farthest, ensuring only reachable sectors contribute to the draw calls and minimizing overdraw on limited hardware. Occlusion is tracked via arrays that mark the uppermost and lowermost visible points per screen column, preventing redundant rendering of hidden elements behind portals. The accompanying Build editor facilitates real-time sector manipulation, allowing designers to draw new sectors by starting and ending outlines with key commands and to adjust connections via portal assignments during editing sessions. Functions like dragging points enable on-the-fly geometry tweaks, with sector attributes such as heights and slopes modifiable immediately to preview changes. A key limitation of this approach is the absence of native true 3D geometry, as all elements—including slopes and textures—are confined to the 2D sector plane, resulting in pseudo-3D effects that cannot support arbitrary vertical overlaps without extensions. Voxels for detailed objects are placed as sprites within these sectors to maintain compatibility with the rendering .

Voxel and sprite integration

The Build engine employs sprites as its primary mechanism for rendering dynamic objects within its sector-based environments, where these flat 2D images are billboarded to always face the player, creating an illusion of three-dimensionality without full . Sprites represent entities such as enemies, weapons, and interactive items, stored in .ART files and positioned relative to sectors for spatial integration. During rendering, after processing walls and floors via column-based occlusion (using arrays like umost and dmost), the engine sorts visible sprites by distance in the tsprite array (up to 1024 entries) and draws them from farthest to nearest in the drawmasks() function, ensuring proper depth with the world geometry. Voxels extend this sprite system by introducing compact 3D volumetric models, defined as arrays of cubic "3D pixels" ( format: uncompressed with dimensions xsiz, ysiz, zsiz, and a 256-color palette where color 255 indicates empty space), allowing for true and perspective without the need for pre-rendered multi-angle sprite sheets. This feature, developed by and integrated into later Build engine iterations, replaces selected 2D art tiles with voxel objects during runtime, enhancing visual fidelity for rotatable elements like pickups and environmental interactives. In games such as , voxels render weapon and power-up items as opposed to traditional sprites, leveraging the engine's existing sprite —sprites are flagged for voxel substitution, then processed similarly for sorting and overlay—but with software-based slicing to generate perspective views on the fly. The integration of voxels and sprites optimizes performance on 1990s hardware by reusing the engine's efficient 2D-to-3D projection math, originally designed for sprite billboarding, while s add depth for specific assets without overhauling the core renderer. Tools like SLABSPRI and SLAB6 facilitated creation by converting 2D images into 3D volumes, carving transparent areas and applying colors, though this capability arrived too late for , which relied solely on sprites digitized from physical models or stop-motion. In , s appeared in limited forms like wall switches, demonstrating selective enhancement over sprite baselines to balance detail and speed. This hybrid approach influenced subsequent ports like Polymost, which extended support to for modern hardware while preserving the original integration logic.

Room-over-room mechanics

The Build engine simulates multi-story environments through a technique known as room-over-room, achieved by stacking multiple sectors vertically in the 2D map layout, building upon the engine's fundamental sector-based structure where each sector defines a polygonal area with floor and ceiling heights. This approach creates the illusion of height differences without employing true 3D geometry, relying instead on parallax scrolling effects—such as offset rendering of distant elements like skies or backgrounds—to enhance depth perception while maintaining the engine's 2.5D constraints. Notably, there is no genuine Z-depth collision detection; player and object movement remains confined to a single horizontal plane per sector layer, with vertical navigation handled through sector effectors rather than volumetric space. To manage visibility and prevent rendering artifacts from overlapping sectors, the engine uses portal masking, where walls designated as portals (with a linked nextsector value) allow views into adjacent or stacked sectors, while upper and lower portions of sectors are clipped based on defined portal heights. This clipping ensures that only the appropriate layer is visible from the player's viewpoint, avoiding simultaneous display of multiple overlapping sectors that could otherwise cause visual glitches, as the engine's raycasting renderer processes one dominant layer at a time within the 90-degree . The portal system floods connected sectors recursively during rendering, enabling seamless transitions but limiting direct line-of-sight to non-adjacent layers unless explicitly portaled. This mechanic supports key gameplay elements, including elevators implemented via sector height adjustments and effectors, jumps between levels through teleporters or ramps, and sightlines across floors for enemy AI and shooting. However, technical constraints include performance overhead from increased raycasting operations per stacked layer, as each requires separate wall, floor, and ceiling projections. These limits stem from the engine's optimized assembly code for raycasting, where solid walls and slopes already consume significant CPU cycles. A key innovation of this system is its facilitation of complex indoor-to-outdoor transitions, such as entering a building from a via a simple portal wall, without the preprocessing demands of full 3D engines like those using BSP trees, allowing for dynamic, runtime determination and reduced memory usage in mid-1990s hardware contexts. This approach demonstrated stacked sectors as early as 1996 prototypes, providing verticality in level design while preserving the engine's efficiency for real-time rendering.

Games using the Build engine

Direct Build engine titles

The Build engine's first major commercial success was , released in 1996 by Entertainment. As the flagship title for the engine, it introduced an episodic structure across three campaigns—L.A. Meltdown, Atomic Edition, and Alien Armageddon—allowing players to progress through interconnected levels in a dystopian overrun by aliens. The game emphasized a wide variety of weapons, including the iconic pipebomb and , which integrated seamlessly with the engine's sector-based level design to enable interactive environments like explosive barrels and destructible objects. Witchaven, developed and published by in 1995, was an early commercial title using the Build engine, transforming the FPS framework into a fantasy RPG hybrid. Players control knight Grondoval, navigating melee-focused combat across seven episodes set in a dark medieval world, where spellcasting is integrated as selectable inventory items functioning like weapons, including effects such as fireballs, flight, and area-of-effect nukes. This integration pushed the engine's sprite and sector systems to handle magical projectiles and environmental interactions, distinguishing it from gun-centric titles while maintaining the 2.5D sector-based level design. Similarly, , another 1995 Capstone release based on the author's novels, used an early version of the Build engine for a cyberpunk narrative, emphasizing futuristic policing against virtual reality drug dealers. The game features standard FPS shooting with energy weapons but innovates through vehicle sections, where players pilot a hover car through urban streets, leveraging the engine's sector portals to simulate driving within its 2.5D constraints. These sequences, limited by the engine's lack of true 3D rotation, used pre-rendered paths and sprite-based traffic, highlighting creative workarounds for vehicular gameplay in a pre-Quake era. Following closely, arrived in 1997, also from , showcasing the engine's versatility in fast-paced action. Developed as a satirical take on tropes, it featured protagonist Lo Wang navigating Asian-inspired levels filled with ninjas and , with a strong emphasis on combat options like katanas and fists alongside firearms. The title innovated by incorporating mirrors and conveyor belts into level geometry, enhancing exploration, and included robust multiplayer deathmatch modes supporting up to 10 players over LAN. Monolith Productions' Blood, released the same year in 1997, shifted the engine toward horror-themed first-person shooting with cultist as the anti-hero. It leveraged the Build engine for advanced particle effects simulating in gore, such as splattering blood and dynamic fire propagation, while enabling destructible environments through sector manipulation for immersive, chaotic battles against supernatural foes. Expansions like Cryptic Passage and Plasma Pak further expanded its arsenal and level complexity, solidifying its reputation for atmospheric dread. Lobotomy Software's Powerslave (also known as Exhumed), released in 1996, utilized the Build engine for an Egyptian-themed action-adventure shooter. Players explore ancient tombs as a commando battling mummies and gods with weapons like shotguns and magical artifacts, incorporating puzzle elements and platforming enabled by the engine's sector-based design. Extreme Paintbrawl, developed by Argo Games and published by Accolade in 1997, applied the Build engine to a unique paintball simulation game. It featured multiplayer-focused matches in varied arenas, using the engine's capabilities for destructible environments and sprite-based player models to simulate paint splatters and team-based gameplay. Xatrix Entertainment's (1997) brought a humorous Western to the engine, casting players as hillbilly Leonard rescuing his pig Bessie from alien invaders in rural . The game's levels parodied redneck stereotypes with chainsaw-wielding fights and moonshine-fueled antics, utilizing the engine's sprite and support for quirky enemy designs like hogs. Its expansion, Suckin' Grits on Route 66, added vehicular elements and more episodic content, maintaining the series' lighthearted tone. These direct Build engine titles shared core traits rooted in their MS-DOS origins, including 320x200 VGA graphics for vibrant, textured environments and built-in level editors like BUILD that empowered community from launch. Their sector-based rendering facilitated non-rectilinear architecture, fostering creative level designs without full 3D polygon overhead.

Derivatives from Duke Nukem 3D source

Chex Quest, released in 1996 by Digital Café as a promotional for , directly modifies the codebase to create a non-violent variant, replacing firearms with "zorchers" that stun rather than kill, and enemies with slime-like Flemoids invading the planet Bazoik. Distributed free in cereal boxes, it reuses modified Duke levels and assets, adapting the Build for family-friendly while preserving core mechanics like sector and interactive environments. This derivative exemplifies promotional repurposing, achieving cult status for its faithful engine fidelity without gore. In the late 1990s, community modifications extended derivatives through custom executables tailored for compatibility, addressing DOS limitations like sound and input issues on newer hardware. Ports such as early iterations of JFDuke and similar wrappers recompiled the codebase to support for improved rendering and mouse controls, enabling smoother play on post- systems without full source access until 2003. These efforts laid groundwork for broader engine preservation, focusing on runtime enhancements rather than major overhauls.

Unreleased and canceled projects

Several projects utilizing the Build engine were abandoned during development, often due to the engine's limitations in handling increasingly ambitious 3D features amid the industry's rapid shift toward fully polygonal engines like id Tech 2 (Quake). One prominent example is Corridor 8: Galactic Wars, a planned sequel to the 1995 first-person shooter Corridor 7: Alien Invasion, developed by Vision Technology for publisher . Intended as a sci-fi shooter featuring interstellar combat and alien invasions, the project advanced to a playable stage in 1996, incorporating Build's sector-based rendering for complex level geometry and sprite-based enemies. However, Capstone's financial collapse in late 1996 led to its cancellation, leaving only the prototype and design documents as artifacts; the source code has since been preserved in fan archives, allowing community playthroughs via modern ports like EDuke32. Another canceled title was Fate, an unreleased developed by DogBone Software and published by IntraCorp Entertainment. Announced in 1996, Fate aimed to blend horror elements with fast-paced action in a demonic invasion narrative, leveraging Build's support for detailed environments and dynamic lighting effects. A four-level demo was distributed at industry events, showcasing early like upgrades and AI, but development halted later that year due to IntraCorp's bankruptcy and shifting market priorities toward more advanced 3D technology. The demo remains accessible through preservation efforts, highlighting Build's potential for atmospheric level design despite its constraints. Embassy, developed by Cyberlore Studios in the mid-1990s, represents an internal prototype that never progressed beyond asset creation. This concept explored espionage-themed levels with room-over-room mechanics enabled by Build's sector system, but it was abandoned as the studio pivoted to other projects, including expansions for unrelated titles. Leaked assets, including maps and sprites compatible with Build editors, surfaced in fan communities around 2022, providing insight into experimental features like multi-layered architecture tested during the engine's commercial peak. Early development of also began with Build engine prototypes in 1996, following the success of , as initially extended their existing toolkit for the sequel's open-ended levels and interactive environments. These initial builds demonstrated ambitious scope, including destructible scenery and non-linear gameplay, but were scrapped by December 1996 due to Build's inability to support advanced features like sloped surfaces and full 3D movement, prompting a of the instead. No public prototypes from this phase exist, though design documents reference the transition, underscoring the engine's role in prototyping before broader industry evolution rendered it obsolete.

Source code release and ports

Initial source releases

In June 2000, Ken Silverman, the creator of the Build engine, released the core source code for the engine on his personal website, marking the first major public availability of its internals. This release included the engine's tools and a sample game called Ken-Build, distributed as a snapshot of the codebase developed between 1993 and 1997. The licensing terms were proprietary, permitting free distribution for non-commercial purposes provided the included BUILDLIC.TXT file was retained and three lines of credit to Silverman appeared in any standalone executable or archive; commercial use required permission from Ken Silverman. The release came amid shifting industry dynamics, where the DOS-centric Build engine faced obsolescence from advancing full 3D technologies like id Software's Quake engine, prompting Silverman to share the code to encourage hobbyist adaptations and extend the engine's viability on emerging platforms such as Windows and Linux. Distributed initially via Silverman's FTP server, the source immediately spurred community interest, facilitating early enhancements to mapping tools like the existing DukeEdit editor for Duke Nukem 3D and inspiring initial fan experiments with ports, though full modern compatibility awaited further developments. Subsequent official releases built on this foundation. On April 1, 2003, 3D Realms released the source code for version 1.5 under the GNU General Public License version 2.0 or later, encompassing the game logic layered atop the Build engine but excluding the engine core itself, which relied on Silverman's earlier drop. This GPL designation allowed broader modifications and redistribution, including commercial derivatives with proper attribution, and was made available through ' website and FTP archives to sustain the game's popularity amid requests from fans following id Software's 1997 Doom source release. The move enabled rapid community mods and tool improvements, such as refined level editors, without initial commercial restrictions beyond the GPL terms. (archived announcement context) Note that commercial use of -specific assets and code requires permission from . In 2005, extended this openness by releasing the Shadow Warrior source code on April 1 under the same GPL-2.0-or-later license, including compiled Build engine object files tailored for the game. Like the Duke release, it prohibited commercial use of the assets but freed the code for non-profit ports and modifications, distributed via the company's site to revive interest in the 1997 title. These initial drops collectively democratized access to Build-based games, fostering a wave of hobbyist projects while navigating proprietary constraints on the underlying engine.

Key community ports

Following the release of the Build engine source code, community developers began adapting it for , with efforts focusing on cross-platform compatibility during the early . These initial ports laid the groundwork for broader accessibility, enabling the engine to run on non-DOS environments while preserving core functionality. One of the earliest significant ports was the Icculus.org Build engine port, developed by Ryan C. Gordon in 2003. This SDL-based adaptation targeted and Unix systems initially, with subsequent support for Win32, and maintained compatibility with the original DOS compilation. Key additions included support for improved input handling and resolution scaling to accommodate higher display resolutions beyond the engine's native limits. In 2003, Jonathon Fowler released JonoF's Build port, which emphasized enhancements for Windows while extending to Linux and other platforms. This port introduced the Polymost renderer, developed in collaboration with , providing true support for hardware-accelerated 3D graphics, including true-color textures and basic 3D model substitution for sprites. These early ports incorporated foundational improvements such as compatibility, allowing aspect ratios wider than 4:3, and basic fixes to networking code for more reliable multiplayer sessions over TCP/IP, addressing limitations in the original IPX-based system. Developers faced notable challenges, including reverse-engineering undocumented portions of the original codebase—such as internal rendering optimizations—and ensuring with DOS executables, which required careful handling of legacy assembly routines and hardware-specific assumptions optimized for processors of the era.

Advanced enhancements like EDuke32

EDuke32, initiated in 2004 and actively maintained to the present, serves as a high-definition source port of the Build engine, enhancing with advanced features such as scripting via the system for modding gameplay elements, true room-over-room (TROR) capabilities that enable vertical sector stacking for more complex level designs, and support for 32-bit color rendering to eliminate palette limitations of the original 8-bit mode. A key upgrade is the integration of the renderer in 2009, developed by Pierre-Loup Griffais, which provides hardware-accelerated rendering with dynamic lighting, per-pixel shadows, and reflective mirrors, effectively replacing the earlier Polymost software renderer for superior visual fidelity on modern hardware. Additional enhancements include high-resolution textures through the High Resolution Pack (HRP), mouse look controls for intuitive aiming, and a comprehensive console system supporting Quake-style command bindings for runtime adjustments and debugging. The port is cross-platform, natively supporting Windows, macOS, and , with community efforts extending compatibility to Android devices for mobile play. The development community remains active on the Duke4.net forums, where contributors led by "TerminX" Gobeille collaborate on optimizations and fixes under GPL . Another notable enhancement is BuildGDX, a Java-based port released in 2014 utilizing the framework, which facilitates cross-platform deployment for Build engine titles including , emphasizing bilinear filtering and XInput controller support for broader accessibility in Java environments. EDuke32 builds upon earlier efforts like JonoF's JFDuke3D as a foundational precursor. In 2020, the Raze source port was initiated as a unified engine for multiple Build-based games (including Duke Nukem 3D, Shadow Warrior, Blood, Redneck Rampage, and Powerslave/Exhumed), leveraging GZDoom technology for advanced rendering, scripting, and cross-platform support. Its stable 1.0 release in 2022 introduced features like improved HUD scaling, sector lighting effects, and mod compatibility, with ongoing updates as of November 2025.

Legacy and influence

Impact on 2.5D game design

The Build engine significantly advanced game design by integrating a real-time 3D level editor directly into its core, making complex environment creation accessible to developers without requiring separate tools. This (what you see is what you get) approach allowed for immediate adjustments to textures, slopes, and sector heights, streamlining the process of building intricate levels and democratizing design for smaller teams. Unlike prior engines like , which relied on node-based BSP trees for static maps, the Build editor's live rendering enabled rapid iteration, influencing the evolution of intuitive editing paradigms in later FPS development. In terms of innovations, the engine's portal-based rendering and room-over-room mechanics introduced genuine verticality and interconnected spaces, overcoming the flat, sector-limited layouts of earlier raycasting systems. This allowed designers to stack multi-level structures and create dynamic, non-Euclidean illusions—such as overlapping rooms visible through portals—fostering more immersive and exploratory gameplay. These features encouraged level designs with elevated platforms, hidden upper areas, and fluid transitions, as seen in titles like Shadow Warrior, where vertical navigation added strategic depth to combat and puzzle-solving. The engine's flexibility in handling slopes and moving sectors further enhanced this, promoting environments that felt spatially rich despite underlying 2D constraints. The Build engine left a profound cultural footprint on FPS design, shaping the genre's blend of humor, , and environmental responsiveness. Games powered by it popularized irreverent protagonists and "pointless" interactive elements—like flushing toilets or playing pool—that injected personality into levels, defining the era's lighthearted yet gritty tone. Its support for destructible environments, enabled by dynamic sector manipulation, allowed for realistic destruction and player agency, notably in where objects and walls could be shattered with plasma effects, elevating immersion beyond static backdrops. The engine's source code release in 2000 further amplified its modding legacy, empowering communities to produce extensive user-generated content, including custom levels and expansions, years before centralized platforms like Steam Workshop emerged in 2011. This openness sustained the engine's relevance, powering more than a dozen commercial titles during its peak and inspiring 2010s indie retro shooters that emulated its sprite-based aesthetics and fast-paced design, such as Ion Fury, which modernized Build-style visuals for throwback appeal.

Successors and modern adaptations

BuildGDX, developed by Alexander Makarov, represents a modern reimplementation of the Build engine using Java's libGDX framework, supporting games such as Duke Nukem 3D, Blood, and Redneck Rampage with features like bilinear filtering and XInput controller support for contemporary platforms. Similarly, Raze, initiated by the ZDoom team in 2019 and reaching version 1.0 in 2021, is a C++-based port leveraging GZDoom's rendering technology to unify support for multiple Build titles including Duke Nukem 3D, Blood, Shadow Warrior, Redneck Rampage, and Powerslave/Exhumed within a single executable, enabling cross-platform play via SDL2. These projects extend the engine's viability for new development by incorporating hardware-accelerated rendering and modern input handling while preserving the original 2.5D architecture. Ion Fury, released in 2019 by Voidpoint, marks the first commercial built on an enhanced version of the Build engine in over two decades, utilizing EDuke32 as its foundation to deliver a retro-styled experience with updated visuals and mechanics on modern hardware. This adaptation revives the Build engine's fast-paced, sector-based gameplay for new audiences, demonstrating its enduring appeal in indie boomer shooter development. Ken Silverman's Voxlap, a voxel-based rendering developed from 1999 to 2003, represents a later exploration of techniques by the engine's creator. Community-driven 2.5D clones, such as variants inspired by Build's map formats, continue this lineage through amateur projects that emulate the engine's efficient rendering for custom levels and mods. Recent fan efforts include enhanced ports supporting re-releases like Duke Nukem 3D: 20th Anniversary World Tour, which integrate with tools such as BuildGDX for improved compatibility and features on current systems. In October 2025, Ken Silverman gave his first video interview, discussing the Build engine's development and lasting impact on . Looking ahead, Build's concepts find ongoing integration in retro gaming emulators and source ports, facilitating preservation and play on devices from PCs to single-board computers, with no significant commercial successors appearing after the early .

References

  1. https://www.arcadeattack.co.uk/ken-silverman/
  2. http://advsys.net/ken/kensrole.txt
  3. https://icculus.org/BUILD/
  4. https://advsys.net/ken/buildsrc/
  5. https://www.doomworld.com/forum/topic/149995-release-historical-snapshots-of-ken-silvermans-works/
  6. https://fabiensanglard.net/duke3d/
  7. https://advsys.net/ken/build.htm
  8. https://www.mobygames.com/game/365/duke-nukem-3d/
  9. https://fabiensanglard.net/duke3d/build_engine_internals.php
  10. https://www.mobygames.com/game/387/shadow-warrior/
  11. https://www.mobygames.com/game/980/blood/
  12. https://advsys.net/ken/
  13. https://wiki.eduke32.com/wiki/Build/Mapster32_Keyboard_Commands
  14. https://www.fabiensanglard.net/duke3d/BUILDINF.TXT
  15. https://www.blood-wiki.org/index.php/Voxel
  16. https://dukenukem.fandom.com/wiki/Build_engine
  17. https://www.mobygames.com/game/3318/witchaven/
  18. https://www.mobygames.com/game/2420/william-shatners-tekwar/
  19. https://www.mobygames.com/game/1045/powerslave/
  20. https://www.mobygames.com/game/1475/extreme-paintbrawl/
  21. https://www.mobygames.com/game/936/redneck-rampage/
  22. https://vision.gel.ulaval.ca/~klein/duke3d/
  23. https://90sfps.fandom.com/wiki/Corridor_8:_Galactic_Wars
  24. https://www.youtube.com/watch?v=h33mbbgyt60
  25. https://www.betaarchive.com/forum/viewtopic.php?t=994
  26. https://www.unseen64.net/2009/04/05/fate-pc-cancelled/
  27. https://www.youtube.com/watch?v=sUOZwQneA-4
  28. https://www.doomworld.com/forum/topic/98930-fate-the-unreleased-capstone-game/
  29. https://forums.duke4.net/topic/12059-embassy-assets-from-the-unreleased-game-on-build-engine/
  30. https://dukenukem.fandom.com/wiki/History_of_Duke_Nukem_Forever
  31. https://forums.duke4.net/topic/8991-the-duke-game-engines/
  32. https://www.youtube.com/watch?v=ebOpE3MHmQc
  33. https://www.eduke32.com/buildlic.txt
  34. https://github.com/videogamepreservation/dukenukem3d
  35. https://www.ign.com/articles/2005/04/01/shadow-warrior-source-code-released
  36. http://www.jonof.id.au/jfbuild/
  37. https://www.eduke32.com/
  38. https://forums.duke4.net/topic/6641-lunatic-lua-for-eduke32-preview-introduction/
  39. https://wiki.eduke32.com/wiki/True_Room_Over_Room_Mapping_Guide
  40. https://wiki.eduke32.com/wiki/Frequently_Asked_Questions
  41. https://wiki.eduke32.com/wiki/Polymer
  42. https://hrp.duke4.net/index.php?n=56
  43. https://wiki.eduke32.com/wiki/Console_commands
  44. https://dukenukem.fandom.com/wiki/EDuke32
  45. https://sourceforge.net/projects/eduke32/
  46. https://forums.duke4.net/forum/26-everything-eduke32/
  47. https://voidpoint.io/terminx/eduke32
  48. https://m210.duke4.net/index.php/downloads/download/8-java/53-buildgdx
  49. https://wiki.eduke32.com/wiki/EDuke32
  50. https://github.com/ZDoom/Raze
  51. https://zdoom.org/wiki/Raze
  52. https://www.rockpapershotgun.com/build-engine-duke-nukem-blood-shadow-warrior
  53. https://www.filfre.net/2023/04/the-next-generation-in-graphics-part-1-three-dimensions-in-software-or-quake-and-its-discontents/
  54. https://egmnow.com/blast-from-the-past-behind-the-rise-of-the-throwback-shooter/
  55. https://raze.zdoom.org/about
  56. https://voidpoint.io/
  57. https://entertainium.co/2023/11/01/ion-fury-aftershock-review/
  58. https://steamcommunity.com/sharedfiles/filedetails/?id=2143325742
  59. https://www.youtube.com/watch?v=WruzfQLxpQY
  60. https://www.macsourceports.com/game/ionfury/
Add your contribution
Related Hubs
User Avatar
No comments yet.