September 27th, 2024

Guide to implementing 2D platformers (2012)

The guide outlines four methods for implementing 2D platformers, focusing on tile-based systems, their mechanics, and the importance of collision detection, while inviting community feedback for improvement.

Read original articleLink Icon
Guide to implementing 2D platformers (2012)

This guide aims to provide a comprehensive overview of implementing 2D platformers, categorizing various methods along with their strengths and weaknesses. The author identifies four primary implementation types, starting with the simplest, tile-based (pure), where character movement is restricted to tiles, making it suitable for puzzle games but limiting for action-based platformers. The second type, tile-based (smooth), allows for free movement while still using a tilemap for collision detection, making it popular for action games due to its flexibility and ease of implementation. The guide discusses the mechanics of each type, including how character movement is calculated, collision detection, and the handling of slopes and one-way platforms. The author emphasizes the importance of understanding these systems to create engaging gameplay experiences and invites feedback to enhance the guide further. The information is derived from reverse engineering game behaviors rather than direct code analysis, which may lead to discrepancies in the actual implementation.

- The guide categorizes four main methods for implementing 2D platformers.

- Tile-based (pure) systems restrict character movement to tiles, suitable for puzzle games.

- Tile-based (smooth) systems allow for free movement and are favored in action platformers.

- Collision detection and handling of slopes and one-way platforms are crucial for gameplay mechanics.

- The author encourages community feedback to improve the guide's comprehensiveness.

Link Icon 8 comments
By @jonathanyc - 4 months
I like the idea of a guide like this. Reminds me of “Implementation of Hex Grids,” another high quality game-related guide: https://www.redblobgames.com/grids/hexagons/implementation.h... and before that, “Beej’s Guide to Network Programming”: https://beej.us/guide/bgnet/
By @dang - 4 months
Related. Others?

Guide to implementing 2D platformers (2012) - https://news.ycombinator.com/item?id=31450218 - May 2022 (37 comments)

A guide to implementing 2D platformers - https://news.ycombinator.com/item?id=10202275 - Sept 2015 (32 comments)

The guide to implementing 2D platformers - https://news.ycombinator.com/item?id=4065033 - June 2012 (2 comments)

The Guide to Implementing 2D Platformers - https://news.ycombinator.com/item?id=4005883 - May 2012 (2 comments)

By @henning - 4 months
For making the game more fun, you can then add features that are now standard/expected like coyote time. https://www.youtube.com/watch?v=97_jvSPoRDo
By @teddyh - 4 months
> Type #1: Tile-based (pure)

> Character movement is limited to tiles, so you can never stand halfway between two tiles.

[…]

> Examples: Prince of Persia

That is absolutely false. You can stand on any pixel in Prince of Persia. It’s when I find stupid errors like these that I start to question the entire article they appear in.

By @matheusmoreira - 4 months
> I believe that Mega Man actually employs infinite acceleration, that is, you’re either stopped or on full speed

Yeah, acceleration is essentially infinite.

https://tasvideos.org/GameResources/NES/Rockman/Data

When moving horizontally there's very small lag at the start and then he accelerates to full speed pretty much instantly.

When moving vertically by jumping, his speed is straight up set to some constant. There is downwards deceleration by gravity though, leading to "fall faster" tricks:

https://tasvideos.org/GameResources/NES/Rockman#FallingFaste...

By @moth-fuzz - 4 months
I’ve implemented platformer collision dozens of times now and the only way I’ve found it to be genuinely smooth is to do it one pixel at a time, just like the author suggests.

But something always bugs me about that - we know the closest edge of the closest obstacle, we know the vector of the player’s motion, by all accounts we should be able to calculate the point of contact in one go without doing any substeps.

And yet, doing it in one pass always seems to result in a myriad of edge cases (literal!) that break the whole thing, unless you do heavy preprocessing, converting your tiles to a graph of lined surfaces, etc etc.