urgh.. I kind of hate having to post this, with all the custom movement and slope examples going around at the moment but I'm just lost. I just don't understand how slopes work with fastlooped platform movements.
This is really bare, just working on the movement. Nothing fancy. At this point not interested in wall-jumps and crazy things like that. What's my actual problem? I worked this up from an example I found in that massive tutorial pack recently posted, and the movement worked really well without needing like 6 detectors so I used it. The problem is that I looked at several more custom movements and how their slopes were coded and the engines worked differently and didn't seem to be able to be incorporated into my engine
Not necessarily asking for someone to go ahead and do the whole thing for me, but point me in the direction of understanding how I can code the slopes into the engine. I've gone through the code I have now and I understand all of that, I understand how the basic movement functions, but I'm not sure where to go from here, do I need a new detector or several to detect slopes? It's the tricky thing because your floor detector will be touching a slope so how can you tell if you are on a slope or just a surface
You don't need to tell if you are on a "slope" or a "surface".
Just reposition the character and let gravity work its magic.
You will of course, need to re-design some aspects of your platformer engine to regain the smoothness once this is implemented. (everything from the way the animations work to how jumping works) You'll see what I mean when you add it in.
Just make a new code group and put the following in it:
Player is overlapping background
Repeat while Joystick moved right ----> Set Y pos to Y(player) - 7
(Negate X) Player is overlapping background
Repeat while Joystick moved right ----> Set Y pos to Y(player) + 3
Player is overlapping background
Repeat while Joystick moved left ----> Set Y pos to Y(player) - 7
(Negate X) Player is overlapping background
Repeat while Joystick moved left ----> Set Y pos to Y(player) + 3
Blood of the Ancient One, Seen only as Shadow, Faster than Lightning, Fierce as the Greatest Dragon, Nearly Invisible, Floating in a Dream, Entered through the Demon Door, Destroyer of Evil in a Realm with a Red Sky Scarred, Who could I be ?
It looks like you need a way to tell the difference between a slope and a wall. By the looks of things anything that is one pixel more than totally flat is considered a wall at the moment.
I'm no coding genius so i had to use 4 detectors for slopes for
walking left up a slope
walking right up a slope
walking left down a slope
walking right down a slope
since you're using loops for walking you'll also need to only use your normal walking loops when on flat ground and make new loops for the four other directions.
This was pretty fun and simple for me to solve, but OMC and AndyUK are quite right.
I've made this nice little fix but it is a tiny bit jumpy and it will become a even more jumpy past 1 pixel difference.
If you expect anything better than this then you will need to add a few active objects as slopes/detectors or make use of some other method besides obstacle backgrounds, like importing graphics or active picture objects or something.
Blood of the Ancient One, Seen only as Shadow, Faster than Lightning, Fierce as the Greatest Dragon, Nearly Invisible, Floating in a Dream, Entered through the Demon Door, Destroyer of Evil in a Realm with a Red Sky Scarred, Who could I be ?
Originally Posted by jthongbai I understand how the basic movement functions, but I'm not sure where to go from here, do I need a new detector or several to detect slopes? It's the tricky thing because your floor detector will be touching a slope so how can you tell if you are on a slope or just a surface
Slopes, in my opinion, are the hardest part of building a custom platform movement. I've downloaded A LOT of examples of CPM engines and the one thing that I've learned is that there are a variety of ways to accomplish sloping movement in your CPM engine.
Rather than explain the method I use (because it sounds like you want to code this for yourself) let me discuss the scenarios that you'll need to consider. Hopefully this will help you decide for yourself how you'd like to develop the logic for your slope movement. I know you'd like to reduce the required number of detectors - so, just think about what you'll need in these scenarios.
First, as AndyUK mentioned, there are really TWO scenarios for slopes:
Moving UP a slope
Moving DOWN a slope
Since you have to consider the direction a player is moving (RIGHT or LEFT), this doubles the scenarios:
Moving UP a slope (Moving to the RIGHT)
Moving DOWN a slope (Moving to the RIGHT)
Moving UP a slope (Moving to the LEFT)
Moving DOWN a slope (Moving to the LEFT)
For now, let's simply consider moving to the RIGHT and what that means for UP and DOWN movement. I'll show each movement in four figures.
Moving UP a slope
Figure 1
In this figure, the sprite is moving to the right and is not yet touching the slope.
Figure 2
In this figure, the sprite is now next to the slope. In a platform engine without slope movement, that 1-pixel height slope would be considered a wall and the sprite would not be allowed to move to the right anymore. However, since we are building slope movement, there has to be some way to differentiate a wall from a slope. That is usually done by the height of the object next to the sprite.
Figure 3
In this figure, the sprite has been allowed to move over the top of the slope. This is usually handled within a fastloop and is never displayed on the screen. When this event occurs, the sprite will need to be "raised" out of the floor (as seen in the next figure).
Figure 4
In this figure, the sprite has been raised out of the floor and is now resting on top of the floor. This would typically be the end of the fastloop.
Moving DOWN a slope
Figure 5
In this figure, the sprite is approaching a downward slope. The sprite is currently moving along a smooth surface.
Figure 6
In this figure, the sprite is at the very end of the surface but still 1 pixel over the surface. The next frame will take them over the edge. In a platform engine without slope movement, that next frame (Figure 3) would send the sprite into a "Falling" animation.
Figure 7
In this figure, the sprite is now not in contact with the floor. In a platform engine without slope movement, the sprite would now be in a falling animation and gain downward movement from some sort of "gravity" logic. This is not what you want to do a CPM engine with slope movement (which would lead to the "jumpy" feeling that OMC mentioned). You want to detect the slope undernearth the sprite and move the sprite down to the slope below. If the slope movement is handled by a fastloop, this condition may not be displayed on screen and the fastloop might end with figure 4.
Figure 8
In this figure, the sprite has been moved downward and the sprite is now resting solidly on the slope - ready to continue the RIGHTWARD movement.
Other considerations
You're slope movement must consider the alternates for the above Figure 3 and Figure 7. First when RIGHTWARD, the sprite must know the difference between the slope and a Wall. Compare the above Figure 3 to this Figure:
Figure 9
Secondly, when RIGHTWARD, the sprite must know the difference between a slope and a dropoff. Compare the above Figure 7 to this Figure:
Figure 10
Again, there are NUMEROUS ways to handle slope movement. You can check my CPM engine for how I resolved these issues. If you'd like other examples, I can dig up a few and try to post them.
Repost all of that in an article and then show different methods of accomplishing it.
That's really good info that needs to be kept somewhere other than the forum.
Ummm .. yea .. just take a look at my little fix. I'm sure he'll be quite happy with it.
I thought they were talking about how you can see the platforms sort of flex up and down by one pixel because of the way it would need to be designed (what I did) to not have to use anything other than backdrops. That's really the only "jumpy" thing.
Walking down slopes by using gravity needs nothing more than an animation fix (look where it says MBK altered this) in the code of his that I added to.
Simple stuff really.
You can also hard code it with x and y of specific location throughout the levels where slopes are, but that's alot of repetitive code if you have alot of slopes. The up side is that you wouldn't need to use an active and you also wouldn't need to consider animation tweaks, but the downside is obvious (you'd need to put in code for every place a slope is to be).
Edit: LoL Jess, I always get yelled at for posting stuff in the article section that doesn't look like articles to people, and now you're getting yelled at for posting article material outside of the article section! .. LOL!
UrbanMonk has a point though, it'd make a great article if you don't already have it there.
Blood of the Ancient One, Seen only as Shadow, Faster than Lightning, Fierce as the Greatest Dragon, Nearly Invisible, Floating in a Dream, Entered through the Demon Door, Destroyer of Evil in a Realm with a Red Sky Scarred, Who could I be ?
Originally Posted by MBK Walking down slopes by using gravity needs nothing more than an animation fix (look where it says MBK altered this) in the code of his that I added to.
Detecting a DOWNWARD slope is important when your sprite can change movement speeds (i.e. Walking and Running). This can be seen in some platform games such as the Mario series. In the Mario series, holding down a button will allow Mario to gain speed until he is running. Mario's running is reflected in two ways: the animation loop gets faster and, when at top speed, his animation sequence changes so that his arms are outstretched (as if he might fly away).
If you do not detect the DOWNWARD slope, the sprite will be subject to "gravity" logic and will fall. Whether or not the sprite changes to a falling animation or not, the sprite will still fall and this presents several issues. The primary issue is that if the sprite is falling (and not in contact with the ground) then it will not be permitted to gain speed from a walk to a run. Typically, only when the sprite is in contact with the ground should it be allowed to gain speed from a walk to a run. Otherwise, the sprite could accellerate in mid air - which would lead to an unnatural set of physics (that is, as if double jumping weren't strange enough).
Yeah, also you usually can't jump in mid air (I guess it depends on the engine though) if there is no double jump you'll just be unable to jump whilst running downhill besides the rare occasion you just so happen to press jump whilst touching the floor.
Typically, only when the sprite is in contact with the ground should it be allowed to gain speed from a walk to a run. Otherwise, the sprite could accellerate in mid air - which would lead to an unnatural set of physics (that is, as if double jumping weren't strange enough).
You are thinking in black and white, but I am thinking of the grey areas as well.
Don't say it shouldn't do that in the air, but instead say to what extent should it do that in the air to also keep the physics intact.
Have you guys looked at the fix yet? The only troubles will be if you want slopes higher than just one pixel, which means that you also can't have convex slopes, although you could still have concave ones if you wanted.
I'd imagine that you can still add running, you'd just need to tweak it a little bit to consider the difference between running and walking.
Here is what I added for jthongbai. You'll want to take a look if you haven't yet:
Blood of the Ancient One, Seen only as Shadow, Faster than Lightning, Fierce as the Greatest Dragon, Nearly Invisible, Floating in a Dream, Entered through the Demon Door, Destroyer of Evil in a Realm with a Red Sky Scarred, Who could I be ?
Originally Posted by AndyUK Yeah, also you usually can't jump in mid air (I guess it depends on the engine though) if there is no double jump you'll just be unable to jump whilst running downhill besides the rare occasion you just so happen to press jump whilst touching the floor.
Exactly! If half the time you WALK down a slope you are actually FALLING - then you typically won't be able to JUMP during the falling periods.
Originally Posted by MBK You are thinking in black and white, but I am thinking of the grey areas as well.
Don't say it shouldn't do that in the air, but instead say to what extent should it do that in the air to also keep the physics intact.
I think for the most part the physics, in the majority of these games, are pretty strange.
In Mario you can change direction in mid-air, double jump, jump five times your height, etc. Real physics are certainly not the goal - fun gameplay is the goal. However, accellerating to a run speed in mid-air is not allowed (in Mario games). For that accelleration, you must be in contact with the ground.
That said, you can make your physics do anything you want. I think as long as it is "fun" - there are no rules. I'm just providing an example of where it would be necessary to detect a downward slope.
Originally Posted by MBK Have you guys looked at the fix yet? The only troubles will be if you want slopes higher than just one pixel, which means that you also can't have convex slopes, although you could still have concave ones if you wanted.
I'd imagine that you can still add running, you'd just need to tweak it a little bit to consider the difference between running and walking.
Here is what I added for jthongbai. You'll want to take a look if you haven't yet:
It's a good example, MBK. You've definitely done a good job with the slope. However, it does have a problem in that occasionally you can't JUMP going DOWNWARD on a slope. Try this, stand at the top of the slope and then tap direction key (to WALK) and then the JUMP key. Half the time the sprite won't jump - I'm guessing because it is submerged in the floor. You could probably fix that with a few checks.
It's a good example, MBK. You've definitely done a good job with the slope. However, it does have a problem in that occasionally you can't JUMP going DOWNWARD on a slope. Try this, stand at the top of the slope and then tap direction key (to WALK) and then the JUMP key. Half the time the sprite won't jump - I'm guessing because it is submerged in the floor. You could probably fix that with a few checks.
Hmm .. yea .. I see what you're saying. Now I'm in the Black and White ... Have any Grey thoughts on the matter?
What checks can I do to make it always jump on the slope? Right now it apparently won't jump unless you have right or left held in.
Edit: It works ok if you hold the jump key in when going down slopes, but it feels a bit sticky. If this can be sorted out though, it'd be a good fix though right? ... This is my first attempt at slopes btw, and I almost helped someone. I had planned on messing with them sooner but got sidetracked with that spread value annoyance. GamesterXIII found out what was wrong btw. Apparently some of the check options needed to be set differently so stuff wouldn't appear and follow the screen.
Blood of the Ancient One, Seen only as Shadow, Faster than Lightning, Fierce as the Greatest Dragon, Nearly Invisible, Floating in a Dream, Entered through the Demon Door, Destroyer of Evil in a Realm with a Red Sky Scarred, Who could I be ?
Great discussion, I still haven't returned home but I will be back in approximately 12 hours or so, so I can't wait to play around with the engine and check out the examples/apply some of the theory provided.
Addition of two detectors for left and right wall collisions, they sit one pixel higher to allow for 1 pixel gradient slopes. Works fine.
Addition of two 1x1 pixel detectors for left and right slopes.
What's wrong? The going upward slopes I figured out easily thanks to all of your help. My problem now is downward slopes. I know all I need to do is catch the player in the right position and just move him down 1 pixel so it never thinks it's falling on a slope.. but it's still jumpy I am guessing because of detector sizes/positions. I checked Jess Bowers CPM and I see that yes I am correct in that all I have to do action-wise is move the player 1 pixel down. My bane is detecting it correctly.
Will I really need to add another 2 or 4 detectors to be able to conquer moving down a slope?
Thanks again for all your excellent help and input.
you do need something that checks the ground below the player for downward slopes. Your two current slope detectors are above the ground so they wont work.
You don't need to create more detectors though.
You can just make a new animation or direction that has the two current detectors a pixel lower and only then check for downward slopes.
Originally Posted by AndyUK you do need something that checks the ground below the player for downward slopes. Your two current slope detectors are above the ground so they wont work.
You don't need to create more detectors though.
You can just make a new animation or direction that has the two current detectors a pixel lower and only then check for downward slopes.
Does this mean that the slope detectors would be constantly looping an animation where the pixel moves up and down to "feel" for either the upwards or downwards slope?
I'll have to check this out when I go home today.
I might try changing the animation to check for upward or downwards slopes on loop indexes being even (check up slope) or uneven (check down slope), this is probably fast enough to cycle so that I can check both without missing detection of either..
Originally Posted by Jon C-B Hey MBK, is it ok if I use your engine in a game of mine? I'll give you credit.
Yes, you can use anything of mine freely unless I state otherwise in the event editor (all my projects are opensource so far). It would be kind of you to give me a credit and I'll thank you kindly for doing so.
BUT if you are speaking of this slopes thing, this is mostly jthongbai's work and you'll need to ask him, as I only added to it.
If you are speaking of my 2.5d platform engine, however, well I would like very much for all klikers to feel free to use that to make games with, as I want to see more 2.5d beat-em-up styled games and new/interesting styles of games on TDC, and while it is not technically needed, a credit does go a long way when it comes to making one feel appreciated.
Blood of the Ancient One, Seen only as Shadow, Faster than Lightning, Fierce as the Greatest Dragon, Nearly Invisible, Floating in a Dream, Entered through the Demon Door, Destroyer of Evil in a Realm with a Red Sky Scarred, Who could I be ?
I am fine with allowing people to use code I've posted here, just not any graphics.
Though, the code is not too functional anyway so I assume he means your work MBK
I've run into a bug ... again.
This is really strange, I have downward slope movement working perfect now, viewing animation shows me that the fastloop detection is working perfect and it never thinks it is falling now. But now upwards won't work correctly, and I have no idea why as the events should not be clashing at all. I have my original events and yet, I cannot begin an ascent up a slope. But sometimes I can move up again while mid-slope if I am currently moving down.
Also, viewing animation of the sprite shows me that he thinks he's falling as he goes up (if you can manage to make him move upwards a slope).
You can probably imagine my frustration now, since at first there was no sloping, then it was working somewhat, then no downwards slope, now descending slopes is perfect and going up doesn't work properly at all
I've made several attempts to detect the upwards slopes at the right point and move him up 1 pixel but it seems he's never in the right spot to jump. I repeat, downwards slope movement works perfect and you can jump while doing so. But upwards has just gone haywire.
(Side note on graphics: a) don't use them and b) I know it's strange but when I get this sloping working perfectly the character will rest lower on the tiles because it's a slight perspective, not dead on side view)
Advertisement
Post Reply
Moving UP a slope
Edited by MBK
Addition of two detectors for left and right wall collisions, they sit one pixel higher to allow for 1 pixel gradient slopes. Works fine.
