El truco visual que hizo sentir tridimensional a DOOM
DOOM construía su sensación de profundidad a partir de mapas 2D, sectores con distintas alturas, sprites y un árbol BSP que decidía qué debía dibujarse en cada cuadro.
El truco visual que hizo sentir tridimensional a DOOM
El mundo de DOOM nacía de mapas dibujados en dos dimensiones. Sectores con alturas, sprites, paredes proyectadas y un árbol BSP hacían el resto: la pantalla terminaba mostrando un espacio que el jugador podía leer como profundo.
En 1993, DOOM daba la impresión de que uno podía atravesar pasillos, subir escalones, mirar salas a distintas alturas y correr alrededor de enemigos dentro de un espacio tridimensional. Debajo de esa sensación había una estructura más limitada y, precisamente por eso, muy ingeniosa. Los niveles se describían principalmente como geometría 2D y el motor convertía esa información en la vista en primera persona que llegaba al monitor.
El nivel empezaba como un dibujo visto desde arriba
Los mapas de DOOM se construían mediante líneas que delimitaban sectores. Cada sector podía tener su propia altura de piso y techo, además de texturas e iluminación. Esa información vertical era suficiente para producir habitaciones elevadas, escaleras, fosos y cambios de nivel sin almacenar cada espacio como un conjunto libre de polígonos tridimensionales.
La consecuencia era importante: la planta del escenario seguía siendo esencialmente bidimensional. El motor sabía qué tan alto estaba el piso o el techo de una zona, pero no podía resolver cualquier geometría 3D imaginable.
La planta del nivel se describía mediante vértices, líneas y sectores.
Cada sector añadía piso y techo a distinta elevación.
Enemigos, objetos y muchos elementos móviles seguían siendo imágenes planas.
La altura estaba en los sectores, no en una malla 3D completa
En pantalla, una pared podía verse más alta o más baja según el sector al que pertenecía y la distancia respecto al jugador. El motor proyectaba los segmentos visibles y dibujaba las paredes como columnas de píxeles. Después calculaba las superficies de piso y techo que quedaban entre ellas.
Ese diseño explicaba tanto sus virtudes como sus límites. Era posible crear desniveles convincentes, pero no colocar dos habitaciones independientes exactamente una encima de otra dentro de la misma posición del mapa. El espacio tenía profundidad visual, aunque su representación interna no fuera equivalente a la de motores 3D posteriores.
Llamarlo “falso 3D” explica poco
El motor sí calculaba perspectiva, distancia, altura, oclusión y posición relativa dentro del escenario. Lo que estaba limitado era la forma en que describía la geometría. “2.5D” suele ser una etiqueta útil para distinguirlo de un entorno 3D arbitrario, pero el resultado visual seguía dependiendo de matemáticas de proyección y visibilidad muy reales.
El BSP evitaba que el motor tratara todo el nivel como si estuviera frente al jugador
Antes de ejecutar el juego, el mapa se dividía mediante Binary Space Partitioning, o BSP. El proceso elegía líneas de división y partía el escenario de manera recursiva hasta obtener subsecciones convexas. Esa estructura quedaba almacenada como un árbol.
Durante el render, el motor recorría ese árbol desde la posición del jugador. Así podía ordenar segmentos y descartar grupos completos mediante pruebas de visibilidad y cajas delimitadoras. El truco no consistía en inventar profundidad, sino en evitar trabajo que la máquina no necesitaba hacer.
El render ocurría en varias capas
La revisión del código original permite ver una secuencia muy concreta. Primero se recorría el BSP para localizar y proyectar las paredes visibles. Esas paredes ayudaban a definir las zonas de piso y techo. Finalmente se dibujaban elementos enmascarados como enemigos, objetos y superficies transparentes.
Recorre el árbol, ordena subsectores y proyecta los segmentos visibles.
Convierte las zonas de piso y techo en superficies visibles en pantalla.
Añade sprites, objetos y otros elementos transparentes o enmascarados.
La ilusión nacía de esa combinación. Una pared tenía perspectiva. El piso cambiaba con la distancia. Un enemigo podía quedar parcialmente oculto detrás de una esquina. El jugador no veía el formato del mapa ni el árbol BSP; veía una base marciana con volumen suficiente para orientarse, pelear y perderse.
DOOM tenía reglas espaciales muy concretas
- No manejaba geometría tridimensional arbitraria como un motor moderno.
- Los sectores no permitían habitaciones independientes apiladas libremente en la misma coordenada 2D.
- Enemigos y muchos objetos se representaban con sprites orientados hacia el jugador.
- Pisos y techos dependían de estructuras específicas del renderer, incluidos los conocidos visplanes.
Esas restricciones no eran un defecto accidental. Permitían que una PC de principios de los noventa dedicara sus recursos a lo que realmente se veía. El diseño de niveles aprendió a trabajar con las reglas del motor y terminó haciendo que sus límites fueran difíciles de notar mientras uno corría a toda velocidad con una escopeta.
El jugador rellenaba el resto del espacio
La sensación tridimensional de DOOM dependía tanto de la tecnología como del diseño. Cambios de altura, pasillos que se abrían a salas grandes, ascensores, ventanas, puertas y enemigos moviéndose entre planos daban suficientes pistas de profundidad para que el cerebro aceptara el escenario como un lugar continuo.
Unos años después, Quake llevaría a id Software hacia geometría y modelos plenamente tridimensionales. Visto desde ahí, DOOM ocupa una etapa fascinante: un motor diseñado alrededor de restricciones muy específicas que conseguía que casi nadie estuviera pensando en ellas mientras jugaba.
Fuentes
Código liberado del motor, incluidos los módulos de renderizado y manejo de sprites.
Material oficial de DOOM y DOOM II.
Diagrama del formato de mapas de DOOM, dominio público.
Sobre el autor
