¿Quién está de regreso? ¡MOMFUS! (aplausos forzados) Vuelvo con otro diario desarrollo orientado a la parte técnica para seguir el progreso de PROJECT NN. En el artículo anterior (que podés leer AQUÍ) estuve comentando los posibles enfoques y sus implicancias en el tipo de movimiento que queríamos hacer para el proyecto; esta vez veremos su implementación (de una manera muy general y simple).

Recordando brevemente: decidimos usar una vista top-down con una leve inclinación hacia abajo (ejemplos: Enter The Gungeon o Hyper Light Drifter)  donde tendremos 5 sprites diferentes utilizados en 8 direcciones (ejemplo: Tower 57). Esto conlleva un trabajo mayor para el diseñador gráfico (a los cuales deberé compensarlos con cerveza u juegos de ofertas) pero una mayor sensación de profundidad y dinamismo al jugador; obviamente también es un un pequeño dolor de cabeza aplicar esto en GameMaker Studio 2 ¿A qué solución llegué?

Primero me dedique a observar otro juegos en donde se puede apreciar que las piernas están separadas del torso, este último se orienta según dónde está ubicado el cursor (8 áreas empezando en grado 0 e incrementando en 45/2) y las piernas no solo toman en cuenta el accionar de las teclas de movimiento WASD; sino que también en cómo está el torso dirigido (obviamente sería raro ver las rodillas hacia abajo si el torso está mirando hacia arriba).

En la siguiente imagen vemos esa división, las letras seguidas de ®️x es para marcar que son un reflejo; por ejemplo: B®x es el reflejo de la dirección B.

Teniendo en cuenta esto y que cada letra representa una dirección, hay un conjunto de movimientos posibles de piernas. Acá presentamos un ejemplo para el jugador con el cursor hacia arriba (de nuevo, es ilustrativo nada más):

Cada número de la imagen anterior representa un sprite diferente para las piernas (de nuevo, los caracteres ®️x indican que son un reflejo horizontal del número que lo precede). Se puede observar que algunos se repiten y es porque se puede utilizar el mismo sprite y ahorrar recursos. Analizando cada dirección con el torso se puede obtener la lista de sprites utilizados para piernas y torso en total, no voy a dejar todos porque sería aburrido y largo pero en resúmen nos dio: 5 sprites para torso y 10 para las piernas.

El sprite del jugador se dibuja en dos partes, como dijimos en un principio y en el evento Draw  de GMS2 se dibujan juntos, uno después del otro.

Teniendo en cuenta esto y que cada letra representa una dirección, hay un conjunto de movimientos posibles de piernas. Acá presentamos un ejemplo para el jugador con el cursor hacia arriba (de nuevo, es ilustrativo nada más):

Para obtener la dirección del torso simplemente llamo a un script que creé al principio de cada evento Step del objeto jugador, es algo trivial y no se quiere hacer más extenso este artículo, pero simplemente es obtener en qué dirección con respecto al jugador esta el cursor y obtener el resto de las direcciones del resultado de dividirlo por 22.5; obteniendo de 0 a 14 (quince números), cada par representa una dirección usando los enumerators (de 0 a 7). La siguiente imagen deja mejor explicado el concepto explicado:

Por último, lo más tedioso, es que al crearse el objeto jugador, este tiene que tener 3 arreglos bidimensionales: uno para el torso y dos para las piernas. Para no volverse loco con los números y posiciones, usamos enumerators según el estado del jugador y su dirección; por lo que no se asusten si no ven números. Explorando un poco el concepto de enumerators, entenderán porque en muchos lenguajes de programación se utilizan. El sprite del jugador y los scripts para inicializar los arreglos son los siguientes:

Para demostrar que no es magia negra lo que hemos hecho, para los sprites del estado Idle (ocioso, es decir, quieto) del jugador en el primer script, se realiza lo siguiente:

Como ven, solo asigna los sprites (assets del juego) a una posición específica del arreglo, que luego se usa para realizar un cambio dinámico según la dirección del torso. Podemos ver que la dirección derecha e izquierda son el mismo sprite, y esto es porque al momento de asignarse al jugador se cambia su image_xscale al opuesto para así reflejarlo.

Para las piernas, y para tener un mayor manejo, decidimos tener dos arreglos: uno para cuando el jugador está en estado Idle y otro cuando está en el estado Move (ya que aca no solo cambia según la dirección del torso, sino también de qué dirección se definió al presionar las teclas WASD); los sprites asignados en el segundo script utilizado en el objeto jugador para su estado Idle son los siguientes:

El resultado en conjunto puede apreciarse en el siguiente GIF, donde ya es más trabajo para los diseñadores gráficos cambiar como se verá cada parte de los sprites.

CONCLUSIÓN

Espero haber dejado un panorama general de cómo enfrentamos en Crios Devs el problema del movimiento y los sprites, el artículo se haría ridículamente largo si tuviera que explicar y mostrar cada línea de código, pero lo importante es entender la idea de la solución planteada (para poder aplicarla en otros proyectos). Sé que este post es mucho más técnico que artículos anteriores, pero es algo que me preguntan mucho y espero haber aclarado algunas dudas. Igual como siempre si quieren dejarnos alguna pregunta o comunicarse con nosotros pueden dejarnos un comentario o enviarnos un mensaje!

Quiero aclarar que seguramente existen métodos mejores pero éste fue el método que en el equipo de programación encontramos útil, rápido y relativamente simple, pero como casi cualquier área en el desarrollo de juegos, es una tarea de nunca acabar realmente. Cualquier sugerencia y crítica, además de que punto les gustaría que desarrollemos más, pueden comentarnos en nuestras redes sociales y/o en este mismo artículo.

¡Adiós y buen gaming!


Sharing is caring!