ZONA DE PRUEBAS

EL JUEGO
Basado en un juego de mesa, aparentemente inventado en Francia durante el siglo XVII por un noble encarcelado en La Bastille. Hay diferentes variantes respecto a la forma del tablero y el número de casillas.

En esta versión el tablero se compone de 45 casillas, ocupadas todas por una ficha, excepto la central.
Mediante una serie de movimientos se van eliminando las fichas, hasta dejar una única ficha que debe ser la que estaba vacía al principio de la partida.
Los movimientos consisten en hacer saltar una ficha sobre una de las adyacentes siempre que a continuación la casilla esté vacía. En este caso hay que eliminar la ficha sobre la que hemos saltado.

El movimiento se indica introduciendo 4 valores numéricos comprendidos entre el 1 y el 9:
- Fila inicial / Columna inicial / Fila destino / Columna destino

En esta versión no se detecta el final de partida o la imposibilidad de poder realizar más movimientos.

Descargar el juego en formato ".p":


BLOQUES
He dividido el listado en 3 bloques:
- Impresión del tablero.
- Introducir la tirada y comprobar el tipo de movimiento a realizar.
- Comprobar si el movimiento es correcto y actualizar las fichas.


COMO FUNCIONA
A continuación detallo, línea por línea, el funcionamiento del programa.

Se utilizan las siguientes variables:
A$ - Entrada del movimiento.
F – Variable numérica para bucles.
A – Variable numérica coordenada vertical inicial.
B – Variable numérica coordenada horizontal inicial.
C – Variable numérica coordenada vertical destino.
D – Variable numérica coordenada horizontal destino.
Y - Variable numérica de incremento vertical.
X - Variable numérica de incremento horizontal.

8 – Guardamos el valor 2 en la variable “T”. Se usará a lo largo del programa y permite ahorrar memoria.
10 – Muestra el valor de las columnas.
12 – Inicio del bucle que dibuja el tablero.
14 – Guarda en la variable “B” el valor del tipo de la fila del tablero. Hay 3 diferentes.
16 – Imprimir el número de la fila y la fila del tablero.
18 – Final del bucle que dibuja el tablero.
20 – Introducir la tirada del jugador.
21 – Si la longitud de la tirada es distinta de 4 se vuelve a la línea 20.
22 – Guardar en la variable “A” el valor de la coordenada vertical inicial.
24 – Guardar en la variable “B” el valor de la coordenada horizontal inicial.
26 – Guardar en la variable “C” el valor de la coordenada vertical de destino.
28 – Guardar en la variable “D” el valor de la coordenada horizontal de destino.
30 – Guardar en la variable “X” el valor 0.
31 – Guardar en la variable “Y” el valor de “X” (es 0).
32 – Comprobar si el movimiento es horizontal, guardando en “X” la diferencia entre las casillas de inicio y de destino.
34 – Comprobar si el movimiento es vertical, guardando en “Y” la diferencia entre las casillas de inicio y de destino.
36 – Si el movimiento horizontal y vertical es distinto de 2, se vuelve a la línea 20.
38 – Si el valor absoluto de “X” es igual a 2, guardar en X el signo del movimiento. Negativo=Izquierda, Positivo=Derecha.
40 – Si el valor absoluto de “Y” es igual a 2, guardar en Y el signo del movimiento. Negativo=Arriba, Positivo=Abajo.
42 – Inicio del bucle que comprueba que la tirada sea correcta y que actualiza el tablero.
44 – Si el valor del bucle es distinto de 1 y de 4 se salta a la línea 50.
46 – Guardar en la variable “C” el valor de la variable “A”.
48 – Guardar en la variable “D” el valor de la variable “B”.
50 – Situar el cursor en la posición C (vertical) / D (horizontal).
52 – Si “F<3” comprueba si en la pantalla hay la secuencia de caracteres para considerar que el movimiento es correcto, sino pone el valor de “F” a 9 para romper el bucle.
56 – Incrementa el valor de “C” con el valor de “Y”, que puede ser (-1, 0, 1).
58 – Incrementa el valor de “D” con el valor de “X”, que puede ser (-1, 0, 1).
60 – Si el valor del bucle “F” es distinto de 9 imprime el carácter que debe haber en esa posición de la pantalla.
62 – Final del bucle de comprobación.
64 – Saltar a la línea 20 para introducir una nueva tirada.


