CAAD

Comunidad de Aventuras Conversacionales y Relatos Interactivos
Fecha actual 12 Ago 2020 22:35

Todos los horarios son UTC + 1 hora




Nuevo tema Responder al tema  [ 65 mensajes ]  Ir a página Anterior  1, 2, 3, 4, 5  Siguiente
Autor Mensaje
NotaPublicado: 01 Abr 2011 13:13 
Desconectado
Samudio
Samudio
Avatar de Usuario

Registrado: 10 Sep 2004 00:17
Mensajes: 3088
Ubicación: Chile
kalel099 escribió:
Sip, ahora ya te pillo por donde ibas jeje. Pero ese extra debe de correr a manos del autor de la aventura y el parser facilitar la tarea. ¿no? Esto es lo que entiendo yo por riqueza de una aventura desde que navego por estos lares.

Pues... sí.

De hecho, la "riqueza" de una aventura comienza donde termina la riqueza del sistema de autoría; un buen sistema de autoría, aparte de manejar algunos verbos de base o "típicos", deja en libertad al autor de aventuras para crear otros nuevos verbos, según su gusto o las necesidades del relato (los verbos derivados del texto de salida, etc.)

_________________
[Incanus] - Sígueme en itch.io
El Escritorio - Blog Aventurero y Literario


Arriba
 Perfil  
 
NotaPublicado: 01 Abr 2011 13:33 
Desconectado
Yiepp
Yiepp

