The Call of Cthulhu: Semana del 17/11/08

Aquí estamos otra vez comentando los avances de Cthulhu durante la pasada semana. En este tiempo, el trabajo se ha centrado en tres aspectos: 1) Optimización brutal del código para la reducción del consumo de memoria, 2) Remodelación de la primera escena del juego, y 3) Desarrollo de una aplicación nativa (funciona en Mac OS X, Windows y Linux) para definir los scripts de las escenas.

En la parte de la optimización de código, los avances han sido impresionantes. Apple recomienda que las aplicaciones del iPhone no consuman más de 20 ó 25 MB de memoria. A pesar de que el aparato cuenta con 128 MB, hay que tener en cuenta que el sistema operativo está corriendo por debajo, y que después de días y días sin apagar el iPhone o iPod Touch, haya basura en la RAM que acorte aún más la memoria libre disponible. Por ello, ocurría que en ocasiones, el sistema abortaba el juego y volvía a SpringBoard, el lanzador de aplicaciones del iPhone. Trazando el programa con la aplicación Instruments, se veía que el uso de RAM era de 40 MB en la escena más larga del juego, que es la segunda, y aunque después de apagar y volver a encender el dispositivo el juego no se abortaba nunca, esta situación no daría una buena experiencia al jugador.

Cuando trabajas en proyectos marcándote plazos de finalización, está claro que trabajas a contra reloj y muchas cosas las haces sin pararte después a optimizar recursos. Por ello, es bueno volver sobre el código reescrito y ver las partes críticas para buscar una alternativa. En el caso del Cthulhu, había dos apartados críticos donde las cosas no se habían hecho de la forma adecuada: por un lado, la música de fondo se cargaba completamente en RAM, en lugar de ir haciendo streaming de disco para reducir la carga en memoria; y por otro, cuando en una escena aparecían repetidos varios objetos, se recargaba la imagen para todos ellos.

Así que añadí el streaming de audio, y escribí un sistema para que las imágenes que aparecen varias veces se cargasen una sola vez y se reutilizasen, y realicé algunas otra optimizaciones, aunque estas no tuvieron un gran impacto en el ahorro de recursos. Por ejemplo, gran parte de los arrays dinámicos que utilizábamos en el juego han sido reemplazados por arrays estáticos. Una vez hecho todo esto, los resultados fueron impresionantes. En las partes donde se consumía más memoria, ésta se redujo hasta un 90%. Por ejemplo, la escena que comentábamos que consumía 40MB, ocupa en memoria ahora únicamente 4,6.

En la parte gráfica, se remodeló como comentábamos la primera escena del juego. Aún hay que pulir algunos aspectos, pero la mejoría es bastante notable. Os pongo una imagen del antes y el después (sí, aún falta la puerta en la nueva versión):

Por último, empecé a trabajar en una aplicación con la que definir las características y los scripts de cada escena del juego. Hasta ahora, como quienes se encargan de esto no son programadores, realizaban los scripts con una hoja de Excel, que era después exportada por Visual Basic a un formato binario que se cargaba en el juego. Una de las pegas de este sistema era la manera engorrosa de colocar objetos en la escena, metiendo las coordenadas a mano y luego comprobando con el juego que se colocaran correctamente (si además contamos que las coordenadas van en 3D, y luego se proyectan a la pantalla para que queden correctamente colocadas sobre el fondo, lo hace aún menos intuitivo). Por otro lado, los valores de muchas constantes había que meterlos a mano, haciéndolo más propenso a errores (como ya ha ocurrido alguna vez).

Gracias a esta nueva aplicación, ahora se colocan de forma visual los objetos sobre el fondo de la escena, y se definen los scripts a base de clicks de ratón. Básicamente, se empieza definiendo el fondo de la escena y a continuación se pintan las cuatro esquinas del suelo sobre el que el jugador podrá moverse. Esto además sirve para definir el tamaño y profundidad de la perspectiva en 3D. Luego se eligen los objetos de la lista y se van colocando sobre el fondo. sobre cada objeto se pueden definir una serie de propiedades, como los scripts a lanzar cuando se realiza la acción Mirar, o Coger, o Usar, etc. Estos scripts se declaran en otra pestaña, y básicamente son una secuencia de acciones, algunas de ellas condicionales en función de que se cumplan ciertos requisitos (haber recogido determinado objeto o llegado a cierto punto en el juego).

Aquí tenéis una captura del aspecto actual de la aplicación, aún sin terminar:

En unos días volveremos con otro informe, como siempre.