Si no ha leido anteriores entradas de esta bitácora, es conveniente que lo haga. Desde el índice tiene acceso a todas ellas.
Para, poco a poco, ir dando a conocer partes de la arquitectura global de pyphiverses, se describirán, a vista de pájaro, los elementos básicos que normalmente intervendrán en el proceso que parte de la entrada de texto para llegar a la ejecución de acciónes, todo ello sin tener en cuenta el sistema de Entrada/Salida, que queda abstraido, ni el de acciones, que merece tratarse aparte.
Se mencionará el uso genérico de la capa dimensión, sus ventajas y retos.Existen tres perfiles de acercamiento a pyphiverses. Ya sea desde el punto de vista del desarrollador de núcleo, del desarollador de extensiones o del autor.
En una persona pueden coexistir los tres roles, en mayor o menor medida.
Estas entradas de bitácora, al intentar dar una visión de conjunto, van mezclando información para los tres perfiles. Sin embargo, durante un tiempo habrá una clara tendencia a tratar temáticas más técnicas, ya que de éstas dependen las funcionalidades que se le ofrecerán al autor.
La gestión de cada entrada del "jugador" (Puppeteer, titiritero) puede realizarse utilizando un conjunto de clases, cada una con una labor específica, que empiezan desgranando el texto introducido y acaban ejecutando una acción por cada frase.
TextualInterpreter es la clase en la que basar los parsers. Se encargará, por ejemplo, de sanear la entrada del Puppeteer, dividir la entrada en frases y dividir cada frase en sus elementos fundamentales (sintagmas, p.ej.). Devuelve una lista con cada una de esas posibles frases (de clase ParsedSentence).
ActionInterpreter es la clase que ha de decidir qué acción está solicitando una frase. Para ello puede comienzar asignando, siempre que sea posible, mediante una EntityAssigner, a cada sintagma su entidad, empezando por el sujeto de la frase (normalmente el Puppet, títere). Posteriormente, mediante ActionResolver se decidirá la acción. Con esta información se crea un objeto ActionContext.
El ActionDispatcher utilizará ese ActionContext y se encargará de ejecutar la acción y devolver su salida para poder enviarsela de vuelta al Puppeteer vía el Puppet.
El nivel de detalle que implemente cada clase puede ser muy diverso, dependiendo del funcionamiento que se desee. Desde TextualInterpreter verbo+objeto a otros que identifiquen cada tipo de objeto y complemento gramatical. ActionInterpreter de una sola pasada o de refinamientos sucesivos utilizando incluso información de anteriores acciones u otro tipo de contexto. Incluso se puede prescindir de esta organización de clases y plantear una alternativa.
Como se puede observar, visto desde esta perspectiva, pyphiverses es un attoMOLE extendido, que permite (lo mismo que attoMOLE permitió crear attoPAWS) crear diferentes sistemas de autoría, cada uno con su propia personalidad y funcionalidades.
Cada obra o autor puede necesitar un determinado comportamiento. Tener un único conjunto de clases que los domine a todos no parece el camino correcto. Se cree adecuado que pyphiverses permita crear sabores diferentes de motor, utilizando piezas al gusto. Utilizando la capa dimensiones se podrán organizar las clases, recopiladas a modo de framework en el multiverso.
Las combinaciones posibles de esas clases son muchas, aunque no todas tendrán sentido desde el punto de vista funcional o práctico. Los desarrolladores podrán crear nuevas clases que implementen comportamientos innovadores o experimentales, o diferentes formas de enfocar el problema de la narración interactiva. El framework de pyphiverses presentará por defecto una o varias dimensiones con su propia filosofía que podrán usarse desde el primer momento.
Uno de los grandes retos que se encuentran en pyphiverses es determinar un posible común denominador de estas dimensiones, de forma que las Entity y otros elementos puedan traspasar la barrera de la dimension, al igual que se puede hacer entre universos y mundos de la misma dimensión. Algo que permitiera esto sería muy deseable, pero parece poco probable poder compatibilizar entidades que utilicen sistemas de parseado o de acciones muy dispares.
Por ejemplo, una entidad que requiera conocer si está siendo usada como complemento indirecto no podrá utilizarse en una dimensión en la cual no exista un TexualInterpreter que desgrane con ese detalle las frases. ¿Alguna idea de como poder implementar esto? Un planteamiento de partida puede ser dar por hecho que la única división obligatoria es la de sujeto+predicado y que las entidades siempre podrán utilizar esa división básica. Como último recurso siempre estará disponible la frase como cadena.
La opción extrema es plantear directamente las dimensiones como incompatibles por definición.
Como siempre, se ha creado un hilo para la discusión de esta entrada, en el foro del CAAD. Esperamos, agradecidos de antemano, vuestras dudas, sugerencias y comentarios.
Deseamos que haya sido de su agrado. dddddd.-