Build-Engine
Basisdaten
Entwickler Ken Silverman
Betriebssystem PC-kompatibles DOS
Programmiersprache C
Kategorie Spiel-Engine
deutschsprachig nein
advsys.net/ken/build.htm

Bei der Build-Engine handelt es sich um eine 3D-Engine für Computerspiele, welche von Ken Silverman für 3D Realms entwickelt wurde und die erstmals beim Ego-Shooter Duke Nukem 3D zum Einsatz kam. Die Engine ist mit der wenige Jahre älteren Doom-Engine (auch id Tech 1) vergleichbar. Mit Ion Fury (ehemals Ion Maiden) erschien im August 2019 wieder ein Ego-Shooter auf Basis einer verbesserten Build-Engine.

Entwicklung

Ken Silverman begann die Entwicklung der Build-Engine im März 1993. Zu dieser Zeit hatte er die finale Version seines ersten kommerziell erfolgreichen Spiels, Ken’s Labyrinth, für Epic fertiggestellt. Dieses Spiel basierte ebenfalls auf einer komplett selbst entwickelten 3D-Engine, die technisch mit Wolfenstein 3D vergleichbar war. Mit „Build“ orientierte sich Silverman eindeutig an den Standards, die Doom gesetzt hatte. Technisch wurden jedoch einige andere Ansätze verfolgt – „Build“ stellt somit nicht bloß einen Klon der Doom-Engine dar.

Technik

Frühere Ego-Shooter-Engines wie die von Wolfenstein 3D bekannte nutzen das vergleichsweise schnelle Raycasting zur Darstellung der dreidimensionalen, aus der Egoperspektive gezeigten Spielwelt. „Build“ erweitert diese Technologie stark und kombiniert schnelle zweidimensionale, an Raycasting angelehnte Ansätze mit solchen, die auch in späteren Grafik-Engines mit echter Dreidimensionalität zum Einsatz kommen. Die Level-Geometrie basiert auf einem zweidimensionalen Grundriss und ist damit deutlichen Einschränkungen unterworfen, die der Leveldesigner beachten muss und die sich teilweise auch auf die Freiheitsgrade des Spielers auswirken. So ist es beispielsweise nicht möglich, senkrecht nach oben oder unten zu sehen. Strukturen mit mehreren Ebenen – beispielsweise Brücken oder Gebäude mit mehreren Etagen – sind nur mit Tricks darstellbar. Engines dieser Art werden auf Grund der Einschränkungen auch „2,5D-Engines“ genannt.

Im Gegensatz zu Ken’s Labyrinth und anderen früheren Engines (etwa den in Wolfenstein 3D oder System Shock eingesetzten) sind die Grundrisse in der Build-Engine nicht an ein festes quadratisches Raster gebunden. Wände müssen senkrecht sein, können aber in beliebigen Winkeln aneinander stoßen. Ferner erlaubt die Engine unterschiedliche Höhenwerte sowie das Kippen von Böden und Decken. Den Leveldesignern ermöglichte dies, ein viel intensiveres dreidimensionales Spielgefühl zu vermitteln, da die Levelgeometrie nicht auf eine Ebene beschränkt war. Um die noch bestehenden Beschränkungen zu umgehen, wurden verschiedene Tricks angewendet. Im ersten Build-Spiel Duke Nukem 3D befinden sich einige Bereiche tatsächlich gar nicht übereinander, wie die Level-Architektur vermuten lässt; der Spieler wird jeweils nur im richtigen Augenblick unbemerkt an eine andere Stelle des Levels teleportiert. Beispiele hierfür sind das Eintauchen in Unterwasserbereiche oder der Sprung in Schächte. Wendeltreppen und ähnliche Konstruktionen mit übereinander liegenden Räumen sind möglich, der Leveldesigner muss jedoch sicherstellen, dass der Spieler nie mehr als eine Ebene gleichzeitig einsehen kann.

Lösung des Sichtbarkeitsproblems

Was den Auswertungsmechanismus für sichtbare Flächen betrifft, verhält sich Build wie eine Portal-Engine. Die atomaren Abschnitte des Levels, in Build „Sektoren“ genannt, sind durch spezielle Verbindungsflächen („Portale“) miteinander verbunden. Der Algorithmus folgt allen sichtbaren Sektoren und stellt diese dann dar. Die verwendeten Algorithmen und die Art der Datenorganisation unterscheiden sich jedoch von anderen Engines. Silverman verwendete eine Kombination aus exakter Tiefensortierung und vertikalem Span-Buffer zur Auswertung der räumlichen Tiefe jedes Pixels auf dem Bildschirm. Fällt ein Portal in den gültigen Tiefenbereich, wird der Sektor und alle darin enthaltenen Sektoren gerendert. Das Sortierverfahren stellt sicher, dass alle Flächen in der richtigen Reihenfolge dargestellt werden.

Über Tags und Effectors können Knöpfe und Bewegungen von Sektoren über numerische IDs verknüpft werden. Das Sektoren-System und die exakte Sichtbarkeitsauswertung zur Laufzeit ermöglichte eine bis dahin nicht dagewesene Level-Dynamik. Sektoren waren frei beweglich und konnten – abhängig von der Kreativität des Leveldesigners – alles erdenkliche darstellen. Typische Beispiele für bewegte Sektoren sind Fahrstühle, Türen, zerstörbare Wände oder bewegliche Objekte wie Autos und U-Bahnen, mit denen sich der Spieler teilweise sogar fortbewegen konnte. In einer statischen Level-Geometrie wie dem in Doom verwendeten BSP-System waren Effekte dieser Art umständlich bis gar nicht umzusetzen.

Objekte

Für Gegner, Items und andere Objekte werden, wie zur damaligen Zeit typisch, zweidimensionale Sprites verwendet, welche immer in Richtung des Spielers zeigen (Billboard). Daneben können Sprites auch starr senkrecht oder waagerecht angeordnet werden, was in den Spielen beispielsweise für Verkehrszeichen oder einfache Brückenkonstruktionen genutzt wird.

In späteren Build-Versionen werden auch Voxel-Objekte verwendet, so zum Beispiel in Blood oder Shadow Warrior.

Verbreitung

Die Build-Engine ist, gemessen an der Anzahl kommerzieller Titel, die wohl meistgenutzte 3D-Engine der 1990er Jahre.

  • Spiele, welche direkt mit der Build-Engine erstellt wurden:
  • Spiele, die auf den Duke-Nukem-3D-Quelltexten aufbauen:
    • Extreme Paintbrawl (1998)
    • NAM (1998)
    • Redneck Deer Huntin (1997)
    • Redneck Rampage (1997)
    • Redneck Rampage Rides Again (1998)
    • WW2 GI (1999)
  • Nicht veröffentlichte Spiele:
    • Legend of the Seven Paladins (niemals erschienen, da die Build-Engine ohne Lizenz genutzt wurde)
    • Liquidator (nur in Russland erschienen, da die Build-Engine ohne Lizenz genutzt wurde)
    • Fate (niemals fertiggestellt, eine Demoversion existiert)
    • Corridor 8: Galactic Wars (nie erschienen, die Quelltexte wurden freigegeben)

Nachfolger

Nach mehreren Versuchen einen Nachfolger der Build-Engine zu entwickeln, begann Ken Silverman 2006 erneut mit dieser Idee zu experimentieren. Er verwendete diese Arbeit – inzwischen Build 2 genannt – um Kindern in einem Sommercamp von 2007 bis 2009 die Entwicklung von 3D-Spielen beizubringen. Er arbeitete bis 2011 daran, als er letztlich das Interesse an diesem Projekt verlor. Es beinhaltet ein erweitertes Beleuchtungssystem, Voxel-Rendering für Gegenstände und Gegner und echte Raum-über-Raum-Positionierung. Zudem wurde zumindest eine teilweise Abwärtskompatibilität zur ursprünglichen Build-Engine hergestellt. Silverman veröffentlichte seine Entwürfe am 7. März 2018. Der Quelltext dazu wurde am 8. Juni 2019 veröffentlicht.

Einzelnachweise

  1. ↑ Michael Obermeier, Christian Fritz Schneider: Frisch gestrichen: Duke Nukem 3D - Brutal, sexistisch & wieder vom Index. In: GameStar. 18. Februar 2017, abgerufen am 25. Januar 2021.
  2. ↑ Andreas Bertits: Ion Maiden: Shooter heißt nun Ion Fury und hat Releasetermin. In: PC Games. 11. Juli 2019, abgerufen am 31. Januar 2021.
  3. 1 2 Boris Schneider-Johne: Build It Yourself. In: PC Player. Juli 1996, S. 36–37 (Textarchiv – Internet Archive).
  4. ↑ Max Ylitalo: Dev Blog #1: 3D in Build engine and Ion Fury. 3D Realms, 31. Oktober 2018, abgerufen am 30. Januar 2021 (englisch).
  5. ↑ Fabien Sanglard: Duke Nukem 3D: Build Engine Internals. In: Fabien Sanglard's Website. 14. Februar 2013, abgerufen am 30. Januar 2021.
  6. ↑ Philipp Reuther: Hardware- und Grafikeffekte Teil 8: Schattendarstellung. In: PC Games. 27. August 2017, abgerufen am 26. Januar 2021.
  7. ↑ Domonic Tarason: Ken Silverman's long-lost BUILD2 engine released. Rock, Paper, Shotgun, 9. März 2018.
  8. ↑ Alex Wawro: Now you can muck around with the Build engine successor: Build2. Gamasutra, 9. März 2018.
  9. ↑ Andreas Bertits: Duke Nukem 3D: Neue Version der Engine veröffentlicht. PC Games, 13. März 2018.
  10. ↑ BUILD2 Demo and Tools. In: advsys.net.
This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.