Registrado: 01 Mar 2011 20:20
Mensajes: 77
Johan Paz escribió:
Creo, sinceramente, que esta situación es considerablemente más sencilla. La existencia de sinónimos DE PALABRA en fichero o en el código (en I7 sería con 'Understand the commands "sube", "aupa"... as "subir".), que era la pregunta original, no tiene nada que ver con todo lo anterior y es evidentemente una necesidad perentoria.


Vale, quizas el planteamiento de mis dudas no lo decia todo, pero tu has tocado precisamente la parte que queria tratar.

Osea, dos cosas. Esta el archivo que contiene vocabulario de sinonimos, que supongo que es el que dices que es completamente necesario (subir=aupar=sube=suba) que para otros contextos seria (subir=ir arriba). Y estaria el archivo que define los verbos y sus estructuras sintacticas (el pseudo codigo en Inform que muestras).

Para el primero se necesita un archivo para definirlo, y accesible para el autor de aventuras.
Para el segundo, estaria la opcion de una gramatica definida o bien crear "patrones" como el pseudo-codigo que muestras.

Lo que estoy entendiendo es que en AGE se define bajo los mismos patrones para todos los verbos:

[verbo] + [obj1]
[verbo] + [obj1] + [obj2]

y en Inform bajo la pseudo-gramatica (intento imitar tu ejemplo de Inform) que se define para cada verbo.

[resultado1] ::= [verbo] + [preposicion1] + [tipo_obj1]
[resultado2] ::= [verbo] + [preposicion1] + [tipo_obj2]
[resultado3] ::= [verbo] + [preposicion2] + [obj1]
[resultado4] ::= [verbo] + [obj1] + [preposicion2] + [obj2]
[resultado5] ::= [verbo] + [preposicion1] + [obj1]

Viendolo asi, resulta hasta mas facil. Un parser crea el patron para crear verbos.
Implementa los suyos basicos bajo ese patron, y deja accesible el patron para los autores, para que incorporen todo lo que quieran.

Realmente no es crear una gramatica para analizar el arbol sintactico que devuelve la entrada del usuario. Solo es comparar que la entrada del usuario coincide con alguno de los patrones definidos de cada verbo.

Concluyo pues que no hace falta una gramatica completa para tratar cualquier frase que el jugador pueda introducir, sino una pseudo-gramatica y comparar la cadena que introduce el jugador.

Vamos, que si lo que estoy interpretando es correcto, habria que descartar crear una gramatica completa y potente. Hay que dejar que cada autor implemente la suya propia para cada verbo nuevo que quiera incorporar.


Arriba
 Perfil  
 
NotaPublicado: 01 Abr 2011 13:40 
Desconectado
Betatester
Betatester
Avatar de Usuario

Registrado: 24 Dic 2010 14:37
Mensajes: 937
Así es no es 'necesario', porque en realidad nos 'apañamos' con los patrones a día de hoy. Lo cual no quita que me encantaría disponer de un parser en la que os patrones en lugar de escribirse así:

Understand "subir en [a supporter]" as going on.

Que sólo entiende:

>> subir en la carretilla azul

como:

<going on carretilla azul>

Pudiese escribirse como:

Understand "verb-subir comp-en [a supporter]" as going on.

Y fuese capaz de entenderme:

>> subir en la carretilla que está junto al porche

como:

<going on carretilla azul>

pero no porque sus nombre son 'carretilla' y 'azul', sino porque es una carretilla y su localización es cercana al porche.

Eso me encantaría, sobre todo porque facilitaría mucho la interacción compleja con PNJ en esta manera:

>> decirle a pedro que vaya al norte y le pida a juan que le de el libro que tiene en su maletín

Algo que actualmente es completamente impensable, incluso en frases mucho más sencillas de la que he usado de ejemplo.


Arriba
 Perfil  
 
NotaPublicado: 01 Abr 2011 14:01 
Desconectado
Yiepp
Yiepp

Registrado: 01 Mar 2011 20:20
Mensajes: 77
Johan Paz escribió:
Eso me encantaría, sobre todo porque facilitaría mucho la interacción compleja con PNJ en esta manera:

>> decirle a pedro que vaya al norte y le pida a juan que le de el libro que tiene en su maletín

Algo que actualmente es completamente impensable, incluso en frases mucho más sencillas de la que he usado de ejemplo.


hombre, a pesar de que seria un mounstro de parser el que reconociera eso xD
ahi ya entraria en juego de verdad un arbol sintactico de la entrada del usuario porque no dejan de ser tres frases en una. osea, tres resultados en uno: decirle algo a un PSI, que un PSI se traslade de localidad, que un PSI le de un objeto a otro PSI. Y todo sin que el jugador se mueva de su sitio.

El libro no es 'libro azul', sino 'libro' que tiene por caracteristicas 'estar en inventario de Juan'. Podria haber dos libros en el norte, por ejemplo.
No seria facil, la verdad, analizar esa entrada por patrones jeje. Aunque a nivel de funcionalidad del sistema, es practico, aunque laborioso.
Aqui si que creo que hace falta el arbol sintactico que comentaba Al-Khwarizmi al principio.

Este dividiria esa frase en las tres acciones diferentes. Y el sistema recibiria tres ordenes, y las compararia con sus patrones. Asique ¿puede que falte un subsistema intermedio mas bien no?

(nota mental) que dificil es llegar a una conclusion xD


Arriba
 Perfil  
 
NotaPublicado: 01 Abr 2011 15:54 
Desconectado
Samudio
Samudio
Avatar de Usuario

Registrado: 09 Mar 2004 16:16
Mensajes: 5312
Ubicación: Coruña
Johan Paz escribió:
El problema es que en AGE (y en PAWS-likers) hay un salto directo entre el comando y la interacción/respuesta, sin que haya un mediador en forma de 'acción' como en Inform. Eso limita las cosas que se pueden codificar de forma genérica

¿Por ejemplo, qué cosa se puede codificar de forma genérica en Inform y no en AGE? Yo nunca me he encontrado nada que no se pueda hacer. ¿No será simplemente que te gusta más el azúcar sintáctico de Inform que el de AGE?

Johan Paz escribió:
(de hecho para mi la situación en AGE es peor que en PAWS-likers ya que al menos en PAWS-likers entre el comando y la respuesta 'media' el vocabulario y el parseador genérico de forma 'obligada', lo que homogeneiza para el programador la situación, logrando que la secuencia de palabras reconocidas funcionen a modo de 'acción' -aunque de forma imcompleta y algo deficiente, véase el código extra en la librería base de Superglus para crear 'acciones sinónimas', que constituyen en realidad una auténtica gramática al estilo Inform- mientras que en AGE el vocabulario es sólo un medidador opcional, lo que a mi me parece muy problemático).

Opcionalidad -> más libertad para el autor, más formas de hacer las cosas -> bueno.

En Inform se llega a la situación extrema de que uno está programando un juego que toma como entrada strings y produce como salida strings, y el sistema se toma toda clase de molestias para que el usuario no pueda acceder a esos strings o manipularlos (al menos así es hasta I6, espero que con I7 haya mejorado algo).

Tal vez ese nivel de abstracción esté muy bien para ciertos tipos de usuarios; pero AGE es un sistema pensado para programadores, que necesitan tener control sobre lo que hace su aventura. Para otro tipo de usuarios, hay otros sistemas, como sabes yo no soy defensor de que uno deba desbancar a otros sino de que cada uno tendrá su base de usuarios.

Citar:
Como se ve en todos estos ejemplos de Jenesis se está confundiendo la 'respuesta' con la 'acción'. Algo lógico debido a que es usuario de AGE en la que esta confusión es una decisión de diseño de la herramienta. En una aproximación de tipo Inform es la gramática la que separaría de forma contextual estos diversos comandos sintácticamente homomorfos en acciones semánticamente muy diferentes. Y esta gramática es pefectamente lógica a nivel global y no residente en el objeto.

Escribo seudo-código porque no tengo el I7 aquí para compilar y verificar:

Código:
     Understand "subir -/a/por [a stairdoor]" as going through.
     Understand "subir -/a/por/en [a supporter]" as going on.
     Understand "subir -/a/en [a vehicle]" as going in.
     ...etc...
     Understand "subir [a thing] a/en [a supporter]" as putting it on.
     ...etc...
     Understand "subir -/a/por [a thing]" as fail('¡Eso no tiene sentido').


Creo, sinceramente, que esta situación es considerablemente más sencilla.

Más sencilla o no, es subjetivo. Pero lo que es objetivo es que con una aproximación en la que la gramática se define necesariamente de forma global, no puedes coger una escalera de una aventura, llevártela a otra y que funcione. Dependes de esa gramática global. Creas mucha más cohesión entre las diferentes partes de una aventura.

Por otra parte, esto es parsing estricto. Si escriben "subir encima de la silla", ya no va, a no ser que añadas otra regla para esa variante. Si quieres tener una cobertura decente, tienes que añadir un montón de reglas. Los novatos que prueban aventuras en AGE y en otros sistemas suelen concordar en que las de AGE son mucho más fáciles de usar porque responden mejor a las órdenes que teclean.

_________________
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: 01 Abr 2011 15:57 
Desconectado
Samudio
Samudio
Avatar de Usuario

Registrado: 09 Mar 2004 16:16
Mensajes: 5312
Ubicación: Coruña
kalel099 escribió:
(nota mental) que dificil es llegar a una conclusion xD

Es que no hay por qué llegar a una conclusión. Igual que hay diferentes formas de diseñar y programar software y por eso existen diferentes lenguajes de programación, y a nadie se le pasaría por la cabeza decir que deberían reducirse a uno y que lo usara todo el mundo; también existen distintas formas de diseñar y programar una aventura, y por eso puede y debe existir una variedad de sistemas con diferentes diseños.

_________________
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: 01 Abr 2011 20:16 
Desconectado
Betatester
Betatester
Avatar de Usuario

Registrado: 24 Dic 2010 14:37
Mensajes: 937
Al-K ya te lo he explicado un buen montón de veces y no me entiendes, volverlo a explicar no llevaría a nada. ¿Lo has intentado? Haz una aventura en I7, pruébalo, uno que tenga complejidad de parseado por contexto. Ponlo a prueba y luego ya me dices. Yo sí que lo he intentado con AGE y me ha parecido un dolor.


Arriba
 Perfil  
 
NotaPublicado: 01 Abr 2011 21:38 
Desconectado
Samudio
Samudio
Avatar de Usuario

Registrado: 09 Mar 2004 16:16
Mensajes: 5312
Ubicación: Coruña
Johan Paz escribió:
Al-K ya te lo he explicado un buen montón de veces y no me entiendes, volverlo a explicar no llevaría a nada. ¿Lo has intentado? Haz una aventura en I7, pruébalo, uno que tenga complejidad de parseado por contexto. Ponlo a prueba y luego ya me dices. Yo sí que lo he intentado con AGE y me ha parecido un dolor.

Yo soy el primero que está cansado de este tipo de discusiones, y ya hace muchos años que no las comienzo. Pero comprenderás que si se hacen unas críticas a mi sistema con las que no estoy en absoluto de acuerdo, llegando a compararlo desfavorablemente con sistemas de la época de los ocho bits, no me voy a quedar sin decir nada. Podría suceder que alguien que no conoce los sistemas llegara al hilo y se quedara con tus opiniones que, si bien respetables, están absolutamente sesgadas, así que me veo obligado a intervenir.

Deberías plantearte que tal vez si alguien no te da la razón sea porque simplemente opina de manera distinta. Yo probé en su momento I7, y sinceramente me pareció una idea muy bonita para no programadores que no se atrevan con un lenguaje tradicional; pero inmantenible para proyectos grandes por lo desestructurado que es, como buen lenguaje basado en reglas. Sobre el parsing contextual, sí, lógicamente se puede hacer, como también se puede hacer en AGE (y a mí no me parece ningún dolor, me parece más dolor en I7 donde sólo puedo hacer parsing estricto -¿parsing estricto? Estamos en 2011- a no ser que prevea las cincuenta formas en las que un jugador puede teclear cada cosa... y donde la gramática es una cosa global que me dificulta llevarme objetos de una aventura a otra, cosa que en AGE puedo hacer y hago todo el rato con total facilidad).

Pero ya digo, para gustos colores. Yo respeto la opinión de los que preferís I7. Respetad vosotros la mía.

_________________
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: 01 Abr 2011 22:59 
Desconectado
Implementador
Implementador

Registrado: 09 Jun 2010 14:50
Mensajes: 1677
Ubicación: Argentina
Claro Al-K, creo que tú te has llevado la decepción de I 7 que parece ser más cerrado que su predecesor I 6. Yo creo que I 6 te gustaría mucho más pues se tiene más control sobre lo que hace la aventura al no ser un lenguaje recubierto, además de que puedes revisar directamente los ficheros de la librería para modificarlos a tu antojo ya sea directamente o reemplazando partes de los mismos en el código de tu aventura.
Y no estoy de acuerdo con que no puedes llevar con Inform un objeto de una aventura otra. ¿Acaso no hay autores como Jarel que suelen pegar código entre distintas aventuras para no tener que reinventar la rueda? Soy conciente de que no es tan directo como en AGE que las acciones están integradas en los objetos, pero al menos en I 6 (no sé qué tan fácil será en I 7) puedes editar los ficheros .h que manejen lo que quieras tener editado y listo, te sirve para cualquier aventura. Destacar también que los códigos que se utilizan en Inform para la definición de acciones y bervos también se pueden pegar, e incluso en I 7 lo veo más fácil que en I 6 porque para eso las oraciones son realmente prácticas.


Al-Khwarizmi escribió:
Johan Paz escribió:
Al-K ya te lo he explicado un buen montón de veces y no me entiendes, volverlo a explicar no llevaría a nada. ¿Lo has intentado? Haz una aventura en I7, pruébalo, uno que tenga complejidad de parseado por contexto. Ponlo a prueba y luego ya me dices. Yo sí que lo he intentado con AGE y me ha parecido un dolor.

Yo soy el primero que está cansado de este tipo de discusiones, y ya hace muchos años que no las comienzo. Pero comprenderás que si se hacen unas críticas a mi sistema con las que no estoy en absoluto de acuerdo, llegando a compararlo desfavorablemente con sistemas de la época de los ocho bits, no me voy a quedar sin decir nada. Podría suceder que alguien que no conoce los sistemas llegara al hilo y se quedara con tus opiniones que, si bien respetables, están absolutamente sesgadas, así que me veo obligado a intervenir.

Deberías plantearte que tal vez si alguien no te da la razón sea porque simplemente opina de manera distinta. Yo probé en su momento I7, y sinceramente me pareció una idea muy bonita para no programadores que no se atrevan con un lenguaje tradicional; pero inmantenible para proyectos grandes por lo desestructurado que es, como buen lenguaje basado en reglas. Sobre el parsing contextual, sí, lógicamente se puede hacer, como también se puede hacer en AGE (y a mí no me parece ningún dolor, me parece más dolor en I7 donde sólo puedo hacer parsing estricto -¿parsing estricto? Estamos en 2011- a no ser que prevea las cincuenta formas en las que un jugador puede teclear cada cosa... y donde la gramática es una cosa global que me dificulta llevarme objetos de una aventura a otra, cosa que en AGE puedo hacer y hago todo el rato con total facilidad).

Pero ya digo, para gustos colores. Yo respeto la opinión de los que preferís I7. Respetad vosotros la mía.


Arriba
 Perfil  
 
NotaPublicado: 02 Abr 2011 01:00 
Desconectado
Betatester
Betatester
Avatar de Usuario

Registrado: 24 Dic 2010 14:37
Mensajes: 937
Oca, pues te contesto punto por punto entonces, ya que te lo tomas así. :)