EL PROGRAMA


APUNTES FINALES
El verano es una época que invita a salir por las noches, lo que me deja poco tiempo libre para estar con mis equipos retro.

Revisando mi colección de juegos de ingenio encontré una versión del solitario hecha de madera, perteneciente a una colección de fascículos.

Lo usé un rato y pensé que sería interesante crear una versión para jugar en el ZX-81. En Internet vi que existe una versión de 16K, pero la mía debía caber en 1K. Aparentemente sencillo hasta que ves que es más complicado de lo que parece, y que la poca memoria RAM se consume...


UN SOLITARIO EN 1K
A falta de tiempo libre he usado el emulador “EightyOne” en mis viajes al trabajo en tren, y la verdad es que en poco más de 2 horas el juego estaba completamente finalizado.

Desarrollar este juego ha sido un nuevo reto ya que inicialmente parecía muy simple, pero la cosa se ha complicado cuando has de validar el movimiento y actualizar el tablero, y esto consumía los 600 bytes disponibles, con el consiguiente error 4 de memoria llena.

El programa se divide básicamente en tres partes:

1. Dibujar el tablero
Esta parte ha sido fácil de desarrollar a pesar de que hay 3 tipos de filas distintas en el tablero: 3 bolas, 9 bolas y el de 8 bolas de la fila central. Con 5 líneas de código, tema resuelto, estando la clave en las filas 14 y 16.

La línea 14 nos devuelve un valor 1, 10 ó 19 en función de la cadena que indica el tipo de fila a imprimir, y la línea 16 contiene otra cadena con los tres tipos de fila, en grupos de 9 caracteres. El valor de “B” indica la posición inicial de la cadena a imprimir, más los siguientes 8 caracteres.

2. Validar el movimiento
Esta segunda parte ya ha dado más guerra ya que aquí hay que hacer parte de la validación de la tirada, y detectar el tipo de movimiento: vertical/horizontal y dirección.

Lo primero es introducir la tirada en la línea 20 y validar en la línea 21 que este valor se compone de 4 caracteres, dando por seguro que se han introducido números. A continuación se guarda el valor de cada dígito en una variable (líneas 22 y 28) y se inicializan las variables X e Y que guardan el incremento horizontal y vertical (líneas 30 y 31).

En las líneas 32 y 34 comprueba si las coordenadas verticales y horizontales de inicio y destino son iguales. En caso afirmativo guardamos la distancia entre las otras dos coordenadas. En 36 comprobamos que la distancia absoluta (sin signo) sea igual a 2. Y en 38 y 40 miramos que si el valor absoluto de estas distancias vertical u horizontal es igual a dos, nos guarde el signo del valor en esa variable (-1, 0, 1).

3. Actualizar el tablero
Esta parte es la más complicada ya que primero hay que comprobar que la ficha seleccionada saltará por encima de otra y caerá en una casilla vacía, y a continuación se deben actualizar las fichas del tablero. En un principio este proceso se componía de dos bucles que contaban de 1 a 3, pero como daba errores de memoria lo he conseguido meter en un único bucle que cuenta de 1 a 6.

Si el contador del bucle “F” es distinto de 1 y 4 saltamos a la línea 50, en caso contrario guardamos en las variables “C” y “D” la posición inicial de la ficha a mover, y en la línea 50 ponemos el cursor en la posición de esas dos variables, que “casualmente” coincide con su posición en la pantalla.

Si el contador es menor o igual a 3 comprobamos en la memoria de video si el estado de cada una de las tres posiciones es la correcta, o sea “ficha-ficha-vacía”, y si se detecta un error pone el valor del bucle a 9 para salir en el NEXT de la línea 62. A continuación avanzamos la posición a comprobar con los incrementos de las variables “X” e “Y”.

