Game: Analizar migración de loop de flushEvents del backend al frontend

[mind-ar]

Actualmente hay dos bucles en game: uno en backend y otro en frontend(manejado por p5).
Este issue es para analizar la posibilidad de unificar los loops existentes en uno solo

A mí no me convence la implementación con el setInterval en el server.
Para mí eso lo debería manejar j5 en su loop (expone una función para eso).

Por ahora esto está bien, pero si te parece en alguna reunión me gustaría que pensemos alguna > implementación alternativa que no necesite que server y cliente estén timeados.

Originally posted by @PalumboN in #136 (review)

[mind-ar]

en #140 hice una prueba, y no convence el resultado

Lo que hice

• En el backend, reemplacé el setInterval para el evento flushEvent por un socket.on('flushEvents', ...)
• En el frontend, utilicé el método draw() para emitir un flushEvent al backend

Lo que noté

• el método draw() se utiliza para dibujar en el lienzo, a una determinada velocidad (frameRate) que por defecto es 30 (creo)
• para emparejar con el funcionamiento del backend (100ms) hay que bajar el frameRate a 10
• cuando llamamos a esta función, estamos haciendo dos cosas:
  • dibujar en el lienzo los visuales que recibimos en algún evento anterior
  • enviar la solicitud de actualización al backend (que va a tardar unos cuantos ms en poder resolver)
• con unos cuantos visuales, el tiempo que tarda el backend en resolver un flushEvent pasa fácilmente esos 100ms, lo cual produce una baja de performance para onTics muy cortos y para la detección de teclas
• esto sucede indistintamente con éste nuevo método o con el del setInterval en el backend, pero la gran diferencia que noté es que con éste método se cuelga mal la consola (finalizar el programa puede llevar varios muchos segundos)
• esto se debe a que con este nuevo método estamos enviando un evento flushEvent cada 100ms sin importar si el backend puede procesarlos a tiempo o no, acumulando los eventos y haciendo que se cuelgue todo
• Si queremos poner la lógica en el frontend, creo que va a tener que ser en forma mas controlada, por ejemplo, sacarlo del draw() y poner un setTimeout cuando se recibe un evento visuals así no sobrecargamos al backend

dejo el link del proyecto que armé para ir probando wollok-ts: https://github.com/mnunez-unahur/wollok-ts-pacman.git