Venturing Into Platforming

It’s inevitable, right?

If someone is just starting out as a game developer, they’re bound to make some form of platformer. They’re probably going to try to recreate the first Mario game they played or if they’re outgoing, maybe they’ll try for some sort of simplistic Metroidvania. Whichever way you go, you’re almost guaranteed to have some sort of character that you’re controlling that is going to need to jump, climb, tumble, or otherwise wind up on a platform that is either higher, lower, or across a gap from where they are currently standing. This, ladies and gents, is called platforming.

So what did I do?

Well I made this:

Baby steps. I think.

Now it’s not anywhere near a complete game, but what you’re seeing there is a world with 2 platforms and a controllable character. The large red rectangle is a debug shape showing me the outline of the player’s sprite. The white you see poking out from under it is the sprite that I’ve been using to test with. The smaller red square is showing which block the player’s sprite is currently touching. In the upper left, you’re seeing debug output for player’s sprite including it’s current location, size, anchor point, and visibility.

The debug information was really easy to turn on which is convenient because I have a feeling I’m going to need to use it much more in the future:

Here I’m taking advantage of Phaser’s render function to turn on the debug info. It’s called after the game has rendered all sprites and what have you and is particularly useful for applying post-processing effects. The first line is just outputting all the sprite information I mentioned previously and the Phaser.Rectangle is the red shape on top of the player’s sprite.

Since debugging is boring, let’s get into how I was able to get the rest of it up and running.

The Player

This one was slightly more complicated than controlling the paddle in Breakout, but still very easily within just about anyone’s skill level. Since I’m determined to use a spritesheet for the player this time, we have to switch up how we load our image.

Instead of the game.load.image() that I’ve been using, I had to change it up to call game.load.spritesheet() so that Phaser can split up the sprites for easy access for me instead of me doing it manually. So just like last time, I’m providing a simple tag to refer to this sprite sheet (‘player-sprites’), the location of the file, and the width and height of each sprite. As you can tell by the weird dimension, I didn’t find the best possible sprite sheet to use to test with, but it’s good enough for now. Whatever.

While most of that showed up in the Breakout example, the new pieces to worry about here are the animations lines. The first being add which will add an animation with a given name (standing) and an array of frames that make up the animation. Additionally, you can also provide parameters for setting the frame rate of the animation and whether or not to loop the animation.

Another new piece of the framework that we’re adding here is setting a local gravity to the physics body of the player’s sprite. While I wasn’t aware of this until literally right now, you can set a world gravity value and local gravity values to override it. Since I’d like a relatively realistic world, I believe I’ll swap out this local gravity setting for a world gravity value in the next version.

Controlling The Player

Controls were fairly easy to handle with following the mouse in Breakout and they were just as easy to setup when mapped to the keyboard:

These were setup in the create() function.

Once I told the framework which keys to care about, I then had to tell it when to care about them and what to do when they were pressed:

Here I’m increasing or decreasing the horizontal velocity of the player character’s physics body to hopefully make the player fairly easy to maneuver. While one of the buttons is down I’ve got it set to steadily increase the velocity in the desired direction up to the maxVelocityX that I have set. Additionally, I’m keeping track of which direction the player is facing when one of the keys is pressed and using that information to know when to directly set the velocity as opposed to incrementing/decrementing it. You’ll also notice that when neither of the buttons are pressed I’m applying a negative velocity relative to the current direction of movement. In other words, I’m slowing the player down when motion is not needed.

But What About Jumping?

Easy man. Well, mostly easy. First up, jump when the jump button is pressed and don’t allow jumping if they player is already mid-jump:

The jump method is just as simple:

However, one thing that I’m still not satisfied with is when to turn off the jumping flag. Originally, I set it to something weird that allowed the player to stick to the underside of the platforms if you held the jump button. While that could possibly be turned into a cool mechanic, it wasn’t what I was looking for. I’m trying to correct that now, but here’s what I’ve got so far:

I’m cycling through all the blocks in the world to check if there’s a collision. That’s fine, I have to do that anyway to make sure the player doesn’t go through anything. I’m turning off the jumping flag if the player’s y position is lower than or on the same level as a colliding block. That works for blocks below the player, but does not work for blocks next to the player. What you end up with is the ability to stick to a wall. Again, could be a fun mechanic, but not what I’m looking for. I’ll refine movement in the next version. For now though, let’s look at how the world is setup.

The World As We Know It

Believe it or not, setting up the game world was incredibly easy:

Yeah. That easy.

All that line is doing is setting the top left corner of the world (0, 0) and the width and height of the world. The blocks were placed in the world the same way that I set them up in Breakout:

This is so similar, in fact, it’s using the same createBlock function that the Breakout implementation used.

Once the world size is set and everything is placed in it, just enable the physics system and you’re good to go:

What’s up next?

Refinement. The movement of the player is pretty solid, but that jump has to be fixed up. Additionally, I need to add more animations to the player and get them synced up appropriately. From there, who knows. Maybe I’ll add in those mechanic ideas from earlier in some way or maybe I’ll put in some kind of enemy for the character to deal with. Whatever it is, it’ll be fun and I’ll explain how I did it.

As usual, you can play the game here and the code can be found here. Enjoy!

If you have any questions, comments, or concerns just let me know. I’ll be happy to respond to anything and everything. Like, share, and follow and eventually, we’ll all be game devs.