Optimizing Collision Code

As I said in a previous post about my platformer engine (the one I’m working on for Fuzeboy), I’m using Zack Bell‘s code as a base. Recently I started to look into ways to optimize such code without losing the functionality (slopes are a big feature of that simple collision/movement code).

Looks like I was able to gain some speed here…

And as someone once told me “sharing is how better games are made”… so here it is my “improved” version.

Continue reading Optimizing Collision Code

Basic Platformer Mechanics in GameMaker: Studio

I’m fond of platformers. It’s only natural that I spent the past year studying and refining platformer engines for GameMaker: Studio. Here’s what I actually use for my engine.

Fuzeboy early gameplay

Continue reading Basic Platformer Mechanics in GameMaker: Studio

Devlog #1 – GameMaker: Studio new Project

This entry marks the first entry of a new Devlog Series.

I’m currently working on a couple of GameMaker projects and I thought it might be useful to document my development process. I’ve been inspired to do so by reading the Loadworld Devlog PT. 2 by @ZackBellGames

Continue reading Devlog #1 – GameMaker: Studio new Project

Choosing the right resolution for a 2D Platformer

In this post I’ll try to write down the thinking process I made when I chose to develop Kren at a 384×216 sceen resolution.


Everything starts with the tiles. If you make tiles your measurement unit, you’re going to be able to simplify the visualization process. I made this kind of reasoning: how many 16px square tiles do I want displayed vertically?

Can you count the tiles? (hint: it's 15x10)
Can you count the tiles? (hint: it’s 15×10)

I wanted to be able to show at least 10 tiles. Which then I realized was a pretty low number for a Desktop game. That meant having a vertical resolution of 160px. That was the resolution of Metroid Zero Mission, on a Game Boy Advance. Granted, it looked great even on an emulator, on a Desktop PC… but… did I really want to go with that little number of tiles? Let’s look at how others approached the problem…

This is what the player sees on the monitor. Notice the small character and the whole room is in the view.
This is what the player sees on the monitor in Axiom Verge. Notice the small character. Also the whole room is in the view.

Axiom Verge, a more modern desktop platformer, is displaying almost 17 tiles vertically, at a vertical resolution of 270px. So I had to stop and ponder a little. Was it enough? Was it too much?

Too much indeed. Axiom Verge displays gigantic environments around one of the smallest player character I’ve ever seen. The player’s height to screen height ratio is absurd. But it works, for that game.

I wanted to keep a more claustrophobic feeling. Given I didn’t want to mess with tile size, I had to display less tiles. Simply by reducing the resolution.

Aspect Ratio

Metroid Zero Mission has a resolution of 240×160. It’s a 3:2 aspect ratio and it’s not what most computers use today (or even back in the days). In fact the 16:9 aspect ratio is now almost a universal standard. Or at least you can find it in most of the TV sets, desktops and notebooks you see around.

Back to Axiom Verge. It’s 16:9, which is great. But I already chose not to go with a resolution as high as 480×270 because I want less tiles on the screen.

Don’t get me wrong. If you want to be able to display a great number of 16×16 tiles on the screen, 480×270 is a really great option. I would advise you go with that resolution! It’s 1/16th the pixel area of a Full HD monitor. Which means it scales pretty well without pixel interpolation artifacts (you multiply 480 and 270 by 4 and you get the 1920×1080 Full HD resolution).

Next, I looked at the closest 16:9 resolution available with almost the same vertical resolution as the Game Boy Advance: 288×162.

I made a few tests at this resolution and even though I liked it (a lot), it doesn’t scale well. There’s no easy way to scale the 288×162 resolution to perfectly fit a 1920×1080 monitor. That means problems. Also, even though I liked the effect, it really is a little bit ugly. And maybe a little too much claustrophobic, even for my game; there’s barely enough space to fit 10 tiles, vertically. Given my player’s height is a bit more than 2 tiles, it meant huge player (yes, you can draw a different character), really small “field of view” and ugly pixels.

The 384 x 216 Compromise

I finally found the optimal compromise resolution: 384×216. Multiply that by 5 and you get the Full HD resolution. This should avoid pixel interpolation distortions. It also allows me to display 13.5 tiles vertically. This is not that far from the Game Boy Advance look, but it sits nicely between Metroid Zero Mission and Axiom Verge.

Testing the resolution and the view size. Notice the size of the Player and the smaller visible area.
What the hell is this?! (just a fun way to test player size, resolutions and ratios). It gave me familiar elements to gauge my observations.

I don’t want the player to feel small, inside gigantic environments. I want the players to feel the environment around them. Leaving him/her with little air. But not as little as in Metroid ZM on the GBA. All with a modern 16:9 look.

I found my own resolution with this process and a bit of testing. It might not be the best approach (in fact I’m sure I might have missed some other considerations) but for now it’s working great. Your mileage may vary so I recommend a lot of testing.

How I positioned the tileset in my tech demo

In the earlier tech demo, I had positioned a truckload of similar tilesets. Those bluish/greyish square blocks are not hand picked. I did not make that work in the level editor. I got inspired by the Smart Tile Objects tutorial by HeartBeast.

I simply downloaded the Square Blocks Textures from OpenGameArt.org, cut and pasted a bit in Paint.net to adapt it to my needs, and imported the end result as a background in GameMaker Studio.

My background version. Easier to import in GameMaker Studio.
My background version. Easier to import in GameMaker Studio.

I made so that when the floor/wall object (which is invisible) is created, it places random tile from that background into the level. Covering the same surface the object covers.

This makes for a pretty quick and dirty way to test a level with low object counts. Also gives me a little “randomized” effect every time I start the level.

What if I don’t want all that randomness? It’s as easy as using random_set_seed(1)

So, here is the create event of the smart object.

tile_fill_object(id, bg_blocks_16, 16, false)

And here is the tile_fill_object script

///tile_fill_obj(obj, tile, tile_size, randomize_tiles)

var obj         = argument[0]
var tile        = argument[1]
var tile_size   = argument[2]
var rand        = argument[3]

var col_num = background_get_width(tile) div tile_size
var row_num = background_get_height(tile) div tile_size

if !rand

for (var row = 0; row < obj.image_yscale; row += 1)
    for (var col = 0; col < obj.image_xscale; col += 1)
        var col_index = irandom(col_num - 1)
        var row_index = irandom(row_num - 1)

        tile_add(tile, col_index * tile_size, row_index * tile_size, tile_size, tile_size, obj.x + (col * tile_size), obj.y + (row * tile_size), obj.depth)

This is how it looks in the level editor

Level editor with few big Smart Tile Objects
Level editor with few big Smart Tile Objects

While this is how it looks in the game

Same few big smart tiles objects. But with randomized tiles.
Same few big smart tiles objects. But with randomized tiles.