Cuidadín porque va una clase teórica…
A continuación voy a proceder a explicar en qué consiste el módulo de movimiento, y cual es la idea que tenemos para desarrollarlo.
Detrás del Juego y los bonitos movimientos de los avatares, hay un complejo sistema de envío y recibo de mensajes entre usuarios, que cada ordenador “desencripta” y lo transforma en movimiento. De esta forma, si un usuario pulsa en un lugar (el lugar a donde quiere ir) manda automáticamente a todos los usuarios un mensaje de texto en el que indica su nombre, y las coordenadas de donde quiere ir. Cada ordenador desencripta esta información, y mueve el avatar a esas coordenadas. Dicho así, incluso parece simple. Pero en la encriptación del mensaje por parte del usuario que va a moverse y la desencriptación del resto de usuarios de ese mensaje, hay mucho más.
Para hacernos una idea, el usuario que se mueve envía, concretamente, este mensaje: “<clientparam from=’el nombre de quien quiere moverse’ name=’hasta’ value=’posicion en X-posicion en Y’>“. El FROM está claro: es para que todo el mundo sepa quien se está moviendo. El NAME es para que la gente sepa qué acción está sucediendo. En este caso, “hasta” quiere decir que va a haber un movimiento, pero imaginaos que no se va a mover sino que va a lanzar un hechizo, en ese caso, NAME sería igual a ‘hechizo’. Y por último, VALUE es el valor. En este caso, manda las coordenadas en X y en Y de donde queremos dirigirnos.
Bueno, como veis esto comienza a complicarse, pero digamos que esto es sólo el 1%, porque la cosa no queda ahí: ¿cómo hacer que el usuario se mueva sorteando los obstáculos que haya en el camino hasta llegar a su destino? ¿cómo sabemos que en las coordenadas que se han mandado no hay un objeto, y por lo tanto no podemos desplazarnos hasta ahí? Estas son sólo algunas de las preguntas que hacen el sistema mucho más complejo. No obstante, ya están solucionadas. El problema que tenemos ahora es, precisamente, que los avatares se muevan físicamente, no que sólo se manden mensajes entre ellos y sepan qué camino deben recorrer sorteando obstáculos o si pueden llegar a su destino.
Para esto, se han desarrollado dos funciones. Una, la función WorkGen, y la otra, la función MoveGen. Ambas utilizan la abreviación Gen, de “Genérica”. Es decir, es una función “Genérica”, para todos los usuarios.
La función WorkGen se está poniendo en marcha TODO el tiempo. Su trabajo es saber QUIEN se está moviendo en cada instante. ¿Cuál es el problema de esta función? Que el hecho de estar trabajando constantemente puede causar al cabo de un tiempo un retraso, y si hay mucha gente moviéndose, más retraso aún. Al final lo que hace la función WorkGen es saber quien se está moviendo y, por cada usuario que se esté moviendo, activar la función MoveGen.
La función MoveGen es aún más compleja, lo que significa que si hay mucha gente moviéndose (y por lo tanto la función se está ejecutando muchas veces) puede provocar más lentitud aún. Con que haya UNA sola persona en movimiento, esta función se pondría en marcha 12 veces por segundo. Si hay más de una persona, simplemente tendríamos que multiplicar 12 por el número de usuarios en movimiento (en esa misma sala), si hubiese 20 usuarios en movimiento, la función estaría ejecutándose ni más ni menos que 240 veces al segundo. Esta función se encarga de ir moviendo, de píxel a píxel, los avatares por la pantalla.
Detrás de todo esto hay mucho, mucho más, y cientos y cientos de líneas de programación. Publico todo esto para que os hagáis una idea de lo complejo que es UN sólo módulo (hablamos simplemente del movimiento, como os recuerdo) y de los problemas que puede causar. La misión actual es completar la función WorkGen y MoveGen, ya que aún están sin terminar (es la nueva idea de la que hablamos en otro Post) y después, intentar reducir esos retrasos que se pueden causar.
¡Bueno, ya he avisado al principio de lo teórico que iba a ser esto! Pero así al menos entiendes algo más Winguts y no te quedas simplemente esperando sin saber qué está pasando.
¡Saludos!