Si actualizaste un juego y solo lo optimizaste en esa actualización (al optimizar el código) ¿la actualización haría que el archivo del juego se hiciera más pequeño?

Answer 1

Las tiendas de consolas deben mantener sus descargas lo más simples posible. Las actualizaciones siempre deben funcionar desde la descarga original o desde el juego en el disco. Ese tamaño está establecido en piedra, por lo tanto, las actualizaciones solo pueden agregarse a ese archivo.

Si tienes un juego de 10 Gb y una actualización de 2 Gb, no puedes hacer que los archivos sean más pequeños después. Solo puede optimizar antes de hacerlo público.

Si escribiste un juego de 10 Gb y luego optimizas el código a 8 Gb, no puedes reemplazar el archivo de manera segura. ¿Qué sucede si hay un error en la segunda versión? ¿Qué sucede si alguien tiene un problema con la primera versión (la descarga y detiene las actualizaciones automáticas) y la línea de ayuda solo funciona para la segunda versión?

Debería almacenar actualizaciones separadas según la versión que haya comprado. Entonces necesitaría el software para saber qué versión es y solo actualizar de manera específica, eso no hará que el código sea más pequeño.

Además, algunos juegos tienen múltiples actualizaciones y debes ejecutar cada una de ellas, ya que arreglan cosas diferentes. Si la actualización uno corrige errores y actualiza el multijugador dos correcciones, aún necesita actualizar ambos.

Básicamente, el código de optimización solo se puede hacer antes de que el juego se haga público, no después de 🙂

Answer 2

Tal vez , pero el código en sí es un porcentaje insignificante del tamaño de la mayoría de los juegos. Por lo general, son los recursos de video y audio los que ocupan la mayor parte, y para muchos juegos independientes, es Unity u otros motores / marcos que representan la mayoría del peso de un juego.

Eso es, por supuesto, todo el juego, no solo el ejecutable. Pero digamos que estamos siendo particularmente anal sobre el tamaño del ejecutable, porque ¿por qué no?

Incluso entonces, la respuesta no está del todo clara hoy en día: los compiladores (los programas que convierten el código en productos finales) ejecutan automáticamente una gran cantidad de optimizaciones por su cuenta. El tamaño “físico” de una base de código por lo tanto no está estrictamente correlacionado linealmente con el tamaño ejecutable.

Veinte líneas de código pueden colapsar a un par de operaciones en el ensamblaje (que es lo que finalmente decide el tamaño binario), o pueden aumentar a algo más grande.

Mi punto es que pequeñas reducciones del tamaño del código físico pueden conducir a un pequeño aumento en el tamaño del ejecutable, una pequeña disminución o ningún cambio en absoluto. El último con mayor frecuencia, probablemente, y los dos primeros podrían ser cambios de un puñado de kilobytes en el mejor de los casos .

En una escala macroscópica, por supuesto, sigue siendo una relación lineal. Por lo tanto, recortar una porción significativa de código (porcentaje de dos dígitos) producirá una diferencia notable en el tamaño ejecutable.

Yo mismo he hecho refactorizaciones de esa magnitud antes, pero eso fue en proyectos de aplicaciones de escritorio “simples”. No veo que suceda de manera realista en los juegos, a menos que lo que se elimine sea un andamiaje de depuración significativo.

Y, por supuesto, recuerda: para empezar, el ejecutable es un pequeño porcentaje del tamaño total de un juego moderno.

Answer 3

Es probable que un programa optimizado sea más pequeño que el programa no optimizado, pero depende de la naturaleza exacta de los cambios de optimización que realice.

También es relevante cómo el compilador para el lenguaje de programación elegido convierte su programa (juego) y sus activos en código de máquina. A veces sus resultados son contra intuitivos.

Por ejemplo, si tiene un bucle for en su juego, puede optar por “desenrollarlo” en un código más largo que no implique un bucle, lo que puede resultar en un programa más grande, que se ejecuta de manera más rápida y eficiente después de la compilación.

Otro ejemplo podría ser la optimización de los activos de imagen. Puede procesar PNG, JPG, etc. para reducir su tamaño de archivo manteniendo la calidad. Xcode en realidad va un paso más allá y al construir / compilar su juego cambia el orden de los bytes en sus activos de imagen para que coincidan con el orden esperado por la GPU en su dispositivo iOS, lo que significa que pueden cargarse / procesarse más rápidamente cuando se ejecuta el juego.