Para terminar imprimimos en la posición correspondiente el estado correcto. Se ha hecho de esta manera para ahorrar memoria ya que realmente esta condición solo se debería ejecutar a partir del valor del bucle 4, y siempre que “F” sea distinto de 9 (error detectado).

Para terminar
Esta vez he apostado por una mejor legibilidad del programa con lo que he evitado la instrucción CODE y he optado por definir los valores numéricos mediante VAL.

Hay artículos en los que se comentan las estrategias que hay para solucionar el juego en sus múltiples variantes, consistente en agrupar las fichas en zonas con una forma concreta y aplicar unos movimientos determinados para solucionar cada una de las zonas, todo ello en un orden concreto.
Con todo, el programa funciona perfectamente, así que… prueba superada ¡!!

Os invito a probarlo…

screen_2.gif (3 KiB) Visto 8214 veces

screen_3.gif (2.82 KiB) Visto 8214 veces

screen_4.gif (2.65 KiB) Visto 8214 veces

…con el siguiente regalito…

¡Qué chulada! Preguntas:
- Con el diagrama de la última página no me aclaro al 100% pero... los movimientos de "comida" de fichas son iguales que en las damas, ¿no?
- Este programa usa PEEKs a unas direcciones determinadas, que parecen ser de la pantalla. ¿Significa eso que si se cambia el programa lo más mínimo deja de funcionar bien? ¿Funciona en un ZX81 con ampliación de 16K? (corrijo: vale, es la dirección de una variable del sistema, no influye)

mcleod_ideafix escribió:- Con el diagrama de la última página no me aclaro al 100% pero... los movimientos de "comida" de fichas son iguales que en las damas, ¿no?

Es muy simple. Comienza en una ficha y acaba donde acaba la línea. A veces se come una ficha y a veces va encadenando saltos y se come varias del tirón. Yo lo he seguido y realmente funciona.

mcleod_ideafix escribió:- Este programa usa PEEKs a unas direcciones determinadas, que parecen ser de la pantalla. ¿Significa eso que si se cambia el programa lo más mínimo deja de funcionar bien? ¿Funciona en un ZX81 con ampliación de 16K? (corrijo: vale, es la dirección de una variable del sistema, no influye)

Pues tu te has autorespondido.

Consulta la posición de memoria donde está el cursor, a través de las variables del sistema, en el que te has situado con un PRINT AT.
De esta forma funciona en cualquier ZX-81, tenga la cantidad de memoria que tenga.

Bueno, pues aquí va mi pequeña aportación a este Solitario de dancresp.

La cosa es que lo de usar variables del sistema para ver dónde se ha impreso lo último me pareció que echaba por tierra los esfuerzos por mantener el programa legible (ya sabes, todo eso de usar NOT PI en lugar de 0 o INT PI en lugar de 3, por ejemplo). Por otra parte, quería que cuando el jugador lograra su objetivo, el programa terminara.

Así que mirando el código original vi que la rutina de impresión era un poco más compleja de lo habitual, y pensé que eso estaba gastando bytes, y que una rutina en la que se imprime una cadena a cachos, como ha hecho Dani en algún que otro juego, debería funcionar igual de bien.

Ahora que claro, esto significa tener en una cadena una copia del tablero, y eso se come también mucha memoria. Es más, el tablero estaría triplicado: una en el propio código, otra en la variable, y otra en la pantalla.

Aun con todo ese despilfarro de memoria, me atreví a re-escribirlo basándome en guardar el tablero en una variable, y, bueno, creo que lo he conseguido (aunque quizás no es mucho más legible que el original, o incluso menos). Por otro lado, algunos de los cálculos que en el programa original se necesitan para validar el movimiento y detectar su sentido y dirección, con el uso de una variable contenedora del tablero, se simplifican muchísimo, como vereis.

Además, como valor añadido, esta versión detecta cuándo se ha terminado correctamente la partida, finalizando el programa. También se puede jugar a otras versiones de este solitario sin más que cambiar el valor inicial de T$ con la única condición de que el tablero siga siendo de 9x9 casillas, y el valor inicial de X para indicar cuántas casillas hay que vaciar.

