Sobre programación de aventuras conversacionales (ACs) se ha dicho mucho, muchísimo diría yo. La mayoría de los fanzines de aventuras han dedicado, en algún momento de su historia, parte de su contenido a cursos de creación de aventuras: artículos sobre programación de PSIs, laberintos, diseño de guiones, problemas y un largo etcétera. [ Por cierto, que de todos ellos, EL CURSO con mayúsculas es y seguirá siendo el vertido por Andrés Samudio en la revista Microhobby hace ya algunos años. Recientemente ha sido transcrito a formato a HTML y los puedes conseguir en la página del CAAD. Te aconsejo que si quieres hacer una aventura leas sus jugosos artículos, pues son toda una maravilla avalada por el director de Aventuras AD, creadores de admirables trabajos como 'Jabato', 'Cozumel'... ]

Sin embargo, poco se ha dicho acerca de programación de aventuras conversacionales multijugador (ACMs), que son una mezcla de MUD y conversacional. A ellas nos vamos a dedicar en esta serie de artículos, donde vamos a intentar aprender a programarlas. En esta primera entrega, trataremos de dar una definición más precisa de lo que son, comentaremos algo sus tipos y enumenaremos los problemas que surgen tanto en su diseño como en su programación.

Y antes de meternos ya en materia, añadir que aunque el contenido de este curso está especialmente orientado al desarrollo de aventuras conversacionales, contiene pistas igualmente valiosas para realizar gráficas y juegos de rol por ordenador.

¿Qué es una Aventura Conversacional Multijugador?

Como he comentado más arriba son mezcla de MUD (Multiple User Dungeon) y de las aventuras conversacionales de siempre. Las ACMs tienen de aquellos que varios jugadores están compartiendo un mismo mundo virtual y de aquella que hay un guión de fondo y unos problemas a resolver. No todo se limita, pues, al despanzurramiento existente en la mayoría de MUDs. Tan solo es una AC en la que pueden cooperar (y también competir) varios jugadores.

Al igual que en las ACs podrán ser con gráficos o sin gráficos, pero el texto explicativo no lo quita nadie, porque si se lo quitas deja de ser una ACM y se convierte en véte a saber qué, ¿ok? A mi entender una ACM es la evolución lógica de la conversacional, y no lo que se nos ha presentado como su evolución, la aventura gráfico animada (AGA). Éstas no son más que hijos deformes con las capacidades más interesantes de una AC recortadas o suprimidas del todo.

Veamos, antes de nada, lo que hereda una ACM de una AC:

• se puede programar fácilmente y apenas sin coste (a parte del esfuerzo, claro). No hay que pagar dibujantes, ni artistas 3D ni nada. La base es el texto, la palabra, como en los libros. Las acciones aleatorias son baratas (la bruja que se puede rascar la cabeza, se le cae un moquillo o se pone a barrer) porque están basadas en el texto. Hacer acciones aleatorias en una aventura gráfica implica tener una animación por cada una de ellas, lo cual es extremadamente costoso y por eso no suele hacerse (con la pérdida de ambientación que ello conlleva).

• un buen texto puede crear una magnífica ambientación. Un texto puede sugerir cosas y, lo que es más importante, puede sugerir cosas diferentes a diferentes personas. Así -el ejemplo que siempre acabo poniendo- si ves el gráfico de un dragón, los jugadores ven al dragón que dibujó el hábil dibujante y todos ven el mismo dragón. Si se escribe una descripción exponiendo a parte de su aspecto, el apestoso olor de su aliento, y el apretujón que te mete tu asustado hombre de armas, totalmente cagado de miedo, no todos verán ni el mismo dragón, ni vivirán la misma escena.

• no hay límite en la complejidad que quieras dotar a tu aventura, tanto en guión (una aventura con varias posibilidades de ser resuelta) como en lo que respecta a la simulación del mundo.

• no se necesita un equipo potente para ser disfrutada. Unicamente el que hace de host debe tenerlo si es que la aventura es extremadamente compleja (con rutinas de IA, por ejemplo). Al jugador remoto le sobra con un 386.

Si una AC la veo como una excursión al mundo ideado por el autor, una ACM la veo como una excursión en compañía. Allí, podrán cooperar para conseguir realizar una misión, o dividirse en grupos y competir entre ellos. De hecho, el abanico de posibilidades que abre una ACM es realmente impresionante, sobre todo si cada jugador encarna a un personaje con características diferentes. Así, puede ser que el personaje con mayor percepción descubra, entre los escombros, un anillo que los demás no ven. Puede que ese alguien decida cogerlo disimuladamente para él, o puede que informe a los demás acerca de su descubrimiento. Puede que un problema tenga que resolverse con colaboración, el típico bloque de piedra que bloquea la entrada a las cavernas pueda ser alzado (no sin dificultad) por el jugador bárbaro de dos metros.

