Patches de jogos: localidade de bytes nos pacotes, chunks de entrega e manifestos

Finalidade

Uma pequena edição de asset pode gerar uma atualização grande se reorganizar muitos bytes nos pacotes distribuídos. Por isso, o design de patches começa pela relação entre conteúdo lógico, layout dos pacotes e sistema de entrega. Um chunk da engine que agrupa assets não é necessariamente a mesma unidade que os chunks de bytes de um serviço de distribuição. Documente os dois limites antes de interpretar uma estimativa de tamanho de atualização.

Como funciona

O SteamPipe divide os arquivos enviados em chunks de cerca de um megabyte, compara o novo conteúdo com o build anterior e reaproveita os chunks inalterados sempre que possível. A documentação alerta que reordenar assets, mudar offsets ou usar compressão que abranja conteúdos não relacionados pode fazer com que pequenas edições afetem faixas de bytes bem maiores. Manter uma ordem estável e agrupar os assets por fase ou funcionalidade pode melhorar a localidade, mas o benefício depende do formato real do pacote.

Um manifesto de entrega descreve os assets que pertencem a um build. O exemplo do ChunkDownloader da Epic lista nomes de arquivo, tamanhos em bytes, versões, identificadores de chunk e caminhos relativos. Esse manifesto é uma descrição de distribuição; ele não dispensa a verificação de que os arquivos referenciados estão disponíveis e corretos.

Exemplo prático

Suponha que um sistema de atualização substitua pacotes inteiros e que um jogo tenha 4 pacotes de 64 MiB cada, ou seja, 256 MiB no total. Editar uma textura de 500 KiB dentro de um dos pacotes exige, nessa política, baixar o pacote alterado de 64 MiB. Se todo o conteúdo estivesse em um único pacote de 256 MiB, a unidade de substituição seria de 256 MiB.

Um serviço de delta de bytes pode transferir menos quando encontra regiões inalteradas. O cálculo acima ilustra uma política de substituição de pacote inteiro e não é um resultado medido do SteamPipe. Bytes transferidos comprimidos, uso temporário de disco e leituras e escritas da instalação são grandezas distintas.

Fluxo de trabalho prático

Compare artefatos de releases consecutivas antes da distribuição. Verifique se uma edição de asset altera apenas a região pretendida ou se também move dados não relacionados. Mantenha estáveis a ordem dos pacotes e os limites de compressão sempre que o formato permitir. Envie e verifique os novos assets antes de publicar o manifesto que os referencia; associe manifestos e arquivos a uma identidade de build inequívoca.

Teste a atualização a partir de cada versão instalada suportada, incluindo downloads interrompidos, retomada e pouco espaço em disco. Uma instalação em etapas só deve se tornar o build selecionado depois que os arquivos necessários passarem nas verificações do atualizador. Guarde informações suficientes sobre o build anterior para diagnosticar ou recuperar uma transição incompleta.

Limites e verificação

A Valve observa que alterar uma pequena parte de um pacote grande ainda pode exigir a reconstrução desse pacote em disco, mesmo que o download seja pequeno. Reduzir o tráfego de rede não reduz automaticamente o tempo de instalação nem o espaço livre necessário.

Criptografia, compressão, agrupamento de dependências e regras de distribuição da plataforma podem restringir as escolhas de empacotamento. Pacotes minúsculos em excesso também trazem sobrecarga própria. Meça edições de conteúdo representativas no caminho de entrega real, registrando separadamente os bytes baixados, o trabalho em disco e o tempo. Não prometa uma proporção de patch específica com base apenas no tamanho dos assets.

Fontes

• SteamPipe: Uploading to Steam — Valve
• Hosting a Manifest and Assets for ChunkDownloader — Epic Games