# How do I set up moving platforms in a 2D side scroller to interact with the player properly?

Edit: I changed the way that gravity was applied so that it is applied even when a player is standing on a block, so instead of the game outputting that you are stepping on a tile as true and false (because if it is true gravity isn't applied, and it is moved out of collision thus in the next frame it does not collide) so now I'll be easier to check if the player is still colliding with a moving tile. I think that I will make a bool that checks if the player was colliding with the tile in the last frame, and if so set the velocities to equal that of the tile plus whatever they are doing (jumping, gravity, walking left and right).

I am trying to create moving tiles such as the ones in basically any platformer. The game is a 2d sidescroller, and the problem that I am running into is handling standing on moving tiles.

The tiles are stored in a vector, but I am unsure how to make it so that the play will have the same y and x velocity as the tile they are standing on, as well as not fall off it.

I was thinking of creating a pointer to the tile they are colliding with on the top (that is standing on it) and setting the velocities to be equal to that plus whatever the player presses (so going left or right or jumping).

However, I am unsure how to check if they collide and how to check if the player had jumped off the tile. I know how to check if the player's collision is at the top using half widths and half heights, but beyond that is a mystery.

I think you are having trouble because you might have confused yourself for world coordinates with camera coordinates.

In a simple 2D game, the player is always in the 0,0 (center) camera view (assume no camera easing), but the world coordinate keeps changing.

When the scene/background/hit-map moves, you can think of it as a camera position offset. However, everything on the map is still the same position relative to the world coordinates.

So when you do hit collision, just use world coordintates. Don't try to do hit collision in camera coordinates, at least not conceptually, and unless it is a mouse click collision test. Or your brain will explode!

And if your chracter changes world position, just apply the character world position offset to the scene's camera view offset.

EDIT: For moving tiles, you can "tag" the character to the tile when he lands, and "de-tag" it when he is in the jumping state. On each animation frame, change the position of the tile by an offset and for each tagged object, change their position by the same offset. Since at the beginning of each frame snapshots are static, just do bounding box collision test like normal.

This "tagging" is that same idea as you would equip a 3D character RPG with armor and weapons.

To handle the case where player simply walks off the edge: while the character is tagged to a tile, check if character x coord is outside or inside tile min and max x-coord to see if it is still on the tile. De-tag or re-tag to another tile as necessary.

imo, we want to make the game run as efficient as possible and do away with unecessary computations. so I would not think the gravity idea is the best. gravity only needs to be applied when character is in mid-air. Can easily use the chracter jump and land events to turn gravity on and off

• I do use world co ordinates. – user975989 Oct 28 '11 at 20:20
• +1, that's a nice way of explaining what I was trying to say in my answer. – Ilmari Karonen Oct 29 '11 at 16:30

Your idea to pass a pointer is the right way. If a collision occurs between two objects pass a pointer to each. Then each object can decide how to alter the properties of the coliding one. Try to differ between objects by attaching a property (like PLAYER, OBSTACLE, POWERUP) to handle collisions with different types in other ways.

For checking collisions the easiest way is to use libraries. At least just look at the docs to get some ideas how to implement collision detection in your own way. For Example http://clanlib.org/wiki/MainDocs:Collision_Detection.

Hahah, this is a pretty common problem, here's what I do->

Step 1: collision detection: Be sure you're separating your map into sections or using quadtrees to speed up grouping,

Step 2: basic collision resolution, my preferred method works great for moving platforms, I always preform this check

if (myPreviousBottom <= theirPreviousTop){ //bottom side collision
//move upwards outside of range of other block
//add their velocity to our position (THIS is what you want to implement)

//I also have a quick method that's overloaded in other classes called_bottom collide()
//and another method of sending events between objects, I send an event notifying
//the other object of the collision here
}
if (myPreviousTop >= theirPreviousBottom){
//simply move our position outside of theirs
}

//CHECK FOR COLLISIONS AGAIN
if (collide(us,them)){

if (myPreviousRight <= theirPreviousLeft) { //we have a right hand collision
//check to see if we should slip by the platform
//move object in question to the position of the other object - our object's size
}

//repeat for left side
}


The important step here is when you have a bottom collision you add the other object's velocity to your position. This allows you to move about freely on their platform and have your own physics unaffected by it's (you may want to, instead, change your axis velocity to theirs and add their other axis's position to the object in question)

There are several ways to deal with this situation. One way is, whenever the player is standing on something (a platform, a monster's back, etc.), to work (conceptually) in a reference frame moving along with whatever the player is standing on. So, as far as the player's movement is considered, the platform they're standing on isn't moving — the rest of the world is.

Of course, this means you need to keep track of what (if anything) the player is standing on. It also means that whenever this changes, e.g. because the player jumps, falls off or steps from a moving platform to a stationary one (or vice versa), you need to change reference frames; depending on your implementation, this typically means e.g. adding the previous platform's velocity to that of the player when they jump off it.

One convenient feature of this method is that you don't need to worry about gravity except when the player is airborne. In fact, you can make jump physics and walking physics as different as you like, which is often useful in games — the approximations that work well for (semi)ballistic motion in mid-air are not the same as those which work when you're in contact with a solid immobile surface.

Conversely, one thing that may be a problem with this approach is if the platform your player is standing on undergoes rapid acceleration. (Think of a spring-loaded platform that launches the player into the air like a catapult.) In that case, you may need to include extra checks to see if the player should fly off or slide along the platform (or fall over, if you model that kind of stuff).

(In principle, the player should be tossed off if the downward acceleration of the platform they're standing on exceeds gravity, and should slide if the sideways acceleration exceeds the total downforce (sum of upward acceleration and gravity) times the coefficient of friction. Of course, many games essentially assume infinite sliding friction and otherwise neglect most effects of horizontal acceleration. In particular, if your platform moves horizontally and suddenly reverses direction, that should cause anyone standing on it to stumble — but I've never seen a game actually do that.)

This can be a bit tedious to do in raw C++. Are you using any libraries, if so what are they?

My personal suggestion would be to use a 2d physics engine called Box2D.

• I am not using any physics libraries, programming it myself to learn about how this kind of stuff works. It's really tedious to be honest, but I feel it's a good learning experience when I'm not banging my head against the wall. – user975989 Oct 28 '11 at 16:11
• What a useless answer... – Ed S. Oct 29 '11 at 0:44