Internal Beeper


¿Pero que graban?
octubre 29, 2005, 2:21 am
Filed under: Quejas

Uno de los ejemplos más claros sobre el despilfarro generalizado de memoria y recursos de los juegos actuales está en el tamaño de los saves, de las partidas grabadas.

Para calcular el tamaño que se requiere para grabar, debemos tener en cuenta el tamaño de los datos. Contabilizando el tamaño en bytes (1024 bytes es un kb), podemos representar un número con un byte (exceptuando quizás algunos números más grandes que ocuparán 2 bytes). Con un byte podremos representar también un total de 8 valores binarios entre verdadero o falso, o también una letra.

Es decir, sin comprimir, en 1 solo kb podríamos representar un total de 1024 números, o 8192 valores binarios. Eso tendría que darnos capacidad de sobra para grabar los datos de muchos juegos. Pero en realidad, actualmente no hay ningún juego donde el save ocupe tan poco. Por lo general, pocos saves bajan de los 100 kb, y muchos llegan a alcancar la mega. Es decir, más de un millón de números.

Pongamos el ejemplo del Lumines. El save del juego, una vez descontado el tamaño del icono del save y similares, queda en 18464 kb. La configuración de teclas debería ocupar una cuarta parte de byte (2 bits), ya que sólo se pueden escoger entre tres opciones. El resto de la ficha de personaje, es decir, el nombre y nuestro icono, ocuparán como mucho, 7 bytes, ya que hay 6 letras.
Eso nos lleva un total de 8 bytes, al que le debemos sumar 2 bytes más para puntuación máxima en modo 1 jugador, y 2 bytes más, uno para máximo nivel conseguido en el puzzle y otro para el nivel máximo en 1P vs CPU.

Llevamos 12 bytes para el registro de personaje. Y no hacen falta más. Los skins e iconos conseguidos los puede calcular la máquina, porque dependen de los valores que ya hemos almacenado.

Aunque es cierto que el juego permite usar múltiples “cuentas de personaje”, deberíamos usar 1.500 cuentas distintas para agotar los 18 kb de tamaño. Que va a ser que no, oiga.

Ahora sólo nos quedan los records. Son 10 récords, y para cada uno son 8 bytes (6 del nombre y 2 para la puntuación), pero los podemos resumir a 3 si en vez de nombre usamos el identificador de número de “cuenta de personaje”.

Así pues, el save ideal, y sin compresión, sería de 30+(12 x numero de cuentas) bytes, y no 18464 bytes.

Es un simple ejemplo, aunque aceptemos que hay juegos donde se graba en cualquier momento y que deben contemplar el estado de todos los enemigos y objetos de esa fase (a veces, de todo el juego), lo que hace que el tamaño del save sea descomunal por necesidad, este efecto de desperdicio de save es común en todos los juegos.

Por poner un ejemplo rápido… juegos tipo Tekken, de lucha, arcades como el Metal Slug, shooters como el Star Soldier (su save en PSP ocupa 100 kb)… tienen un tamaño de save exageradamente grande que podría ocupar, tranquilamente, menos de un 1kb.

Es un simple detalle. Ninguna juego de consola, ni de PC, va a funcionar mal por usar un save más grande de lo necesario, pero es una muestra de como se suele programar. Mal. Muy mal. Se empieza guardando saves demasiado grandes, y se acaba ocupando memoria de forma estúpida en texturas y polígonos que no aparecen, calculando las sombras de cosas que no aparecen por pantalla, etc, etc.

A veces vemos un juego que supera todas las características de los juegos anteriores, que permite una gran cantidad de polígonos, una IA avanzada, un escenario dinámico y vaya usted a saber que chorradas y nos sorprendemos. Nos preguntamos como es posible que hayan conseguido superar la calidad de los juegos anteriores con un dispositivo que tiene la misma potencia que hace 5 años.

La respuesta, desgraciadamente, es que los de ahora han sido un poco menos malos que los de hace 5 años, y han optimizado más los recursos.

Anuncios

11 comentarios so far
Deja un comentario

Asi a lo pronto solo se me ha ocurrido exclamar: ¡Pero que brutos!

Comentario por Koopa

Y no es solo en los juegos.

Una vez estuve encargada de reciclar una vieja aplicación de gestión para adaptarla a los requerimientos de otra empresa. Programando mal y a lo tonto (lo reconozco), la aplicación final ocupaba 2 Megas. Y les pareció pequeño.

Como los clientes no nos decían nada y me aburría, un día optimicé el programa, mejorando mis funciones y encerrando en comentarios todas las funciones “heredadas” de la vieja aplicación y que ahora no se usaban.

Imagínate la cara de sorpresa que pusieron cuando les dije que aquella aplicación tan pequeñita tenía una nueva versión que ocupaba la mitad.

Comentario por Urui

Echando mano de la conspiranoia (o quizá sin llegar a eso), casi te diría que los saves ocupan tanto para obligar a los usuarios a comprar más targetas de memoria…

Comentario por Shimart

No tiene que ver que ocupen 20kb un savegame cuando se podría guardar en 1kb o menos. Hay que tener en cuenta muchos factores, por ejemplo: qué pasa si el cálculo de cierta imagen o ciertos datos son costosos, quizás cueste menos leerlos de disco a tener que volver a recalcularlos. Otro ejemplo: Si un juego está bien programado lo lógico es que guarde sus partidas serializando las estructuras que contienen esos datos. La serialización puede ser en binarios o quizás en ascii usando XML y seguramente incuya datos sobre la información que contiene.

Otro ejemplo aùn más revelador, las intros de 4kb (www.pouet.net). Es bestial ver como en 4kb meten gráficos, geometría, música, efectos… son solo 4kb, pero piden muchísima más máquina de la que usaría si ocuparan 1 mega.

En conclusión, aunque es posible que no mire demasiado el tamaño de esas cosas, no creo que sea un factor determinante para decir si está bien o mal programado. Es más, por que un videojuego tenga una tecnología muy buena no va a ser mejor juego.

un saludo

Comentario por javi

Antes que nada, javi, buena página, te enlazaré en la próxima actualización de main.

Pero debo disentir en lo que me comentas. Volver a recalcular los datos implicaría un tiempo mayor de carga de datos (no realmente, los datos tardarían menos en cargar, pero el proceso de recalcular amplia ese tiempo).

Y es posible que en algunos casos concretos sea mejor, en cuestión de saves, hacer un simple volqueo de zonas de memoria (por ejemplo, en un FPS) para que, cuando se cargue, todo se comporte exactamente igual.

Pero, lo que he dicho, en juegos donde el save se produce en momentos muy concretos, como un juego de puzzle, uno de lucha, shooters, de carreras, etc, no hay coste de recalculación de datos. En el ejemplo del Luúmines, calcular los skins desbloqueados mediante la puntuación o nivel alcanzado en modo puzzle y 1pvscomputer no tiene ningún tipo de coste.

O los extras desbloqueados en un Tekken o un Time Crisis, por ejemplo, o las carreras y coches disponibles en un Ridge Racer. Y todos estos juegos tienen saves que superan los 100 kb.

El formato xml para guardar saves es un grave error. Si, internamente, tienes una array de bits donde contemplas que hay bloqueado y que desbloqueado, lo mejor para guardar es volcar la array como un único bloque de bytes y, para cargar, hacer lo mismo.

Comentario por DonDepre

Está claro que lo mejor es poner lo justo y empaquetado en binario, pero a veces no es posible hacerlo así, no por cuestión tecnológica, si no por cuestión de tiempo. Hace poco he programado un juego para art futura y en él se guarda en disco información acerca de los parámetros de un coche. Para mi era muchisimo más cómodo guardarlo en un formato de texto (léase xml, ini, etc) para poder editar parámetros a mano. Llega el momento de la entrega y estoy pillao, lógicamente prefiero dejarlo a un lado en favor de otras cosas más importantes y que se ven más, como por ejemplo la animación del cielo, quedando un fichero de parámetros del coche 10 veces mayor del que realmente necesito.

De todas formas estaría bien saber qué guardan algunos juegos, quizá sea cuestión de investigar :).

Gracias por lo de la página, lo mismo digo de la tuya.

Comentario por javi

Yo también me decanto por formatos más “legibles”. Empaquetar a binario y luego interpretar eso me costaría algo de trabajo y el beneficio es mínimo. Ciertamente aún mi proyecto no está en la etapa de3 salvar nada, pero planeo usar xml para tener un formato flexible y facil de depurar.
Oye ¿es un error o el save de Lumines ocupa 18464 kb? Eso es 18 megas ¿no?

Comentario por roger

David, disculpa que vaya con tanta prisa, pero por culpa de un bulo publicado por la cadena Tebeos en el “Tebeo Tvo”, las autoridades de la blogósfera intentan capturarme. Por favor, ayúdame a escapar.
Rafv

Comentario por rafv

Estimado blogociudadano. Las autoridades nos han informado de las huellas que Rafv ha dejado en su blog hace un instante. La cadena Tebeos, colaborando con las autoridades, le pide que nos facilite cualquier pista que nos ayude a capturarlo, con el fin de mantener el orden de la blogósfera en paz.
Así mismo, la cadena Tebeos, comprometida con el bienestar social, le pide su colaboración para subsanar las incomodidades que esta cacería pueda causar. Si usted sabe de alguien que se vea emocionalmente afectado por los desplazamientos de Rafv, háganoslo saber. El canal dará una valiosa recompensa: un link tanto para el notificante como para la víctima, en su sección “mando a distancia”
Que tenga muy buenas tardes y gracias por su colaboración.

Comentario por Tebeos

DonDepre, se te ha colado Spam. Eso es que eres famoso.

Por cierto, en PS2, las partidas salvadas suelen ocupar tanto más bien por el monigote 3D que sale de icono, y ya si tiene una animación currada lo flipas.

AUnque toda partida salvada se queda pequeña ante una del Eyetoy 😛

Comentario por tostadilla

Si es que hay pocas personas que realmente se pongan a hacer saves pequeños… yo apenas me creía, cuando empecé a jugar a la saga ToHo que un replay de una partida de más de veinticinco minutos ocupara tan sólo ¡60 kb! ¡Y yo que pensaba que semejantes monstruos ocuparías al menos ocho megas (pues cuentan todos los movimientos de tu personaje, los disparos de los enemigos, sus factores aleatorios (¡que son miles!), cuando disparas y cuándo no, las bombas que usas, las apariciones espontáneas… todo eso… ¿en menos de un mega? Me costaba (y aún me cuesta…) pensar que eso es posible.

Lo que logró Zun en el Perfect Cherry Blossom (para PC, por cierto) siempre me ha parecido algo más cercano a una obra de arte que a una solución técnica, en serio…

Comentario por Jeshua_Morbus




Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s



A %d blogueros les gusta esto: