Allegro.cc - Online Community

Allegro.cc Forums » Game Design & Concepts » Platformer terrain styles

This thread is locked; no one can reply to it. rss feed Print
 1   2 
Platformer terrain styles
Archon
Member #4,195
January 2004
avatar

Quote:

Which is the preferable method?

I'd go with #2, but don't automatically increment the y values. Instead go left/right, if they are going down, gravity should pull them down, but if they collide with an inclined polygon, do a collision check... If the character is within the polygon, push him up to the top so he isn't anymore.

Mark Oates
Member #1,146
March 2001
avatar

I have struggled with this sloped platform problem for a long time. I firmly believe that nobody will be able to provide you with the solution unless they know exactly what method needs to be used and how to implement it.

here is my feeble attempt:
http://code.markmusicproduction.com/sloped/p1.htm

this also might help:
http://www.harveycartel.org/metanet/tutorials/tutorialA.html

Epsi
Member #5,731
April 2005
avatar

Quote:

I have struggled with this sloped platform problem for a long time. I firmly believe that nobody will be able to provide you with the solution unless they know exactly what method needs to be used and how to implement it.

here is my feeble attempt:
http://code.markmusicproduction.com/sloped/p1.htm

Part 6 is missing and refer to part 5 ???

Anyway, OpenLayer handles the collision between Line and Polygon for you, so you don't have to worry about that, and you can focus on the actual implementation of your idea.

___________________________________

piccolo: "soon all new 2d alegro games will be better. after i finsh my MMRPG. my game will serve as a code reference. so you can understand and grab code from."
piccolo: "just wait until my invetion comes out its going to take the wii to the next leave of game play. it will run sony and microsoft out of busness if i dont let them use it aswell."

Mark Oates
Member #1,146
March 2001
avatar

Quote:

Part 6 is missing and refer to part 5

Yeah, I still haven't finished it... cause I haven't figured out how to do it! >:(>:(
That tutorial above is as far as I have gotten. :P

Unfortunately Openlayer doesn't calculate any reactions to a collisions.

Matt Weir
Member #7,476
July 2006
avatar

Quote:

I'll gladly take it, but I do use Dev-CPP. Who knows, maybe somebody else would want it as well.

Latest OpenLayer SVN compiled for MSVC8

It's just the release build for now, I messed up the debug one and haven't got around to doing it again properly... ::)

Matt.

Elverion
Member #6,239
September 2005
avatar

Quote:

Anyway, OpenLayer handles the collision between Line and Polygon for you, so you don't have to worry about that, and you can focus on the actual implementation of your idea.

Are you suggesting that rather than moving the player to the new coordinates that it might be better off to use OpenLayer's line method to make sure the player doesn't collide? Of course, you would still need check the player against other polygons in the area with the full collision rect that represents that player.

Quote:

I'd go with #2, but don't automatically increment the y values. Instead go left/right, if they are going down, gravity should pull them down, but if they collide with an inclined polygon, do a collision check... If the character is within the polygon, push him up to the top so he isn't anymore.

Yes, that makes sense. Wouldn't a rough check of if a slope is too steep to climb be something along the lines of checking a point up and to the left/right that is 45° from the player? Or, I suppose, you should move the player to the left/right whatever amount, then move them up a max of speed pixels checking for collision. If they still collide after that, then it must be too steep or a wall.

Oh, and thanks for the OpenLayer SVN, Matt Weir.

--
SolarStrike Software - MicroMacro home - Automation software.

Archon
Member #4,195
January 2004
avatar

Quote:

Wouldn't a rough check of if a slope is too steep to climb be something along the lines of checking a point up and to the left/right that is 45° from the player?

Yeah, for that, you could supply a current_position and a current_movement_vector for the map to use.

You should also consider sliding effects (because it'll be a part of your algorithm) - including allowing the player to run up a slope even slightly when he is running fast.

[edit]
I'm actually thinking that you should explicitly flag slopes as 'steady' or 'sliding'...

Epsi
Member #5,731
April 2005
avatar

Quote:

Are you suggesting that rather than moving the player to the new coordinates that it might be better off to use OpenLayer's line method to make sure the player doesn't collide? Of course, you would still need check the player against other polygons in the area with the full collision rect that represents that player.

Just check for a collision with the Collision class from OpenLayer between the player movement segment and the ground polygon. If one occurs, get the colliding segments of the ground polygon (again integrated into OL) and the point of collision.

To adjust the speed of the player against the slope, it's actually quite easy. I don't remember the exact method I've used but you need to take in account the angle of the ground segment.

You can do something like:

newSpeed = actualSpeed - (actualSpeed * factor between -1 and 1)

Where the factor depends from the ground angle angle between -90 and 90
--> factor [ -1 to 1 ]

e.g. coming from the bottom left

slope with this shape "/" is 45 deg (loose speed)
slope with this shape "_" is 0 deg (horiz, no change)
slope with this shape "\" is -45 deg (gain speed)
slope with this shape "|" is 90 (speed = 0)

___________________________________

piccolo: "soon all new 2d alegro games will be better. after i finsh my MMRPG. my game will serve as a code reference. so you can understand and grab code from."
piccolo: "just wait until my invetion comes out its going to take the wii to the next leave of game play. it will run sony and microsoft out of busness if i dont let them use it aswell."

Elverion
Member #6,239
September 2005
avatar

So, you are suggesting the 2nd method I mentioned before in combination with this? That is, not the sin/cos based movement.

--
SolarStrike Software - MicroMacro home - Automation software.

Archon
Member #4,195
January 2004
avatar

Quote:

That is, not the sin/cos based movement.

You'll need sin/cos somewhere. Whether it's calculated when the movement vector changes direction, or when you are updating the picture (using an integer, angle).

 1   2 


Go to: