Proyecto: USB Blackjack

Transcripción

1 Universidad Simón Bolívar Departamento de Computación y Tecnología de la Información CI-2691 Laboratorio de Algoritmos I Trimestre Enero-Marzo del 2007 Proyecto: USB Blackjack El objetivo de este proyecto es lograr que los estudiantes trabajen, de una forma guiada, en el desarrollo de un programa no trivial. 1. Planteamiento del Problema 1.1. Reglas y desarrollo del juego Para poner en práctica los conocimientos adquiridos en el curso de Algoritmos I se le pedirá realizar un programa que permita a un usuario jugar Blackjack con un computador. Se desea implementar una versión simplicada y ligeramente modicada del juego Blackjack. El Blackjack es un juego de cartas que consiste en obtener el puntaje más cercano posible a 21 con la sumatoria de los valores de las cartas, pero sin pasarse de ese valor. Las reglas y el desarrollo del juego es como sigue. Las barajas que poseen números aportan a la suma su valor, las que poseen guras (j,q,k) aportan el valor de 10, los ases aportan 1 y además se tienen 4 barajas comodín (una por cada una de las pintas) que suman 11. Al agregar las barajas de comodín, nuestro mazo contará con 56 cartas. El computador hará el papel de crupier 1. Al comenzar el jugador debe hacer una apuesta inicial no menor a un valor mínimo. Luego se reparten 2 cartas al jugador y al crupier. De las cartas repartidas al crupier, la primera es visible. Si la suma de las cartas del jugador da 21 entonces se considera blackjack y gana automáticamente y su apuesta será pagada a razón de 3 a 2, a menos que el crupier también tenga blackjack, en cuyo caso se le devuelve el dinero al jugador. Si el jugador no tiene 21 entonces tiene cuatro opciones: que son recibir una carta, plantarse, doblar y salir del juego. El jugador puede recibir una carta mientras la sumatoria de las mismas no sobrepase 21. Si al recibir una carta se pasa de 21 entonces perdió su apuesta. En el caso de que sus cartas sumen lo mismo que las del crupier hay un empate y recupera su apuesta. Si el jugador decide plantarse entonces le tocará el turno al crupier de hacer su jugada. El jugador puede doblar su apuesta si la sumatoria de sus 2 primeras cartas es igual a 9, 10, 11 y después de ese momento se le dará una carta más y hasta allí llega su turno. La opción salir del juego hace que la aplicación aborte y termine. El crupier se reparte el mismo las cartas. Mientras la sumatoria de sus cartas es menor o igual 16, entonces el puede recibir una carta más. Al llegar a 17 puntos o más el crupier deberá plantarse. Si la sumatoria de las cartas del crupier sobrepasa a 21 entonces el jugador gana. Si en este punto el valor de las cartas del jugador y del crupier no sobrepasan 21 entonces gana quien tenga la mano de cartas cuya sumatoria esté más cerca de 21 y se le paga al jugador a razón de uno a uno. Las reglas dadas anteriormente son un subconjunto de las reglas utilizadas habitualmente en los casinos. Hay dos sitios web que que sirven como ejemplo para mostrar la dinámica del juego, pero cuyas reglas son ligeramente diferentes a las aquí expuestas. Estos son: El crupier es es trabajador de los casinos que se encarga de repartir las cartas así como de recibir y pagar las apuestas y viene a representar al casino en el juego de blackjack. Se tiene que el crupier se apega a las reglas preestablecidas del casino por lo que su trabajo es mecánico, es decir, no tiene capacidad de deliberación 1

2 1.2. Requerimientos y características de la aplicación La aplicación a desarrollar debe interactuar con el usuario a través de una interfaz gráca y de una interfaz de texto. La interfaz gráca debe mostrar: Las cartas del crupier, en donde la primera está descubierta y las demás están cubiertas Las cartas del jugador El crédito disponible del jugador La cantidad apostada en la mano El valor de la primera carta del crupier El valor de las cartas de jugador La interfaz de texto debe cumplir los siguientes requerimientos Pedir el nombre al jugador al comenzar la partida Pedir al jugador, llamándolo por su nombre, el monto de la apuesta al comenzar cada una de las manos Muestra al jugador un menú con las opciones que puede ejecutar en su turno que son recibir una carta, plantarse, doblar y salir del juego Recibe la opción de la acción a ejecutar por el usuario Al comenzar el juego el jugador tendrá como crédito la cantidad de 1000 unidades. La apuesta mínima en cada mano es de 5 unidades. Si un jugador hace una apuesta con un monto inferior a 5 unidades o superior al crédito que dispone, la aplicación dará un mensaje de error y le volverá a pedir al usuario el monto de la apuesta. Al terminar una mano el programa deberá mostrar al usuario un mensaje con el resultado de la misma, es decir, indicará si el jugador perdió o gano. Este mensaje se puede hacer vía consola o con una interfaz gráca. Además se debe mostrar el valor y las cartas del crupier, el valor y las cartas del jugador y demás mensajes que crea necesarios para indicarle al usuario lo ocurrido en la mano. La aplicación debe permitir jugar a un usuario mientras tenga crédito disponible. Cuando el jugador intenta la opción de doblar sin cumplir los requerimientos para aplicar la misma, entonces se debe dar un mensaje de error al usuario y se debe volver a mostrar el menú de opciones. Si al repartir las dos primeras cartas el jugador hace blackjack, entonces el programa debe nalizar e indicar el resultado de la mano que va a depender de las reglas expuestas anteriormente. En la parte de la interfaz gráca se deben mostrar dibujos que representen unívocamente a cada una de las cartas. El usuario debe poder reconocer a simple viste las cartas visibles de la mano. No se le pide que haga un gráco detallado de una carta. En la gura 1 se muestra un ejemplo de como pueden ser dibujadas cartas utilizando guras y texto. La representación de la carta comodín se deja a su libre elección, solo recuerde que los cuatro comodines son diferentes Para hacer el USB Blackjack menos vulnerable a los contadores de cartas, se tendrá un número casi innito de barajas. Esto hace que en una mano a un jugador le puedan repartir cartas iguales. Su código debe ser hecho para que pueda ser entendido por seres humanos. Recuede que es importante la modularidad y el dividir el problema en varios más pequeños. La claridad del código, el estilo, la buena indentación, el nombre adecuado de las variables y los comentarios bien hechos tendrán un peso importante en la evaluación. 2

3 Figura 1: Dibujos de cartas hechos con texto y guras 2. Estructuras de datos sugeridas En el desarrollo de todo programa es importante decidir que estructuras de datos serán utilizadas para almacenar la información que el programa debe manejar. El mazo de cartas estará representado por arreglo unidimensional de 56 elementos del tipo String. Todos los elementos son diferentes y cada uno representa una carta del mazo. Otras estructuras importantes son las que representan a la barajas que poseen el jugador o el crupier en una mano. Estas pueden ser representados con arreglos de Strings. El tamaño del arreglo va a depender del número máximo de cartas que piense usted pueda tener un jugador en una mano. Si escoge arreglos para representar la mano de los jugadores justique en el informe el tamaño del arreglo Durante el juego es necesario llevar la cuenta de varios instancias que cambian según como se vaya desarrollando las acciones. Estas son el monto de la apuesta, el crédito del jugador, el valor de la mano del jugador y el valor de mano del crupier, las cuales se pueden representar con variables enteras. Las cartas a repartir deben tener cierto nivel de aleatoriedad. Para escoger al azar la carta a repartir podemos usar la acción random r que asigna a una variable r del tipo doble un valor entre 0 y 1. Luego este valor se puede convertir en entero usando la acción toint, de esta forma: toint(r*56). Con esto se obtiene un número entero entre 0 y 55, que va a ser la posición del arreglo, que representa al mazo, de la carta que se va a repartir a un jugador. Para la descripción detallada del funcionamiento de estas acciones visite las páginas web: Esquema de la solución algorítmica sugerida 3.1. Esquema de la solución general Un componente importante del programa es la parte gráca, la cual debe ser actualizada constantemente a medida que ocurren los eventos dentro del programa. En esta aplicación se recomienda tener separados los componentes que tienen que ver con la visualización del estado del juego (componente interfaz), con los componentes que representan el manejo de las estructuras de datos, como son los arreglos que contienen el mazo y las manos de los jugadores (componente lógica). Esto se hace con el n de tener el programa más estructurado. El diseño de la solución de la componente lógica lo hacemos aplicando el análisis descendiente, mediante el cual a un problema lo dividimos en varios subproblemas de menor complejidad. Un primer esquema de la solución general obtenido después de hacer el análisis descendiente lo vemos en la gura 2. Observando el esquema general de solución, tenemos que el subproblema Inicialización-de-variables corresponde a la inicialización con valores los adecuados de las 3