Al-Khwarizmi escribió:
Johan Paz escribió:
El problema es que en AGE (y en PAWS-likers) hay un salto directo entre el comando y la interacción/respuesta, sin que haya un mediador en forma de 'acción' como en Inform. Eso limita las cosas que se pueden codificar de forma genérica

¿Por ejemplo, qué cosa se puede codificar de forma genérica en Inform y no en AGE? Yo nunca me he encontrado nada que no se pueda hacer. ¿No será simplemente que te gusta más el azúcar sintáctico de Inform que el de AGE?


Como ya he puesto antes el primer paso en I7 es definir las gramáticas que no te gustan a nivel 'global'. Los understand tienen dos capacidades contextuales:

  • En el patrón puedes restringir la aplicabilidad a un tipo de objeto, que puedes determinar mediante una jerarquía de objetos o mediante 'adjetivos', que son calificadores de objetos, o si quieres clasificadores -no me refiero a palabras que sean adjetivo. En AGE puedes poner código (y tiene que ser código necesariamente) en dos lugares básicamente en el 'mundo' o en cada objeto. Dado que puedes crear los objetos en jerarquías una de las partes está disponible, pero al no tener una forma de crear 'adjetivos' de forma global las maneras que se me ocurren de tener una funcionalidad equivalente son: poner un atributo por cada adjetivo -pero habría que activarlos uno a uno en cada objeto y es muy incómodo-, poner en todos los objetos un método que evalúe el adjetivo, el problema en este caso es que el método tendría que estar en lo alto de la jerarquía y en general en todos los objetos. Estos métodos habría que invocarlos en el parseCommand adecuado, de nuevo tienes el problema de determinar en qué nivel de la jerarquía tendrías que hacerlo, así que o replicas el código en varios o muchos puntos o estás restringido a lo que hayas diseñado desde el principio (este es el primer que veo una limitación en AGE para programar algunas cosas de forma genérica -entendido como la capacidad de ajustar según vayas necesitando el comportamiento de la aventura sin tener que refactorizarlo todo- )
  • Después del patrón puedes poner una cláusula 'when' que determina si el patrón se debe considerar o no según la circunstancia, esto permite ajusta de manera cómoda qué partes de la gramática se van a considerar o no. Por lo que sé en AGE la única forma de hacer eso es de nuevo crear código en el parseCommand adecuado a lo largo de la jerarquía, por lo que tienes el mismo problema que antes.