Desde luego, los juegos tipo rol se prestan muy bien a una adaptación a ACM, y estoy seguro que en un futuro no muy lejano vamos a tener varios de ellos en circulación. Los juegos ambientados en Dungeons & Dragons serán muy interesantes, pero también lo serán desde los ambientados en los mitos de Cthulhu, pasando por la guerra de las galaxias (¡me pido el ewok!) y hasta por fanhunter. Aunque todo no va a ser estilo rol, con características y tal, vamos digo yo. También sería muy interesante una versión de la aventura original en multijugador, por ejemplo. Y la mayoría de las aventuras conversacionales que incluyan un PSI que acompaña al jugador en la mayor parte de la aventura, también serían candidatas perfectas para ser convertidas en ACM.

¿En qué lenguaje se pueden programar las ACMs?

Primero y fundamental es que el lenguaje que vayamos a utilizar tenga soporte TCP/IP, para que el ordenador que hace de host (el que tiene todos los datos de la aventura y ejecuta los comandos de los jugadores) y los ordenadores cliente (los de los jugadores) se puedan conectar y así intercambiar información. Si no hay conexión, poco multijuego va a poder haber, ¿no es cierto?

Así pues, no tenemos un abanico demasiado amplio de lenguajes donde elegir. Se puede usar C/C++ o cualquier lenguaje de alto nivel siempre y cuando dispongas de la librería de comunicación adecuada. Otra posibilidad es usar DIV, [risas estridentes del que esto escribe], que según comentan en su página apañará TCP/IP en una próxima versión. Es una posibilidad, de acuerdo, pero no la más adecuada. Para una aventura es muchísimo más adecuado emplear un lenguaje especialmente diseñado para crear éstas, y te adelanto que el más adecuado es GLD. A parte de soporte multijuego TCP/IP, permite orientación a objetos y herencia (ideal para crear ACs y ACMs), orientación a eventos, multitarea, tiempo real y todo tipo de virguerías. Será software gratuito, y estará disponible a partir de abril-mayo de 1999.

Los ejemplos, que a buen seguro inundarán este cursillo, estarán escritos en GLD, pero no hay mayor problema porque lo que es realmente la base puede ser transportado a otros sistemas.

Los problemas que surgen

No esperes que hacer una multijugador sea tarea fácil, porque si se quiere hacer bien hay cosas que habrá que cuidar. De hecho, lo único que podrás permitirte ahorrar serán PSIs (porque ahora algunos de ellos se convierten en personajes jugadores), pero se plantean una serie de problemas. Veámoslos:

1. Problemas de librería

   La librería debe estar adaptada a un juego multijugador. En el momento de escribir esto, ningún parser de ACs tiene una librería (o una base de datos inicial) que lo permita. Para GLD sí que se está haciendo una librería base con soporte multijugador incluido.

   Lo que hace inútil para las ACMs una librería que funciona para ACs, es que ésta presupone que hay un único jugador. Las acciones consultan los atributos de este jugador directamente y, por otra parte, información del estilo de si un objeto es conocido o no por el jugador está asociada al objeto en sí. En una multijugador debe haber existir información no para un solo jugador, sino para todos ellos. Volviendo al ejemplo del jugador que ve el anillo, éste si lo ha visto, pero el resto no. Teóricamente esta info debe estar entre los atributos del jugador y no en el objeto en cuestión.

2. Problemas de resolución de puzzles

   Problemas que quizá no eran resolubles por un sólo personaje, ahora sí que lo son entre varios. A parte de lo de poder sumar fuerzas para levantar objetos pesados, citar coordinación para maniobras de distracción.

3. Problemas de mensajes

   Muy importante, para hacer creíble el mundo y la historia a los jugadores. Dependiendo quién sea el personaje, el texto que se le ha de presentar (de una descripción de localidad o de una acción de otro jugador), puede variar de uno a otro. Por ejemplo, en una aventura, la espada corta puede ser "Una espada de juguete" para el bárbaro de dos metros de altura (y también metro y medio de espalda), mientras que para el ladronzuelo del grupo puede ser "Una espada corta, muy ligera y bella".

   Además hay que cuidar la descripción que los personajes reciban unos de otros. Cuidado con relaciones de parentesco, para X "Y es mi padre", mientras que para Y "X es mi hijo". A más de esto, para el orco la dulce clériga del grupo puede ser "uno de esos humanos sin barba", mientras que para el elfo ella puede ser "una bella humana", y el orco puede ser "un apestoso y feo orco" para nuestra clériga. Para el humano (cuyo personaje está enamorado secretamente de ella), el hecho de que el elfo la mire puede ser reflejado con un mensaje como "Genthen clava los ojos en tu chica", mientras que los demás reciben un mensaje por defecto "Genthen mira a Pepah".

