Práctica de Programación

Bingo

Versión: 1.0
Curso 22/23

Enunciado:
Escribe un programa en Pascal para jugar al bingo siguiendo todas las indicaciones hechas a conti-
nuación. En el juego hay tres jugadores y cada jugador obtiene una serie de cartones en los que hay
líneas con números. Cada línea puede ser de un color diferente. Inicialmente, cada jugador obtiene un
número dado de cartones (fase de configuracion), tras lo cual se obtienen bolas de un color determi-
nado con un número dibujado en cada una (fase de extracción). Gana el juego el primero que ve que,
en uno de sus cartones, todos sus números han salido (cada número debe ser del color adecuado
como se explica luego).

Fase de configuración
• Hay tres jugadores, cada uno con un número dado de cartones.
• Un cartón es una cuadrícula de casillas con filas y columnas. Hay tres filas por carton y cinco
números en cada fila. Cada una de las filas tiene un color que puede ser Rojo, Verde, Azul o Amari-
llo. Los números son enteros positivos no mayores que 100.
• El programa debe leer todos los datos de un fichero llamado datos.txt que utiliza como entrada. No
debe leer en ningún momento de la entrada estándar.
• Al comienzo de la ejecución, el programa debe leer de la entrada (datos.txt), primero, los cartones
del jugador uno, luego, los del dos, y por último, los del tres (ver epígrafe siguiente).
• Los datos relativos a los cartones de un jugador consisten en una serie de cartones (uno o más de
uno). Cada cartón está especificado por, para cada una de las líneas del carton, un color y cinco
números. La serie de cartones se termina cuando se encuentra en la entrada la palabra FIN.
• Puede haber cualquier número de caracteres blancos (espacios, tabuladores y fines de línea) entre los
diversos datos de la entrada. Por ejemplo, no puede suponerse que cada línea de un cartón está en
una línea de la entrada o que la palabra FIN está sola en una línea.
• Se puede suponer que siempre hay un blanco (espacio, tabulador, fin de línea) o el fin de fichero tras
un color y tras cada número.
• No puede haber blancos separando las letras de FIN o de colores o números.
Por ejemplo, estos podrían ser los datos relativos a los cartones del jugador 1:
rojo 3 2 10 12 8
verde
3 2
10
12 32 amarillo 3 4 5 2
50 FIN

Esta entrada corresponde a un sólo cartón. La primera fila es roja y tiene los números 3, 2, 10, 12 y
8. La segunda es verde y tiene los números 3, 2, 10, 12 y 32. La tercera es amarilla y tiene los
números 3, 4, 5, 2 y 50.
 -2-

Fase de extracción
• Una extracción de una bola consiste en tomar una bola (de un color, con un número dibujado) de un
bombo. Una bola se representa por un color (Rojo, Verde, Azul o Amarillo) y un número (entre 1 y
100, inclusive).
• El fichero datos.txt, tras los datos de los cartones de los jugadores, debe contener una serie de
extracciones para la partida. Igual que para los cartones, entre los datos de las extracciones puede
haber un número indeterminado de espacios, tabuladores o fines de línea. Por ejemplo, la siguiente
secuencia de extracciones
rojo 3 verde
50

amarillo
7

representa que se han obtenido tres bolas. La primera era roja y tenía el número 3. La segunda era
verde, número 50. La tercera amarilla, número 7.
• Después de configurar los cartones de los jugadores, el programa debe leer del fichero datos.txt las
extracciones hasta que gane uno de los jugadores o se acabe el fichero.
• El número de extracciones en la entrada tal vez sea cero.
• Podrá suponerse un máximo razonable para el número de extracciones, aunque se valora si el número
de extracciones puede ser potencialmente ilimitado (esto es, se utiliza una lista enlazada para imple-
mentar este punto).
• Antes de cada extracción, el programa tiene que escribir por su salida estándar los cartones de cada
jugador. Para cada cartón hay que escribir una línea con el número de cartón y número de jugador y
luego una línea de texto por cada línea. La línea debe comenzar por el nombre del color y seguir con
los números de dicha línea separados todos por un espacio en blanco. Los números han de escribirse
ordenados. En cada cartón deben aparecer como "XX" los números que han salido durante las
extracciones hasta ese momento (se entiende que el color ha de coincidir para que se considere que
un número ha salido). Este ejemplo muestra el formato de un posible cartón tal y como aparece
durante una partida:
Jugador 1 Carton 3
amarillo 3 5 12 XX 58
rojo 13 15 XX XX 58
rojo 13 15 24 42 58

