Crea tu propio Wherigo (7) INPUTS… ¡Comienza la diversión con la Action If/Else!

Esta entrada forma parte del curso “Crea tu propio Wherigo”: Pincha en los siguientes enlaces para ver las entregas anteriores del mismo:

1: EL RETO

2: COMENZANDO NUESTRO CARTUCHO

3: GRÁFICOS Y AUDIO: LOS MEDIA

4: DE ZONA EN ZONA y tiro porque me toca

5: PERSONAJES Y OBJETOS… dialogando con unos y cogiendo a los otros

6: TASK Y VARIABLES… Vamos avanzando

……………………..

Wherigo es una marca registrada.

Antes de nada recomiendo encarecidamente leer las guidelines oficiales, así como la sección de preguntas frecuentes para tener claro que podemos y que no podemos hacer a la hora de crear y publicar un caché Wherigo.

………………………

¿Cuál es la diferencia principal entre ver una película o leer un libro y jugar a un videojuego? En mi opinión es, sin duda, la posibilidad de que el jugador interactúe con la obra. Mientras que en en las dos primeras actividades el espectador/lector actúa como sujeto pasivo de una historia, cuando se convierte en jugador debe tomar decisiones y actuar en consecuencia para que el juego avance en una dirección un otra. Un cartucho Wherigo puede plantearse de las dos maneras expuestas, pudiendo hacer que el jugador tome, o no, decisiones y que estas afecten al desarrollo de la aventura. Sin duda será mucho más inmersiva una historia en la que el personaje que la está viviendo  pueda elegir su propio destino, que si únicamente va de un lugar a otro siguiendo el recorrido propuesto por el programador.

Esta interactividad en los cartuchos Wherigo se consigue a través del ObjectInput“, que posibilita al jugador introducir manualmente un dato en su dispositivo. Para comprender y poder utilizar de forma útil los Inputs, resulta necesario introducir la Action If/Else, que sirve para establecer condicionales gracias a los cuales programar que si el jugador  introduce un determinado dato, ocurra una cosa en consecuencia, mientras que si introduce otro dato, ocurra una distinta. Vayamos paso a paso:

INPUTS

Como se ha explicado, un Input consiste en un Object que, al ser introducido en un evento, invita al jugador a introducir un dato de forma manual. Las posibles aplicaciones son muchas, desde responder una pregunta a tomar una decisión entre varias alternativas, pasando por multitud de “minijuegos” cuyo límite lo pondrá la imaginación del autor. En entregas posteriores se expondrá la programación de algunos de estos posibles minijuegos, en la entrega de hoy estudiaremos como crear los inputs más básicos.

Como puede verse claramente, los Inputs son el verdadero atractivo de un Wherigo, siendo bajo mi punto de vista lo que realmente puede dotar de personalidad y diversión al mismo si se utilizan bien. Sin embargo tienen un importante punto negativo a considerar y es que son los responsables de que un cartucho que los contenga no funcione correctamente en Iphone y GPS supuestamente compatibles con Wherigo y sólo se puedan completar en el WhereYouGo de Android. Mientras el software de los otros dispositivos no se actualice para una mayor compatibilidad es el precio que debemos pagar si queremos conseguir cartuchos Wherigo cada vez más complejos y originales.

Urwigo nos ofrece la posibilidad de crear cuatro tipos distintos de Inputs:

1) TEXT: Invitará al jugador a teclear una palabra o grupo de palabras. Por ejemplo serviría para, una vez llevado al jugador a un cartel, preguntarle: “¿Cuál es la tercera palabra que puedes leer?”; y sólo si se contesta correctamente poder seguir jugando.

2) NUMBER: Invitará al jugador a teclear un número. Por ejemplo podríamos utilizarlo para preguntarle al jugador: “¿Cuántas monedas quieres coger?”; y, en función de su respuesta, incrementar las monedas de su inventario en ese mismo número.

3) CHOICE: Invitará al jugador a seleccionar una de las respuestas alternativas que el programador le ofrece. Por ejemplo, al llegar en el juego a una puerta cerrada podríamos preguntarle: “¿Qué quieres hacer?” y ofrecerle dos botones para que presione uno con las respuestas “Abrir la puerta” y “Llamar a la puerta”.

