Open Asset Package

Jogos usam uma quantidade impressionante de arquivos (assets). Texturas, malhas, áudio, shaders, cenas, scripts — um título moderno pode facilmente conter dezenas de milhares de assets individuais. Gerenciar esse “custo por assets” é um dos desafios silenciosos do desenvolvimento de jogos.

Formatos de arquivo tradicionais como Tar e ZIP continuam sendo alternativas comuns, mas foram projetados para ambientes muito diferentes. O Tar surgiu no final da década de 1970 para sistemas de fita magnética, enquanto o ZIP foi introduzido no final dos anos 1980 para melhorar a eficiência de armazenamento em disquetes. Ambos continuam sendo formatos de uso geral úteis, mas nenhum foi projetado para a forma como motores de jogo modernos carregam e fazem streaming de assets.

À medida que os projetos crescem, os motores frequentemente adotam sistemas de empacotamento especializados. A Unreal Engine utiliza arquivos .pak, a Unity depende de Asset Bundles, a Godot distribui projetos exportados em arquivos .pck, e o raylib oferece o formato aberto rres. Cada um resolve uma parte dos mesmos problemas, mas geralmente está atrelado a ecossistemas, ferramentas ou suposições específicas sobre como os assets devem ser organizados.

O Open Asset Package (OAP) é uma tentativa de resolver esses desafios com um formato aberto e independente de motor, projetado especificamente para fluxos de trabalho modernos de assets em jogos.

O problema central

Motores de jogo geralmente precisam de três capacidades de um contêiner de assets:

1. Acesso aleatório, permitindo que um único asset seja localizado rapidamente sem percorrer todo o arquivo.
2. Suporte a streaming, permitindo que assets sejam obtidos incrementalmente via requisições de intervalo HTTP em vez de baixar arquivos monolíticos inteiros.
3. Identidade estável, garantindo que as referências a assets permaneçam válidas mesmo quando nomes de arquivo, estruturas de diretório ou estratégias de empacotamento evoluem.

Os formatos de arquivo tradicionais atendem apenas parcialmente a esses requisitos.

O Tar foi projetado para mídias sequenciais. Encontrar um arquivo específico exige percorrer as entradas do arquivo uma por uma, resultando em tempos de busca lineares. Quando combinado com compressão de fluxo como tar.gz, extrair um único asset requer descomprimir todo o arquivo.

O ZIP melhora substancialmente ao introduzir um diretório central que permite buscas diretas. No entanto, o diretório fica no final do arquivo, os cabeçalhos locais duplicam metadados, e o suporte a criptografia evoluiu através de múltiplas extensões ao longo dos anos. O ZIP continua sendo um formato de arquivo de uso geral flexível, e não um sistema otimizado para streaming de assets e identidades estáveis.

Os formatos de motores de jogo frequentemente resolvem essas limitações de formas que refletem as prioridades de seus respectivos ecossistemas.

Os Asset Bundles da Unity priorizam a integração com o editor e o runtime da Unity. Implementações iniciais dependiam fortemente de compressão LZMA monolítica, enquanto versões mais recentes introduziram compressão LZ4 em blocos para melhorar o comportamento de carregamento. Apesar desses avanços, o formato permanece intimamente ligado à Unity.

O formato PAK da Unreal é uma das abordagens mais ricas em recursos, com suporte a métodos avançados de compressão, criptografia e montagem em camadas de pacotes. No entanto, está profundamente integrado ao sistema de arquivos virtual e ao pipeline de assets da Unreal.

O formato PCK da Godot foca na simplicidade e na integração perfeita com o motor. Os assets são identificados principalmente por caminho, e o sistema de empacotamento é projetado em torno do processo de exportação da Godot, não para gerenciamento geral de assets.

O rres do raylib é talvez o parente filosoficamente mais próximo do OAP. Oferece uma especificação aberta com suporte a compressão e criptografia, mantendo uma implementação leve. Intencionalmente deixa questões como gerenciamento de dependências e identidade de assets em grande escala para sistemas de nível superior.

O OAP foi projetado para atender a esses requisitos diretamente: acesso aleatório rápido, streaming eficiente, identidades estáveis de assets e relações de dependência explícitas em um formato independente de qualquer motor específico.

Destaques do design

