Build-Engine

aus Wikipedia, der freien Enzyklopädie
Wechseln zu: Navigation, Suche

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.

Entwicklung[Bearbeiten]

Ken Silverman begann die Entwicklung der Build-Engine im März 1993. Zu dieser Zeit hatte er die Vollversion 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[Bearbeiten]

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 auch abwertend „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änkung 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[Bearbeiten]

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.

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[Bearbeiten]

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[Bearbeiten]

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:
  • Nicht veröffentlichte Spiele:
    • Legend of the Seven Paladins (niemals 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)

Weblinks[Bearbeiten]