Build (game engine)
The Build engine is a first-person shooter engine created by Ken Silverman for 3D Realms. Like Doom, the Build engine represents its world on a two-dimensional grid using closed 2D shapes called sectors, and simple flat objects called sprites. It is widely considered a 2.5D engine as the basic world geometry is two-dimensional with an added height component as each sector may have a different ceiling and floor height, and the ceiling and floor may be angled along one line of the sector. The engine renders these sectors from a perspective that initially appears three-dimensional. However the sizing for perspective only depends on the horizontal distance (most noticable as the fact that wall verticies are always straight vertical lines onscreen). This can cause noticable distortion when looking up and down and so most build games restrict this to a fairly limited range of angles.
Sectors
The Build engine allowed for more complex and flexible worlds than Doom by virtue of its representation of the world information. Sectors could be manipulated in real-time; their shape, heights, and slope angles being completely variable, without requiring recalculation of rendering information.
Developers of games based on the engine used reserved sprites, often called sector effectors, that when given special tags (numbers with defined meanings), would allow the level designer to make a dynamic world that appeared to be 3D. 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 a player fall through the floor if he walked over it and teleport him into 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 currupted 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 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 room 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, that the engine actually stored the world geometry as proper 3D information.
Voxels
Later versions of kens build engine supported replacement of sprites with 3D objects made of voxels. This feature appeared too late for duke nukem 3D but was seen in several of the later build engine games.
Build engine games
The Build engine was most famous for powering the classic 3D Realms FPS Duke Nukem 3D. But was used in numerous other games.
- Games that were built directly on kens code.
- Games whose code was based on duke3D
- Nam
- WW2GI
- The Redneck Rampage series.
- Details unknown
room over room
Several build engine games used a trick involving rendering multiple times to draw two sectors joined floor to ceiling. The sectors could either be moved at map load time which made calculations during the game simpler or left where they were (building them over the top of each other wasn't really feasiable due to limitations of the editor. The two best known games to do this where shadow warrior (which moved the sectors at map load time) and blood (which didn't). It is important to stress that this is not a feature of the build engine but a trick discovered by game developers.
Source release and further developments
On the 20th of june 2000 (according to his website) ken released the build engine sourcecode.
The early days
A few total conversion teams for build games decided to base on kens build code directly and the Eduke project started moving towards using kens released build code (though it didn't really get anything out of it in a publically released version until after the source release of duke3D). It was claimed at the time by many on the 3DR 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 availible in a multi tasking environment (the people who claimed this obviously didn't realise how virtual memory works). An enhanced version of the build editor known as mapster was also developed.
The icculus port
Ryan C. Gordon (Icculus) 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++ which was the compiler used for the original dos build (Note: build is plain C despite being compiled with watcom C++). There was some talk of matt saettler using this to port eduke to windows but nothing came of this.
The jonof port
A second port was made to windows and later linux by Jonothen Fowler (jonof). Unlike the icculus port this used directdraw rather than SDL on windows and so was generally faster.
The duke nukem 3D source release
On the 1st april 2003 3D realms finally released the source code to duke3D after years of saying it would never happen. Not long afterwards both icculus and jonof had ports made. It was now possible to play duke nukem 3D well on the NT line of windows and interest in the ports soared.
Polymost
[[image:rawmeat polymost.png|looking down in raw meat in polymost mode, notice the full 3D perspecive with the After the windows build ports it was often claimed by long timers on the 3DR forums that it would not be possible to make build render to polygons. The particular issue that they picked on this time was how to turn the floors into a series of triangles with decent speed. Eventually ken silverman got sick of the claims that it was impossible and decided to do it himself based on the jonof port. Soon afterwards support for 3D models was added and eventually support for voxels was added too. The addition of polymost to the Jonof port made it far more attractive than the ICCULUS based versions though netcode issues meant that ICCULUS based ports remained the norm for multiplayer until quite recently.