Platforming Game Physics

By Published

Game developers have come up with lots of creative ways of making objects in video games behave similarly to the real world. All of the falling, bumping and bouncing that they do needs to be simulated in a strict way that a computer can process. In this post I'll discuss several methods for this in the context of 2D platformers, and then how I ended up doing it in my game Valerie.

In the early days, this would pretty much always be done using a tiled system. Everything was based around tiles, because it's a really efficient way of sorting out graphics and information into chunks.

[1] In the original Super Mario Bros, all of the game's graphics are stored in this pattern table. You can only see four colours here, but the palette can be changed for each tile.

If you want your game to involve slopes, this can get very complicated as every tile needs to represent a different kind of slope. Slightly later games were able to pull it off, the most famous of which being the Sonic the Hedgehog games. This is what allowed their iconic loops and topsy-turvy physics.

[2] You can see each tile light up as Sonic steps on it.

For modern 2D games that don't involve pixel art, they tend to use simplified geometric shapes. You may be seeing detailed and textured illustrated environments, but under the hood there are simple lines and circles holding it all together. Ori and the Blind Forest is a beautiful example of what you can do using rendered 2D sprites combined with this method. Modern game engines have tools that allow you to manipulate collision polygons, so it's very common in modern games, particularly that don't use pixel art.

In Ori and the Blind Forest, the levels aren't made of tiles. Instead, they're made of shapes that a computer can do maths with easily.

There is however, another method. This is bitmap collision, where every pixel of the level is accounted for as being solid or not. The most famous example of this which makes very good use of it is probably the turn-based strategy series Worms. In this game, it meant that the terrain was able to be destroyed by explosions and the characters could still stand on it realistically. This method works best for games that use pixel-art, because there are less pixels that need to be processed.

In Worms, the environments can be precisely erased by explosions while still being interacted with accurately.

My game Valerie uses this kind of bitmap collision for a few reasons:

  • The game uses pixel art
  • I wanted natural and curved looking levels
  • I wanted sloped/angle based physics
  • I'm kind of lazy

I'll elaborate on that last one. As you may be able to imagine, placing tiles down for every level, especially if there are slopes involved, can be a long process. Programmers will usually find ways to automate certain parts of it such as detecting edges to use the appropriate tiles. I wanted to keep things lighter on the programming side, essentially by just drawing my levels and filling them in with patterns to make them look nice.

In my game engine, the collision data for each area takes the form of a single image. In the example below you can see what a section of it looks like:

Here you can see a screenshot of gameplay followed by a section of the same area's collision.

This single image is then separated into "masks" based on a colour assigned to each material, such as black for ground or blue for water. A mask is an image where each pixel is either black or white - 1 or 0. They're handy because they're efficient to deal with, even as they get quite large. This idea of using a colour-coded mask is actually inspired by my time using Scratch when I was younger! A lot of games back then would use the "touching colour?" block because it was an easy way of making games with a solid ground in black, hurting bits in red, and the goal in yellow, for example. It worked a treat.

Does this bring back memories for anyone else that used Scratch?

There is a drawback to this system, though. The masks contain no information about the terrain. On a tiled system designed to deal with slopes (such as the aforementioned Sonic the Hedgehog games) you can assign an angle to a particular tile, and in a geometric system you can just know the angle of the ground from its geometry. There are also plenty of games with ledge mechanics, allowing the player to grab onto ledges. In tiled systems, ledges can be indicated by a property held by that tile.

To make up for the lack of information baked into the environment, in this game engine the character has to do a lot of 'sensing' around to discover what the terrain looks like. This includes finding the angle of the floor or walls, or finding where ledges are. Doing this in a robust way can get quite complicated, and it's something I don't have time for in this post but I'd like to share details about in future.

Because of a combination of this sensing the character has to do and the freedom offered by essentially being able to 'draw' levels, it's possible to make things that aren't compatible with the game engine and behave in a buggy way. There are certain angles of walls or shapes that it doesn't deal with well, so you need to be a little bit careful when designing. It does a pretty good job for what it is though, and I think there's a limit to how many edge-cases it's sensible to cater to.

The yellow bits here indicate the "go through" mask, a material the player can jump upwards through. Also sorry.
 

I'm sure other games use similar methods to mine and it's nothing groundbreaking, but this post was just an opportunity to show a little bit of how it works. I also wanted to highlight how game developers can often have different solutions to similar problems, sometimes driven by limitations in the tools they have available to them. The developers working on Super Mario Bros. definitely didn't have the tools for a method like this, but then maybe the world famous question mark blocks ever present to this day wouldn't have ever come to be. I think it's interesting to consider how much these different technical approaches change what comes out.

 

 

Thanks for taking your time to read! If you're interested in the project and want to help support it, the best way to do that is to go to my twitter profile @Jole_says_hi and like + retweet this post! Or of course, to tell someone you know about it. I’d love to hear from you if you have thoughts or questions, too.

Sources: