Using ZIPs as WAD replacement

PK3 redireciona para cá. O formato de arquivo PK3 é o mesmo que o formato de arquivo ZIP e é tratado exatamente da mesma forma pelo ZDoom.

O ZDoom permite usar vários formatos de arquivo compactado em vez dos WADs tradicionais. Mais notavelmente:

ZIP

Um arquivo .zip usado como “contêiner” para um mod do ZDoom geralmente recebe a extensão .pk3 (originalmente usada pelo Quake 3), .pkz (para ZDoom), .pke (para o Eternity Engine) ou .ipk3 (para ZIPs de jogos completos) em vez de .zip. Não há diferença técnica, mas isso ajuda a evitar confusão (usuários achando que precisam extrair o conteúdo) e também impede que o Windows apresente o arquivo como um diretório. O ZDoom suporta vários métodos de compactação ZIP: stored (sem compactação), shrunk, imploded, deflated (o mais comum), bzip2 e LZMA. Note que muitos utilitários ZIP implementam apenas parcialmente o padrão ZIP e, por isso, ficam limitados a arquivos “store” e “DEFLATE”. Essa implementação parcial também afeta algumas ferramentas de edição que normalmente suportam PK3, como (GZ) Doom Builder e SLADE.

7z — use com cautela

Um arquivo .7z usado como contêiner para um mod do ZDoom geralmente recebe a extensão .pk7, .pkz ou .ipk7, por motivos semelhantes. Esse formato oferece uma taxa de compressão bem melhor, mas também aumenta o uso de memória no engine, então é preciso cuidado ao escolher entre 7z e ZIP. Uma possibilidade é desenvolver o mod como ZIP e, ao finalizar, converter para 7z para reduzir o tamanho do arquivo distribuído. Porém, tenha em mente que a descompressão é bem mais lenta do que em ZIP, então os tempos de carregamento aumentam, inclusive durante a execução quando, por exemplo, novos sons são carregados. Hoje em dia, aumentar load times em troca de reduzir tamanho de arquivo provavelmente não vale tanto a pena.

Pastas

Pastas podem ser carregadas diretamente pelo ZDoom, como se fossem um ZIP ou 7z. Isso é mais útil ao criar um mod sem usar um editor como o SLADE, pois permite alterar os arquivos com seu próprio conjunto de ferramentas e carregar rapidamente no ZDoom.

Arquivos compactados têm várias vantagens sobre (P)WADs, mesmo para armazenar conteúdo de Doom:

• Tamanho menor devido à compressão.
• Uso de memória muito reduzido durante o jogo.
• Uso adequado de diretórios em vez de namespaces de WAD.
• Você não precisa mais de ferramentas dedicadas de gerenciamento de WAD como XWE para manipular seus dados.
• Mais flexibilidade por permitir nomes completos (paths) em vez de apenas 8 caracteres em muitos sistemas.

Como fazer

Você pode embutir WADs dentro de arquivos. Qualquer WAD encontrado no diretório raiz será adicionado também ao diretório de lumps. Isso permite carregar muitos ZIPs distribuídos em /idgames sem precisar extraí-los. Se vários WADs estiverem incluídos em um arquivo, eles serão carregados em ordem alfabética.

Warning: Com exceção de WADs contendo mapas colocados sob a subpasta /maps/ de um PK3, carregar WADs dentro de um arquivo causará problemas de memória. O ZDoom vai desempacotar cada WAD e usar mais memória para acessar o conteúdo. Esse efeito se acumula rapidamente quanto mais WADs existirem, podendo levar o PC do usuário a ficar sem memória. Por isso, é altamente recomendado desempacotar completamente todo o conteúdo de quaisquer WADs embutidos (totalmente ou como parte do mod) para os diretórios organizados. Além disso, o ZDoom suporta e incentiva subdiretórios sob os diretórios principais para fins de organização (ex.: sprites/Weapons/Cannon, sprites/Monsters/Technodemon, etc.). Nenhum esforço extra é necessário para indicar que os sprites estão presentes, pois o ZDoom faz varredura automática em todos os subdiretórios.

