Esse artigo foi originalmente escrito para o blog do OpenRCT2.

Nosso jogo é uma reimplementação de código aberto do RollerCoaster Tycoon 2 com a adição de muitas funcionalidades e correções ao longo dos últimos 11 anos¹ que com certeza fizeram-no engordar. Isso não significa que não queremos que ele rode em sistemas mais simples² então o LRFLEW deu uma volta e aplicou algumas canetas de emagrecimento em alguns arquivos para torná-lo até 30% menor enquanto comprime e descomprime até 12 vezes mais rápido!

Bora mergulhar nessa melhoria incrível? Se sua resposta foi: “Nem a pau, comédia, prefiro ler as mudanças direto”, aqui estão:

• Refactor Compression and Streams, and Add IStream Direct Interface - #24701
• Don’t Double-Compress Park Chunks in Replay File - #24728
• Use ZStandard Compression for PARK and PARKREP Files #24734

Então lá vamos nós 🎢

Compressão & OpenRCT2

Para simplificar, daqui em diante vou tratar “compressão” como sinônimo tanto de comprimir e descomprimir um arquivo.

Quando você está jogando, há muitas situações em que criamos um arquivo, eis algumas delas:

1. Criar arquivos de cenário/jogo salvo (*.park)
2. Gravar um replay (*.parkrec)
3. Quebrar (crashar) o jogo³ (*.sad *.dmp e amigos)

Cada um deles tem diferentes requisitos de velocidade e tamanho: replays normalmente são criados manualmente e as pessoas tolerariam esperar mais tempo para que eles fossem salvos, especialmente por poderem ser maiores, enquanto do outro lado você não quer o jogo dando umas “travadas” toda vez que está salvando automaticamente, então ajustar a compressão e descompressão é um trabalho difícil! Para esse trabalho, o LRFLEW atacou os dois primeiros itens, por serem os mais comuns.

Compressão na v0.4.25

Nessa versão usávamos a zlib como nossa biblioteca padrão para compressão. É um algoritmo robusto que resiste ao tempo, está aí desde 1995 e se tornou um padrão na indústria, sendo encontrado nativamente em vários sistemas operacionais e provavelmente há um rodando nesse momento em alguma das suas aplicações em execução.

Ele continua sendo bem comum mesmo tendo 30 anos de idade, porque muitas das alternativas que surgiram desde então ou conseguem comprimir mais, de forma mais lenta, ou mais rápido, mas sem diminuir tanto o tamanho do arquivo.

Compressão na v0.4.26

Muitas empresas big-tech⁴ já despenderam recursos ilimitadamente para desenvolver melhores algoritmos de compressão, já que enviar dados ou mantê-los em disco pode ser muito caro. Algumas delas tornaram públicas essas tecnologias, como a Google que expôs o Brotli ao mundo ou a Meta lançando o Zstandard (abreviado como Zstd). Enquanto o primeiro pode chegar a incríveis taxas de compressão, ele normalmente o faz ao custo de longuíssimos tempos de execução e como não seria uma solução universal para os usos destacados acima, escolhemos o segundo.

Eis aqui como o ZStandard se compara ao zlib em termos de velocidade e tamanho para comprimir o arquivo:

E aqui pode-se ver quão mais rápido ele é na descompressão desses mesmos arquivos:

Resultados

Esses algoritmos são bastante customizáveis e você pode escolher um maior nível de compressão para ter um arquivo menor se quiser esperar mais tempo. No Zstd esses níveis variam do 1 ao 22, então havia muito a ser testado e refinado. Felizmente LRFLEW fez isso de forma meticulosa e trouxe os resultados, veja nessa tabela a seguir:

Nota: Descomprimir se tornou 3,5 vezes mais rápido em todos os cenários, independente do cenário.

Ao que tudo indica, todos deveriam ver o OpenRCT2 gastar menos espaço nos seus discos daqui pra frente, assim como criar e abrir arquivos de forma mais ágil. Podemos falar que “caiu como uma luva”!

Reconhecimentos

Se ainda não está claro, um grande salve para LRFLEW por correr atrás disso. Não só escreveu todas as muitas mudanças necessárias no código, mas o fez com paciência de escrever relatórios detalhados, separando em conjuntos de mudanças menores onde dava e monitorando qualquer desastre da mudança após ser incorporada para fazer correções rapidamente. Um ótimo retorno!

Como posso ajudar?

1. Jogue OpenRCT2 e se divirta
2. Espalhe a palavra do nosso jogo
3. Apoie os desenvolvedores que tem o programa de patrocínio do GitHub ativados
4. No domínio de compressão, ainda podemos investigar:
   1. Se podemos aplicar o Zstd aos relatórios de crash
   2. Se queremos começar a comprimir outros artefatos como os JSONs de objetos ou parkpatch
   3. Se queremos criar as versões dos outros repositórios Open* em outro formato, e assim tornar mais rápido baixá-las durante a compilação, potencialmente acelerando também nossos fluxos de integração contínua
5. Relatando um problema ou abrindo um pedido de mudança caso encontre uma oportunidade!