Al-Khwarizmi escribió:
Johan Paz escribió:
(de hecho para mi la situación en AGE es peor que en PAWS-likers ya que al menos en PAWS-likers entre el comando y la respuesta 'media' el vocabulario y el parseador genérico de forma 'obligada', lo que homogeneiza para el programador la situación, logrando que la secuencia de palabras reconocidas funcionen a modo de 'acción' -aunque de forma imcompleta y algo deficiente, véase el código extra en la librería base de Superglus para crear 'acciones sinónimas', que constituyen en realidad una auténtica gramática al estilo Inform- mientras que en AGE el vocabulario es sólo un medidador opcional, lo que a mi me parece muy problemático).

Opcionalidad -> más libertad para el autor, más formas de hacer las cosas -> bueno.


No sé, creo que no has entendido mi párrafo. Yo lo que estoy diciendo es que el creador de la aventura en AGE, por lo que recuerdo tiene dos forma de establecer 'gramáticas': el fichero de sinónimos -que tan sólo te permite poner palabras sinónimas, ¿no?- y los parseCommands. Para simplificar el trabajo cuantas más alternativas de comandos estén cubiertas por el mismo código mejor. La libertad que dices de AGE obliga a codificar cada combinación de palabras de comando que quieras considerar para asociar al mismo 'comportamiento' no ya una por una, sino potencialmente muchas veces el mismo si la jerarquía de herencia de objetos (la que sea) no es la adecuada para heredar la asociación entre palabras y comportamiento. Eso es lo que me parece muy problemático. En este caso la libertad del autor (que sinceramente consiste básicamente en la capacidad de tratar las cadenas como quieras y eso raramente se usa) complica el trabajo 'habitual' de poner expresiones equivalentes para ofrecer demasiado poco a cambio.

Al-Khwarizmi escribió:
En Inform se llega a la situación extrema de que uno está programando un juego que toma como entrada strings y produce como salida strings, y el sistema se toma toda clase de molestias para que el usuario no pueda acceder a esos strings o manipularlos (al menos así es hasta I6, espero que con I7 haya mejorado algo).



En I7 está completamente 'corregido', tienes indexed strings, regex para detección, sustitución, etc... vamos, no creo que eches en falta nada referente a cadenas, pero en cualquier caso, ¿qué más da? ¿Qué quieres hacer con las cadenas exactamente? El tratamiento de cadenas es algo de demasiado bajo nivel para todo esto que tenemos entre manos. Y en el fondo es el mismo problema que me separa de AGE en otr[/quote]os muchos aspectos, todo es de demasiado bajo nivel cuando estamos tratando de un género que necesita alto nivel, y cuanto más mejor. Necesitas texto variable, no manejar cadenas. Necesitas patrones contextuales de parseado, no pelearte con comparaciones del input del jugador con expresiones regulares o cascadas de condificionale de comparaciones con 'palabras sueltas'.

Al-Khwarizmi escribió:
Tal vez ese nivel de abstracción esté muy bien para ciertos tipos de usuarios; pero AGE es un sistema pensado para programadores, que necesitan tener control sobre lo que hace su aventura. Para otro tipo de usuarios, hay otros sistemas, como sabes yo no soy defensor de que uno deba desbancar a otros sino de que cada uno tendrá su base de usuarios.


¿Por qué creer que el control está siempre reñido con el nivel de abstracción? No tienen porque tener que ver una cosa con la otra, si la abstracción es la correcta el trabajo será menor y el control será todo el necesario. Por lo tanto creo que lo verdaderamente importante es hablar sobre qué abstracción es la adecuada y cuál resulta un problema, y de la misma manera sobre cuál es el control necesario y cuál el que provoca trabajo adicional. De hecho lo ideal es que en la mayor parte de los casos 'habituales' la abstracción simplifique el trabajo a lo mínimo posible, a casi nada, mientras que para los casos especiales la flexibilidad del sistema permita hacer todo lo que sea necesario.

Un ejemplo de cosa que me parece poco útil (y que por lo tanto debe ser casi gratis en cuanto al trabajo extra que añada por existir) es eso que mencionas muchas veces de 'llevar una este objeto' a otra obra. Yo nunca he visto eso. Usar una librería de líquidos, de sonidos o de lo que sea sí. O de gráficos y otra multimedia. O formateadores de respuestas. Todo eso sí. Pero el contenido del mundo aún no la he visto reutilizar de una aventura a otra. ¡Y es lógico! Toda la experiencia tiene que ser 'coherente', debe ser fluida y tener toda ella el mismo tono. Si coges un objeto de una aventura espacial, digamos una caja, y te la llevas con su tratamiento de input y sus respuestas ¡no va a encajar en una aventura medieval! ¡Es casi imposible! Exactamente le he dicho a 'ddddd' para su pyphi y sus 'universos'. Que sí que son chulos, pero ¡no creo que realmente se pueda reaprovechar gran cosa de una obra a otra! Y eso es así porque en este género lo importante en las respuestas es lo 'particular', la 'excepción', no lo general.

