Construir (motor del juego)

Los sectores son los bloques de construcción del diseño de un nivel, consistentes en un contorno poligonal bidimensional visto desde arriba, con las caras superior e inferior del sector con altitudes separadas para crear un espacio tridimensional. ^{[ 2 ]} Por lo tanto, todas las paredes son perfectamente verticales; cualquier cosa que parezca lo contrario es técnicamente un suelo o techo inclinado. La palabra habitación puede usarse como un sustituto informal para facilitar la comprensión, aunque una habitación en el mundo del juego puede constar de muchos sectores, y los cielos con paralaje pueden dar la ilusión de estar al aire libre. Los sectores se pueden manipular en tiempo real; todos sus atributos, como la forma, la altura y la pendiente, podían modificarse "sobre la marcha" por los juegos, a diferencia del motor Doom anterior . Esto permitió que los juegos tuvieran entornos destructibles, como los que se ven en Blood . ^{[ 2 ]} Esta técnica es similar al uso de paredes de empuje en el título anterior de Apogee Software, Rise of the Triad , que presentaba entornos dinámicos similares.

Los desarrolladores de juegos basados ​​en este motor utilizaban "sprites" (objetos de juego) especiales reservados, a menudo llamados " efectores de sector " , que, al recibir etiquetas especiales (números con significados definidos), permitían al diseñador de niveles construir un mundo dinámico; información de etiquetas similar podía aplicarse a las paredes y el suelo de los sectores para dotarlos de características especiales. Por ejemplo, un efector de sector concreto podía permitir a los jugadores atravesar el suelo al caminar sobre él y teletransportarlos a otro sector; en la práctica, esto podía utilizarse para crear el efecto de caer por un agujero a una habitación más grande o crear una masa de agua en la que se pudiera saltar para explorar bajo el agua. A un sector se le podía asignar una etiqueta que lo hiciera comportarse como un ascensor.

Los sectores podían superponerse, siempre que no se vieran al mismo tiempo (si se veían dos sectores superpuestos al mismo tiempo, se producía un efecto de espejos ). ^{[ 3 ]} Esto permitió a los diseñadores crear, por ejemplo, conductos de aire que parecían extenderse por encima de otra habitación (sin embargo, hacerlo podía ser complicado para los diseñadores debido al punto de vista 2D utilizado en gran parte del proceso de edición). Esto permitió a los diseñadores crear mundos que serían físicamente imposibles (por ejemplo, la puerta de un edificio pequeño podía conducir a una red de habitaciones más grandes que el propio edificio). Si bien todo esto hacía que los juegos que usaban el motor parecieran 3D, no sería hasta los juegos de disparos en primera persona posteriores, como Quake , que usaba el motor Quake , que el motor realmente almacenaba la geometría del mundo como información 3D real, lo que hacía muy factible la creación de un área apilada sobre otra área en un solo mapa.

Las versiones posteriores del motor Build Engine de Ken Silverman permitieron reemplazar los mosaicos artísticos seleccionados del juego por objetos 3D hechos de vóxeles . Esta característica apareció demasiado tarde para usarse en Duke Nukem 3D , pero se vio en algunos de los juegos posteriores del motor Build Engine. Blood usa vóxeles para recoger armas y munición, potenciadores y elementos visuales (como las lápidas en el nivel "Cradle to Grave", algunas sillas y una bola de cristal en "Dark Carnival"). Shadow Warrior hace un uso aún más avanzado de la tecnología, con vóxeles que se pueden colocar en las paredes (todos los interruptores y botones del juego son vóxeles).

Durante varios años, Ken trabajó en un motor moderno basado completamente en vóxeles, conocido como Voxlap .

Una limitación del motor de construcción es que su geometría de nivel solo puede representar una conexión entre sectores para cada pared. Por ello, una estructura tan simple como una repisa con espacio tanto arriba como abajo resulta imposible, aunque a veces se pueden usar sprites o vóxeles. Si bien técnicamente es posible construir edificios de varias plantas, no es posible que uno de ellos contenga una ventana exterior directamente encima o debajo de otra. Además, será necesario tomar ciertas libertades con las escaleras, los ascensores y otros métodos de acceso a cada planta.

Varios juegos de Build Engine (como Shadow Warrior , Blood y Redneck Rampage ) sortearon este problema mostrando una "ventana gráfica" a otro sector mediante un pase de renderizado adicional. Esta técnica, llamada room-over-room (ROR), parece imperceptible para el jugador. Además de ampliar el rango de construcción vertical, ROR se usaba a menudo para dar a las masas de agua superficies translúcidas . ROR nunca fue una característica del propio Build Engine, sino más bien un "truco" creado por los desarrolladores del juego. Un truco utilizado en Duke Nukem 3D para sortear esto, como en el caso de sus secciones submarinas opacas, consistía simplemente en transportar rápidamente al jugador a otra región del mapa diseñada para imitarla, similar a los ascensores de Rise of the Triad .

