Ahorcado online multijugador

Transcripción

1 Ahorcado online multijugador Objetivo Que el alumno ponga en práctica los conocimientos teóricos y prácticos adquiridos en la Parte II de la asignatura de Programación Concurrente. La práctica podrá realizarse de forma individual o por parejas. Fecha y mecanismo de entrega La entrega se realizará el Viernes 29 de Enero de 2016 por el campus virtual. Se deberá entregar un.zip cuyo contenido será el proyecto eclipse en el que se ha realizado la práctica. Las carpetas src, target y el fichero pom.xml deberán estar en la raíz del fichero comprimido (no debe haber una carpeta practica o similar). El nombre del fichero.zip tiene que ser igual al identificador del alumno en la URJC (la parte antes de del correo electrónico del alumno en la URJC). En caso de dos alumnos, se incluirán ambos nombres separados por -. En el fichero pom.xml se deberá incluir el siguiente nombre del proyecto (donde nombre.alumno corresponde con el identificador del alumno o alumnos): <groupid>es.urjc.pc</groupid> <artifactid>nombre.alumno</artifactid> <version>0.0.1-snapshot</version> Además del envío del código, se realizará un examen oral de la práctica para que el profesor pueda verificar que ambos alumnos conocen el funcionamiento de la práctica entregada. Durante el examen los alumnos tendrán delante el código fuente de la práctica y se les pedirán explicaciones sobre el mismo y su ejecución. El examen se llevará a cabo el mismo día 29 de Enero de 12:00 a 14:00 y de 15:00 a 18:00. El aula está todavía por determinar y será notificada desde el campus virtual. Los alumnos seleccionarán la franja horaria en la que desean defender la práctica usando esta página web: dit?usp=sharing 1

2 Enunciado La empresa HappyPigs de desarrollo de videojuegos quiere desarrollar un juego ahorcado online multijugador. Para poder implementar este juego la empresa ha decidido realizar varias iteraciones. En cada iteración se irán incorporando funcionalidades a la iteración anterior. Esta forma de desarrollar aplicaciones es muy habitual en equipos de desarrollo profesionales porque permite tener versiones completas que enseñar al cliente en cada iteración. Además, también es una forma efectiva de organizar el trabajo. En el caso de HappyPigs, se van a realizar las siguientes iteraciones: Iteración 1 - Ahorcado monojugador offline: Esta primera versión del ahorcado sólo permite un único usuario y se ejecuta completamente en la máquina del jugador. Esto permite centrarse en la mecánica del juego y olvidarse de los detalles de red. Además, al existir un único usuario hace el código más sencillo de implementar. Iteración 2 - Ahorcado monojugador online: En esta segunda versión se aborda la conversión de una aplicación offline (que se ejecuta completamente en el sistema del jugador) a una aplicación online. La aplicación online está formada por dos partes: la parte servidor y la parte cliente. La parte servidor alberga la lógica del juego. La parte cliente tiene el interfaz necesario para interactuar con el jugador y se ejecuta en el sistema de dicho jugador. Iteración 3 - Ahorcado multijugador online: En la tercera versión el juego se convierte en multijugador. Esta versión está centrada en la sincronización de los distintos jugadores, que tendrán que esperar a que se hayan unido los demás jugadores para iniciar la partida y tendrán que esperar su turno para poder mostrar una letra. Iteración 4 - Ahorcado multijugador online con estadísticas: En la cuarta y última versión del juego el objetivo es añadir estadísticas. De esta forma, la empresa HappyPigs podrá saber qué jugadores son los mejores jugando al juego del ahorcado. A continuación se describen en mayor detalle cada una de estas iteraciones. Las dos primeras ya están completamente desarrolladas. La tercera está parcialmente completada y la cuarta aún no ha empezado su desarrollo. Iteración 1 - Ahorcado monojugador offline La versión monojugador offline del ahorcado es una aplicación Java en modo consola. El objetivo del juego consiste en que el jugador adivine el nombre de un país. Para ello, el jugador verá tantos guiones como letras tiene el nombre del país. La mecánica del juego consiste en que el jugador va indicando letras (vocales o consonantes). Cada letra que seleccione el jugador que esté presente en el nombre del país se considera un acierto y se muestra en la propia palabra sustituyendo el guión o los guiones en los que aparezca esa letra. Cada letra que elija el jugador que no esté presente en el nombre del país se considera un error. 2

3 Cada vez que se produce un error, se añade una parte del cuerpo del ahorcado. El jugador pierde si el cuerpo del ahorcado aparece completo antes de que el haya completado el nombre del juego. El jugador gana si es capaz de completar el nombre del juego. Para un jugador, el juego del ahorcado funciona de la siguiente manera: 1) Cuando el juego se inicia se pide el nombre al jugador para poder dirigirse a él. 2) A continuación se muestra el dibujo de una horca sin el ahorcado. 3) Posteriormente se muestran tantos guiones como letras tiene el nombre del país que el jugador tiene que adivinar. 4) Se pregunta al jugador una letra. Si la letra aparece en el nombre, se muestra en todas las posiciones en las que aparezca. Si no está en el nombre, se añade una parte más al cuerpo del ahorcado. 5) Si el nombre del juego se ha completado, el jugador gana. Si el cuerpo del ahorcado se ha completado, el jugador pierde. Si no se ha llegado al final, se vuelve a preguntar una letra al jugador. El cuerpo del ahorcado se va completando con las siguientes partes: cabeza, tronco, un brazo, otro brazo, una pierna y la otra pierna. A continuación se muestra la sucesión de pasos en los que se va formando el cuerpo del ahorcado. (1) (2) (3) # (_) # (_) [ ] [_] (4) (5) (6) # (_) x--[ ] [_] # (_) x--[ ]--x [_] # (_) x--[ ]--x [_] _

4 (7) # (_) x--[ ]--x [_] El juego está formado por las siguientes clases: ahorcado.app.ahorcadoapp: Es la clase que contiene el método main de la aplicación. Se encarga de crear el objeto encargado de gestionar el juego (JuegoAhorcado) y el objeto encargado de representar al jugador (Jugador). ahorcado.juego.juegoahorcado: Es la clase encargada de seleccionar el país de forma aleatoria de una lista que contiene todos los países del planeta. Una vez seleccionada la palabra, crea un objeto encargado de gestionar la partida (PartidaAhorcado). ahorcado.juego.partidaahorcado: Contiene la lógica del juego del ahorcado. Es la encargada de preguntar las letras al usuario, verificar si están o no en la palabra y en función del resultado, incluir una parte más en el cuerpo del ahorcado. ahorcado.juego.jugador: Es la clase encargada de comunicarse con el jugador. Le pide el nombre, las letras de la palabra y cunado finaliza la partida, pregunta al usuario si quiere una nueva. ahorcado.juego.palabra: Controla la palabra que tiene que ser adivinada por el jugador. Es la encargada de verificar si cada una de las letras están en la palabra y de ser así, es la encargada de mostrar dicha letra. ahorcado.juego.horca: Es la clase encargada de mostrar la horca con las diferentes partes del ahorcado. util.consola: Esta clase oculta todos los detalles de gestión del teclado para poder leer información del jugador. También es la encargada de mostrar información por pantalla. Esta versión del juego del ahorcado está completamente implementada y se encuentra en el proyecto Ahorcado_1. Iteración 2 - Ahorcado monojugador online Para crear la versión monojugador online partiendo de la versión offline se ha dividido la aplicación de la iteración 1 en dos aplicaciones: un servidor y un cliente. Primero se arranca el servidor y queda a la espera de recibir peticiones. Posteriormente el jugador inicia la aplicación cliente que se conecta al servidor y en ese momento inicia la partida. Cuando el jugador termina la partida y no 4