Al-Khwarizmi escribió:
Citar:
Como se ve en todos estos ejemplos de Jenesis se está confundiendo la 'respuesta' con la 'acción'. Algo lógico debido a que es usuario de AGE en la que esta confusión es una decisión de diseño de la herramienta. En una aproximación de tipo Inform es la gramática la que separaría de forma contextual estos diversos comandos sintácticamente homomorfos en acciones semánticamente muy diferentes. Y esta gramática es pefectamente lógica a nivel global y no residente en el objeto.

Escribo seudo-código porque no tengo el I7 aquí para compilar y verificar:

Código:
     Understand "subir -/a/por [a stairdoor]" as going through.
     Understand "subir -/a/por/en [a supporter]" as going on.
     Understand "subir -/a/en [a vehicle]" as going in.
     ...etc...
     Understand "subir [a thing] a/en [a supporter]" as putting it on.
     ...etc...
     Understand "subir -/a/por [a thing]" as fail('¡Eso no tiene sentido').


Creo, sinceramente, que esta situación es considerablemente más sencilla.


Más sencilla o no, es subjetivo. Pero lo que es objetivo es que con una aproximación en la que la gramática se define necesariamente de forma global, no puedes coger una escalera de una aventura, llevártela a otra y que funcione. Dependes de esa gramática global. Creas mucha más cohesión entre las diferentes partes de una aventura.

Por otra parte, esto es parsing estricto. Si escriben "subir encima de la silla", ya no va, a no ser que añadas otra regla para esa variante. Si quieres tener una cobertura decente, tienes que añadir un montón de reglas. Los novatos que prueban aventuras en AGE y en otros sistemas suelen concordar en que las de AGE son mucho más fáciles de usar porque responden mejor a las órdenes que teclean.


A ver, que es parser estricto no te lo puedo negar, pero no es tan difícil como lo pintas ni de lejos, realmente te animo a volver a probar I7 de nuevo porque es muchísimo más fácil proporcionar alternativas de lo que estás sugiriendo y cubrir todo lo que la obra 'pide', y no tienes que añadir 'un montón de reglas', de hecho si comparas ejemplos de código tienes mucho más código en cualquiera de los listados de AGE para estos temas de parseado que en los de I7 y no lo digo por decir, sino porque me preocupado de ir comparando las diversas aventuras de AGE que han ido saliendo.

Supongo que con novatos te refieres a gente que nunca se ha enfrentado a ninguna de estas y que escribe 'cualquier cosa'. Pero el parser no estricto no es la única parte necesaria, los sinónimos de frases es aún más importante. Y qué quieres que te diga, aún estoy por encontrar una aventura de AGE que en algún momento no se me quede sorda. La mejor hasta ahora ha sido la de Jenesis e incluso en ella a veces sufre bastante del síndrome de 'no entiendo', algo sorprendente para un sistema basado en parser no-estricto, y, qué quieres que te diga, no puedo dejar de pensar que el hecho de tener que verificar el input del jugador mediante una secuencia larga de condicionales y de forma distribuida en todos esos objetos es tanto trabajo que el trabajo se queda imcompleto (y por lo tanto la obra sorda a ratos).

Pero para mi, lo peor es que debido precisamente a este parseado asociado al objeto que hay que hacer en diversos momentos de la creación de la obra, la capacidad de 'comprensión' de la misma no es coherente a lo largo de la experiencia, sino que depende mucho de la parte en la que estás, los objetos con los que interactúas. Un usuario bienintencionado irá aprendiendo mediante prueba y error qué es lo que entiende una obra dada y se adaptará, pero si el nivel de comprensión no es estable a lo largo de la obra no sabrá a qué atenerse.

Esos son los problemas que le veo a AGE y su sistema de parseado, pero sinceramente estoy convencido de que te los he contado ya en varias ocasiones.


Arriba
 Perfil  
 
NotaPublicado: 02 Abr 2011 10:21 
Desconectado
Samudio
Samudio
Avatar de Usuario

Registrado: 09 Mar 2004 16:16
Mensajes: 5312
Ubicación: Coruña
Johan Paz escribió:
[*] En el patrón puedes restringir la aplicabilidad a un tipo de objeto, que puedes determinar mediante una jerarquía de objetos o mediante 'adjetivos', que son calificadores de objetos, o si quieres clasificadores -no me refiero a palabras que sean adjetivo. En AGE puedes poner código (y tiene que ser código necesariamente) en dos lugares básicamente en el 'mundo' o en cada objeto. Dado que puedes crear los objetos en jerarquías una de las partes está disponible, pero al no tener una forma de crear 'adjetivos' de forma global las maneras que se me ocurren de tener una funcionalidad equivalente son: poner un atributo por cada adjetivo -pero habría que activarlos uno a uno en cada objeto y es muy incómodo-, poner en todos los objetos un método que evalúe el adjetivo, el problema en este caso es que el método tendría que estar en lo alto de la jerarquía y en general en todos los objetos. Estos métodos habría que invocarlos en el parseCommand adecuado, de nuevo tienes el problema de determinar en qué nivel de la jerarquía tendrías que hacerlo, así que o replicas el código en varios o muchos puntos o estás restringido a lo que hayas diseñado desde el principio (este es el primer que veo una limitación en AGE para programar algunas cosas de forma genérica -entendido como la capacidad de ajustar según vayas necesitando el comportamiento de la aventura sin tener que refactorizarlo todo- )

Es que las propiedades de AGE hacen exactamente la misma función que eso que llamas adjetivos. Puedes poner un código en el parseCommand que sólo se ejecute si un objeto es sólido, inflamable y blando. Sí, para comprobar eso tienes que usar un if, "código necesariamente". ¿Cuál es el problema? Como digo, AGE es un sistema para programadores, no está pensado para gente a la que el que haya "código" le parezca un inconveniente. Eso sí, código organizado de una forma cómoda. Porque no, no hay que replicar código en ninguna parte. Si lo has hecho de forma que haya que replicar código, es que lo estás haciendo mal.

Johan Paz escribió:
[*] Después del patrón puedes poner una cláusula 'when' que determina si el patrón se debe considerar o no según la circunstancia, esto permite ajusta de manera cómoda qué partes de la gramática se van a considerar o no. Por lo que sé en AGE la única forma de hacer eso es de nuevo crear código en el parseCommand adecuado a lo largo de la jerarquía, por lo que tienes el mismo problema que antes.[/list]