4 estructuras de datos y de las variables globales del programa. Luego comienza un lazo do od que tiene como función permitir a los jugadores realizar varias partidas mientras el jugador tenga crédito disponible y no haya escogido la acción de abortar. Si el jugador es lo sucientemente bueno esta iteración podría teóricamente no terminar jamás. En GaCeLa se exige que toda iteración termine, por lo tanto se tendrá que establecer una cantidad máxima de partidas que el jugador podrá realizar. Inicialización-de-variables do ( salir-juego) (crédito 5) Repartir-cartas-iniciales ; do n-mano Acciones-del-jugador ; Acciones-del-crupier ; Decisión-del-juego od; od Figura 2: Esquema general de solución Continuando con el análisis descendiente, el subproblema Repartir-cartas-iniciales consiste en la repartición de la dos cartas iniciales al los jugadores y en la presentación de la conguración inicial del juego. En la gura 3 se muestran las principales acciones que se efectúan en Repartir-cartas-iniciales. La acción mostrar-estado-del-juego, consiste en el despliegue de un componente gráco que muestre las dos cartas del jugador, la carta descubierta y la carta cubierta del crupier, el valor de la mano del jugador, el valor de la carta descubierta del crupier, el monto apostado y el crédito disponible. pedir-apuesta-al-jugador; repartir-2-catas-a-los-jugadores; determinar-valor-de-las-manos; actualizar-variables; mostrar-estado-del-juego Figura 3: Acciones de Repartir-cartas-iniciales Luego viene en el esquema general de solución una iteración que se realiza si no se ha nalizado la mano. Como en el caso de la iteración anterior usted deberá decidir una cantidad máxima de iteraciones permitidas, tal que sea mayor que la cantidad de jugadas que se puedan llevar a cabo durante el desarrollo del juego. El siguiente subproblema es Acciones-del-jugador para el cual en la gura 4 se muestran una serie de acciones que lo conformarían. En el subproblema Acciones-del-crupier se tiene como objetivo manejar las operaciones que debe efectuar el crupier, las cuales están sujetas a las reglas expuestas anteriormente. En la gura 5 el esquema sugerido para las Acciones-del-crupier. El último subproblema a tratar es el del Decisión-del-juego el cual tiene como n la determinación del ganador de la mano de blackjack así como el manejo que se debe hacer del componente gráco y de texto una vez nalizada una mano. En esta secuencia de acciones el componente gráco debe mostrar quien ganó la mano, el valor total de las de las cartas del jugador y del crupier así como las cartas ocultas del crupier y la información de lo ganado o 4

5 if jugador-hizo-blackjack gana-con-relación-3-a-2 [] puntos 21 mostrar-opciones; if pedir-carta dar-carta; actualizar-estado-del-juego [] jugador-se-planta actualizar-estado-del-juego [] jugador-dobla if puede-doblar dar-carta; actualizar-estado-del-juego [] (puede-doblar) manejar-error-usuario [] desea-salir manejar-salida [] ninguna-de-las-otras-opciones manejar-error-del-usuario [] puntos > 21 manejar-pérdida-del-jugador; actualizar-estado Figura 4: Solución algorítmica propuesta de Acciones-del-jugador if n-mano if puntos < 17 dar-carta; actualizar-estado-del-juego [] 17 puntos 21 skip [] puntos > 21 manejar-pérdida-del-crupier; actualizar-estado [] n-mano skip Figura 5: Solución algorítmica propuesta de Acciones-del-crupier 5

