Need help in 2D Platform Game Physics

Started by
4 comments, last by bglanzer 12 years ago
Hello, i am trying to write a simple 2D Platform Game but having trouble implementing simple platform physics.
Unfortunatly i dont have any experience in game programming or game math and i dont understand complex formulas.

What i have so far, is a player with a position rectangle a velocity vector and a list of platform objects.
I can freely move the player by controls and i have done some simple collision detection.

This is achieved by increasing the position by the velocity * (speed * frametime) and works for non platform games.
In case of a collision, the velocity is set to zero, but this has a bad side effect for platform physics which does not allow any movement on a platform where the player already collides.

I think the the player should always be pushed down by gravity until he hits a platform (falling), but should be able to move in X axis and can collide with other objects or platforms as well.

It would be really great if you can give me some advice how i can do this.

Thanks,
Final
Advertisement
Do X motion and Y motion in separate steps, so stopping X from hitting a wall doesn't stop you from falling, and stopping Y motion from the ground doesn't stop you from walking :)

Do X motion and Y motion in separate steps, so stopping X from hitting a wall doesn't stop you from falling, and stopping Y motion from the ground doesn't stop you from walking smile.png


This i do already, but i am having trouble determine which tile i need to check for collision.
For the moment i want to detect the tile beneath me, detect collision with the players bottom rect and set vely to 0 and set also y to foundtile y - player height.

How is this done?
Sounds like you've got the right idea. It's easier if you limit velocity to 1 tile per frame. That way, you only have to check if you're changing tiles... not worrying about exactly how far you're moving. X motion might look something like this, assuming spriteX and spriteY refer to the left and top of the sprite's collision box, and that the collision box is "exclusive", i.e. if tile size is 16x16, a collision box that is 16x16 pixels can fit into a 1 tile space (this is why I use collisionBoxWidth - 1 when calculating the right edge).

This is untested, but simple enough that I'd be very disappointed in myself if there are any errors tongue.png

[source]if (velX > 0)
newTileX = (spriteX + velX + collisionBoxWidth - 1) / tileSize; // checking with right edge of moved rectangle
else
newTileX = (spriteX + velX) / tileSize; // checking with left edge of moved rectangle

if (newTileX != spriteX / tileSize) // see if we actually moved into a new tile
{
// loop over the height of the sprite, to see if any part of the box will hit a solid tile at the new X position
const int bottomTileY = (spriteY + collisionBoxHeight - 1) / tileSize;
for (int tileY = spriteY / tileSize; tileY <= bottomTileY; tileY++)
{
if (collisionMap[tileY][newTileX]) // maybe should do bounds checking here, if sprites can ever move outside the map edges
{
// shorten velocity to stop at wall
if (velX > 0)
velX = newTileX * tileSize - collisionBoxWidth - spriteX; // move right edge to the wall
else
velX = -(spriteX % tileSize); // move to the left edge of the tile you started in
break; // no sense continuing the loop since finding another solid tile would just set the velocity the same again
}
}
}[/source]
I suppose my approach is rather fundamentally different, but perhaps it may be of use for comparison:

In my engine, the stage is not "tiled", and therefore objects can be of arbitrary rectangular dimensions (technically it can handle non rects too, but that is a lot more complicated in practice). The stage itself is divided into a relatively fine-grained set of cells. Each cell contains info for each object that overlaps it, thus to find a collision in a given area you check the cells one object is occupying. Info for any other objects implies a collision.

For my player object, I actually do four different collision detections... I basically define four subrects for the top, bottom, left, and right sides. That way I know exactly from what direction an impact came and I can make any physics adjustments I need to (ie: impact on the bottom means null out y velocity, but leave x velocity as it was -- though I also apply a little friction when you are on a solid surface so you don't just slide on forever). This approach can also be easily expanded to include other major types of attribues (ie: whether other objects in the area can be interacted with, whether they can be seen, etc).
There was a saying we had in college: Those who walk into the engineering building are never quite the same when they walk out.
You should test where the collision occurred on your rectangle objects. If the collision occurred at the top of a rectangle then the player was falling down on it, set the players y velocity to zero, move the player to the top bounds of the rectangle, and account for any friction. If the collision occurred on the left or right of the rectangle then set the x velocity to 0 and move the player outside the bounds of the rectangle depending on which side the collision occurred on. Ifs its from the bottom set the y velocity to zero and move the player to the bottom bounds of the rectangle.

If your player will be moving faster than the dimensions of the box make sure to test if the player might have moved completely through a rectangle.

Brendon Glanzer

This topic is closed to new replies.

Advertisement