En AGE si quieres que un código en un televisor se ejecute sólo si el televisor está encendido, pondrás if ( get(self,"encendido") ) ... Y si le has dado a tu aventura un diseño decente, el parseCommand donde tengas que poner eso será obvio. Estás diciendo que son problemas cosas que no son problemas en absoluto. Si estás usando un framework orientado a objetos y tienes un diseño donde no sabes en qué objeto has metido cada cosa, creo que el problema lo tienes tú, no el framework.

Johan Paz escribió:
No sé, creo que no has entendido mi párrafo. Yo lo que estoy diciendo es que el creador de la aventura en AGE, por lo que recuerdo tiene dos forma de establecer 'gramáticas': el fichero de sinónimos -que tan sólo te permite poner palabras sinónimas, ¿no?- y los parseCommands. Para simplificar el trabajo cuantas más alternativas de comandos estén cubiertas por el mismo código mejor. La libertad que dices de AGE obliga a codificar cada combinación de palabras de comando que quieras considerar para asociar al mismo 'comportamiento' no ya una por una, sino potencialmente muchas veces el mismo si la jerarquía de herencia de objetos (la que sea) no es la adecuada para heredar la asociación entre palabras y comportamiento. Eso es lo que me parece muy problemático. En este caso la libertad del autor (que sinceramente consiste básicamente en la capacidad de tratar las cadenas como quieras y eso raramente se usa) complica el trabajo 'habitual' de poner expresiones equivalentes para ofrecer demasiado poco a cambio.

En primer lugar, los sinónimos habituales del español ya vienen dados por defecto (aunque puedes desactivarlos si quieres). Por defecto, si capturas el verbo "coger" para un objeto, estás capturando a la vez el verbo "tomar", así como sus formas verbales "cojo", "tomo", "toma", "coge", etc. Para otros verbos que siempre son sinónimos en español, igual.

Si quieres que un comportamiento sea accesible mediante varios verbos (por ejemplo que "pulsar interruptor" sea lo mismo que "activar interruptor"), en donde lo defines harás un or entre "pulsar" y "activar".

Si hay varios objetos que se pulsen o activen, tienes la opción de definir ese comportamiento en cada objeto (en cuyo caso tienes la ventaja de que los objetos son más fácilmente portables entre una aventura y otra, pero el inconveniente que dices tú de que hay que repetir ese if - que, la verdad, tampoco me parece tanto trauma, pero bueno) o bien tienes la opción de definir ese comportamiento en el mundo y poner el chequeo sólo una vez. En este último caso, estarías exactamente en la misma situación que I7: tendrías el patrón definido sólo una vez en tu aventura; aunque a cambio los objetos no se pulsarán si te los llevas a otra aventura sin copiar ese código.

En realidad si cogieras AGE y solamente usaras los parseCommands del mundo, sin usar nunca los de los objetos, tendrías una organización del código equivalente a la de I7, que al fin y al cabo es un sistema sin estructura, donde todas las reglas están en principio universalmente cuantificadas (tienen ámbito global). Yo personalmente prefiero usar los parseCommand del mundo o los de los objetos según la situación, sopesando las ventajas e inconvenientes que dije antes. Por ejemplo si quiero que muchos objetos del mundo se pueden quemar y todos reaccionen exactamente igual, seguramente pondré ese código en el mundo. Pero si un objeto captura un verbo que es específico de él (por ejemplo un libro se lee, y lo que sucede al leer el libro es específico de ese libro; aunque pase el "leer" al mundo no voy a evitarme poner ese código) lo pondré en el objeto. En I7 simplemente tienes un sistema menos flexible que sólo admite la primera opción, no admite la segunda.

Johan Paz escribió:
En I7 está completamente 'corregido', tienes indexed strings, regex para detección, sustitución, etc... vamos, no creo que eches en falta nada referente a cadenas, pero en cualquier caso, ¿qué más da? ¿Qué quieres hacer con las cadenas exactamente? El tratamiento de cadenas es algo de demasiado bajo nivel para todo esto que tenemos entre manos. Y en el fondo es el mismo problema que me separa de AGE en otros muchos aspectos, todo es de demasiado bajo nivel cuando estamos tratando de un género que necesita alto nivel, y cuanto más mejor. Necesitas texto variable, no manejar cadenas. Necesitas patrones contextuales de parseado, no pelearte con comparaciones del input del jugador con expresiones regulares o cascadas de condificionale de comparaciones con 'palabras sueltas'.

Me alegra de que I7 te deje manipular la cadena, eso es un avance.

Lo de que "qué más da" me suena como los usuarios de iPhone que dicen que para qué quieren USB, y para qué quieren multitasking (aunque luego Steve Jobs anuncia el multitasking en una keynote y dicen todos que eso era justo lo que necesitaban :D) ¿De verdad te parece que para programar algo que toma como entrada cadenas y produce como salida cadenas no es útil poder acceder a la cadena? Yo no digo que haya que estar haciéndolo todo el tiempo, tal vez en una aventura sencilla no lo hagas nunca; pero por supuesto que es útil y es un crimen no soportarlo.

Muestra de que es necesario es la enorme truculencia que tuvo que hacer jarel para implementar su sistema de conversación en I6: http://informatetu.blogspot.com/2008/10 ... cente.html - y sí, ya sé que en tu comentario le dabas una opción algo menos horrible; pero no dejaba de ser de todos modos un complicado workaround para paliar el hecho de que el sistema no da acceso a lo que debería darlo: la cadena.

Ya no hablemos de hacer aventuras que jueguen con las características de la cadena de entrada, tipo Ad Verbum, etc.


Al-Khwarizmi escribió:
¿Por qué creer que el control está siempre reñido con el nivel de abstracción? No tienen porque tener que ver una cosa con la otra, si la abstracción es la correcta el trabajo será menor y el control será todo el necesario. Por lo tanto creo que lo verdaderamente importante es hablar sobre qué abstracción es la adecuada y cuál resulta un problema, y de la misma manera sobre cuál es el control necesario y cuál el que provoca trabajo adicional. De hecho lo ideal es que en la mayor parte de los casos 'habituales' la abstracción simplifique el trabajo a lo mínimo posible, a casi nada, mientras que para los casos especiales la flexibilidad del sistema permita hacer todo lo que sea necesario.

