| Construir motor | |
|---|---|
| Tipo de | Motor de juegos |
| Desarrollador | Ken Silverman |
| Escrito en | xi |
| Sistema operativo | DOS |
| plataforma de hardware | MS-DOS |
| Licencia | código del autor - bajo el propietario BUILDLIC.TXT [1] |
| Sitio web | advsys.net/ken/build.htm |
| Archivos multimedia en Wikimedia Commons | |
Build Engine es un motor de juego de disparos en primera persona creado por Ken Silverman para 3D Realms . Al igual que el juego Doom , Build Engine proyecta el mundo del juego en una cuadrícula 2D de formas planas cerradas llamadas sectores y utiliza los objetos planos más simples llamados sprites para poblar el mundo geométrico con objetos.
El motor de construcción pertenece a la clase de los llamados " motores de 2,5 dimensiones ", porque el mundo del juego se basa en un plano con un componente de altura añadido. Cada sector puede tener diferente altura de piso y techo, así como diferente pendiente de piso y techo. Como resultado de la representación , el mundo parece tridimensional. El cálculo de la perspectiva se basa únicamente en la distancia horizontal; por lo tanto, las líneas verticales correspondientes a los vértices son estrictamente verticales, independientemente del ángulo de visión. Esto provoca una distorsión significativa de la perspectiva cuando se mira hacia arriba o hacia abajo en ángulos altos en la mayoría de los juegos de Build Engine .
Los sectores son el componente principal de la geometría del nivel. Puedes trabajar con sectores en tiempo real. Sus parámetros (alturas, forma, ángulos de inclinación) no requieren un nuevo cálculo al cambiar. Esto te permite hacer que el entorno del juego sea más interactivo, como destructible (como en Blood ).
Los desarrolladores utilizaron sprites reservados ( efectores de sector ), a los que se les asignaron etiquetas (números con un significado determinado) superiores ( hi-tags ) e inferiores ( lo-tags ) especiales, lo que hizo posible que el mundo fuera más dinámico (por ejemplo, puertas, barriles explosivos, etc.). Se pueden dar las mismas etiquetas al suelo y al techo del sector para darle propiedades especiales. Por ejemplo, un jugador que camina en un piso con etiquetas especiales se caería y caería de otro techo con etiquetas especiales. En la práctica, esto se utilizó para crear embalses. A un sector se le pueden dar etiquetas que lo conviertan en una puerta o un ascensor. Los sectores pueden superponerse entre sí para que uno no sea visible debido al otro (si en tal situación dos sectores son visibles a la vez, entonces con una distorsión severa). Esto hizo posible crear, por ejemplo, conductos de ventilación ubicados sobre las instalaciones (aunque esto dificultó mucho más el trabajo con esta parte del nivel, ya que el desarrollador pasa casi todo el tiempo en modo bidimensional). También te permite crear mundos que son imposibles desde el punto de vista de la física (por ejemplo, un sistema de habitaciones en un edificio que es más grande que el propio edificio). Todos estos efectos hacían que el mundo pareciera tridimensional, hasta que apareció el motor Quake .
Para ordenar los aviones en orden Z, Doom usó un árbol BSP que se construía cada vez que se guardaba el WAD. A diferencia de Doom, Build usó el mecanismo del portal .
Los segmentos que separan los dos sectores se declaran "portales". El motor primero dibuja el sector en el que se encuentra el espectador, recordando todos los portales. Después de eso, recursivamente comienza a renderizar los sectores que son visibles a través de los portales (sin tocar lo que ya está dibujado).
En el motor de 2,5 dimensiones, este método fue mejor que el árbol BSP por las siguientes razones:
Versiones posteriores del motor hicieron posible reemplazar imágenes en el juego con objetos 3D hechos de vóxeles . Esta característica apareció demasiado tarde para usarse en Duke Nukem 3D , pero se usó en otros juegos. Blood usa vóxeles para armas, municiones, mejoras y varias decoraciones (como lápidas en Cradle to Grave).
Durante varios años, Ken ha estado trabajando en el motor Voxlap basado en tecnología voxel.
Algunos juegos en el motor Build usaban el truco de combinar el suelo y el techo de dos sectores. Crear tales estructuras durante la edición de niveles fue difícil, por lo que a menudo los sectores se movían durante la carga del nivel (lo que simplificaba los cálculos realizados por el motor de renderizado). La tecnología de habitación sobre habitación se usó en Shadow Warrior (sectores cambiantes durante la carga del mapa) y Blood (sin compensación). La tecnología en sí no estaba integrada en el motor, los creadores de niveles pensaron en ella.
El 20 de junio de 2000, Ken Silverman abrió el motor de compilación.
La versión 2.0 (el primer y único lanzamiento oficial) de EDuke de Matt Setler (un puerto para ejecutar Duke Nukem 3D en sistemas operativos modernos ) se envió a 3D Realms ( las fuentes de Duke Nukem 3D y EDuke todavía eran de dominio público). Trabajando con la versión beta 2.1 , Matt intentó incrustar las fuentes de Build en las fuentes de Duke, pero el proyecto se cerró antes de que estuvieran disponibles los lanzamientos públicos depurados. Varios equipos de conversión de compilación decidieron trabajar directamente con las fuentes del motor de compilación de Ken en lugar de las fuentes de Duke. Más tarde, como resultado del trabajo, apareció el editor mapster. Durante mucho tiempo, fue difícil trasladar el motor Build a sistemas operativos multitarea debido a la necesidad de áreas muy grandes de memoria de la computadora, que no estaban disponibles en los sistemas operativos multitarea. El problema se resolvió conectando memoria virtual .
El 1 de abril de 2003, 3D Realms lanzó el código fuente del motor 3D de Duke Nukem , a pesar de las largas afirmaciones de que esto nunca sucedería. Después de eso, muy pronto aparecieron puertos de Icculus y JonoF . Se hizo posible jugar a Duke Nukem 3D sin problemas en GNU / Linux , Windows NT y otras plataformas, y aumentó el interés en los puertos.
Ryan Gorden (icculus) creó el primer puerto del motor usando SDL con ayuda externa . Inicialmente fue un port para Linux , luego para Cygwin y aún más tarde para Win32 puro (al construir se usó el compilador Watcom C++ , que también se usó para la compilación original de DOS (con la precisión que se usó Watcom C++ ) para Windows , y Build estaba escrito en C simple ) Hubo rumores sobre la migración de EDuke a Windows, pero no sucedió nada.
Segundo puerto en Windows y luego en Linux por Jonathan Fowler (JonoF). A diferencia del puerto icculus, este puerto usa DirectDraw en lugar de SDL en Windows y es significativamente más rápido. Durante mucho tiempo, el motor no admitía el modo multijugador , luego hubo soporte para el modo multijugador solo para dos jugadores.
El autor del motor asumió la tarea de actualizar Build Engine a un motor 3D completo. En las notas de la versión de JFDuke3D, Silverman escribe:
Cuando 3D Realms lanzó los códigos fuente de Duke Nukem 3D, pensé que alguien haría un puerto OpenGL o Direct3D . Después de unos meses me di cuenta de que nadie está trabajando en el uso de aceleración de hardware real en Build, la gente simplemente dice que no es posible. Más tarde me di cuenta de que la única forma de lograr cualquier cosa es hacerlo todo uno mismo.
El sistema de renderizado polybridge utiliza OpenGL para la aceleración 3D por hardware. También se ha introducido la tecnología Hightile , que permite sustituir los recursos estándar del juego por otros mejores en varios formatos.
Polybridge ha sido utilizado en JFBuild por Jonathan Flower, JFDuke3D, JFSW y otros puertos basados en este código base.
La publicación del código fuente de EDuke 2.0 agregó las capacidades del puerto JonoF y el motor Build Engine 2.1 a EDuke, pronto apareció EDuke32, pero hasta la fecha solo EDuke está en desarrollo.
El código fuente de la última versión beta personal de EDuke 2.1 (que nunca se lanzó) también se publicó después de los códigos fuente de EDuke 2.0. También hay un puerto basado en Icculus, cuyo nombre en código es windeduke, que actualmente no está en desarrollo.
EDuke contenía elementos de los códigos fuente Nam y WW2 GI , lo que puede haber facilitado el desarrollo. También hubo un intento de recrear el motor Blood on the DarkPlaces y llamarlo Transfusion , pero a partir de 2006 este puerto aún se encuentra en desarrollo temprano.
Los códigos fuente de Shadow Warrior se publicaron el 1 de abril de 2005 y JonoF publicó una versión del juego el 2 de abril de 2005. Es cierto que afirma que tuvo acceso a los códigos fuente de Shadow Warrior una semana antes de que se publicaran.
También se han publicado los códigos fuente de Witchaven , Witchaven II , Tekwar y Corridor 8 . La verdad es cuestionable es la legalidad de su publicación.
| Juegos de construir motores | |
|---|---|
| |