Diferente dos WADs (que não possuem estrutura real de diretórios), a colocação dos dados dentro de arquivos compactados é bem mais estritamente aplicada para o engine reconhecer como um lump “padrão”. Qualquer dado especial precisa estar no diretório correspondente dentro do arquivo, senão não será encontrado. Para o nome do lump, os primeiros 8 caracteres do nome do arquivo são usados e a extensão é removida. Por exemplo, para colocar um MAPINFO dentro de um arquivo, você pode nomear o arquivo como MAPINFO.txt, MAPINFO.lmp, ou qualquer extensão (ou nenhuma) e colocar na raiz do arquivo. Os seguintes subdiretórios são usados para atribuir dados aos namespaces existentes de WAD no ZDoom:

Diretório	Descrição
acs/	contém bibliotecas ACS normalmente encontradas entre A_START e A_END
colormaps/	contém colormaps Boom normalmente encontrados entre C_START e C_END. WADs novos para ZDoom não devem precisar disso.
filter/	contém lumps e diretórios que só serão carregados com jogos específicos. Veja filtragem de lumps.
flats/	contém flats normalmente encontradas entre FF_START e FF_END
graphics/	todos os gráficos especiais como title pictures ou caracteres de fonte devem ir aqui. Esse namespace não existe em WADs.
hires/	contém texturas de alta resolução normalmente encontradas entre HI_START e HI_END
maps/	contém níveis na forma de WADs. Esses WADs devem conter apenas os dados de um único nível (incluindo lumps de GL nodes, se necessário). Qualquer outro dado em tal WAD será ignorado. Note que o nome do arquivo (e não o map label dentro do WAD) determina como o mapa é nomeado no jogo.
music/	contém todos os dados usados como música. Esse namespace não existe em WADs.
patches/	contém patches normalmente encontrados entre PP_START e PP_END
sounds/	contém todos os arquivos de som referenciados por SNDINFO. Esse namespace não existe em WADs.
sprites/	contém sprites normalmente encontrados entre S_START e S_END (também conhecidos como SS_START, SS_END)
textures/	contém textures normalmente encontradas entre TX_START e TX_END (namespace de override de texturas)
voices/	contém sons de diálogo de Strife normalmente encontrados entre V_START e V_END
voxels/	contém objetos voxel normalmente encontrados entre VX_START e VX_END
/	contém objetos no namespace global, como arquivos MAPINFO e ZScript

Dicas

• SLADE ou programas similares são recomendados para criar o arquivo compactado em si, para garantir que programas como WinZIP ou WinRAR não o criem com compressão não suportada. Caso contrário, podem parecer “corrompidos”, o que pode atrapalhar modificações do arquivo com SLADE, Slumped, etc.

• O SLADE também é capaz de editar muitos tipos de arquivo com realce de sintaxe especial (syntax highlighting) semelhante a uma IDE, tornando-o muito útil para escrever DECORATE e similares.

• O diretório do arquivo é ordenado alfabeticamente antes de ser adicionado ao diretório de lumps; quaisquer WADs na raiz são carregados depois. Leve isso em conta ao criar dados que dependem de ordem por nome de arquivo. Para a maioria das coisas, não há necessidade de depender de ordenação, com exceção de animações de textura do tipo range que animam texturas dos subdiretórios flats/ ou textures/.

• Qualquer arquivo que não esteja em um dos diretórios reservados não é adicionado ao diretório WAD e só pode ser usado por código que procura por caminhos completos (full paths), o que inclui muitas coisas. A extensão disso não é listada aqui porque muda com frequência; você terá que descobrir por conta própria quais sistemas suportam isso.