Un ejemplo de cosa que me parece poco útil (y que por lo tanto debe ser casi gratis en cuanto al trabajo extra que añada por existir) es eso que mencionas muchas veces de 'llevar una este objeto' a otra obra. Yo nunca he visto eso. Usar una librería de líquidos, de sonidos o de lo que sea sí. O de gráficos y otra multimedia. O formateadores de respuestas. Todo eso sí. Pero el contenido del mundo aún no la he visto reutilizar de una aventura a otra. ¡Y es lógico! Toda la experiencia tiene que ser 'coherente', debe ser fluida y tener toda ella el mismo tono. Si coges un objeto de una aventura espacial, digamos una caja, y te la llevas con su tratamiento de input y sus respuestas ¡no va a encajar en una aventura medieval! ¡Es casi imposible! Exactamente le he dicho a 'ddddd' para su pyphi y sus 'universos'. Que sí que son chulos, pero ¡no creo que realmente se pueda reaprovechar gran cosa de una obra a otra! Y eso es así porque en este género lo importante en las respuestas es lo 'particular', la 'excepción', no lo general.

"A quien tiene un martillo, todos los problemas le parecen clavos".

Tú no habrás visto eso nunca; pero yo lo hago todo el tiempo. En "Fuego" copié objetos de "Los Inmortales". En "Morluck", buena parte de los objetos que hay (incluyendo parte de las armas, los enemigos y los conjuros) fueron copypasteados tal cual de un proyecto de gran aventura inconclusa que tengo, sin necesidad de cambiar ni una coma del código. Según vaya haciendo aventuras, iré reutilizando más coas.

Obviamente no voy a coger un objeto de una aventura espacial y ponerlo en una medieval tal cual. No digo que el tema de copiar y pegar objetos se pueda aplicar absolutamente siempre y que nunca haya que programarse un nuevo objeto. Pero que se puede hacer muchas veces, sí, por supuesto.

Si no le ves la utilidad es porque te has adaptado al sistema que usas, que implica una cierta forma de enfocar el proceso de diseño. Igual que yo me he adaptado al mío.


Johan Paz escribió:
A ver, que es parser estricto no te lo puedo negar, pero no es tan difícil como lo pintas ni de lejos, realmente te animo a volver a probar I7 de nuevo porque es muchísimo más fácil proporcionar alternativas de lo que estás sugiriendo y cubrir todo lo que la obra 'pide', y no tienes que añadir 'un montón de reglas', de hecho si comparas ejemplos de código tienes mucho más código en cualquiera de los listados de AGE para estos temas de parseado que en los de I7 y no lo digo por decir, sino porque me preocupado de ir comparando las diversas aventuras de AGE que han ido saliendo.

Porque la mayoría de las aventuras en Inform son sordas profundas. En cuanto les pones una cosa que no se ajusta exactamente a lo que esperan, empiezan a decir cosas raras.

Por ejemplo, en viewtopic.php?f=9&t=4641 una novata se quejaba de que una aventura en Inform (en I6, pero para el caso es lo mismo) aceptaba "mirar dentro de la cesta" y no "mirar dentro cesta". Sí, sé que se podría haber puesto algo como "-/de -/la" o algo así. Pero la propia naturaleza del parsing estricto de Inform incita a cometer esos errores. En AGE es dificilísimo cometerlo, habría casi hasta que esforzarse para que el parser trague "mirar dentro de la cesta" y no "mirar dentro cesta".

Por eso las aventuras de Inform en la práctica son casi siempre inflexibles y al final hay que jugarlas como si uno estuviera trabajando con una terminal de comandos, más que con lenguaje natural.

Johan Paz escribió:
Supongo que con novatos te refieres a gente que nunca se ha enfrentado a ninguna de estas y que escribe 'cualquier cosa'. Pero el parser no estricto no es la única parte necesaria, los sinónimos de frases es aún más importante. Y qué quieres que te diga, aún estoy por encontrar una aventura de AGE que en algún momento no se me quede sorda. La mejor hasta ahora ha sido la de Jenesis e incluso en ella a veces sufre bastante del síndrome de 'no entiendo', algo sorprendente para un sistema basado en parser no-estricto, y, qué quieres que te diga, no puedo dejar de pensar que el hecho de tener que verificar el input del jugador mediante una secuencia larga de condicionales y de forma distribuida en todos esos objetos es tanto trabajo que el trabajo se queda imcompleto (y por lo tanto la obra sorda a ratos).

En su momento no pusiste ejemplos de en qué situaciones se quedaba sorda esa aventura. Supongo que sería simplemente tema de comportamientos no implementados por olvido, como puede suceder en cualquier aventura en cualquier sistema.

Johan Paz escribió:
Pero para mi, lo peor es que debido precisamente a este parseado asociado al objeto que hay que hacer en diversos momentos de la creación de la obra, la capacidad de 'comprensión' de la misma no es coherente a lo largo de la experiencia, sino que depende mucho de la parte en la que estás, los objetos con los que interactúas. Un usuario bienintencionado irá aprendiendo mediante prueba y error qué es lo que entiende una obra dada y se adaptará, pero si el nivel de comprensión no es estable a lo largo de la obra no sabrá a qué atenerse.

Si alguien define un objeto con comandos muy detallados y luego define otro objeto que es sordo como una tapia, ese alguien es un chapucero. AGE es un sistema para programadores, no para chapuceros.

Johan Paz escribió:
Esos son los problemas que le veo a AGE y su sistema de parseado, pero sinceramente estoy convencido de que te los he contado ya en varias ocasiones.

Sí, y yo te los he respondido en varias ocasiones; pero aquí cada cual ve lo que quiere ver. Yo me conformaría con que dejáramos a la gente juzgar por sí misma y no tener que andar gastando el tiempo en responder una y otra vez a las mismas cosas.

_________________
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: 02 Abr 2011 14:45 
Desconectado
Betatester
Betatester
Avatar de Usuario

