Existen muchas herramientas que sirven para crear aventuras conversacionales, pero me he encontrado que ninguna termina de ajustarse a mis necesidades. Así que, permíteme explicar por qué estoy reinventando la rueda.

La primera característica que debía cumplir es que debería estar programada para soportar la conjugación verbal y la concordancia de número y género de las expresiones, como en español. La mayoría de las herramientas están escritas y pensadas para inglés. Sus adaptaciones al español suelen ser farragosas, incompletas y dejan mucho que desear, pues son añadidos para herramientas con visiones muy limitadas de la lingüística.

La segunda especificación es que debería poder soportar «aventuras multijugador». La mayoría de las herramientas de creación de narrativa interactiva están pensadas para aventuras unipersonales.

Las dos características anteriores las cubre AGE⁴, pero presenta otro problema: está realizado en Java. Hace tiempo que no se actualiza y es posible que esté abandonado (hace tiempo que no hablo con su desarrollador) y, por otro lado, los applets de java están considerados malware por defecto, desde que Micro$oft® quiso arrebatarle a Java su preponderancia con .Net.

Lo pensé algunos días. Lo consulté con algunos amigos del ambiente de la ficción interactiva, y finalmente me decidí a hacerlo desde cero. Las opciones que tenía era hacerlo a partir del MUD que ya había programado en erlang o retomar el proyecto de Trókola⁵. He optado por lo segundo.

Cuando inicié el proyecto de Trókola tenía previstos algunos puntos que me parecían mejorables a la hora de simular el mundo. Al diseñar este tipo de herramientas es delicado determinar qué cosas debe hacer el modelo y qué otras cosas se dejan para que decida el programador de la aventura. Si te pasas implementando características en el mundo, tu modelo puede ser demasiado rígido. Si no llegas, obligas al programador de aventuras a programar casi desde cero cada aventura.

El modelo espacial de mundo, en la mayoría de las aventuras conversacionales y MUD's, se basan en el concepto de room: una localización donde el jugador puede realizar algunas acciones. Puede examinar los objetos que hay en ella, coger y soltar objetos, examinar cada uno de ellos o utilizar alguna de las salidas, para cambiar de room. Son suficientes sólo para simular habitaciones no muy grandes.

El modelo temporal de mundo, en la mayoría de los casos, se basa en el concepto de «turnos». Cada turno viene determinado por cada comando que escribe el jugador. Aunque hay algunas herramientas que soportan el tiempo real, lo habitual es que en las aventuras conversacionales esté suspendido el tiempo entre comandos del usuario y éste pueda reflexionar cuál será su siguiente paso sin presiones de tiempo.

El modelo de interrelación con los objetos, se basa en el inventario. Cada jugador tiene un inventario, muchas veces infinito, de cosas que puede portar, sin especificar si en la mano o dónde. Un objeto pasa a su inventario o sale de su inventario cuando lo obtiene o cuando lo suelta. Se obvia dónde se guardan los objetos y pocas veces, a no ser que sea importante para la resolución de algún puzle, se tiene en cuenta si lo lleva en la mano o no, a la hora de utilizarlo, o cuántos objetos sostiene en la misma mano. Algunos sistemas implementan también la cuestión por pesos, pero raramente he visto usarlo y la mayoría de autores prefiere seguir ignorándolo.

Cuando inicié el proyecto de Trókola tenía estos tres aspectos en mente, con la intención de mejorar el modelo de mundo. Al modelo espacial quería añadirle el concepto de zona. El modelo cerrado, es ideal para simular cuevas, calabozos o entornos cerrados pasando de una localidad a otra, siendo estas independientes y generalmente pequeñas. Simular un patio, un jardín o un gran espacio con múltiples posiciones o lugares, es complejo en estos sistemas, porque son espacios abiertos, por los que te puedes desplazar, que te permiten ver e interactuar con lo que haya en distintos lugares del mismo. En mi proyecto, quiero que las zonas puedan agrupar distintas localidades y que lo que haya en esa zona sea visible para toda la zona abierta. También puede haber localidades cerradas en la misma zona. Por ejemplo, en un jardín donde hay una caseta para el perro, no puedes ver lo que hay dentro de la caseta, a no ser que te asomes, pero sí lo que hay en el porche de la casa: la caseta sería una localidad cerrada mientras el porche sería una localidad abierta aunque las dos pertenezcan a la misma zona.

