Rework on the interaction

[eru-manifestation]

The clips interface should be independent from the frontend implementation. So each change should be sent to the frontend as an add, remove, modify or move change, the value changed and the reason why it changed.

Later the client should transform this information into the corresponding javascript/HTML/CSS actions and apply them.

I suggest that for the web implementation, the application of these javascript orders should be done by javascript events.

[eru-manifestation]

3 TIPOS:

• [x] ADD
• [x] REMOVE
• [x] MODIFY
• [x] MOVE
• [ ] REVEAL ??? o es un modify???

Inicialmente se pensó que la forma para hacer al gestor de visualización del cliente partícipe de la interpretación del estado del juego fue añadir textualmente la interpretación de cada acción junto a la propia acción.

ANNOUNCE TEXTUAL + ETIQ TIPO:

"El jugador baja el personaje A en B" + MOVE A B "noeseo" + ADD A B

Es mejor que el propio gestor de visualización identifique el significado de la actualización en vez de proveerlo textualmente. Se envía sólo el tipo de actualización y su información.

Se hace el cambio aquí pero es invisible y se falsifica la visualización durante toda la anim. INICIO -----------------^^------^^-------------- FIN ANIMACION

o bien se hace el cambio aquí y se falsifica la visualización durante toda la anim. INICIO -----------------^^------^^-------------- FIN ANIMACION

Entonces:

1. El cliente recibe ETIQ TIPO con la actualización
2. Su "gestor de visualización" infiere qué tipo de animación se realiza según:

NO HACER Animaciones a la espera anteriores (puede que no haya necesidad) NO HACER EN CAMBIO, HACER:

• Otros elementos de la partida en conocimiento del gestor (intentar no utilizar para mantener la simplicidad)
• Clases y valores previos y posteriores del elemento actualizado

NO HACER El gestor de visualización no conoce la causa del cambio más allá de lo que pueda analizar de los elementos EVENT, por lo que debe mantener la lista ordenada de precedencia en actualizaciones, para que el gestor de visualización pueda entender con más profundidad la secuencia de cambios (INTENTAR QUE NO SEA NECESARIO) NO HACER EN CAMBIO, HACER:

3. El gestor de visualización maneja la visualización de los elementos del juego mediante el correcto uso de hojas de estilo y modificaciones en la estructura del juego

4. La secuencia de elementos visualizables no tiene relevancia más allá de definir el orden en el que se ejecutan estas animaciones

Para conseguirlo:

• El agente CLIPS hace que todas sus instancias hereden de una nueva clase USER1
• USER1 tiene manejadores de mensajes que envían las etiquetas cuando se modifica, añade o elimina cualquier elemento del juego
• El gestor de posición del agente de CLIPS también informa sobre las modificaciones de posición de los elementos

Entonces, el cliente posee:

• [x] Gestor de conexión (DONE; refinement expected)
• [ ] Gestor de visualización (WIP)
• [ ] Gestor de interacción (TODO)

Ejemplo de funcionamiento:

1. CLIPS decide que se llega a un combate, por lo que envía ADD EVENTOCOMBATE ... con todos sus atributos
2. El gestor de visualización del cliente recibe el ADD y aplica los estilos a la partida para que el usuario comprenda que se ha entrado en el momento de un combate entre ciertos integrantes
3. El combate se resuelve de la forma que sea, con sus animaciones de forma independiente a las correspondiente al evento EVENTOCOMBATE
4. Al terminar el combate, CLIPS envía REMOVE EVENTOCOMBATE, por lo que el gestor de visualización aplica los estilos para que la partida continúe con normalidad