Platforms for a platformer

A platformer needs… platforms! Right? Level design has been one of my favourite parts of working on this game. I’m using Tiled Map Editor which is as intuitive as it gets to whipping up 2D levels.

When I first created my tiles I always envisioned having platforms that move horizontally, vertically and diagonally. Spikes were an early game decision too. And hopefully, I can add a threat that’s a bit more dynamic, something that moves that the player has to avoid.

In any case, moving platforms in Phaser took a lot longer than I’d like before I was happy with it. Just to be clear, it wasn’t a problem with Phaser itself, at every given point it behaved exactly as it should have.

Moving Tiles by Tweening X & Y Coordinates

Phaser comes packaged with some Physics systems that you can use, the simplest one being Arcade physics. By and large, you can make many great games with this engine. And for all intents and purposes, it’s serving me well for this one. Phaser 2 had a pretty nice way to get moving tiles but things have changed a lot since then.

My first attempt was to move tiles by setting up a tween that will carry platforms to a set start and endpoint. Results were quick to see and quick to shoot down. The tiles moved correctly, but if the player went on the tiles they would immediately fall to the bottom.

Player falling as they cannot stick to moving platforms

A fix for this would be to calculate the change in the platform’s positions, and then update the player’s positions so it sticks. Working out deltas came out of the box for Phaser 2, but were removed in Phaser 3. I had to implement it myself but it was an easy fix.

Here’s little Cuadrado chilling on a platform:

Cuadrado on moving platform with delta calculations

So I added the vertical platforms, and things didn’t always work out as planned. Sometimes the delta was fine, other times the player would fall through the platform immediately. After some debugging, I noticed that the code which calculates the render sometimes gets called after a big update, like 5 pixels. When a big update occurs, the collision check that runs every frame to ensure that the player is on a moving platform is no longer true. So while playing, you’ll jump on a tile and then see something like this:

Deltas don’t work well with vertical tiles

Not so bueno. However, it was not so unexpected within the realm of Phaser (and other engines). When you’re using the Physics engine, we move sprites by velocity. Directly changing x/y values pretty much ignores the Physics engine, which can lead to weird behaviour like this. I figured I should try to get the moving platforms managed by the Physics engine so I don’t have to code up these solutions around it.

Moving Tiles by Tweening Velocity

I decided to stick with tweens but this time move their velocity. I’ll set the platform to have high friction so players would stick to them. With tweens, you get quick results. However, velocity is not as precise as x/y coordinates. Tweens are set to run for a fixed duration. Regardless of where the platform reached, after 1 second, it will stop. Over time, the imprecisions become noticeable and I really did not like how it looked. Didn’t even check that code into version control, I needed a better way

Moving Tiles by Setting Velocity and Adding Invisible Colliders

A game technique I used eons ago for a hobby project I can no longer find did this for enemies. I would set an enemy to walk on a platform and add colliders for the enemy that were invisible. When the enemy hits a collider they go into the opposite direction. For this game, I had a waiting period when a platform reached its destination and when it returned home. Tween have settings for this since I’m no longer using tweens I had to add my own timer event. That may not be the most efficient use of resources but the game is small enough to make it manageable. I hope.

Hack hack hack, and implemented the third iteration of moving tiles. It worked well but there were some caveats. The player did not stick to a falling platform. It made sense, a platform moving on its own very quickly will leave a gap between itself and player that gravity will fulfil. That wasn’t the aesthetic I wanted so I made gravity ridiculously high when a player is on a platform. To make that work I need to check when the player is not a platform to bring it back to normal. And of course, revert settings when jumping.

Speaking of jumping, it works out of the box but looks completely wrong when a platform is moving upward. Player jumps did nothing at all. Again, it made total sense. My jump velocity was 180 and my platform velocity was 200. When the player jumps the platform quickly catches up and collides again, giving the player some intense gravity syndrome. I scratched my head for a bit and watched some videos of Mario for inspiration. To be honest, in those Mario games with perfect vertical platforms, they moved pretty slowly. I decided to accept this limitation and make my vertical platforms slower. To make the game feel more balanced, I reduced the speed of all platforms and changed the level to suit it better. In the end, it worked out well.

Moving On

The end is nigh. Luckily with this work, I can crank out some fun levels pretty quickly. It took me 15 mins the design and test the 3rd level, and 30 mins to integrate it as it added spikes which meant new code. I can crank out a few more levels really quickly with what’s in place so I’ll do that.

I’ll work on the game timer and set it up as well. Hoping to get that done by Friday to leave a fun Saturday for more levels, sound and some much-needed polish.

It’s coming along!

Files 332 kB
May 26, 2020

Leave a comment

Log in with to leave a comment.