5 quiere jugar otra, el servidor queda disponible para un nuevo cliente. En esta iteración la aplicación no puede atender a varios jugadores de forma simultánea. Para conseguir esta funcionalidad, se han incluido y/o modificado las siguientes clases al programa: ahorcado.app.servidorahorcadoapp: Es la clase que contiene el método main e inicia un servidor de red en el puerto Este servidor está diseñado para atender las peticiones de una aplicación que actúa como cliente. ahorcado.app.clienteahorcadoapp: Es la clase que contiene el método main e inicia un cliente de red. Al arrancar le pregunta al usuario la dirección IP y el puerto del servidor. Si no se introduce ningún valor, el cliente se conecta al servidor por defecto que está en la misma máquina (dirección IP ) y puerto util.consolatecladopantalla: No es una clase nueva, en realidad es el nuevo nombre de la clase Consola. Se ha cambiado de nombre porque se ha decidido crear una clase Consola genérica que sea la clase padre de todos los tipos de consola que se pueden necesitar en un programa online. util.consola: Es una clase abstracta que actúa como clase padre de todos los tipos de consolas del programa. En concreto, existe una consola que permite escribir en la pantalla y leer del teclado (ConsolaTecladoPantalla) y otra consola diseñada para enviar la información por la red a un cliente y recibir la información de un cliente (ConsolaRed). util.red.consolared: Es un tipo de consola diseñada para comunicar a un cliente con un servidor. Para ello utiliza un protocolo muy básico basado en texto que sirve para enviar comandos del servidor al cliente. util.red.servidor: Es la clase encargada de esperar la llegada de conexiones a un socket que actúa como servidor. Cuando llega una nueva conexión se crea una tarea y se envía a un Executor para que sea procesada en un hilo. El Executor se pasa como parámetro en el constructor de forma que se pueda configurar de forma adecuada. Esta clase contiene todos los detalles de bajo nivel que permiten crear un servidor. Un objeto de esta clase se usa en el ServidorAhorcadoApp para crear el servidor del ahorcado. util.red.cliente: Es la clase encargada de realizar una conexión a un servidor implementado con la clase Servidor. Esta clase contiene todos los detalles de bajo nivel que permiten crear un cliente. Un objeto de esta clase se usa en el ClienteAhorcadoApp para crear el cliente del ahorcado. Las demás clases que no se indican aquí no han cambiado nada desde la iteración 1. Para que un desarrollador pueda ejecutar el ahorcado monojugador online de la iteración 2 debe ejecutar dos aplicaciones a la vez en la misma máquina. Primero se ejecuta el servidor (ServidorAhorcadoApp), de forma que pueda atender peticiones. Posteriormente se inicia el cliente (ClienteAhorcadoApp) que será la aplicación con la que interactuará el jugador. Los entornos de desarrollo para Java (Eclipse y Netbeans) permiten la ejecución de varias aplicaciones de forma simultánea. El desarrollador sólo tiene que elegir de qué ejecución quiere ver la salida. Cuando el juego se encuentre en producción, la aplicación ServidorAhorcadoApp se ejecutará en un 5

6 servidor y la aplicación ClienteAhorcadoApp se ejecutará en el ordenador del jugador. Esta versión del juego del ahorcado está completamente implementada y se encuentra en el proyecto Ahorcado-2. Iteración 3 - Ahorcado multijugador online En la iteración 3 se incorpora la característica de que varios jugadores puedan jugar a la misma vez al ahorcado. Las reglas del juego con varios jugadores son las siguientes: Todos los jugadores tienen que adivinar el mismo país. Un jugador elige letras mientras acierte las que vaya indicando. Cuando un usuario falla al elegir una letra (porque no se encuentre en la palabra) se añade una parte al cuerpo del ahorcado y el turno pasa al siguiente jugador. Todos los jugadores comparten la misma horca, de forma que los fallos de un jugador cuentan para los demás jugadores. El juego termina cuando un jugador completa la palabra o cuando un jugador completa el ahorcado. Además, como ahora varios jugadores se tienen que coordinar para jugar a la misma vez en la misma partida, cuando un jugador quiere jugar sucede lo siguiente: Una partida puede tener un mínimo de 1 jugador y un máximo de 4. Sólo se permite una partida a la vez. Cuando un jugador se conecta al servidor y quiere iniciar una partida se pueden dar las siguientes situaciones: Si no hay ninguna partida iniciada, el jugador espera a que se unan a la partida hasta 3 jugadores más (un máximo de 4 jugadores por partida) o hasta que finalice el tiempo de espera (10 segundos). Si hay una partida iniciada, el jugador tiene que esperar a que finalice la partida en curso. Una vez que finaliza la partida en curso, tendrá que esperar a que se unan el resto de jugadores o finalice el tiempo de espera. Los desarrolladores de HappyPigs han estado trabajando en la iteración 3. Han añadido / modificado las siguientes clases: ahorcado.app.servidorahorcadoapp: Han modificado el servidor para permitir que varias conexiones sean procesadas de forma concurrente. En concreto, el executor que alberga el pool de hilos se ha creado con 10 hilos, por lo tanto se permiten hasta 10 conexiones simultáneas al servidor. En cualquier caso, sólo 4 jugadores podrán estar jugando al ahorcado a la misma vez. 6

7 ahorcado.juego.juegoahorcado: Esta es la clase que más ha cambiado respecto a la iteración anterior. Ahora se utiliza para sincronizar a los jugadores durante todas las fases del juego: Bloqueo de jugadores que no pueden empezar una partida porque ya hay una partida activa. Bloqueo de jugadores que no pueden empezar una partida porque todavía no han llegado los demás jugadores o no ha pasado el tiempo de espera. Bloqueo de jugadores hasta que sea su turno o finalice la partida. ahorcado.juego.partidaahorcado: Esta clase también ha cambiado respecto a la iteración anterior. Se han realizado las modificaciones necesarias para que pueda haber varios jugadores en una partida del ahorcado. Se han añadido/modificado los siguientes atributos: consola: Se ha sustituido la consola básica (que sólo permitía la comunicación con un jugador) con una consola múltiple (ConsolaMultiple) que permite enviar la información a todos los jugadores de la partida. juegoahorcado: Ahora una partida tiene acceso al objeto JuegoAhorcado para sincronizar los turnos de los jugadores. ahorcado.juego.jugadorreal: La clase jugador de la iteración 2 se ha cambiado de nombre. Además, se ha incorporado todo el protocolo de acceso a una nueva partida (esperar si hay una en curso y esperar hasta el resto de jugadores) y las reglas que se aplican cuando varios jugadores juegan en la misma partida (espera por el turno o que haya finalizado la partida). ahorcado.juego.jugadorbot: Es un jugador automático que se comporta parecido a un jugador real pero sin realizar una conexión de red. Esta clase se ha creado con el objetivo de probar el funcionamiento del JuegoAhorcado y la PartidaAhorcado con múltiples usuarios de forma automática. Así los desarrolladores evitan la tediosa tarea de probar manualmente todas las situaciones posibles con partidas de varios usuarios. ahorcado.juego.jugadortest: Es un jugador que no tiene comportamiento y que se utiliza para implementar tests automáticos. ahorcado.juego.jugador: Es el interfaz implementado por JugadorReal y JugadorBot. De esta forma, las clases JuegoAhorcado y PartidaAhorcado pueden comunicarse con cualquier tipo de jugador (sea real o sea automático). ahorcado.app.pruebajugadoresbot: Es una aplicación que permite probar el correcto funcionamiento del juego del ahorcado multijugador online de forma automática. Para ello, crea un objeto JuegoAhorcado y arranca seis hilos de ejecución, en cada uno de esos hilos ejecuta un JugadorBot. Para facilitar la depuración del programa, sólo el servidor muestra información por pantalla. Los jugadores automáticos (JugadorBot) usan una consola que no muestra información por pantalla (ConsolaOculta). 7

