Se trata de un juego de plataformas en el que un personaje un tanto corruptillo llamado Lárcenas tiene que adjudicar obras públicas a sus amigos constructores lanzándoles ladrillos. Éstos, en agradecimiento, le devuelven unos sobres-aguinaldo. Como la cosa anda revuelta, Lárcenas necesita hacer llegar los sobres a otro amigo, banquero esta vez, que los pondrá a buen recaudo en un paraíso fiscal. Pero un implacable juez no se lo va a poner fácil, requisando todo indicio de corrupción y soborno que se cruce en su camino.El objetivo ahora es hacer llegar esos sobres a su banquero de confianza para que éste lo deposite en un paraíso fiscal.
Guía:
-
Lanza ladrillos al promotor.
-
El promotor te devolverá el favor en forma de sobre.
-
Lanza el sobre al banquero y acumula dinero.
-
Evita que el juez intercepte tus envíos o acabarás entre rejas.
Historia del juego y desarrollo
La idea se nos ocurrió a mi amiguete de fechorías Alfredo Soro y a mí en un brainstorming de 1 hora. A lo largo del desarrollo la idea original se fue retocando, normalmente para recortarla ya que no nos daba tiempo a meter tanta cosa como habíamos pensado.
Yo empecé a mirarme unos tutoriales sobre la arquitectura del CPC 464, leí algunas historias de gente que aún andaba programando para esta máquina, recopilé las herramientas que usaban unos y otros, las probé todas y seleccioné las que menos problemas me dieron creando un toolchain que permitía convertir mi código C/ASM en una disco/imagen ejecutable. Después hice una prueba sencilla en la que pintaba un cuadrado, el cuadrado se convirtió en un muñeco y el muñeco en un sprite. Después se unieron varios sprites para hacerle compañía al primero. Ahí se unió Alfredo que me ayudó con la parte artística: crear una historia/excusa para el juego y crear unos sprites bonitos para no tener que robarlos de otros juegos. Después todo fue implementar una pequeña lógica dirigida por una jerarquía de sencillísimas máquinas de estado, poner algo de orden, pelearnos con algunos problemas derivados de escribir a lo loco en la memoria, sobreescribiendo partes del firmware de la máquina, empaquetar y listo.
En primer lugar, intentamos elaborar un diseño general del juego para hacer una división del trabajo en función de los intereses o habilidades de cada uno. Sin embargo la falta de tiempo y conocimientos de las tecnologías en uso nos impidió hacer el desarrollo que a priori diseñamos y fuimos intentando salvar los problemas al tiempo que surgían.
El problema principal fue el desconocimiento de la arquitectura y el poco tiempo que teníamos (3 noches) para aprenderlo y desarrollar el juego. La solución: derribar el muro a cabezazos (prueba/error, prueba/error, prueba/error…). Los problemas típicos eran cuelgues, resets y glitches visuales aleatorios, casi todos provocados por no tener una estrategia bien definida de manejo de la memoria.
Tras todo esto, incomprensiblemente, ganamos el concurso :).
Tecnologías utilizadas
-
sdasz80 ensamblador cruzado (parte de SDCC).
-
SDCC como compilador para el código fuente en C.
-
CPCDiskXP para generar los ficheros DSK a partir de los binarios.
-
AMSprite para crear los sprites del juego.
-
WinAPE como emulador principal de Amstrad donde probar y depurar los resultados.
Lecciones Aprendidas
Hemos aprendido que todo era más sencillo y más bonito cuando no había tanto framework y tanta historia. De paso, confirmé que es mucho más divertido hacer videojuegos que jugarlos.