Creación de salas de juego y juegos multiusuario (continuación)

En la entrega anterior implementamos la lógica funcional del juego multiusuario ‘Simón dice’. El juego era completamente funcional y lo integramos parcialmente con el resto de la interfaz que hemos ido desarrollando a lo largo de esta serie de artículos.

Aunque la implementación quedó prácticamente lista dejamos una serie de aspectos sin atar. A lo largo de este artículo perfilaremos el funcionamiento, daremos unos últimos retoques a la aplicación y haremos una refactorización de la aplicación para optimizar y ordenar todo lo que hemos hecho.

El orden. Una necesidad
Tal y como hemos venido apuntando hasta ahora, en el desarrollo de aplicaciones, la fase de diseño es tan importante o más que la fase de implementación. En el mundo de la programación es muy importante saber lo que se tiene que hacer antes de empezar a hacerlo, si no lo sabemos o simplemente tenemos dudas de cuál va a ser nuestro siguiente paso tenemos muchos números para que nuestros desarrollos terminen siendo un completo caos.
Cuando mis proyectos llegan a una fase avanzada de su desarrollo, cuando realizar determinados cambios puede implicar la aparición de comportamientos colaterales no deseados (bugs) y sobretodo cuando se sabe lo que se ha hecho pero no se tiene muy claro lo que falta por hacer, es buena idea hacer una lista con las tareas pendientes. En dicha lista podemos incluir lo que falta por implementar, las partes de código que funcionan pero que nos gustaría optimizar y también las partes de código que no funcionan y que evidentemente se tienen que depurar.
Para hacer esta lista podemos ayudarnos de palabras inglesas como TODO (to do -> por hacer), DEBUG (depurar), FIXME (fijar) o IDEA. Estas palabras las acompañamos de una breve descripción. El siguiente texto se incluye en el archivo tasksToDo.as
tasksToDo.as
//FIXME: Integración del sistema de video-conferencia y del juego. En la implementación actual si estas jugando puedes realizar una videoconferencia o viceversa. En estos casos se solapan las interfaces.
//TODO: Implementación Client-side del final del juego
//FIXME: En el lado de servidor, cuando una partida está iniciada se pueden seguir incorporando nuevos jugadores. Haremos que cuando una partida se haya iniciado no admita más jugadores. Tendremos que permitir también una reinicialización de las partidas.
//TODO: Creación y gestión de salas de juego
//TODO: Refactorización del código, eliminar código repetido y ordenarlo de forma lógica.
Este archivo tiene extensión .as, pero podríamos haber usado cualquier otra. Recordemos que la misión de este archivo no es otra que ayudarnos en la organización de nuestro trabajo.

Solventando las incoherencias gráficas
Siguiendo el orden de la lista de tareas vamos a empezar solventando las incompatibilidades existentes entre el sistema de videoconferencia y el juego.
Todas las utilidades que tiene nuestra aplicación hacen uso del objeto User, al que se le han ido añadiendo una serie de propiedades que nos permiten conocer en todo momento qué está haciendo el usuario. Veamos el resumen de propiedades:
- name: Una vez conectado con el servidor, almacena el nombre de usuario con el que se ha conectado.
- privadoCon: En caso de estar realizando una videoconferencia nos indica el nombre de usuario del interlocutor, en caso contrario toma el valor undefined o null.
- state: Esta propiedad nos indica qué partes de la aplicación está utilizando el usuario en cada momento. Sus valores son numéricos y se han codificado como se indica a continuación:
- 0: Sólo está chateando.
- 1: Tiene una ventana de videoconferencia abierta.
- 2: Tiene una partida abierta.
- room: En caso de estar jugando una partida a Simón Dice nos indicará el nombre de dicha partida. En la implementación actual sólo existía una partida y se llamaba “simon”.
Hay momentos en los que el objeto User presenta alguna propiedad más, pero son temporales y no afectan a esta parte del desarrollo.
Una descripción a alto nivel de lo que pretendemos hacer sería:
Si el usuario está realizando una videoconferencia y quiere empezar un nuevo juego, le tendremos que avisar que antes de empezarla tiene que cerrar la ventana de videoconferencia. De igual forma, si está jugando y quiere empezar una videoconferencia, se le advertirá que tiene que cerrar la partida.
Si describimos así el problema vemos claramente qué es lo que tenemos que hacer y dónde. En la función que lanza la videoconferencia deberemos verificar el estado del usuario (user.state) y sólo se procesará la petición en caso que el usuario no esté jugando (user.state == 0).
Recordemos que para iniciar una videoconferencia, teníamos que hacer doble click sobre algún usuario en la lista de usuarios. En este momento se ejecutaba la función clickHandle, que al detectar la doble pulsación pasaba a ejecutar la función videoconferencia. Va a ser en ésta última en la que incluyamos la condición.
function videoConferencia(label) {
if (User.state == 0) {
User.state = 1;
User.privadoCon = label;
abrirPrivado();
pedirPrivado();
}else{
_root.attachMovie(“FMessageBoxSymbol”, “Alert”, 600);
Alert._x = (Stage.width - alert._width) / 2;
Alert._y = (Stage.height - alert._height) / 2;
Alert.setTitle(“Error”);
Alert.setMessage(“An