I'm currently trying to create a 2D platformer puzzle game like Mario vs. Donkey Kong: Mini-land Mayhem! within Flash. My issues reside in the bridge collision with the walking AI.

The game allows the player to create a bridge from one end point to another at any angle. Then the player's AI mummies (in this case) walk across the bridge to reach another platform.

Now, seeing that the bridge can be constructed at any angle, I'm only going to have a rotated rectangle to represent the body of it.I obviously can't use the typical AABB to check collision against this, instead it looks like I'm going to need to do a SAT or pixel perfect check.

The AI mummy must always stick to the platform or bridge as it walks across it (not to mention rotate to the bridge's angle). Therefore, I suppose I'm going to need some gravity and sliding collision? The walking speed should also be the same on both the platform and bridge.

Lastly, since I'm using a grid for my platform tiles (including the end points) connecting a bridge to them isn't going to be perfect. Going up and down the bridge may need some offsetting with floor in order to make a smooth transition from or two the bridge.

An example

Some things I have tried in the past week or two:

  1. Using SAT collision with rotated rectangular bodies on the mummy and the bridge. I tried having the mummy walk up the bridge by adding 3 mini-hitboxes on the bottom-left, bottom-mid, and bottom-right to him. I had a hard time trying to get this to look right and trying to stick all of the hitboxes onto the bridge and the floor (especially when I rotated the mummy to that of the bridge).
  2. Using Box2D Flash port library. Just doing something simple as this is seeming like an uphill battle with this physics engine. It looks as if it will be troublesome to get a predictable movement with a constant speed especially when going up the bridge. I've tried their 'conveyor' example, but for some reason, the classes that were used for it are missing in the Flash port. I've also tried disabling the physics and just using it for collision detection, however I dislike it entirely. I also don't receive any contact information for collision on the sensors (like distance, normal, point of collision, etc.). I'm better off with using my own SAT implementation for this task.
  3. I've also tried placing nodes above each end point and when a bridge is connected, the mummy will know to go from one node to the other when he collides with the starting node itself. This has drawbacks of needing to offset the nodes perfectly so the mummy's feet will always be on the bridge, so I'd have to make sure to never change the size of the character and the bridge. Also, I'd need two nodes per end point, since going down and up a bridge will need different offsets.

It feels as though a fully fledged physics engine just doesn't feel right for this game. It would handle a lot of my current problems, but it will be introducing more at the same time. If I want a smooth walking transition from the platform to the bridge, it seems as it's the only choice.

Now my question is how would you guys go about having the mummies walk up and down a bridge smoothly at a constant speed and angle? Just use a physics engine? Create your own physics? Or trying raycasts?



2 Answers 2


You should set up four points on each side of the enemy's/player's feet. Two represent the range in which the feet should make contact with the ground. The other two represent the range walk-able slope.

This is a picture representing an enemy moving right, represented by a box, with each of the points mentioned drawn.

visualization of collisions

The fist picture is how it should be, with the bottom two points under the ground and the top two points above the ground. There is no need to change altitude.

In the second picture, only the top point isn't colliding with the ground, so it must slope upward. In the code, you would then adjust the enemy's y-location pixel-by-pixel until the second-to-top point no longer collides.

In the third picture, only one point collides, so you must adjust the y-location pixel-by-pixel downward until the second lowest point collides.

You would use these points only when the enemy moves right. If he moves left, check points set up the same way but on the left side of the bounding box.

There are two other cases that can happen. In one, no point collides, which means the enemy is hanging over the edge of a cliff. In the other, every point collides, meaning the enemy is walking straight into a wall. You can use additional code under these special circumstances.

  • \$\begingroup\$ When the sprite moves up or down the slope I would like to rotate it as the same angle of the slope. Is this something I should only do to the sprite itself and keep the collision box unrotated (as above)? \$\endgroup\$
    – crjenkins
    Mar 5, 2012 at 23:57
  • \$\begingroup\$ Yes, you should leave the collision box where it is. You could calculate the angle needed to rotate based on how many times it needs to loop to adjust the height. The more pixels it needs to change in elevation, the more extreme the slope must be, and the more rotated the sprite should be. \$\endgroup\$
    – tyjkenn
    Mar 6, 2012 at 1:44

I guess I would implement almost the same method as your 3rd, create some lines representing platforms and bridges. but the offset is no big deal, checking distance between a line and a point is really easy to calculate(just check the wiki page).

  • for each frame
  • move the object with constant speed in the same direction as the line
  • check if it's distance to bridges is less than bridge width
    1. if it's near enough change the line mummy is walking on
    2. if not do not do anything

this is a simple enough algorithm to implement. note that each line is represented by two points. which are head and tail of the line. you can also calculate normal value for that vector, and rotate the character to that angle.

  • \$\begingroup\$ I'll try this out, thank you for your great explanation. \$\endgroup\$
    – crjenkins
    Mar 5, 2012 at 0:35

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .