"Build, the powerful 3D Realms game engine written by Ken Silverman, boasts some of the hottest features available in a 3D game." — Blood Website
Build is the 3D rendering engine used in Blood and its expansion packs Cryptic Passage and the Plasma Pak. It was created by Ken Silverman, previous creator of Ken's Labyrinth (published by Epic MegaGames), under contract by 3D Realms (formerly known as Apogee Software) from June 1993 onward. It was licensed to Monolith Productions when they purchased the rights to Blood and QStudios, who originally bought it from 3D Realms.
3D Realms used this engine internally for its games Duke Nukem 3D and Shadow Warrior, both of which played similarly to Blood. Build has also been licensed out for a variety of other games, most notably the PC version of PowerSlave, which like Blood started out as part of an extended 3D Realms stable only to eventually be transferred to other publishers. Most recently the engine has been used in a modern game published by a revived 3D Realms in 2019 called Ion Fury by Duke4 affiliated developer VoidPoint.
The engine was controversially supplanted by the Kex Engine in the official remaster Blood: Fresh Supply. Updated community variants however, most notably the EDuke32 project among others, are the basis for unofficial source ports BloodGDX and NBlood (plus the fork Raze), as well as earlier fan recreation BloodCM.
The Build engine renders its world on a two-dimensional grid using closed 2D shapes called "sectors" and simple flat objects called "sprites" to populate the world geometry with objects. It is generally considered to be a 2.5D engine, since 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. However the final result is that the world looks three-dimensional due to the way the engine renders it. The version of the Build engine used in Blood also makes use of the voxel technology for weapon/ammo pickups, power ups and occasionally decorations, such as the tombstones in the first level of episode one, "Cradle to Grave". It also supports viewports, where glimpses of other sectors may be displayed, used for simulating room-over-room and transparent water.
"I wrote the Build Engine. I visited the team in Redmond 3 times, each for about a week. During those times, I worked closely with the programmers - Nick Newhard and Peter Freese. Those guys also visited Texas in 1995 for about 2 weeks. I was mostly helping them fix bugs related to the engine. I helped them to implement network code. The room over room effect was something I started collaboratively with Nick." — Ken Silverman
The development of the version of Build used in Blood was mostly conducted by Peter Freese and Nick Newhard in combination with Ken Silverman; he visited the QStudios team two times, and once more at the Monolith Productions offices. The Blood team also visited him once in Texas in 1995, where he was working with 3D Realms, and Newhard regularly called Silverman whilst he was in his first semester of college. As revealed in documents included with the leaked Blood Alpha, this relationship was not smooth. The abrupt tweaks and unconventional coding style of the young maverick clashed with those of seasoned developers like Peter Freese.
"Ken understands algorithms, and he understands graphics. What he doesn't get is how to design SYSTEMS. Everything he does to the engine is a piecemeal enhancement to something that should have been designed right from the beginning. The memory system is a poignant example of this. It is a hack, like most of his code, and not very robust. From what I've disassembled of the group file code (trying to figure out a way to eliminate or replace it), it too demonstrates plentiful opportunities for crashing the system -- pointers being freed without validation, files being closed without verifying the handle, etc... Tonight I tried to explain to Ken what a library file is. I told him how linkers work, and how they resolve symbol name when producing an executable. I tried to impress on him the benefits of 'code granularity' -- breaking a system up into as many small discrete modules as possible so that the linker can efficiently pack only used code into the executable. I informed him about 'dead code', and why there was so much of his in Blood. I don't think I made any impression at all." — GEORGE.TXT, Blood Alpha
This proved to be only one dimension of a growing conflict between 3D Realms and Monolith, also delineated on in the accompanying EPIC.TXT file in the Alpha. On the split between 3D Realms and Monolith, Silverman himself commented:
"You would have to ask Scott Miller, George Broussard, or Jason Hall about the specific reasons for the split-up [between Monolith and 3D Realms]. From what I hear, things weren't working out very well - they disagreed on what would make a good game. I visited the Blood team a total of 3 times - the final time was at the Monolith office." — Ken Silverman
Silverman has stated his final views on the big three games built on the engine thus:
After the source code of many games and engines had been released by their respective owners, an intense fan campaign called for the release of the Blood source code (see: Blood Source Campaign)
File types used with the original Blood and its various commercial and fan made add-ons.
EXE and COM
An executable file format used by a variety of IBM PC compatible operating systems, most prominently MS-DOS and Windows. Blood's stock EXEs are DOS only (with exceptions to the GOG version's DOSBox exe's), however certain launchers' and other utilities' may be hybrid or Windows only.
Configuration file that stores display, control and other customizable settings information.
Text files are often used for storing background materials, installation instructions, or other pertinent information. Some may also use RTF or PDF.
A modem string file for use with network mutliplayer and storing INIT strings.
Initialization file; often used to store information pertinent to structuring episodes, such as level order, names, music, authors, messages, etc. There are also special "Network Game" INI files which essentially store multiplayer game rules and other options; a primitive form of game management. Other programs (launchers, editors, ect.) will often also use INI files, though usually for a different purpose.
Launched via the command parameter: "blood -ini example.ini". By default will load the stock "blood.ini" file without any parameters, however will actually load any INI file with this name. This can be exploited to force Blood to support features that aren't normally supported when playing custom maps/episodes, such as demo playback.
For Network Game INIs, the person loading the file uses the parameter "-getopt" , whilst everyone else uses "-auto".
Stores sector data for map construction, as well as tagging points and object placements.
Launched via the command parameter: "blood -map example.map"
Stores information pertaining to textures, sprites and so forth. Cryptic Passage uses the extension .AR_ for it's art files.
Used to store voxel mappings (3D pixels).
A special proprietary archive format Blood uses in place of Build's traditional GRP format.
Blood includes three of these files: BLOOD.RFF, GUI.RFF and SOUNDS.RFF.
Used for storing information related to CD audio.
Common audio format on Microsoft (Windows & DOS) PCs. Blood uses them to add sound to its cutscenes, though mods may use them for other purposes too.
Another common format on Windows. This one contains both audio and video. Like the previous two, Blood uses these for it's cutscenes though only when ran from Windows 95/98.
RAW and SFX
RAW is a format for storing uncompressed audio. It is often accompanied by a SFX file which contains some additional metadata and the sound's properties (relative volume, ect.)
Stores information for real-time animations, such as the menus, help screen and weapon animations; modified in the "Weapons Mod".
Stores information for enemy and NPC animations.
Stores information for re-playing live game demos. In the early days of the internet, before sharing videos or streams of gameplay was feasible, this is how you shared your gameplay. It store all the player's actions and repeats them, imitating a video.
Use parameter "-record" or the "SPIELBERG" cheat in talk box to record a demo. Use the "-playback" parameter to replay a recorded demo. Note that Default demos ("Blood***.dem") have to be removed to properly use these functions as the defaults oddly have priority over the user made demos. However the default demos can be replaced with user made ones which will be played sequentially in order. Also note that demos are disabled by default for Cryptic Passage and user made add-ons, but as noted above in the INI section, they can be enabled by renaming the add ons' INI file in the main "blood.ini"'s place. Utilizing both tricks, a mod developer can enable a full sequential set of demos for their episode(s); such a thing is best done with batch scripts to rename (or move) then revert the original files as to not overwrite them.
Game save files, these contain the various status and other progress info that is restored when selected in the load menu. Don't delete these unless necessary.
A very old picture format for IBM PCs. Blood can generate these by pressing F12 in-game, though for DOSBox users it's probably better to use an external capture program to make images in a modern format (i.e. PNG, JPEG, ect.)
DAT, TMP, BAK and BME
Stores generic data of any category. TMP is often used for files that are temporarily moved out the way to be replace by others. BAK is often used for files that are modified, a backup is made just in case the modification process damaged the file. BME is often used by mod developer BME for his mod sets.
Blood only has four DAT files by default: SURFACE.DAT, TABLES.DAT, VOXEL.DAT and COMMIT.DAT. The other types are only encountered in mods or other utilities.
"You can destroy anything right down to the signs on the walls. Unlike Duke, we have somewhere in the region of 30 different chip types. Burning wood, regular wood, metal, rocks, plants. Pretty much everything can be destroyed and pretty much everything has its own individual look when it gets wrecked." — Craig Hubbard
- 0 = None
- 1 = Stone
- 2 = Metal
- 3 = Wood
- 4 = Flesh
- 5 = Water
- 6 = Dirt
- 7 = Clay
- 8 = Snow
- 9 = Ice
- 10 = Leaves
- 11 = Cloth
- 12 = Plant
- 13 = Goo
- 14 = Lava
- Ken Silverman's Build Engine page
- Build Engine - Wikipedia
- Build Engine - MobyGames
- Build Engine - Giant Bomb
- Build Engine - ModDB
- Build Engine - IndieDB
- Build engine based games compilation - YouTube
- RTCM - Build Engine and Game Resources
- Duke Nukem 3D: Build Engine Internals - Code Review
- Ken Silverman - Videogame Music Preservation Foundation Wiki
- History of the Build Engine - 3D Relams (March 12, 2018)
- Dev Blog #1: 3D in Build engine and Ion Fury - 3D Realms - Firepower Matters (October 31, 2018)
- Upscaling Build Engine Games - Upscale Wiki
- JFBuild website
- The Build Engine Porting Project - icculus.org
- ProASM ports
- EDuke32 Engine (derivative ports)
- LAB3D/SDL (updated with hi-res textures)
Ken Silverman Interviews
- DOS Games Archive
- Pickles Revil
- Strife Streams (2001)
- Strife Streams (2005)
- Classic DOS Games (November 21, 2005)
- The Apogee Legacy (February 27, 2006)
- Blood Wiki (October 23, 2008)
- Videogame Potpourri (May 1, 2012)
- Duke Nukem Forever - What Went Wrong - NowGamer (August 15, 2011)
- Meet the voxel, the pixel’s long-lost cousin, and why it became videogames’ Betamax - Kill Screen (July 24, 2013)
- There's more to graphics tech than resolutions and framerates - bit-tech (June 6, 2014)
- Blood, Sweat & Laughter: The Beauty of the Build Engine - Rock, Paper, Shotgun (April 13, 2016)
- Behind the scenes with Voxon Chief Computer Scientist Ken Silverman