Part 1.d - Player jump mechanics: Setup A

We’re just going to jump into it this week. Yes, I realize that was a terrible pun. No, I’m not going to change it. Yes, I’m the worst.

If you’re making a platformer, nine out of ten times, you’re going to need to create a jump function. There are certain cases where player-controlled jumping isn’t going to be implemented (see: NES Robocop, Bean’s Quest) but those seem to be more of the exception, than the rule.

Today we’re going to be talking about jumping mechanics in our game. We’re going to split this into two setup posts as well, so we can talk about the different methods of getting our player to jump, dependent on the way we want to use device controls.

We’re going to take a few minutes to set up our jump button(s), and to do that, we’re going to have to re-jigger our button layout.

This snippet is modifying the x/y positions of the buttons to be more something resembling an SNES controller. We’ll see how this affects the gameplay later on, as the screen real estate is being eaten up with buttons and arrows.

The other jump option we will be using is the traditional four-way direction pad, and using the “Up” arrow. In the “shooting mechanics” tutorial we’ll go over what the “Down”arrow does, but right now it’s just going to chill out.

So, we’ve got our re-worked gamepad buttons and some more directional arrows. I’m going to make the H button the jump button as well.

So, we’ve created a jumpInit() function, but we haven’t seen what’s inside. Let’s take a look at that now.

The most important thing to note here is that we are using transitions and easing properties to move our player, rather than physics. This is by design, as I wanted to show a very very simple method of replicating a jump function without using the physics engine. If you are going to be using physics in your game, however, using transitions to handle jumping will NOT WORK. It’s not a good idea to try to hack it to resemble functionality.

The prevDir holds the previous direction value, so that after the player hits the “ground”, movement still takes place.

Showing jumping logic by using transitions is a fun experiment, but no one is going to use this as a final solution in their game, so let’s look at how it would work with physics. First, we want to start the physics engine and create the “ground” to walk on.

I also enabled the physics object properties on the player’s hitbox, which is what holds the collision logic. Below is the code holding the jump logic for both physics and transitions. Why do I bother including the transition logic? Well, I already made it, so I’m going to go ahead and do whatever I want.

So now we’ve got our jump logic working, both for physics and non-physics implementations. This is just for the pad configuration. We’ll be looking at the other control configurations in the next post.

TL;DR? Check the download link to see the full code and working project:

https://www.dropbox.com/s/t3u9zw5iicibr8y/05.%208-27-14%20platform%20tute.zip?dl=0