CAAD

Hola

¿Podría resultar útil un sistema como este de definición de una aventura ?. Creo que PUCK hacía algo parecido.

http://2.bp.blogspot.com/_UcEUtJT6TrI/S5OQRxg1c6I/AAAAAAAAAHY/s6YIdf0PdNo/s1600-h/latorre.png

Si bien el sistema puede que no sea completo si que podría simplificar bastante la creación de una aventura. Una forma muy rápida de declarar los puzzles, las localidades y que posteriormente puede ser rellenada con un editor de texto. Me gusta poder ver de un vistazo la relación entre los objetos.

Se ha creado en DIA, cuyo formato de salida es XML. En él sólo se incluyen los objetos que forman el diagrama, no las líneas que lo forman. Además elementos especiales como las flechas incluyen información sobre los objetos que conectan. Este formato permite de forma muy sencilla generar código a partir del diagrama.

_________________
---
KMBR! http://www.aliensuavito.org @lecambre

Sí, el PUCK usa algo parecido pero con la diferencia de que el diagrama del PUCK modela sólo los datos, no los comportamientos. Es como un diagrama entidad-relación, permite expresar cómo están organizados y relacionados los datos pero todo lo que es eventos, métodos, etc. va en código y no en el diagrama.

La verdad es que sería interesante tener también en el PUCK una representación similar a la del diagrama que pones, a partir de la cual se generara código que manipulara objetos. El problema podría ser la escalabilidad. Para una aventura pequeña y no muy detallada un diagrama así puede ser manejable, pero en cuanto empiezas a meter muchos objetos en cada localidad, al tener que diagramar también los verbos y tal, la representación podría volverse bastante compleja.

Tal vez esto último se podría evitar con un diseño tipo "task-oriented interface". O sea, que en un momento dado no veas el diagrama entero sino una parte de él. Una de esas partes podría llamarse "puzzle de la caja fuerte" y contener todos los objetos y eventos necesarios para que el jugador consiga abrir la caja fuerte.

Ay, si tuviese tiempo...

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

Para mí, ese ejemplo que muestras sería inmanejable a partir de los... 20 objetos.
Puck solo muestra en pantalla los objetos y sus relaciones con otros objetos, mi aventura es pequeña y aún así a veces pierdo algún objeto en el mapa.

Para mi proyecto hice una especie de diagrama de puzzles, unido a una línea de tiempo.

Ahora me he dado cuenta que con Puck no hace falta eso, como cada objeto tiene su propia ficha que se muestra a la derecha del mapa, es cuestión de empezar haciendo la historia a la par que los objetos y comentando en sus fichas los diferentes estados que pueden tener a lo largo de la historia, sin crear los puzzles solo plateándolos por medio de "writes", y luego jugarla de ese modo y buscar inconsistencias en la misma. Cuando no las haya... es el momento de empezar a meter código.
Ya os contaré si me funciona.

Se puede hacer de otro modo.
Cada vez que selecciones un objeto, cambia el mapa general del mundo, por el particular de ese objeto, de este modo la escalabilidad dejará de ser un problema.
Otro modo sería que se abriera el objeto en una nueva ventana y así podrías pasar de un mapa al otro sin problema... pero sé que odias las ventanas. xD

Hola

No estoy de acuerdo con lo de que no sea escalable y que es inmanejable para algo a partir de 20 objetos. Todo se podría agrupar en cajas de mayor nivel, de modo que a nivel superior podría verse un diagrama de bloques. Y al ir entrando en los bloques podríamos ver los distintos objetos, también podria permitirse ver relaciones de un objeto y otros tipos de vista para el conjunto de objetos.

Os recomiendo que le echéis un vistazo a LABVIEW, que es justamente esto que propongo salvo que no está orientado a aventuras. En LABVIEW modelan el flujo de señales con el lenguaje, en nuestro caso sería modelar el flujo de información dentro de la aventura. Este diagrama es un ejemplo sencillo, es el tutorial de la torre, pero se puede complicar bastante más sin perder claridad. Seguramente con un subconjunto de los ladrillos del LABVIEW se podrían cubrir una casuística muy amplia en las aventuras.

_________________
---
KMBR! http://www.aliensuavito.org @lecambre

Hace cosa de 2 años yo ya propuse algo en esa dirección.

_________________

"Tengo tres perros peligrosos: la ingratitud, la soberbia y la envidia. Cuando muerden dejan una herida profunda. (Martín Lutero)"

Hola

Sí es algo en ese estilo. Lo que propongo es concretarlo, proponiendo un sistema similar a algo que ya funciona y se utiliza ampliamente. He intentado darle forma a un diagrama con una sintaxis determinada, de modo que con un generador adecuado se podría crear la aventura. Lo bueno de usar DIA es que ya está hecho, permite crear nuevas formas y darles atributos.

Un saludo.

_________________
---
KMBR! http://www.aliensuavito.org @lecambre