Cabeçalho de tamanho fixo: O OAP organiza os pacotes com um layout simples onde o índice fica no final. Um cabeçalho de tamanho fixo é armazenado no início do arquivo, enquanto um índice ordenado fica em um deslocamento conhecido próximo ao final. Os dados dos assets ocupam o espaço intermediário. Abrir um pacote torna-se um processo simples: ler o cabeçalho, ir diretamente ao índice e fazer uma busca binária para localizar o asset desejado. Não é necessário percorrer o conteúdo dos assets. Quando os pacotes são hospedados remotamente, localizar um asset geralmente requer apenas duas requisições de intervalo HTTP: uma para o cabeçalho e outra para o índice.

Recursos independentes por asset: Compressão e criptografia são definidas por asset, não no nível do pacote. Um asset pode ser armazenado sem compressão para carregamento rápido, enquanto outro pode usar compressão DEFLATE e criptografia ChaCha20. Ler um único asset nunca requer descomprimir ou descriptografar o arquivo inteiro. As chaves de criptografia são intencionalmente excluídas do pacote, oferecendo proteção contra extração casual sem tentar funcionar como um sistema de DRM.

Identidade de assets: O OAP separa a identidade do asset da organização do sistema de arquivos. Os assets são identificados por identificadores estáveis de 128 bits, enquanto os caminhos legíveis por humanos são tratados como metadados, não como chaves primárias. Isso viabiliza fluxos de trabalho práticos para patches e conteúdo para download. Um pacote pequeno contendo apenas assets modificados pode ser montado junto a um pacote existente, e as buscas são resolvidas usando identificadores de assets em vez de nomes de arquivo. Renomear ou reorganizar arquivos não invalida mais referências em todo o projeto.

Grafo de dependências de assets: O OAP permite que assets declarem dependências diretamente no índice do pacote. Materiais podem referenciar texturas, cenas podem referenciar malhas, e prefabs podem referenciar recursos de suporte. Ao tornar esses relacionamentos explícitos, os motores podem construir grafos de carregamento, realizar análise de dependências e implementar estratégias de streaming mais sofisticadas sem depender de sistemas de metadados separados.

Especificação técnica

O formato OAP é documentado independentemente em SPEC.md. A especificação é agnóstica de linguagem e intencionalmente compacta: um leitor em conformidade requer apenas parsing de inteiros em little-endian, uma implementação de CRC-32/ISO-HDLC e um decodificador DEFLATE bruto — todos disponíveis em qualquer biblioteca padrão principal. Um leitor mínimo tem algumas centenas de linhas em qualquer linguagem com acesso a buffers de bytes. Implementações alternativas em outras linguagens são explicitamente bem-vindas; o repositório inclui um guia de portabilidade (docs/implementing.md) e um fixture de teste canônico (testdata/sample.oap) para validação.

Comparações

Formatos de arquivo de uso geral

Recurso	tar.gz	ZIP	OAP
Especificação aberta	Sim	Sim	Sim
Busca de assets	Sequencial O(n)	Diretório central O(1)	Índice com busca binária O(log n)
Amigável a range HTTP	Fraco	Limitado	Excelente
Compressão por asset	Não (arquivo inteiro)	Sim	Sim
Criptografia por asset	Apenas externa	Legada / extensões AES	ChaCha20 por asset
Identidade estável do asset	Não	Não	Sim (ID de 128 bits)
Verificação de integridade	Nenhuma	CRC-32 opcional	CRC-32 obrigatório
Rastreamento de dependências	Não	Não	Sim
Overhead típico por entrada	512 bytes	~76+ bytes	64 bytes fixos

Formatos de assets de motores de jogo

Recurso	Unity Asset Bundles	raylib rres	Godot PCK	Unreal PAK	OAP
Especificação aberta	Não	Sim	Sim	Não	Sim
Busca de assets	Indexada O(1)	Sequencial O(n)	Sequencial O(n)	Indexada	Busca binária O(log n)
Amigável a range HTTP	Limitado	Moderado	Limitado	Moderado	Excelente
Compressão por asset	Em blocos (LZ4)	Sim	Não	Sim	Sim
Criptografia por asset	Não	Sim	Nível de pacote	Sim	Sim (ChaCha20)
Identidade estável do asset	Não	IDs de 32 bits	Baseada em caminho	Hashes de caminho	IDs de 128 bits
Verificação de integridade	Sim	Sim	Sim	Sim	CRC-32 obrigatório
Rastreamento de dependências	Externo (Addressables)	Não	Externo	Externo	Embutido
Ferramentas independentes de motor	Não	Sim	Limitado	Não	Sim

