Una de mis inspiraciones en todo esto de hacer videojuegos es la serie “Elige tu propia aventura”. Esta serie de libros no se leen de principio a fin, sino que comenzando desde la primera página, el libro te plantea una elección al final de cada segmento (que generalmente se extiende por una sola página). Dependiendo de la elección que hagas, el libro te instruye saltar a una página u otra.
Este formato es uno de los primeros que surgió cuando los videojuegos se popularizaron, y se llama Ficción Interactiva (o Interactive Fiction, en inglés). No hay casi nada nuevo en este formato, tan solo que las herramientas para escribir ficción interactiva se han simplificado muchísimo. El objetivo de este artículo es hacer una introducción al tema y sugerir una herramienta que puedes utilizar para crear tus propias historias.
Hace un par de meses me di la oportunidad de escribir una historia interactiva, se llama La Línea. Era algo que había querido hacer desde hace ya algún tiempo, y había escuchado una herramienta que permitía hacer esto fácilmente, en un formato muy simple de distribuir, páginas en HTML.
Uno podría ciertamente escribir la historia con HTML, pero esto implica concentrarse en los detalles del formato, cuando lo que hace falta realmente es concentrarse en los detalles de la historia que uno quiere contar. Lo ideal es tener una herramienta donde puedes escribir, y sin muchas vueltas poder establecer las partes que quieres que enlacen con otras. Si ya has tenido suficiente práctica con la herramienta, hasta podrías pensar en que quieres establecer algunas condiciones para ofrecer una opción (por ejemplo, digamos que quieres revisar toda una habitación antes de seguir adelante).
Lo bueno es que estas herramientas existen, y voy a listarlas a continuación. Eso sí, una buena práctica antes de comenzar a escribir es revisar y ver qué han hecho otras personas con estas herramientas. Este es un listado de sitios (†) donde puedes leer buena ficción interactiva:
Twine, esta es la herramienta que utilicé para La Línea, y hablaré un poco sobre ella más adelante. Tiene una versión que puedes usar en línea, por lo que puedes comenzar ahora mismo, incluso en un dispositivo móvil.
inklewriter, de la misma gente de Inkle. Tuve la oportunidad de probar un poco esta herramienta, y me pareció muchísimo más simple de utilizar que Twine, ya que tiene una interfaz mejor lograda para escribir y agregar opciones. Sin embargo, Twine ofrece un poco más de flexibilidad en comparación. Como es una página web, lo puedes utilizar en un dispositivo móvil.
Seltani, permite también la participación colectiva para escribir. Permite también un poco de código.
Inform, es un sistema de programación hecho para que los jugadores escriban instrucciones para avanzar en la historia.
Un poco sobre Twine
De todas estas opciones sólo he podido probar las dos primeras que mencioné, y en ambas me encontré con herramientas que insisten en salirse de tu camino a lo que es realmente importante: escribir una historia. Una ventaja de Twine es la posibilidad de descargarlo a la computadora y poderlo utilizar completamente fuera de línea, utilizando solamente un navegador moderno.
Para escribir una historia en Twine debes crear pasajes de texto, representados visualmente como recuadros), y luego enlazas los pasajes de texto con hiperenlaces, rodeándolos con doble corchete [[así]], muy al estilo Wikipedia
Lo otro interesante de Twine es la posibilidad de utilizar macros para hacer un mínimo de programación para la historia. Por ejemplo, podrías tener un contador para saber cuántas veces ha leído el jugador un cierto texto, almacenar el nombre de alguien y mostrarlo dentro del texto, mostrar variaciones de un mismo texto para que no se haga monótono. Lo importante del asunto es que no requiere algo por separado, lo puedes escribir ahí mismo junto a tu historia.
Espero que este artículo te anime a escribir historias. Y si tienes alguna hecha, puedes subirla a algún lugar al estilo neocities y enlazarla en los comentarios. ¡Buena suerte!
(†) Este listado fue tomado de un taller corto sobre el tema con Emily Short, síguela en Twitter para buena información sobre ficción interactiva. He aquí otros enlaces interesantes:
Intfiction forum, un lugar de reunión para autores y jugadores de ficción interactiva.
20_8 es un juego basado en los hechos que ocurrieron en la frontera colombo-venezolana a partir del 20 de agosto de 2015. Ante la muerte de un militar en la frontera, el gobierno señaló como culpables a paramilitares colombianos que huyeron hacia la frontera. Como respuesta, el gobierno cerró la frontera en el Estado Táchira a casi todo tipo de tránsito, un cierre que hasta la fecha de publicación de esta nota, sigue en pie, sin perspectivas de levantarse.
Surgió días después del cierre de frontera, que militares venezolanos habían pasado por casas cercanas a las fronteras, entrando a las casas, marcando aquellas que pertenecen a colombianos (aun naturalizados venezolanos, con cédula) con la letra D, de demoler, y deportando a sus habitantes, enviándolos hacia Colombia.
En 20_8 participan dos jugadores, uno se encarga de marcar las casas, y el otro se encarga de manejar la excavadora para demoler sólamente las casas marcadas con la letra D. Debes hacer el mayor puntaje en una partida, y sólo te puedes equivocar tres veces. El juego por el momento requiere tener instalado Adobe Flash.
Si esto te parece una injusticia, si crees que esto lo debe saber todo el mundo, y quieres comunicarlo a todos los medios, te invito a jugar Tele, una vista a cómo los medios se manejan dentro de Venezuela. (NB, ¿sabías que hay un nuevo canal de TV donde antes estaba La Tele?)
Puedes ver el video del anuncio del juego a continuación:
El pasado julio se hizo el Venezuela Duel Jam, un game jam online que invitó a varios desarrolladores a hacer juegos en torno a un tema bastante peculiar:
Pueden ver a todos los participantes en la página del jam en itch.io. Los ganadores en esta ocasión fueron los juegos Chicks (por Fiery Squirrel), Chicken Rights (por bellick4) y Psycho Chicken (por TriBrain, Tomas Bruckner Kambo, y warles34).
Si has tenido que entregar un trabajo escrito, o un proyecto para la universidad, muy probablemente has tenido esto en tu escritorio:
Es muy importante darse cuenta de que un documento que escribes, ya sea código fuente, documentación, un libro, una tesis, no es solamente el producto que entregas al final. Es también el proceso de pensamiento por el que pasas para poder llegar a ese producto.
Ese proceso muy rara vez es lineal. Muy pocos libros se escriben comenzando desde la introducción, y escribiendo cada capítulo en orden. Muy pocos proyectos de software comienzan con la pantalla de inicio.
El proceso de pensamiento en muchas ocasiones es caótico y desordenado. Pero sobre todas las cosas, los pensamientos son orgánicos, tenemos decenas de pensamientos cada día, pero solo algunos de estos se quedan en la mente. Algunos de estos pensamientos son difíciles de concebir, de hacer crecer, mientras que otros parecieran que crecen más rápido que nuestra misma capacidad de concebirlos.
Cada idea que tenemos es el resultado de ensayar varias posibilidades. No podemos escogerlas todas, hay que tomar decisiones en el camino. Algunas veces es muy conveniente poder ir atrás en el tiempo, y explorar otra posibilidad, lo que lleva la idea por otro camino.
Un control de versiones es un software que facilita este proceso. Es capaz de tomar fotos de un documento y compararlos en el tiempo. En cada comparación podemos ver qué cosas se agregaron, se quitaron o se cambiaron. Es capaz de tomar una de esas fotos y formar una línea de tiempo. Todo lo escrito va para un repositorio, el cual preserva toda esta información.
Pero de todas las funcionalidades, la más importante es tener la capacidad de comunicar y compartir cambios en el documento/código a otras personas que están trabajando sobre el mismo proyecto. En casi todos los sistemas el proceso es similar: cada integrante descarga una copia del proyecto a un “directorio de trabajo”, allí hace los cambios, y luego manda los cambios de vuelta al repositorio. El sistema incorpora los cambios hechos por otros participantes de la manera más transparente posible, pero si no es posible integrar los cambios (por ejemplo, dos personas cambiaron la misma línea de texto), entonces el sistema deja al usuario el trabajo de seleccionar cuáles cambios continúan o se revierten.
No es mi objetivo enseñar específicamente cómo utilizar un control de versiones. Creo que hay recursos en línea que son mucho mejores y están disponibles inmediatamente, y a los que haré referencia al final del artículo.
Si escribo esto, es para animar a aquellos interesados en programar a que aprendan también a manejar un control de versiones. Esto es algo que muchas veces se aprende en una oficina y no en una universidad (donde supuestamente se aprende esta clase de cosas).
Por otro lado, muchos escritores no tienen el conocimiento tecnológico para incorporar un control de versiones en su trabajo (¿instalar un servidor?, ¿cómo guardo mis cosas?). Sin embargo, ver un recurso como GitBook me hace pensar que es posible traer a los escritores las ventajas del control de versiones sin pagar tanta penalidad en el aprendizaje de su manejo. Si eres escritor regular me gustaría saber tus opiniones al respecto.
Si necesitas saber más sobre el control de versiones, el libro Version Control By Example, de Eric Sink, es una de los mejores libros que he leído sobre el tema, e incluye los sistemas más populares. Si tu intención es, además, ser desarrollador profesional de videojuegos, en algún momento te encontrarás con Perforce, el cual es un servidor centralizado, similar a Subversion. Cuenta además con una versión gratuita para un límite de usuarios, lo que te permite probarlo sin costo alguno.
Últimamente he observado en varias comunidades de desarrolladores de videojuegos la tendencia a idealizar las herramientas que utilizamos, quizás hasta el punto de excluir la posibilidad de que existan otros puntos de vista.
Comparamos engines, lenguajes de programación, hasta pipelines completos de desarrollo. No es que esto sea malo, la verdad es que aprender a utilizar alguna de estas herramientas (o conjunto de herramientas) requiere invertir tanto esfuerzo que entiendo la necesidad de sentir que hemos hecho la elección correcta y, por lo tanto, destacar las bondades de la herramienta.
También es cierto que es muy difícil anticipar cómo se va a comportar una herramienta ante un proyecto. No es lo mismo hacer un juguete que algo que sea entregable. La herramienta puede tener limitaciones que no eran conocidas al momento de comenzar, o se comporta lentamente, o la recolección de basura pone el juego lento en momentos al azar.
Pero uno de los vicios, si así lo puedo llamar, es hacer la comparación de las herramientas empleando el material de marketing o los juegos más exitosos del momento. Dado el nivel de muchos desarrolladores noveles, no creo que les sean útiles muchas de las últimas características novedosas de tal o cual herramienta, pues suelen ser cosas que en cada versión van aumentando en complejidad. Son características que multiplican la productividad o los resultados si has hecho el trabajo indicado al momento en que aparecen, pero no agregan beneficios si apenas estás comenzando.
Cada desarrollo es un proceso largo y complejo, conformado por muchos pequeños momentos que se suman y forman algo más grande. Ese material de marketing que vemos está hecho precisamente para eso, para difundir las bondades del engine que se te está vendiendo, muy probablemente sin cubrir tu caso de uso, que suele ser más complejo u oscuro de lo que parece. El juego que estás alabando muy probablemente tuvo que tomar más de un atajo para lograr el resultado que estás viendo. Quizás todo esto sea porque me gustaría ver más juegos hechos, y no tanto “mira qué maravilla [tal característica] de [tal engine]”.
Mi recomendación, si es que quieres seguirla, es que siempre cuestiones lo nuevo que sale. Si has visto un juego hecho con una determinada herramienta, sea cual sea, significa que existe la posibilidad de hacerlo. Por tanto, lánzate a hacer tu juego con esa herramienta que conoces. Verás que esa herramienta que alabas tanto tendrá sus dificultades y sus achaques. Eso es algo bueno, significa que esa herramienta tiene posibilidades de mejoras. Si es un producto hecho en comunidad, significa que puedes ingresar a la comunidad de desarrolladores y participar allí, sugiriendo mejoras, e incluso hacerlas tu mismo y subirlas.
Foto por