8 util.consolaoculta: Consola que no muestra información por pantalla. Es utilizada en las aplicaciones de prueba en las que no se requiera que todos los jugadores muestren información por pantalla. Aunque la empresa HappyPigs ha avanzado bastante en el desarrollo de la iteración 3, está incompleta. Como en la mayoría de las aplicaciones de red, cada jugador que se conecta al servidor se ejecuta en su propio hilo de ejecución. Y todos hilos ejecutan el mismo objeto de la clase JuegoAhorcado. El problema es que los desarrolladores de la empresa no han sido capaces de implementar el código para que la clase JuegoAhorcado sea thread-safe y que coordine correctamente a los jugadores. Por este motivo la clase JuegoAhorcado tiene métodos sin completar y no compila. Para solucionar estos problemas, la empresa HappyPigs ha decidido contratar a los alumnos de la asignatura de Programación Concurrente. En concreto, la empresa pide a los alumnos: Que analicen y comprendan el código de las iteraciones 1 y 2. No es importante que se centren en los detalles de comunicación cliente/servidor porque esta parte está completa y no necesita ningún cambio. Tampoco es importante que conozcan los detalles de las clases Palabra y Horca, ya que tampoco necesitan ningún cambio. No obstante, conviene que conozcan a grandes rasgos su funcionamiento. Que implementen completamente la clase ahorcado.juego.juegoahorcado, que se utiliza para sincronizar los hilos de los jugadores. En esta clase deben implementarse los siguientes métodos: esperarjugarpartida(jugador jugador): Bloquea al jugador hasta que se han apuntado el resto de jugadores o se ha llegado al tiempo máximo de espera (10 segundos) y se puede empezar una nueva partida. También bloquea al jugador en caso de que haya una partida en curso o bien la partida que está a punto de comenzar ya ha alcanzado el número máximo de jugadores. Este método es usado por el jugador. esperarturnoofin(jugador jugador): Bloquea al jugador hasta que llega su turno o hasta que acaba la partida (porque otro de los jugadores ha ganado o ha perdido). Este método es usado por el jugador. cambiarturno(): Asigna el turno al siguiente jugador. Es importante que los turnos vayan cambiando en el orden en que los jugadores se apuntaron a la partida. Este método es usado por la PartidaAhorcado. getjugadoractual(): Devuelve el jugador que tiene asignado el turno. Este método es usado por la PartidaAhorcado para mostrar mensajes y usar su consola. finpartida(): Finaliza la partida actual desbloqueando a todos los jugadores que esperaban en esperarturnoofin. Este método es usado por la PartidaAhorcado cuando la partida ha finalizado. Que verifiquen el correcto funcionamiento del juego del Ahorcado. Para ello, los alumnos deberán hacer las siguientes pruebas: 8