En 2011, se añadió a EDuke32 una función llamada TROR ( True Room Over Room ), que permite apilar varios sectores verticalmente de forma que la pared de cada sector tenga su propia conexión, posibilitando estructuras sin restricciones verticales. La diferencia entre ROR y TROR radica en que los sectores TROR se superponen físicamente en los datos del mapa y el editor (lo que facilita su creación y visualización), en lugar de dibujarse desde ubicaciones separadas mediante portales de vista; de ahí el nombre TROR . TROR es una función del motor gráfico de EDuke32, no una característica o truco del juego.

• Fate (sin terminar, solo existe una demo)
• Corredor 8: Guerras Galácticas (sin terminar, el código fuente está disponible)

La versión 2.0 de EDuke , un proyecto de Matt Saettler (Matteus) para mejorar Duke Nukem 3D para modders , se envió a 3D Realms para su empaquetado poco después del lanzamiento del código fuente de Build, dejando a Duke Nukem 3D con las bibliotecas precompiladas que 3D Realms había utilizado con el Duke original. (Tanto Duke Nukem 3D como EDuke seguían siendo de código cerrado en ese momento).

Con las versiones beta privadas 2.1 , Saettler trabajó para integrar el código fuente de Silverman en el código fuente de Duke, pero el proyecto fracasó antes de producir algo más que unas betas privadas con muchos errores. Algunos equipos de conversión total para juegos de Build decidieron trabajar directamente con el código de Silverman, y también se desarrolló una versión mejorada del editor de Build conocida como Mapster.

En aquel entonces, muchos usuarios de los foros de 3D Realms afirmaron que sería imposible adaptar Build a un sistema operativo multitarea, ya que requería un gran bloque de memoria contigua que no estaría disponible en un entorno multitarea. Esta afirmación no se sostuvo tras un análisis más profundo, puesto que todos los sistemas operativos modernos utilizan memoria virtual , lo que permite a las aplicaciones acceder a memoria lógica contigua sin utilizar memoria física contigua. Sin embargo, la opinión generalizada en aquel momento era que adaptar Build a un sistema operativo de este tipo era inviable.

El 1 de abril de 2003, tras varios años de afirmaciones en contrario, 3D Realms publicó el código fuente de Duke Nukem 3D bajo la licencia GPL-2.0 o posterior . ^{[ 13 ]} Poco después, tanto Ryan C. Gordon (icculus) como Jonathon Fowler (JonoF) crearon y publicaron versiones del código fuente del juego, incluido el motor de compilación. Era posible jugar a Duke Nukem 3D sin problemas en la línea NT de Windows (incluidos Windows 2000/XP) y en Linux y otros sistemas operativos Unix , y el interés por las versiones del código fuente se disparó.

Ryan C. Gordon (icculus), con la ayuda de otros, hizo el primer puerto del motor usando SDL . El puerto fue primero a Linux , luego a Cygwin , y finalmente a una compilación nativa de Windows usando el compilador Watcom C++ , que fue el compilador usado para la compilación original de DOS (a pesar de ser compilado con Watcom C++, Build es C simple.) ^{[ 14 ]} Hubo algo de conversación de que Matt Saettler usaría esto para portar EDuke a Windows, pero no se llegó a nada. Una versión de Duke Nukem 3D fue producida más tarde después de que se publicó el código fuente. ^{[ 15 ]} Este también fue bifurcado por David Koenig (Rancidmeat) como Duke3d_w32 que a su vez fue bifurcado en los enfocados en multijugador xDuke, hDuke, nDuke y rDuke.

Jonathon Fowler (JonoF) realizó una segunda adaptación del código fuente para Windows, y posteriormente para Linux y Mac OS X. Esta adaptación, JFDuke3D, inicialmente no tenía soporte para juegos en red, aunque se añadió posteriormente durante el desarrollo. Tras un largo periodo de inactividad, se publicó en GitHub en 2020 y recibió actualizaciones en 2021 y 2024. ^{[ 16 ] [ 17 ] [ 18 ]} También adaptó el juego de prueba Ken-Build. ^{[ 19 ]}

Un mes después del código del juego, también se publicó el código fuente de EDuke 2.0, ^{[ 21 ]} seguido del código fuente de la última beta privada de EDuke 2.1 (que nunca llegó a una versión final). Richard Gobeille (TerminX) fusionó el código fuente de EDuke 2.0 con JFDuke3D para crear EDuke32 . Otro port, Wineduke , basado en el código de icculus, ha sido abandonado, dejando a EDuke32 como el único port de EDuke que aún está en desarrollo. ^{[ 22 ]}

EDuke32 también es compatible con los juegos NAM y WWII GI , ya que EDuke se basó en el código de esos juegos.