4) TRUE/FALSE: Nunca lo he utilizado y no consigo entender que ventaja podría suponer respecto al resto de tipos de inputs. Si alguien tiene alguna idea será bienvenida en un comentario a esta entrada.

Para crear un Input seguiremos los siguientes pasos:

1) En la barra de menús de Urwigo, como viene siendo habitual, accederemos a la pestaña “Input” a través de “View“, “Input“. Como siempre, la pestaña consiste en una columna central donde se listarán todos los Inputs que hayamos creado y una columna derecha donde definiremos las propiedades de cada uno de ellos.

2) Presionaremos el botón “New Item” de la columna central y rellenaremos los siguientes campos de la columna de propiedades:

a) Name: Es el nombre del Input. El jugador no lo conocerá , pero debemos seleccionar uno lo suficientemente identificativo para trabajar con él comodamente sin confundirlo con otro.

b) Description: Una breve descripción de en que consiste el Input para mayor comodidad del programador. El jugador no verá esta descripción.

c) Identifier: No lo utilizaremos por el momento.

d) Display: Con la casilla activada el jugador podrá ver el Input cuando se lance. Al contrario de lo que ocurría, por ejemplo, en las zonas, soy partidario de dejar activada esta casilla en todos los Inputs que vayamos a crear para ahorrarnos trabajo posterior.

e) Image e Icon: Como siempre, pondremos la imagen que queramos que acompañe al Input. Sin embargo el Icon de estos Objects no aparece nunca durante el desarrollo de un Wherigo hasta donde yo se, por lo que podemos ahorrarnos el ponerle uno.

f) Type: Seleccionaremos el tipo de Input que vamos a crear (TEXT, NUMBER o CHOICE).

g) Question: Aquí escribiremos el texto que leerá el jugador cuando se le invite a introducir el dato. Es decir, aquí escribiríamos “¿Cuál es la tercera palabra del cartel?”, “¿Cuántas monedas quieres coger?” o “¿Qué vas a hacer?”, por poner los mismos tres ejemplos que se han comentado anteriormente.

h) Input Choice: Al crear un Input de tipo CHOICE en este cuadro de texto escribiremos las distintas respuestas alternativas que el jugador podrá seleccionar. Escribiremos cada una de estas respuestas en una fila distinta y, preferiblemente, en mayúsculas. De esta manera, para crear un Input de tipo CHOICE en el que se pregunte al jugador si va a abrir o llamar a la puerta deberíamos obtener una columna de propiedades como la siguiente:

CHOICEY así, el Input ya estaría creado. Pero por si sólo no sirve para nada, pues hay que establecer lo que ocurre en el momento de que el jugador responda a la pregunta planteada. Para hacer esto deberemos hacer click en Events, On get input unhandled y programar el evento que corresponda utilizando la Action If/Else y la expresion Compare, que introduciremos a continuación para posibilitar la creación de Inputs efectivos desde hoy.

IF / ELSE

Como se ha explicado anteriormente, gracias a la Action If/Else podremos establecer condiciones para que, en funcion de un determinado supuesto, se produzca una consecuencia u otra.

La fórmula que utiliza esta action es fácilmente comprensible, aunque difícil de explicar de palabra: “Si es A, entonces B”, “Si es C, entonces D”, “Si es cualquier otra cosa distinta a A o B, entonces E”; o lo que es lo mismo: “If A: B”, “If C: D”, “Else: E”. Aunque pueda parecer algo complejo en los siguientes ejemplos gráficos lo comprenderemos rápidamente.

IF / ELSE EN UN INPUT DE TIPO TEXT

En primer lugar vamos a crear un evento para el Input de tipo TEXT que se ha expuesto anteriormente, es decir, para preguntar al jugador por tercera palabra de un cartel que encontrará durante su recorrido. Supondremos que ya hemos creado el Input siguiendo las instrucciones que se han dado anteriormente y que nos encontramos en su “On get Input“, tal y como se ve en la siguiente imagen:

Imagen2

A continuación seguiremos los siguientes pasos:

1) Arrastraremos la Action If/Else al interior del cuadro “Drag actions here“.

