However they are not without their cons and through experience I posit that a box or cylinder collider, in 2D and 3D respectively, with additional systems is better for serious platforming.

The Problem

Capsule colliders have curves on the feet and head. You can stand on the edge of a ledge and be lower than normal, upsetting any tight movement controls you might have calibrated. If your movement is physics based you will slip off the edge, and jumping into an edge will bounce you in an awkward direction.

Additionally, with a cylinder the character will semi-smoothly glide up each stair, rather than abruptly stepping up which would give the feeling of climbing a staircase. Smoothly stepping may be desirable behaviour but should actually be achieved by modelling the collision for the stairs as a slope, as the capsule will still have some bounce.

The Solution

A box or cylinder collider on the other hand has flat faces on the feet and head. This allows movement to be rigid and exact, but needs extra mechanics implemented to not feel frustrating. It removes the problem of variable heights when dealing with edges in exchange for requiring extra coded systems for step handling, ledge snapping (also called corner correction), and more complex grounded checks when dealing with slopes.

Step Handling

Step handling systems behave by detecting a step in front of the player, and if it is shorter than a variable step height limit, moving the player onto the step - often with a small interpolation so its not too jolting, or game-breakingly quick to ascend a flight of stairs. This allows the level designer to choose whether a staircase should feel like a staircase or like a ramp depending on it’s collision model.

Ledge Snapping

Interlinked with step handling is ledge snapping. This allows a player to move or jump into a ledge’s corner and snap on top of it, giving a variably small tolerance to landing on a ledge. It is similar to step handling but occurs in the air and zeroes the player’s Y velocity.

This also introduces a micro optimisation technique into the game which may be desirable; by jumping precisely at a ledge you can snap to it and reset your Y velocity, reducing airtime which could lead to a small time save. This only really concerns speedrunning but could be desirable in a precision platformer or any platforming game that wants to make speedrunning more interesting.

Sloped Grounded Checks

When standing on a slope with a flat footed collider, the centre of the collider will not be touching the ground. If you were to cast a ray to the ground for a grounded check, it may be too far away and appear as though you should be falling. It may be tempting to address this with collision based grounded checks, but this doesn’t work because as you traverse a slope, with the collider’s sharp corners you will flicker between touching and not touching the slope, making it so that your jump could not trigger or the wrong animation plays.

Instead, have three raycasts. One for the left side, the centre and the right side. If any of them are close enough to the ground, grounded is true. You can have a more robust set of rays if needed, but these 3 should be sufficient in most cases. You may also want to include a max slope angle using the normal of the raycast collision that returns false on a grounded check if the slope is too steep. This turns slopes that are too steep into walls instead of ground. If you still experience flickering because of context-dependent variables, like scale and angles, you can add extra gravity when grounded to push the player into the ground.

I recommend a cylinder collider for 3D so that the character can have the aforementioned benefits of flat feet and head, while being able to smoothly roll over bumpy walls. It also avoids an issue that a box collider has of non-uniform distance to walls at different angles.

Conclusion

The additional systems may seem painful to implement when a capsule collider can cover the scenarios pretty well but the advantage overall of using flat faced colliders in this way is a much tighter control of movement technology and less random-feeling behaviour. For games where tight movement isn’t an important element you can use a capsule collider just fine. But if you are serious about movement, use a box.

This post is a follow-up of the previous post you can check out here: Techniques to Improve 2D platforming

Thanks for reading! I will be posting once a week for the near future so come back soon or subscribe via RSS in the footer.

In this post I will share the techniques I include in my game to subtly improve the game feel of platforming. These techniques are what I consider the minimum for a platforming game where platforming is perhaps secondary to adventure or puzzling. In the end, I will briefly introduce some extra techniques you can use for more platforming-centric games.

The following implementations are extensions of the Godot CharacterController2D Basic Movement Template.

Jump Input Buffering

Jump input buffering allows the player to press their jump action slightly before landing and the jump will still execute. This avoids the frustration of a jump the player thought should work not executing or having to perfectly press jump right when you are grounded in scenarios where you want to jump again as soon as you land, which is extremely common for efficiently traversing platforming scenes.

It works by changing the jump input from the ‘jump’ action to a new ‘jump buffering’ action. The jump buffering action sets a jump boolean to true, and back to false after it times out. During the time it is true, if the player touches the floor the jump action is executed.

Here is my Godot implementation:

@onready var jump_buffer_timer: Timer = %JumpBufferTimer
var is_jump_buffered: bool = false

func _physics_process(delta: float) -> void:
	# Add the gravity.
	if not is_on_floor():
		velocity += get_gravity() * delta

	# Buffer jump.
	if Input.is_action_just_pressed("jump"):
		is_jump_buffered = true
		jump_buffer_timer.start()

	# Handle jump.
	if is_jump_buffered &&  is_on_floor():
		is_jump_buffered = false
		velocity.y = JUMP_VELOCITY

	move_and_slide()

func _on_jump_buffer_timer_timeout() -> void:
	is_jump_buffered = false

Coyote Time

Coyote time, named after Wile E. Coyote, allows the player to still jump for a short time after running off of a ledge. This helps a player make a long jump because they will want to time it to the last possible moment to press jump, which often would result in them unceremoniously falling off of the edge. Coyote time instead extends a grace period during this fall where if the jump action is pressed within it, the jump still goes ahead.

By keeping a boolean value from the last frame of whether you were grounded, and comparing it to the current frame, you can determine if the player just left the ground. If you just left the ground, and you didn’t jump, it starts the coyote timer which sets a coyote boolean to true. Now in the jump action, you check if the player is on the floor or if coyote is true.

In Godot, I implemented it as such:

@onready var coyote_timer: Timer = %CoyoteTimer
var is_coyote: bool = false
var was_grounded: bool = false

func _physics_process(delta: float) -> void:
	...
	# Handle jump.
	if is_jump_buffered && (is_on_floor() or is_coyote):
		is_coyote = false
		is_jump_buffered = false
		velocity.y = JUMP_VELOCITY

	move_and_slide()

	# Handle coyote timer
	if was_grounded && !is_on_floor() && !Input.is_action_just_pressed("jump"):
		is_coyote = true
		coyote_timer.start()

	if is_on_floor():
		is_coyote = false

	was_grounded = is_on_floor()

Note: is_on_floor() is only updated after move_and_slide(), so we need to do the coyote check after move_and_slide() to have an up to date is_on_floor() and before updating was_grounded to know if the character left the floor in the previous frame.

Variable Jump Height

Variable jump height allows for the player to control jump height based on how long they hold the jump button. A short tap results in a small hop, and a full hold results in a max height leap. This is desirable because it gives players control and expression over how they move throughout a scene and let’s them optimise away air time.

Most implementations you will see of this reduce gravity while jump is held. This adds height to the standard jump. I prefer to treat it as a reductive process, and add gravity when jump is released. This allows the developer to implement this without having to reconfigure their standard jump height.

I implement it in Godot like this:

func _physics_process(delta: float) -> void:
	...
	# Halve velocity when jump is released while ascending
	if Input.is_action_just_released("jump") && velocity.y < 0:
		velocity.y = velocity.y / 2
	...

Instead of adding gravity I simply halve the vertical velocity which creates a smooth apex in one operation.

Other Techniques

The techniques above can be incorporated into almost any platformer and feel right. The following techniques are a bit more specialised and may not be suitable for your game. I will introduce the concept and explain why it could be good, but I won’t provide details as to how they work.

Apex hang time - By reducing gravity at the apex of a jump you can create a short hang time which creates a floaty feeling that feels heroic.

Horizontal acceleration - Instead of instantly being at max speed when moving, horizontal velocity ramps up and down following acceleration and deceleration curves. It is recommended to decelerate faster than the acceleration. This gives the movement a feeling of weight while letting it still feel responsive.

Reduced air control - By allowing the player to influence their horizontal velocity less in the air, you make the player be more deliberate about their jumps because they cannot make corrections as easily. This can be taken the other way and allow for more air control to achieve an opposing effect.

Turn acceleration - Detect when the player changes direction and increase acceleration. This creates a snappier horizontal movement.

Ledge snapping - Snap the character’s position to a ledge if they would barely miss. This softens the difficulty a bit and rewards intent rather than execution. This ties into player-centred design which favours the player’s intent over the game’s physics.

Juice

Mechanics is only half the puzzle of game feel. To make a mechanic really feel good, you need ‘Juice’ - or visual and audio feedback.

The principles of animation such as squash and stretch and anticipation will make all of the movements feel more real and impressive by adding a perception of weight and intention to the character.

Visual effects such as dust particles when running, landing or turning quickly can help make motion feel real, readable, and identifiable.

Good sound design goes a long way into making a movement system feel good. A soft jump sound and strong landing sound can help to give a sense of impact and subtly reinforce timing to the player. A subtle footstep loop quietly makes the movements feel real and immersive.

A heavy landing could reverb and cause dust to fall in a cave scene or create a large water spray in a pond scene. How you juice the mechanics is largely dependent on what you are trying to achieve with your game design.

Check out the follow-up post where I discuss collider shapes.

That’s all! Thank you for reading. Follow me on the platforms in the footer so I look cool online and subscribe via RSS if you want to catch the next one.

Auto tiling is a powerful technique in 2D gamedev that allows you to build levels much easier by setting a tile as populated or not, and having the editor programmatically place the corresponding tile.

Typically this involves checking the 8 neighbours and choosing from 16 to ~47-56 Tiles. In theory there are 256 permutations, but you can get away with creating much less. Of course you could create a world with just 1 tile, but we are after painted edges.

This post shows an implementation of a system I discovered from Nonsensical 2D’s video that uses just 5 tiles. The concept is engine-agnostic but part 2 will be turning it into Godot specific tooling.

How it works

The core concept is to separate the tilemap into 2 tilemaps: one for physical tiles with colliders, and one for visuals. By separating the visuals from the physical, we can offset the visuals by -0.5 tiles and paint a tile by it’s corners, as shown below:

This gives each tile 4 neighbouring tiles between the other tilemap or just 16 permutations. We can represent this as a 4-bit mask and map each permutation to a visual placement.

Then for each 4 visual neighbours of a physical tile, we check their physical neighbours to know which permutation to place.

Note: For corners you need to place the visual tile that opposes the occupation representation i.e. if there is a neighbour in the bottom-left, you will need to place the visual tile that occupies the top-right quadrant of the visual tile; for the physical tile it is the bottom-left, but for the visual tile it is the top-right*

Since we are painting visuals by their corners, we can reuse textures to compose other variants by rotating them in editor or in the placement script. This means we only need: a corner, a side, opposing corners, inwards corner, and a full / middle piece - 5 tiles.

From these 5 tiles, we can rotate or flip the tile programmatically, as needed, to create the 16 different tile pieces. I store the 16 pieces in an array which is accessed by index corresponding to the binary value of the bitmask - it is important to setup your array in this order. In Godot, we can create alternative tiles directly in the editor and they are given coordinates in the texture atlas so we can simply store the coordinates. For other implementations, you may want to store the tile atlas coordinate + rotation instructions.

@onready var tileArray: Array[Vector2i] = [ # Encodes 16 tile permutations as a u4 bitmask / index
	Vector2i(4,0), # 0000
	Vector2i(0,3), # 0001 TL
	Vector2i(0,1), # 0010 BL
	Vector2i(2,0), # 0011 BL TL
	Vector2i(0,2), # 0100 TR
	Vector2i(2,3), # 0101 TR TL
	Vector2i(1,0), # 0110 TR BL
	Vector2i(3,2), # 0111 TR BL TL
	Vector2i(0,0), # 1000 BR
	Vector2i(1,1), # 1001 BR TL
	Vector2i(2,4), # 1010 BR BL
	Vector2i(3,0), # 1011 BR BL TL
	Vector2i(2,2), # 1100 BR TR
	Vector2i(3,3), # 1101 BR TR TL
	Vector2i(3,1), # 1110 BR TR BL
	Vector2i(4,0), # 1111 BR TR BL TL
]

Make sure to order your tiles in the binary order corresponding with the bitmask representations of neighbour occupation.

