Parches de juegos: localidad de bytes en paquetes, chunks de entrega y manifiestos

Propósito

Una edición pequeña de un asset puede generar una actualización grande si reordena muchos bytes de los paquetes distribuidos. Por eso el diseño de parches parte de la relación entre el contenido lógico, la estructura de los paquetes y el sistema de entrega. Un chunk del motor que agrupa assets no es necesariamente la misma unidad que los chunks de bytes de un servicio de distribución. Documenta ambos límites antes de interpretar una estimación del tamaño de la actualización.

Cómo funciona

SteamPipe divide los archivos subidos en chunks de aproximadamente un megabyte, compara el contenido nuevo con la compilación anterior y reutiliza los chunks sin cambios siempre que es posible. Su documentación advierte que reordenar assets, cambiar los desplazamientos (offsets) o usar una compresión que abarque contenido no relacionado puede hacer que ediciones pequeñas alteren rangos de bytes mucho mayores. Mantener un orden estable y agrupar los assets por nivel o por funcionalidad puede mejorar la localidad, pero el beneficio depende del formato de paquete concreto.

Un manifiesto de entrega describe los assets que pertenecen a una compilación. El ejemplo de ChunkDownloader de Epic enumera nombres de archivo, tamaños en bytes, versiones, identificadores de chunk y rutas relativas. Ese manifiesto es una descripción de distribución y no sustituye la comprobación de que los archivos a los que hace referencia estén disponibles y sean correctos.

Ejemplo resuelto

Supón que un sistema de actualización reemplaza paquetes completos y que un juego tiene 4 paquetes de 64 MiB cada uno: 256 MiB en total. Con esta política, editar una textura de 500 KiB dentro de un paquete obliga a descargar ese paquete modificado de 64 MiB. Si, en cambio, todo el contenido estuviera en un único paquete de 256 MiB, la unidad de reemplazo sería de 256 MiB.

Un servicio de deltas por bytes puede transferir menos cuando detecta regiones sin cambios. El cálculo anterior ilustra una política de reemplazo de paquetes completos; no es un resultado medido de SteamPipe. Los bytes transferidos comprimidos, el uso temporal de disco y las lecturas y escrituras de la instalación son magnitudes distintas.

Flujo de trabajo práctico

Compara los artefactos de versiones consecutivas antes de distribuirlos. Comprueba si la edición de un asset modifica solo la región prevista o si además desplaza datos no relacionados. Mantén estables el orden de los paquetes y los límites de compresión siempre que el formato lo permita. Sube y verifica los assets nuevos antes de publicar el manifiesto que los referencia, y asocia manifiestos y archivos a una identidad de compilación inequívoca.

Prueba la actualización desde cada versión instalada que soportes, incluyendo descargas interrumpidas, reanudación y poco espacio en disco. Una instalación por etapas solo debería convertirse en la compilación activa cuando los archivos necesarios hayan superado las comprobaciones del actualizador. Conserva información suficiente de la compilación anterior para diagnosticar o recuperar una transición incompleta.

Límites y verificación

Valve señala que cambiar una parte pequeña de un pack grande puede seguir exigiendo reconstruir ese pack en disco, aunque la descarga sea pequeña. Reducir el tráfico de red no reduce automáticamente el tiempo de instalación ni el espacio libre necesario.

El cifrado, la compresión, la agrupación por dependencias y las reglas de distribución de cada plataforma pueden limitar las decisiones de empaquetado. Demasiados paquetes diminutos pueden introducir su propia sobrecarga. Mide ediciones de contenido representativas en la vía de entrega real y registra por separado los bytes descargados, el trabajo en disco y el tiempo. No prometas una proporción de parche concreta basándote solo en el tamaño de los assets.

Fuentes

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