CAAD

Comunidad de Aventuras Conversacionales y Relatos Interactivos
Fecha actual 18 Dic 2017 11:57

Todos los horarios son UTC + 1 hora




Nuevo tema Responder al tema  [ 13 mensajes ] 
Autor Mensaje
NotaPublicado: 15 Feb 2015 17:44 
Desconectado
Semimomio
Semimomio
Avatar de Usuario

Registrado: 24 Ago 2007 00:41
Mensajes: 2023
Ubicación: Chile
Hola chicos.

Hace una chorrera que no escribía aquí sobre algo concreto, pero esta vez quisiera solicitar los comentarios de todo el que quiera aportar algo sobre mis preguntas, sobre todo de los diseñadores / programadores / traductores / contribuidores de sistemas de IF como Al-K, Uto, avilches, tesheñes, Johan Paz, y alguno más que me dejo en el tintero.

Las preguntas son las siguientes:

Citar:
1. ¿Qué tipo de parser/parsing les ha resultado más conveniente de programar/implementar? (dejando a un lado las preferencias personales o la potencia del sistema o el lenguaje de programación)

2. ¿Qué tipo de parser/parsing piensan que requiere un desarrollo más sencillo, en la relación calidad-tiempo-esfuerzo?

3. ¿Qué modelo del mundo (base) recomiendan para un parser? (sencillo, complejo, intermedio; poner ejemplos si gustan) [Inform?, TADS3?, PAWS?, Otros?]

4. ¿A qué nivel de detalle del modelo del mundo/parsing es recomendable llegar?

5. Cualquier otra observación que deseen añadir.


Si las preguntas son demasiado ambiguas, pido disculpas. Sólo quiero conocer la impresión de cada uno para luego tomar una decisión. :)

Antemano, gracias por vuestros comentarios.

Saludos! ;)

_________________
Eliuk Blau
eliukblau (AT) gmail.com
http://www.caad.es/eliukblau/


Arriba
 Perfil  
 
NotaPublicado: 15 Feb 2015 20:07 
Desconectado
Samudio
Samudio
Avatar de Usuario

Registrado: 09 Mar 2004 16:16
Mensajes: 5274
Ubicación: Coruña
Vaya, interesante tema. ¿Estás pensando en hacer un parser? Cuenta, cuenta.

Te respondo a las preguntas, aunque en algunas no te puedo ayudar mucho porque son un poco complicadas:

1. En esto no te puedo decir mucho, porque sólo he implementado un parser, así que no puedo comparar la implementación de varios. Pero bueno, dentro de AGE, te puedo decir que posiblemente la característica que más complejidad ha añadido al desarrollo es el multijugador, ya que hay que dar soporte a que todos los eventos y sucesos que pueden ocurrir en el mundo se puedan ver desde distintas perspectivas, y te impide tomar muchos atajos de diseño (por ejemplo te fuerza a distinguir órdenes/acciones de cliente de los de servidor, etc.). Esto produce un diseño más limpio y potente (te proporciona "gratis" cosas como que los PNJ's puedan ejecutar órdenes ya que el jugador no puede ser un objeto único y distinguido como en Inform, etc.) pero es mucho más costoso de implementar. Un hipotético AGE monojugador habría sido bastante más sencillo.

2. Pues lo siento si mi respuesta suena a perogrullada, pero creo que simplemente cuanto más ambicioso sea el parser, más desarrollo requiere. Lo más fácil de desarrollar sería un sistema "choice-based" o de hipertexto, y a partir de ahí, cuantas más características y flexibilidad quieras añadir, más trabajo te va a dar.

De todas formas, más importante que el trabajo que dé o deje de dar es lo útil que sea, creo yo.

3. Bueno, yo recomiendo el de AGE, como es natural :lol: Es un modelo basado en que cada entidad del mundo tiene un determinado estado (expresado en forma de propiedades con valores), y un temporizador. Cada unidad de tiempo se decrementan en 1 los temporizadores de todas las entidades del mundo, y cuando el temporizador de una entidad llega a 0, se actualiza el estado llamando a un método de actualización propio de cada entidad. Se trata de un modelo sencillo, robusto, potente y adaptable, es un diseño que creo que salió muy bien y del que nunca me he arrepentido.

De lo que sí me he arrepentido en el diseño, y te prevengo, es de hacer que criaturas/PNJ's y cosas/items de la aventura fuesen clases distintas. Quita flexibilidad. Habría sido mejor que fuesen la misma clase.

4. Pues creo que no es recomendable llegar a mucho detalle en el modelo de mundo, porque al final lo importante es la flexibilidad. Si creas un modelo detalladísimo (lo típico de permitir poner unos objetos encima de otros, dentro, al lado, etc.; o tener respuestas por defecto en el parser para todo tipo de acciones peregrinas: que si saltar, rezar, estornudar...) al final para lo único que va a valer es para que los autores que realmente sean detallistas y se preocupen de hacer aventuras de gran calidad tengan que sobreescribirlo todo para ponerlo a su manera, porque no tienen por qué querer hacer las cosas exactamente como tú las has puesto por defecto. Y para los autores que no son detallistas, para lo único que vale es para que sus aventuras incluyan respuestas o reacciones que son anti-inmersión, porque están programadas por defecto para situaciones genéricas y el autor no las ha adaptado.

Yo te puedo decir que con AGE, si lo reimplementara, le metería menos cosas en el modelo de mundo, no más. Lo importante es que haya los menores límites posibles para el programador a la hora de redefinirlo todo.

_________________
Actúa siempre de tal modo que las decisiones de tu voluntad pudiesen servir como preceptos de una legislación universal (E. Kant)


Arriba
 Perfil  
 
NotaPublicado: 15 Feb 2015 23:07 
Desconectado
Betatester
Betatester
Avatar de Usuario

Registrado: 24 Dic 2010 14:37
Mensajes: 891
  1. No se entiende la pregunta, no me queda claro si preguntas por la creación del parser, o de la creación de obras con el parser. Lo primero no sé qué utilidad tiene contestarla. Pero en cualquier caso, no hagas otro parser. Hay demasiados y los que los usan o los que los crean ni se hablan ni se entienden, por ejemplo la respuesta de Al-K en la que menciona a Inform es completamente desinformada, lo que demuestra la falta de interés de unos creadores sobre las obras de otros parsers. No hagas otro parser. Es esfuerzo tirado a la papelera.
  2. Otra pregunta que carece de sentido. Pero en cualquier caso no hagas otro parser. Sobre todo antes de haber hecho una aventura con todos y cada uno de los que ya existes o estarás haciendo una porquería.
  3. El modelo del mundo debe estar en una librería no en el parser. Meterlo en el parser es un error y otra pérdida de tiempo. Preocúpate, de lo que es más importante el parser en sí, quiero decir, la parte que entiende las frases. Si no haces una mejora sustancial en la comprensión de frases que vaya mucho más allá de lo que tiene los parser actuales no hagas otro parser. Y sobre todo no hagas un parser sin haber hecho unas cuantas aventuras largas y haber experimentado tu mismo la dificultad que representa.
  4. Parseado de frases todo. Modelo del mundo lo más bajo posible. Eso sí, hasta no haber hecho una aventura que no sea sorda como una tapia con algún otro parser, NO HAGAS OTRO PARSER, porque será otra basura más.
  5. NO HAGAS OTRO PARSER, demuestra primero que sabes hacer aventuras con un par de las herramientas que ya existen.


Arriba
 Perfil  
 
NotaPublicado: 16 Feb 2015 00:37 
Desconectado
Momio
Momio
Avatar de Usuario

Registrado: 09 Mar 2004 16:14
Mensajes: 4614
Me temo que ni siquiera entiendo la mayoría de tus preguntas, y como además yo solo he hecho parsers tipo PAW, es difícil decir qué es más difícil de hacer. Sin embargo si sabría decirte unas cuantas cosas que pienso sobre los parsers, si de ahí sacas respuestas a tus preguntas es cosa tuya :-)

- Hacer parsers tipo PAW me parece más fácil que hacer parsers de otro tipo, salvo que sea un parser que directamente sea en un lenguaje de programación (como fi.js) y por tanto no necesite de un compilador (y si como fi.js no necesitas tampoco desarrollar un intérprete, mejor que mejor).

- No me gustan los analizadores estrictos (el parseado en si mismo), como jugador prefiero los tipo PAW, y como autor creo que además son más fáciles de hacer. Ambos modelos dan lugar a problemas de "parser que se pasa de listo", pero el estricto acaba siendo incómodo para el jugador, en español más aún. NMP tenía un parseado cero estricto, mientras que Superglús (desde cierta versión) y ngPAWS también son no estrictos, pero tienen ciertas funcionalidades para permitir diferenciar "METE EN LA CAJA EL BARRIL" de "METE LA CAJA EN EL BARRIL" o "ABRIR" de "ABRIR YYTWEY"(donde YYTWEY es una palabra desconocida).

- El modelo del mundo tiene que tener cierta profundidad, pero no creo en el simulacionismo.

- Las respuestas por defecto tienen que ser muy muy muy neutras, o corren el riesgo de romper la inmersión. Y no hay que llevarlo a un extremo absurdo. En ese sentido creo que las actions de Inform son muy razonables, pero llegar a limites como poner respuestas a rezar o estornudar no.

- La sintaxis de un parser debe ser parecida a la de otros, o a la de lenguajes de programación. No se debe reinventarse la rueda.

- Muchos parsers tienen implementadas funcionalidades que luego nadie usa, o que se usan a modo de demo (lo uso porque se puede usar) pero no aportan nada desde el aspecto lúdico del juego.

_________________
Sígueme en twitter: @uto_dev
http://www.ngpaws.com


Arriba
 Perfil  
 
NotaPublicado: 16 Feb 2015 01:04 
Desconectado
Semimomio
Semimomio
Avatar de Usuario

Registrado: 23 Abr 2004 08:49
Mensajes: 2890
Ubicación: España (Galicia)
Hola,

Personalmente, siempre he renegado de crear nuevos parsers, hasta que en un momento dado decidí que por mucho que avanzara Inform, así como otras posibilidades existentes, estaban todos en una vía muerta, pues para mi el presente y el futuro está en soportar el juego en la web, de forma cómoda tanto para el desarrollador como para el jugador. Así que creé fi.js. En esta herramienta hay poco publicado, así que podríamos decir que es como una herramienta casi personal.

Hace poco salió ngPAWS y creo que es también un paso en la dirección correcta, por la misma razón. Al menos para quien le guste programar estilo PAWS, que son muchos.

Cuando creé fi.js, sabía que no tendría mucho tiempo ni recursos, así que realmente es un framework, no un sistema completo con compilador, runtime, etc. como ngPAWS. Así, programas en JavaScript, que es directamente lo que entiende el navegador, y punto. Hace un parsing no estricto, y aunque proporciona bastantes acciones por defecto, en realidad es bastante austero. ¿Quieres poner gráficos? Los soporta el navegador. ¿Quieres estilos de texto? Los soporta el navegador. Así, el framework solamente hace la vida un poco más sencilla, soportando las cuestiones más típicas.

¿Es sencillo escribir una aventura en fi.js? Sí, si eres programador. En otro caso, tienes que aprender a programar en JavaScript. Es un lenguaje de programación que se está perfilando mucho como de iniciación para principiantes, así que, por otra parte... Pero vamos, que no puedes escribir una aventura rellenando unos formularios.

_________________
-- Baltasar, el arquero


Arriba
 Perfil  
 
NotaPublicado: 16 Feb 2015 10:21 
Desconectado
Samudio
Samudio
Avatar de Usuario

Registrado: 09 Mar 2004 16:16
Mensajes: 5274
Ubicación: Coruña
Johan Paz escribió:
por ejemplo la respuesta de Al-K en la que menciona a Inform es completamente desinformada

Hombre, a lo mejor no me he expresado en los términos más precisos o lo que he dicho está desactualizado y ha cambiado, pero la realidad que he descrito existe o existió. En su momento se habló del tema y hubo informitas que lo comentaron. Por eso había una librería para hacer Inform multijugador que se basaba en un workaround, cambiando el objeto marcado como "el jugador" para ir ciclando y dar el control a todos los jugadores humanos.

Tampoco es algo que dijese como crítica. Que yo sepa Inform se diseñó para aventuras monojugador, cuando se creó no había interés en multijugador para nada. Así que era la decisión de diseño lógica en ese contexto.

Uto escribió:
- No me gustan los analizadores estrictos (el parseado en si mismo), como jugador prefiero los tipo PAW, y como autor creo que además son más fáciles de hacer. Ambos modelos dan lugar a problemas de "parser que se pasa de listo", pero el estricto acaba siendo incómodo para el jugador, en español más aún. NMP tenía un parseado cero estricto, mientras que Superglús (desde cierta versión) y ngPAWS también son no estrictos, pero tienen ciertas funcionalidades para permitir diferenciar "METE EN LA CAJA EL BARRIL" de "METE LA CAJA EN EL BARRIL" o "ABRIR" de "ABRIR YYTWEY"(donde YYTWEY es una palabra desconocida).

En mi respuesta se me pasó hablar del parsing, pero estoy totalmente de acuerdo, es mucho más práctico y útil el parsing no estricto. Una aventura tiene que aspirar a aceptar cuantas más entradas y formas de decir las cosas, mejor, y la forma de conseguir eso no es definir una gramática estricta.