• Después de una extracción, el programa debe notificar a cada usuario el resultado de la misma, escri-
biendo por su salida estándar unas líneas con este formato:
Jugador 1: Nada.
Jugador 2: Nada.
Jugador 3: Tachado.

El resultado de una extracción puede ser Nada, Tachado, o Bingo según el número no esté en ningún
cartón del jugador, o el número esté, o el número esté y complete un cartón con todas los números
tachados. Se recuerda que se considera que el número está si coincide tanto en valor numérico como
en color.

Fin del juego

• Cuando después de una extracción (tras informar del resultado de la misma según el punto anterior),
un jugador consiga tener todos sus números tachados en alguno de sus cartones, se considera que este
jugador ha ganado y el juego termina. Nótese que esto implica que no debe leerse nada más del
fichero de entrada (por ejemplo, las extracciones que pudieran seguir) una vez termina el juego.
 -3-

Como consecuencia, no es posible leer todas las extracciones primero y procesarlas después. Hay que
hacerlo extracción por extracción.
• Si en una misma jugada varios jugadores consiguen un bingo, se considera un empate para todos los
jugadores.
• Si se acaba el fichero de datos y no hay un ganador, se considera que el juego termina en empate.
• Al final de la ejecución (tras el empate o la victoria de un jugador) el programa debe imprimir en su
salida estándar todas las extracciones efectuadas con el siguiente formato y un mensaje final indi-
cando el resultado del juego. Por ejemplo:
Rojo 3
Verde 52
... y otras muchas extracciones de este estilo ...
Rojo 13
Ganador: Jugador 1

Otro ejemplo podría ser este:

Verde 52
Empate

Restricciones de la implementación
• Como habrá podido deducirse del enunciado, la entrada debe ser correcta (salvo detalles menciona-
dos en los puntos anteriores de este enunciado). No obstante, se valora procesar correctamente fiche-
ros de entrada que tengan errores. Por ejemplo, menos números de los que debe haber en una línea, o
más números. O, por ejemplo, una palabra en lugar de un número, o cualquier otro tipo de cosa que
pudiesemos escribir por error en la entrada. En este caso, si el error sucede en la fase de configu-
ración, el programa debe imprimir un mensaje informando de tal error y terminar de ejecutar sin
hacer ninguna otra cosa. Y, en este caso, si el error sucede en la fase de extracciones, debe escribirse
un mensaje informando del error y considerar que la fase de extracciones ha terminado (y hacer todo
lo que el programa debe hacer cuando las extracciones terminan).
• Se puede suponer un máximo para el número de extracciones, pero se valora considerar que el
número de extracciones puede variar desde cero hasta ser potencialmente ilimitado (esto es, utilizar
una lista enlazada para implementar esta parte).
• El programa debe cumplir todas las normas de estilo de la asignatura, utilizar correctamente procedi-
mientos, funciones, tipos de datos y estructuras de control (bucles, condicionales, etc.) para conside-
rarse limpio, y estar realizado en un único fichero fuente llamado bingo.p. De otro modo, podría lle-
gar a suspender aunque cumpla con el resto del enunciado.
• El programa no puede escribir por la salida estándar nada que no se especifique en el presente enun-
ciado. Todas las trazas tienen que ser eliminadas del programa antes de su entrega.
• El programa no puede leer datos de ningún fichero que no sea datos.txt y no puede escribir nada en
níngun fichero que no sea la salida estándar.
• El programa debe definir todos los tipos de datos necesarios, así como los subprogramas necesarios
para manipular elementos de dichos tipos.
• Se recuerda que el programa debe estar correctamente escrito y debe usar subprogramas y tipos para
solucionar los distintos subproblemas de los que se compone. Se recomienda empezar pensando en
las estructuras de datos y desarrollar el programa pensando en Top-Down e implementado y probando
Bottom-up.
• Si el programa no cumple correctamente todos los requisitos anteriores (no hace todo lo que tiene
que hacer) o su código no es legible, o no compila, se considerará que el programa no funciona
correctamente (lo que supone un suspenso en su evaluación).
 -4-

Opciones para mejorar

Se valorará:
1 Tolerar errores en la entrada. En este caso, si el error sucede en la fase de configuración, el programa
debe imprimir un mensaje informando de tal error y terminar de ejecutar sin hacer ninguna otra cosa.
Y, en este caso, si el error sucede en la fase de extracciones, debe escribirse un mensaje informando
del error y considerar que la fase de extracciones ha terminado (y hacer todo lo que el programa debe
hacer cuando las extracciones terminan).
2 Admitir un número potencialmente ilimitado de extracciones (esto es, utilizar una lista enlazada para
implementar esta parte).