9 Pruebas funcionales manuales: Para ello iniciarán el servidor y varios clientes en su propio equipo. De esa forma se estará realizando una partida con varios usuarios simultáneos. Pruebas de integración automáticas: La clase PruebaJugadoresBot inicia una serie de jugadores automáticos (bots) que juegan al ahorcado. Como seleccionan las letras al azar, es bastante probable que pierdan la mayoría de las veces, pero de estar forma se puede comprobar que el sistema se comporta de forma adecuada con interacciones muy rápidas. Pruebas unitarias de la clase JuegoAhorcado: Esta clase es la que más se tiene que probar porque es la que tienen que implementar los alumnos. Por este motivo, se tienen que implementar varios tests unitarios que verifiquen el correcto funcionamiento de sus métodos. Para implementar estos tests unitarios se utilizará la librería JUnit. En la siguiente sección se explica el funcionamiento de esta librería y se detallan los tests que deben implementarse. JUnit, librería de testing Java Además de las clases del propio programa, el código disponible de la iteración 3 dispone de un test unitario para verificar el correcto funcionamiento de la clase JuegoAhorcado. Los tests son miniprogramas que comprueban de forma automática que una determinada funcionalidad que está implementada se comporta como se espera. Los tests son especialmente útiles para asegurarnos de que algo que tenemos implementado y funciona no se rompe al añadir nueva funcionalidad. El test está implementado con la herramienta JUnit ( que se utiliza bastante en el ámbito profesional para la implementación de tests en Java. Cada test se implementa como un método de un clase. La clase PartidaTest implementa un test que verifica que cuando se añaden cuatro jugadores a una partida, la partida comienza inmediatamente sin que transcurra el tiempo máximo de espera. Como la clase JuegoAhorcado está sin implementar, si ejecutamos el test fallará, pero cuando implementemos correctamente dicha clase, el test pasará y verificará que todo es correcto. El código de la clase PartidaTest es el siguiente: public class PartidaTest public void test() throws InterruptedException{ JuegoAhorcado juego = new JuegoAhorcado(new ConsolaTecladoPantalla()); CountDownLatch latch = new CountDownLatch(4); for(int i=0; i<4; i++){ String nombre = "Jugador"+i; new Thread(()->{ Jugador jugador = new JugadorTest(nombre); try { juego.esperarjugarpartida(jugador); } catch (Exception e) {} 9

10 } latch.countdown(); }).start(); } } El test hace lo siguiente: if(!latch.await(5, TimeUnit.SECONDS)){ Assert.fail("El jugador no debería esperar para jugar"); } 1) Crea un objeto de la clase JuegoAhorcado: JuegoAhorcado juego = new JuegoAhorcado(new ConsolaTecladoPantalla()); 2) Simula que 4 jugadores quieren jugar una partida. Para ello, crea 4 hilos, en cada hilo crea un objeto de la clase JugadorTest y se invoca el método juego.esperarjugarpartida(jugador). De esa forma, se estará ejecutando ese método desde 4 hilos a la misma vez. for(int i=0; i<4; i++){ String nombre = "Jugador"+i; new Thread(()->{ Jugador jugador = new JugadorTest(nombre); try { juego.esperarjugarpartida(jugador); } catch (Exception e) {} } latch.countdown(); }).start(); 3) Finalmente se verifica que todos los jugadores han finalizado la ejecución del método esperarjugarpartida inmediatamente, sin esperar los 10 segundos necesarios. Para ello se utiliza un CountDownLatch para sincronizar los hilos de los jugadores con el hilo del propio test. Se crea un CountDownLatch inicializado a 4, cada jugador invoca countdown y por último el test verifica que la cuenta llega a 0 antes de 5 segundos, lo que demuestra que no se han esperado los 10 segundos. CountDownLatch latch = new CountDownLatch(4); latch.countdown(); if(!latch.await(5, TimeUnit.SECONDS)){ Assert.fail("El jugador no debería esperar para jugar"); } Para ejecutar este test en eclipse, basta con hacer botón derecho sobre el nombre del método y 10

11 seleccionar la opción Run as... > JUnit Test. Durante la ejecución, aparecerá una vista en eclipse que muestra el resultado de los tests. El color verde significa que los tests han pasado, es decir, que han comprobado que el comportamiento del código es el esperado. En caso de que los tests fallen, se mostrará el color rojo con el mensaje que indica qué ha ido mal. Test con fallo Test correcto Se considera que un test no pasa, cuando se da alguna de las siguientes situaciones: Se eleva una excepción en el hilo del test durante su ejecución y no se captura en ningún catch. Si se eleva una excepción en cualquier otro hilo del programa, el test no se considerará como fallo. Se invoca el método Assert.fail Se invoca el método Assert.assertTrue con una expresión que se evalúa a false. Se considera que un test pasa en cualquier otro caso. Es decir, un test se considera que pasa en las siguientes situaciones: Si el método del test finaliza sin excepción y todos los asserts ejecutados son correctos. Si el método del test finaliza sin excepción (aunque no se haya ejecutado ningún assert). Es importante tener en cuenta algunos aspectos de JUnit cuando estamos implementando tests para código concurrente: Si el test termina sin excepción, ni llamada a fail, ni llamada a asserttrue con una expresión falsa, se considera el test correcto. Es decir, los tests no esperan a que cualquier hilo creado dento del test haya terminado. Si deseamos que nuestro test se espere, tendremos que implementarlo de forma explícita en el test. Para que un test falle, se debe llamar al método fail o al método asserttrue en el hilo que ejecuta el propio test. Si se llama a estos métodos en otro hilo se provocará que esos hilos 11

