Making the character walk around the screen was fairly easy. Keep in mind that at this point there is no interaction with any environment elements or vertical movement, so the whole thing will have to become more complex over time.
At the moment however, the whole system works on few basic principles.
As player spawns, a number of variables are defined:
- maxSpeed
defines the terminal velocity for the character. It’s at the moment set fairly low, as ChiChiLand Adventure will be a game about exploration and not require quick reflexes or perfectly timed jumps. - friction helps the character stop. When no input from the user is detected, player character will lose a fraction of its speed each frame. If I recall correctly, I have it set at 0.1 or 0.15 at the moment.
- idleTime defines how long will it take after the character comes to a complete stop for the idle animations to kick it. At the moment the sprite only randomly blinks, but I have more idle animations planned.
- jumpHeight – so… I am still figuring out how to implement that one. I will probably do collisions first, before jumps, but for now I use jumpHeight as one of the variables in setting up the position and scale of the shadow underneath the player sprite.
Other than that, it’s really quite simple – pressing any of the directional arrows generates an increase or decrease in horizontal and vertical speed, up until positive or negative maximum. Pressing the opposite keys nullifies the effect on the player, while mixing horizontal and vertical movement, lets the sprite move diagonally.
The animation script analyzes the direction of movement and applies one of the four walk cycle animations, depending on the vector. Early on I had the 360° of possible directions divided equally into four chunks, but it created a bit of a problem. Upon reaching maximum speed at 45° diagonal, the sprite displayed was hard to predict.
Say the character walks North-East (Up-Right). Sometimes it would display the spr_player_walkUp animation, sometimes spr_player_walkRight. I quickly realized that most of the time I prefer to see the character facing the camera (or fully away from the camera), so I decided to extend the cones understood as Up and Down and narrow down the Left and Right ones.
To do so I created a simple variable named orient which uses a series of if/then/else gates to assign a simplified numeric system for the direction of movement. 0 is right, 1 is up, 2 is left and 3 is right.
The cool thing is that these numbers correspond to my sprite array so that first frame (frame 0) of the spr_player_default faces right, second frame (frame 1) faces up etc. I can therefore use a simple command image_number=orient; to turn my player in the correct direction.
Try it yourself with the previous post: ChiChiLand Adventure: Basic Movement Demo.
In the next post I’ll talk a bit about the behavior flow, idle animations and some other elements of bringing the player character to life.