Guess who’s back? MOMFUS! (forced applause!) I return with another dev diary oriented to the technical part of the sprite in PROJECT NN. In the previous post (you can read it HERE) I was telling the possible camera angles and their implications in the type of movement we wanted to do for the project; this time we’ll see it’s implementation (in a very general and simple way).
We decided to use a top-down view with a slight downward tilt (examples: Enter The Gungeon or Hyper Light Drifter) where we’ll have 5 different sprites used in 8 directions (example: Tower 57). This represents a greater work for the graphic designers (to which I must compensate with beer or games on sale) but a greater sense of depth and dynamism to the player, obviously it’s also a little headache to apply this in GameMaker Studio 2 so, What solution did I found?
First I observed other games that have the sprite legs separated from the torso. The torso is oriented according to where the cursor is (8 areas starting at grade 0 and increasing at 45/2) and the legs don’t just follow the action of the WASD movement keys; but also on how the torso is directed (obviously it would be weird to see the knees down if the torso is facing up).
In the next image we see that division. The letters followed by ®️x are to mark that they’re a reflection; for example: B®x is the reflection of the B direction.
Considering this and that each letter represents a direction, there’s a set of possible leg movements. Here we present an example for the player with the cursor up (again, it is illustrative nothing else):
Each number in the previous image represents a different sprite for the legs (again, the characters ®️x indicate that they are a horizontal reflection of the number that precedes it). You can see that some are repeated and that’s because you can use the same sprite and save resources. Analyzing each direction with the torso you can get the list of sprites used for legs and torso. In our case they were: 5 sprites for torso and 10 for legs.
The sprite of the player is drawn in two graphic parts and in the Draw event of GMS2 they’re drawn together, one after the other.
Considering this and that each letter represents a direction, there’s a set of possible leg movements. Here we present an example for the player with the cursor up (again, it is illustrative):
To get the direction of the torso I simply call a script that I created at the beginning of each Step event of the player object, it is something trivial and I don’t want to extend this article, but it’s simply to obtain in which direction to the player the cursor is, and get the rest of the directions of the result of dividing it by 22.5; obtaining from 0 to 14 (fifteen numbers), each pair represents a direction using the enumerators (from 0 to 7). The following image makes the explained concept better explained:
Finally, when the player object is created, it has to have 2 two-dimensional arrangements: one for the torso and two for the legs. In order to make things easy with the numbers and positions, we use enumerators according to the state of the player and his direction; so don’t be scared if you don’t see numbers. Exploring the concept of enumerators a little, you’ll understand why in many programming languages they’re used. The player’s sprite and the scripts to initialize the arrangements are the following:
To demonstrate that what we have done isn’t black magic, for the sprites of the Idle state of the player in the first script, the following is done:
As you can see, it only assigns the sprites (assets of the game) to a specific position of the arrangement, which is then used to make a dynamic change according to the direction of the torso. We can see that the right and left direction are the same sprite, and this is because at the moment of assigning the player their image_xscale is changed to the opposite one in order to reflect it.
For legs, and to have more management, we decided to have two arrangements: one for when the player is in Idle state and another when in the state Move (since here not only changes according to the direction of the torso, but also of what direction was defined by pressing the WASD keys); The sprites assigned in the second script used in the player object for its Idle state are the following:
The overall result can be seen in the following GIF:
I hope to have left a general overview of how we faced in Crios Devs the problem of movement and sprites, the article would be ridiculously long if I had to explain and show each line of code, but the important thing is to understand the idea of the proposed solution (for be able to apply it in other projects). I know that this post is much more technical than previous articles, but it is something that people ask me a lot and I hope I have clarified some doubts. As always, if you want to leave a question or communicate with us, you can leave us a comment or send us a message!
I want to say that surely there are better methods but this was the method that in the programming team we found useful, fast and simple, but like almost any area in the development of games, it’s a never ending task. Any suggestion and criticism, in addition to which point would like us to develop more, can comment on our social networks and / or in this article.
Goodbye and good gaming!