• Lumps de sprite para o frame \ em um WAD (como VILE\* para um dos frames de cura do Arch-Vile) podem ser colocados em um arquivo: o caractere de barra invertida deve ser trocado por um circunflexo (^). Assim, VILE^1 a VILE^8 em um arquivo serão interpretados como os lumps VILE\1 a VILE\8. Essa substituição só funciona para sprites; qualquer outro nome de lump não deve conter barras invertidas em lugar nenhum. Como é possível usar múltiplos nomes de sprite para um ator via DECORATE, frames além de Z não precisam ser usados.

• É fortemente recomendado usar a extensão .pk3, .pk7 ou .pkz (e não .zip ou .7z) ao criar um arquivo destinado a ser carregado diretamente no ZDoom. O usuário médio está acostumado a abrir um .zip e extrair um .wad, então nomear o arquivo do jogo como .zip costuma causar confusão.

• O conteúdo dos arquivos dentro do arquivo compactado deve ser idêntico aos lumps em um WAD. Isso é especialmente importante para gráficos. O ZDoom não lê arquivos .BMP! Embora esse seja um formato comum de encontrar, importar com um gerenciador de WAD converte para o formato interno do Doom. O XWE exporta gráficos do formato interno do Doom para .BMP. O SLumpEd e o SLADE podem exportar esses gráficos como lumps crus (raw lumps) do Doom, e o SLADE também pode exportar como PNG. Para o ZDoom reconhecer gráficos como tais, eles precisam estar no formato interno do Doom ou em um formato de imagem suportado como PNG.

• Cuidado com arquivos ocultos! Se você adicionar um diretório inteiro (ou árvore de diretórios) a um arquivo compactado, é possível que arquivos do sistema indesejados (como o thumbs.db do Windows, que costuma ser criado em pastas com imagens) sejam incluídos também. Eles aumentam desnecessariamente o tamanho do arquivo e podem disparar warnings ao carregar o ZDoom. O Slumped frequentemente trava ao navegar recursos de um arquivo, pois espera que thumbs.db seja um gráfico e obtém valores incoerentes.

Usando pastas em vez de arquivos

Warning: Trabalhar a partir de pastas é geralmente bem conveniente durante o desenvolvimento do seu projeto (e você pode abrir essas pastas no SLADE também, se precisar), mas saiba que o SLADE não cria backups de pastas, ao contrário de WADs e PK3s. Você precisa cuidar dos backups por conta própria. O método mais conveniente é transformar a pasta do projeto em um repositório Git para ter controle de versão seguro e detalhado.

Um mod PK3/ZIP não precisa estar empacotado para ser utilizável. Se ele estiver “desempacotado” em uma pasta com a mesma estrutura interna que um PK3 teria, funcionará do mesmo jeito. O GZDoom pode rodar pastas como se fossem PK3, por exemplo:

gzdoom.exe -iwad doom2.wad -file mods\mymod

"mymod" neste exemplo é o nome de uma pasta que contém os mesmos lumps e subpastas, como Sprites, Textures, etc. Lumps podem ter qualquer extensão ou até nenhuma, então por exemplo MAPINFO.txt, MAPINFO.mod ou apenas MAPINFO funcionarão.

Caminhos longos (long paths) também são suportados:

gzdoom.exe -iwad tnt.wad -file "C:\Doom\My Projects\MyWipMod"

O SLADE também pode abrir pastas e analisá-las do mesmo modo que WAD ou PK3 via File > Open Directory.

Há várias vantagens significativas em usar pastas em vez de PK3, então costuma ser uma ótima ideia manter mods em desenvolvimento em uma pasta e só empacotar quando for “lançar” para outros jogadores. Algumas vantagens:

• Você não precisa usar o SLADE para editar tudo; pode usar seus programas favoritos para editar partes específicas do mod. Por exemplo, editar arquivos de ZScript/DECORATE no seu editor de código preferido. Notepad++ e TextPad podem usar realce de sintaxe de ZScript/DECORATE (veja este tópico no fórum).
• Você não precisa abrir o arquivo inteiro quando só quer editar uma parte específica. Acessar uma pasta via Windows Explorer ou outro gerenciador é bem mais rápido do que “abrir/descompactar” um PK3 no SLADE, e quando você altera um lump específico (como ZScript.txt), você só precisa salvar aquele arquivo em vez de salvar o archive inteiro e esperar a aplicação das mudanças.
• O SLADE pode ter crashes ocasionais e corrupção de dados. Usar o método de pasta diminui muito a chance disso acontecer.
• O SLADE ainda é necessário para coisas como ajustar offsets de sprites. Porém, usando File > Open Directory no SLADE você pode abrir um subdiretório específico (como "Mymod\sprites\weapons\shotgun\") em vez de abrir o archive inteiro. Isso é mais rápido e, em caso de crash ou falta de energia, qualquer corrupção tende a afetar só aquela pasta e não o projeto inteiro.
• Você pode transformar sua pasta em um repositório GitHub. Isso facilita controle de versão, releases, colaboração entre autores e ajuda a evitar perda do trabalho (backup em nuvem). Assim, seu repositório também pode ser baixado e executado em qualquer ponto.

Notas:

• Editores externos (como Notepad++) não têm tooltips/popups embutidos para funções de ZScript/DECORATE.
• O GZDoom pode demorar um pouco mais para carregar uma pasta na memória do que um PK3.
• A maioria dos softwares de edição visual remove metadados de offset ao editar imagens; então, se você editar um sprite, terá que usar o SLADE para definir os offsets de novo. (Isso vale para PK3 também, mas fica mais evidente no método de pasta.) Isso pode ser contornado definindo offsets no lump TEXTURES em vez de diretamente nos sprites (ainda assim você vai precisar do SLADE para o editor visual de TEXTURES).
• O SLADE não cria backups para pastas; se você estiver usando GitHub, isso deixa de ser um problema porque o Git rastreia mudanças e permite reverter.

Armazenando mapas em um PK3

Os mapas em si só podem existir dentro de arquivos WAD, enquanto todos os outros assets e código são melhor armazenados em um PK3. Se você está fazendo um projeto com assets e mapas customizados, é importante saber como combinar isso. É possível distribuir como 2 arquivos separados (um WAD com os mapas e um PK3 com assets) e pedir para os usuários rodarem juntos, mas geralmente é mais conveniente empacotar tudo em um único PK3. Para isso:

1. Cada mapa precisa ser salvo em um WAD separado, e o nome desse arquivo deve corresponder ao nome interno do mapa (definido no MAPINFO): por exemplo MAP01.wad, MAP02.wad, E1M1.wad, E1M2.wad, etc. (Nomes mais longos/customizados também são possíveis.)

2. Todos os WADs contendo mapas devem ficar dentro da subpasta maps/ no seu PK3.

3. Seu lump MAPINFO (com as definições dos mapas) deve ficar na raiz do PK3 (junto de outros text lumps, como ZScript, MODELDEF, ANIMDEFS, etc.).

Isso vale principalmente para empacotar a versão final; durante o desenvolvimento, você não é obrigado a usar essa forma de armazenamento. Você pode manter mapas e assets separados, e (como descrito acima) os assets podem ficar em uma pasta também.

Evite colocar os mapas na raiz do PK3: isso fará o GZDoom carregar todos os mapas na memória de uma vez, o que pode levar a performance ruim.

Compatibilidade

A maioria das ferramentas modernas de edição consegue lidar com pastas e arquivos ZIP, embora nenhuma suporte 7z até agora.

Vavoom e Doomsday também usam arquivos ZIP para recursos; porém, a organização de subdiretórios é diferente. Adaptar um mod de um desses ports para funcionar no ZDoom pode exigir reempacotamento, além de conversão de recursos “enhanced” para equivalentes do ZDoom. O Eternity Engine adotou um modelo parecido com o do ZDoom, mas diferente o suficiente para causar incompatibilidades em ambos os sentidos.

Veja também

• Dicas para usar ZIPs como substituto de WAD