Asteroids: conclusiones

A lo largo de unas 50 entradas y 23 versiones del proyecto, hemos desarrollado paso a paso un juego clásico en ensamblador.

Las principales conclusiones que saco del proceso son:

• No es suficiente con saber ensamblador del 6510. Además, hay que dominar el mapa de memoria y el hardware del C64. Un buen conocimiento de los chips especiales (VIC, SID y CIAs) es fundamental. Y también del Kernal, aunque no tanto.
• Es muy importante que el proceso de desarrollo sea paso a paso o incremental. Hay que empezar por lo más sencillo y nuclear, e ir completándolo poco a poco. No parece viable obtener un producto completo de forma directa, especialmente si es complejo.
• Interesa usar herramientas modernas como CMB prg Studio y VICE. Ni me quiero imaginar cómo podría ser la tarea si se intentara directamente sobre un C64.
• Disponer de unas librerías de programación para sprites, sonido, entrada / salida, etc., también es muy importante para ser eficientes. Si el programador no dispone de ellas, siempre puede desarrollarlas y mejorarlas con cada juego.
• Hay que plantearse retos asumibles. Y luego ir subiendo el listón. No vamos a sacar “Uridium” a la primera.
• El código tiene que estar debidamente estructurado. No podemos tener un único fichero “asm”. Tiene que haber varios ficheros, y estos tiene que ser autocontenidos. Como decían los clásicos “alta cohesión y bajo acomplamiento”.
• Los juegos suelen tener una inicialización y una actualización. La inicialización es el código que prepara el juego; por tanto, se ejecuta una vez. La actualización es el código que se ejecuta en cada ciclo del bucle de juego. Se utiliza para leer joystick y/o teclado, actualizar posiciones, disparar, detectar colisiones, hacer animaciones, reproducir sonido, etc.
• El concepto de bucle de juego es muy importante también. El bucle de juego es la ejecución de las actualizaciones. Se ejecuta repetitivamente hasta que el juego termina. Hay tareas que se pueden ejecutar completas en cada ciclo, y otras tareas que hay que ejecutarlas a lo largo de varios ciclos porque, si las ejecutáramos en un único ciclo, serían imperceptibles o para hacerlas perceptibles dejarían el juego “enganchado”.
• El ensamblador es tan rápido que hay tareas que, para que se puedan hacer bajo control, tienen que ser ralentizadas. Algunos ejemplos son los movimientos de la nave o los disparos. Esta ralentización se suele hacer mediante un “retardo”.
• Es mejor hacer las cosas bien desde el principio, que corregir los errores en una fase tardía del proyecto, cuando el diseño ya está muy avanzado. No obstante, somos humanos y nos equivocaremos. Al menos, aprendamos de los errores.
• Salvo que venga muy a cuento, no pongáis información en la zona derecha de la pantalla. Dejad que los sprites se muevan en libertad.
• Tenemos sprites, caracteres personalizados y bitmaps. Cada cosa tiene su uso. Los sprites son limitados, sólo tenemos ocho. Hay que hacer un uso razonable de los recursos.
• Las fórmulas matemáticas son un horror en ensamblador. Es mucho más sencillo usar tablas de datos. Y CBM prg Studio tiene un “data generator”.
• Os encontraréis situaciones imprevistas como letras que desaparecen de la pantalla, asteroides que siempre se expanden, programas que se cuelgan, explosiones inesperadas, etc. Hay que estar preparado para ellas e investigarlas. Esto os consumirá mucho tiempo y esfuerzo.
• Con frecuencia lo perfecto es enemigo de lo bueno. Quizás los disparos podrían estar más centrados respecto a la nave, pero, ¿cuánto me costaría hacerlo perfecto? Si la nave mirara siempre en la misma dirección podría resolverlo con relativa facilidad, pero admite ocho direcciones. ¿Estoy dispuesto a asumir el coste de hacerlo perfecto? ¿Hay alguna solución subóptima?
• Es importante reutilizar ideas e intentar ser coherentes en los diseños. Si los asteroides son una mezcla entre la nave y los disparos, porque son sprites como la nave, pero los hay activos e inactivos como los disparos, pues no reinventemos la rueda.
• Es interesante meter niveles de dificultad progresivos. Hay recursos para generar información pseudoaletoria (relojes del sistema).
• La detección de colisiones, ya sea sprite – sprite o sprite – texto no es sencilla. Con frecuencia implicará el uso de las posiciones para averiguar con precisión quién choca con qué.
• La animación de explosiones, igual que la reproducción del sonido, son ejemplos típicos de tareas que interesa extender a lo largo de varios ciclos del bucle de juego.
• Los juegos no sólo tienen la pantalla de juego (la obvia). También tienen pantallas de carga, pantallas finales, pantallas de puntuación y records, etc. Diseñar las diferentes pantallas es fácil, pero la correcta transición entre ellas puede tener algo más de miga.
• Lo normal es que los juegos se puedan jugar varias veces seguidas en una “sesión de partidas”. Cuidado con las inicializaciones en este caso, especialmente si confías en la inicialización implícita de las variables mediante directivas “byte” y similares.
• El SID es complejillo. El manejo de librerías simplifica mucho. Y el uso de tablas para separar música o sonido de programación también.
• A los humanos nos gustan los números en base diez. La solución obvia, que sería usar codificación y aritmética BCD, no siempre es viable. Siempre está la opción de usar codificación y aritmética binarias, y convertir a BCD antes de imprimir los datos.
• A programar se aprende programando, y sufriendo en tus carnes los errores. Y disfrutando mucho con el proceso y el resultado, claro.

Así que, lo dicho, espero que hayáis disfrutado mucho del proceso y, sobre todo, que os sirva de inspiración para vuestros propios proyectos.