It’s been over a decade since I’ve written a side scrolling platformer. However, it’s sort of like riding a bicycle. One you’ve did it once, you’ll never forget.
On the surface, it seems really simple. When the player presses”A” the character starts jumping until the player releases the “A” button. That’s a starting point, but that allows the player to hold down the button forever, which results in the character blasting off into space.
Therefore, you’ve got to add a counter to keep track of how long the player has jumped. If this value reaches a certain point, then the player should start to fall. This is easily handled by adding a boolean jump variable. Press “A”, and then the jump boolean gets set to true. Release “A”, then the jump boolean gets set to false. If the player reaches the jump limit, then set the jump boolean to false. In the update function, subtract from the player’s Y position the jump velocity if the jump boolean is set to true. If the player is not standing on anything, then add the falling rate the player’s Y position. Starting out, I just used Y == 400 as the ground. More complex collision detection will be handled later.
This works okay, but it still allows the player to press “A” again while the character is falling, which results in a double jump. Further, the player can keep jumping over and over again to go as high as they want. Therefore, another boolean is introduced to keep track of falling. When the jump period is over, the falling boolean gets set to true, and the player is not allowed to jump again until they have collided with the ground. At that point, the falling boolean gets set to false.
For the run animation, I used Blender to render 3 frames of a new stick man model that I created. For this model I used additional smoothing before creating the bones. Then I used Gimp to crop all three images to the same size (128×128). Then I flipped all three images to create the player facing the opposite direction. (There may be a function in XNA to do that).
A new integer variable is created to keep track of the current walk animation frame. In the update method, this variable is incremented. However, if it changes one image per frame, then the walk animation will go too fast. This would probably work if you have a graphic for each frame. However, I only have three for now, so I just divide the animation counter (which maxes out at 30 and gets reset back to 0) by 10. This provides 3 frames for every half second, assuming that the update function is getting called 60 times a second.
Shooting seems fairly simple as well, but there is actually a little more involved than one would think. Just pressing either shoot button will set the pellet to active, but it doesn’t know which way to travel. Therefore, a new variable has to be added to the player to keep track of which way they are facing. I used -1 for facing left and +1 for facing right. That way, I set the velocity of the pellet to the pellet speed times the facing value. Additionally, the alive value has to be set to false once the pellet reaches the left or right window bounds.
Also, the player can repeatedly press the shoot button, which will keep reinitializing the pellet back to the player’s location. To avoid this, a check must be preformed to ensure that a new pellet is not taking the place of an already existing pellet.