Build (game engine)


Build is a first-person shooter engine created by Ken Silverman 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 since the basic world geometry is two-dimensional with an added height component, allowing each sector to have a different ceiling height and floor height. Playing the game shows that some floors can be lower and some can be higher; same with ceilings. 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 as a result of powering the 1996 first-person shooter Duke Nukem 3D, it was also used for many other games. The "Big Three" Build engine games are generally considered to be Duke Nukem 3D, Shadow Warrior, and Blood.

Technical features

Sectors

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. 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. 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", often called "sector effectors" , that, when given special tags, 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. This allowed the designers to create, for instance, air ducts that appeared to extend across the top of another room. This allowed the designers to create worlds that would be physically impossible. 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

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. Shadow Warrior makes even more advanced use of the technology, with voxels that can be placed on walls.
For several years, Ken worked on a modern engine based entirely on voxels, known as Voxlap.

Room over room

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 worked around this by displaying a "viewport" to another sector through an additional rendering pass. This technique, called room-over-room, 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, 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, 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.

Build engine games

; Games that are built directly on the Build engine
; Games that are based on the Duke Nukem 3D code
; Unreleased Build engine games
Version 2.0 of Matt Saettler's EDuke, a project to improve Duke Nukem 3D for modders, 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.
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 OS, 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

On April 1, 2003, after several years of claims to the contrary, 3D Realms released the source code to Duke Nukem 3D. Not long afterwards, both Ryan C. Gordon and Jonathon Fowler 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 and on Linux and other Unix operating systems, and interest in the source ports soared.

icculus.org port

, 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 There was some talk of Matt Saettler using this to port EDuke to Windows, but nothing came of it.

JonoF port

A second source port was made to Windows, and later to Linux and Mac OS X, by Jonathon Fowler. This port, JFDuke3D, initially did not have network game support, though this was added later in development.

Polymost

The task of updating the Build engine to a true 3D renderer was taken on by Silverman himself. In the for JFDuke3D, 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."

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

The source for EDuke 2.0 was later released, followed by the source for the last private beta of EDuke 2.1. Richard Gobeille 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.
EDuke32 also supports the games NAM and WWII GI, as EDuke was based on the code to those games.

Polymer

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

The Shadow Warrior source code was released on April 1, 2005, and JonoF released a source port of it, JFShadowWarrior, on April 2, 2005. However, he admitted that he had access to the Shadow Warrior source code about a week before its release.
The Transfusion project aimed to re-create Blood in the DarkPlaces engine, but as of 2006, this project is far from complete, though it has complete deathmatch multiplayer; a similar project is BloodCM which recreates all of the Monolith made single player levels for Blood on top of EDuke32, as well as ZBlood which ports some Blood assets and levels onto ZDoom.
The source code of Witchaven, Witchaven II: Blood Vengeance, William Shatner's TekWar, and Corridor 8: Galactic Wars have also surfaced. The legal status of these, however, is unclear. The full source code to an alpha version of Blood was also leaked, and was used as a reference for an otherwise reverse engineered port to Java using LibGDX called BloodGDX in May 2017. This followed from the author's previous port of TekWar released in January 2016, and has been followed up by ports for Witchaven and Redneck Rampage, now collectively called BuildGDX. A further port of Blood, called NBlood, was released in January 2019 based on EDuke32 and the creator's previous Rednukem port for Redneck Rampage.

Successor

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. The source code was published on June 8, 2019.