Planeta Aventurero

Distribuir contenido
Planeta aventurero de CAAD (en pruebas)
Actualizado: hace 17 horas 51 mins

Rayuela Jam 2021: 19 trabajos publicados

Hace 17 horas 51 mins

Ha concluido el período de publicación de trabajos para la edición 2021 de la Rayuela Jam.
La cosecha ha sido abundantísima: 19 trabajos de relatos interactivos para disfrute de la afición.

Las votaciones de la jam en itch.io está abierta sólo a los participantes, pero la organización ha dispuesto de un "premio del público" para que la afición toda vuelque sus impresiones y pareceres: basta con jugar y luego usar este formulario de Google Docs para emitir vuestro voto.

Notar que:

* las votaciones son privadas y secretas
* la lista de participantes está aleatorizada en el voto para no beneficiar (ni perjudicar) a ninguno de los participantes
* es recomendable jugar a la mayor cantidad de juegos posibles, o al menos 5 de ellas, antes de votar
* se puede cambiar el voto cuantas veces se desee hasta que finalize el plazo de votación a las 19:59 del 30 de Junio

Independiente de ello, damos la enhorabuena a todos los autores e invitamos a quienes gustan del género a disfrutar de tan suculentos frutos.

Categorías: Planeta

Creando una aventura de texto VI: literatura y complementos

Hace 17 horas 51 mins

En el sexto y último artículo de la serie me referiré a los elementos complementarios de la aventura.

Notar que digo complementarios porque con lo ya visto hasta el momento es posible crear una aventura completa y plenamente disfrutable: es cuestión de escoger una tecnología o sistema de autoría a nuestro gusto o alcance y ponerse a construirla o programarla. No es un objetivo de esta serie el dar recomendaciones en ese sentido y es asunto del autor el encontrar el mecanismo que más le acomode o aquel que le permita crear con soltura y sin complicaciones.

En cuanto a mí, llegado a este punto del proceso ya he empezado a programar la aventura, con todas las localidades y todos los objetos y personajes involucrados en los puzzles; todo lo que permite completar la historia de principio a fin de la narración: con lo ya descrito en la serie, tengo información más que suficiente para hacerlo.

Cuando ya tengo una maqueta o esqueleto plenamente funcional de la aventura, comienzo a agregar todos los elementos que enriquecen el producto y lo acercan más a lo que a mí me gusta publicar en cuanto a ficción interactiva.

La literatura

Empezando por las localidades y luego por los objetos y personajes que en ella concurren, escribo descripciones que realcen y detallen, usando un estilo y tono acorde al argumento, cada uno de esos elementos de la historia, tomando en cuenta las siguientes consideraciones:

  • Una descripción inicial, muy completa, que nos permita situarnos respecto del elemento la primera vez que lo vemos, intentando agregar un componente emocional o que involucre al jugador desde el punto de vista de su personaje.
  • Otra descripción más abreviada para cuando miramos el elemento una segunda o sucesivas veces.
  • Si la interacción con el elemento o con otros cercanos o relacionados mediante un puzzle afectan la descripción del elemento, agregar esas consideraciones de variabilidad a la descripción.
  • Si es posible hacerlo, modificar las respuestas de texto estándar que usa la tecnología de implementación para que las interacciones con el elemento (especialmente manipular un objeto o interactuar con un personaje) tenga una respuesta más enriquecida y acorde al momento de la historia en que se realizan. Esto es particularmente significativo para las interacciones plausibles con el objeto aunque no formen parte de algún puzzle.
  • Todo lo anterior ciertamente aplica al personaje que usa el jugador, lo que le permitirá identificarse con el protagonista y no usarlo meramente como un agente de telepresencia.
  • Si el resultado de alguna interacción o resolución de algún puzzle es particularmente significativo para la aventura, suelo escribir un párrafo (o los que hagan falta) redactado con mucho mimo y cuidado. El final de la aventura ciertamente califica en este apartado y si existen varios finales con mayor razón merecen mi atención, no importando si son finales felices, neutros o "malos finales".

Como podrá suponer el lector, es perfectamente posible que en este proceso de enriquecimiento literario surjan ideas o inspiraciones que modifiquen algún elemento de la historia, afectando a localidades, objetos, personajes y puzzles aun por enriquecer o, puchas digo, que ya fueron debidamente descritos.

Fuera de agarrarme a mí mismo a patadas, la mayor de las veces "me hago caso" y modifico lo que haya que cambiar... salvo presión de tiempo para una entrega para participar en alguna competencia. En esos casos, tomo notas, dejo comentarios y ruego a que el tiempo no me devore una vez finalizada la "comp", para sacar entonces una versión revisada.

Los detalles del ambiente

Después del "crecimiento literario" de la aventura es inevitable que hayan surgido detalles mencionados en las descripciones que no forman parte de ninguno de los objetos o personajes ya creados.

Esos detalles yo normalmente los agrego a la aventura como objetos o personajes puramente decorativos: no cumplen ningún fin a efectos de los acontecimientos de la historia ni permiten resolver puzzle alguno, pero el poder interactuar con ellos agregará mayor profundidad al pequeño mundo creado para la aventura y permiten al jugador sentirse en verdad inmerso en la narración.

De la misma manera, introducir algunos mensajes de texto aleatorios pero que sugieran que el mundo "sigue girando" a nuestro alrededor genera el efecto (curiosísimo) de la música ambiental o el de los efectos de audio ambientales en un juego multimedia. Es algo completamente opcional pero, cuando he incluido esos textos según la localidad o el momento narrativo de la historia, agregan otra capa más de profundidad a la aventura.

Además de lo anterior es posible "iluminar" con ilustraciones las localidades o algunos objetos particularmente significativos. Esto puede embellecer la aventura y, mientras sean ilustraciones opcionales (no aportan información que no esté ya en el texto) ciertamente serán un agregado estéticamente grato al jugador. Como yo no sé dibujar, nunca he llegado a este punto pero es algo que el lector (acaso con ayuda de otros) podría querer considerar.

¡Extra! ¡Incluye material adicional!

Cuando todo lo anterior ya está hecho, por consideraciones de calidad y usabilidad de la aventura yo siempre agrego algunos apoyos o elementos adicionales para ayudar al jugador:

  • Una ficción introductoria breve (lectura lineal, no interactiva) para situar al jugador en la piel del protagonista y dar pie al inicio de la historia.
  • Opciones de ayuda, con los comandos más habitualmente usados en cualquier aventura, incluyendo entre ellos elementos que el sistema de autoría incluya para guardar y recuperar partidas o sesiones de juego de la aventura.
  • Alguna forma de entregar pistas al jugador, particularmente si hubiera puzzles muy complejos de resolver.

¿Y ahora, a publicar?

¡De ninguna manera! Lo más probable es que, por minucioso que yo haya sido, habrán muchos pequeños (y no tan pequeños) detalles que habré pasado por alto: cosa del todo normal, esto de la ceguera del autor respecto de su propia obra...

Más que recomendable, es necesario someter la aventura a varias rondas de pruebas o testing que nos permitan corregir lo que falla o lo que derechamente nos quedó mal hecho y que pueda echar a perder el disfrute de la aventura.

¡A publicar!

La realidad es que la aventura siempre podrá refinarse o ajustarse, pero en algún momento hay que saber dejar de trabajar en ella. Ese punto es variable para cada autor y responderá a su propia madurez creativa o (no es raro) al tiempo disponible.

Mi única recomendación a efectos de exponer lo creado es buscar una plataforma de publicación con un alcance razonable desde el punto de vista de los jugadores potenciales.

A título de ejemplo, pueden ver lo que he hecho en itch.io y en mi propia página de trabajos publicados (hay vínculos a varios sitios hispanos), amén de (en inglés) ifWiki e  ifdb.org.

Un final que es sólo el comienzo

Finaliza así este artículo y esta serie. Espero que conocer el proceso creativo fruto de mi experiencia creando aventuras de texto, con sus limitaciones, errores y aciertos, les haya sido de utilidad y les ayude en sus propios esfuerzos creativos.

Algunas de estas indicaciones pueden servir de orientación o acaso para guiar sus primeros pasos: es normal que pronto las dejen atrás.

Descubrirán entonces que la mejor manera de hacer aventuras de texto es la que ustedes mismos quieran inventarse.

Categorías: Planeta

Creando una aventura de texto V: puzzles

Hace 17 horas 51 mins

En este quinto artículo de la serie me explayaré sobre un tema central de las aventuras: los llamados puzzles.

¿Por qué incluir puzzles en una aventura?

Es enteramente posible plantearse una aventura como una experiencia literaria pura: recorrer localidades e ir teniendo interacciones simples como observar lo que nos rodea, leyendo el texto generado. Ejemplos de este tipo de relatos serían una visita a un museo o bien un recorrido por el campo o algún paisaje urbano.

En cuanto a ejercicio creativo, semejante relato sería diferente a una lectura normal ("ir pasando páginas") con el añadido que no habría necesariamente una secuencia prefijada en el orden de visita o recorrido de las diferentes localidades del mapa; lo mismo ocurrirá con los objetos que estén al paso del jugador.

¿Sería esta una aventura de texto? Desde el punto de vista de la implementación, ciertamente que sí y tendría consideraciones de estilo no menores para mantener coherencia narrativa, para no hablar del interés del jugador.

Sin embargo, el verdadero aporte de la aventura a la experiencia literaria "tradicional" es precisamente involucrar al jugador como un personaje crucial de la historia narrada, planteándole en múltiples ocasiones desafíos que tendrá que resolver para que avance la narración.

Así, en el sentido estricto, la aventura supondrá un puzzle cada vez que en la historia se requieran acciones de parte del jugador para que se desarrollen los acontecimientos, particularmente si esas acciones son no triviales e implican algo más que el mero desplazamiento (sin obstáculos) por localidades.

El eterno problema del equilibrio

En mi caso, llegados a este punto ya tengo todos los elementos necesarios para identificar los puzzles así como su lugar en la secuencia (de las posibles) en la historia a relatar, pues tengo razonablemente detallados:

  • En qué localidad o localidades ocurren
  • Los objetos involucrados
  • Los personajes participantes
  • Las acciones que se requieren del jugador (y en qué orden)

Sin embargo, hay un elemento absolutamente crítico para la experiencia y (uno espera...) disfrute del jugador y es la dificultad.

Por ejemplo, si pongo al jugador en una habitación en llamas y la única salida a la vista es una ventana, el puzzle o problema a resolver sería cómo salir por la ventana...

...a no ser que haya otra manera de escapar de las llamas y el jugador tenga información al respecto o pueda adquirirla a tiempo para darse cuenta.

Esta es precisamente la medida habitual de qué tan "justo" estoy siendo con el jugador al plantearle un problema. Si, habiendo "llegado" al momento narrativo en que necesita resolver el puzzle para continuar con la historia, el jugador ya adquirió o experimentó todo lo necesario (tiene los objetos y/o los personajes requeridos lo acompañan o le dieron información) para poder resolver la situación o bien la solución está frente a sus ojos (en el ejemplo: hay una escalera apoyada para subirse hasta la ventana) entonces, sí, he sido justo con el jugador.

La dificultad (para el autor, que no del puzzle) estriba precisamente en lo interactivo del relato y si, en efecto, he dispuesto las cosas para que siempre, el jugador tenga lo necesario para salir adelante y esto sea así en todas las variantes narrativas en las que se llega a la situación en la que se plantea el puzzle.

En mi caso, si no he sido negligente en mi trabajo hasta el momento, es simple el saber si están o no dadas las condiciones para esa resolución; es relativamente simple, sin embargo, toda vez que, si la historia es muy compleja y está llena de vueltas y revueltas de la trama, es perfectamente posible que yo haya pasado algo por alto y haya dejado al jugador en un figurativo callejón sin salida.

¿Misión imposible?

Si se revisa la literatura teórica sobre creación de aventuras, en algunos casos el planteamiento de la dificultad de los puzzles es considerado una decisión de estilo del autor, es decir, que el permitir o no que el jugador se atasque esté previsto por el autor, incluyendo variantes en las que se diseña la aventura para que:

  • El jugador no pueda atascarse nunca
  • El jugador pueda atascarse, pero pueda retroceder a una situación en que puede reintentar resolver el problema
  • El jugador pueda atascarse y no pueda retroceder, aunque entonces sea inmediatamente evidente que debe volver a comenzar (ejemplo: el jugador está muerto)
  • El jugador pueda atascarse, no pueda retroceder y nunca será evidente que debe volver a comenzar

Dicho esto, a la fecha creo haber publicado aventuras razonablemente justas para con el jugador y pretendo seguir haciéndolo.

Es enteramente atendible que inducir algo de frustración en el jugador es parte de lo que genera interés en seguir adelante con la aventura... pero sólo hasta un cierto punto. Yo estimo que al jugador no hay que joderle (bastante tenemos con la vida real, gracias) pero puedo entender que otros autores piensen distinto a mí y que por cierto haya jugadores que gusten de aventuras con un grado de frustración o desafío mayor que las que yo hago.

Notar que ciertamente la dificultad de un puzzle está en directa relación con la sensación de satisfacción del jugador al lograr resolverlo, pero en qué punto entramos en el sadismo o masoquismo de parte del autor y/o del jugador es algo que escapa a mi propósito al escribir esta serie.

Finalizamos aquí este artículo dedicado a los puzzles de una aventura. En el siguiente y último post de esta serie abordaremos los elementos que redondean la creación de la aventura, incluyendo uno muy caro a quien esto escribe: la literatura.

Categorías: Planeta

Creando una aventura de texto IV: objetos y personajes

Hace 17 horas 51 mins

En el cuarto artículo de esta serie veremos cómo llegamos desde las localidades a los objetos y personajes de la aventura.

Expandiendo las localidades

Una vez que tengo enunciadas las localidades de la aventura, escribo un párrafo para cada una indicando qué acontecimientos ocurren en ella y que objetos y personajes están involucrados... lo que implica que pueden haber hechos que ocurren a espaldas del jugador y con relación a los otros personajes del relato.

Normalmente incluyo en esa redacción el orden (de entre los posibles) de cada acontecimiento en la secuencia de la historia general y, si veo que la trama de eventos los amerita, dibujo un diagrama separado con la relación causa/efecto o secuencia de cada acontecimiento en la historia para luego hacer una redacción aparte que detalle los acontecimientos y los elementos del modelo del mundo involucrados: localidades, objetos y personajes.

Como podrá suponer el lector, es perfectamente posible que en este laborioso proceso uno descubra que por temas de coherencia narrativa sea necesario hacer cambios a la historia (rara vez al argumento) y esto signifique revisar el mapa y alguna área o localidad.

Por otra parte, la cantidad de trabajo está relacionada con la complejidad de la historia y no necesariamente con la cantidad de localidades. He creado aventuras de una sola localidad que me dieron no poco trabajo precisamente por los acontecimientos que en ella ocurren: las múltiples interacciones, dentro de la misma localidad, entre el jugador, objetos y personajes.

Los objetos

Habiendo identificado los objetos y su vínculo con las localidades, lo que escribo a continuación es una redacción o punteo para cada uno de ellos, para tener claro su rol en la aventura:

  • Primero, escribo qué función cumple el objeto en la historia: por qué o para qué existe en la aventura. Se puede tratar de un mero decorado, para mejorar la descripción de la localidad o bien efectivamente ser un componente necesario para algo que el jugador debe hacer más adelante en la historia, pudiendo ser opcional o imprescindible, cosa que se le puede hacer inmediatamente clara al jugador o ir revelándose conforme avanza el relato. Por último, puede tratarse de un objeto completamente inútil, inane y baladí, cuyo único propósito es distraer al jugador, hacerle perder el tiempo o incluso irritarlo... cosa que personalmente no hago nunca por no encontrarle sentido, pero lo menciono por que es, en efecto, una posibilidad "funcional" de los objetos.
  • Segundo, tengo que definir si están directamente disponibles al entrar en la localidad: "visibles" para el jugador o bien están ocultos y requieren alguna acción de parte del jugador o alguna otra circunstancia (paso del tiempo, acontecimientos que ocurren antes en otra localidad, usar otros objetos en combinación) para quedar "a la vista".
  • Tercero, corresponde detallar si son "muebles" o partes del paisaje y no pueden ser llevados o cogidos por el jugador o bien si se trata de objetos que el jugador puede llevar consigo. En el caso de que puedan ser llevados por el jugador, si hay pre condiciones a ese efecto, a saber: el jugador no puede llevar más de cierta cantidad de objetos, o acaso para coger este objeto "x" primero hay que haber conseguido otro objeto "y" pues hay que usar "y" para coger "x".
Este punteo puede resumirse con notación personal o sistematizarse mediante tablas o planillas debidamente categorizadas: de hecho, para mi primera aventura usé muchas planillas para no dejar nada fuera de mi vista o mal encajado en la historia, pero el paso del tiempo y la experiencia me han permitido ir afinando el estilo y estos días solo me basta con un bloc de notas y un texto exhaustivo, sí, pero breve.

Los personajes
Ya definidos los objetos, paso al apartado de los personajes, cosa esta en la que declaro de antemano no soy muy ducho. Mis trabajos, aparte del jugador, no suelen ser muy abundantes en personajes secundarios, pero cuando los hay, también me hago una pequeña redacción o punteo para cada uno, no del todo diferente del de los objetos:
  • Primero, escribo qué función cumple el personaje en la historia: por qué o para qué se hace presente en la aventura. Esclarecer el rol de un personaje, sus motivaciones y cómo o para qué interactúa con el jugador es imprescindible para poder tener personajes interesantes y que sean un aporte al relato. Como ocurre con los objetos, pueden ser "relleno" o decorado para dar más realce a una localidad o a la historia, actuar como medio para un fin práctico o ser un obstáculo a superar para acceder a un lugar... o estar derechamente para incordiar al jugador: un ladrón que nos quitará cosas que habremos de obtener nuevamente o un bromista que nos hará perder tiempo.
  • Segundo, tengo que definir si son parte de una localidad o bien están ocultos y es menester que el jugador haga algo o alguna otra situación (paso del tiempo, acontecimientos que ocurren antes en otra localidad, interacciones con otros objetos o personajes) para hacerse "presentes" en un lugar. Otra opción es que sean itinerantes y el desafío para el jugador es dar con ellos... o conseguir que se estén quietos para luego interactuar con ellos.
  • Tercero, corresponde detallar si pueden acompañar al jugador para lograr algún objetivo y cómo logra el jugador que le sigan. Asimismo, le acompañen o no, corresponde definir si necesitan algo de parte del jugador: recibir un objeto, conversar con ellos... o alguna otra forma de interacción plausible con el personaje, dado su rol en la historia.
Esto de los personajes es un mundo del que yo he explorado una parte muy pequeña como para poder explayarme mucho más al respecto. Lo que sé está arriba explicado, pero aunque no es poco, me consta que es apenas un comienzo: nunca he creado una aventura basada enteramente en personajes ("Macetas" es la que más tiene) y no estoy seguro de querer hacerlo.
Concluimos aquí este post. En el siguiente artículo de la serie explicaré como encaro el fascinante entramado de todos estos elementos (localidades, objetos y personajes) en lo que suele ser el corazón y motor de la historia de una aventura: los puzzles.
Categorías: Planeta

Creando una aventura de texto III: mapa y localidades

Hace 17 horas 51 mins

En el tercer artículo de esta serie entraremos de lleno en lo que yo conozco como el modelo del mundo de la aventura: las partes constituyentes con las cuales interactúa el jugador.

Modelo del mundo

En términos generales, una vez que tengo la historia para una aventura, mi siguiente paso es concretar o traducir la historia desde el punto de vista de los elementos con los que interactuará el jugador durante el desarrollo de la historia.

Normalmente, esos elementos caen en las siguientes categorías:

  • Localidades: los sitios o espacios en los que se desarrollan los acontecimientos.
  • Objetos: los elementos que manipula el jugador, ya sean parte del escenario, del paisaje o bien artefactos que pueden ser llevados por el jugador.
  • Personajes: entidades animadas que tienen comportamiento, desplazamiento, motivaciones y capacidades propias para interactuar de manera más o menos compleja con las localidades y los objetos, incluyendo en esa interacción posible el diálogo lingüístico. Notar que el jugador es de hecho un personaje de la aventura.
Este post se referirá a cómo abordo las localidades y en artículos posteriores detallaré cómo desarrollo los demás elementos.

El mapa

Tengo por costumbre describir primero que nada la relación que tendrán entre sí los lugares en los que se desarrollan los hechos, para lo cual suelo dibujar un grafo lo más sencillo posible, agrupando (si puedo) las localidades en áreas generales con alguna afinidad.

Por ejemplo, si la aventura que voy a relatar ocurre en el bosque alrededor de una villa en cuyo centro hay un castillo, tendría un primer dibujo de un circulo central (el castillo) rodeado por dos anillos concéntricos; de adentro hacia afuera, la villa y el bosque.

En cambio, una aventura que ocurre en el interior de un barco tendría como áreas las distintas cubiertas de la nave, incluyendo algunas áreas funcionales como ingeniería, el puente de mando, bodegas, cabinas, etc.

Suele ocurrirme que al momento de definirlas algunas de estas áreas nunca tendrán un uso o recorrido disponible para el jugador, pero me resulta útil el incluirlas en el mapa ya que luego son mencionadas en el texto de la aventura, para enriquecer el relato.

Las localidades

Una vez que ya tengo el mapa general, comienzo a detallar, para cada área del mapa, las localidades (habitaciones o lugares) por lo que podría pasar el jugador durante el desarrollo de la aventura.

Notar este podría porque algunas de esas localidades pueden tener una finalidad meramente descriptiva y no hay nada que el jugador deba hacer en ellas para que se desarrollen los acontecimientos. Otras pueden servir meramente para comunicar otras localidades que sí son importantes para la historia como, en el ejemplo del barco, las escaleras que comunican las cubiertas y los pasillos de acceso a las cabinas.

Para cada área suelo crearme un diagrama tipo grafo dirigido que muestra como se comunican o conectan entre sí las localidades, detallando con notas o simbología si hay libre tránsito o bien si el acceso a alguna localidad requiere acciones de parte del jugador. Para el ejemplo del castillo, habrá cuartos cerrados con llave o lugares cuyo acceso no es evidente al pasar junto a ellos: los clásicos pasadizos secretos, que para su uso requieren que previamente el jugador adquiera informacion interactuando con personajes y/o manipulando objetos.

En cuanto al nivel de detalle de las localidades, esto obedecerá únicamente a las necesidades de la historia y al estilo del autor.

Para mi gusto, si un lugar puede describirse con una palabra y las acciones o hechos del relato pueden describirse correctamente sin "particionarlo", asigno ese lugar a una sola localidad. En el ejemplo del barco, si un pasillo no tiene más que cuatro accesos (entrada, salida y un par de puertas a lado y lado) ese pasillo es solo una localidad.

Si en cambio veo que los acontecimientos y las acciones del jugador se volverán complicadas de realizar o confusas de narrar con una sola localidad, la divido según las necesidades de la historia. En el ejemplo del castillo, el salón del trono puede dividirse como: la entrada, pasillo central, ala derecha (con tapices), ala izquierda (con una chimenea y escaños) y el trono propiamente tal al final de todo. De cada una de estas localidades podrían arrancar sendas salidas o accesos a otras localidades, incluyendo un pasadizo secreto desde la chimenea, etc.

No tengo, pues, una regla canónica para la cantidad de localidades de una de las áreas del mapa. Si el área es una casa, resulta sencillo modelar cada habitación como una localidad... pero en la planta alta, si hay muchas habitaciones, modelo el pasillo como tres localidades distintas: la primera da acceso a la planta baja y a una habitación , mientras que la parte del medio y el final del pasillo son otras dos localidades que acceden a dos habitaciones cada una, con puertas a los costados.

Cuando ya tengo definido el mapa y sus localidades es momento de hacer levantamiento de los demás componentes del modelo del mundo de la aventura.

Ese detalle de los objetos y los personajes lo revisaré en el siguiente artículo de la serie.

¡Hasta pronto!

Categorías: Planeta

Creando una aventura de texto II: argumento e historia

Hace 17 horas 51 mins

Continuando con la serie sobre creación de aventuras de texto, en este segundo artículo comenzaré con el "aterrizaje" de las ideas que salen de la inspiración.

Como siempre, recordar que esta es mi experiencia y perspectiva sobre este proceso creativo y no supone un dogma ni una guía metodológica absoluta.

Argumento

Identificar el argumento del relato es mi punto de partida habitual para la creación de una aventura, ya que suelo plantearme el argumento en cuanto a "depuración de la inspiración". Por ende, procuro que el resultado de esa depuración atienda a los siguientes criterios generales:

  • ¿De qué se trata esta aventura?
  • ¿Puedo explicar lo que ocurre o lo que quiero narrar?
  • ¿Es posible reducirlo a una oración corta o en una frase breve?
  • Si se usa el argumento como primera exposición o contacto con la aventura ¿resultará atractiva para el eventual lector?

Esta aproximación tipo sinopsis al concepto de argumento es muy útil, sobre todo porque permite filtrar algunas ideas o inspiraciones que, no siendo malas per se, pueden no ser adecuadas para una aventura. Notar que esto significa que es enteramente posible que algunas de estas ideas se puedan usar en otra instancia creativa, así que no existe la inspiración mala, etc.

En muchas ocasiones he generado argumentos que resultaron ser más sugestivos que descriptivos, lo que lejos de ser un problema supone de hecho un verdadero salvavidas creativo. Este tipo de argumento me ha resultado particularmente útil cuando, en medio del fárrago de la programación ("los árboles no dejan ver el bosque") se me ha perdido el norte de qué tipo de aventura estoy creando.

En resumen: para llegar al argumento, la clave es expresar la esencia de la aventura que vamos a crear.

Historia

Una vez que ya he capturado el argumento, lo que hago a continuación es empezar a detallarlo en cuanto a la historia o narrativa que voy a desarrollar con la aventura.

Salvando las distancias entre la lectura lineal ("ir pasando páginas") y la interactiva, suelo usar con bastante éxito las técnicas narrativas tradicionales (planteamiento, desarrollo, nudo y desenlace) ya sea para la aventura completa o para situaciones puntuales o "episodios" narrados (independiente de la secuencia) dentro de la aventura.

Ampliando el punteo anterior, intento identificar o explicar:

  • El acontecimiento central o inicial que mueve el relato.
  • Si existe, el orden (causa y efecto) de los episodios o elementos narrativos de la A.
  • Qué elementos intervienen en el o los acontecimientos: el lugar o lugares donde ocurren, personajes (incluido el jugador) que intervienen, objetos o artefactos involucrados.
  • La temporalidad en el flujo de los acontecimientos: todo ocurre en el "tiempo real" del jugador o hay espacios de tiempo (¿cuánto tiempo "muerto"?) entre los diferentes episodios.

Dependiendo del tipo de aventura a crear, este proceso puede resultarme muy laborioso o no demasiado. Yo nunca he escrito guiones de mis aventuras, aunque entiendo que algunas personas se benefician de ello.

Por otra parte, en más de una ocasión me ha ocurrido que durante el desarrollo de la historia me he encontrado con un elemento narrativo tan importante y válido que he necesitado redefinir el argumento y volver a repasar la historia completa... cosa esta que no me ha hecho (en ese momento) particularmente feliz, pero que ha redundado, a la postre, en una historia más coherente y en una aventura más disfrutable.

Para concluir: la historia nos permite crear la "hoja de ruta" de la aventura y mientras más clara resulte, menos nos extraviaremos durante su construcción o programación.

Concluye así el segundo artículo de esta serie. En el siguiente artículo comenzaré a desmenuzar la historia en las "partes y piezas" habituales en una aventura.

¡Nos vemos!

Categorías: Planeta

Arranque de Rayuela Jam 2021: Tras el velo

Hace 17 horas 51 mins

Después de una votación con un récord de más de 100 participantes, se ha definido "Tras el velo" como el tema de la Rayuela Jam 2021.

También se dió hoy arranque oficial a la competencia, con la friolera de más de 70 participantes inscritos, los que tienen este mes de Mayo para preparar sus trabajos para la competencia.

Para animar la competencia, se han propuesto diversificadores como variaciones sobre el tema de la comp. De acuerdo a la página de la jam:

Los diversificadores son pequeños retos creativos. Limitaciones autoimpuestas a la hora de realizar las obras como una manera de desafiar las propias habilidades o explorar distintos medios o estilos que no habíamos usado nunca. Son totalmente opcionales pero muy recomendables pues sirven como chispa creativa y enfoque a la hora de pulir las ideas que vamos a desarrollar en torno al tema princial.

En esta ocasión hay 4 diversificadores, a saber:

  • "Ceñirse a lo esencial": Crea una obra minimalista, reduciendo el juego a lo esencial para comunicar tu idea.
  • "No está muerto lo que yace eternamente": Resucita un viejo proyecto que hayas dejado aparcado en el cajón.
  • "Multiverso": El juego debe incorporar contenido transmedia y no quedarse sólo en el plano videolúdico.
  • "Creadores del Renacimiento": Si participas en solitario, todo el juego debe ser realizado por ti, no pudiendo usar arte, sonidos, música, etc de terceros o libres de de derechos. Además, debe contener AL MENOS dos ilustraciones/modelos y dos piezas musicales o efectos de sonido. Si participas en equipo, no sólo TODO el contenido del juego debe estar hecho íntegramente por el equipo, sino que además cada miembro debe realizar una pieza de un género distinto a lo que esté acostumbrado.

Para más detalles, pueden consultar en itch.io.

En las páginas del blog anunciaremos el avance de la jam y el inicio del periodo de votación por los trabajos publicados...

...¡y adelante con la aventura!

Categorías: Planeta

Creando una aventura de texto I: motivación e inspiración

Hace 17 horas 51 mins

Introducción

Como anuncié anteriormente, comenzaré una serie de artículos en los que me referiré a mi proceso creativo (etapas y tareas) para crear una aventura de texto.

La idea rondaba hace ya un tiempo en mi cabeza y miembros de la comunidad me han indicado que este tipo de literatura puede ser de utilidad a los que se están iniciando en estas lides o desearían hacerlo; nada me gustaría más que apoyar a esos incipientes autores, máxime desde mi propia experiencia.

En general, salvo que sea imprescindible o en verdad relevante, evitaré en esta serie la alusión a tecnologías de implementación o sistemas de autoría específicos, concentrándome en cambio en las consideraciones, dificultades y tareas creativas asociadas a mi propio proceso creativo.

Iniciaré la serie con lo que probablemente sean los aspectos más imprecisos y a la vez más trascendentes: motivación e inspiración.

Advertencia

En adelante, en este artículo y en la serie, por consideraciones de tiempo de escritura usaré los términos "aventuras" o "aventura" a secas (o incluso la abreviatura "A.") para referirme a la o las aventuras de texto, sea como el "juego" resultante del proceso o en cuanto a fenomenología creativa (ejem).

Estoy perfectamente consciente de que puedo estar pasando a llevar convenciones o consideraciones muy caras a los puristas del lenguaje y/o de la ficción interactiva, pero esa discusión no atañe a este blog ni a quien esto escribe... y acaso tampoco en demasía a mis lectores, ya que estamos.

Motivación

En mi caso, la principal razón para crear aventuras es el deseo de contar historias, con el añadido de que, tratándose de ficción interactiva, se trata literal y literariamente de más de una sola historia, con un componente de desarrollo y expresión narrativos importante.

Hago esta puntualización porque no necesariamente una aventura tiene por fuerza que tener un origen o una expresión literaria o narrativa importante o como elemento imprescindible. Existen y existirán estupendas y muy disfrutables aventuras donde la literatura (los textos desplegados) será escaza o la justa, sin que ello sea detrimento del resultado ni de su experiencia lúdica o interactiva.

Por el contrario, hay situaciones e interacciones de una aventura que deben resolverse en forma tersa, breve o hasta escueta, ya sea por necesidad de la historia,  para no echar a perder la experiencia de la A. o derechamente por el estilo del autor.

En efecto, para el autor de este blog este es un aspecto delicado a tener en consideración, toda vez que la narrativa interactiva tiene sus propias reglas y equilibrios, precisamente para que la ficción no ahogue lo interactivo... ni vice versa.

Resumiendo: lo que me mueve a crear aventuras es el deseo de contar historias, historias que se abren y se ramifican en la medida que son experimentadas por el lector.

Inspiración

Lo único coherente que he destilado después de varios años de autoría de aventuras es que en esto de la inspiración lo único que está vetado es precisamente el vetar fuentes de inspiración.

Cada cosa que el autor haya vivido, escuchado, visto, imaginado, leído o escrito anteriormente es una fuente válida de inspiración y es de hecho problemático el poner cortapisas en este sentido. Incluyo como limitación innecesaria, por cierto, el socorrido y peliagudo tema de la originalidad, copia descarada aparte, claro está.

Si bien este asunto fue desarrollado anteriormente en este blog, haciendo una "raya para la suma" es absolutamente imposible ser completamente original en una expresión creativa cualquiera pero máxime en las aventuras, precisamente porque para ser entendidas o acaso disfrutadas se requiere (en mi opinión, pero...) de un sustrato mínimo o común entre autor y lector cual es, a saber, el lenguaje.

El lenguaje y los mundos que crea o comunica deben tener necesariamente elementos familiares o asimilables por lector y autor. Sin duda, si yo grth kjlo gef driwe garuda tolkuato y por su parte el lector nmje qwet ñolka zemjo kenpli chamero entonces wref nokto klenko... pero si lo anterior pudiera ser glosolalia aleatoria (creo) no sería original, mucho menos si estamos hablando de un relato interactivo "disfrutable" más allá de la experimentación o la psicodelia.

Como se deduce, esto de la inspiración no es un tema resuelto ni fácil, toda vez que en el caso de las A. el autor deberá llegar desde la idea o inspiración "germen" a la historia interactiva, con todas sus "partes y piezas" que dilucidaremos en los siguientes artículos de esta serie...

...y para aquello el autor no podrá, por fuerza, inventarlo todo de cero en pos de una originalidad (reitero) inútil y hasta contraproducente como cota para la inspiración.

Para concluir: si un o una [lo que sea] lleva al autor a querer crear una aventura, aquello es inspiración válida, sea esta original o no.

Con esto concluye el primer artículo de la serie. En el próximo episodio explicaré cómo hago para concretar esa inspiración en una aventura.

¡Hasta pronto!

Categorías: Planeta

"Bueno, estoy de vuelta otra vez" (disculpa la repetición, Sam)

Hace 17 horas 51 mins
Cuando retomé el blog el año pasado lo hice escencialmente con tres objetivos:

  • Recobrar el hábito de la escritura mediante las reseñas literarias.
  • Volver a tomar contacto periódico con la comunidad de ficción interactiva de habla hispana y reflejar eso en el blog.
  • Regresar a la creación de relatos interactivos.
Estos objetivos se han cumplido muy satisfactoriamente para mí y (modestia aparte) también para el resto de mis lectores, al menos si me baso en las estadísticas de acceso al blog y a mis trabajos publicados, ya sea vía itch.io, facebook, mi web y demás canales.
Si bien logré publicar "Memoria", un hiperrelato tipo librojuego en Squiffy, faltaba aún una tarea a abordar para sentir que estaba (como alguna vez dijo Samsagaz Gamyi) de verdad de vuelta: crear una nueva aventura de texto.
Fruto de mis recientes contactos con la comunidad he "redescubierto" el lenguaje Inform 6 (con la librería en español INFSP) y puedo anunciar con mucho agrado que ya estoy trabajando nuevamente en una aventura de texto de argumento original, con (espero) buena literatura pero ciertamente con su dosis de puzzles interactivos para los que gustan de ese elemento fundacional de las aventuras.
En razón de esto, iniciaré en el blog una serie de artículos sobre mi proceso creativo para crear una aventura: sin "spoilers" pero sí incluyendo lo que he aprendido con la perspectiva de años de oficio... y un periodo de inactividad más bien largo.
Será un viaje de regreso a crear y a aprender: el mejor de los periplos, sin duda.
¡Hasta pronto!

Categorías: Planeta

IFPUBS: novedades en la biblioteca de ficción interactiva

Hace 17 horas 51 mins

He tomado la costumbre de pasar a menudo por los canales de Textualiza en discord para estar al día con lo que va surgiendo en el mundillo de la ficción interactiva.

