FANDOM


Un WAD (que, según la Biblia de Doom es un acróstico de "Where's All the Data?") es el formato de archivo utilizado por Doom y todos los juegos basados ​​en el motor de Doom para el almacenamiento de datos; contiene los sprites, niveles, música y los demás datos necesarios para la ejecución del juego. Un archivo WAD consta de una cabecera, un directorio, y los datos de lumps que componen los recursos almacenados en el archivo.

Los archivos WAD pueden ser de dos tipos:

  • IWAD: Un "WAD Interno" (o "WAD Inicial"), o un WAD esencial que es cargado automáticamente (o desde un menú de selección de juego en los source port) por el motor y por lo general proporciona todos los datos necesarios para ejecutar el juego.
  • PWAD: un "Parche WAD", o un archivo opcional que reemplaza los datos del IWAD cargado o proporciona datos adicionales para el motor. Es un progenitor de los mods actualmente tan populares.


Un archivo WAD se puede leer y / o editar por muchas herramientas, tales como los editores WAD.

Antecedentes históricos

Durante el desarrollo de Doom, Id Software era consciente de que muchos jugadores habían tratado de crear niveles personalizados y otras modificaciones para su juego anterior, Wolfenstein 3D. Sin embargo, los procedimientos involucrados en la creación y carga de modificaciones para ese juego eran muy engorrosos.

John Carmack, programador jefe en id Software, diseñó las partes internas de Doom desde cero para permitir a los jugadores extender el juego. Por esa razón, los datos del juego, tales como niveles, gráficos, efectos de sonido y la música se almacenan por separado del motor de juego, en los "archivos WAD". Esto permitió a los jugadores hacer sus propios datos sin realizar ninguna modificación al motor.

La idea de hacer que Doom fuese fácilmente modificable fue respaldada principalmente por Carmack, un partidario bien conocido del copyleft y el ideal Hacker de personas que comparten y se basan en el trabajo de otros, y por John Romero, que había hackeado juegos en su juventud y quería permitir otros jugadores hagan lo mismo. No todo el mundo en el equipo de id Software estaba contento con este desarrollo; algunos, entre ellos Jay Wilbur y Kevin Nube, lo objetaron debido a preocupaciones legales y en la creencia de que no sería de ningún beneficio para los negocios de la compañía.

Cabecera (header)

Un archivo WAD siempre comienza con una cabecera de 12 bytes, que contiene tres valores:

wadinfo_t
Posición Largo Nombre Descripción
0x00 4 identification Los caracteres ASCII "IWAD" o "PWAD". Define si el WAD es un IWAD o un PWAD.
0x04 4 numlumps Un número entero que especifica el número de lumps en el WAD.
0x08 4 infotableofs Un número entero que posee un puntero a la ubicación del directorio.

Todos los enteros son de 4 bytes de longitud en estilo x86 little-endian orden. Sus valores no pueden exceder el valor de 2 31 -1, donde Doom los lee como enteros con signo. Para algunas portaciones basadas en el código de Atari Jaguar (los derivados de Playstation son la excepción notable), en su lugar se utiliza el orden big-endian.

La firma IWAD o PWAD tiene la intención de definir si el archivo es un IWAD o un PWAD, sin embargo, esto no está realmente comprobado por el motor. Es posible cargar un IWAD como PWAD, y también es posible cargar inversamente un PWAD como un IWAD. Por ejemplo, CHEX.WAD y TNT.WAD tienen una firma PWAD a pesar de actuar como IWAD.

Directorio

El directorio asocia nombres de lumps con los datos que les pertenecen. Se compone de un número de entrada, cada uno con una longitud de 16 bytes. La longitud del directorio se determina por el número dado en la cabecera del WAD. La estructura de cada entrada es como sigue:

