CAAD

Tengo entre manos varios proyectos de tipo librería para el lenguaje I7 y no me acabo de decidir por qué camino seguir, así que inspirado por la lectura de varios mensajes de este foro sobre la transparencia y demás he decidido preguntaros:

• ¿Qué librerías existentes en I6 echáis de menos y con qué mejora os gustaría verlas en I7?
• ¿Qué librerías de las existentes en inglés (http://inform7.com/write/extensions/) os gustaría que existiese en español?
• ¿Sobre qué tema echáis en falta extensiones útiles (PNJs, características físicas de objetos -líquidos y demás-, sistemas de conversación, combate, etc...)? En el caso de respuesta a esta pregunta, sería interesante que detallaséis en lo posible qué os gustaría que os proporcionase la extensión.
• ¿Qué es lo que más veces habéis repetido en I7 y os resulta repetitivo? De nuevo cuanto más detalle mejor.

Gracias.

Yo creo que sería interesante disponer de las librerías estandar, las que van con la distribución oficial de I7, más que nada por conseguir un I7 hispano que no eche nada en falta al guiri, y también porque son utilizadas por otras extensiones. Plurality, Complex listing, Menus, Rideable Vehicles...

Por otra parte está la de epistemología, aunque me suena que ya hay algo.

En cuanto a conversación, a mí me gusta el "framework" de extensiones de Eric Eve.

De objetos complicados están los líquidos para la que hay una extensión de Al Golden, y las cuerdas, que juraría que había visto algo de Emily Short, pero no parece que esté. En las recipes de todas formas creo recordar que había algún ejemplo elaborado.

Y por último, los personajes. La más potente parece ser Planner, de la que espero publicar un pequeño tutorial en la web de Grendel, a falta solamente de... que funcione la extensión. La oficial no compila, pero que esto no induzca a malas impresiones, la extensión es realmente cojonuda, lo que pasa es que el bueno de Nate no está demasiado motivado con I7. Espero que publique la corrección en breve, y si no lo haré yo.
Planner no necesita traducción, pero hay mejoras evidentes por meter, como un control de epistemología para personajes. Yo lo he intentado pero me he encontrado con limitaciones serias de I7 para definir estructuras de datos más allá de una simple tabla. Quizás alguien con mucho conocimiento y (sobre todo) imaginación pueda hacer algo...

Pensaba que ya estaban incluidas! Revisaré la situación de esas... aunque en esto Sarganar debería opinar sobre cuál es la forma más correcta de incluirlas. ¿Sustitución del paquete interior?



En su momento dije (http://wiki.caad.es/Extensiones_I7, habría que actualizar este artículo...)



No sé si ha cambiado mucho la situación, lo miraré.



Yo también querría tener funcionando el Planner, será una alegría si la haces funcionar. Pero, vamos, si me explicas qué limitaciones encontrastes igual podemos dar ideas entre todos.

Pues no sé qué licencia tendrá el paquete ese, creo que el IDE es open source así que no habrá inconveniente, si alguien se pone, claro. Otra solución es un paquete post-instalación para hispanizar todo, incluyendo la Spanish básica de Sarganar.

Ah, pues la verdad es que no conocía esa página. Parece que no se actualiza desde 2007... Sería excelente actualizarla o montar algo como la oficial, pero para traducciones y originales en español.. Umm...


Funcionando está, el problema es que no es mía y la corregida está en mi pc, a la espera de qué hace su autor.

Respecto a las limitaciones sería un poco largo de explicar. Como está ahora, los personajes interactúan con el entorno, y lo hacen muy bien, pero en base a un conocimiento absoluto de objetos y hechos, cosa poco realista. La ampliación lógica es modificar los patrones por defecto definidos en los Basic Plans para que tengan en cuenta su propio conocimiento del mundo.

Entonces llega el problema de implementar una estructura eficiente que relacione elementos de tres en tres. Es decir: personaje - objeto - situación subjetiva. La última es la localidad donde lo vio por última vez. Caso de no conocerla o haber cambiado de sitio el objeto cuando llegue el personaje, podría iniciar una búsqueda por localidades y contenedores, por ejemplo.

La idea inmediata es una tabla donde busquemos por índice [personaje - objeto] y nos devuelva la localidad. Pero I7 no permite esto. De hecho tengo la desagradable sensación de que la búsqueda actual en tabla por un índice único es secuencial y que realmente todo eso se traduce a arrays de toda la vida, así que tanto daría que existiera o no la búsqueda por varios campos.

Por otra parte se podría meter como una Relation. Pero a día de hoy no hay relaciones ternarias ni atributos de relación.

Por lo que sólo quedaría una solución que en la práctica no es viable, y que es algo como meter en algún libro de reglas una regla por cada posible combinación, y luego recorrerse el libro entero en cada turno. Dado que tenemos tres variables posibles el número de combinaciones puede ser intratable.

Y esto asumiendo que los personajes hagan un "seguimiento" a objetos concretos y marcados. Si queremos hacer algo general a lo epistemology, miedo me da hasta de pensarlo.

No había nada que traducir, excepto el ejemplo y la doc que me ha costado un rato, pero primer avance:

https://sites.google.com/site/johanilat ... logySP.i7x

Intentaré este fin de semana hacer una equivalente basado en relaciones para los PNJs.

Ayer pensaba en librerías. Y me gustaría tanto para I 7 como las demás variantes de Inform, que no haya que preocuparse de escribir los objetos sin ñ ni letras acentuadas para que se puedan escribir en el juego sin estos caracteres. Lo que me gustaría que la librería haga es permitir escribir en el código los objetos bien puestos (también los nombres, adjetivos etc) y que al compilar la extensión se ocupe de convertir de alguna forma estos objetos para que en el juego se puedan de todas formas escribir sin ñ ni acentos.

Uff... me temo que eso sólo se podría conseguir cambiando el compilador. Pero lo pensaré.

¿O sea que no se pueden hacer aventuras en I7 donde salgan como objetos (y se distingan) una cana y una caña, un panal y un pañal, una cuna y una cuña, un mono y un moño? http://static.zooomr.com/images/4703312_ab5478c5b1.jpg ¿Y tampoco con un papa y un papá, un inglés y unas ingles, una sábana en la sabana?

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

Yo, ya tenía resuelto ese problema.
Pero, tu apreciación Al-K, es muy buena. Justo es reconocértelo.
Y los ejemplos escogidos, magistrales.

Jhoer, tú eres unos de esos tipos, de los que deberían hacer un parser algún día.

Nada de eso Al-K, estás completamente equivocado. Observa los ejemplos, te pego el código y los resultados:



Ahora este otro código:



Finalmente:



Como puedes ver SI que se PUEDE distinguir entre sábana y sabana, si quieres. El problema sobre el que hablaba Fernando es este último, es decir si en el juego sólo existe la 'sábana' y el jugador escribe 'sabana' el parser no se relacionará una cosa con la otra. Esto funciona así porque en el código (desde los tiempos de I6) está este código:



Que básicamente hace lo siguiente: si una palabra tecleada por el usuario contiene acentos y no coincide con ninguna palabra del vocabulario la librería le quita a lo tecleado los acentos y vuelve a mirar. Entiendo que lo que pide Fernando es un comportamiento como sigue:

• Que se puede usar tanto en I6 como en I7 vocabulario con acentos: A sábana is in the Lugar.
• Que cuando el jugador escribre 'incorrectamente' > ex sabana, el parser pruebe también con 'sábana'
• Pero sólo cuando no haya 'sábana' y 'sabana' como objetos diferentes en el juego.

Para lograr eso la única manera eficiente que se me ocurre de hacerlo es con el compilador, es decir, que en tiempo de compilación si existe 'sábana' pero no 'sabana' entonces que el compilador añada como sinónimo 'sabana'. Se podría intentar en tiempo de ejecución pero me parecería muy poco eficiente, y además no conozco ninguna forma de añadir palabras al vocabulario en tiempo de ejecución en Inform.

Equivocado no, porque no estaba afirmando, estaba preguntando si se podía hacer eso o no (aunque vale, preguntar con "¿o sea que...?" es como decir que te parece que no...)

El comportamiento por defecto de I7 que has explicado me parece muy razonable, de hecho mientras se pueda poner "understand sábana as sabana" (o algo así) si realmente en la aventura son lo mismo, yo diría que la opción que propone Fernando de que se pueda usar "sabana" para referirse a la "sábana" (en ausencia de una sabana de verdad) es innecesaria. Una aventura debería tener derecho a ser quisquillosa con las tildes si quiere (imaginemos "Aprende ortografía con Elfito").

Si realmente añadís ese cambio al compilador, yo lo pondría en todo caso como opción, no como cambio forzoso.

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

Sucede que en I7 en las últimas 4 o 5 versiones se lleva trabajando tiempo para completar el soporte Unicode, que ya está listo en las dos últimas versiones.

Gracias a tal soporte, ahora los códigos fuentes pueden llevar tildes y otros caracteres raros fuera de ASCII y ser perfectamente entendibles por el sistema, el compilador (ya parcheado) y los intérpretes (que hayan sido actualizado) para dicho fin.

En las dos últimas Specs de Glulx ya se completado el soporte Unicode. Y en Z existen parches.

---

Pero es distinto si hablamos de INFSP6/InformATE! En estos dos, se ha tenido forzosamente que incluir la rutina QuitarAcentos porque, a falta de soporte Unicode, de debía recurrir a cualquier solución a la mano.

Aunque no estaría mal eliminar dicha comprobación, ahora que ya existen binarios apropiados del compilador para aprovechar estas características...

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

Nosotros no podemos 'incluir nada en el compilador', eso los guiris que son los dueños del compilador.



En cualquier caso a mi me parece bien facilitar en lo posible la vida al usuario, incluso para los que cometan faltas de ortografía. A ver si alguno se anima a traducir el Poor Man's Mistype.

En Inform 6 se me ocurre una forma bastante sencilla usando la propiedad "prioritario" controlada en el ChooseObjects de tal forma:


De esta forma, para sábana de la cama podríamos escribir tanto "sábana" como "sabana", y en caso de estar presente también la sabana africana, ésta tendría prioridad automáticamente al omitir el acento.

PD: El caso de la eñe supongo que funciona igual que el de los acentos ¿no?

_________________
_/ /\ R e \_

Pero explícame algo que todavía no cazo. ¿El soporte Unicode permite más allá de poner caracteres raros en el código hacer lo mismo que la función QuitarAcentos? En ese caso estaría bien eliminar la comprobación, de todas formas sería bueno esperar a que los binarios estén disponibles para todas las plataformas; sé que se puede compilar a través de los fuentes pero hay muchos que no sabemos cómo o nos da pereza.
Otra cosa que se me acaba de ocurrir saber: Si el soporte Unicode mejorado es cosa del compilador se podría entonces en I 6 e InformATE con el compilador más reciente poner cosas como (nótese la acentuación) y asimismo cambiar en InformATE nombres de cosas para que por ejemplo descripcion se ponga descripción, estatico estático etc.?