Me enteré así, por "boca" de su autor Billy Y. Fernández, que hay novedades en IFPUBS: una biblioteca, ya reseñada en este blog, con una cada vez más amplia colección de e-books dedicados a la ficción interactiva en todas sus formas: aventuras de textojuegos de rollibrojuegos e hiperrelatos.

A destacar, entre las novedades:

  • Un curso de ficción interactiva mediante Ficdwon, escrito por el propio Billy Y. Fernández
  • El libro "Teoría y Diseño de Juegos de Rol" de Arturo González-Escribano
  • Recopilaciones de artículos del fanzine SPAC y de su segundo andar, SPAC 2.0
  • Tres manuales de teoría y práctica para el sistema de autoría Inform 7
  • El ensayo "IF Theory Reader" de K. Jackson-Mead & J. R. Wheeler
  • Una recopilación de artículos del blog "Pacificaciones" de Johan Paz
  • El manual "Writing With Ink", texto oficial del lenguaje de scripting Ink creado por Inkle Studios
Estos títulos se suman, por cierto, a la de por sí amplia colección ya disponible en el sitio.
Buenas noticia para los autores de ficción interactiva, avezados o novatos, que pueden acceder así a más y mejor material para guiarles en sus esfuerzos creativos.

Categorías: Planeta

Corrigiendo el bug de HABLA en DAAD para Spectrum.

Hace 17 horas 51 mins

El mundo de las aventuras conversacionales se halla dividido desde los felices 80 en dos hemisferios que se dan la espalda el uno al otro: en uno lo común es manejar la comunicación con los «personajes seudo-inteligentes» mediante el comando DECIR seguido de un entrecomillado con la frase exacta que le dices al personaje (DECIR a PERSONAJE «bla-bla-bla»), en el otro el protocolo consiste en usar la fórmula HABLAR con PERSONAJE, pudiendo refinarse con la variante HABLAR con PERSONAJE sobre TEMA para afinar más en el asunto de la conversación en sí. El primero es común en los sistemas basados en condactos, como en la saga de herramientas de Gilsoft (Quill, PAWS, DAAD), especialmente optimizadas para funcionar así, mientras que el segundo se hizo habitual en las obras de Infocom, dada su mejor adaptación a los sistemas de programación orientada a objetos y es por tanto el que se usa comúnmente hoy en día en lenguajes como TADS, Inform, etc…
Sobre las posibilidades de evolución y expansión del segundo se habla largo y tendido en el capítulo dedicado a los personajes del libro Creating Interactive Fiction with Inform 7 de Aaron A. Reed. A su vez se puede leer una comparativa con los pros y contras de uno y otro en este reciente post del blog de Ricardo Oyon.

Sistemas de conversación en el libro de Aaron A. Reed.

Lo cierto es que no hay ninguna razóin técnica para circunscribir exclusivamente ambas tradiciones a un tipo de sistema de desarrollo u otro. Es perfectamente posible «cambiarlas de entorno» a gusto del autor. Así, han sido muchos los casos de aventuras hechas con sistemas de condactos que se decantan por la fórmula de HABLAR con PERSONAJE, pero en el caso de las plataformas de 8 bits se han encontrado sistemáticamente con un pequeño escollo: la incompatibilidad del uso de la forma imperativa de verbo HABLAR («HABLA») con los sistemas existentes de asociar los verbos acabados en LO, LA, LOS, LAS con el objeto de la orden inmediatamente anterior.

Estos sitemas, que permiten el uso de secuencias de órdenes como EXAMINA LIBRO y COGELO no generan ningún conflicto en sus equivalentes ingleses basados en los pronombred IT o THEM (EXAMINE BOOK and TAKE IT) pero en los sistemas españoles de la época clásica que lo implementaban (salvo error u omisión: PAWS y DAAD) tenían un efecto secundario inesperado al entrar en juego la orden HABLA. Si la secuencia de comandos del jugador era algo parecido a EXAMINA LIBRO y HABLA con PERSONAJE, la terminación en LA del imperativo HABLA activaría automáticamente el sistema de tal modo que el parser entendería que en la segunda órden el jugador está intentando hablar con el libro. Este «bug» es ya un «viejo conocido» entre los usuarios de PAWS, pudiendo rastrearse menciones al mismo en los manuales de las primeras aventuras del Doctor Van Halen de Josep Coletas allá por 2004, aunque no hay que descartar que las haya anteriores.

El bug de HABLA en el manual del primer Dr. VanHalen.

Es un hecho inapelable que el sistema funciona codificado «a fuego» en las entrañas del parser de PAWS e igualmente se halla en el interior del código de DAAD que maneja el funcionamiento del condacto PARSE. En principio eso significa que no hay manera de controlar este comportamiento por el autor de la aventura salvo acciones drásticas como usar condactos para eliminar todo el sistema de raíz, una solución claramente insatisfactoria porque supone prescindir totalmente de una característica del sistema simplemente porque falla en un caso concreto. Lo cierto es que el único modo de soslayar el problema pasa inequívocamente por hacer un hack al intérprete.

Vamos a proponer un modo de hacerlo en el caso del intérprete de DAAD para Spectrum. En otros intérpretes de DAAD o en el del PAWS podría aplicarse seguramente un metodo parecido salvando las diferencias de direcciones concretas de memoria en cada caso, pero no tengo tiempo material de ponerme a investigarlo
Para «destripar» el interior del intérprete de Speccy vale cualquier desensamblador, pero por sus facilidades para hacer maniobras de ingeniería inversa he usado SkoolKit, un conjunto de scripts de Python especializado en «meter mano» a software de Spectrum y ponérselo facilito a quienes quieran analizar códigos fuente. A su vez aprovechamos que en DAAD la parte de código que queremos analizar se halla «aislada» en las rutinas que se ejecuten al invocarse el condacto PARSE (en el proceso 1 siguiendo la plantilla por defecto de DAAD) para añadir un pequeño proceso de «debug» que permita echar un vistazo al estado de las banderas justo antes y después de éste.
En las imágenes se puede ver que llamamos a un proceso 12 que nos imprime el estado de unos cuantos flags estratégicos (el grupo 33-36 y 43-47, ver el manual para sus usos concretos). Mediante este truco pudimos determinar que PARSE, al encontrarse con un verbo acabado en LO, LA, LOS, LAS adjudica al flag 34 (nombre) el valor del nobre de la acción anterior y a su vez coloca en 44 (NOUN2) el valor que hubiera correspondido al nombre de la entrada del jugador si no se hubiera detectado la terminación. Esto último es útil para secuencias de órdenes del tipo: EXAMINA LIBRO y DASELO a PERSONAJE, donde en la segunda orden el nombre es el nombre de la primera y el que hubiera sido el nombre original pasa a ser el segundo nombre o NOUN2. Si hubiera habido un NOUN2 en el input original este pasa a ser ignorado (tomen nota del detallito los autores de intérpretes alternativos ).

A su vez con la opción de monitorear la memoria del programa durante la ejecución disponible en la práctica totalidad de emuladores de Spectrum es fácil determinar las posiciones exactas de memoria que ocupan las banderas o flags del DAAD. En el caso del Spectrum los 256 flags están entre 32540 y 32795. Sabiendo ésto es fácil deducir que los flags de verbo (33), NOUN (34) y NOUN2 (44) están respectivamente en 32573, 32574 y 32584.

Entra en acción SkoolKit. Podemos rebuscar entre las rutinas del código desensamblado instrucciones que afecten a esas direcciones de memoria o, en su defecto, al valor indicado por el registro IX del procesador más el número de flag, ya que en DAAD de Spectrum, IX almacena la dirección de inicio de estos. Ahora ya es cuestión de ensayo y error, paciencia, y algo de suerte para encontrar algo que resulte significativo para nuestro propósito. Tirando del hilo pronto aparece esta rútina que vemos en la imagen, con comentarios añadidos por mí aprovechando las facilidades de SkoolKit:

SkoolKit destripando a DAAD.

En ella podemos ver que en cierto momento de la ejecución, el parser mira en la zona de memoria donde ha almacenado el verbo del input del jugador y examina desde su final hacia atras. Si los caracteres que encuentra allí se corresponden con LO, LA LOS o LAS, pone una marca en el registro A, iza el flag Z del procesador, y el programa se bifurca hacia otra parte.

Monitoreando, es posible determinar que en ese preciso momento el flag 33 (verbo) ya está establecido, no así los referentes a NOUN, NOUN2, adjetivos y adverbio que continúan en 255 (255 es el valor al que se resetean en cada turno o sentencia lógica). Es fácil deducir que la asignación de estos se hará de una manera si no se ha detectado terminación y de otra en caso contrario. Es… ¡un buen sitio donde intervenir!

Podemos sustituir las instrucciones de salto marcadas en la imagen por una llamada a una pequeña rutina creada expresamente para la ocasión que colocaríamos en algún lugar libre de la memoria. Normalmente éste sería alguna posición indeterminada entre el final de la base de datos del juego y el comienzo de la de los gráficos, que es la zona de memoria que DAAD deja libre en Spectrum, pero eso significaría que tendría que ser una ubicación distinta en cada juego, ya que nunca sabremos a priori donde empezará y terminará ese espacio. Como la rutina va a ser en realidad pequeñita podemos buscarle un sitio estable razonablemente seguro que puede ser un puñado de bytes por debajo del comienzo del intérprete, concretamente la dirección 24560. La única precaución a tener en cuenta en este caso es que el cargador de BASIC del juego ponga la habitual instrucción CLEAR un byte más abajo, es decir 24559 en lugar del 24575 original.
Así que, como decía, sustituimos esas dos instrucciones del código DAAD original por un JP 24560. Las dos instrucciones juntas ocupaban 5 bytes y nuestro JUMP sólo 3 así que los 2 bytes restantes los ponemos a 0. La rutina a la que llamamos hará algo como esto:

ORG 24560 JP NZ, 27449 LD A, (32573) CP 31 JP Z, 27449 LD A, 6 JP 27677

Veámoslo detenidamente. Hemos tomado nota como si entráramos en el molino del Quijote, o sea, cuidadosamente :-p, del estado de los flags del procesador en el momento de llegar al punto en que nos desviamos del código original. En este se levanta el flag Z si se ha encontrado la terminación verbal (y se carga el registro A con 6). Si ése es el caso, el código se desvía a 27677 y si no (no hay terminación) el desarrollo normal del programa sigue por 27449.

En nuestro hack primero mandamos la ejecución a 27449 si no está puesto el flag Z, o sea, le decimos que continue con normalidad porque no hay nada de LAS ni LOS.

A continuación cargamos en A el valor de 32573, donde sabemos que está el valor del verbo.

Comparamos con 31, que es el valor por defecto en la plantilla de DAAD para el verbo HABLAR. Ésto, por supuesto, será cierto en una mayoría de los casos, pero también podría darse perfectamente el caso de que en un juego concreto el verbo HABLAR tenga cualquier otro valor en la sección de vocabulario (/VOC) de su código fuente. Para esta situación bastará con que el cargador BASIC de la aventura haga, tras cargar el intérprete, un POKE 24567, valor (siendo valor el número que HABLAR tenga en VOC).

Si el verbo era, efectivamente HABLAR (31 o el valor que fuera en su caso) podemos afirmar por eliminación y con un 100% de seguridad que se ha detectado un LA y que el verbo era HABLAR, por lo que sabemos a ciencia cierta que, de seguir el flujo normal del programa, se produciría el cambio de NOUNs. Por eso le decimos que de estar izado el flag Z se vaya a 27449, donde procesará la entrada del jugador como si la terminación NO se hubiera detectado.

Y en caso contrario podemos asumir también con seguridad que se ha encontrado la terminación, pero el verbo NO era HABLAR, así que, tras cargar A con 6 como hubiera hecho en la rutina original, le decimos que vaya a 27677, donde procederá a hacer los cambios de NOUNs igual que hubiera hecho normalmente.

Tenéis el intérprete de DAAD de Spectrum con todas estas modificaciones disponible en esta DESCARGA.

En el archivo ZIP enlazado hay:

-Un binario con el intérprete modificado tal cual, sin ningún tipo de cabecera.
-Una versión alternativa del disco nº 33 de la descarga original del DAAD, el que contenía el intérprete de Spectrum en un disco de Spectrum +3, en la que el intérprete original y el cargdor BASIC han sido sustituidos por la versión hackeada.
-Una imagen de cinta de Spectrum TAP con un pequeño ejemplo.
-Un fichero de texto con las indicaciones básicas para su uso.

El primer juego de DAAD español para Spectrum en incluir la modificación es Torreoscura, de Bieno Marti, cuya versión de Spectrum actualizada ya está disponible en su web habitual: AQUÍ. Podéis probar nada más empezar con PULSA TIMBRE y HABLA con RECEPCIONISTA, algo que no funcionaba en la primera versión salvo que utilizaras el infinitivo HABLAR.

Torreoscura ya entiende HABLA en imperativo.

Y por lo que he podido probar hasta el momento, el hack es efectivo para órdenes tanto del tipo HABLA con PERSONAJE como de la modalidad HABLA con PERSONAJE sobre TEMA. Sabiendo cómo funciona el proceso en Spectrum sería posible buscar el modo de hacer lo propio en PAWS y en el resto de intérpretes de DAAD (pero, al contrario que en el clásico de los Rolling, el tiempo, eer… no está de mi lado ).

Categorías: Planeta

Copérnico 86, nueva aventura de Xavi Carrascosa

Hace 17 horas 51 mins

Después de años de ausencia en el apartado autoril, regresa el incombustible Xavi Carrascosa (Grendel Khan para los más viejos del lugar) con una nueva aventura debajo del brazo. Programada en Inform 7 y con un portadón por bandera, nos veremos inmersos en una situación desesperada, como único miembro de la tripulación que puede salvar a la nave Copérnico 86, que parece abocada al desastre.

Una historia de supervivencia espacial con algunas sorpresas que no dejará a nadie indiferente.

https://www.caad.es/fichas/copernico-86.html

Categorías: Planeta

Fanzine del CAAD número 51

Hace 17 horas 51 mins

Su director y editor, Juan J. Muñoz Falcó, nos anunciaba en el foro la publicación de un nuevo número: «Me alegra poder deciros que el CAAD 51, con el que se inaugura la Tercera Edad de este fanzine, ya está disponible. Cuenta con 108 páginas de contenidos aventureros, edición en color y diseño totalmente renovado. El CAAD empezó a publicarse en 1989, y ha sido el nexo de unión de la comunidad aventurera desde entonces.»

Índice y descarga del pdf en:
https://www.caad.es/fichas/caad-51.html

Categorías: Planeta

Port a DAAD de "Las Aventuras de Rudolphine Rur" publicado

Hace 17 horas 51 mins

Publicado el port a DAAD de “Las Aventuras de Rudolphine Rur”.
Se trata de un port a DAAD de una aventura ya publicada en 2005, para sistemas “modernos” (máquina virtual Glulx y web). Ahora, con el port a DAAD, la aventura podrá jugarse en sistemas “retro” como: ZX Spectrum, Amstrad CPC, Amstrad PCW, MSX, MSX2, Commodore 64, PC MS-DOS, Atari ST y Amiga.
Hay un total de 18 descargas diferentes (16 correspondientes a este port a DAAD), existiendo versiones en cinta, disco y para dispositivos de carga rápida tipo DIVMMC, M4, SD, etc.
Podéis descargarla en su web: www.rudolphinerur.com
En los próximos días se pondrá a la venta una pequeña tirada física. Os mantendremos informados.
¡Disfrutadla!

Categorías: Planeta

Publicado Hiperrelato "Memoria" de Incanus

Hace 17 horas 51 mins

Publicado nuevo relato interactivo del prolífico Incanus. Sci-Fi, en modalidad hiperrelato tipo libro-juego.

En el relato, has naufragado en un planeta extraño, de vastas llanuras... y con despiadados Cazadores al acecho. ¿Podrás aprender de La Gente que no basta con 'sólo' sobrevivir?

Esta historia es la segunda parte del ciclo de relatos de "La Gente", al que pertenece "El Protector".

Pueden disfrutarlo directamente en su página web (requiere habilitar JavaScript) o descargarlo en ZIP para leerlo off-line.

https://www.caad.es/fichas/memoria.html

Categorías: Planeta

Copérnico 86, nueva aventura de Xavi Carrascosa

Hace 17 horas 51 mins

Después de años de ausencia en el apartado autoril, regresa el incombustible Xavi Carrascosa (Grendel Khan para los más viejos del lugar) con una nueva aventura debajo del brazo. Programada en Inform 7 y con un portadón por bandera, nos veremos inmersos en una situación desesperada, como único miembro de la tripulación que puede salvar a la nave Copérnico 86, que parece abocada al desastre.

Una historia de supervivencia espacial con algunas sorpresas que no dejará a nadie indiferente.

https://www.caad.es/fichas/copernico-86.html

Categorías: Planeta

Fanzine del CAAD número 51

Hace 17 horas 51 mins

Su director y editor, Juan J. Muñoz Falcó, nos anunciaba en el foro la publicación de un nuevo número: «Me alegra poder deciros que el CAAD 51, con el que se inaugura la Tercera Edad de este fanzine, ya está disponible. Cuenta con 108 páginas de contenidos aventureros, edición en color y diseño totalmente renovado. El CAAD empezó a publicarse en 1989, y ha sido el nexo de unión de la comunidad aventurera desde entonces.»

Índice y descarga del pdf en:
https://www.caad.es/fichas/caad-51.html

Categorías: Planeta

Torreoscura

Hace 17 horas 51 mins

De la mano de Bieno Marti, cuyas anteriores incursiones en el terreno de la aventura conversacional (Mansión Kali I y II, El Prisionero…) son sobradamente conocidas, nos llega Torreoscura. Ai igual que en anteriores ocasiones el juego ha sido desarrollado simultaneamente en Quill para Commodore 64 por el propio Bieno, para Amstrad CPC por Miguel Ángel Silva (MiguelSky) y para ZX Spectrum por vuestro humilde y seguro servidor. Y a diferencia de ellas, esta vez el port para Spectrum no se ha hecho usando la herramienta InPAWS (para producir un juego PAWS) sino que se ha re-escrito usando DAAD, lo que ha propiciado que además de Spectrum hayan salido versiones para PC MS-DOS (CGA), Amstrad PCW y MSX. Como todavía no nos parecía suficiente, una versión adicional para ORIC ha sido realizada gracias a Chema Enguita.

La aventura, que tiene ese toque de ambientación a caballo entre el misterio y el gótico que encantará a los seguidores de las obras de Bieno, comienza con un protagonista que, siguiendo la invitación de un antiguo amigo cuyo contacto perdió hace tiempo, realiza una escapada de vacaciones a un pueblo recóndito. Nada más presentarse allí se encuentra con que su amigo no aparece por ninguna parte… y, por supuesto, empiezan a pasar cosas raras…

Rompiendo también con la tradición de las aventuras anteriores de Bieno, en esta ocasión las ocasionales pantallas gráficas hechas con bloques PETSCII han pasado a ser gráficos vectoriales realizados con el Illustrator, la herramienta de Gilsoft hecha expresamente para añadir gráficos a las aventuras realizadas con Quill (que a su vez sentaría el modelo para las herramientas gráficas de PAWS y DAAD). Como suelen remarcar todos los que han usado alguna vez alguna de las encarnaciones de este sistema de gráficos de la familia Gilsoft, su interfaz de usuario es más fea que pegar a mamá, pero en el fondo hacerse con ella no requiere más esfuerzo que ser consciente de que no estás dibujando a mano alzada como con cualquier programa de dibujo común, sino que estás introduciendo un listado rigurosamente secuencial de órdenes gráficas, lo que hace que todo tenga sentido (aunque no lo haga más bonito ). Hay que decir que el uso que ha hecho Bieno Marti de un sistema que, mayormente, se limita a una sucesión de líneas y rellenos con tramas, ha sido bastante ingenioso y sabiamente aprovechado.

Como curiosidad os enseñamos alguno de los primeros ensayos gráficos desechados. El primero es la primera aproximación al gráfico de la habitación del hostal. El segundo es la recepción del mismo hostal en una primera interpretación hecha por Igor Errazking, una maravillosa locura inspirada en la estética de las películas de expresionismo alemán en la que no se pudo continuar por falta de tiempo del colaborador.


Finalmente Bieno se encargó en exclusiva de la realización de los gráficos en C64, lo que llevó a una de las partes más laboriosas de todo el proceso de creación, que fue portar los susodichos gráficos a los otros sistemas. A diferencia de lo que sucedería posteriormente con DAAD, en Quill no hay (o no se llegó a lanzar) ninguna herramienta de conversión entre los gráficos de un sistema y otros, por lo que hubo que realizar un montón de cosas «a mano». Para Spectrum había que convertir los gráficos de Quill de C64 a gráficos de DAAD de Spectrum teniendo en cuenta que la pantalla de C64 tiene una resolución horizontal notablemente superior (64 bytes mayor, el equivalente a 8 caracteres). Entre la disyuntiva de intentar hacer una versión reescalada para ZX o cercenar parte de la imagen en cada gráfico lo último fue lo más viable y acertado. Algunas pantallas se prestaban bastanta bien a prescindir de las partes laterales, o a hacer un «corte» en alguna parte interior donde quedase hueco. Con ello en mente, el proceso consistió en tomar nota manualmente de cada órden gráfica de C64, pasar sus coordenadas a las equivalentes de la pantalla de Spectrum (con un oportuno script de Python) e introducir manualmente la órden con su código y sus nuevas coordenadas en el editor de gráficos de DAAD para Speccy. Nada difícil, aunque desde luego aburrido de narices. Todo fue cuestión de dedicarle sin prisa ni ansia un rato cada día poniendo una buena música de fondo y sin obsesionarse por acabar

Con la intención de evitar que la conversión de los gráficos de C64 a Amstrad CPC fuera tan tediosa como en Spectrum, pensamos en buscar un modo de automatizar el proceso. Aparentemente sería más sencillo dado que el tamaño y resolución de sus respectivas pantallas es el mismo así que no habría que preocuparse por andar buscando areas «recortables» lo que haría la conversión algo más directa. Las facilidades terminaban ahí, claro, ya que aunque las pantallas tengan igual tamaño, el hardware gráfico deñ C64 y del CPC se parecen como un huevo a una castaña. Aunque el formato en que están internamente codificadas las órdenes gráficas en uno y otro tiene puntos en común, también tiene otros aspectos en que es sustancialmente distinto (ejes de coordenadas que van en distinta dirección, entramados cuyo manejo no tiene nada que ver en un caso y en otro…) así que finalmente hubo que:

-Hacer ingeniería inversa del formato de gráficos de C64.
-Hacer ingeniería inversas del de CPC.
-Crear un script de Python que convirtiese del uno al otro.

Como el destino tenía escrito en letras de fuego que nada relacionado con los gráficos en Torreoscura tenía que ser sencillo y directo pronto nos encontramos con un dilema adicional. Trabajábamos con las ultimísimas versiones conservadas tanto de Quill como de Illustrator para Amstrad CPC, pero por más que rebuscábamos en todas las opciones disponibles, no había ninguna aparente manera de conseguir en éste sacar los gráficos a pantalla partida como en el caso de C64. El único modo era a pantalla completa, es decir, en cada localidad sale el gráfico ocupando toda la pantalla hasta que pulsas una tecla, se borra, y ya entonces sale el texto con la descripción del lugar. Y sin embargo, como MiguelSky hizo notar rápidamente, hay evidencia histórica de una buena cantidad de aventuras hechas con Quill para CPC que sí tienen los gráficos a pantalla partida (una ventana gráfica en la parte superior de la pantalla para el dibujo y otra en la inferior para los textos), como, por poner tan sólo un ejemplo entre muchos, el Murder Off Miami de Delta 4 (una de mis obras clásicas favoritas por basarse en un antecedente de la FI de los años 30 del siglo pasado, pero esa sí que es otra historia…). En el Illustrator de C64 los gráficos a pantalla partida venían de serie en su última versión, en Spectrum se conseguían mediante utilidades hechas por terceros (The Patch), pero no había rastro del método utilizado en los juegos de CPC…

Así que tuvimos que crear el nuestro propio. Siguiendo la pista sugerida por MiguelSky tomamos nota de las llamadas a rutinas del sistema que manejan ventanas en CPC en el desemsamblado del intérprete de Quill e, investigando, localizar las que nos interesaba desviar a un hueco en la memoria libre donde pusimos llamadas a otras que a su vez dividían la pantalla del modo que queríamos para que la versión de CPC tuviese sus gráficos a pantalla partida igual que las demás. Una «ñapa» casera muy poco elegante pero que pasa totalmente desapercibida para el jugador, quien simplemente verá que en CPC los gráficos salen igual que en el resto de versiones sin preocuparse de los malabarismos que tuvimos que hacer para lograrlo.

Como no podía ser de otro modo, una vez que el trabajo ya estaba hecho se descubrió que, por existir, ya existía la herramienta que buscábamos. Las últimas ediciones de Illustrator para CPC incluían una utilidad llamada The Splitter de la que lo único que se conserva en este momento son unas fotos de las instrucciones y que, como su nombre sugería, servía para partir la pantalla de los juegos de Quill. Significativamente el programa está ausente en todas las versiones preservadas de Illustrator conocidas en la red hasta la fecha. En el momento de escribir estas líneas no se ha perdido la esperanza de que Tim Gilberts lo encuentre entre sus discos viejos para que, si hay suerte, los próximos en hacer una aventura en Quill para CPC no tengan que hacérsela ellos mismos como nosotros

Bastante menos complicado fue conseguir gráficos para la versión PCW, ya que estos no son más que un copia-pega de pantallazos de la versión de Commodore convertidos al formato de Degas PI1 usado habitualmente en Aventuras AD para pasarlos por la herramienta DG en su versión de MS-DOS. Como un paso intermedio del proceso era tener los gráficos para PC CGA, pues aprovechando que el Pisuerga pasa por Valladolid, también salió una bonita versión para PC MS-DOS

La pantalla de carga es original de R. Internacional excepto en las versiones de Spectrum y MSX, en las que las utilidades habituales de conversión automática de formatos daban unos resultados bastante pobres, por lo que optamos por sustituir el motivo de «atardecer» original por un nuevo gráfico «nocturno», más apropiado para sus paletas de colores, creado desde cero.

La versión de C64 incluye sendas piezas musicales creadas por Barón Ashler (de Kabuto Factory), una para oir durante la carga del juego en cinta y otra que suena de fondo durante la aventura. En Spectrum se usó la melodía de carga durante las pantallas de presentación de cada una de las 2 partes del juego y la música de fondo durante el resto de la aventura, como en el original. Ensamblar la música con el juego de Quill en C64 fue obra de Karmic, mientras que para Speccy (sólo 128k, como es habitual) usamos el motor musical CHIPnSFX de CNGSoft, al que se llama desde el gestor de interrupciones interno del propio DAAD, una combinación que ha dado muy buenos resultados. Que las llamadas al motor musical se hagan desde el propio DAAD además ha facilitado enormemente que, en Spectrum, desde órdenes del juego la música se pueda parar o reanudar al gusto del usuario, evitando el terrible efecto de precedentes como la versión 128k de The Neverending Story, donde la misma melodía machacona se reproducía en un bucle interminable sin posibilidad de parar salvo quitando el audio del ordenador/emulador. Torreoscura no será ni mucho menos la primera aventura conversacional con música de fondo, pero sí la primera hecha con DAAD en incluirla en su versión Spectrum