Con respecto al modelo temporal, quería implementar la elección entre «turnos» y «tiempo real» a elección del programador de la aventura. Incluso que se pudieran mezclar y que se pueda aplicar uno u otro dependiendo de la acción. Mi intención sigue siendo esa, aunque al añadirle la opción multijugador, veo más factible la implementación de juegos en «tiempo real», porque si no, cada turno dependerá de que todos los jugadores hayan hecho o no, su acción... aunque supongo que será algo que deba decidir y programar el que implemente la aventura.

Por último, la gestión del inventario era otra de las consideraciones que tenía en mente cuando inicié el proyecto. Si pensamos que lo que llevamos lo portamos en el sitio más habitual: las manos; no es factible llevar quince cosas... o dos. O imagina que quieres atornillar algo y en la mano tienes un destornillador y un huevo de gallina... ¿podrías hacerlo sin romper el huevo o lo soltarías? En fin, el sistema que había pensado era establecer una variable de manejabilidad a las cosas y otra a los personajes. Por ejemplo, un personaje con manejabilidad 4, podrá portar cuatro objetos de manejabilidad 1; o uno de 3 y otro de 1; o dos de 2; y no podrá llevar objetos de manejabilidad 5 salvo en condiciones especiales. Por supuesto, será el programador de la aventura el que pueda seguir o ignorar esta herramienta.

Por qué elegí Tcl⁶ es otra cuestión. Hay que tener en cuenta que es un lenguaje minoritario, incluso desconocido para muchos, a pesar de ser bastante antiguo. Posiblemente sea más conocido su toolkit gráfico, Tk, porque lo utilizan otros lenguajes como Python o Perl. En mi caso, Tcl me gustó porque me gustan los lenguajes simples y éste lo es. En él, todo es una cadena de caracteres, no hay tipos todo son cadenas, el código es una cadena, todos los datos son cadenas. Además, si evalúas una cadena, se comporta como código. De hecho, la descripción del modelo de mundo del proyecto es una cadena, con estructura de diccionario, se carga como código y se escribe como cadena. La acción de guardar partida es, literalmente, escribir en un archivo la cadena y recuperar la partida es leer el archivo como código.

Esta característica, por tanto, permite que la metaprogramación sea sencilla: un procedimiento puede devolver una cadena que sea código. El lenguaje es homoicónico, como LISP, es decir: todas las instrucciones tienen la misma estructura:

nombreComando [argumentos]

Por ejemplo, para definir un procedimiento se utiliza el comando proc, que tiene la siguiente forma:

proc nombreProcedimiento {argumentos} {código}

Esta característica me recuerda mucho a Scheme o LISP. Por ejemplo, la asignación no utiliza un operador, sino el comando set:

set x 12

El añadido de metaprogramación es importante, para dar la oportunidad al creador de las aventuras a añadir y/o modificar el código que hace funcionar el modelo de mundo. Por ejemplo, para poder añadir acciones a determinados objetos o personajes. En otros sistemas como AGE, que mencioné con anterioridad, se utiliza el método parseCommand(). Y aunque aún no está desarrollado, pues estoy en las fases iniciales del proyecto, sí espero que sea relativamente fácil implementar un sistema afín.

El sistema que estoy programando no está orientado a objetos, aunque también lo soporta Tcl. Desde la versión mayor 8.6 el módulo TclOO es de los que vienen en la distribución base. De momento, me parece más sencillo mantener el modelo de mundo como un diccionario. Las entidades que representas los objetos, los personales, las localidades, etc. se guardan en pares key / value, donde el valor es también un diccionario que contiene las características de la entidad que representa. Las peticiones del jugador se recogen y el sistema reacciona, modificando y/o mostrando parte de la información del diccionario.

Lo primero: lo que aprendo haciéndolo, eso no me lo quitará nadie aunque el proyecto termine estrellándose por otros motivos⁷. Lo segundo y más importante: añadir al valor propedéutico de la narrativa el trabajo en equipo con una actividad que puede ser divertida si está bien dirigida, fomentará la comprensión lectora, fomentará la imaginación, fomentará la colaboración.

A unas malas, lo que espero es que, al menos, pueda programar una o dos aventuras y jugarlas con los colegas.