if elseCon una estructura como la que en este momento tenemos podríamos crear las consecuencias para una sola condición, por ejemplo “Si el jugador escribe correctamente la respuesta, lanzar el Dialog “Muy bien, podemos seguir adelante”, o lo que sintéticamente se reduce a “Si es A, entonces B”. Sin embargo, para el caso que nos ocupa nosotros queremos crear una segunda condición para que, por ejemplo “Si el jugador escribe incorrectamente la respuesta, lanzar el Dialog “Te has equivocado, vuelve a intentarlo”, es decir “Si es C, entonces D”. Para conseguirlo, debemos hacer un click en el signo “+” que se encuentra junto a If/Else, consiguiendo la siguiente estructura:

dos condicionesPara el ejemplo que nos ocupa esto sería suficiente. Sin embargo, no debemos perder de vista que haciendo sucesivos clicks en el signo “+” podríamos añadir infinitos condicionales para considerar todas las posibles respuestas a la pregunta que el jugador pueda darnos. Puede ser divertido jugar con estas condicionales para, por ejemplo, introducir algún guiño ante determinada respuesta.

La estructura que hemos creado hasta ahora responde a la formula: “Si…”, “Si…”, por lo que aún debemos completarla.

2) Supongamos que la respuesta correcta a la pregunta planteada al jugador fuera “Geocacheando el mundo“. En este caso, lo que debemos programar en el “If” de la izquierda en la estructura que estamos creando responde a la fórmula: “Si la respuesta dada por el jugador es “Geocacheando el mundo”, entonces lanzar un Dialog que diga “Muy bien!! Esa es la respuesta correcta””.

Para conseguir esta estructura en nuestro evento utilizaremos las ExpressionsCompare” y “Answer“, que localizaremos utilizando la barra de desplazamiento vertical de la ventana de las Actions y Expressions.

a) Compare: Ya hemos visto esta Expression en anteriores entregas del tutorial. sirve para comparar 2 elementos de nuestro wherigo utilizando los operadores “Igual que“, “Diferente que“, “Menor que“, “Mayor que“, “Menor o igual que” o “Mayor o igual que“. En el caso que nos ocupa, compararemos si la respuesta dada por el jugador es igual a “Geocacheando el mundo”.

b) Answer: Esta expresión contiene el valor de la respuesta dada por el jugador al input propuesto. Sirve no sólo para compararla con el texto correcto de la respuesta, sino, por ejemplo en el caso de un Input numérico y a través de un SET, convertir una variable en el número dado para, por ejemplo coger un número determinado de monedas como se verá más adelante.

Así, lo que debemos hacer a continuación es arrastrar la ExpresiónCompare” a “Drag Actions here“:

comparePosteriormente, arrastraremos la Expression Answer al lado izquierdo de la igualdad planteada y, en el lado derecho escribiremos “Geocacheando el mundo” sin comillas:

compare answerPor último en el “Drag actions here” que se ha generado bajo la igualdad, colocaremos todas las consecuencias que se deben producir para el caso de que el jugador conteste a la pregunta de forma correcta. Podemos colocar Dialogs, activar Tasks, hacer visibles e invisibles zonas, etc… En este caso, únicamente colocaremos un Dialog que le informe que la respuesta es correcta:

Imagen2A continuación debemos programar lo que sucederá en el caso de que se escriba una respuesta distinta a “Geocacheando el mundo”. Si quisieramos establecer lo que ocurriría con otra respuesta concreta crearíamos la misma estructura. Por ejemplo si quisieramos crear una consecuencia para la respuesta “WordPress.com”, deberíamos hacerlo como muestra la siguiente imagen:

Imagen2Sin embargo, no es este efecto el que queremos obtener, pues si escribiéramos cualquier otra respuesta diferente de “Geocacheando el mundo” o “WordPress.com”, no obtendríamos ninguna consecuencia. Para que cualquier otra respuesta distinta a la correcta nos lance el Dialog “RESPUESTA INCORRECTA. VUELVE A INTENTARLO” y se vuelva a plantear el mismo Input, no debemos establecer ninguna comparación en el cuadro de la derecha, programando simplemente la consecuencia para cualquier otra situación distinta de la planteada en la izquierda, es decir, para el ELSE, tal y como se ve en la siguiente imagen:

Imagen2Como puede verse, al introducir cualquier erronea, el jugador vería el texto “ESA RESPUESTA ES INCORRECTA. VUEVE A INTENTARLO”, el jugador presionaría “OK” y el cartucho volvería a plantearle la misma pregunta, pues esa es la opción que hemos elegido para este caso.