4. Problemas de juego

   Cinco jugadores quedan a una hora para adentrarse en el peligroso castillo de Celkart. Tras una hora de juego, uno de ellos tiene que dejar el juego, por la causa X. ¿Siguen los otros cuatro jugadores sin él o posponen la partida para otra ocasión?

   ¿Y si la palma un personaje? ¿La partida continúa o no? Quizá algunos puzzles del juego queden irresolubles si ese personaje no está presente. En el caso de que los personajes puedan morir durante el transcurso de la aventura, el autor debe prever estas situaciones.

   Otra pregunta que uno se puede realizar es: ¿podrán entrar nuevos jugadores en mitad de una partida? ¿Dónde aparecerán si es así?

5. Problemas de objetos

   En una AC el aventurero podía hallar unas bonitas botas que le permitían cruzar un río de lava (y casualmente las botas eran de su número). Ahora son cinco jugadores los que se van a aventurar por esas mismas cavernas. ¿Pondrás cinco pares de botas? (y demasiada sería la casualidad si encima hay tallas para todos) Si tus aventureros parten sin apenas equipo, vas a tener que equipar no solo a uno, sino a todo el grupo.

   Referente también a los objetos, un problema que sufren los MUDs. Si vas a hacer una aventura-MUD, el problema va a ser que pronto los objetos se agotan, los jugadores se los agencian y no los van a soltar (y el jugador que lleva la corona de los dioses no piensa volver a pasarse por el MUD, por lo que la corona se estanca en su inventario). Los MUDs suelen resolverlo a medias reseteando (inicializando) cada cierto tiempo el estado de los objetos. Problema: en tu mundo pueden acabar coexistiendo veinte anillos únicos...

6. Problemas de PSIs

   Probablemente el PSI que antes se refería a un sólo jugador, ahora se deberá referir a todo un grupo de ellos. ¿Cómo lo hará? ¿Hablará en plural? ¿Preguntará si todos van juntitos? Por ejemplo, cuando entren tres a la vez en la tienda, ¿qué dira el tendero? ¿Saludará a todos ellos por separado o dirá un hola en general a todos?

7. Problemas de declaración de acciones

   En la estupenda Jabato (de AD, of course), estando en la pirámide de Keops, y al encontrarnos con un sarcófago uno tecleaba algo así como: "decir a Taurus 'levanta la losa'", y éste la alzaba. En las multijugador el problema radicaría en si dos jugadores quieren ponerse de acuerdo y cooperar para hacer un trabajo juntos, ya que ellos por separado no pueden. No basta con pedir al otro jugador que levante la losa. Hay que hacerlo simultáneamente y este hecho hay que indicárselo de alguna forma al parser.

8. Problemas de tratamiento del tiempo

   Problema grave, como tratar el tiempo si uno de los personajes pilla un avión, se va a dormir o se va de viaje a Plutón. Si todos los personajes van juntos no hay problema, sí van en grupitos (o cada uno por libre) entonces sí que pueden aparecer dificultades. Habrá que tener cuidado con este tipo de situaciones.

9. Problemas de adaptación según número de jugadores

   Si la aventura puede ser jugada con un número variable de jugadores, entonces en teoría la dificultad de la misma debería ser ajustable. Si la ACM es de espada y brujería con combates y tal, entonces deberían presentarse más o menos enemigos según el número de personajes controlados por humanos. Es más, si algún personaje fundamental no tiene controlador, habría que hacerlo PSI, es decir, habría que tener programado el PSI por si acaso. Si no hay jugador que lo lleve se le mete en la aventura como PSI.

10. Problemas de rejugabilidad

    Si la aventura es posible jugarla tanto en solitario como con otras personas se presenta un problema adicional. Puede que una persona la haya jugado en solitario y ahora le apetezca rejugarla en compañía. Esa persona debería tratar de no adelantar acontecimientos al resto y evitar fastidiar así al personal. Se supone que la juega para probar diferentes cosas de las que en su día probó en solitario. Sin embargo, el autor ha de tratar dar muchas posibilidades en este sentido, que su aventura en solitario sea diferente que en compañía: incluir gran cantidad de detalles aleatorios, que los puzzles se resuelvan de diferente forma en uno u otro caso, etc. La solución radical es hacer tu ACM eso, una ACM pura, no jugable en solitario.

11. Problemas de testeo

    Si testear una compleja aventura ya puede ser complicado, imagina una ACM con media docena de jugadores, cada uno con sus características, que leerán mensajes específicos, responderán a los eventos de diferente forma, recibirán diferente tratamiento de los PSIs que pululan por ahí...

Fin de primera entrega

Ya nos vamos, pero que quede bien claro que las soluciones a todos los problemas aquí citados las iremos viendo a partir de la próxima entrega. Esta primera ha sido una mera introducción, para abrir boca y poco más. En próximos artículos analizaremos también muchas otras posibilidades que nos ofrece el fascinante mundo del multijuego. ¡Espero que no faltes a nuestra cita!

ÚLTIMA REVISIÓN EN ABRIL DE 1999