El juego: Solitario 1K versión McLeod

Este es el listado:


Se puede apreciar que es más cortito que el de dancresp. Ocupa 24 líneas BASIC. Las variables que se usan son:

T$ : el tablero. Cadena de la friolera de 81 caracteres, que se inicializa con el tablero completo. Se va actualizando a medida que progresa el juego.
O : guarda el valor 1
T : guarda el valor 2
N : guarda el valor 9
X : contador de piezas "comidas". Empieza siendo 43, y se resta uno en cada tanda. Cuando esta variable vale 0 y además la ficha del centro es una O, el juego termina (línea 12)
G : tiene dos funciones esta variable: se usa como contador del bucle que pinta el tablero, y después toma el valor fijo 14 que se usa como destino de GOTO para repetir una entrada cuando se ha detectado que no es correcta.
A$ : movimiento del usuario. Mismo formato que el programa original.
I : posición dentro de T$ de la casilla con la ficha que queremos mover
J : posición dentro de T$ de la casilla a donde queremos mover la ficha

Las líneas 1 a 5 son inicialización, y sólo se ejecutan una vez en toda la partida.
Las líneas 6 a 12 contienen la rutina de impresión del tablero y chequeo de fin de partida.
Las líneas 14 en adelante piden la jugada al usuario, la validan y actualizan el tablero en consecuencia, o piden repetir la jugada si no es legal.

Saber si la jugada es legal consiste en mirar si en la casilla de posición I hay una "O" y en la de posición J, un "." . Si no es así, repetir la tirada (línea 30)

Luego tengo que saber si las dos casillas están separadas entre sí por una única casilla, y no varias. Eso se hace comprobando cuánto vale el valor absoluto de I-J. Debe valer, o bien 2 (casillas en la misma línea horizontal separadas entre sí por una única casilla) o bien 18 (casillas en la misma línea vertical separadas entre sí por una única casilla). Si no vale ninguno de estos dos valores, repetir la tirada (línea 32)

Por último, para dar por legal la jugada, tengo que saber si la pieza que está en la casilla que se encuentra entre las dos que ha elegido el jugador contiene una "O". La posición de esa casilla es la media de las posiciones de las casillas elegidas, o sea (I+J)/2. Si ahí no hay una "O", se repite la jugada (línea 38)

En las líneas 40 a 46 se actualiza la variable T$ moviendo la ficha. En la 48 se actualiza X, el contador de fichas comidas, y por último, volvemos un poco más arriba a pintar de nuevo el tablero. Justo después de pintarlo es cuando se comprueba si X es 0 y si la casilla central (la de posición 41) contiene una "O". Si es así, se termina el juego.

Hombre mcleod, una de las gracias de la programación es que permite llegar a un mismo resultado de muchas formas distintas, pero no tengo ningún problema en reconocer que tu versión me parece más "correcta" que la mía, aunque en algún punto es algo más confusa, especialmente la parte más del final.

Yo opté por el tema de usar la memoria de vídeo para ahorrarme la memoria que ocupa el tablero las tres veces que comentas: listado, memoria de variables y memoria de vídeo porque estaba "casi" convencido que no cabría el programa en 1K. Pero viendo tu programa está claro que no solo cabe, sino que encima es más corto.

Vale, la próxima vez prometo hacerlo mejor...

Como decía en el post anterior, una de las gracias de la programación es que no hay una única forma de hacer las cosas, y por norma general unas soluciones son más correctas que otras.

Mi planteamiento inicial era incorrecto, pensando que no cabría en 1K y eso ha viciado todo el desarrollo, pero la versión de mcleod me ha hecho ver que el juego podía tener un planteamiento mucho más sencillo.

Como todavía tengo mucho que aprender... ... he estado probando la versión y he visto que no solo es más rápida que la mía sino que encima detecta el final de los movimientos.

Así que he estado analizando la versión de mcleod y me he tomado la libertad de reducir tres líneas, quedando en solo 21.
La verdad es que no me había pensado nunca que pudiera quedar tan "cortito", y creo que se puede recortar algo más...