INPUT DE TIPO NUMBER

A continuación vamos a ver un ejemplo distinto en el que, a través de un input de tipo NUMBER  en el que se preguntará al jugador cuantas monedas quiere coger, consigamos que dependiendo de su respuesta, la variable numérica que representa la cantidad de monedas que el jugador posee en su inventario sea igual a ese número.

En primer lugar debemos crear dicha variable siguiendo las instrucciones que vimos en la entrega anterior del tutorial, dándole un valor inicial de 0.

A continuación crearemos un Input de tipo NUMBER en el que en el cuadro “Question” escribiremos “CUANTAS MONEDAS QUIERES COGER?”. Por último en su “On get input“, “Unhandled” simplemente tendremos que establecer que la variable “MONEDAS” tenga el valor seleccionado por el jugador en su “ANSWER” a traves de un sencillo SET, tal y como se puede ver en la siguiente imagen:

Imagen2Así, el SET haría que la variable MONEDAS fuera igual al número que hubiera respondido el jugador y, a continuación, una sucesión de Dialogs informaría de cuantas monedas hubiera cogido.

INPUT DE TIPO CHOICE

Por último, vamos a programar un input de tipo CHOICE para el caso expuesto anteriormente en el que al llegar a una puerta cerrada, se plantee al jugador dos opciones: “ABRIR LA PUERTA” y “LLAMAR A LA PUERTA”. Para ello debemos volver al input que creamos al iniciar la entrada y que se corresponde con la siguiente imagen:

CHOICEA continuación, en su “On get input” debemos crear una estructura IF / ELSE en la que comparemos si la respuesta dada por el jugador se corresponde textualmente con cada una de las alternativas propuestas en el cuadro de texto “Input choice“, tal y como se puede observar en la siguiente imagen:

Imagen2

De esta manera ya hemos visto como programar cada uno de los tres tipos de Inputs (TEXT, NUMBER y CHOICE) y sólo nos restaría indicarle al cartucho Wherigo el momento en el que tiene que lanzar estas preguntas. Esto se consigue con la ActionInput“, que debemos colocar donde corresponda y, en su interior, el Input requerido. Para ejemplificarlo, vamos a imaginar que llegamos a una zona llamada “Castillo” y queremos lanzar en su “On proximity” el Input de tipo Choice que hemos creado y al que he llamado “PUERTA DEL CASTILLO”. Habría que programar el siguiente evento:

Imagen2

……………………………….

Y hasta aquí llega la entrega de hoy del tutorial. Para aquellos de vosotros que esteis siguiedo EL RETO tendreis que introducir en el cartucho que estais creando un Input del tipo que querais, estableciendo las consecuencias para el mismo que mejor veais y explicarme en vuestro correo que es lo que habeis pretendido hacer.

Compilad un cartucho con extensión GWC utilizando las técnicas que hemos visto hasta ahora y enviádmelas a manupor3@gmail.com

Todas las dudas que pudieran surgir de la explicación, agradecería que no se me plantearan por privado, sino como comentario a esta entrada, para que todo el mundo pueda consultarla, así como la respuesta que, si tengo, daré a la misma.

FELIZ GEOCACHING Y FELICES WHERIGOS A TODOS!!!

Los grandes riesgos de convocar un evento

El desarrollo en grupo de actividades al aire libre y en la montaña es una faceta que cobra un especial protagonismo en el geocaching a través de la figura de los eventos. Cualquier geocacher, de la misma manera en que puede publicar un caché, puede también convocar un evento en la fecha y lugar que haya seleccionado y con un contenido por él determinado previamente. Este evento se publica en www.geocaching.com y, desde ese momento, cualquier persona puede apuntarse y acudir al mismo para disfrutar de una agradable jornada junto a otros compañeros de actividad.

Sin embargo, lo que se concibe inicialmente como una divertida actividad en la naturaleza podría convertirse en un auténtico infierno jurídico para el convocante en el caso de que, durante el desarrollo de la misma, se produjera por cualquier circunstancia un daño personal o patrimonial generador de responsabilidad civil, o incluso penal, pues la jurisprudencia de nuestros tribunales le haría, en muchos casos, responsable del mismo y a responder con su patrimonio de las posibles indemnizaciones por daños y perjuicios a terceros que se generasen.

