Trucos Twine – (live:) y (event:)

Éste es el cuarto post de una serie de minitutoriales sobre Twine enmarcados en #LEARNUARY, un esfuerzo colectivo por aprender nuevas habilidades durante el primer mes del año.

Ya comenté en un post anterior que Twine sólo ejecuta el código de un pasaje cuando se entra al pasaje, por lo que si alguna acción del jugador cambia alguna variable dentro de ese pasaje los condicionales que haya en él no se recalcularán para adaptarse al cambio.

Sin embargo, en Harlowe tenemos el comando (live:) que hace que el siguiente fragmento de código que pongamos junto a él se reejecute cada cierto tiempo. Ésto quiere decir que si ponemos (if:), (unless:) o (either:) dentro de hook que esté vinculado a un (live:), éste condicional se reevaluará cada intervalo.

Por ejemplo, nos puede servir para crear una cuenta atrás y que, cuando ésta termine, el jugador sea enviado a un pasaje diferente automáticamente.

Los usos de éste comando son muchos y muy variados. Podemos mostrar un enlace sólo si el jugador está en un pasaje el tiempo suficiente, cómo en el siguiente ejemplo (ésto viene muy bien si queremos recompensar su paciencia o queremos reflejar el tiempo de espera de un personaje)

Sin embargo, tener que crear nuestros propios temporizadores para éstas acciones es bastante pesado, por lo que en Harlowe se ha buscado una manera de automatizarlo y simplificarlo: el comando (event:).

(event:) reune las propiedades de (live:) y un (if:) además de (stop:) que es el comando que se usa para parar toda la secuencia. El ejemplo anterior hace lo mismo que el que habíamos visto pero con mucho menos código. Se activa cuando se carga el pasaje y va contando el tiempo transcurrido, al llegar a 5 segundos ejecuta el hook oculto.

Trucos Twine – Subir tu juego a itchio

Éste es el tercer post de una serie de minitutoriales sobre Twine enmarcados en #LEARNUARY, un esfuerzo colectivo por aprender nuevas habilidades durante el primer mes del año.

Tan importante (¡y difícil!) como terminar los juegos que empezamos es encontrar una manera de mostrárlos a la gente, ya sea para conseguir feedback que nos ayude a mejorarlos, como para poder monetizarlos llegado el caso. Hay infinidad de plataformas para lograrlo, todas ellas con sus pros y sus contras. Para éste post me voy a centrar en utilizar itchio por varias razones, pero principalmente por lo sencillo que resulta y por las facilidades que ofrece a los desarrolladores independientes.

Lo más interesante que nos ofrece itchio es la facilidad con lo que podemos configurar nuestro juego para que se ejecute en casi cualquier navegador. No está completamente optimizado, pero es más que suficiente para subir nuestros primeros proyectos de Twine sin tener que quebrarnos mucho la cabeza.

El primer paso, si no tenemos ninguna cuenta en itchio es crearnos una. Una vez logueados en ella, crearemos el nuevo proyecto desde el menú del perfil como se muestra en la imagen.

La página de nuevo proyecto tiene cantidad de funcionalidades en las que no voy a detenerme mucho, os animo a trastear un poco. La parte que nos interesa es la que está en la zona de Upload.

Es ahí donde subiremos el juego y aplicaremos las opciones adecuadas para que el juego pueda descargarse facilmente, o jugado en el navegador que es casi lo que más nos interesa para los juegos de Twine.

Resalto las partes más importantes de ésta sección.

  • El juego debe estar en .zip. Ésto quiere decir que cogeremos el html de la historia, así como todos los archivos que deban acompañarlo (ilustraciones, sonidos y músicas, etc) que hayamos creado con el editor de itchio y lo empaquetaremos en un zip para subirlo.
  • Dentro del zip debe haber un archivo llamado index.html. Ésto es primordial. Itchio por defecto llama al archivo .html de la historia con el nombre del proyecto, por lo que antes de empaquetarlo para la subida tendréis que modificar su nombre a index.html.
  • Hay que marcar la opción que indico con la flecha para que el juego se ejecute en el navegador.

Un poco más abajo habrán aparecido las opciones de embebido en el navegador. En la siguiente imagen os marco las opciones que yo he podido comprobar que funcionan mejor a día de hoy. El comportamiento varía entre sobremesa y móviles, pero he podido testear que ésta configuración es la que funciona en un rango más amplio de dispositivos. Todo puede variar con el tiempo ya que itchio está constantemente haciendo cambios en su página para mejorar la presentación.

Una cosa que desconcierta a mucha gente la primera vez que sube proyectos a itchio es la doble comprobación que tiene la página para publicar los juegos.

Al principio, la opción «Public» estará desabilitada y sólo nos dejará publicar la página en modo «Draft» o «Restricted», lo que implica que el juego no será público todavía. Para poder ponerlo en modo Público tendremos que dar una primera vez a Save y volver de nuevo a la página de Edit Project, donde ya se nos habrá habilitado la opción «Public». Sólo tenemos que marcarla y volver a darle a Save. Ahora sí, el juego ya debería estar público.

Trucos Twine – Cycling-link y bind

Éste es el segundo post de una serie de minitutoriales sobre Twine enmarcados en #LEARNUARY, un esfuerzo colectivo por aprender nuevas habilidades durante el primer mes del año.

Ésta es una funcionalidad de Twine muy simple, pero muy efectiva para marcar el tono de la historia que estamos narrando y darle al jugador agencia dentro de la misma.

(cycling-link:) nos permite crear un enlace que va cambiando entre distintas opciones cada vez que el jugador hace click sobre él, pero sin abandonar la página. Bien usado nos permite, entre otros muchos usos, darle al jugador la posibilidad de construir una oración a su antojo, o generar la sensación de que el personaje está dudando entre las opciones disponibles.

Combinándolo con el comando bind, podemos almacenar la elección del jugador en una variable que podamos usar más adelante como queramos. La sintáxis quedaría como sigue:

La elección del jugador se almacena de manera dinámica en la variable conforme el jugador pulsa sobre el cycling-link, pero recordemos que Twine sólo ejecuta la lógica de un pasaje al cargarlo. Lo que significa que si creamos un fragmento como el que sigue:

Al pulsar sobre «Ésta es la opción que he elegido», se mostrará en pantalla la opción que estuviera seleccionada (la que fuese visible en el pasaje) en ese momento, pero si tras eso cambiamos a otra opción el texto no variará dado que Twine ya ha ejecutado el (print:) correspondiente.

Uno de los usos más frecuentes del cycling-link es la de almacenar detalles sobre personajes o ubicaciones que luego puedan ser mostrados en descripciones en otros puntos de la historia. Aquí dejo un sencillo ejemplo:


Trucos Twine – Fuentes personalizadas

Éste es el primer post de una serie de minitutoriales sobre Twine enmarcados en #LEARNUARY, un esfuerzo colectivo por aprender nuevas habilidades durante el primer mes del año.

Vamos a comenzar nuestra serie de tutoriales sobre Twine con algo sencillo, pero que ayuda mucho a personalizar las historias que escribamos: importar y utilizar fuentes personalizadas.

Además de la fuente estándar de Twine, podemos utilizar fuentes que sean comunes a muchos sistemas operativos y dispositivos simplemente accediendo al CSS de la historia

Fuentes Personalizadas CSS

y añadiendo la línea:

Fuentes Personalizadas estándar

Pero, ¿Qué hacemos si la fuente que queremos usar no es de las comunes, o simplemente, queremos asegurarnos de que el sistema no nos la cambia?

Hay dos maneras de hacer ésto en Harlowe: mediante un enlace a un sitio web externo o incorporando el archivo con la fuente junto con el HTML y luego «llamándola» desde el código.

Para enlazar a un sitio externo se utiliza el comando @import url, sólo tenemos que buscar la dirección en la que está almacenada la fuente. Yo aconsejo usar Google Fonts, que además de tener una enorme variedad de tipos de letra, carga muy rápido las fuentes personalizadas. Pongamos que quiero utilizar la fuente «Montserrat» (que es la que utilicé en «La Página en Blanco» con un resultado muy bueno en mi opinión) enlazándola desde Google Fonts. Así es como quedaría el código:

Fuentes Personalizadas Import

Cuidado con la sintaxis, si nos dejamos unas comillas o punto y coma el código no funcionará. El mismo Google Fonts nos dice como tenemos que usarla, sólo hay que hacer copy&paste de la sección de @import, ignorando las etiquetas de html.

Fuentes Personalizadas Google Fonts

Por último, en el caso de que queráis incluir una fuente sin tener que enlazar a algún sitio externo, sólo tenéis que descargarosla de la página que decidáis (yo por ejemplo recomendaría DaFont) y acompañarla junto con el html cuando exportéis el juego. Luego sólo hay que usar el comando @import url poniendo en la ruta de acceso el nombre del archivo de fuente que hemos incluido.

Pisadas en la arena – Postmortem

Han sido unos meses algo silenciosos por mi parte, os pido disculpas. Diversas obligaciones me han tenido apartado del blog más de lo que me gustaría. Para hoy vamos a hablar de un juego narrativo que hice como parte de un reto. Pisadas en la Arena.

El juego

Pisadas es un juego que nació a raiz de un reto que puso Ludipe durante una charla que dio en Málaga en el que animó a todos los presentes a terminar un juego antes de que acabase la semana. Una gran manera de motivar a la gente a realmente llevar el desarrollo de un juego hasta el final. Cuando vi el reto lanzado por twitter no pude contenerme, así que a pesar de que ya estábamos finalizando el martes me propuse construir un juego desde cero en el tiempo disponible.

Pisadas en la arena es un juego narrativo creado en INK, el motor creado por Inklestudios. Es una pieza corta cuyo texto engloba aproximadamente 5000 palabras, de las que el jugador en un run normal sólo lee unas 1800 – 2000. Aunque fue realizado en sólo cinco días, ha recibido algunas ediciones para corregir bugs y ampliar algunas partes que se quedaron cortas en la primera redacción.

El concepto

