Build engine
 | |
| Developer(s) | Ken Silverman |
|---|---|
| Type | Game engine |
| License | Free for non-commercial use[1] |
| Website | http://advsys.net/ken/build.htm |
The Build engine 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.
It 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 and floor height, and allowing them to be angled along one line of the sector. The engine renders the world in a way that looks three-dimensional; however, the sizing for perspective only depends on the horizontal distance. This is noticeable in that wall vertices are always straight vertical lines on screen, regardless of the angle of view. Therefore, with no vertical distance parameters (only horizontal), this can cause small size distortion when looking up and down. However, this distortion can be severe if the player is looking at a structure that is very tall. As such, most Build games restrict objects' vertical height to a fairly limited range.
Technical features
Sectors
Sectors are the building blocks of level 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.
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 a simple 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 corrupted display resulted). 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). More interestingly, this allowed the designer to create worlds that would be physically impossible (e.g. a door way of a small building could lead into a network of rooms that was larger than the building itself). While all these things made the game appear to be 3D, it wouldn't be until later first-person shooters, like Quake, which used a different 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'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 several of the later Build engine games. Blood uses voxels for weapon and ammo pickups, powerups, and occasionally 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
One limitation of the Build engine is that the algorithm that "renders" the game world to the screen cannot simultaneously display multiple sectors that overlap each other vertically. Several Build engine games (namely Shadow Warrior, Blood, and Redneck Rampage) worked around this by displaying a "viewport" to another sector using the same multi-pass functionality provided to program mirrors into a Build game. 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 developed by game developers.
A feature added to EDuke32 in 2011 is true room over room (TROR). This allows sectors to be placed on top of other sectors where both can be viewed at the same time, 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. It should be noted that TROR is an engine feature of EDuke32, not a game feature or trick.
Build engine games
Though the Build engine achieved most of its fame as a result of powering the classic first person shooter Duke Nukem 3D, it was used for many other games. It is usually considered that the "Big Four" Build engine games are Duke Nukem 3D, Shadow Warrior, Blood and Redneck Rampage, though sometimes the latter is omitted.
- Games that were built directly on the Build engine.
- Legend of the Seven Paladins (1994) (completed but only released locally, though there exists a leaked copy in the internet, used the early version of Build engine illegally)
- William Shatner's TekWar (1995)
- Witchaven (1995)
- Duke Nukem 3D (1996)
- PowerSlave (Exhumed in Europe) (1996)
- Witchaven II: Blood Vengeance (1996)
- Blood (1997)
- Shadow Warrior (1997)
- Games that were based on the Duke Nukem 3D code
- Extreme Paintbrawl (1998)
- NAM (1998)
- Redneck Deer Huntin' (1998)
- Redneck Rampage (1997)
- Redneck Rampage Rides Again (1998)
- World War II GI (1999)
- Unreleased Build games
- Fate (not completed, only a demo exists)
- Corridor 8: Galactic Wars (not completed, source code available)
Source release and further developments
On June 20, 2000 (according to his website) Ken Silverman released the Build engine source code.[2]
Early days
Version 2.0—the only official binary release of Matt Saettler's EDuke, a project to improve Duke Nukem 3D for modders—was sent to 3D Realms for packaging. Unfortunately, it was sent just after the release of the Build source and hence Duke Nukem 3D was stuck with the build libraries that 3D Realms had used in 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 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 ports. 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 ports soared.
icculus.org port
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.) There was some talk of Matt Saettler using this to port EDuke to Windows, but nothing came of it.
JonoF port
A second port was made to Windows, and later to Linux, by Jonathon Fowler (JonoF). This port didn't have network game support until much later, and then only worked with two players.
Polymost
The task of updating the Build engine to a true 3D renderer was taken on by Silverman himself. In the release notes 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 ports derived from their codebases.
Polymer
On April 1st 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 much 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. As of the fifth installment of the High Resolution Pack (released in 2011), the Polymer renderer is mandatory. The developers of EDuke32 have stated that once Polymer has been rewritten for speed, it will replace Polymost completely, as it is a superior renderer, and can be made to look identical to Polymost.
Other ports
The source for EDuke 2.0 was released, but it took a while because some people had problems compiling the archived source. This was merged with the JonoF port of Duke Nukem 3D, and many features from 2.1.1 and various other EDuke branches were added by TerminX to make EDuke32. Another port based on the icculus code, Wineduke, has since died off, leaving EDuke32 the only EDuke port still in development.
Source for the last private beta of EDuke 2.1 (which never made it to a release version) was also released soon after the EDuke 2.0 source.
EDuke32 also works with NAM and WWII GI as EDuke was based on the code to these games.
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.
The Shadow Warrior source was released on April 1, 2005, and JonoF released a port of it on April 2, 2005. However, he admitted that he had access to the Shadow Warrior source code about a week before its release.[3]
The source code of Witchaven, Witchaven II, Tekwar and Corridor 8 have also surfaced. The legal status of these, however, is unclear.
External links
- Ken Silverman's Build Engine Page
- Build engine on the Open Directory Project
- Build Engine code review
Notes
- ↑ From the source code BUILDLIC.TXT
- ↑ Ken Silverman's Build Engine Source Code Page. Last accessed July 7, 2008.
- ↑ Fowler, Jonathon (3 April 2005). "JFShadowWarrior". JonoF's. p. 1. Retrieved 3 August 2011. "…I [JonoF] did have a week head start…"
| ||||||||||||||||||||
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
