SPAC
Portada > Webzine > Sección objetiva > Teoría > El ACÁ - El Autómata de Conversacionales Aventuras

El ACÁ - El Autómata de Conversacionales Aventuras

Miércoles 2 de abril de 2008, por Mel Hython

En varias ocasiones se ha hablado en el foro del CAAD sobre cuales son las mejores aproximaciones para un parser muy simplificado. En este artículo se analiza una de estas posibilidades. No la que yo escogería, pero una posibilidad.

Este artículo no pretende alcanzar PAPAÍTO, de hecho ni siquiera pretende acercarse a él. Este artículo viene a explorar las ideas que JBG ha expresado repetidamente en los foros. Y en cierta forma en este artículo del SPAC.

Su idea central es básicamente (e interpretado libremente por mí): “si los relatos interactivo son relatos y por lo tanto lo que realmente importa es el texto que se presenta como respuesta de los tecleado por el usuario, ¿la programación no podría reducirse a simplemente eso?”. En definitiva, ¿se podría disponer de un lenguaje ’simplificado’ que no tuviese que estar ligado a un paradigma de programación, como por ejemplo Orientación a Objetos?. Su hipótesis es que si creamos desde cero un lenguaje orientándolo desde su mismo origen a la creación de aventuras el resultado será lo más adecuado para crear aventuras.

En este artículo exploro esta idea. Lo voy improvisando sobre la marcha, así que seguro que queda fatal, pero bueno, ya sabéis que soy el depravado del CAAD (¿o tal vez el enloquecido?) así que no podéis esperar otra cosa.

Para empezar decir que simplemente no podemos prescindir de todos los paradigmas de programación, porque queremos o no estamos construyendo una herramienta informática. Pero podemos ir a las mismas bases a ver qué pasa. Si desposeemos a la programación de facilidades como los objetos, o incluso más allá, ¿qué nos queda? Tal vez podamos pensar en la máquina algoritmica más simple de todas la Máquina de Turing.

Desde luego dicho así parece una atrocidad, pero... ¿realmente estamos tan lejos de necesitar simplemente un autómata?. Pensemos cuales son los componenets básicos que realmente necesitamos:

- Poder tratar el input del jugador para casarlo con alguna clase de gramática o patrones.
- Poder responder con texto.
- Para que las respuestas sean coherentes necesitamos de alguna forma un ’estado’, lo que se ha venido en llamar ’el modelo y estado del mundo’.

¿No están todos esos componentes en una máquina de Turing? Tenemos entradas de datos (los comandos lanzados por el jugador), tenemos estados internos (el estado del mundo de la aventura) y tenemos salidas (respuestas en texto).

Evidentemente programar una aventura en una máquina de Turing real sería un verdadero incordio... pero, ¿y en algo un poco más especializado?

Hagamos el siguiente modelo:

- Nuestro ’parser’ va a ser un autómata, cuyo grafo de transiciones es la aventura misma.
- Los arcos de las transiciones serán condiciones necesarias para pasar de un estado a otro incluyendo entre estos requisitos las entradas del jugador. Junto a estas condiciones habrá ’respuestas’, textos que propocionar al jugador.
- El estado del autómata será un enorme vector de ’hechos’. Un hecho podrá ser cualquier cosa que el programador quiera, y los cambios de estado serán del tipo ’inclusión de un hecho’ o ’supresión de un hecho’.

Improvisemos una sintaxis:

- Una expresión entre comillas dobles será una respuesta a dar al jugador.
- Una expresión entre paréntesis será una condición de transición, en donde la ’,’ hace el papel de AND y el ’|’ hace el papel de OR. Se admiten subparéntesis para agrupar adecuadamente estas condiciones.
- Una negación ’-’ en una condición implicará la inexistencia de tal hecho.
- Consideraremos una expresión entre comillas simples como una entrada del jugador.
- Junto a la condición de transición se incluirá un bloque entre corchetes que indicará el cambio de estado a realizar y posiblemente expresiones entre comillas dobles que corresponden a la respuesta.
- Supondremos una condición inicial llamada INICIO que se dará sólo cuando la aventura inicie.
- Supondremos una condición especial llamda DEFECTO que se considerará válida solo cuando ninguna otra haya funcionado.
- Supondremos un hecho especial llamado FIN que implicará que la aventura ha terminado.
- Para incluir un hecho en el estado considerarmos la sintaxis ’+ hecho’ y para suprimirlo la ’- hecho’.

Con esa sintaxis podría escribir algo como esto:

(INICIO) [ "Despiertas y sólo puedes ver un túnel con una luz en el fondo." ]

(’salir’|’sal’|salgo’) [ "Aunque te da bastante miedo decides atravesar finalmente el túnel." + FIN ]

(DEFECTO) [ "No sabes qué será, pero no es eso lo que has de hacer." ]

¡Vaya! Si ya tenemos una participante en la XComp. Vamos a complicarla mínimamente:

(INICIO) [ "Despiertas y sólo puedes ver una puerta cerrada." + Puerta Cerrada ]

(’salir’|’sal’|salgo’, Puerta Cerrada) [ "No puedes ir a ninguna parte mientras la puerta esté cerrada." ]

(’salir’|’sal’|salgo’) [ "Aunque te da bastante miedo decides atravesar finalmente el túnel." + FIN ]

(’m’|’mirar’, Puerta Cerrada) [ "Todo está tan oscuro que solo puede verse una puerta cerrada." ]

(’m’|’mirar’) [ "En la oscuridad destaca el túnel luminoso que se escondía tras la puerta." ]

(’abrir puerta’|’abre puerta’|’abro puerta’, Puerta Cerrada) [ "Con algo de miedo abres la puerta, desvelando un luminoso pasillo." - Puerta Cerrada ]

(’abrir puerta’|’abre puerta’|’abro puerta’) [ "Ya está abierta." ]

(DEFECTO) [ "No sabes qué será, pero no es eso lo que has de hacer." ]

¡Vaya esto puede funcionar!

Si, el ACÁ es realizable y se puede usar. Evidentemente habría que darle algunas facilidades más para que fuese razonable:

- Hechos especiales de tipo ’variable’. Algo así como ’Puerta ESTA Cerrada’. Si el sistema reconoce las construcciones ESTA o ES como algo especial cuando le dijésemos ’+ Puerta ESTA Abierta’, vería que ambos hechos son incompatibles y tendríamos algo parecido a unas variables.

- Patrones de gramática razonables: ’abrir|abre *’, ’coge|cojo|coger *’.

- Formas de escribir texto dependiendo de la existencia o no de determinados hechos.

- Tal vez bucles, condiciones, etc...

Si le añadimos demasiado tal vez nos alejemos del propósito inicial, así que cuidado.

En definitiva, como habéis visto lo que yo entiendo que da vueltas en la cabeza de JBG se puede llevar a cabo, el ACÁ, se puede realizar. ¿Resulta más útil y cómodo que lo disponible hasta ahora? Tengo serias dudas, pero para eso están los comentarios a este artículo.

10 Comentarios

  • El ACÁ - El Autómata de Conversacionales Aventuras

    2 de abril de 2008 13:29, por planseldon
    Creo que está bien pensado, y sin duda es mucho más fácil de aprender que informate o superglus, pero sigue planteando el mismo problema: se trabaja con un "lenguaje", y eso hace que para la mayoría de la gente sea inaccesible. La idea de Papaíto era precisamente que todo sea visual, no necesariamente porque sea más fácil, sino por crear una herramienta para quienes NUNCA se plantearían programar una aventura en un lenguaje de programación y, sin embargo, si que se atreverían a intentarlo en un entorno 100% visual.
  • El ACÁ - El Autómata de Conversacionales Aventuras

    2 de abril de 2008 13:52, por Al-Khwarizmi

    La teoría de autómatas está ahí desde hace muchos años, y si no se suelen utilizar autómatas finitos para hacer programas (salvo los analizadores léxicos) es por algo...

    Al final, en cuanto quisieras hacer tu aventura mínimamente compleja, tendrías un porrón de estados (estoy en tal sitio y he cogido el objeto A y el B pero no el C, estoy en ese mismo sitio y he cogido el A pero no el B ni el C...). Se produciría una explosión combinatoria en la cantidad de estados y de chequeos que tendrías que hacer.

    Por supuesto puedes agrupar estados (tú lo estás haciendo implícitamente, estás diciendo que "+PuertaCerrada" te lleva de cualquier estado que no tenga PuertaCerrada a un estado que es igual en todo, menos en que tiene PuertaCerrada). Pero aun así, como mínimo tienes un grave problema de desestructuración, al final acabas con una lista enorme de ifs que dependen todos unos de otros y no es mantenible. Para resolver ese tipo de problemas se crean aproximaciones más abstractas como la programación orientada a objetos, que te permiten estructurar un poco esos estados dividiéndolos en partes manejables. Al convertir la enorme lista de transiciones en una abstracción estructurada, estás haciéndola más manejable, pues es más fácil ver de un vistazo lo que hace, y también modificar una parte.

    Sinceramente, y siento ser duro, creo que con esto de intentar encontrar un lenguaje "ultra-sencillo" estáis perdiendo el tiempo. Llevamos como cincuenta años de investigación en lenguajes de programación, investigación que en gran medida ha buscado incrementar la sencillez y la productividad (se trata de hacer más cosas sobrecargando menos la cabeza). La programación orientada a objetos es fruto de esas investigaciones. Al final, cuando la gente se pone a diseñar lenguajes, siempre acaba llegando a la conclusión de que hace falta algún tipo de encapsulación (llámale módulos, objetos, funciones en programación funcional, etc.) para manejar problemas medianamente grandes. Las listas interminables de condiciones "if" parecen muy bonitas cuando tienen diez de esas condiciones, pero cuando empiezan a tener cientos ya no lo son tanto.

    A la hora de intentar suavizar la curva de aprendizaje de los novatos, veo más viable la alternativa de intentar hacer IDEs y herramientas gráficas que la de hacer un superlenguaje hipersimple revolucionario. Los IDEs sí que van progresando en muchas disciplinas, los superlenguajes hipersimples no existen (lo más próximo que he visto es I7).

    • El ACÁ - El Autómata de Conversacionales Aventuras 2 de abril de 2008 16:00, por Mel Hython
      Hola Al-K. Que conste que NO, intento buscar este camino yo, solo pretendía clarifiar el pinta que tendría. Yo ya sé el problema que tiene esto a nivel de lo difícil que acaba siendo ordenar el resultado.
  • El ACÁ - El Autómata de Conversacionales Aventuras

    2 de abril de 2008 17:26, por JBG

    Hola Mel.

    Me ha parecido interesante tu artículo, se nota que realmente te has puesto a experimentar lo que debe ser buscar tu propio lenguaje (partiendo de cero), para programar ACs, aunque digas que lo has hecho todo en plan improvisado ;).

    Por otro lado, dado que se supone que el artículo intenta explorar algunas ideas básicamente expuestas por mi en el foro, pero siempre desde tu interpretación, es lógico que venga a matizar cualquier idea que haya observado que por lo que sea, note que no se ajuste bien a mi manera de pensar, y que alguien por tanto pudiera atribuirme erróneamente, como podría ser Al-Khwarizmi.

    Voy al grano:

    Has estado muy acertado cuando has dicho que "Su hipótesis es que si creamos desde cero un lenguaje orientándolo desde su mismo origen a la creación de aventuras el resultado será lo más adecuado para crear aventuras.", porque realmente pienso eso, pero si no interpreto mal por el resto del artículo y el comentario de Al-k, se está enfocando la cosa como si necesariamente la idea fuera encontrar un lenguaje que rechace ideas OO, y cualquier otro tipo de ideas conocidas, con el objeto de obtener un lenguaje minimalista y teóricamente sencillo, y no es exactamente así.

    Veréis esto es muy importante de aclarar, porque como dice Al-k efectivamente un lenguaje así no existe e intentar buscarlo desesperadamente sólo sería una pérdida de tiempo.

    Me explico: Rechazar ideas OO o cualquier otro tipo de ideas ya conocidas en el mundo de la programación, para buscar un lenguaje orientado a ACs desde cero, no es un objetivo, es un punto de partida. Cuidado con eso.

    Por ejemplo no se trataría de buscar un lenguaje parecido a un autómata, ni a una máquina de Turing, ni parecido a OO, ni "parecido a" nada, todo está en el mismo saco. La idea es investigar hasta dar con el lenguaje que necesitamos, es una incógnita qué aspecto final va a tener en conjunto dicho lenguaje, y no nos importa a qué se parezca con tal de que realmente resuelva nuestras necesidades.

    En ese sentido es en el que, (al inicio de la investigación de un lenguaje para ACs), rechazo ideas preconcebidas, pues toda suposición nuestra acerca del aspecto final que debería tener el lenguaje ideal que buscamos, es un error, porque nos desvía de la investigación honesta, (la que parte del desconocimiento), y nos conduce al diseño de un lenguaje que inconscientemente sólo pretende ajustarse a nuestra probablemente equivocada suposición del tal lenguaje ideal.

    Pero repito, ¿esto significa que lo rechazamos todo hasta el final?, no. Sólo es un punto de partida. Qué tomaremos en el camino y a dónde llegaremos finalmente es un misterio. Y sabemos que es muy probable que el aspecto final del lenguaje sea el de uno que incorpora ideas OO, ideas X, Y, Z... algunas ya viejas conocidas de la programación, y otras quizás más inéditas nacidas de nuestro ingenio, ¿pero qué más da a que se parezca?, lo único que uno puede temer es que se parezca demasiado a algo que ya exista, pero si no tienes fé en hacer algo que merezca la pena por encima de lo que ya pueda existir, entonces esta no es tu Aventura, y no escojo la palabra al azar ;).

    • El ACÁ - El Autómata de Conversacionales Aventuras 2 de abril de 2008 19:25, por Mel Hython

      Esto... vale... pero JBG, la pregunta es más bien, el ACÁ, ¿es algo parecido a lo que tendrías en mente o es otra cosa?

      En cuanto a lo de improvisado o no... el otro día cuando hablaste en el foro se me ocurrió la base de esto y para serte sincero no he podido hacer ni pensar en nada hasta hoy y sí, lo he escrito de corrido corrigiendo sólo un par de frases, así que está improvisado.

      • No, ni en sintaxis ni en potencia. Lo que si comparte el ACÁ con lo que tengo desarrollado es en aplicar la filosofía de que el autor decide qué ocurre según qué es lo que diga el jugador. De todos modos la manera en que se aplica ese esquema está mucho más avanzada a como lo haría el ACÁ.

        Añádanle a este comentario mi mensaje anterior, que explica qué tipo de planteamiento es el que yo he estado aplicando para buscar un lenguaje.

        A ver si lo termino pronto.

        Un saludo a todos.

    • El ACÁ - El Autómata de Conversacionales Aventuras 3 de abril de 2008 09:58, por Al-Khwarizmi

      Ya, si entiendo lo que dices. Lo que tú quieres es poner en duda todo lo que se ha hecho antes para no partir de ideas preconcebidas, como Descartes en su "Discurso del Método".

      No dudo que esa metodología te pueda llevar a buenos resultados. Simplemente, en mi opinión esos resultados van a acabar siendo una forma de orientación a objetos, porque me parece bastante claro que es el mejor paradigma (de los conocidos en programación) para modelar una aventura. Y para eso se gana tiempo dando por hecho que uno va a usar un modelo orientado a objetos desde el primer momento.

      Mira el experimento I7 vs. TADS que salía últimamente en RAIF... Se enfrenta un lenguaje orientado a objetos puro, tradicional, de manual; contra una cosa bastante rara surgida específicamente para crear aventuras y para ser más "literaria"... y resulta que hasta los escritores que no habían programado en su vida acabaron prefiriendo el lenguaje orientado a objetos clásico.

      Yo creo que si se quiere programar el mejor sistema lo único que hay que hacer es aplicar estas ideas, que llevan funcionando muchos años en todo tipo de sistemas (sistemas en los que, en la mayoría de los casos, los objetos son mucho menos claros que en las aventuras, donde coinciden directamente con los objetos de mundo simulado). Lo que hace que un sistema como I6 resulte insuficiente no es el paradigma de programación que usa, que está bien; sino más bien problemas de diseño y de acabado: tener que compilar para una máquina arcaica, falta de capacidad para juego en red, que la multimedia sea un infierno, modelo de objetos y eventos que deja que desear, capas que se podrían añadir por encima y no existen como los tan cacareados IDE’s gráficos, etc.

      Otra cosa es si lo que uno busca no es programar el mejor sistema; sino un sistema que no meta miedo a la gente que no quiere aprender a programar. Pero esto ya casi es un problema de márketing (mira cómo aquellos literatos, cuando probaron TADS no quedaron descontentos, el problema es convencerles de que lo prueben). Y, en todo caso, creo que la manera de resolver este problema de márketing también pasa más por cosas como IDEs, capas y tutoriales que por cambios de paradigma.

      Pero bueno, de todas formas tu experiencia es interesante. Así no se podrá decir que se crean los sistemas de una determinada manera porque se parte de ideas preconcebidas erróneas.

  • El ACÁ - El Autómata de Conversacionales Aventuras

    3 de mayo de 2010 18:09, por Mel Hython

    Que gracia... revisando sistemas de autoría me he encontrado con el EAC de Lumpi, y las semejanzas entre el ACÁ y el listado del Vampiro de EAC para mi son evidentes...

    :)

    http://www.caad.es/informate/vampiro/vampiro_eac.zip


Seguir la vida del sitio  RSS 2.0: Artículos, Comentarios | Mapa del sitio | SPIP
CC Some rights reserved El contenido está disponible bajo los términos de Atribuir - Compartir bajo la misma licencia 3.0 ó 2.5 de Creative Commons.