Build Engine es un motor de disparos en primera persona creado por Ken Silverman , autor de Ken's Labyrinth , para 3D Realms . Al igual que el motor Doom , Build Engine representa su mundo en una cuadrícula bidimensional utilizando formas 2D cerradas llamadas sectores, y utiliza objetos planos simples llamados sprites para poblar la geometría del mundo con objetos.
El motor de construcción se considera generalmente un motor 2.5D , ya que la geometría básica del mundo es bidimensional con un componente de altura añadido, lo que permite que cada sector tenga una altura de techo y de suelo diferente. Algunos pisos pueden ser más bajos y otros más altos; lo mismo ocurre con los techos (en relación entre sí). Los pisos y los techos pueden girar a lo largo de una de las paredes del sector, lo que da como resultado una pendiente. Con esta información, el motor de construcción renderiza el mundo de una manera que parece tridimensional , a diferencia de los motores de juegos modernos que crean entornos 3D reales.
Aunque el motor Build alcanzó la mayor parte de su fama gracias al juego de disparos en primera persona Duke Nukem 3D de 1996 , también se utilizó para muchos otros juegos.
Los sectores son los bloques de construcción del diseño de un nivel, que consisten en un contorno poligonal bidimensional cuando se ve 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 piso o techo inclinado. La palabra habitación se puede usar como un sustituto suelto para ayudar a la comprensión, aunque una habitación en el mundo del juego puede constar de muchos sectores, y los cielos paralajeados 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, se pueden modificar "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 el motor utilizaron "sprites" especiales reservados (objetos del juego), a menudo llamados "efectores de sector [ sic ]", que, cuando se les daban etiquetas especiales (números con significados definidos), permitían al diseñador de niveles construir un mundo dinámico; se podía dar información de etiqueta similar a las paredes del sector y al área del suelo para darle características especiales al sector. Por ejemplo, un efector de sector en particular podía dejar que los jugadores cayeran a través del suelo si caminaban sobre él y los teletransportaba a otro sector; en la práctica, esto se podía usar para crear el efecto de caer por un agujero a una habitación más grande o crear un cuerpo de agua al que se pudiera saltar para explorar bajo el agua. Se podía dar una etiqueta a un sector que hiciera que se comportara como un ascensor o un elevador.
Los sectores podían superponerse entre sí, siempre que no pudieran verse al mismo tiempo (si se veían dos sectores superpuestos al mismo tiempo, se producía un efecto de salón de espejos ). [3] Esto permitió a los diseñadores crear, por ejemplo, conductos de aire que parecieran extenderse por la parte superior de otra habitación (sin embargo, hacerlo podía ser complicado para los diseñadores debido al punto de vista 2D utilizado para gran parte del proceso de edición). Esto permitió a los diseñadores crear mundos que serían físicamente imposibles (por ejemplo, una puerta de un edificio pequeño podía conducir a una red de habitaciones más grande que el edificio en sí). Si bien todo esto hizo 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 almacenó la geometría del mundo como información 3D real, lo que hizo que la creación de un área apilada sobre otra área en un solo mapa fuera muy factible.
Las versiones posteriores del motor de construcción de Ken Silverman permitieron que los mosaicos de arte seleccionados del juego se reemplazaran por objetos 3D hechos de vóxeles . Esta característica apareció demasiado tarde para ser utilizada en Duke Nukem 3D , pero se vio en algunos de los juegos posteriores del motor de construcción. Blood usa vóxeles para recoger armas y municiones, potenciadores y adornos 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 enteramente en vóxeles, conocido como Voxlap .
Una limitación del motor de construcción es que su geometría de niveles solo es capaz de representar una conexión entre sectores para cualquier pared dada. Debido a esto, una estructura tan simple como una estantería con espacio tanto por encima como por debajo es imposible, aunque a veces se pueden sustituir por sprites o vóxeles. Los edificios con varios pisos son técnicamente posibles, pero no es posible que un edificio de este tipo contenga una ventana externa directamente encima o debajo de otra ventana. Además, será necesario tomarse algunas libertades con las escaleras, los ascensores y otros métodos de acceso para cada piso.
Varios juegos de Build Engine (a saber, Shadow Warrior , Blood y Redneck Rampage ) solucionaron este problema mostrando una "ventana gráfica" a otro sector a través de un paso de renderizado adicional. Esta técnica, llamada room-over-room (ROR), parece perfecta para el jugador. Además de una gama ampliada de construcción vertical, ROR se utilizó a menudo para dar a los cuerpos de agua superficies translúcidas . ROR nunca fue una característica del propio Build Engine, sino más bien un "truco" que fue creado por los desarrolladores de juegos. Un truco utilizado en Duke Nukem 3D para evitar esto, como en el caso de sus secciones submarinas opacas, fue simplemente transportar al jugador rápidamente a otra región del mapa hecha para imitarla, similar a los ascensores de Rise of the Triad .
En 2011, se agregó una característica a EDuke32 llamada true room over room (TROR), que permite apilar múltiples sectores verticalmente para que la pared de cada sector tenga su propia conexión, lo que permite estructuras sin restricciones verticales. La diferencia entre ROR y TROR es que los sectores de TROR se superponen físicamente en los datos del mapa y el editor (lo que permite una fácil creación y visualización), en lugar de dibujarse desde ubicaciones separadas mediante portales de visualización, de ahí que sea una verdadera habitación sobre habitación. TROR es una característica del puerto de origen de EDuke32, no una característica o truco del juego.
El motor Build fue esencialmente un proyecto de una sola persona para Ken Silverman, aunque consultó a John Carmack para obtener orientación al principio del proyecto. [3] Silverman fue contratado por 3D Realms sobre la base de su demo para Build. Aunque continuó refinando el motor después de ser empleado en 3D Realms, según Silverman nunca trabajó en equipo con ningún otro empleado de 3D Realms en el proyecto y nunca se le indicó que adaptara el motor a ningún juego en particular. [2]
El 20 de junio de 2000 (según su sitio web) Ken Silverman lanzó el código fuente de Build Engine bajo una licencia propietaria no comercial . [11] [1] Silverman explicó que después de que id Software sentó un precedente al publicar el código fuente del motor Doom , los fanáticos lo habían estado presionando para que publicara el código fuente de Build Engine. [2]
La versión 2.0 de EDuke de Matt Saettler , un proyecto para mejorar Duke Nukem 3D para modders , fue enviada 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 usado con el Duke original. (Tanto Duke Nukem 3D como EDuke todavía eran de código cerrado en ese momento).
Con las versiones beta privadas de la versión 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 algunas versiones beta privadas llenas de errores. Algunos equipos de conversión total para juegos de Build decidieron trabajar directamente con el código de Build de Silverman y también se desarrolló una versión mejorada del editor de Build conocida como Mapster.
En su momento, muchos en los foros de 3D Realms afirmaron que sería imposible portar Build a un sistema operativo multitarea, ya que necesitaba un gran bloque de memoria contiguo que no estaría disponible en un entorno multitarea. Esta afirmación no resistió el escrutinio, ya que todos los sistemas operativos modernos utilizan memoria virtual que permite a las aplicaciones obtener memoria lógica contigua sin usar memoria física contigua, pero la sabiduría convencional de la época era que portar Build a un sistema operativo de ese tipo era inviable.
El 1 de abril de 2003, tras varios años de afirmaciones en sentido contrario, 3D Realms publicó el código fuente de Duke Nukem 3D bajo la licencia GPL-2.0 o posterior . [12] Poco tiempo después, tanto Ryan C. Gordon como Jonathon Fowler crearon y publicaron versiones de código fuente del juego, incluido el motor de compilación. Duke Nukem 3D se podía jugar bien en la línea NT de Windows (incluido Windows 2000/XP) y en Linux y otros sistemas operativos Unix , y el interés por las versiones de código fuente se disparó.
Ryan C. Gordon (icculus), con la ayuda de otros, hizo el primer port del motor usando SDL . El port 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 DOS original (a pesar de estar compilado con Watcom C++, Build es C simple). [13] Se habló de que Matt Saettler usaría esto para portar EDuke a Windows, pero no se concretó. Más tarde se produjo un port de Duke Nukem 3D después de que se lanzó el código fuente. [14] David "Rancidmeat" Koenig también lo bifurcó como Duke3d_w32, que a su vez se bifurcó en xDuke, hDuke, nDuke y rDuke, enfocados en el modo multijugador.
Jonathon Fowler (JonoF) realizó un segundo port de código fuente para Windows y, más tarde, para Linux y Mac OS X. Este port, JFDuke3D, inicialmente no tenía soporte para juegos en red, aunque esto se agregó más adelante en el desarrollo. Después de un largo período de inactividad, se colocó en GitHub en 2020 y recibió actualizaciones en 2021 y 2024. [15] [16] [17] También portó el juego de prueba Ken-Build. [18]
La tarea de actualizar el motor Build para convertirlo en un verdadero renderizador 3D fue asumida por el propio Silverman. En las notas de lanzamiento de Polymost, escribió: "Cuando 3D Realms publicó el código fuente de Duke Nukem 3D, pensé que alguien haría un port OpenGL o Direct3D. Bueno, después de que pasaran unos meses, no vi señales de que alguien estuviera trabajando en un verdadero port acelerado por hardware de Build, solo gente que decía que no era posible. Finalmente, me di cuenta de que la única forma de que esto sucediera era que lo hiciera yo mismo". [19]
El renderizador Polymost permitió gráficos 3D acelerados por hardware utilizando OpenGL . También introdujo "hightile", una característica que hizo posible reemplazar las texturas originales del juego con reemplazos de alta resolución en una variedad de formatos. Polymost se ha utilizado en JFBuild, JFDuke3D, JFShadowWarrior de Jonathon Fowler y en los puertos fuente derivados de sus bases de código.
El código fuente de EDuke 2.0 se publicó más tarde [ ¿cuándo? ] , seguido por el código fuente de la última versión beta privada de EDuke 2.1 (que nunca llegó a ser una versión de lanzamiento). 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 desaparecido desde entonces, dejando a EDuke32 como el único port de EDuke que aún está en desarrollo. [20]
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 1 de abril de 2009, se reveló que se había desarrollado un renderizador de modelo de sombreado OpenGL 3.0 para EDuke32, llamado Polymer para distinguirlo del Polymost de Ken Silverman . Al principio se pensó que era una broma del Día de los Inocentes, pero el renderizador se hizo público más tarde. Permite efectos más modernos, como iluminación dinámica de colores en tiempo real y mapeo de sombras, mapeo especular y normal , y otras características basadas en sombreadores, además de la mayoría de las características agregadas a Polymost a lo largo de los años. Aunque Polymer es completamente utilizable, técnicamente está incompleto y no está optimizado, y aún está en desarrollo. Los desarrolladores de EDuke32 han declarado que una vez que Polymer haya sido reescrito para mayor velocidad, reemplazará a Polymost por completo, ya que es un renderizador superior y se puede hacer que se vea idéntico a Polymost.
El código fuente de Shadow Warrior fue publicado 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. [21] Sin embargo, admitió que tuvo acceso al código fuente de Shadow Warrior aproximadamente una semana antes de su lanzamiento. [22] El puerto quedó en un estado parcialmente incompleto, antes de ser puesto en GitHub en 2020 y recibir actualizaciones en 2021 y 2024. La versión anterior fue posteriormente bifurcada por Ben "ProASM" Smit para el puerto SWP. [23] Se inició un puerto icculus de Shadow Warrior , pero permaneció en versión alfa. [24] Un puerto VoidSW de los desarrolladores de Ion Fury y EDuke32 entró en beta pública el 21 de mayo de 2020. [25] También existe una bifurcación de una versión anterior, llamada IcedSW, de Justin "IceColdDuke" Marshall. [26]
El proyecto Transfusion tenía como objetivo recrear el motor Blood in the DarkPlaces , [27] pero en 2007, este proyecto estaba lejos de completarse, aunque tiene un modo multijugador de combate a muerte jugable; un proyecto similar es BloodCM que recrea todos los niveles de un jugador creados por Monolith para Blood sobre EDuke32, [28] así como ZBlood que traslada algunos recursos y niveles de Blood a ZDoom . [29] El proyecto eRampage intentó crear una conversión total de Redneck Rampage para EDuke32. [30] Mientras tanto , DN3DooM , [31] [32] [33] Shadow Warrior TC , [34] Doomed Redneck , [35] Re-Blood , [36] Re-PowerSlave , [37] VietDoom , [38] [39] [40] [41] y Fatedoom [42] adaptan esos juegos a GZDoom .
También han aparecido los códigos fuente de Witchaven , Witchaven II: Blood Vengeance , TekWar de William Shatner y Corridor 8: Galactic Wars . 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 . [43] JonoF lanzó ports para Witchaven y TekWar el 3 de marzo de 2024; [44] con ports derivados de ETekWar y EWitchaven también prototipados. [45] El código fuente completo de varias versiones alfa de Blood también se ha filtrado con el tiempo. [46]
Esto se usó luego como referencia para un puerto de ingeniería inversa a Java usando LibGDX llamado BloodGDX en mayo de 2017 por Alexander "M210" Makarov, el autor anterior de BloodCM . [47] Esto siguió al puerto anterior del autor de TekWar lanzado en enero de 2016, [48] y ha sido seguido por puertos para Witchaven , [49] Redneck Rampage , [50] Duke Nukem 3D , PowerSlave , Legends of the Seven Paladins y Shadow Warrior , ahora todos colectivamente llamados BuildGDX. [51] DukeGDX también admite los archivos de la edición 20th Anniversary World Tour de Duke Nukem 3D . [52]
Un port adicional de Blood , llamado NBlood, fue lanzado en enero de 2019 por Alexey "Nuke.YKT" Khokholov basado en EDuke32, [53] y el puerto Rednukem anterior del creador para Redneck Rampage (que también es compatible con Duke Nukem 3D y Duke Nukem 64 ). [54] [55] 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. [56] El puerto de origen Raze bifurca varios puertos de Build engine, incluidos JFDuke3D, SWP, NBlood, Rednukem y PCExhumed, y lo vincula a un nuevo backend subyacente basado en el propio GZDoom de los desarrolladores . [57] NBlood y PCExhumed también han sido retroportados a JFBuild con el propósito de adaptarlos a plataformas como Amiga , PlayStation Vita y Nintendo 3DS . [58]
Después de múltiples intentos de diseñar un sucesor de Build, Silverman comenzó a experimentar nuevamente con esa idea en 2006. Utilizó este trabajo, ahora llamado Build 2 , mientras enseñaba programación de juegos en 3D a niños en un campamento de verano desde 2007 hasta 2009, y el trabajo continuó hasta 2011, cuando perdió el interés en el proyecto. Cuenta con un sistema de iluminación más avanzado, renderizado de vóxeles para entidades y espacios 3D reales de habitación sobre habitación, y al menos en parte mantuvo la compatibilidad con versiones anteriores del Build original. Silverman lanzó sus borradores al público el 7 de marzo de 2018. [59] [60] El código fuente se publicó bajo una licencia propietaria no comercial el 8 de junio de 2019. [61]
El 1 de abril de 2005, 3D Realms publicó el código fuente del motor de SW bajo licencia GPL. El momento de la publicación del código fuente hizo pensar que se trataba de una broma del Día de los Inocentes, ya que generó su primer puerto fuente un día después, titulado JFShadowWarrior, y tenía las mejoras de JFDuke3D y compatibilidad con Linux.
…Yo [JonoF] tenía una semana de ventaja…
única parte restante del juego es una demostración de 4 niveles con 7 armas y 10 enemigos, lanzada justo antes del cierre de IntraCorp... También hay un mod llamado Fatedoom que transporta el contenido de la demostración a Doom.
Obtendrás dos versiones: parcheada (Mejorada) y minorista (Original) para aquellos de ustedes que prefieren una experiencia sin modificaciones como beneficio adicional. Ambas versiones se ejecutan en DOSBox con una herramienta de configuración personalizada. La versión mejorada presenta correcciones introducidas en EGwhaven, un proyecto comunitario imprescindible, que aborda una variedad de errores y problemas con el juego (nos gustaría agradecer a ETTiNGRiNDER por la contribución a esta versión). Además, los controles se reasignaron a lo que esperaría ver como predeterminado en un juego en primera persona hoy en día.
Uno de los miembros del equipo dijo que se lo considere un poco como BuildGDX, ya que Raze "comparte el renderizador, el sistema de sonido y el código de la interfaz de entrada/sistema en todos los juegos".