El código fuente de Shadow Warrior se publicó el 1 de abril de 2005 bajo la licencia GPL-2.0 o posterior , y JonoF publicó un puerto fuente del mismo, JFShadowWarrior, el 2 de abril de 2005. ^{[ 23 ]} Sin embargo, admitió que tuvo acceso al código fuente de Shadow Warrior aproximadamente una semana antes de su publicación. ^{[ 24 ]} El puerto quedó en un estado parcialmente incompleto, antes de ser publicado en GitHub en 2020 y recibir actualizaciones en 2021 y 2024. La versión anterior fue posteriormente bifurcada por Ben Smit (ProASM) para el puerto SWP. ^{[ 25 ]} Se inició un puerto de Shadow Warrior para icculus , pero permaneció en fase alfa. ^{[ 26 ]} Una versión de VoidSW desarrollada por Ion Fury y EDuke32 entró en beta pública el 21 de mayo de 2020. ^{[ 27 ]} También existe una bifurcación de una versión anterior, llamada IcedSW, creada por Justin Marshall (IceColdDuke). ^{[ 28 ]}

El proyecto Transfusion tenía como objetivo recrear Blood en el motor DarkPlaces , ^{[ 29 ]} pero en 2007, este proyecto estaba lejos de estar completo, aunque tiene un modo multijugador de deathmatch jugable; un proyecto similar es BloodCM que recrea todos los niveles de un jugador creados por Monolith para Blood sobre EDuke32, ^{[ 30 ]} así como ZBlood que traslada algunos recursos y niveles de Blood a ZDoom . ^{[ 31 ]} El proyecto eRampage intentó crear una conversión total de Redneck Rampage para EDuke32. ^{[ 32 ]} Mientras tanto , DN3DooM , ^{[ 33 ] [ 34 ] [ 35 ]} Shadow Warrior TC , ^{[ 36 ]} Doomed Redneck , ^{[ 37 ]} Re-Blood , ^{[ 38 ]} Re-PowerSlave , ^{[ 39 ]} VietDoom , ^{[ 40 ] [ 41 ] [ 42 ] [ 43 ]} y Fatedoom ^{[ 44 ]} adaptan esos juegos a GZDoom .

El código fuente de Witchaven , Witchaven II: Blood Vengeance , William Shatner's TekWar y Corridor 8: Galactic Wars también salió a la luz en 2007 del desarrollador Les Bird. ^{[ 45 ]} Sin embargo, el estatus legal de estos no está claro, aunque los parches derivados de EGwhaven para Witchaven se incluyeron en los relanzamientos del juego en Steam y GOG.com . ^{[ 46 ]} JonoF lanzó puertos para Witchaven y TekWar el 3 de marzo de 2024; ^{[ 47 ]} con puertos derivados de ETekWar y EWitchaven también prototipos. ^{[ 48 ]} El código fuente completo de varias versiones alfa de Blood también se ha filtrado con el tiempo. ^{[ 49 ]}

Esto se utilizó como referencia para una adaptación a Java mediante ingeniería inversa utilizando LibGDX llamada BloodGDX en mayo de 2017 por Alexander Makarov (M210), el autor anterior de BloodCM . ^{[ 50 ]} Esto siguió a la adaptación anterior de TekWar del autor publicada en enero de 2016, ^{[ 51 ]} y ha sido seguida por adaptaciones para Witchaven , ^{[ 52 ]} Redneck Rampage , ^{[ 53 ]} Duke Nukem 3D , PowerSlave , Legends of the Seven Paladins y Shadow Warrior , ahora todos llamados colectivamente BuildGDX. ^{[ 54 ]} DukeGDX también admite los archivos de la edición del 20.º aniversario de World Tour de Duke Nukem 3D . ^{[ 55 ]}

Un puerto adicional de Blood , llamado NBlood, fue lanzado en enero de 2019 por Alexey Khokholov (Nuke.YKT) basado en EDuke32, ^{[ 56 ]} y el puerto anterior de Rednukem del creador para Redneck Rampage (que también admite Duke Nukem 3D y Duke Nukem 64 ). ^{[ 57 ] [ 58 ]} Un puerto EDuke32 para PowerSlave , llamado PCExhumed , fue lanzado el 21 de noviembre de 2019 por Barry Duncan (sirlemonhead) con la ayuda de Nuke.YKT. ^{[ 59 ]} El puerto fuente Raze bifurca varios puertos del motor Build, incluidos JFDuke3D, SWP, NBlood, Rednukem y PCExhumed, y lo vincula a un nuevo backend subyacente basado en el propio GZDoom de los desarrolladores . ^{[ 60 ]} NBlood y PCExhumed también se han adaptado a JFBuild con el fin de hacerlo compatible con plataformas como Amiga , PlayStation Vita y Nintendo 3DS . ^{[ 61 ]}