Lets Talk 2D Platformers!

[Ekamu]

I found this really thoughtful article about 2D platformers. Having read through a little I think its time I begin making one myself. I've been swimming in the shallow end long enough and its about time I actually challenge myself with something I've always wanted to do/make.



Here are the steps for a Tiled Smooth platformer, (probably the most popular method of all.)

Assuming that there are no slopes and one-way platforms, the algorithm is straightforward:

1) Decompose movement into X and Y axes, step one at a time. If you’re planning on implementing slopes afterwards, step X first, then Y. Otherwise, the order shouldn’t matter much. Then, for each axis:

2) Get the coordinate of the forward-facing edge, e.g. : If walking left, the x coordinate of left of bounding box. If walking right, x coordinate of right side. If up, y coordinate of top, etc.

3) Figure which lines of tiles the bounding box intersects with – this will give you a minimum and maximum tile value on the OPPOSITE axis. For example, if we’re walking left, perhaps the player intersects with horizontal rows 32, 33 and 34 (that is, tiles with y = 32 * TS, y = 33 * TS, and y = 34 * TS, where TS = tile size).

4) Scan along those lines of tiles and towards the direction of movement until you find the closest static obstacle. Then loop through every moving obstacle, and determine which is the closest obstacle that is actually on your path.

5) The total movement of the player along that direction is then the minimum between the distance to closest obstacle, and the amount that you wanted to move in the first place.

6) Move player to the new position. With this new position, step the other coordinate, if still not done.

(Rodrigo Monteiro)

Read More Here: The Guide to Implementing 2D Platformers

How do you guys go about making your platformers, would you follow these similar steps too or do something else?

As the title suggests lets talk 2d platformers!

Any code examples will be immensely appreciated \(^_^)/

[ivan]

Not bad, but I think the article is a little too general.
For starters, I would advise that you separate your collision code from the rest of your code (rendering/game logic/input etc).
It might be a good idea to look at some of the existing collision libs.
Kikito has a good and simple lib that might give you some ideas.
Or you could check out my short tutorial.
Once you get the collisions down - you'll have to add some form of AI.
The easiest approach is to use finite states.
The player would have to have certain states like "jumping", "running", "standing", "dead", etc.
Enemies in platformer rarely require much AI so you can get away with a lot.
In fact, if you look at most platformers you'll notice that the enemies are usually repeating some simple scripted behavior.
From my experience, a good platformer is determined largely by the quality of the levels themselves.

[Ekamu]

I made my own collision system too some time ago...

grdsys3.love

grid collision

(3.06 KiB) Downloaded 208 times

Collision is still determined by a tilemap, but characters can move freely around the world (typically with 1px resolution, aligned to integers
The character’s collision hitbox is now an Axis-Aligned Bounding Box (AABB, that is, a rectangle that cannot be rotated), and are typically still an integer multiple of tile size.
(Rodrigo Monteiro)

I'm a bit lost on the AABB type collision. You cant just check tiles as I did.

Collision is extremely important for platformers and it can get very complex with physics involved. I tend to use pseudo-physics (fake & simple physics) and not the physics engine which is a "ten-ton hammer designed for heavy-lifting ".

The article itself is just a good mind opener, well at least for me. The real details on making all sorts of platformers could fill an entire book.

[Puzzlem00n]

Most people use pseudo-physics, yeah, it's not that foreign a concept.
I model my platformers after YellowAfterLife's. I've done a few with kikito's bump.lua, and I like his rectangle collision rather than point-based approach, but I ended up somehow preferring the latter.
I'd vote on your poll, but I really don't think any one of them is better than the others, it depends on the game. I mean, Pure Tiles is kinda outdated, but even it can have limited use. I like the variety that bitmask and vectorial give, but when it comes to procedurally-generated games like Spelunky, tiles are just plain easier.
I wrote a badly written explanation of some of the reasoning behind YellowAfterLife's collision methods here, at least in the way I use them. You may read it if you dare.

[micha]

I am working on a platformer. It is fully tile-based and there are no slopes. That makes the collision part relatively easy. Before I started, I read this article, too and it helped me a lot. If you don't have slopes, then the separation of x- and y-axis is the magic ingredient, that makes collision detection/resolution so easy.
(Some preliminary screenshots of my current project are shown on my blog (see signature))

[Inny]

I wrote a short megaman clone called "LBJ Picks Up His Pants" and never finished anything beyond the jumper engine because the joke wasn't funny to me anymore.

Anyway, the thing I learned from while writing the code was to separate your velocity vector into scalars, and apply them separately. Meaning that you move the entities to the right or left first, and check every possible vertical wall of collision, then you apply the up or down movement and test against floors or ceilings. The value in doing it this way is that you don't have to special-case the entire collision detection system for what should be standard motions. Motion along a floor has nothing to do with bumping into a wall, and if the player isn't jumping, then the only work the engine is doing for the vertical components is to see if the floor isn't below them anymore.

[CRxTRDude]

This can also be a helpful too.

I am also making a platformer: <insert James Bond theme> cinematic ACTION platformer (I emphasized the action there as cinematic platformers are as they would have say like an interactive movie (or PxC adventure games, only with more freedom)) and i'm using bounding boxes with ATL, so you can say it's tile-based.

From my experience, a good platformer is determined largely by the quality of the levels themselves.

True. Some platformers have simple yet resourcefully ingenious designs, some complex. It depends on what you want for your really, as long as the levels are spot-on fun and challenging ...

[Ekamu]

Code: Select all

 I learned from while writing the code was to separate your velocity vector into scalars, and apply them separately.

Thanks for the tip Inny, I have my x and y velocity separate now and it works well. Personally for anything tile-based I avoid using dt or I math.floor the final number to keep things tight. Pixels also behave very strangely in between floating point positions.

Its funny though, I always though sonic was vectorial until now because of all the loops and advanced physics.

How do you get the player to jump though? (<_<) I have most everything setup already but that.

[CRxTRDude]

Well, a lot of jumps involve, one way or another, vertical velocity and interpolating that to your y coords.

Oh yeah, I also contribute another resoucrce ... Te bulk of what I've been making was derived from YouTube tutorials, but when I scoured the internets for more, I found the video's TRUE source...

LÖVE Tutorials as said in the forum text, but actually is a tutorial to make platformers until entity creation. It uses ATL, so it's tile-based. i don't know if it can be used to make tile-smooth... I did found AdvTiledCollider (forgot the link, but it's in the forums) but I stuck with the explodingrabbit version.

[Inny]

Personally for anything tile-based I avoid using dt or I math.floor the final number to keep things tight.

I remember there being a really big and good thread on this forum about Verlet Integration, and this might be it, but it's been long enough that I may be wrong. However, using dt in a jumper is perfectly fine, so long as you apply the delta in the middle of the integration, rather than at the front or back. What that means is that typically we'd quantize the motion vectors like so:

• Apply Vertical velocity to entity.
• Decrease Vertical velocity by the Gravity Acceleration constant.

This leads to the case where swings in dt can affect the height of the player's jump, such as the Quake 3 Arena unfair advantage that players with better hardware got.

The better way to do it goes like that:

• Decrease Vertical velocity by half of the Gravity Acceleration constant.
• Applythe Vertical velocity to entity.
• Decrease Vertical velocity by the other half of the Gravity Acceleration constant.

The code for that looks something like this:

Code: Select all

    dy = dy + gravity * (dt * 0.5)
    y = y + dy*dt
    dy = dy + gravity * (dt * 0.5)

From that thread, Kikito provided this link, and it's worth reading: http://www.niksula.hut.fi/~hkankaan/Hom ... avity.html