6 perdido en la partida. En la gura 6 se muestra una posible solución al subproblema if n-mano if puntos-jugador = puntos-crupier retornar-apuesta-jugador actualizar-componente-gráco [] puntos-jugador > puntos-crupier jugador-gana-con-relación-1-a-1 actualizar-componente-gráco [] puntos-jugador < puntos-crupier actualizar-componente-gráco ; n-mano := true [] n-mano skip Figura 6: Solución algorítmica propuesta de Decisión-del-juego 3.2. Funciones del programa En está sección se presentarán los encabezados de algunos procedimientos y funciones que tienen asociación con los subproblemas expuestos anteriormente Obtener monto de la apuesta La función obtenerapuesta tiene como nalidad el procesamiento de un monto de apuesta válido por parte del usuario. La función recibe como parámetro de entrada, el monto del crédito disponible y esto se debe a que el usuario sólo puede apostar un monto un mínimo de 5 unidades y un máximo de unidades igual al crédito que disponga. En caso contrario la aplicación da un mensaje de error y vuelve a pedir la apuesta al usuario. Para lograr este comportamiento la función obtenerapuesta cuenta en su interior con un lazo que itera mientras el usuario no introduzca una apuesta válida. El la gura 7 se presenta a la función fun obtenerapuesta:(in crédito: int) int {Pre...} {Post...} Figura 7: Función que toma una apuesta y retorna el crédito disponible Mostrar grácamente el juego El desarrollo del juego se seguirá a través del componente gráco. Por ello se propone un procedimiento llamado mostrarjuego, que se encargará de dibujar el estado del juego a medida que ocurren los eventos del mismo. Para todo el manejo gráco se usará las llamadas máquinas de trazados, que son objetos del tipo Screen en GaCeLa. El procedimiento recibe como entrada los datos mínimos que se deben mostrar. Estos son: el dinero apostado en la mano, el crédito, disponible del jugador, las cartas del jugador y del crupier, el valor de la mano del jugador y el valor de la carta o mano del crupier. Una llamada a este procedimiento debería efectuarse cada vez que ocurra un evento que cambie el estado del juego. La gura 8 presenta los parámetros del procedimiento. 6

7 proc mostrarjuego:(in scr: Screen, in apostado: int, in crédito: int, in numcartasjug:int, in numcartascrupier:int, in valormanojugador: int, in valormanocrupier: int, in manojugador:array[ ] of String, in manocrupier:array[ ] of String) {Pre...} {Post...} Figura 8: Procedimiento que dibuja el estado del juego Repartir una carta Una de las acciones que más frecuentemente se va a efectuar es el de repartir una carta. Por ello es importante contar con una función que se encarga de ese cometido. Se propondrá una función llamada darcarta que recibe como entrada la estructura de datos que contiene el mazo de 56 cartas y retorna una carta escogida aleatoriamente del mazo. La gura 9 muestra el encabezado de la función fun darcarta:(in mazo :array[ ] of String) String {Pre...} {Post...} Figura 9: Función que reparte una carta a un jugador Determinar el valor de una mano Una vez que se le han entregado las cartas a los jugadores es necesario determinar el puntaje numérico de las misma. Con este n se propone el procedimiento valormano que recibe la mano de un jugador, la cantidad de cartas que posee la mano del jugador y un parámetro de entrada y salida llamado puntosmano que contendrá el valor de la mano. Este procedimiento posee una iteración con la cual se examinaran los registros del arreglo mano para determinar que barajas posee y dependiendo de las mismas se van acumulando los puntos. En la gura 10 se muestra el encabezado del procedimiento proc valormano:(in mano: array[ ] of String, in númerocartasmano: int, in out puntosmano: int) {Pre...} {Post...} Figura 10: Procedimiento que determina el valor de una mano 4. Entrega de Avances y Entrega Final Durante las tres semanas que se tienen estipuladas para el desarrollo de este programa, se realizarán tres entregas: dos avances parciales y una entrega nal con el programa completo Primer Avance - Semana 9 (valor 10 puntos) Siguiendo el esquema general de solución propuesto, se deberá entregar un programa en Ga- CeLa que resuelva el subproblema Repartir-cartas-iniciales. El programa no debe terminar sino cuando un el usuario introduzca un carácter por la consola. 7