El artículo 1902 del Código Civil establece la regulación básica de la responsabilidad civil extracontractual, que es la que se genera en base a una relación no derivada de un contrato, como podría ser la que se establece entre el organizador de un evento y sus asistentes. Este artículo dice que “el que por acción u omisión causa daño a otro, interviniendo culpa o negligencia, está obligado a reparar el daño causado”. Para saber cuándo una persona ha actuado sin culpa o negligencia se acude a una obsoleta figura jurídica como es la de haber actuado “con la diligencia propia de un buen padre de familia”, lo que la jurisprudencia y la doctrina han perfilado como el nivel de diligencia, cuidado y previsión propios de una persona media con los conocimientos y experiencia que, en ese momento, tenía el posible responsable civil.

No cabe duda que cualquier actividad desarrollada en la naturaleza, como puede ser un evento de geocaching, no está exenta de riesgos y que quien decide participar en ellas debe conocerlos y asumirlos, adoptando las medidas necesarias para minimizarlos en su desarrollo. Así lo estableció el Tribunal Supremo en su Sentencia de 22 de octubre de 1992 al señalar, respecto a actividades deportivas en general, que “la idea del riesgo que cada uno de ellos [deportes] pueda implicar –roturas de ligamentos, fracturas óseas, etc…-, va ínsita en los mismos y consiguientemente quienes a su ejercicio se dedican lo asumen, siempre claro es que las conductas de los partícipes no se salgan de los límites normales ya que de ser así podrían incluso entrar en el ámbito de las conductas delictivas dolosas o culposas”.

La Audiencia Provincial de Huesca fue incluso un paso más allá en su Sentencia de 19 de Octubre de 2004, al establecer que la asunción del riesgo por parte del deportista se produce “por muy acompañado que se vaya con un guía, que viene obligado a minimizar los riesgos pero que nada puede hacer para neutralizarlos completamente desde el momento en que el deportista decide adentrarse en el cauce del barranco, que por su propia naturaleza en un medio poco hospitalario”.

Pese a esta contundente declaración jurisprudencial por la cual cada geocacher debería convertirse en responsable de los riesgos que asume de forma voluntaria en un evento, sería absurdo e ingenuo interpretarla literalmente y de forma absoluta en cualquier caso, pues podría generar situaciones en las que un geocacher se viera responsabilizado de unos daños derivados de una actitud negligente por parte de aquella persona que organiza la actividad, lo que produciría una clara ilegalidad al ir en contra del ya comentado artículo 1902 del Código Civil.

La jurisprudencia de nuestros tribunales ha establecido, por estos motivos, que en cualquier grupo que realiza una excursión por la montaña, siempre existe una persona que se convierte en el responsable legal de los demás. Con carácter general se trataría de aquel con más experiencia o conocimientos en este tipo de actividades, pero también lo sería aquel que, por ser el organizador de la salida, se hubiera convertido en la figura jurídica denominada “guía benévolo”, cuya definición encaja a la perfección con la del organizador de un evento de geocaching en muchos casos, pues se trata de la persona que asume la función de guía sin poseer un título que le acredite para ello y sin relación contractual con el resto de participantes, es decir, sin percibir una remuneración económica por su actividad, lidera el grupo y toma las decisiones durante la actividad.

La responsabilidad del guía benévolo, como la del conductor de un vehículo a motor (por poner otro ejemplo con el que todos estamos más familiarizados), es absolutamente irrenunciable. De esta manera cualquier cláusula que se incluyera en la convocatoria de un evento, o que se hiciera firmar a los asistentes al mismo, por la cual se eximiera al organizador de toda responsabilidad transmitiéndosela a ellos, seria nula de pleno derecho y no tendría ningún efecto legal en un eventual juicio. Es más, podría llegar a perjudicar al responsable que la ha establecido o ha hecho firmar esa cláusula al poderse interpretar su intención previa de no adoptar la diligencia mínima que se le exige como organizador.