Os dejo el listado de esta nueva versión en el que he modificado lo siguiente:
- Línea 6: He quitado el CLS y lo he sustituido por un PRINT AT, de forma que el tablero se redibuja sin borrar la pantalla, lo que queda como "más suave".
- He desplazado las líneas 7 a 12 hasta 9-13, de forma que el GOTO de la línea 58 lo hace a "N" y así ahorro algo de memoria.
- He anulado la línea 38 y la he fusionado con la 30 de forma que la comprobación de las fichas del tablero queda más compacta.
- Y para terminar he quitado la línea 13 y he sustituido los GOTO G de las líneas 16, 30 y 32 por un GOTO CODE ":" que hace lo mismo.

Un saludo, y a ver quien consigue recortarlo más !!!

Ah! Estupendo! PRINT AT NOT PI, NOT PI; ¿Cómo no se me ocurrió? La verdad es que casi siempre me olvido de que el ZX81 dispone de PRINT AT.

Una cosita: se supone que el juego termina correctamente cuando el jugador se come todas las fichas Y la ficha que se queda solita en el tablero lo hace en el centro del mismo. Esa segunda condición la tenía incluida en mi versión, pero en ésta recortada ha desaparecido (???)

Pregunta: ¿no sería posible fusionar las condiciones de las líneas 30 y 32 en un único IF? Algo como:


Pregunta 2: cuando el juego se ejecute en memoria, habrá que reservar memoria para todas las variables según se vayan creando. Puede ahorrarse un poquito de memoria en tiempo de ejecución si reutilizamos la variable I para que sea al principio el índice del bucle de impresión, y luego la variable que indica la posición de la pieza inicial a mover. No se reduce la legibilidad, ya que "I" es un nombre de variable muy típico para los bucles

ENHORABUENA POR OTRO PEDAZO EXCELENTE POST+PROGRAMA

(¿Cual será el siguiente?)


(En su momento -cuando salieron los coleccionables de puzzles de madera- hice mis versiones Palm/PPC):

mcleod_ideafix escribió:Una cosita: se supone que el juego termina correctamente cuando el jugador se come todas las fichas Y la ficha que se queda solita en el tablero lo hace en el centro del mismo. Esa segunda condición la tenía incluida en mi versión, pero en ésta recortada ha desaparecido (???)

Lo quité ya que si solo queda una ficha, sea en la posición que sea, lo mejor es que se detenga el programa ya que no podrás realizar más movimientos.

mcleod_ideafix escribió:Pregunta: ¿no sería posible fusionar las condiciones de las líneas 30 y 32 en un único IF? Algo como:

Código: Seleccionar todo

30 IF T$(I)<>"O" OR T$(J)<>"." OR T$((I+J)/T)<>"O" OR (ABS(I-J)<>T AND ABS(I-J)<>N*T) THEN GOTO CODE ":"

Hecho !!!

Lo había pensado pero como teclear líneas largas en el ZX-81 es bastante incómodo...

mcleod_ideafix escribió:Pregunta 2: cuando el juego se ejecute en memoria, habrá que reservar memoria para todas las variables según se vayan creando. Puede ahorrarse un poquito de memoria en tiempo de ejecución si reutilizamos la variable I para que sea al principio el índice del bucle de impresión, y luego la variable que indica la posición de la pieza inicial a mover. No se reduce la legibilidad, ya que "I" es un nombre de variable muy típico para los bucles

Pues no solo he anulado el uso de la variable "G", sino que también me he cargado la variable "O" ya que solo se usa 5 veces y ocupa más la línea (10 bytes) que repetir el "SGN PI" en esas cinco posiciones (5 bytes de más) más lo que ocupa en la zona de variables (7 bytes si no recuerdo mal).

También he hecho alguna pequeña modificación más a la hora de dibujar el tablero y al usar ciertos valores.

Total que ha quedado una versión de 19 líneas y 444 bytes, que funciona rápida y a las mil maravillas !!!

Me encantan estos piques de darle una vuelta mas al tornillo, enhorabuena y gracias a los dos, se aprende un huevo con estos posts...