8 El código del programa deberá entregarse impreso a la hora del laboratorio y vía a su profesor respectivo. La ausencia de cualquiera de las dos entregas será motivo suciente para la anulación del avance 4.2. Segundo Avance - Semana 10 (valor 10 puntos) En la segunda entrega se deberá implementar un programa en GaCeLa que resuelva las especicaciones descritas en el esquema general de solución hasta el subproblema Acciones-del-jugador. Es decir, la entrega es una simplicación del programa nal en el sentido de que permitirá al jugador realizar todas las operaciones que le sean lícitas hacer en una mano. Una vez nalizada una mano el programa termina cuando el usuario introduzca un carácter por la consola. La estructura del esquema general de solución modicado para esta entrega se muestra en la gura 11 Inicialización-de-variables do ( salir-juego) (crédito 5) Repartir-cartas-iniciales ; do n-mano Acciones-del-jugador ; n-mano := true od; salir-juego := true od Figura 11: Esquema general de solución modicado para el avance 2 El código del programa deberá entregarse impreso a la hora del laboratorio y vía a su profesor respectivo. La ausencia de cualquiera de las dos entregas será motivo suciente para la anulación del avance 4.3. Entrega Final - Semana 11 (valor 20 puntos) La última entrega consiste en la versión nal del programa grababa en un disco compacto, como también el código impreso en papel. También se deberá entregar un informe con las siguientes secciones: Portada Debe incluir los nombres y los número de carnets de los integrantes del grupo, así como el nombre del profesor Introducción: Breve descripción del problema resuelto y del contenido del resto del informe Diseño: Descripción de las decisiones de diseño tomadas para la resolución del proyecto. Explicación de las estructuras de datos utilizadas. Especicación de los subprogramas claves de la componente lógica y de la componente de interfaz Detalles de implementación: Se deberá dar una lista de los procedimientos y funciones indicando la relación de invocación, así como una breve descripción de cada uno de ellos. También debe incluir peculiaridades de como se resolvieron en GaCeLa los subprogramas diseñados 8

9 Estado Actual del Proyecto: Se debe indicar el grado de operatividad del programa, es decir, si funciona perfectamente o no; en caso negativo de una descripción de los errores conocidos Conclusiones: Resultados obtenidos, dicultades presentadas, su visión sobre la experiencia que involucró el desarrollo del proyecto y cualquier otro aspecto que considere digno de mencionar Recomendaciones: Sugerencias que usted hace para que sean puestas en práctica en los próximos cursos de Algoritmos I Bibliografía La entrega nal se realizará en la hora de clase y se deberá entregar un disco compacto con el programa realizado y un sobre manila debidamente identicado que contendrá el código impreso del proyecto y el informe realizado. Es importante que el equipo trabaje de forma coordinada. El profesor podrá hacer un interrogatorio individual a cada integrante del equipo. 5. Consideraciones Finales Cualquier error que sea hallado en este enunciado, así como cualquier tipo de observación adicional sobre el proyecto, serán publicadas como fe de erratas en la página web del curso. Es responsabilidad de los alumnos revisar periódicamente si hay noticias nuevas o no No debe haber copia, ni intercambio de información especíca, ni ayuda detallada entre los equipos. El incurrir en cualquiera de las acciones descritas anteriormente tendrá como consecuencia sanciones severas 9