12 finalicen su ejecución (porque se elevará una excepción), pero eso no implicará que el test falle. Es decir, si dentro de un hilo detectamos alguna situación que indica que el test no debe pasar (es decir, debe finalizar con error o fallo), entonces habrá que comunicar dicha situación al hilo del test para que invoque el método adecuado. Por último, una clase de test puede tener varios métodos anotados También puede tener métodos auxiliares usados por los propios tests. Si la clase es muy grande, conviene crear varias clases separando los tests por grupos relacionados entre sí. Las tareas concretas que el alumno debe hacer para completar la iteración 3 son las siguientes: Tarea 1: Implementar el método esperarjugarpartida(jugador jugador): Este método debe bloquear al jugador hasta que se han apuntado el resto de jugadores (otros 3 más) o se ha llegado al tiempo máximo de espera (10 segundos). En ese momento el método se desbloqueará y se podrá empezar una nueva partida. También debe bloquear al jugador en caso de que haya una partida en curso o bien la partida que está a punto de comenzar ya ha alcanzado el número máximo de jugadores. El método devuelverá cuando se desbloquee el objeto de la clase PartidaAhorcado en el que se desarrollará la partida. Al implementar este método debe invocarse el método PartidaAhorcado.apuntarJugador(jugador) por cada jugador que finalmente esté involucrado en la partida. Tarea 2: Implementar tests para el método esperarjugarpartidaverificar: Verificar que el método esperarjugarpartida funciona correctamente en todas las situaciones con tests automáticos: Tarea 2.1: Verificar que la partida comienza inmediatamente al llegar 4 jugadores. Para ello se puede usar el test ya implementado de la clase PartidaTest. Tarea 2.2: Implementar un test que verifique que una partida comienza con menos de 4 jugadores después del tiempo de espera de 10s (y no antes). Tarea 2.3: Implementar un test que verifique que si un nuevo jugador se conecta con una partida ya comenzada, ese jugador se espera hasta que la partida anterior haya terminado y que se cumpla que llegan 4 jugadores o ha transcurrido el tiempo de espera de 10s. Tarea 2.4: Implementar un test que verifique que se respeta el orden de llegada de los jugadores para que puedan jugar a una nueva partida. Por ejemplo, si llegan 10 jugadores ordenados del 1 al 10, los 4 primeros (1,2,3,4) jugarán la primera partida, los 4 siguientes (5,6,7,8) la segunda partida y los últimos (9 y 10) jugarán la última partida. Tarea 3: Implementar método esperarturnoofin: Este método debe bloquear al jugador hasta que llega su turno o hasta que acaba la partida (porque otro de los jugadores ha ganado o ha perdido). Tarea 4: Implementar el método cambiarturno: Este método debe asignar el turno al siguiente jugador. Es importante que los turnos vayan cambiando en el orden en que los jugadores se apuntaron a la partida. 12