Cuando me senté a hacer el brainstorming quería que fuese un juego sobre la exploración. Darle al jugador un entorno en el que no hubiera «buenas» ni «malas» decisiones, sólo elecciones que hiciesen al jugador libre y constructor de su propia historia.

Revisando uno de los cuadernos en los que apunto ideas y frases sueltas encontré una referencia a una historia que leí sobre un cartel en medio del desierto, a kilómetros en todas direcciones de cualquier punto civilizado. Esa simple imagen disparó algo y comencé a bocetar un entorno onírico en el que cualquier cosa fuese posible.

Al mismo tiempo, el desierto me daba un entorno en el que el jugador podría perderse: en el desierto no hay referencias ni caminos. Además permitía que el jugador se sintiese sólo y hasta desamparado, una buena excusa para hacerle centrarse en la introspección.

Una parte que considero muy importante del sentimiento de exploración es que sólo lo experimentamos en su plenitud cuando no sabemos que hay en los caminos que no elegimos. El saber que algo va a pasar a estar fuera de nuestro alcance hace que el tomar una decisión sea excitante y consigue que reflexionamos mucho más antes de tomarla. Con ésta premisa y un entorno que parecía propicio para conseguir los objetivos que me había propuesto, comencé a bocetar el esqueleto de la historia.

Mecánicas de exploración

El juego comenzaría con una elección que marcaría el tono onírico y surrealista que buscaba, pero además hice que las elecciones no elegidas desaparecieran en cuanto el jugador se hubiera adentrado un poco en su elección. De esta manera si utilizaba una escapatoria para volver al hub, se encontraría conque los demás caminos ya no estaban disponibles. Con ello pretendía animar al jugador a llevar a término sus decisiones, algo que conseguí a juzgar por el feedback que pude recoger de los que lo probaron.

El nudo de la historia era algo más complejo porque quería construir una parte en la que el jugador se sintiese perdido y desamparado, para darle al final una historia que recompensase su esfuerzo.

La sección «perdido» dentro del segundo acto es un nodo en el que el texto se genera de manera aleatoria de entre una serie de fragmentos preconstruidos. El jugador, al elegir un punto cardinal por el que continuar su camino recibiría un fragmento que parecería casi igual al que acababa de abandonar. Todo ésto buscaba hacerle sentir que estaba tomando direcciones equivocadas y dirigirle a las «escapatorias» que aparecían en algunos puntos, que llevaban a uno de los «finales malos» por así decirlo.

Una gráfica de la estructura de Pisadas.

Si el jugador perserveraba el tiempo suficiente, llegaría a un fragmento de historia nuevo, con nuevas posibilidades. El mensaje que se intenta transmitir sigue siendo el mismo «toma tus propias decisiones y llévalas hasta el final». Estas historias llevan a si mismo un mensaje encerrado que dejaré al lector de éstas lineas el descubrirlas sin spoilers.

Una vez concluida esta parte el jugador llega a la conclusión de la historia, en la que tras tomar unas pocas decisiones se despierta en su cama. Ahora afronta el momento de escribir en su diario lo que ha visto y experimentado, junto con algunas reflexiones acerca de ellas. Ésta parte era crucial porque es la cristalización de la exploración del jugador: los fragmentos que aparecerán serán los que haya desbloqueado durante su travesía, un total de 12 de los que en una sesión normal sólo verá dos o tres, lo que anima a la rejugabilidad.

Reflexiones sobre el juego

Realizar éste juego ha sido todo un viaje y nunca mejor dicho. Concentrar todo el desarrollo en cinco días y conseguir escribir tanto en tan poco tiempo ha sido para mi un triunfo. Evidentemente hay errores y muchas partes que se han quedado poco maduras, pero la limitación temporal no permitía muchas florituras.

El objetivo principal era darle al jugador libertad total para explorar la historia sin miedo y además darle la posibilidad de expresarse con sus decisiones. En base al feedback que he recibido recientemente, parece que eso se consiguió.

Cómo práctica de uso de Ink, también puedo decir que ha sido todo un éxito. Tuve que aprender partes del motor narrativo a mucha prisa para poder estructurar la historia. La parte en la que el jugador vaga por el desierto fue la que presentó un desafío mayor por la complejidad del loop que había que hacer. No sólo había que controlar variables, también había que pasárselas a una función que sería la que derivaría al jugador a las historias que se desbloqueaban en su deambular.

Un aspecto que no logré del todo fue mantener el juego libre de género. Durante toda la historia intenté eliminar del texto todo tipo de alusión al género del personaje principal para que cualquier tipo de jugador pudiera sentirse identificado. Se demostró que es una tarea titánica y a pesar de todo en algunos puntos se me escaparon fragmentos en el que usé inadvertidamente el género masculino. Ésto debe servirme para aprender y evolucionar de cara al futuro. Si alguien se siente ofendido/a por el uso del género durante la historia, le pido disculpas y le doy mi promesa de mejorar en el futuro.

Creo que eso es todo por hoy, espero que podáis jugarlo y darme feedback para seguir mejorando. ¡Y no olvidéis que estoy organizando una gamejam narrativa para Agosto! Si queréis más información sobre #RayuelaJam, podéis visitar su página en itch.io.