Errores comunes en los Wherigos con Urwigo II

Ratio:  / 0

 El funcionamiento de los cartuchos de Wherigo está orientado a eventos, esto implica que cuando corremos un programa no existe un flujo lineal y predecible sino que se van generando eventos dependiendo de la posición del jugador, de los sitios por los que ha pasado o del tiempo transcurrido.  Esto hace que los mensajes vayan apareciendo en la pantalla según se van generando los eventos del juego y los eventos no son fácilmente previsibles. Por ejemplo podemos tener un evento al entrar en una zona y otro  al salir de ella. Si el jugador se queda en el límite de la zona, y debido a los errores del GPS, el jugador puede estar entrando y saliendo de la zona y por tanto los mensajes irán apareciendo en pantalla y pisándose  (en otra entrega explicaremos cómo evitar esto). Vamos a verlo con un ejemplo.

En este ejemplo, vemos que es el propio compilador de Urwigo el que nos da un mensaje de advertencia (triangulito amarillo en el segundo mensaje) que nos indica que esta acción solapa con otra anterior. Si ejecutamos este programa veremos que lo único que aparece en pantalla es el segundo mensaje. En realidad el primero también se ha enviado, pero automáticamente ha sido pisado por el segundo. Por tanto en este caso está muy claro que estamos haciendo algo mal. 
Pero qué ocurre si en lugar de tener dos mensajes encadenados en el mismo evento, lo que tenemos es que uno de ellos está generado por un timer o por otra acción del jugador. En este caso, vemos que el compilador no nos avisa a pesar de que las dos ventanas se van a pisar. 

Si esto sucede, el jugador se quedará sin ver el mensaje de la primera ventana. 

Afortunadamente el propio Urwigo nos da mecanismos para prevenir e intentar paliar los efectos de que las ventanas se pisen. Como ya sabremos, Urwigo nos da dos formas de presentar mensajes al usuario, los mensajes y los diálogos. En principio son muy parecidos, la principal diferencia es que en un dialogo se nos presentan una serie de mensajes encadenados entre los cuales el jugador tiene que pulsar OK para pasar al siguiente. Ambos tienen la opción de presentar dos botones para seleccionar entre dos opciones posibles. 

Empezaremos con los diálogos, en estos existe la opción Buffered que nos permite que los mensajes, en lugar de enviarse directamente en pantalla, se ponen en la cola de salida a la espera de que se envié un mensaje directo  a la pantalla(no buffered o mensaje), para entonces, sacar todos de la cola, en el orden en el cual han entrado (FIFO). Podemos probar con un ejemplo:

 Al entrar en el cartucho lanzamos un timer de 2 segundos que nos lanzará un mensaje, y después nos muestra el diálogo. El comportamiento de estas secuencias de código difiere en función de si hemos seleccionado la casilla Buffered. Con esta casilla sin seleccionar el comportamiento es el siguiente: aparece en pantalla el diálogo "Hola guapo " y dos segundos después y sin dar tiempo a pulsar OK para ver el siguiente diálogo, entra el timer y pisa la pantalla, por lo que el diálogo "Tu si eres guapo" no llega a verse.

Veamos ahora, cómo funciona cuando la casilla Buffered esta seleccionada. En este caso, cuando empieza la ejecución, lanza el timer y acto seguido pone en la cola de pantalla los diálogos "Hola guapo"y "Tu si que eres guapo", de momento en pantalla no aparece nada. Cuando entra el timer, es cuando los mensajes empiezan a presentarse en pantalla. El primero en salir es el primero que entró, por lo que irá apareciendo primero "Hola guapo" luego, tras pulsar OK, "Tu si que eres guapo" y por último "Me alegro de que estes aqui". Como vemos pulsar la casilla Buffered marca la diferencia entre que se pierdan los mensajes o no. Esto nos es gratis, hemos de tener en cuenta  que los mensajes no aparecerán en la pantalla hasta que haya uno que acceda directamente. Esto lo tenemos que tener previsto. 

Lo anterior es para los diálogos, en el caso de los mensajes el mecanismo de protección es distinto de los diálogos, en este caso va más orientado a saber que ha sido pisado y actuar en consecuencia. La casilla en este caso se llama Skip cancel y el funcionamiento es: cuando está seleccionado, el evento On click que se genera cuando pulsamos uno de los dos botones y solo  si pulsamos los botones, es decir, que si hay una ventana que pisa la actual, ese evento no salta nunca y por tanto perdemos la selección. Cuando la casilla no está seleccionada, el evento On click se genera cuando pulsamos uno de los dos botones o si la ventana es pisada. En este último caso, es como si se pulsase el botón cancelar. Si se genera el evento, podemos poner el código necesario para gestionar que el jugador no ha realizado la elección y actuar en consecuencia. Veamos un ejemplo:

En este caso, el jugador tienes dos opciones espada o hacha y ha de elegir una de ellas. Si tenemos Skip  Cancel seleccionado, cuando llegue el evento del timer la pantalla será pisada y saldremos sin haber elegido ninguna de las dos armas. El jugador continuará sin armas. El evento On click no llega a ejecutarse nunca. Sin embargo, si tenemos Skip cancel sin seleccionar, cuando el timer pisa la pantalla, se ejecuta el evento On click y por cómo está escrito el código el jugador sale portando el hacha. También podríamos hacer puesto en nuestra opción if, el código necesario para comprobar si se pulso la opción cancel(ventana pisada). Para ello ponemos un "if menssage button Cancel" y en ese caso mostrar un mensaje del tipo:"Vuelve a hablar con el herrero".

Hemos visto los dos mecanismos que nos proporciona Urwigo para poder evitar y prevenir el que las ventanas se pisen. Ciertamente, esto son unas herramientas más en nuestras opciones de programador y seguro que habéis puesto solución a este problema de otras maneras. Como siempre los problemas de programación tienen varias soluciones, unas más complicadas o efectivas  que otras, pero es necesario conocer todas las herramientas que el compilador pone a nuestro alcance.