O OAP não tenta substituir os pipelines de assets específicos de cada motor. Em vez disso, foca em oferecer um formato de empacotamento portátil que incorpora capacidades comumente encontradas em soluções especializadas, mantendo-se simples de implementar e independente de qualquer ecossistema de motor específico.

Desempenho

A tabela a seguir compara o OAP com tar e tar.gz em uma carga de trabalho sintética de assets de jogos: 360 assets totalizando aproximadamente 114 MB de dados brutos, misturando conteúdo compressível (scripts, configurações, descrições de cenas) com blobs incompressíveis (áudio e texturas pré-comprimidos). Todos os valores OAP usam uma build otimizada com ReleaseFast em x86_64 Linux; os valores do tar incluem o overhead de inicialização do subprocesso.

Formato	Tempo de empacotamento	Tamanho do arquivo	vs bruto	Leitura sequencial	Acesso aleatório
OAP — auto (deflate onde benéfico)	153 ms	89,6 MB	−21,8%	72 ms	71 ms
OAP — store (sem compressão)	100 ms	114,6 MB	+0,0%	65 ms	66 ms
tar	155 ms	114,9 MB	+0,2%	80 ms	N/D
tar.gz	1.399 ms	89,6 MB	−21,8%	123 ms	N/D

O OAP com compressão automática empacota no mesmo tempo que o tar simples enquanto atinge a mesma taxa de compressão do tar.gz — que leva nove vezes mais para produzir e quase o dobro do tempo para ler. A leitura sequencial é mais rápida do que ambas as variantes tar. O acesso aleatório — indisponível para formatos tar sem extração completa — completa em aproximadamente o mesmo tempo que uma leitura sequencial completa, graças à busca binária O(log n) sobre o índice ordenado.

Ferramenta de linha de comando da implementação de referência

A implementação de referência é distribuída como um único executável chamado oap, concebido tanto como utilitário prático quanto como exemplo de uso do formato em aplicações reais.

A biblioteca principal consiste em aproximadamente 500 linhas de código e depende exclusivamente da biblioteca padrão do Zig para funcionalidades de compressão e criptografia. O processo de build produz tanto uma biblioteca estática (liboap.a) quanto o utilitário de linha de comando oap. Aplicações escritas em C, C++, C# ou outras linguagens compatíveis com FFI podem integrar o OAP sem exigir Zig no restante do código.

PACK: O empacotamento é feito com o comando pack, que percorre recursivamente um diretório e produz um arquivo .oap: oap pack assets/ game.oap. A compressão pode ser habilitada ou desabilitada conforme necessário, os metadados do pacote podem ser customizados, e os assets podem ser opcionalmente criptografados com ChaCha20. Por padrão, os identificadores de assets são gerados deterministicamente a partir dos caminhos virtuais, garantindo identidades consistentes entre builds.

INSPECT: Diversos comandos estão disponíveis para inspecionar o conteúdo dos pacotes. O comando inspect exibe metadados do pacote, como versão do formato, informações do manifesto, contagem de assets, localização do índice e status de criptografia. O comando list fornece um inventário mais detalhado dos assets empacotados, incluindo identificadores, métodos de compressão e criptografia, tamanhos e caminhos virtuais.

UNPACK: Os pacotes podem ser extraídos com o comando unpack, restaurando os assets conforme seus caminhos virtuais. Pacotes criptografados podem ser desempacotados fornecendo a chave de criptografia adequada.

VALIDATE: Para fluxos de trabalho automatizados, o comando validate verifica tanto os metadados do pacote quanto o checksum CRC-32 de cada asset contido no arquivo: oap validate game.oap. Isso o torna adequado para uso em pipelines de integração contínua ou para validar pacotes distribuídos por redes de entrega de conteúdo.

Parte do Turian

O OAP se originou no ecossistema do motor de jogo Turian, mas foi projetado como um formato independente, adequado para qualquer motor ou aplicação que necessite de empacotamento eficiente de assets.

Código-fonte e a especificação completa