filelump_t
Offset Largo Nombre Contenido
0x00 4 filepos Un número entero que contiene un puntero al comienzo de los datos del lump en el archivo.
0x04 4 size Un entero que representa el tamaño del lump en bytes.
0x08 8 name Una cadena ASCII que define el nombre del lump. Sólo los caracteres AZ (mayúsculas), 0-9 y [] - _ se pueden utilizar en los nombres de lump (una excepción son algunos de los sprites del Archi-vil, que utilizan "\"). Cuando una cadena tiene menos de 8 bytes de longitud, debe ser rellenada con null hasta el octavo byte. Los valores superiores a 8 bytes están prohibidos.
  • Las herramientas no asumen el orden del lump en el WAD, y son ordenados por el byte de desplazamiento.
  • Lumps "virtuales" (como F_START) sólo existen en el directorio, teniendo un tamaño de 0. Su valor de desplazamiento, por lo tanto, es absurdo (a menudo 0). Es posible que más de un lump tenga el mismo valor de desplazamiento, es como tener compensaciones que se superponen a otros datos del lump.
  • El tipo de archivo no se indica en los datos del lump.

Un típico archivo WAD:

wadfile_t
Cabecera
Datos del Lump
Nombres y punteros de Lumps

Orden de los Lump

La mayoría de los lumps no tienen restricciones sobre dónde deben ser ubicados en los archivos WAD, aunque normalmente hay algunas pautas para que el archivo sea de fácil lectura para otras personas. Para ciertos lumps, sin embargo, la ubicación es crucial.

Lumps de datos de mapa

Un mapa en Doom se compone de varios lumps, cada uno conteniendo datos específicos necesarios para construir y ejecutar el mapa. El primer lump da el nombre interno del mapa. En Doom, tenía que estar en el formato ExMy o MAPxx, donde x e y no podían exceder de 4 y 9, respectivamente (Ultimate Doom), y xx no puede ser superior a 32 (Doom II/Final Doom).

Aparte de definir el nombre del mapa, el lump está generalmente vacío, pero puede contener datos. El archivo DOOM64.WAD para Doom64 EX, convertido desde el contenido de una ROM Nintendo 64, contiene IWADs incrustados en lumps MAPxx . En Hexen, contienen información de control de versión; esto no es usado por el juego pero presumiblemente fue usado por las herramientas de edición de Raven Software.

El nombre del nivel marca el inicio de ese mapa. Para funcionar correctamente, los siguientes lumps deben seguir inmediatamente después del nombre del nivel:

  • THINGS: Un lump con la lista de todas las cosas presentes en este mapa con sus coordenadas X e Y, ángulos de origen, tipo y banderas. Al igual que con todos estos lumps, la lista será generada por el editor de niveles y por lo general se debe dejar sola.
  • LINEDEFS: Una lista de linedefs, definidos por su vértices de inicio y finalización, banderas, tipo, etiqueta, argumentos, y sidedefs frontales y dorsales (si los hay). Nota: El formato estándar de Doom no contiene argumentos.
  • SIDEDEFS: Una lista de los sidedefs que están vinculados a los linedefs. Estos contienen los datos para las texturas que aparecen en cada lado de la línea, sus desplazamientos X e Y, y qué sector del lado de la linedef pertenece.
  • VERTEXES: Una lista de cada vértice en el mapa, utilizando coordenadas X e Y.
  • SEGS: Una lista de los segmentos de línea que se conectan para formar subsectores, creado por un node builder.
  • SECTORS: Define las alturas del piso y del techo y texturas, así como el valor de luz, etiquetas, y el tipo de cada sector en su mapa.
  • SSECTORS: Una lista de subsectores, creado por un node builder.
  • NODES: El árbol de nodos que Doom utiliza para acelerar el proceso de renderizado. Similar a un VISMAP en juegos 3D modernos (como Quake 3). Creado por un node builder.
  • REJECT: Opcionalmente compilado por el node builder, este lump contiene datos sobre qué sectores son visibles desde otros sectores. Originalmente, Doom usó esto para optimizar la velocidad de juego al saltarse las rutinas de IA (Inteligencia_artificial) de los enemigos cuyo objetivo era no entrar en un sector. Algunas portaciones modernas no requieren más este lump; ZDoom por ejemplo, ha sido diseñado para funcionar incluso sin este lump presente. Para fines de compatibilidad, un lump REJECT vacío (completado con 0) debe ser incluido. El lump REJECT también se puede utilizar para crear ciertos efectos especiales (sectores en los que los enemigos no pueden ver, por ejemplo) si se modifica con cuidado.
  • BLOCKMAP: información de detección de colisiones que determina si los objetos en un mapa se tocan.
  • BEHAVIOR: No era originalmente una parte de Doom, el lump BEHAVIOR fue utilizado por primera vez en Hexen y contiene los scripts compilados que este mapa va a utilizar. Vanilla Doom y otros puertos diseñados solamente para Doom, se estrellan cuando este nudo está presente porque los niveles de formato Hexen no son compatibles con los niveles de formato de Doom. Este nudo debe estar presente para  los niveles de formato Hexen, ya que es la única manera de saber si un mapa está en formato Hexen o Doom.

Planos, Sprites y Parche

Estos tres recursos deben estar situados entre marcadores especiales de lump para que Doom sepa lo que se está mirando. Aparte de definir el principio y el final de una sección de gráficos, estos lumps no contienen datos y son de 0 bytes de longitud.

Los marcadores consisten en nombres X_START y X_END, donde X es la primera de una o dos letras que identifican el recurso correspondiente. Por ejemplo, los sprites deben estar situados entre los marcadores S_START y S_END. SS_START y SS_END se utilizan por lo general para los archivos WAD de usuario.

Estos marcadores son requeridos por DOOM:

Marcador inicial Marcador final Qué es Usado por
F_START F_END Delimitadores de planos Todas las versiones
S_START S_END Delimitadores de sprites Todas las versiones

Estos marcadores se encuentran en los archivos WAD oficiales, pero no son utilizados por los motores DOOM conocidos:

Marcador inicial Marcador final Encontrado en Qué es Usado por
P_START P_END Delimitadores de parches Todas las versiones
P1_START P1_END inside P_ range Parches Shareware, Heretic o Hexen Doom shareware y posteriores (pero no Final Doom), Heretic, Hexen
P2_START P2_END inside P_ range Parches de la versión registrada, Heretic o Hexen Doom registrado y posteriores (pero no Final Doom), Heretic, Hexen
P3_START P3_END inside P_ range Parches Doom II Doom II, pero no Final Doom
F1_START F1_END inside F_ range Pisos Shareware, Heretic o Hexen Doom shareware y posteriores (pero no Final Doom), Heretic, Hexen
F2_START F2_END inside F_ range Pisos de la versión registrada, Heretic o Hexen. Doom registrado y posteriores (pero no Final Doom), Heretic, Hexen

Los parches no están obligados a tener ningún marcador. Algunas utilidades de gestión de lumps requieren P_START y P_END.

Misceláneas

Algunos lumps son conocidos por sus nombres y se aplican al juego en su conjunto. Algunos de estos son:

Véase también

El contenido de la comunidad está disponible bajo CC-BY-SA a menos que se indique lo contrario.