Bueno, yo te he dado mi opinión basada en mi propia experiencia.
He estado mirando Labview, los flujos de información son algo cotidiano y habitual para aquellos que han estudiado programación, yo sin embargo nunca me he apañado con ellos.
Se supone que todo esto es para simplificar la tarea del autor de aventuras, pero por lo pronto y siempre hablando de mi caso, yo tendría que aprender la sintaxis y comandos del lenguaje de programación de aventuras por un lado, y el manejo del mapeado y los flujos por otro, no sé si me merecería la pena tanto esfuerzo.

O eso, o no me estoy enterando de nada, que todo es posible.

Sí, eso sería una de las posibles formas de implementar el "task-oriented interface" que decía antes: tener submapas asociados a objetos. Lo que pasa es que también podría ser interesante poder tener submapas asociados a unidades más grandes (como un puzzle), porque una acción o serie de acciones pueden afectar a varios objetos. Así que seguramente lo ideal sería poder definir los submapas como uno quisiera (aunque por defecto estuviesen asociados a objetos). Y un objeto debería poder aparecer en varios submapas.

De todas formas, si algún día llego a programar algo de esto en el PUCK será dentro de bastante tiempo, porque aún hay mucho que refinar y perfeccionar en la funcionalidad que ya existe, antes de añadir funcionalidad radicalmente nueva.

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

JSJ lo hizo hace 2 años y Mel y yo tratabamos sobre este asunto hace unos cuantos meses atrás.

Se ve que el tema es un asunto recurrente. Y tal me hace pensar que es definitivamente una buena idea, porque mucha gente opina que es un método apropiado para empujar el desarrollo de IF.

Por supuesto, estoy seguro que todas las tentativas y aproximaciones serán diversas, pero todas apuntan hacia la misma dirección. Un modelado esquemático.

También opino que es buena idea que partes de los componentes del esquema pudieran ser "envueltos" en especie de "vistas" menores relacionadas con el propio concepto o con el problema que están atendiendo. Es una forma inteligente de resolver el problema de un esquema sea muy grande.

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

¿Servirían los casos de uso de UML a modo de modelamiento o demasiado genérico?

...porque para UML seguro hay demasiadas heramientas e IDEs. Que no generen código para Inform, Puck, PAWS o qué sé yo, ya es otra historia

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

Yo creo que el diagrama de casos de uso de UML es de muy alto nivel para eso. En todo caso, en el nivel apropiado estarían el de actividad, y tal vez a veces el de secuencia.

De todas formas, creo que si el objetivo es hacer un sistema de creación de aventuras más fácil accesible, UML es un poco "overkill". Tal como yo lo veo, UML es una herramienta diseñada para expresar diseños de software muy complejos, en una aventura realmente el 95% del diseño software ya viene hecho por el sistema y el autor sólo está añadiendo datos y algunos eventos asociados a los datos. Por eso veo más adecuados modelos centrados en los datos como el que usa PUCK, que es una especie de versión del modelado entidad-relación clásico.

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

Vuelvo a este hilo porque la verdad es que sí que sería interesante tener algún tipo de programa que facilitara el no dejar cabos sueltos dentro del desarrollo de una aventura.

Como ya comentaba mi aventura es pequeña y aún así a veces tiro de un hilo sin saber a cuantos otros está atado y que cambios va a desencadenar.

En las aventuras hay varias líneas de acción a tener en cuenta, una engranaría la interactividad entre los objetos y el jugador, otra engranaría la interactividad entre los propios objetos y otra engranaría la interactividad generada por los diferentes sucesos aportados por el propio guión, en el caso de que lo haya.

Son demasiados hilos para no perder el control de alguno en un momento dado y originar algún efecto no deseado, o sea, un bug.

El método que muestra Saimazoon, no parece controlar la línea del tiempo.
El que muestra JSJ... es que no lo veo nada claro...
¿No podrías poner una imagen un poco más grande JSJ ?
Es que no tengo cita con el ofta, hasta fin de mes.

Saludos
Jenesis

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

Pues ahora mismo no tengo una imagen más grande... pero ¿qué quieres ver?... es un diagrama unifilar. Dudo que puedas sacar algo en claro de él... o extrapolable al desarrollo de aventuras. Yo en su día, hace dos años, lo expuse como ejemplo de interface de un posible IDE.

Creo que PUCK, más o menos, se acerca a la idea que yo tenía.

Quizá lo que tú quieres se conseguiría añadiendo a PUCK la idea de las "cajitas" que ya se comentó.

_________________

"Tengo tres perros peligrosos: la ingratitud, la soberbia y la envidia. Cuando muerden dejan una herida profunda. (Martín Lutero)"

Vale, pensé que era algo similar a lo que había mostrado Saimazoon, pero ya veo que no.
En ese caso no hace falta que me amplíes la imagen.

Saludos
Jenesis

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