Es curioso, porque en investigación en procesamiento del lenguaje natural es un hecho de aceptación prácticamente universal que las gramáticas estrictas son poco útiles en la práctica, y que cualquier analizador sintáctico debe ser lo más robusto posible. Prácticamente a nadie se le ocurre pensar otra cosa, y es rarísimo encontrar un paper de los últimos veinte años que proponga parsing estricto para lenguaje natural. Id a la demo del Stanford Parser (http://nlp.stanford.edu:8080/parser/index.jsp), uno de los parsers más conocidos, teclead algo como "take the aijdfadijf adhfi ahid afdsadf sword" y veréis cómo os lo analiza sin problemas, diciendo que "sword" es el objeto directo de "take". Para nada serviría rechazar la frase por tener cosas extrañas en medio, más que para reducir la funcionalidad del sistema que lo use. Siempre me ha llamado la atención que en la comunidad de ficción interactiva existan dudas al respecto de esto.

La solución de AGE es que se localizan las palabras importantes y se ignora el resto, al estilo PAWS. Eso sí, se proporciona al programador de la aventura acceso a toda la cadena, de forma que si quiere tener en cuenta el resto de palabras para algo, siempre puede hacerlo.

baltasarq escribió:
Personalmente, siempre he renegado de crear nuevos parsers, hasta que en un momento dado decidí que por mucho que avanzara Inform, así como otras posibilidades existentes, estaban todos en una vía muerta, pues para mi el presente y el futuro está en soportar el juego en la web

Con esto también estoy de acuerdo, aunque mi propio sistema esté entre los que se están quedando atrás. Me temo que todo pinta a que la mejor apuesta para el futuro está en la web. Aunque tampoco hablaría de que todo lo demás sea una vía muerta. Puede haber otras vías, cosas como distribución por Steam y similares. Pero la web es la más segura, sin duda.

_________________
Actúa siempre de tal modo que las decisiones de tu voluntad pudiesen servir como preceptos de una legislación universal (E. Kant)


Arriba
 Perfil  
 
NotaPublicado: 16 Feb 2015 22:54 
Desconectado
Yiepp
Yiepp

Registrado: 06 Oct 2004 15:12
Mensajes: 50
Ubicación: Madrid
Querido Eliuk: si te apetece hacer un parser, haz un parser. Si te apetece crear un juego, crea un juego. Si quieres simular a Eru, simula a Eru. Se trata de divertirse y poner en funcionamiento la molleja cerebral. No te lo tomes tan en serio como para sufrir un síndrome de "total pa qué". Haz un PAUGS, un INFORK, un CAECHO2000 o un EFLUVIO INTERACTIVE incorporando interface sensorial con olores. Lo que te apetezca. Pero, sobre todo, pásatelo bien.

_________________
=======================================
The GILSOFT PAW Reservoir
=======================================


Arriba
 Perfil  
 
NotaPublicado: 16 Feb 2015 23:33 
Desconectado
Betatester
Betatester
Avatar de Usuario

Registrado: 24 Dic 2010 14:37
Mensajes: 891
:D

Que haga lo que quiera; pero un parser no.

:P


Arriba
 Perfil  
 
NotaPublicado: 17 Feb 2015 03:41 
Desconectado
Aventurero
Aventurero

Registrado: 01 May 2014 14:46
Mensajes: 2
Creo que no entiendo del todo las preguntas originales aunque si estoy de acuerdo con lo que comentan arriba con que prefiero que el analizado no sea demasiado estricto y el modelo para el mundo que permita detalle sin entrar en simulaciones excesivas.


Arriba
 Perfil  
 
NotaPublicado: 17 Feb 2015 16:57 
Desconectado
Archivero
Archivero

Registrado: 19 Nov 2008 12:32
Mensajes: 268
eliuk! que gusto leerte!

pues yo solo conozco algunas cosas de I6/I7, desde la enfrascada-posición de desarrollador de extensiones.

Debería primero crear una aventura decente en varios sistemas y luego te diré.

Lo que aportan los muchachos mas arriba me parece interesante.


Arriba
 Perfil  
 
NotaPublicado: 17 Feb 2015 17:20 
Desconectado
Semimomio
Semimomio
Avatar de Usuario

Registrado: 24 Ago 2007 00:41
Mensajes: 2023
Ubicación: Chile
Johan Paz escribió:
:D

Que haga lo que quiera; pero un parser no.

:P


Seguro que no será de tu gusto, así que descuida... ;)

_________________
Eliuk Blau
eliukblau (AT) gmail.com
http://www.caad.es/eliukblau/


Arriba
 Perfil  
 
NotaPublicado: 20 Feb 2015 23:24 
Desconectado
Semimomio
Semimomio
Avatar de Usuario

Registrado: 24 Ago 2007 00:41
Mensajes: 2023
Ubicación: Chile
Gracias a todos por su tiempo y la valiosa información compartida. :mrgreen:

Se viene... :mrgreen:

Imagen

_________________
Eliuk Blau
eliukblau (AT) gmail.com
http://www.caad.es/eliukblau/


Arriba
 Perfil  
 
NotaPublicado: 21 Feb 2015 14:40 
Desconectado
Samudio
Samudio
Avatar de Usuario

Registrado: 10 Sep 2004 00:17
Mensajes: 3037
Ubicación: Chile
+1 :-) 8)

_________________
[Incanus]
El Escritorio - Blog Aventurero y Literario


Arriba
 Perfil  
 
Mostrar mensajes previos:  Ordenar por  
Nuevo tema Responder al tema  [ 13 mensajes ] 

Todos los horarios son UTC + 1 hora


¿Quién está conectado?

Usuarios navegando por este Foro: No hay usuarios registrados visitando el Foro y 2 invitados


No puede abrir nuevos temas en este Foro
No puede responder a temas en este Foro
No puede editar sus mensajes en este Foro
No puede borrar sus mensajes en este Foro

Buscar:
Saltar a:  
cron
Desarrollado por phpBB® Forum Software © phpBB Group
Traducción al español por Huan Manwë para phpBB-Es.COM