Analizando la figura del guía benévolo, cuya existencia reconozco que desconocía hasta que he estudiado un poco el tema, podemos imaginar fácilmente situaciones tremendamente injustas en cualquier paseo por la montaña. Por ejemplo, si dos amigos acuerdan realizar un paseo juntos por la montaña para buscar un caché y uno de ellos tiene más experiencia que el otro o, simplemente, utiliza un GPS mientras que su acompañante no, por confiar en la mayor pericia del primero, aquel debería actuar con extrema diligencia para evitar la producción de cualquier daño físico o patrimonial en su compañero, pues de otra manera incurría en responsabilidad civil que podría acarrear una indemnización por daños y perjuicios. De esta manera, sería él quien tendría que estudiar previamente las condiciones climatológicas durante la excursión para evitar que una intensa nevada durante la misma pudiera poner en riesgo a su amigo; sería él quién tendría que asegurarse del correcto estado de las instalaciones por las que van a transitar; sería él quien tendría que seleccionar una ruta sin riesgo hasta el caché y, por supuesto, en caso de accidente, sería él quién tendría que emprender diligentemente todas las actuaciones necesarias para que no se pudiera reclamar posteriormente su responsabilidad civil como guía benévolo.

La buena noticia es que en estos casos, el seguro de responsabilidad civil que incluye toda licencia expedida por las distintas federaciones de montaña de las Comunidades Autónomas, cubren las posibles indemnizaciones originadas. La mala noticia es que no lo hacen en el caso de que el responsable civil lo sea por ser el organizador de una actividad convocada, por ejemplo, en las redes sociales como podría ser geocaching.com, en cuyo caso, debería responder con su patrimonio presente y futuro de las indemnizaciones generadas, con la salvedad de que hubiera contratado un seguro de responsabilidad civil específico para la actividad en cuestión. El precio de estas pólizas de seguro, por lo que he visto, oscilan entre los 5 y los 10 euros por asistente.

Y es en este punto donde me surgen algunas incógnitas. ¿Estaría preparada la comunidad geocacher española para que el organizador de un evento le exigiera a los asistentes al mismo abonar el importe de un seguro de responsabilidad civil como requisito previo e indispensable para participar en él? Intuyo que exigirlo en nuestro país tendría un impacto mucho más negativo que el que pudiera tenerlo, por ejemplo, en Estados Unidos, donde están más acostumbrados que nosotros a contratar seguros privados. Incluso voy un paso más allá: ¿Permitiría Groundspeak y sus revisores que, en el listing de un evento, se estableciera el mecanismo para contratar este seguro antes de realizar el will attend, por ejemplo dando un número de cuenta bancaria para realizar el ingreso del importe del mismo? Por mi parte, no pienso convocar ni un solo evento más sin al menos intentarlo, pues las consecuencias económicas de un accidente durante el mismo podrían ser muy grandes en caso contrario.

¿Y tú? ¿Estarías dispuesto a tener que contratar un seguro de responsabilidad civil para asistir a un evento de geocaching?

Crea tu propio Wherigo (6) TASK Y VARIABLES… Vamos avanzando

Esta entrada forma parte del curso “Crea tu propio Wherigo”: Pincha en los siguientes enlaces para ver las entregas anteriores del mismo:

1: EL RETO

2: COMENZANDO NUESTRO CARTUCHO

3: GRÁFICOS Y AUDIO: LOS MEDIA

4: DE ZONA EN ZONA y tiro porque me toca

5:PERSONAJES Y OBJETOS… dialogando con unos y cogiendo a los otros

……………………..

Wherigo es una marca registrada.

Antes de nada recomiendo encarecidamente leer las guidelines oficiales, así como la sección de preguntas frecuentes para tener claro que podemos y que no podemos hacer a la hora de crear y publicar un caché Wherigo.

………………………

En la entrega de hoy del tutorial vamos a seguir analizando los distintos objetos que podemos crear en nuestro Wherigo. No debemos perder de vista que estos “objetos” hacen referencia a los Objects, y no a los Items que vimos que la entrega anterior. Hasta ahora, los Objects que hemos estudiado son “Cartridge“, “Zones“, “Characters” e “Items” y hoy veremos las “Tasks” (tareas  del jugador) y las “Variables“.

TASKS

Una característica interesante que podemos incluir en nuestros cartuchos más complejos es la de que el jugador pueda acudir al MenúTasks” para comprobar que tareas tiene todavía pendientes en el desarrollo del juego. Estas “tareas” pueden ir desapareciendo del menú a medida que se van completando, o bien ser marcadas como “completadas” para que el jugador pueda comprobar en todo momento la evolución de la partida.