13 Tarea 5: Implementar el método getjugadoractual: Este método debe devolver el jugador que tiene asignado el turno. Tarea 6: Implementar el método finpartida: Este método debe finalizar la partida actual desbloqueando a todos los jugadores que esperaban en esperarturnoofin. Tarea 7: Implementar tests para los métodos esperarturnoofin, cambiarturno, getjugadoractual y finpartida: Verificar que el método esperarturnoofin funciona correctamente en todas las situaciones con tests automáticos: Tarea 7.1: Implementar un test que verifique que los jugadores se van desbloqueando del método esperaturnoofin en el orden en el que se unieron a la partida cuando se llama al método cambiarturno. Tarea 7.2: Implementar un test que verifique que el resto de jugadores se desbloquean del método esperaturnoofin cuando un compañero finaliza la partida ejecutando finpartida. Iteración 4 - Ahorcado multijugador online con estadísticas Los responsables técnicos de la empresa HappyPigs han quedado gratamente sorprendidos de la capacidad técnica que han demostrado los alumnos de la asignatura en la iteración 3. Por ello, han decidido ofrecerles un trabajo de mayor responsabilidad para la iteración 4. Para la iteración 4 quieren incorporar estadísticas al juego del ahorcado. En concreto, quieren que la aplicación tenga las siguientes funcionalidades: Estadísticas al finalizar la partida: Cada vez que un jugador finaliza una partida, se quiere registrar si el jugador ha perdido, ha ganado o ninguna de las dos cosas (ha perdido o ganado otro jugador). En concreto, quieren llevar una cuenta del número de partidas en las que cada jugador ha ganado, perdido o ninguna de las dos. Además, cada vez que finaliza una partida quieren mostrar por pantalla el jugador que más veces ha jugado, el que más veces ha ganado, el que más veces ha perdido y el que más veces ni ha ganado, ni ha perdido. Como todos estos cálculos llevan tiempo, no quieren que el jugador tenga que realizar esos cálculos en su hilo. Es decir, deben realizarse en un hilo diferente. Obviamente, en vez de crear un nuevo hilo cada vez, será mejor reutilizar hilos con alguna de las técnicas conocidas. Además, para implementar estos cálculos, no deben procesarse la lista de jugadores completa, basta con evaluar los jugadores que acaban de terminar la partida y los jugadores que antes ocupaban estas posiciones top. Estadísticas cada 10 segundos: Además de las estadísticas básicas que se muestran cuando finaliza una partida, es necesario sacar unas estadísticas más elaboradas cada 10 segundos. En estas estadísticas más elaboradas lo que se pretende es mostrar varias listas de jugadores con sus puntuaciones: Lista 1: Jugadores ordenados de mayor a menor por el número de partidas ganadas. Lista 2: Jugadores ordenados de menor a mayor por el número de partidas perdidas. 13

14 Lista 3: Jugadores ordenados de menor a mayor por el número de partidas ni ganadas ni perdidas. Lista 4: Jugadores ordenados de menor a mayor por el número de partidas jugadas. Para aprovechar la potencia de cómputo del sistema informático estas ordenaciones tienen que realizarse en paralelo utilizando varios hilos. Para ello pueden emplearse streams o implementar manualmente un algoritmo de ordenación paralelo. Hay que tener en cuenta que las estadísticas que se ejecutan por cada partida y las estadísticas que se ejecutan cada 10 segundos acceden a los mismos datos a la misma vez. Por tanto, es necesario que los objetos estén debidamente gestionados para que no se produzcan condiciones de carrera. En este sentido, es importante tener en cuenta de que los resultados de las listas tienen que ser coherentes entre sí. Es decir, no debería ocurrir que un jugador indique que ha jugado 30 partidas, pero que la suma de ganadas, perdidas y ni ganadas ni perdidas sea 29, por ejemplo. Dicho de otro modo, hay que hacer lo que sea necesario para que las estadísticas sean correctas aunque un jugador acabe un partida justo en el momento del cálculo de estadísticas cada 10 segundos. Se pide Se pide a los alumnos que complenten la iteración 3 y que implementen la iteración 4 del juego del ahorcado de la empresa HappyPigs. 14