Torreoscura he dejado además como efecto colateral la creación de una nueva herramienta para DAAD pensada para facilitar la creación de versiones de aventuras para MSX en cinta (hasta ahora, desde la recuperación del DAAD en 2014, sólo el formato disquette estaba cubierto en MSX). ¿Recordáis ese párrafo del manual del DAAD que dice textualmente «there is no simple way to save files to cassette on MSX»? Bien, ya lo hay, se llama DAAD2MSXCas y es un script de Python pensado para cubrir ese «there is no simple way» ensamblando una imagen de cinta de MSX (fichero .cas) a partir de los ficheros DDB y MDG correspondientes.
Debido al complejo mapa interno de memoria de los juegos de DAAD en MSX (usando 64 Kb como RAM) es bastante complicado preparar un cargador de cinta que use las rutinas de la ROM. DAAD2MSXCas usa una modificación del cargador personalizado de Aventuras AD (sacado de la versión MSX en cinta de Los Templos Sagrados) que se automodifica para adaptarse a la carga de los ficheros de la aventura que estés haciendo. Los pythoneros pueden encontarlo en:

https://pypi.org/project/daad2msxcas/

Y hasta aquí las aburridas batallitas técnicas del «cómo se hizo». Todos los implicados a un nivel u otro (no dejéis de ver la amplia sección de créditos) esperamos que el juego final os guste y os haga pasarlo bien. Podéis encontrarlo en cualquiera de las siguientes páginas web:

Zona FI

Commodore Plus

ESp Soft

Categorías: Planeta

Port a DAAD de "Las Aventuras de Rudolphine Rur" publicado

Hace 17 horas 51 mins

Publicado el port a DAAD de “Las Aventuras de Rudolphine Rur”.
Se trata de un port a DAAD de una aventura ya publicada en 2005, para sistemas “modernos” (máquina virtual Glulx y web). Ahora, con el port a DAAD, la aventura podrá jugarse en sistemas “retro” como: ZX Spectrum, Amstrad CPC, Amstrad PCW, MSX, MSX2, Commodore 64, PC MS-DOS, Atari ST y Amiga.
Hay un total de 18 descargas diferentes (16 correspondientes a este port a DAAD), existiendo versiones en cinta, disco y para dispositivos de carga rápida tipo DIVMMC, M4, SD, etc.
Podéis descargarla en su web: www.rudolphinerur.com
En los próximos días se pondrá a la venta una pequeña tirada física. Os mantendremos informados.
¡Disfrutadla!

Categorías: Planeta

Alerta de virus en los discos de «El cetro del sol» para AMIGA.

Hace 17 horas 51 mins

Malas noticias para los poseedores de copias físicas y/o descargadas del port para AMIGA de «El cetro del sol». Si habéis descargado vuestra copia en fecha anterior a ayer 13 de febrero de 2020, con toda seguridad el fichero ejecutable del juego, llamado «Cetro», está infectado con el virus «Ebola», un virus clásico del AMIGA para el que inexcusablemente no tomé las mínimas precauciones durante la fase de cración y testeo de esta versión del juego.

Peor aún, por lo que he podido comprobar, las ediciones físicas de la aventura que se hicieron expresamente para servir de recompensa en el crowfunding de la Enciclopedia Homebrew Vol. 2, realizadas a partir de esos mismos ficheros, están igualmente infectadas.

Debo resaltar que el autor original de la aventura de texto, Toni Pera, es enteramente ajeno al desaguisado, ya que el port para AMIGA fue labor mía y se realizó en mis ordenadores, donde se produjo el «contagio».

Debo pedir públicamente disculpas por mi imprudencia al dar por hecho que hoy en día podía despreocuparme del tema de la transmisión de virus en una plataforma retro como el AMIGA, máxime cuando todos sabemos que históricamente éste tuvo una muy nutrida fauna propia de amenazas tóxicas. Quizá no tenga excesiva importancia si eres un simple usuario nostálgico, pero en el momento en el que pones algo, la mínima cosa, a distribución pública, es imperativo realizar un chequeo con antivirus. Incluso considerando que yo no fuera el «culpable» original de la cadena de transmisión, si fue responsabilidad mía no haber reparado en esa posibilidad, como a partir de ahora, muy a mi pesar, voy a recordar cada vez que vea el pantallazo con las más de 1100 descargas que el juego ha tenido sólo en Aminet.

Podéis encontrar información sobre el virus Ebola de AMIGA en la página web del Virus Help Team, concretamente en:

https://www.vht-dk.dk/amiga/desc/txt/ebola.htm

Como podéis ver, dentro de la gravedad del asunto, al menos el Ebola no es de las especies más agresivas. Es un virus de tipo «link». No se propaga por sectores de arranque de discos y aunque se queda residente en memoria no sobrevive a los reseteos. Tampoco se conoce que cause expresamente daños adicionales. Pero ser de los «menos malos» no quita el hecho de que se dedique a dar por saco a base de bien replicándose en ficheros ejecutables. En un Amiga 500 «pelao» puede incluso no causar «muchos» problemas ya que comunmente se hace un reset al acabar un juego. En sistemas, reales o emulados, con disco duro ya se vuelve un huesped bastante más pesado, ya que tiende a replicarse en ficheros de uso común como los comandos de la carpeta C, particularmente los que se ejecuten en cada Startup-Sequence al arrancar el ordenador, lo que multiplica sustancialmente sus probabilidades de superviviencia y difusión.

Afortunadamente al ser ya un «viejo conocido» la práctica totalidad de antivirus pueden retirarlo de la memoria y limpiar de una pasada todos los ficheros afectados. Pero CUIDADO, que mi primer intento fue un sonado fracaso. Usé VirusChecker II, que afirmaba estar retirando el virus de los ficheros. Por motivos que aún no acabo de entender muy bien, sin embargo, los ficheros desinfectados dejaron de ser utilizables. Al intentar ejecutar cualquiera en el shell del Amiga se producía un error de «bad loadfile hunk» (vamos, que al quitar el virus el fichero había sido dañado, probablemente ya sin remedio). Teniendo en cuenta que esto sucede con numerosos comandos del sistema de la carpeta C, todo el arranque de mi Amiga emulado con WinUAE (del que piadosamente tenía una copia de seguridad) quedó poco menos que arruinado.

En mi Amiga 1200 real, tras muchos ensayos y precauciones con copias, pude realizar el proceso de limpieza exitosamente y sin sobresaltos con VirusZ III. Así que debo insistir, basándome en mi experiencia concreta, que para retirar el Ebola:

-NO usar VirusChecker II
-USAR VirusZ III

Podéis informaros sobre VirusZ III también en la web del Virus Help Team en:

https://www.vht-dk.dk/amiga/vz/vz.htm

La descarga de VirusZ III no incluye algunas de las librerías comunes de AMIGA necesarias para su funcionamento, pero ésto se explica con claridad en la documentación y las librerías se encuentran disponibles en Aminet. Lamento que no sea la vía más sencilla y directa, pero es la única que puedo recomendar sin correr riesgo de crear destrozos adicionales.

En cualquier caso, las imágenes de disquette adf descargables tanto desde la página web de «El cetro del sol»:

http://www.zonafi.rockersuke.com/if/cetro_del_sol/descargas.html

… com desde su ficha en Aminet:

http://aminet.net/package/game/text/cetro_del_sol

… ya han sido debidamente saneadas. Si habéis estado en contacto con este juego ya sea en Amiga reales o emulados, no dejéis de pasar un antivirus (con las consideraciones que he expuesto más arriba) a la mayor brevedad.

Si sois alguno de los afortunados poseedores de las copias físicas (si mal no recuerdo, una tirada de 20) podéis grabar el contenido del adf en el disquette para tener una copia funcional y sin virus.

Si no sabéis exactamente cómo hacerlo o no tenéis los medios precisos, no dudéis en contactar conmigo por los comentarios del este post, redes sociales o en el mail «rockersuke» en gmail punto com. Podremos ponernos de acuerdo para que me mandéis el disquette por correo ordinario y os lo devuelva sin presencias indeseadas. Como mínimo el envío de vuelta correría de mi cuenta (y si me pasáis una cuenta bancaria o de paypal os ingresaría el del envío de ida).

Para tranquilidad de los usuarios de DAAD que estén haciendo cosas para AMIGA, los disquettes de AMIGA de la descarga del DAAD están limpios y son seguros de usar.

Dicho todo lo cual, vuelvo a reiterar mis disculpas por todo el desastre. Podría reabrir el debate sobre la maldad intrínseca de distribuir software malicioso como se hacía en el AMIGA hace 30 años, pero sería éso, un debate para hace 30 años. Sí cabe recordar que quizá (bueno, y no tan «quizá» ) no estamos tan libres como queremos pensar de los pecados y excesos que cometieron, o cometimos, en otras generaciones. Vivir en el 2020 no es un colchón mágico que nos haga inmunes a las «armas de destrucción masiva» del pasado y que el objeto de nuestra afición sea consideradao como «retro» no es excusa para bajar la guardia ante peligros que consideramos superados u obsoletos. Vamos, que si lanzáis juegos de AMIGA, siempre, siempre, pasadlos antes por un antivrus

Categorías: Planeta

(c)1998-2019 CAAD

Todos los contenidos de esta web son propiedad de CAAD. Las colaboraciones son propiedad de sus respectivos autores.