El efecto que el jugador obtendrá al reproducir el Wherigo es el siguiente:

TASKSEn este caso el jugador ya habría completado dos de sus tareas (Ir al inicio de la aventura y conseguir un arma), mientras que aún tendría pendiente de completar “Vencer al Caballero Negro”.

La creación de las distintas “TASKS” y trabajar con ellas es muy sencillo, pues seguiremos un proceso muy similar al de la creación de los Objects que ya conocemos. De esta manera, accederemos a la pestaña “Task”  abriendo el Menú “View” de la barra de Menús de Urwigo y seleccionando Tasks. La estructura de esta pestaña es la misma a la que ya estamos acostumbrados, con una columna central en la que se irán listando las “tasks” que hayamos creado y una columna a la derecha con las propiedades de las mismas.

Pestaña tasksPara crear nuestra primera task seguiremos los siguientes pasos:

1) Pulsaremos el botón “New Item” de la columna central y rellenaremos los distintos campos de la columna de la derecha tal y como viene siendo habitual:

a) Name: es el nombre de la tarea tal y como la verá el jugador. Quizá fuera una buena idea utilizar imperativos como “Ve al Castillo”, “Busca dinero”…

b) Description: Al hacer click en la tarea, el jugador leera una descripción de la misma, los motivos para completarla y todo lo que el programador considere oportuno incluir en este campo.

c) Identifier: No lo utilizaremos.

d) Display: Como siempre, si queremos que esta tarea aparezca en el menú “TASKS” del jugador desde el inicio de la partida dejaremos activada la casilla. Si queremos que aparezca en un momento posterior la dejaremos desactivada para hacerla visible mediante un SET task.display=true cuando sea el momento adecuado.

set taske) Image e Icon: Colocaremos la imagen y el icono que hayamos preparado previamente siguiendo nuestra filosofía de no dejar ni un sólo elemento del cartucho sin representación gráfica.

f) Active: Como ocurría con las Zones, para que el jugador pueda acceder a una task, esta no sólo debe ser visible (Display=true), sino que debe estar activa (Active=true). De esta manera, si queremos que la tarea sea activa desde el principio del cartucho, dejaremos la casilla activada, mientras que si la vamos a activar más adelante, podemos dejarla desactivada y en el momento que sea oportuno hacer un “SET task.active=true“.

g) Complete: Las task activas tienen dos posibles estados: completada y pendiente de completar por el jugador. Esta casilla, de dejarse activada, haría que la tarea estuviese completada por el jugador desde el principio de la aventura, a lo cual no consigo encontrarle ninguna aplicación práctica interesante, por lo que lo habitual será dejarla desactivada y, una vez el jugador haya realizado esa misión, pasarla a “completada” mediante un “SET task.complete=true“.

h) Correctness: Sirve para establecer si la tarea se ha completado de forma correcta o incorrecta por el jugador. Esto podría ser utilizado, por ejemplo, para establecer dos finales diferentes según se haya realizado una tarea de forma correcta o no. En cualquier caso, existen distintas alternativas a esta opción, por lo que no es especialmente importante en mi opinión.

i) Events: Podremos crear eventos relacionados con las task para los casos en que sus propiedades “Active“, “Complete” y “Correctness” cambien  su estado, así como para cuando se haga click sobre ella en cualquier momento.

Una vez creada nuestra task, procederemos a trabajar con ella como estimemos oportuno. Por ejemplo, si hemos creado una tarea inicial denominada “Ve al punto de inicio“, deberemos marcarla como completada cuando el jugador llegue a este punto:

Imagen2La misma estructura deberíamos seguir para cualquier otro cambio que queramos realizar en la task (desactivarla, hacerla invisible, cambiar su imagen, icono, nombre o descripción, marcarla como completada correcta o incorrectamente, etc…

…………………………………..

VARIABLES

Las variables son un Object un poco más avanzado que el resto de los que hemos visto hasta ahora. Se trata de un valor que puede consistir en un texto, un número, o bien en un valor Verdadero o Falso. Su principal utilidad es que, tal y como indica su nombre, el valor otorgado en un comienzo a la variable puede ser modificado  tantas veces como queramos durante el desarrollo del Wherigo. Las aplicaciones que se le pueden dar a las variables son muchas:

1) Una variable numérica puede indicar al cartucho cuantas monedas tiene en su poder el jugador. Podemos otorgarle un valor inicial de 0 y que este se vea incrementado según vaya consiguiendo monedas. Así cuando el jugador seleccione su Item “monedas” podriamos crear un “Dialog” que le dijera “Tienes X monedas” en función del valor que tenga la variable en ese momento.