To use the script at runtime we need a method of placing the physical tiles. Bind a mouse input event to get the global mouse position and map it to the tilemap coordinates. We can then set that cell as populated in the physical tilemap layer and call the function to place visual tiles as described above. To erase a tile, bind an opposing mouse event similarly but it should set the cell as unpopulated. We can then update the visual layer by removing the 4 neighbours and calling the visual placement function again.

I recommend to include another function to update all tiles’ visuals. This allows us to place just physical tiles outside of runtime and call the update_all function at runtime to place the visuals for all tiles; I have bound this to a UI button. It works by clearing the visual tilemap, iterating over all populated physical tiles and placing the visuals again.

The next step is to save the level at runtime so that it reflects back in the editor. In the next section, I will describe a Godot-specific implementation of the tooling to do so. You can access the full code for tile placement + level management tooling via my GitHub.

Godot Tooling

I have setup the dual TileMapLayers as so:

WorldMap is simply a container Node. My auto-tiling script is attached to my Physical Tiles layer. Create a separate node for level management and in a new script we can define our level saving logic.

Saving

First, we need to find our WorldMap container Node in the tree and keep a reference to it. We can then do the same for our physical tile layer, and using the physical layer we can do the same for our visual tile layer. We now have 3 references to our container, physical tiles, and visual tiles.

For each of the tilemaps, we need to serialise them and we can store those results in a dict accessed via keys “Physical” or “Visual”. Serialisation works by iterating through all populated cells and appending to an array a dict containing it’s position, source_id, atlas_coords, and alternative_id. If you are adapting this to another engine, substitute alternative_id with your needs such as rotation instructions. To finish serialisation, we can return this array in a dict with a key of the path to the tileset and a value of the array of cells dicts. We model the data this way because every cell in a tilemap layer shares the same tileset, so storing it for every cell would be wasteful.

var data := {
		"physical": _serialize_tilemap(physical),
		"visual": _serialize_tilemap(visual)
	}

Generates data as such:

data =
{
  "physical": {
    "tile_set": "res://Tilesets/physical_tileset.tres",
    "cells": [
      { pos, source_id, atlas_coords, alt },
      { pos, source_id, atlas_coords, alt },
      ...
  ]
  },
  "visual": {
    "tile_set": "res://Tilesets/visual_tileset.tres",
    "cells": [
      { pos, source_id, atlas_coords, alt },
      { pos, source_id, atlas_coords, alt },
      ...
  ]
  }
}

Then save this data. In Godot, runtime data must be saved in user:// rather than res:// because res is read-only during runtime to prevent editor corruption. Attempts to save to res are blocked by Godot. Therefore, we must save the data to user:// and later import the data as real res:// scenes to reflect the changes into the editor.

Importing with EditorPlugin

For a nice developer workflow I have created an EditorInspectorPlugin which adds an import button to the WorldMap inspector. When clicked, it reads the WorldMap data from user://, builds a duplicate WorldMap node with the data, overwrites the scene in res://, and refreshes the editor’s file system which updates the scene. This is a nice solution because the import button lives inside the WorldMap inspector for contextuality and to avoid clutter.

An important caveat is that we cannot load an EditorInspectorPlugin directly from plugin.cfg. Godot requires and EditorPlugin at the top level. However, we can use the EditorPlugin to create the InspectorPlugin.

@tool
extends EditorPlugin

func _enter_tree():
	add_inspector_plugin(
		preload("res://addons/```WorldMap```_importer/world_map_inspector.gd").new()
	)

func _exit_tree():
	remove_inspector_plugin(
		preload("res://addons/```WorldMap```_importer/world_map_inspector.gd").new()
	)

For the InspectorPlugin, the script adds a button which connects to a function which imports the tilemap data, sets the tiles for the two tilemap layers, constructs a new WorldMap PackedScene using it, and saves it over the existing scene before refreshing the file system in the editor. Full code for this can be found on my GitHub.

Relevant resources:

• jess::codes
• Nonsenical 2D
• Oskar Stålberg

That’s all! Thank you for reading my first blog post. Follow me on the platforms in the footer so I look cool online and subscribe via RSS if you want to catch the next one.