miércoles, 3 de marzo de 2021

Archer 10. Participación en el 2021 10-liner Contest


Hace algunas semanas tuve noticia de un concurso de programación retro, si, a través de uno de esos grupos de wasap, el 10th Edition of BASIC 10 Liner Contest. La idea principal es que tienes que desarrollar un juego en BASIC que no ocupe más de 10 líneas de código para cualquier ordenador original de 8 bits. Hay diferentes categorías dependiendo del número máximo de caracteres por línea permitidos. Sencillo, ¿verdad?. Decidí darle un tiento. Pensé "vamos, si son sólo 10 líneas de código, esto no puede ser muy complicado". No podía estar más equivocado. En este artículo explicaré qué y cómo he desarrollado mi participación en la edición de este año (2021), que he llamado Archer10.

El juego

Puesto que era la máquina con la que aprendí, decidí ir a por un programa MSX-1. Llamémosle nostalgia. Claro que, además, es la máquina que mejor conozco. Una vez decidido el equipo, la siguiente cuestión es pensar en un juego. Como no soy bueno en los juegos, decidí plagiarme yo mismo. Comencé con algunas ideas prestadas de Barcelona 92, un programa en BASIC que desarrollé cuando tenía 15 años y fue publicado en la revista MSX Club de Programas nº 3-4 (1985).

Después de algunas reflexiones-no-muy-profundas acabé con una idea sencilla de mecánica de juego: un blanco a la izquierda se mueve hacia arriba y hacia abajo. Controlas un arquero en la derecha que lanza flechas que se mueven de derecha a izquierda. Si impactas el blanco consigues puntos dependiendo de cómo cerca del centro lo haga. Tienes permitido un número máximo de fallos, tras los cuales el programa finaliza. Cuanto mayor sea la puntuación, mejor. Bien, bastante sencillo, pero un juego al fin y al cabo. Y presenta varias posibilidades que puedo explotar. Algo que no me gusta de muchos juegos es que son difíciles desde el principio. Como soy muy malo en los juegos, esto no facilita el que los pruebe. Así que decidí que el juego fuera sencillo al principio (el blanco se mueve muy despacio). Pero según se progresa, la dificultad se va incrementando poco a poco (al principio no se aprecia) de forma que tras algunos aciertos se torna realmente difícil. Y la restricción en el número de fallos hace que quieras repetir de nuevo e intentar superarte.

Estupendo. Ya tengo una idea de juego. Ahora a por la parte visual. Quería mostrar algunas de la estupendas características de los ordenadores MSX-1, por lo que decidí incluir gráficos en alta resolución (lo que se conoce como SCREEN 2 en el mundillo MSX), sprites por hardware, y sonido. Con profusión de colores, por supuesto (descargo de responsabilidad: no soy daltónico, pero definitivamente no soy bueno coloreando). Y, cómo no, también sonidos (descargo de responsabilidad: soy tan bueno con la música como con los colores).

La programación

Comencé programando una maqueta del programa sin restricciones, con un montón de líneas, para tenerlo funcionando. Quería asegurarme de que se pudiera jugar como yo quería. Después trabajé los gráficos para evitar la colisión de atributos de color (típico del procesador de vídeo de los MSX) y a la vez mostrar la mayor parte de la paleta de colores disponible. Básicamente tenía unas cien líneas de código y unas 3 Kb de espacio de programa. Definitivamente demasiado para un 10-liner.

Debido a los gráficos tenía claro que requeriría bastante espacio de programa. Además, mostrar texto en una pantalla gráfica requiere de muchas instrucciones que ocupan bastante espacio de programa. Y definitivamente quería texto. Sin compromisos.

De esta forma decidí participar en la categoría EXTREME-256. Además de sólo diez líneas de código, cada línea no debe de contener mas de 256 caracteres. De forma global ¡¡ el programa no puede ocupar más de 2.5 Kb !!. Para encajar el código en este tamaño hay que utilizar todos los viejos trucos. El intérprete BASIC utiliza un analizador léxico que está basado en la detección de palabras clave y no en los delimitadores. Esto significa que puedes escribir todo el código sin espacios. ¡¡¡ A quien le importa la legibilidad !!! Además, hay que usar variables con una sola letra y números de línea de un sólo dígito (después de todo, recordad, no puedes usar mas de diez :-).

Con esto consigues un código BASIC muy compacto, con la menor cantidad de espacio de almacenamiento posible. Esta es la parte fácil. Pero aún hay más, ya que hay que implementar la mecánica del juego que involucra acciones y decisiones. Cuando se programa tendemos a pensar en secuencias lógicas (o al menos eso deberíamos hacer) que acaban plasmándose en el uso de sentencias GOTO, y con el objetivo de mejorar la claridad, también GOSUB. El problema aquí es que debido al reducido número de líneas el uso de GOTOs y GOSUBs es muy limitado. Así que, en lugar de pensar en secuencias lógicas, donde tienes decisiones y acciones claramente aisladas, tienes que intercalar estas en el poco espacio disponible, incluyendo la mayor cantidad posible en una línea de código. Es un ejercicio de programación muy interesante que habitualmente no se practica.

El juego

Si digo que al final acabé con diez líneas de código, esto no debería ser una sorpresa. No hay spoiler. Las líneas 0 a 3 inicializan el programa y hacen todo el pintado del fondo gráfico y la definición de los sprites hardware. El orden en el que se realizan las instrucciones esta relacionado con el espacio disponible en las distintas líneas de código, paro lo que probé distintas combinaciones. Una cuestión interesante es que sólo se necesita la línea 3 para reiniciar el juego, de forma que se puede hacer un GOTO 3 cuando se acaba la partida.

Las líneas 4 a 7 implementan la mecánica del juego. Gestionan el movimiento del blanco y de la flecha, la interacción con el usuario y el puntaje. Tuve bastante suerte y pude implementar una subrutina en la línea 7, que se llama mediante un GOSUB 7 cada vez que la flecha llega a la parte izquierda de la pantalla (ya sea un acierto o un fallo). La línea 6 utiliza un truco muy interesante. Comprueba tanto el final de la partida como la reinicalización del juego (después de pulsar la barra espaciadora). Lo último mediante una llamada a GOTO 6. Esto produce una corrupción del estado del juego, pero como ya ha finalizado, ¡a quien le importa!. Cuando posteriormente se hace un GOTO 3 el estado del juego se inicia correctamente.

Las líneas 8 a 9 contienen las definiciones DATA para los sprites hardware codificados en hexadecimal. Debo señalar que esta NO es la forma más eficiente de almacenar esta información. Se pueden utilizar cadenas de caracteres, pero he sacrificado un poco de almacenamiento de programa (que al final no necesité) por la codificación de caracteres. Puesto que habitualmente desarrollo tanto en mi Mac como en mi Sony HB-F700S la copia entre estos preservando la codificación de caracteres es muchísimo mas simple así.

El estado del juego se codifica por medio de las siguientes variables:
  • Y (Float): posición vertical del blanco en pixeles. Varía en el rango 30 .. 135
  • S (Float): cantidad de pixeles que se le añaden/sustraen en pixeles a la Y en cada instante de tiempo. El valor uncial es 1,0. Cada vez que s produce un acierto se incrementa en 0,25.
  • X (Integer): posición horizontal de la flecha en pixeles. Varía en el rango 200 .. 22
  • G (Integer): puntuación total conseguida
  • F (Integer): número de fallos
  • H (Integer): puntuación del último acierto. Calculada como la distancia lineal entre la posición y de la flecha y la posición y del blanco. 
  • B (Integer): variable de estado que representa si la flecha está en movimiento (B=1) o no (B=0)
Finalmente conseguí un código de 2.1 Kb, en 10 líneas de código BASIC, y codificación de caracteres en ASCII estándar. ¡¡ Estupendo!!. Objetivo conseguido. Puedes descargar el código, un archivo de disco para simulador (DSK) y diverso material multimedia desde:


Instrucciones

Eres un arquero de alto nivel en la "Liga Mundial de Tiro con Arco al Aire Libre. Blanco Móvil". Lanzas flechas pulsando la barra espaciadora, y no puedes volver a lanzar hasta que aciertas el blanco o fallas. El blanco se mueve por lo que tines que sincronizar con cuidado el lanzamiento de la flecha con el movimiento del blanco. La velocidad del blanco se va incrementando con cada acierto. Consigues puntos según lo cerca que queda la flecha con respecto al centro del blanco. Tienes permitido un máximo de 3 fallos, en cuyo caso la competición finaliza y obtines tu puntuación final. Para iniciar un nuevo juego pulsa la barra espaciadora durante más de un segundo.

Estás listo? Puedes conseguir más de cien puntos? Vamos a ello.

Descarga el archivo archer10.dsk de GitHub y arrástralo a la consola azul de WebMSX (una aplicación estupenda de Paulo Augusto Peccin). Aparece una ventana emergente y entonces selecciona Drive A. A partir de ahí el simulador carga la imagen de disco y se queda a la espera de recibir comandos. Teclea el siguiente comando y después pulsa INTRO:

RUN "ARCHER10.BAS"

¿Demasiado complejo?

He preparado una página web que automáticamente carga y ejecuta el programa en WebMSX. Sigue este enlace para jugar en línea.

El juego tiene sonido, así que recuerda habilitar el audio en el ordenador.

¡¡¡ Disfruta jugándolo !!!




No hay comentarios:

Publicar un comentario