2) Una variable texto podría contener el nombre de un “Character” (personaje no jugable). En un principio podría ser “Desconocido” y, una vez el jugador haya hablado con el, podríamos cambiarlo a “Fulanito“.

3) Una variable Verdadero/Falso (al igual que una numérica) podría usarse para crear situaciones más complejas. Por ejemplo, si al llegar a una zona su valor es verdadero ocurra una cosa, mientras que si es falso ocurra otra.

La creación de las variables es mucho más sencilla que la del resto de Objects que hemos visto hasta ahora, ya que hay muchos menos campos que completar en su columna de propiedades. Para crearlas seguiremos los siguientes pasos:

1) Accederemos a la pestaña “Variables” a través del menú View de la barra de menús de Urwigo y seleccionaremos Variables. Se abrirá una pestaña como a las que estamos acostumbrados con una columna central en la que se listarán las variables que hayamos creado y una columna a la derecha con las propiedades de las mismas.

Variables2) Pulsaremos el botón “New Item” de la columna central y rellenaremos los siguientes campos de la columna de propiedades:

a) Name: Es el nombre de la variable. Un cartucho complejo puede llegar a tener muchas variables y muy similares entre si, por lo que debemos ponerle un nombre lo suficientemente representativo como para no equivocarnos al utilizarla en lugar de otra.

b) Descriptión: Usaremos este campo para escribir algún tipo de descripción que nos ayude en el trabajo posterior. Por ejemplo identificando lo que significa cada valor numérico en una variable de este tipo: “0=sin espada 1=con espada”, por ejemplo.

c) Identifier: Como viene siendo habitual no utilizaremos este campo.

d) Value: Aquí seleccionaremos el tipo de variable que vamos a utilizar (numérica, de texto o Verdadero/Falso), así como el valor que tendrá al comienzo del cartucho., que escribiremos en el cuadro correspondiente en cada caso.

Y ya tenemos nuestra primera Variable creada.

El trabajo con las variables es extremadamente sencillo. Utilizaremos SET para ir cambiando el valor de la misma a nuestra conveniencia. Por ejemplo, con la siguiente instrucción, cuando el jugador llegara a la zona “punto de inicio”, la variable correspondiente a las monedas pasaría a tener un valor numérico de “3“.

Imagen2Más adelante, cuando sepamos utilizar Expressions como “Compare” o Actions como “If/Else“, será cuando el trabajo con ellas adquiera todo su potencial. Por ahora nos conformaremos con saber crearlas y modificarlas.

………………………………………

Y hasta aquí llega la entrega de hoy del tutorial. Para aquellos de vosotros que esteis siguiedo EL RETO tendreis que modificar ligeramente el cartucho que habeis creado hasta ahora. Recordemos que hasta este momento, el jugador llegaba a una zona donde tenía una pequeña conversación con otro personaje, se le hacía entrega un objeto que debía transportado hasta otro personaje en una segunda zona. Pues bien, las pequeñas variantes que introduciremos hoy serán las siguientes:

1) Crear una TASK invisible desde el comienzo que se llame “ENTREGA EL OBJETO“. Haremos visible y activa esta task en el momento en que el primer personaje nos haga entrega del item y, por último, le cambiaremos el estado a “COMPLETADA” cuando en efecto se haya completado.

2) Crearemos una variable numérica llamada “OBJETOS EN EL INVENTARIO” con un valor inicial de “0″, que se convertirá en “1” cuando nos hagan entrega del Item y volverá a valer “0” cuando cumplamos el encargo de dárselo al otro personaje.

Compilad un cartucho con extensión GWC utilizando las técnicas que hemos visto hasta ahora y enviádmelas a manupor3@gmail.com

Todas las dudas que pudieran surgir de la explicación, agradecería que no se me plantearan por privado, sino como comentario a esta entrada, para que todo el mundo pueda consultarla, así como la respuesta que, si tengo, daré a la misma.

FELIZ GEOCACHING Y FELICES WHERIGOS A TODOS!!!