Registrado: 24 Dic 2010 14:37
Mensajes: 937
:) De acuerdo, pero que conste que este hilo no va de comparar unos sistemas con otros y que no fui yo el que empezó diciendo qué era mejor o qué peor:

Citar:
Me parece bien que haya una lista de verbos, no tanto que haya una respuesta distinta para cada uno de ellos, porque eso uniformiza las aventuras y hace que todas parezcan escritas por la misma mano.

Por otro lado...
¿De qué sirve descorchar un auto?
¿De qué sirve pintar el agua?
¿De qué sirve beber un ladrillo?
Todos estos intentos de acción deberían tener una única respuesta.
"¿Estás loco?"

Por eso, yo prefiero asociar las acciones a los objetos y no al mundo en general.


Me limité a explicar porqué a mi me parece justamente lo contrario. Como ya dije cuando Jenesis publicó el artículo en el SPAC que decía exactamente lo mismo. Este hilo es en respuesta a una pregunta sobre gramáticas no es un hilo para intentar que la gente use un sistema u otro. Decir que es mejor que la gramática (Jenesis dice 'acciones', lo que es incorrecto desde mi punto de vista) debe estar en los objetos porque es absurdo 'pintar el agua', es algo completamente gratuito e incorrecto. Decir que la gramática debe estar en los objetos porque así puedes llevártelos de una obra a otra sí es correcta (discutible, porque no lo veo tan útil, pero correcta). Mis ejemplos de I7 y la comparativa con AGE sólo eran para demostrar que el que sea 'absurdo' pedir 'pintar el agua', no lleva ni de lejos a que la gramática esté asociada al objeto y mucho menos a obligar a que el salto desde el input del jugador hasta el código que cambia el estado del mundo tenga que estar todo junto, lo que me sigue pareciendo un problema.


Arriba
 Perfil  
 
NotaPublicado: 02 Abr 2011 14:54 
Desconectado
Implementador
Implementador

Registrado: 13 Feb 2005 18:57
Mensajes: 1955
Johan Paz escribió:
cuando Jenesis publicó el artículo en el SPAC

http://spac.caad.es/spip.php?article253


Arriba
 Perfil  
 
NotaPublicado: 02 Abr 2011 15:54 
Desconectado
Yiepp
Yiepp

Registrado: 01 Mar 2011 20:20
Mensajes: 77
Vaya! no pretendia abrir viejos debates. Sorry chicos

Me queda claro que cada uno tiene sus preferencias, y todo se basa en gustos, y lo que uno ve que es mejor con su experiencia. Crei que habria un consenso al respecto en plan "un parser tiene que usar esto asi y asa porque sino es inviable", pero ya veo que ambas posturas tienen sus pros y sus contras


Arriba
 Perfil  
 
NotaPublicado: 02 Abr 2011 22:51 
Desconectado
xyzzy

Registrado: 09 Mar 2004 22:50
Mensajes: 9150
kalel099 escribió:
jenesis escribió:
Me parece bien que haya una lista de verbos, no tanto que haya una respuesta distinta para cada uno de ellos, porque eso uniformiza las aventuras y hace que todas parezcan escritas por la misma mano.


Aqui me he perdido. Creia que eso era lo que se buscaba, que las respuestas fueran distintas para que el jugador se olvide que esta tratando con una maquina, no?. Es decir, si siempre obtienes la respuesta "¿como? ¿ ¿[ultima_frase_recibida_por_jugador]?" a mi me acaba estresando como jugador, porque es en plan "dios, que demonios tengo que poner".


A ver, con "respuestas distintas", me refiero a que un "parser" tenga un modelo de mundo (como es el caso de informATE), en que hay montones de verbos, que tienen una respuesta "diferente" en vez de generalizada.
Código:
>cantar
Cantas fatal.
>Dormir
No estás especialmente somnoliento

Con eso lo único que se consigue es que si el autor no se molesta en cambiarlo, al final se tengan una serie de aventuras que parecen escritas por la misma persona. A mí particularmente es algo que no me gusta y por eso digo que no es el parser, sino el autor el que ha de asignar esas respuestas. O sea, lista de verbos sí, lista de respuestas no.


Citar:
En cambio si el autor pone respuestas distintas para las maximas acciones, crea riqueza.
O seria exagerado?
En el juego "El libro que se aburria", he jugado al principio nada mas (pero pro falta tiempo no por falta de ganas ;) ) es una de las cosas que apreciaba, que me contestaba acorde con lo que ponia, y no el ¿que? no entiendo. Esto no es fruto del autor del juego?


Exactamente, lo que hice fue coger la lista de respuestas de informATE y cambiarlas en su mayoría.


Citar:
jenesis escribió:
Código:
>sube por la escalera.
Subes por la escalera a la planta de arriba.

>sube por la escalera.
Subes encima de la escalera.


En este caso queda claro que lo que quiere el jugador es subir por la escalera. Aún así en el primer objeto resulta obvio con o sin el "por", no así en el segundo. Luego la comprobación solo sería necesaria en la escalera pequeña.


Pero concretamente, para el caso de la escalera yo lo resolveria, haciendo que la primera fuera un PATH entre dos ROOMS (estilo AGE total) y la segunda escalera fuera un OBJETO que sea SUBIBLE. Y ya no habria ambiguedad entre ambos.


Bueno ten en cuenta que, subirte a una escalera de dos peldaños, puede ser un camino oculto a otra localidad, gemela a la anterior pero con una perspectiva y alcances diferentes.
Yo tengo la costumbre de usar dos localidades diferentes cuando el personaje se sube encima de algo lo suficientemente alto como para que desde ahí pueda ver cosas que no veía y coger cosas que estaban fuera de su alcance.

_________________
Si la mentira tuviera color, todos seríamos daltónicos...


Arriba
 Perfil  
 
Mostrar mensajes previos:  Ordenar por  
Nuevo tema Responder al tema  [ 65 mensajes ]  Ir a página Anterior  1, 2, 3, 4, 5  Siguiente

Todos los horarios son UTC + 1 hora


¿Quién está conectado?

Usuarios navegando por este Foro: No hay usuarios registrados visitando el Foro y 5 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:  
Desarrollado por phpBB® Forum Software © phpBB Group
Traducción al español por Huan Manwë para phpBB-Es.COM