Re: [Mine-dev] Scripts: secuencias de sucesos

[Andres Moya]

El lun, 19 de 05 de 2003 a las 14:27, address@hidden escribió:
>
> Ok, cuando tenga tiempo reharé el diagrama. De momento aquí va el
> "diccionario de campaña":
> 
> [...]

¡Ahora sí lo entiendo mucho mejor! No hay nada como unas buenas
definiciones...

Lo del contexto, a ver si lo entiendo: los contextos de un item son
palabras que definen la situación en la que el item se da, y por ejemplo
si se activan varios items de un tema, se seleccionarán juntos los que
tengan los mismos contextos; y si se cambia a otro tema, se empezará por
los ítems que tengan el mismo contexto que el último que se activó. ¿Va
por ahí la cosa?

Otro: veo que en la definición estableces ítem y guion como dos
conceptos distintos, aunque con relación de 1 a 1. Me parece bien, mejor
que fundirlos en uno único. De hecho el concepto de guion ya existe en
mi sistema, lo que pasa es que no se me había ocurrido una palabra
adecuada para denominarlo. Hasta ahora lo llamaba simplemente "secuencia
de acciones y requisitos".



> No está clara la diferencia entre "suceso" y "acción", hasta ahora yo
> pensaba que eran lo mismo (¿un suceso puede contener varias acciones
> simultaneas? ¿cómo se activa el suceso? ¿una acción puede tener
> requisitos, o sólo a nivel de suceso? ¿los sucesos son siempre de
> ejecución instantána - aunque puedan tener un "trigger" retardado?)

Bien, esto probablemente venga porque he cambiado las definiciones,
después de hablar con Pablo. :P

Olvídate de lo que se dijo antes, la definición buena es la que está en
la página "Operatividad" del Wiki (y las tres que cuelgan). Lo he
reformulado para que encaje mejor con la típica arquitectura orientada a
sucesos (event driven). Una acción es algo que *hace* un objeto, y un
suceso es algo que *le ocurre* a un objeto. El objeto puede *responder*
a un suceso con más acciones, que a su vez causarán sucesos en otros
objetos.

Hay una relación entre ambos, pero no tiene por qué ser de 1 a 1. Por
ejemplo, Glorfindel ejecuta la acción hablar. Los demás personajes de la
sala reciben el suceso personaje_habla. Otro: Frodo ejecuta la acción
comer sobre un objeto manzana. La manzana recibe el suceso
personaje_come, Frodo recibe el suceso actua_uno_mismo, y los demás
personajes reciben actua_personaje.

La respuesta a un suceso es precisamente un guion, o sea: una secuencia
ordenada de requisitos y acciones. Cada requisito, a su vez, tiene un
guion en la parte <cumplido> y otro en <no_cumplido>. Un guion funciona
exactamente como un programa: cada acción es una instrucción y un
requisito es como un if..then..else. Lo único que falta son estructuras
de bucles, pero no creo que sean necesarias.

Ahora bien, de momento los guiones son de ejecución instantánea, habrá
que estudiar cómo introducir temporización y eso.


> Adaptándome a la filosofía del sistema actual lo único que puedo hacer
> es algo así:
> [...]

No, esto no interesa, hay que hacer algo mejor. Por lo que veo, tu
sistema y el mio tienen bastante en común, ambos son una arquitectura
orientada a sucesos.

Las diferencias son que el sistema de conversaciones, en principio,
tiene sólo un suceso (personaje_pregunta), mientras que el otro tiene
muchos. En cambio, tu sistema admite múltiples respuestas distintas a un
mismo suceso, para lo cual usa temas, contextos y enlaces, lo cual
permite introducir IA.

Creo que lo suyo sería unificar las dos cosas, poder incorporar temas,
contextos y enlaces a cualquier tipo de suceso, no sólo a los de
conversación. Pero no lo veo muy claro todavía, dejame que lo siga
pensando un poco...


-- 
Andres Moya <address@hidden>

Contra la guerra global permanente.
Foro Social Mundial - Otro mundo es posible.