Build engine

from Wikipedia, the free encyclopedia

The build engine is a 3D engine for computer games , which was developed by Ken Silverman for 3D Realms and which was first used in the first-person shooter Duke Nukem 3D . The engine is comparable to the Doom engine (also id Tech 1 ), which is a few years older . With Ion Fury (formerly Ion Maiden ), a first-person shooter based on the build engine will be released in August 2019.

development

Ken Silverman began developing the build engine in March 1993, by which time he had completed the final version of his first commercially successful game, Ken's Labyrinth , for Epic . This game was also based on a completely self-developed 3D engine , which was technically comparable to Wolfenstein 3D . With “Build”, Silverman clearly followed the standards that Doom had set. Technically, however, some other approaches were pursued - "Build" is therefore not just a clone of the Doom engine.

technology

Earlier first-person shooter engines like the one known from Wolfenstein 3D use the comparatively fast raycasting to display the three-dimensional game world shown from the first-person perspective . “Build” greatly expands this technology and combines fast two-dimensional approaches based on raycasting with those that are also used in later graphic engines with real three-dimensionality . The level geometry is based on a two-dimensional floor plan and is therefore subject to significant restrictions that the level designer must observe and which in some cases also affect the degree of freedom of the player. For example, it is not possible to look straight up or down. Structures with several levels - for example bridges or buildings with several floors - can only be represented with tricks. Engines of this type are also pejoratively called "2.5D engines".

In contrast to Ken's Labyrinth and other earlier engines (such as those used in Wolfenstein 3D or System Shock ), the floor plans in the build engine are not tied to a fixed square grid. Walls must be vertical, but can meet at any angle. The engine also allows different height values ​​and the tilting of floors and ceilings. This made it possible for the level designers to convey a much more intense three-dimensional feel, as the level geometry was not limited to one level. Various tricks were used to bypass the remaining restrictions. In the first build game Duke Nukem 3D , some areas are actually not on top of each other, as the level architecture suggests; the player is only teleported unnoticed to another point on the level at the right moment. Examples of this are diving into underwater areas or jumping into shafts. Spiral staircases and similar constructions with rooms on top of each other are possible, but the level designer must ensure that the player can never see more than one level at the same time.

Solving the visibility problem

As far as the evaluation mechanism for visible areas is concerned, Build behaves like a portal engine . The atomic sections of the level, called “sectors” in Build, are connected to one another by special connecting surfaces (“portals”). The algorithm follows all visible sectors and then displays them. The algorithms used and the type of data organization, however, differ from other engines. Silverman used a combination of exact depth sorting and vertical span buffer to evaluate the spatial depth of each pixel on the screen. If a portal falls within the valid depth range, the sector and all sectors contained in it are rendered . The sorting process ensures that all surfaces are displayed in the correct order.

The sector system and the exact visibility evaluation at runtime enabled a level dynamic that had never been seen before. Sectors were freely movable and could - depending on the creativity of the level designer - represent everything imaginable. Typical examples of moving sectors are elevators, doors, destructible walls or moving objects such as cars and subways, with which the player could even move in some cases. In a static level geometry like the BSP system used in Doom , effects of this kind were difficult or even impossible to implement.

Objects

For opponents, items and other objects, as was typical at the time, two-dimensional sprites are used, which always point in the direction of the player ( billboard ). In addition, sprites can also be arranged rigidly vertically or horizontally, which is used in the games, for example, for traffic signs or simple bridge constructions.

In later build versions, Voxel objects are also used, for example in Blood or Shadow Warrior .

distribution

In terms of the number of commercial titles, the build engine is probably the most widely used 3D engine of the 1990s.

  • Games that were created directly with the build engine:
  • Games based on the Duke Nukem 3D - source code build:
  • Unpublished games:
    • Legend of the Seven Paladins (never released because the build engine was used without a license)
    • Fate (never finished, a demo version exists)
    • Corridor 8: Galactic Wars (never released, the source code was released)

successor

After several attempts to develop a successor to the build engine, Ken Silverman began to experiment with this idea again in 2006. He used this work - now called Build 2 - to teach children how to develop 3D games at a summer camp from 2007 to 2009. He worked on it until 2011 when he ultimately lost interest in the project. It includes an advanced lighting system, voxel rendering for objects and enemies, and real space-over-space positioning. In addition, at least partial downward compatibility with the original build engine was established. Silverman published his drafts on March 7, 2018. The source code was published on June 8, 2019.

Web links

Individual evidence

  1. ↑ Domonic Tarason: RPS . Rock, paper, shotgun . March 9, 2018.
  2. ↑ Alex Wawro: Gamasutra . Gamasutra . March 9, 2018.
  3. ↑ Andreas Bertits: Duke Nukem 3D: New version of the engine released . PC Games . March 13, 2018.
  4. ↑ BUILD2 Demo and Tools .