Could the problem be that the stairs are also not made with the speed your character has to move in mind? I think that the only way we will get natural stair movement is when we lock characters to the stairs and use an IK and root motion setup that calculates where you can put your feet. Maybe faster characters could go up 2 or 3 steps at once.
The current character movement actually allows for the character to snap up multiple steps at once! I didn’t talk about it in the video since it’s a bit complex but the code actually does two checks. One at the collision point and one at the max step up height. If they are moving fast enough to skip a step the collider will walk up multiple steps at once. But since it runs at 60 updates per second the character usually only moves a fraction of a step. That IK addition and running of root motion would be a great enhancement and hopefully I’ll add it to the project at some point in the future.
Yeah, climbing stairs generally involves a different shifting of the body weight and impulse on the feet and legs than running on flat ground, but that would be an entirely different can of worms to discuss, I think
Yeah, the problem is it depends what sort of game you're playing. Fully realistic stair climbing, isn't always possible due to scale, speed and just generally because filthy normies don't appreciate stair simulator 2023.
There's always a tradeoff between perfect visuals and effort. For a game, faking it is enough. It just has to be good enough to not trigger a "something looks wrong" response in the player's head. However, if we wanted it to be perfect, then we'd need to translate every single step the character takes into an actual step. So we would need to calculate the intended step distance, then find a good landing position for the foot that takes into account obstructions in the movement path for the leg and body, and then execute that movement. But this opens a new can of worms. The player inputs are not precise enough to determine exactly what the player wants their character to do; we only have a 2D vector (i.e. direction on a plane and speed). And even if the character is on a perfectly flat plane, if the player input changes to "speed=0" in the middle of a step, when the character is unbalanced and needs to end the step to not fall over (or even more steps when running), this now has added a considerable input delay. Before spending effort on something like that, there are better mechanisms that could use some love. For example, transforming the player's direction input to align with the terrain. Walking along any structure (straight/curved road/stairs) can be quite annoying as you have to mimic that structure with your controller or mouse input. Even a slight nudge to the character rotation can help tremendously here. If it is implemented well enough, you can get away with a nudge that's big enough that a character can walk up a spiral staircase centre of the steps with the player only pressing forward.
When I was a kid, I would be really impressed or fascinated with how in the original Wind Waker on gamecube, Link's feet would stand on and set up each stair individually. You could stand on the stairs and one foot will be on the next step and one on the lower step. It always looked so smooth.
I must've always had being a game designer in mind because I did love that but then as soon as I saw that I thought "what would happen if it's exactly between two stairs?". I then made link's leg bounce up and down because it wasn't sure which step it should be on
Yeah me too. When the game was just released and I bought it , I was also into programming games a lot, so I also deeply wondered how this was coded back then.
In KH2 there's a funny IK bug on stairs where you can actually angle Sora in a way that both feet think they're the "elevated" foot. So Sora would just do a blank squat. 😂 Same goes for Witcher 3, there's a boat east of Oxenfurt where you can angle Geralt enough to make him "squat stand" as well. It honestly became a habit of mine to just try this in every thirdperson game I play. 😅
Stairs used to be this thing I would not notice in games until GTA IV. I still remember when I first played and Niko started stepping on each step and jumping some if running, it was insane.
My experience with stairs in GTA IV was Niko suddenly being forced into position to climb them. It was the same with ladders. It's pretty disturbing when the game suddenly takes over your character without any warning, you start to panic thinking that your controller might be broken. XD
For years all I've ever wanted was to have my player model in any game actually have their feet match on each step as they go up the stairs, rather than stand on one and slide up a few. A few games have done it but its made the stairs feel more likie a cutscene than being actually fluid with character movement, and I've always wondered that surely it wouldn't be that hard to do. After seeing how much work actually just goes into regular ol stairs I finally understand why it must be so hard for that kind of coding jesus. Thanks for making this vid, it was super informative I greatly appreciate you putting in the time to make it
It's very common to think that you want something in a video game, but when you finally get it, it just feels like it gets in the way. Game devs usually know which mechanic you probably prefer, despite you saying want otherwise. If you want to make a character walk up some stairs in a realistic way, you'd have to slow it down sacrificing control for realism.
Breath of the Wild also has some good examples of making step-ups feel even more natural. On really REALLY short steps it's just the typical smooth looking motion. But as the steps get higher Link begins to do an actual "stepping up" or "clambering" style animation, which influences his movement without interrupting the player's agency, and makes a high step-up look seamless
@@NickMaltbie fun fact: when doing the higher step up animation link won't fall. gravity is set to 0 (probably so that you dont get stuck falling infinitely when doing it). A bug which makes you stuck in an animation and allows movement uses this to perform a "blss" where you just sorta slide around the map at the speed of the Nintendo Switch (trademark) (copyright) (patented)
Harry Potter and the Order of the Phoenix was a videogame that dealt very well with stairs, whenever you were going up or down stair the character moved at a compatible pace, and physically actually stepped on each step like a person would in real life. Actually pretty advanced for a PS2 game, all things considered.
@@spimbles no I'm pretty sure it was a 7th gen game so if anything the ps2 version was just the usual downgraded port to capitalize on the ps2's dying market and order of the phoenix was the first Harry Potter game for ps3 and xbox360.
Snapping has a really bad problem that you seemed to ignore in this video. When you use the snapping method, many games don't include a decent enough compensation for the camera snapping in turn. This can cause motion sickness in some players, especially if the title is a first person game. This is why most first person games use clip brushes to handle stairs rather than snapping, especially highly competitive games such as counter strike or overwatch. Thus, as with most game design decisions, the correct answer rarely is one size fit all, but highly a "it depends". Also note that these aren't the only two options, another example are games such as the Yakuza titles that choose to (atleast most of the time) force you to walk up/down stairs normally, with pre-determined animations for each step. These fit better than either of the two previous solutions for games that are trying to stay more grounded in reality, and there are more options out there too.
I agree, the best answer is it depends. The OpenKCC actually uses a slightly smoothed version of snapping where the player will teleport up and forward a short distance when he tries to snap up smoothing out the movement quite a bit removing that jittery feeling. The code is open source and you can see it here if you're interested in learning more - github.com/nicholas-maltbie/OpenKCC/blob/main/Packages/com.nickmaltbie.openkcc/OpenKCC/Utils/KCCUtils.cs#L179
you should NEVER allow you camera to teleport. you shouldn't even accelerate/decelerate you camera suddenly. typically a camera should be on a collision free physics system, accelerating in such a way as to track some point in space (which can teleport or whatever). if the camera absolutely must teleport, id suggest fading to black and back. or /something/ to avoid teleporting. unless your in VR. then the camera should only teleport X'D X'D - i think this will become less and less of a problem as time marches on tho
AAA dev here. To get the best of both worlds between the consistency of step snapping versus the smoothness of ramps, you can use the snapping, but afterwards apply a dampened spring offset to the character model relative to the capsule. With the spring tuned properly, this makes it so you can author the stairs as normal, get the good behavior of the step snapping, but you don't have the visuals of popping up and down the steps. Paired with some good IK, this is pretty much the de-facto modern stair solution. The spring also helps if you have a very rough terrain.
Something that's always weird to me is that stairs usually look proportional when you're playing, but your character always runs up them like 7-10 steps at a time. In real life, if you're running up stairs full speed you can get 3 at a time, maybe 4 if your legs are long. But VG characters just fly up a whole flight in 2 strides.
Somebody running full speed that start to jump to climb stair as fast as possible is likely too look similar. I think... I guess it try to find a video about that, I am curious now.
I guess it's because the player's velocity is calculated on a flat linear planar, so if you have a steep/stairs you will travel same horizontal distance but more real distance from stair start to top (pythagor stuff)
Have you seen the escalators in Lost Judgement? I was blown away when i saw the protagonist walking up and down FULLY FUNCTIONAL ESCALATORS, with each foot connecting perfectly with each step, adapting to the speed. Literally the best stairs I've ever seen in a game, and they move! Not sure of its something you have time for, but if you're ever able to figure out how they worked that magic, I'd love to hear about it. Your way of explaining things is great.
Yes! I find it so weird that most stair solutions don’t use a step depth variable! I had a fun error where you could walk straight up a 89.9 degree angle while programming it as well leading to some funny situations.
I've made a fair amount of character controllers in my spare time and the floating character method is definitely my favorite solution. It's simple, reliable, and feels very smooth. I would highly recommend it to anybody making an indie game. The very very valet video he references at 3:38 is actually a full tutorial the devs of that game made and it's very helpful, I'd recommend anybody who wants to make a floating character take a look at it.
TF2 maps mostly cover stairs with ramps, but there’s a few maps (or a few sets of stairs) that don’t do this and instead you snap to each step. It’s noticeable when this happens. Your view snaps to each step with you and it can be jarring. The ramps are a good workable solution. I guess, the best stair solutions depend on the type of game. For FPS games, you probably just want a ramp to make it simple.
I agree completely! I can empathize this more in future videos but ramps work as a perfectly serviceable solution especially if you can devote the extra time to level design.
The worst part about stairs in TF2 isn't walking up or down them, it's shooting a rocket and having the geometry absorb the splash damage so that the scout standing 3 inches from the rocket doesn't get hit.
Counter-Strike has had a problem with Dust 2's spiral staircase, where just making a ramp isn't easily feasible due to engine limitations: ruclips.net/video/qpeDBPPn0I0/видео.html
Back in my early days of programming I solved the "stair problem" on my kinematic controller with an absolutely overdesigned solution involving a whole bunch of casted sloped colliders and edge case handling. The colliders would cast forward at the character's feet and essentially act like there was a ramp there for them to walk up. It was fairly rigorous but it was absolutely unmaintainable and not performant and was not entirely free of weird edge cases. This was before I had learned that simple is usually better.
Yes, and being able to disable any comped solution behind a feature flag is also important. That’s why I like the checking cast forward and up, it’s only one extra step and the code ai relatively easy to follow.
On snaps: They can be EXTREMELY disorienting for VR. The sudden up and downs on climbing steps can feel horrible, even for somewhat experienced VR users. The "ramp" approach feels better in taht case. :P
Yes, snaps even without VR can be very disorienting. The ramp can be the better case in those scenarios. The other option is to lerp/interpolate the camera position to move smoother and avoid that snappy feeling. There is always some compromise to make between these decisions, but I think this is a fairly good result for most use cases. And the snapping still works with ramps because it's skipped so it's almost a sub case of the current use.
Oh, I had the line of code wrong, should be this AttemptSnapUp function - github.com/nicholas-maltbie/OpenKCC/blob/main/Packages/com.nickmaltbie.openkcc/OpenKCC/Utils/KCCUtils.cs#L261
@@NickMaltbie It is a fairly good result to accomplish the same thing as making a ramp but also make players sick or unable to play? You said don't settle for less but you're actively kicking people out of a game. That is by far less.
The absolute best solution for this problem for me was shortening the capsule collider up to the knees and adding a downward-facing raycast that checks how far the ground is. It then lerps you to the raycast position every frame. So far it hasn't failed me and I'd assume it costs less than checking contacts
Yep, much cheaper and simpler solution. And the player probably wont' walk higher than their knee height so it works pretty well. The only downside is that now your character's "grounded" state is just a point and not the whole collider shape and can slip between or off small ledges. You can get around that with a sphere cast but then you might as well have the whole character be that shape... It just gets more and more complex but it definitely a cheaper solution. If you were to make 1,000 agents run around a scene it would be a lot simpler and more straightforward. Thanks for sharing the solution and ideas! Having a floating character is a very common solution and robust for most situations. I originally designed this character controller so the player could be any shape (or even a composite shape) so assuming the player is a capsule or even that they have knees might not always be true.
@@NickMaltbie When i was playing with Unity years ago, i solved this by having, rather than ray cast, a second collider below player character. The colider would be allowed to clip through geometry, but you were able to take collision information to do what the raycast does + more.
@@chubbygoat Mate I just checked your game out with absolutely 0 expectations and I was damn near blown away. The map just kept going on and on and after shooting like 200 potatoes I actually started feeling bad about killing these benevolent creatures. The sounds are on point, movement is smooth and the details are amazing. I'm talking about chunks sliding down walls, holes being punched in potatoes etc... Simply an awesome game with crazy potential! Now, I do have a couple of questions. 1) Did you use decals for the "blood" and if so, was it HDRP? 2) Did you make your own sounds? and 3) How do you throw grenades? I can't find anything in the manual. As you can see (on my channel), I'm making an FPS game and questions 1 and 2 have been driving me nuts... Cheers!
@@NickMaltbie Oh yeah, I immediately assumed the player was going to have a humanoid shape. I didn't think of horses and the like. Also, I just figured out that my character falls through mesh that's riddled with holes (although it snaps right back up when you start moving) so an additional trigger for isGround would be appreciated. But all in all it's a nice solution for rigidbodies if you need physics and you can't rely on character controllers.
@Daniel Beard In my case i was trying to make a player controller that was able to support movement similar to Tribes games - where you could press a button that turned your shoes frictionless, and you could slide downhill to gain speed and then use jetpack to go over the next hill, land on down slope and keep building up speed this way. I needed the vertical separation from the ground because of high speeds the physics inaccuracy would push player into the terrain between frames, resulting in weird bounces on sudden slope changes, etc. Adding 2nd collider allowed for kind of hover behaviour that avoided this. And for having different modes, you don't even need to turn on and off coliders, you can just have conditions in the code that handles bottom collider. What i've done is small state machine - depending on player state (walking, running, skiing, jumping, etc) different function would be called on collision detection.
I'm not an animator, or game dev, but stairs in games always mattered to me. The ones that bother me are ramps with stair textures. I would rather they used ladders if they wouldn't want to animate stairs properly, especially in games that are aiming for immersion.
lmao u think they wouldnt have to animate a ladder climbing? whats easier - doing nothing and adding a ramp, or adding a complete new way the character can move?
Using snap up/down code is all fine and well, but people don't rigidly move over obstacles as we naturally keep our heads at a steady height. To accurately move characters over small obstacles and up/down stairs in a realistic manner you'd have to predict that your character is about to go up/down and make the IK legs anticipate changes in elevation, followed by smoothly interpolating between the heights. There's research papers on this (Phase-Functioned Neural Networks for Character Control, Daniel Holden et. al, 2017), but that's really getting into the weeds of things. Ultimately anything less than neural networks and predictive movement is a compromise, but games are made on compromises for reasons ranging from performance to game feel, and more. I mean, competitive shooter games might even opt for ramps only so that player heads (the main way to define skill by clicking on them) aren't jerkily moving up and down that would otherwise disrupt player aim and cause missed shots. Personally I still prefer the invisible-ramp-inside-fake-staircase method for its consistency and smoothness despite the additional work for non-stair steps (and even that might be easy to solve by "baking" a level's steppable areas like you would bake a lightmap - and for procedural levels it wouldn't be too difficult to add additional checks as to where invisible ramps should go in the level generator code).
Hey, thanks for the comment! I really do appreciate feedback on these videos and love sharing this project and getting other people’s opinions. I actually have modified the code since this video have the player smoothly slide up/down steps at whatever their movement speed is to avoid having the jerky camera movement. I think it’s perfectly fine to use ramps and invisible colliders if it serves the purpose in a game. As long as a level designer is willing to put up with two layers of colliders (one for player movement and one for IK/animation and everything else’s), you can usually make this work. Or if you write some fancy automation to handle that generation of a secondary collider for player/avatar movement. I’m releasing this as a library though so I at least need some solution :) and, this stair solution is actually generalized and works just fine with ramps and can be disabled and revert to the previous behavior. These videos are always a compromise in making these videos and I think I didn’t even have time to discuss some of those tradeoffs I made while designing and iterating on the step code. That’s one reason why I like the fact that OpenKCC is open source, people can view and modify the source code as they need. I’m definitely interested in adding procedural animation to the project and I’ll be sure to check out that paper you linked! Neural networks might be overkill for this project but having some intelligent way to mix and set animations or values would be interesting. Since adding the cinemachine library I’ve looked more into having the player model move somewhat I depend rely of the avatar and it seems to be resulting in some good changes. With vertical dampening you can get around some of the jittery changes on steps or slopes as well without bouncing the character everywhere.
@@NickMaltbie Glad you liked my rather verbose reply (I hope my tone was neutral enough - I'm terrible at communicating tone via text). There's a few videos about the study and its implementation by various people on RUclips as well if you want to see it in action. It's neat, but yeah, for smaller indie devs and people just getting into gamedev (or shaking off the rust like myself) it's definitely overkill. And I forgot to mention it in the first reply, but thank you for making it FOSS! I look forward to seeing it evolve and potentially even have community contributions. I rely on a lot of FOSS applications (Linux/Gnome, Godot, Krita, Audacity, etc), and it's people like you who help keep the dream alive. Every little bit helps make the greater tech community and our software/devices even more awesome.
@@MajatekYT thanks! No problem with tone over text. I always try to assume that people are trying to be nice. Always like sharing open source projects like this because other people probably will find it useful and be able to help improve the project for everyone.
People keep their heads level *somewhat,* but not nearly as level as, say, a chicken does. My head moves around a lot when climbing stairs. Having just my legs going up and down while my head goes smoothly up a slope would look pretty ridiculous by comparison. Like, it would look like I was doing a bit. But the brain is good at hiding all that motion so that it's not disruptive to our continuous perception of the movement. So how much of that "brain feel" versus how much of the "actual head motion" you want to portray is I guess a matter of taste. Star Citizen went to great lengths fine-tuning this, in their attempts to make the first person camera always reside in the actual head position, for example. It's kind of a hairy problem that involves compromises no matter what, like you said.
@@delphicdescant Yes, when climbing. But when going down, my head moves in a straight line if possible. I noticed this recently when I noticed I had developed a habit of putting on my garden slippers to go down the stairs in my house (I'm usually barefoot at home). This prompted me to pay attention to my movement patterns. When barefoot, I step onto each step with my toes about half an inch away from the edge, which results in a jerky step-by-step movement. With my shoes on, I step directly onto the edge with it between my toes and the rest of my foot, which gives my body and head a ramp-like travel path. This feels like the ideal path to me, and I even started missing it when I'm in my street shoes on stairs outside my house (negative factors: unfamiliarity, stiff soles, no handrail, soft/slippery edge, bad geometry).
Thanks for the comment. These 3D animations were actually what I used to debug errors and I realized they could be extended to work for videos as well to help explain how they work. Character movement is more complex than it might seem at first and it’s nice to have visual aids that integrate well with the game engine.
Before stair motion can even be fully considered i feel that matching the characters moving speed and animations is really important, if it looks like your feet are sliding under you even on solid ground because the speeds don't match, stairs will never look natural even with a perfect all encompassing stair solution
I saw a video about wheels and terrain, and formulas to calculate how any shape can be a wheel with a specific terrain. The most common one is a square wheel, which it's terrain is just bumps that look like half circles in 2d or half cylinders in 3D. Smoothness was defined by having a point inside the shape that remained linear in motion taking into account the wheel and the terrain. Maybe something like that could be done to solve the stair problem. Define a point that you want to maintain linear motion, like the player torso, and then make the bottom half of the player adjust to the heigh difference between the step you're on and the next one and rest the difference to the upper half so it maintains the same height no matter what the bottom half bumps into. Somewhat like wheel suspensions.
Yep, balancing smooth motion and climbing up steps is a hard problem and suspension is a great analogy! thanks for sharing the design and description. It's a very close solution and all different parts have tradeoffs and benefits.
I love the way the characters go up and down stairs on Resident Evil 1 Remake. You should check it out! It feels really good and it doesn't have that awfull thing where a character seems to ignore the stairs' geometry completely
3kliksphillip made a nice video about this a few years ago. While hidden ramps do add a little work for the map makers it makes them so much better to walk on. It's crazy jarring when you go over some normal stairs and your view jerks upward on every step
It all depends on the game as well. You could smooth the camera's up/down axis to lag behind the actual location by a foot or less. This actually makes the camera feel very smooth but in CSGO imagine if you stopped moving on the stairs and your camera was slowly drifting up to recenter the camera. It'd feel annoying in a twitch shooter. In something like dishonored or thief it doesn't effect your gameplay and is barely noticeable. So hidden ramps or what 3kliks called stair clipping is really the best solution for CSGO that Valve could come up with. Pros and Cons to every solution.
I wouldn't be surprised if this has already been said, but there's a better way to do the snap method. Checking collisions and teleporting upward is risky if you're in an environment where you have a lot of collisions going on. Weird geometry, especially one-way colliders, have the potential to break it significantly if something goes wrong. Also, it's tricky to know for certain if a collision is happening due to the player walking into a step. This is all stuff you could filter out, but requires additional work to identify each of those cases and account for them. A safer way to do effectively the same thing is to say that any situation where you'd move the player forward, you instead actually move up, then forward, then down, all instantly. On a flat surface, the up and down movement will be completely canceled out. If you walk onto a step, you will move up, then forward, then the step will stop you from moving down any further and you are simply on the step. This solution excels at handling weird geometry and unusual situations because there is very little that can go wrong. Everything that happens can be accounted for during that stepping maneuver. An example of this is how to handle minimum step depth - during that forward step, you can test to see if you are able to walk further than the minimum. If you can't, you rewind back to the original position and only walk straight forward with no stepping. Pure math and movement checks, no waiting for collisions. Far more elegant. One complication with this is that when moving, the size of the collider will appear to be slightly taller, as you will hit up against low ceilings. You could account for this by reducing the height of the collider specifically while performing this up and down movement, but you would not want to do that at all times because that would change other collisions. I believe that the unity default character controller does exactly this, but I am unsure. And for what it's worth, I agree with some of the other comments that in most cases, a floating character controller is better overall. But it does have some tradeoffs, and so if you find yourself needing a step-up solution, I would point to this as a more elegant alternative to collision detection and teleportation.
Why not have the player collider use the ramp, and have the IK use the stairs? You could also sorta "flatten" the ends of the stairs so that going up the stairs isn't a constant motion. The ramp at the edges, combined with the IK snapping to the flat stairs, visually simulating the effect of the character's legs pulling the rest of the body upwards.
So many people have been suggesting this, I'll have to make a follow up video with a demo like this. It should work in most cases and replacing the stairs with a ramp is a nice simple solution if you can add it to your game.
You don't need any of that. Your pelvis and head and camera should work independent of each other for motion. There shouldn't be any snapping that needs any solving of extra steps or hidden geometry.
I heard of a case between BOTW and TOTK, where in the latter game Link's ladder climbing was changed, including having him jump farther up the ladder when beginning to climb. A result was that a really short ladder on the top of Hateno Ancient Tech Lab became unclimbable because it's shorter than the distance Link jumps up it.
OK before the final solution comes up for me, here's what I think: Use a ramp collider on all steps, and give your player two types of colliders. A rectangular or triangular one for each foot that collides with the visible step using IK animation, and a capsule one for the root of the player model, that collides with the ramp. Depress the ramp collider into the stairs *just* enough for the feet to be able to travel down to the step without stretching the model. The player should slide smoothly up and down the steps, (which would have to have their angle defined by the level designers) and the feet should reach down to meet the actual step at the same time. Essentially: "Don't do that. Just make it *look* like you're doing that!" You're moving up and down a ramp that *looks* like stairs.
Yes, this is a great solution many games use to get around the issue of stairs entirely, simply pretend they don't exist but move the feet like they do. It's a great solution and works for most simple cases.
A very common variation is to run a "body" capsule at just above the step height, and then do a sphere cast from that position down to the ground. It's effectively the same thing, but ends up a little cleaner code and you get fewer re-tries if you have some jagged terrain and potentially a low ceiling, where you have to re-try collisions after adjusting height. But otherwise, this is fairly standard. There's some additional magic a lot of character controllers will do for hip offsets to reduce IK over-extension and to also make the character movement both up and down the stairs a bit more smooth, but that's sugar on top.
Yeah, I noticed this floating capsule solution during my research but didn’t try to implement it as snapping seemed simpler. I made a follow up work item in the open source repo to tackle it in the future :) github.com/nicholas-maltbie/OpenKCC/issues/189 Just need more time to address these issues!
fun fact. Source engine uses the same snap up and down idea you are using. but they set the minimum snap depth really small. so you can literally climb up a near 90 degree wall as long as there are tiny 1/16th in ledges every foot up.
Thanks for watching the video and leaving a comment. Haha, I didn’t realize the snap depth was so small. Different games need different solutions so it’s good to have multiple ready to use when designing a game!
as someone who isn't any sort of game developer, i find that i don't think about stairs in any sort of way but this video has shown me just how complex all these stairs i have ascended and descended in games, and you looked at the third person pov, first person i would imagine would be more complex as having all those bumps up the stairs might be a motion sickness issue with all the jittering happening. that aside very informative video now whenever i ascend and descend stairs in a game i will know just how complex they really are.
In my experience (and I have written sphere sweeping) your capsule will go over low steps and rough terrain just fine. Getting the animation to look realistic is a different story. Also an overhang will make no difference if it's low enough. It has to be under half your bottom sphere but maybe a 3rd is better. But it reacts the exact same as a regular step.
Honestly the main thing is just don't move the camera so there's a weird bouncing effect. The camera should behave like a ramp but the player should move
It's generally still better for a level designer to add a ramp their stairs even if the snap stair movement method is used as it makes stairs look much smoother.
@@NickMaltbie i did this for a game from 1999 called unreal tournament. moving up stairs was very annoying for other players as it would warp the player and causes you to be 'warpy'. i added invisible ramps which were perfect for the gameplay there. the videos is called duku stairs before/after if you want to see how bad of a difference it is in that game. i think counterstrike uses the same thing for clipping stairs by having invisible brushes made in the editor.
Okay, turned this on on my TV, and pulled up my PC to comment. You're RIGHT!!!! I was not high enough for that intro. Really intrigued by the concept though, so excited to learned something new. Here's a like for the intro.
Something interesting, ive been into game development for like half a decade now (and sadly am not really close to being in the industry because that's less knowing what to do and more networking skills...) but one thing I can say is... This is exactly what ive done in 2D with gamemaker studio. But instead of stairs its slopes, but they are pixelated slopes. So effectively stairs. And the tutorials ive followed for that work in the *exact* same way. Which is ironic because as ive started working with Unity ive found they do slopes in Unity much differently.
I was wondering if a non-dynamic floating capsule could help you (similar to the Toyful games method but without using forces). In essence, always having your collider a certain distance over the ground, this distance being your step height.
That’s a great observation. I actually do have the capsule float above the ground by anywhere between 0.001 and 0.01 units to smooth out any error the user might see. Although the rest of the algorithm is the same. Allowing for around 0.1 units of wiggle room helps the steps look much smoother!
Would be neat to have an A.I. control the character model rather than these smoke and mirror tricks. Let the A.I. study how humans interact with things, and then let it decide how the model should react when a player gets into a certain situation. Maybe even have the developer train the A.I. by telling the A.I. what the character should be able to do as the developer attempts to make the model do the thing. I don't even know if that's possible, but it would be a cool way to teach a character controller what animations should occur in certain circumstances. Basically, give the A.I. a virtual body, and let it figure out how to interact with its world.
I have to say, it depends on many things if this solution works for your game or not. For example using a ramp or having a capsule collider just hit the step doesn't work on some physics configurations. The same goes for your snapping technique. It works like you said in most cases. Many games like sonic on sega game gear even made extra physics checks on the player for edge detection and so on. Which you get for free with your stair check if done correctly (correctly means in game dev if it fits your game, because there are multiple solutions to that as well). Snapping the player might have two issues for example: 1) the rough camera movement might look strange and might be better with a "ramp" 2) if the player as physics entity can move boxes around and so on. This snapping might depending on physics engine create a big force because of the moved in 1 frame. Let's say you have 15 cm stair and a 50 Physic Updates per second then you moved the player in that frame with a velocity of 7,5 m/s or 27 km/h, which is a normal human full sprint against an object. If you snap that upwards in your physics engine this might have unexpected behaviour to the game simulation. So depending on what you want a jagged foot on a "ramp" is the better option. Don't get me wrong, the video and information you provide is awesome! I've testet your Controller in the Browser Link you provided. I can make the character fly above a stair: ibb.co/FwpmwKt
Hey, thanks for checking out the video and leaving a comment! Also, with that demo image, I haven’t setup IK yet so the player can float off the edge of the collider is grounded but their feet are not! More to fix in the future. I actually improved the snapping algorithm a bit since the video was published to have the player smoothly slide up a step at the rate they are moving forward (could still use some work but a much better solution, you can see it live in the demo now). Also, since the player is “kinematic”, they aren’t controlled by the regular physics engine so all that collision code is handled manually and can be capped to be within a max velocity. Although I agree it’s good to have more options. You can disable the snapping in the OpenKCC config via the stepHeight variable and use ramps as well - nickmaltbie.com/OpenKCC/docs/manual/usage.html I should probably make a follow up directly comparing all these versions since so many people are talking about them and interested in it!
You mentioned the floating method. When I was trying to solve this without looking at tutorials cause I'm stubborn and wanted to solve it myself, it felt so good when I finally figured out that I can just make the collision float and maintain a minimum distance to the ground. It's so incredibly easy compared to all other methods. I don't get why you didn't talk more about that one. Of course just making the collision float is just part of the solution: I also made the character move along the normal of the surface instead of directly where the input says, changed the speed depending on the angle, etc.
The trick of having Tha character just "float" above the ground sounds very nice, the hidden with their feet and stuff, might actually work well, I want to try that. Very nice video!
Another graceful solution to consider has to do with physics masks. Since the movement of the player you're attempting to achieve is that of a ramp, and the problem you're attempting to solve is to do with the IK'ing or foot visual placement, you could instead have a more detailed physics mesh that is accurate to the steps *and* a ramp. The ramp is set such that it only interacts with the player capsule, and the higher detail mesh is set such that it only tests against IKs. Solving all the other "step-like" cases (via a similar raycast clearance check like you're describing) is generally much simpler if you can eliminate stairs from that equation. This was a great video! Thanks for making it!
The first retro game that comes to mind when it comes to high-effort player character animation for me is Jak and Daxter, so this video made me try to remember how stairs are handled there. I then realized that everything that could be considered stairs are exaggeratedly large, adjusting with how far into the game you are. (The steps to the final boss each being twice Jak's height.) The idea that they did that partially to avoid stair-step animations is really funny to me.
I have a couple problems with this video, but let me take the lead on this instead of complaining. First, a character controller can help determine what is an acceptable slope. Secondly, your stairs foot length should be relative to your animations making relative sense with the speed at which you move. Next, I use a ramp shape as a trigger. This can tell your camera to ignore the bumpiness by slerping. Lastly, you can make an event that triggers the use of a separate animation and movement speed so that it feels clean or choose some other result. I personally use Unity's free addon of generated inverse kinematics for this so that my feet will always match the steps that I walk.
Nice video but you forgot to mention the easiest trick in the book: using an invisible plane with a special collision flag for feet collision. It's extremely cheap in terms of computations and provides the smoothest surface possible, you won't have any head bobbing in First Person view no matter the steepness so it works very well for FPS. Only drawback is that you have to set them up manually (but in most cases you have to create invisible walls in the level anyway) and they're not the best for spiral stairs with short radius (but these are rare in video games). This technique is used in World of Warcraft for both straight and spiral stairs. Also I don't think OW use a custom collider for climbing stairs, the body collider is actually much higher than the character's feet (somewhere around the knees). Instead the ground probing is achieved with a raycast and the feet position is smoothed to prevent jitter. For stairs and nearby floors, I believe the topology around the character's feet is analyzed to find the best possible floor height. This allows the character to stand on nearby platforms, even if the character's feet don't touch the platform.
Yes, these are all great ways to tackle uneven surfaces in games. I like the idea of a floating capsule as well, I might add it as a separate kind of KCCMovementEngine in the future since so many people are suggesting it and it's a natural extension of the current movement engine. Also, I'd love to add IK to the project, but it will take some time.
I really appreciate this kind of content, I started making games when I was becoming a teenager (I'm not sure what is the correct term in english). But only recently, I started to realize that games aren't made with special assets, systems and engine features taught by famous tutorials that solves your problems magically, instead it's a endless problem solving process, and with problems that you never really thought existed until you start making games, like stairs. Really nice content! Videos like these desmitifies game development!
I've seen Lost Judgement(Judgement is a spinoff series from the Yakuza/Like-a-dragon series) do some really impressive foot kinematics with actively moving escalators.
this is really interesting to me specifically because of how much I play Destiny 2. that game has highly detailed environmental collision boxes that can be somewhat frustrating to deal with because of how they interact with wave generating projectiles. There are a number of weapons in that game that have projectiles that generate a damaging wave that travels along the ground based on the direction the projectile was moving as it hits the ground, and this almost guarantees that if you try and send a wave up a staircase it will hit the face of a stair, bounce off, instantly hit the surface of the next stair down, and then send the wave down the stairs toward you. there's also plenty of other heavily greebled angular environments that will do this to you if you're not careful with your shot placement (especially vex architecture.) I always figured it would have been so much simpler for them to just make ramps and hide them like you mention, but this video has given me so much insight into the problem that it is clearly more complicated than I gave them credit for.
Good luck with the GGJ project this weekend! I wrote an extension for the OpenKCC using using unity’s netcode multiplayer if you want to try it out. There is still a bug with synchronizing position on moving platforms (player sometimes jitters a bit) but otherwise it works fairly well.
There's a handful of games I've played in which the devs created an entirely separate animation for going up or down stairs and with how complex the whole stair problem is, I have so much respect for them. That must've been one hell of a project lmao
Regarding "snapping the character down to the ground to not fall down stairs", one neat trick I've found for myself was to make the length of the downward cast proportional to the character's horizontal movement during that frame. You simply multiply the length of horizontal movement by a factor of your choice. Larger factors support steeper slopes, and smaller factors flatter slopes (I've only tested it with slopes, but I'm pretty sure stairs will work, too). A factor of 1 would support walking down 45° slopes. With a bit of trigonometry, you can even rotate the formula so that the user can specify the desired maximum angle and the cast distance automatically gets the correct multiplier in regards to that setting. Anyways, I think this way of handling the snapping has a few benefits: 1) You don't need to manually configure a cast distance based on feel. 2) The differentiation between walking down slopes and falling down is automatically handled for you (anything that goes beyond your desired slope angle is considered falling). 3) This method is stable across framerates and even scales with player speed. So if you have a super long slope at a constant angle and the player is running down at 100 miles per hour, as long as the slope angle is within the threshold you configured, the player will still stay on the slope and not start falling. (Well, I guess it could be argued that this isn't really physically accurate, but I think for games, it's usually what we want). 4) You can mostly prevent that issue where the player visibly snaps to the ground near the bottom of stairs. There might still be situations where a fixed cast distance will work better, but for my personal needs, this turned out to be a great solution.
Hey Nick! What a great video. I don't even make video games, but as someone who finds programming interesting this video was amazing! Even though it was entertaining and instructive I would've really liked to see clips from games where stairs were NOT implemented correctly. While I am writing this I realize you might have done so without me realizing. If that is the case I would like to apologize. But for someone like me who doesn't have a lot of experience (or none at all) with making video games I would appreciate if you could have told us what is correct or (close to realistic or the most used solution) while shwoing examples of both, While watching the video I was not sure if the character was considered moving smoothly or realisticly. Anyways, this is an amazing video and you have certainly earned another subscriber.
Thanks for the feedback on the video. I'm still pretty new to making instructional/educational videos for game dev. I think presenting clear cases of what works and what doesn't would be a great example. I'll make sure to include this more clearly in the future. No solution was "correct" or "incorrect", it's always a compromise. However, I can create situations where the character specifically moves incorrectly or has a difficult situation to navigate.
5:03 "you can't hide the stair problem, you just put that work somewhere else" great line. I really liked, really liked this. Presenting historical solutions, then ultimately a solution 'better' than those, and mentioning which cases were covered and not.
never knew there was so much to know about stairs in video games, very educational and thnx for bringing this to the public. Hope many nice things come from it.
Just look at literally any game from Naughty Dog. They mastered stair animations since Jak & Daxter and it only got better from there. TLOU has a completely separate animation set that activates when the player interacts with stairs, making climbing stairs slower, but more realistic because the feet land on each and every step perfectly. Naughty Dog's inverse kinematics systems overall are just mind-blowing tech in every example they come up in.
I’m pretty sure this is why a certain funny glitch can end up occurring with this solution, in destiny (the game I’m most familiar with) we can actually abuse stair snapping by using it to gain extra speed. On certain sloped surfaces (aka stairs) if the snapping speed isn’t instant (usually not to avoid it feeling clunky to walk down stairs) you can actually have just enough horizontal speed to get the down snap just as you leave the snapping threshold horizontally but then you still get pulled down by the snap which places you into the threshold of the next step to snap you down then aslong as you are constantly leaving and reentering the snapping threshold horizontally your character builds up speed very quickly which results in a massive burst of speed as long as you then leave the stairs without becoming grounded… a bit hard to describe but if anyones interested and can link a video of it happening
Bit of a complex solution actually. Before the player moves it checks for motion in the object below it and corrects to maintain the same relative position. It also has a bunch of complex logic for handling other situations as well, but that’s a future video topic :)
Yup, and especially when the developers of the engine don't work with you. In Godot, you used to have to be very clever to solve sliding down slopes for instance. And, the developers acted as if this was fine even when you turned off sliding on slopes.
I think this is a great video! With procedural animations, stairs are pretty simple to create, you won't need to have in mind the player speed either because the dot that follows each set of stairs is relative to the position of the players legs :)
I think for most games, a fairly practical solution is to separate the collision mesh from the visual appearance of the stairs. You can then base the position in which the character is shown on the terrain mesh. This allows the camera to move smoothly up and down, while also making your character look like they're firmly grounded. It also signals intent. If you just leave it up to the physical characteristics of the terrain, you might get situations where a player can walk up something they're not supposed to, like for instance up the seats of bleachers. What you want to allow the player to do in situations like this is going to depend on the kind of game you're making. Not everything needs its own collision mesh though. Most terrain will be fine with either using the terrain mesh for collision (like slopes, floors, paths, etc), or not having collision at all and just use IK to smooth things out (thresholds, cobblestones, branches, etc). Of course I agree that it would be ideal to use a one-size-fits-all solution, but in practice that often ends up being more restrictive than liberating. I think a separation of the different concerns of rendering, movement and IK is a far more elegant solution. And you can define all three for each of your terrain elements depending on their intended function, which will allow the level designer to place them down without worrying much about it Your stairs then come with a sloped collision mesh pre-installed, so no matter how steep or shallow they are, they function like stairs. If you don't want your stairs to function like stairs, you can add an exception for a particular instance of that element... or better, place down a different element that wasn't intended to be walked on top of. The only real snag with this system imo is if you want the same element to function differently in different situations, for examples because either the player or the terrain can shrink/grow. In that case, it might be better to use the system you present in this video, since the intent is to let the player traverse big objects not meant for walking on when they're large, and stop them from walking up even small steps when tiny. So if the intended way for a player to interact with something changes over the course of the game, you want a way to deal with that. It's always tempting to design things like we see them in the real world. In the real world, if we can touch an object, we can stand on it and collide with it. But this isn't a design feature. Rather, it's a restriction. We build stairs precisely because we can't walk up walls when the need arises. We want our game to mimic the way things look in real life for the sake of familiarity, but that doesn't mean it has to work the same way under the hood, unless you want the amount of extreme realism from your game that really only VR games could benefit from at the moment. In conclusion, this is what my critique on your movement system boils down to: it doesn't have a concept of intent, and takes any non-visual design work out of the normal level and world design processes. I think that in most cases, "intent" is a crucial thing to have at your disposal when designing. You want the player character to interact with the world as the world wishes, not as the player character wishes, or you'll run into lots of problems later where the intent of your design doesn't match what the player can actually _do_ there. These different elements should not be made to rely on one another if there's no need for it. It just makes things more complicated. There's something nice and declarative with having collision, appearance, and other such properties separately defined on level elements, and it makes it easy to fix problems without having to introduce a whole host of new ones. It's a flexible system, whereas this one is inflexible. Ask yourself what you will do if your level designer comes to you and says, "I want the player to walk up these stairs, but they can't. I also want the player to be unable to climb this slope, but they can." Are you just going to tell them "that's not how physics works, so deal with it"? I don't think this video or your work on OpenKCC is useless. Far from it. It's very impressive. But I think it's also important to realise and accept what its limitations are, and what it is _not_ suited to.
"that's not how physics works, so deal with it"? Yes? If something looks climbable, it should be climbable. Consistent rules are important to immerse the player. It's basically the entire point of the genre "immersive sim".
@@phasmidjelly1429 The physics system does not decide what the player expects to be climbable, and neither is a physics system simple enough to be a comprehensible ruleset. Furthermore, you argue the importance of player empowerment and immersion without ever considering how prioritising these things concretely affects the player experience. These ideas of empowerment and immersion can certainly be reasonably applied to your _experience_ of a game; if a game makes you feel empowered and immersed, that's fun. But they're far too vague to guide the design process. If you want to design a unified, comprehensive experience, you shouldn't put the power to decide what you can make in the hands of an arbitrary system. That system exists to support your intent as a designer, so you should have the power to make it do what you need it to do. Saying "that's not how physics works, so deal with it" is shooting yourself in the foot. It shows that you believe your value as a game designer is in how closely your game can mirror people's expectations. I'll be blunt: if you limit yourself to designing only what people already expect, you will never create anything memorable. The real power of a designer lies in their ability to _set_ expectations. A good game designer can make the player expect almost anything, including that they can walk up those steep stairs, but not up that shallow slope.
The only solution that i could think is making especific animations for stairs by "press a to use" and you go up/down or to have the entire animation controlable by limited controls, up/down or align with the camera angle. And this "auto-animation" will have 4 versions: walking up/down and running up/down (last two skipping some degrees). The good side is will be more realistic, but other side is that will cost so much time because you will have to make an animation for each stairs or make an entire engine for just the stairs locomotion. Thats why stairs is just another ramp.
Having a game play smoothly and look realistic are sometimes at odds. To have something look realistic animation IK and good movement tracking are important. Smooth “looking” movement can actually feel weird when playing a game because when you walk in the real world, it’s not a consistent speed. But seeing your character constantly slow down or speed up can feel weird in game so most games smooth movement.
Right. You could code the player character to deliberately step up the stairs by targeting each step and animate it perfectly, but what if you have to stop and go back? What if you are fighting an enemy while on the steps? This is where it's easy to over engineer a problem and make is worse because now you have to account for every edge case.
@@NickMaltbie Nice way of not answering his question, because you don't know how they did it because you don't actually know anything about the subject you're talking about. This is like modern egyptians discovering ancient egypt and not knowing what it is. The works been done, people already know how to do this stuff well. Just because you've discovered the problem making your shitty indy game for the first time, why do you think you should be making a video on this like some point of authority?
Really makes you appreciate the finer details of game development, and especially the fine touches like Link looking down when he goes down steps or up as he approaches a wall in tears of the kingdom
This is awesome! I wonder how this compares to the Unreal 5 equivalent and their new ik hand and foot stuff. Give’s me a better understanding, as a 3D artist, of level design things to be aware of!
I still think the "hiding" part (pushing it to the level designers) is the best one still. Snapping up stairs isn't perfect like you mentioned but far worse is that in first person you dont want the camera snapping upwards, it's incredibly immersion breaking and jarring. You can smooth out the camera but that has its own issues with feeling floaty and detached and slopes can mess it up etc but if the game requires precise aiming then that smoothing is even worse of a tradeoff. The best solution is pushing it to the level designers+snapping, which is what CSGO uses and they've basically perfected smoothing out stairs with ramp colliders, it checks all the boxes it's smooth, you don't notice it so no immersion is lost, it keeps the camera steady and not floaty (mostly, there is still some from older source games that just had snap and camera smoothing like CS:S), and you never snag on anything random. I think it's the best of all worlds.
The way the snapping works looks completely unnatural to me. You can tell just by watching it that it's snapped to the surface, it doesn't feel like you're walking up or down a surface it looks like you're walking along it, glued to it. If I walk fast off the edge of a step I don't immediately snap down, I get a little air time, with appropriate speed and gravity configured "falling" down a stair is more realistic. In real life if you're walking briskly down a stair, you don't fully stop moving downwards when you put your foot on the step below, your leg continues to bend allowing your center of mass to continue moving downwards slightly, but other than that you really are doing a controlled fall with every step. Something similar happens with stepping up, you are pushing yourself up with your feet, but if you're doing it at speed you also maintain some upwards momentum from the previous steps, effectively tiny jumps. The physics behind stepping up and stepping down is an entirely physical mechanics problem which is difficult to simulate with only primitive colliders. The most accurate form of dealing with steps would be to simulate the forces on an actual skeletal system with the feet targeting and being planted on the ground via a predictionary system that looks for viable spots based on current momentum, expected trajectory and current limb placement (Think of this like the current IK system used for animating moving up steps, but the positions actually used for the calculations themselves not just visual). This would be computationally expensive, but not prohibitively so, the main problem would be the complexity, combining such a system with the more traditional collider-based controllers would be rather tricky, so you'd likely have to design the entire character controller in this style which would be far more complex and would have it's own difficult issues to solve.
Yes, I agree. As you describe in your solution, accounting for all those variables is very complex and can lead to difficult to handle edge cases. Most of the time in tight platformer games you want responsive and snappy motions. So the logical collider for the player should snap up or down to provide smooth motion that doesn’t result in the player clipping between the falling and grounded state when walking up and down small ledges. However, the camera and player avatar should not be bound to these snappy motions as they can look jarring and unnatural. Lots more to cover on this and different types of games require different solutions depending on what the game designer is attempting to achieve. Snapping is not ideal for every game but can work under some scenarios. Additionally, something needs to be done to handle sharp edges. I’ll make a follow up video describing and comparing some of these solutions. The character controller style you described is sometimes referred to as an active rag doll based character controller and is used in some games like human fall flat. However, making a game more realistic can also make it feel unnatural to play and probably would need to be separated from the actual player movement mechanics. Games like super Mario galaxy actually do this and have the character avatar move completely independently of the character collider to make it look natural while also feeling smooth to play.
Im struggling to understand what the issue is that hasn't already been solved. UE for example, has a max step height var on their character class to define the max height the character can step onto. This has been in since the beginning of UE4 as far as I can remember. (Well over 10 years now) How is what youve described different from this? Using the max step height, its just a case of using IK to place the feet on the actual step and move the hips down slightly. One of the main issues i can see people having is with the characters skeleton not being setup correctly (bad bone orientation) which would result in strange behavior when trying to do IK. Adding smoothing to the cameras z movement is easy enough to help combat the jerkiness. Am i missing something?
My approach was a bit different than yours, as different use cases needs different solutions. But your explaination of the subject was very helpful. Off topic question: What tool did you use to create the image seen at 8:18 ?
Thanks! Yes, every game needs different solutions but wanted to provide a guide on how to implement snapping because I didn’t find another good solution online. I used google drawings tool to make these static images and just faded between the different frames. I think learning adobe animate/after effects would probably be a good step in the future to make good 2D animations, just haven’t had time to do that yet :)
I'm not entirely sure I understand? Games like Unreal and Quake from the 90's (and all their sequels) already do this snapping up/down method, with configurable step height and everything you can mess with in the editor. Even Super Mario 64 does this. If I'm not mistaken, a lot of games today still do this method (along with combinations of the other methods more so now), though mostly seen in first person shooters/faster paced games I'd say. Great video explaining and breaking it all down, but the snap up/down method has been a well proven stair solution for decades now. A little unrealistic perhaps since it lets a player zoom up and down them at inhuman speeds lol, but from a gameplay perspective, it's fun and doesn't break the flow of playing, so it's the one I tend to see a lot more than most.
Many games that use this teleporting up solution suffer the problem that moving stairs upwards is much easier and faster than moving stairs downwards. Upwards you just teleport up each step, movement is instant. On the other hand, if you want to move downward the stairs, your player might loose contact to the floor and is overall limited by gravity on how fast he can move the stairs downwards. This doesn't feel right at all. For now I think its best to simulate the player as a little hovercraft, a capsule that does not touch the ground, like it was done at 3:40 it can be extended to have legs, but they are not part of the collision with the environment.
Not a game dev by any means but would like to know. Why isnt the bean(character) and legs movement two separate things. Like the bean can slip up a ramp so it looks more natural, while the legs follow the terrain instead of snapping the entire character. Wouldnt this allow there to be a check in the animation for the legs to only snap them to the flat part of the terrain based on the position of the bean. Kind of like if character bean is over step entity do a check for the position of the forward leg in the animation cycle to make sure it is colliding with the terrain. Sorry if this was covered.
Hey, I haven't had time to add IK to the project yet, that's a bit of a complex addition and adding it would take quite a bit of effort but is on the list for the future. I didn't really cover it in the video, the character and her animations are just meant as a visual reference so it's more interesting than the capsule shape moving up and down.
Alot of people DO NOT understand how hard it is to setup just opening and closing a door and making it look good in a game. This is the same idea and how hard and bad it can look in a game without thinking what it takes to fix it. Thanks for showing us how it works and how to fix it :3
playing your demo I've come across an issue. When the stairs are small enough and you try to jump, there's an inconsistent quirk that happens where you snap to the next stair instead of leaving the ground. I think another kcc library I've seen solves this by very distinctly separating grounded and ungrounded states. This logic that keeps you on stairs (and I believe slopes) only happens while you're grounded. Then when you decide to jump you're forced ungrounded so you're not attached to slopes and stairs. Apologies if this has been mentioned a million times already
I think I’ve seen this too. I found the issue for when the player snaps down stairs causing it to interrupt a jump but never resolved it for snapping up stairs. I think I need to add that check to prevent snapping up when the player is moving up/down as well (I only have that check for snapping down). I’ll add an issue on the GitHub page for this.
The best stairs-to-character animations I have seen are from some old games, like the original Resident Evil and Dino Crisis, where you get the cut scene/loading screen and you can see the character going up the stairs; no weird floating or clipping. It's a trade-off between looking nice and consistent play flow.
I absolutely disagree with your comment about not holding devs accountable who do NOT do decent stairs physics. As a player, the time management of a studio making hundreds of millions, or billions of dollars is absolutely not my concern, any more than the long working hours of a car designer gives them a pass on car safety. When I pay for a product, my concern is the quality of that product. It is up to the studio to allocate sufficient time and staffing resources to ensure that their games are presentable. Indies get a lot more leeway. That said, targeting specific programmers or artists is not helpful.
Great video, excited to implement this a bit later today! One quick question: at 1:37, you're using some "Create Shape" thingy-mer-bob to click and drag your stairs into your scene. Is that a package? Where can I find it?
I'm curious about the floating collider method, tbh. I've seen snapping as well as the hidden ramp trick, but I hadn't really looked into just...not putting the player's collider on the floor.
![Noob To Max With DRAGON REWORK In Blox Fruits [FULL MOVIE]](http://i.ytimg.com/vi/LnBMOinoOvA/mqdefault.jpg)
Could the problem be that the stairs are also not made with the speed your character has to move in mind? I think that the only way we will get natural stair movement is when we lock characters to the stairs and use an IK and root motion setup that calculates where you can put your feet. Maybe faster characters could go up 2 or 3 steps at once.
The current character movement actually allows for the character to snap up multiple steps at once! I didn’t talk about it in the video since it’s a bit complex but the code actually does two checks. One at the collision point and one at the max step up height. If they are moving fast enough to skip a step the collider will walk up multiple steps at once. But since it runs at 60 updates per second the character usually only moves a fraction of a step.
That IK addition and running of root motion would be a great enhancement and hopefully I’ll add it to the project at some point in the future.
Yeah running up stairs in games usually looks weird because you move at the same max speed as on level ground.
Yeah, climbing stairs generally involves a different shifting of the body weight and impulse on the feet and legs than running on flat ground, but that would be an entirely different can of worms to discuss, I think
Yeah, the problem is it depends what sort of game you're playing. Fully realistic stair climbing, isn't always possible due to scale, speed and just generally because filthy normies don't appreciate stair simulator 2023.
There's always a tradeoff between perfect visuals and effort. For a game, faking it is enough. It just has to be good enough to not trigger a "something looks wrong" response in the player's head.
However, if we wanted it to be perfect, then we'd need to translate every single step the character takes into an actual step. So we would need to calculate the intended step distance, then find a good landing position for the foot that takes into account obstructions in the movement path for the leg and body, and then execute that movement. But this opens a new can of worms. The player inputs are not precise enough to determine exactly what the player wants their character to do; we only have a 2D vector (i.e. direction on a plane and speed). And even if the character is on a perfectly flat plane, if the player input changes to "speed=0" in the middle of a step, when the character is unbalanced and needs to end the step to not fall over (or even more steps when running), this now has added a considerable input delay.
Before spending effort on something like that, there are better mechanisms that could use some love. For example, transforming the player's direction input to align with the terrain. Walking along any structure (straight/curved road/stairs) can be quite annoying as you have to mimic that structure with your controller or mouse input. Even a slight nudge to the character rotation can help tremendously here. If it is implemented well enough, you can get away with a nudge that's big enough that a character can walk up a spiral staircase centre of the steps with the player only pressing forward.
When I was a kid, I would be really impressed or fascinated with how in the original Wind Waker on gamecube, Link's feet would stand on and set up each stair individually. You could stand on the stairs and one foot will be on the next step and one on the lower step. It always looked so smooth.
I must've always had being a game designer in mind because I did love that but then as soon as I saw that I thought "what would happen if it's exactly between two stairs?". I then made link's leg bounce up and down because it wasn't sure which step it should be on
Seeing that a generation earlier in Ocarina of Time was even more impressive for me!
Yeah me too. When the game was just released and I bought it , I was also into programming games a lot, so I also deeply wondered how this was coded back then.
In KH2 there's a funny IK bug on stairs where you can actually angle Sora in a way that both feet think they're the "elevated" foot. So Sora would just do a blank squat. 😂
Same goes for Witcher 3, there's a boat east of Oxenfurt where you can angle Geralt enough to make him "squat stand" as well. It honestly became a habit of mine to just try this in every thirdperson game I play. 😅
Yeah my first thought was Windwaker. They were one of the first games I remember noticing the IK
Stairs used to be this thing I would not notice in games until GTA IV. I still remember when I first played and Niko started stepping on each step and jumping some if running, it was insane.
Thanks for watching the video. Those are some great examples of IK and animations. Thanks for sharing!
My experience with stairs in GTA IV was Niko suddenly being forced into position to climb them. It was the same with ladders. It's pretty disturbing when the game suddenly takes over your character without any warning, you start to panic thinking that your controller might be broken. XD
I think that was the first mainstream game to do it, actually. It was the example when I first heard about inverse kinematics for locomotion.
also recent yakuza game has pretty good stair animations, especially stuff came after 6
Funny enough, you can jump right before the stairs to avoid that state, Niko will slide up them
For years all I've ever wanted was to have my player model in any game actually have their feet match on each step as they go up the stairs, rather than stand on one and slide up a few. A few games have done it but its made the stairs feel more likie a cutscene than being actually fluid with character movement, and I've always wondered that surely it wouldn't be that hard to do. After seeing how much work actually just goes into regular ol stairs I finally understand why it must be so hard for that kind of coding jesus. Thanks for making this vid, it was super informative I greatly appreciate you putting in the time to make it
Thanks! Yes, stairs are more complex than they might seem at first :)
It's very common to think that you want something in a video game, but when you finally get it, it just feels like it gets in the way. Game devs usually know which mechanic you probably prefer, despite you saying want otherwise. If you want to make a character walk up some stairs in a realistic way, you'd have to slow it down sacrificing control for realism.
Check out last of us 2. Stairs looked amazing in that one
I've never seen a game yet where sprinting makes you skip 2 or 3 steps which would be cool
@@aceman0000099Red Dead Redemption 2&3 and GTA 4&5.
Breath of the Wild also has some good examples of making step-ups feel even more natural. On really REALLY short steps it's just the typical smooth looking motion. But as the steps get higher Link begins to do an actual "stepping up" or "clambering" style animation, which influences his movement without interrupting the player's agency, and makes a high step-up look seamless
Yes, animations are just as important to have the animation look smooth as the actual physics calculations.
Mgs2 did it all the way back on the PS2
@@fillerbunnyninjashark271 MGS2 is better than most games from the past 10 years in pretty much every way
I'm not Rockstar's biggest fan, but they have some really great stair mechanics, even in GTA IV, a 13yo game
@@NickMaltbie fun fact: when doing the higher step up animation link won't fall. gravity is set to 0 (probably so that you dont get stuck falling infinitely when doing it). A bug which makes you stuck in an animation and allows movement uses this to perform a "blss" where you just sorta slide around the map at the speed of the Nintendo Switch (trademark) (copyright) (patented)
Harry Potter and the Order of the Phoenix was a videogame that dealt very well with stairs, whenever you were going up or down stair the character moved at a compatible pace, and physically actually stepped on each step like a person would in real life. Actually pretty advanced for a PS2 game, all things considered.
Wasn't that on ps3?
I guess it was multiplatform, it also came out for the PC@@ginogatash4030
@@ginogatash4030backwards compatibility most likely
@@spimbles no I'm pretty sure it was a 7th gen game so if anything the ps2 version was just the usual downgraded port to capitalize on the ps2's dying market and order of the phoenix was the first Harry Potter game for ps3 and xbox360.
I think he’s right about the ps3 I vaguely remember not giving a shit about that game when I was a kid and it was everywhere
Snapping has a really bad problem that you seemed to ignore in this video. When you use the snapping method, many games don't include a decent enough compensation for the camera snapping in turn. This can cause motion sickness in some players, especially if the title is a first person game. This is why most first person games use clip brushes to handle stairs rather than snapping, especially highly competitive games such as counter strike or overwatch.
Thus, as with most game design decisions, the correct answer rarely is one size fit all, but highly a "it depends". Also note that these aren't the only two options, another example are games such as the Yakuza titles that choose to (atleast most of the time) force you to walk up/down stairs normally, with pre-determined animations for each step. These fit better than either of the two previous solutions for games that are trying to stay more grounded in reality, and there are more options out there too.
I agree, the best answer is it depends. The OpenKCC actually uses a slightly smoothed version of snapping where the player will teleport up and forward a short distance when he tries to snap up smoothing out the movement quite a bit removing that jittery feeling.
The code is open source and you can see it here if you're interested in learning more - github.com/nicholas-maltbie/OpenKCC/blob/main/Packages/com.nickmaltbie.openkcc/OpenKCC/Utils/KCCUtils.cs#L179
you should NEVER allow you camera to teleport. you shouldn't even accelerate/decelerate you camera suddenly. typically a camera should be on a collision free physics system, accelerating in such a way as to track some point in space (which can teleport or whatever). if the camera absolutely must teleport, id suggest fading to black and back. or /something/ to avoid teleporting.
unless your in VR. then the camera should only teleport X'D X'D - i think this will become less and less of a problem as time marches on tho
highly competetive....overwatch.... HAHAHAHAHAHA
thats a dream of overwatch... they tried so hard
What is a clip brush?
I was about to make this comment, so glad to see it was brought up.
AAA dev here. To get the best of both worlds between the consistency of step snapping versus the smoothness of ramps, you can use the snapping, but afterwards apply a dampened spring offset to the character model relative to the capsule. With the spring tuned properly, this makes it so you can author the stairs as normal, get the good behavior of the step snapping, but you don't have the visuals of popping up and down the steps. Paired with some good IK, this is pretty much the de-facto modern stair solution. The spring also helps if you have a very rough terrain.
Something that's always weird to me is that stairs usually look proportional when you're playing, but your character always runs up them like 7-10 steps at a time. In real life, if you're running up stairs full speed you can get 3 at a time, maybe 4 if your legs are long. But VG characters just fly up a whole flight in 2 strides.
Haha, yes. What feels fun in a game is often not very realistic.
Somebody running full speed that start to jump to climb stair as fast as possible is likely too look similar. I think... I guess it try to find a video about that, I am curious now.
I guess it's because the player's velocity is calculated on a flat linear planar, so if you have a steep/stairs you will travel same horizontal distance but more real distance from stair start to top (pythagor stuff)
@@attractivegd9531 Yeah that's probably it. Turns it into a real mindhecc sometimes :P
Then again it's not that different from how we have our characters run and sprint all over the place.
Walking? What's that?
Have you seen the escalators in Lost Judgement? I was blown away when i saw the protagonist walking up and down FULLY FUNCTIONAL ESCALATORS, with each foot connecting perfectly with each step, adapting to the speed. Literally the best stairs I've ever seen in a game, and they move!
Not sure of its something you have time for, but if you're ever able to figure out how they worked that magic, I'd love to hear about it. Your way of explaining things is great.
A fun example of a game with no minimum step depth is Minecraft. You can stack up a bunch of random blocks to make very steep staircases
Yes! I find it so weird that most stair solutions don’t use a step depth variable! I had a fun error where you could walk straight up a 89.9 degree angle while programming it as well leading to some funny situations.
You can step up and down in tiny increments in the recent Hitman games, including on and off of items.
@@NickMaltbieah, you were Skyrim Horse-ing 😂
I've made a fair amount of character controllers in my spare time and the floating character method is definitely my favorite solution. It's simple, reliable, and feels very smooth. I would highly recommend it to anybody making an indie game. The very very valet video he references at 3:38 is actually a full tutorial the devs of that game made and it's very helpful, I'd recommend anybody who wants to make a floating character take a look at it.
I’m working on adding it as an option for the OpenKCC in the future :)
one problem i always found with stairs is that they never lead up to anywhere good
Agreed, but people still insist on adding them :’(
I dunno man, i once found the stairs to your heart and it was pretty cool
@@dztrict1000 sheesh my man has w rizz fr
@@errorstudioz rizzard
That's because they're always up to something!
“To fall properly you need to get high”
-human fall flat tutorial guy
TF2 maps mostly cover stairs with ramps, but there’s a few maps (or a few sets of stairs) that don’t do this and instead you snap to each step. It’s noticeable when this happens. Your view snaps to each step with you and it can be jarring. The ramps are a good workable solution.
I guess, the best stair solutions depend on the type of game. For FPS games, you probably just want a ramp to make it simple.
I agree completely! I can empathize this more in future videos but ramps work as a perfectly serviceable solution especially if you can devote the extra time to level design.
It doesn't have to be one or the other. You can design a good camera system that doesn't flip out during snapping.
The worst part about stairs in TF2 isn't walking up or down them, it's shooting a rocket and having the geometry absorb the splash damage so that the scout standing 3 inches from the rocket doesn't get hit.
@@BasikMMTXC Yes, but that can be very easily solved by using a Block Bullets brush instead of a Player Clip brush.
Counter-Strike has had a problem with Dust 2's spiral staircase, where just making a ramp isn't easily feasible due to engine limitations: ruclips.net/video/qpeDBPPn0I0/видео.html
Back in my early days of programming I solved the "stair problem" on my kinematic controller with an absolutely overdesigned solution involving a whole bunch of casted sloped colliders and edge case handling. The colliders would cast forward at the character's feet and essentially act like there was a ramp there for them to walk up. It was fairly rigorous but it was absolutely unmaintainable and not performant and was not entirely free of weird edge cases. This was before I had learned that simple is usually better.
Yes, and being able to disable any comped solution behind a feature flag is also important. That’s why I like the checking cast forward and up, it’s only one extra step and the code ai relatively easy to follow.
On snaps: They can be EXTREMELY disorienting for VR. The sudden up and downs on climbing steps can feel horrible, even for somewhat experienced VR users. The "ramp" approach feels better in taht case. :P
Yes, snaps even without VR can be very disorienting. The ramp can be the better case in those scenarios. The other option is to lerp/interpolate the camera position to move smoother and avoid that snappy feeling. There is always some compromise to make between these decisions, but I think this is a fairly good result for most use cases. And the snapping still works with ramps because it's skipped so it's almost a sub case of the current use.
Oh, I had the line of code wrong, should be this AttemptSnapUp function - github.com/nicholas-maltbie/OpenKCC/blob/main/Packages/com.nickmaltbie.openkcc/OpenKCC/Utils/KCCUtils.cs#L261
@@NickMaltbie It is a fairly good result to accomplish the same thing as making a ramp but also make players sick or unable to play? You said don't settle for less but you're actively kicking people out of a game.
That is by far less.
I smoothly move the player up, as if they're naturally climbing a step
if VR doesnt have legs you can see you can just use the ramp method and skip everything about stairs
0:04 I know a guy on the west end for that
The absolute best solution for this problem for me was shortening the capsule collider up to the knees and adding a downward-facing raycast that checks how far the ground is. It then lerps you to the raycast position every frame. So far it hasn't failed me and I'd assume it costs less than checking contacts
Yep, much cheaper and simpler solution. And the player probably wont' walk higher than their knee height so it works pretty well. The only downside is that now your character's "grounded" state is just a point and not the whole collider shape and can slip between or off small ledges. You can get around that with a sphere cast but then you might as well have the whole character be that shape... It just gets more and more complex but it definitely a cheaper solution. If you were to make 1,000 agents run around a scene it would be a lot simpler and more straightforward.
Thanks for sharing the solution and ideas! Having a floating character is a very common solution and robust for most situations. I originally designed this character controller so the player could be any shape (or even a composite shape) so assuming the player is a capsule or even that they have knees might not always be true.
@@NickMaltbie When i was playing with Unity years ago, i solved this by having, rather than ray cast, a second collider below player character. The colider would be allowed to clip through geometry, but you were able to take collision information to do what the raycast does + more.
@@chubbygoat Mate I just checked your game out with absolutely 0 expectations and I was damn near blown away. The map just kept going on and on and after shooting like 200 potatoes I actually started feeling bad about killing these benevolent creatures. The sounds are on point, movement is smooth and the details are amazing. I'm talking about chunks sliding down walls, holes being punched in potatoes etc... Simply an awesome game with crazy potential!
Now, I do have a couple of questions. 1) Did you use decals for the "blood" and if so, was it HDRP? 2) Did you make your own sounds? and 3) How do you throw grenades? I can't find anything in the manual.
As you can see (on my channel), I'm making an FPS game and questions 1 and 2 have been driving me nuts...
Cheers!
@@NickMaltbie Oh yeah, I immediately assumed the player was going to have a humanoid shape. I didn't think of horses and the like. Also, I just figured out that my character falls through mesh that's riddled with holes (although it snaps right back up when you start moving) so an additional trigger for isGround would be appreciated. But all in all it's a nice solution for rigidbodies if you need physics and you can't rely on character controllers.
@Daniel Beard In my case i was trying to make a player controller that was able to support movement similar to Tribes games - where you could press a button that turned your shoes frictionless, and you could slide downhill to gain speed and then use jetpack to go over the next hill, land on down slope and keep building up speed this way.
I needed the vertical separation from the ground because of high speeds the physics inaccuracy would push player into the terrain between frames, resulting in weird bounces on sudden slope changes, etc.
Adding 2nd collider allowed for kind of hover behaviour that avoided this.
And for having different modes, you don't even need to turn on and off coliders, you can just have conditions in the code that handles bottom collider. What i've done is small state machine - depending on player state (walking, running, skiing, jumping, etc) different function would be called on collision detection.
I'm not an animator, or game dev, but stairs in games always mattered to me. The ones that bother me are ramps with stair textures. I would rather they used ladders if they wouldn't want to animate stairs properly, especially in games that are aiming for immersion.
Bungie hated old fashioned game ladders but I loved them. Valve loved ladders but their players hated them. But yeah, ramp stairs are goofy. ❤😂
I prefer the ramps because ladders feel slow
lmao u think they wouldnt have to animate a ladder climbing? whats easier - doing nothing and adding a ramp, or adding a complete new way the character can move?
Can you sound more annoying, please
Using snap up/down code is all fine and well, but people don't rigidly move over obstacles as we naturally keep our heads at a steady height. To accurately move characters over small obstacles and up/down stairs in a realistic manner you'd have to predict that your character is about to go up/down and make the IK legs anticipate changes in elevation, followed by smoothly interpolating between the heights.
There's research papers on this (Phase-Functioned Neural Networks for Character Control, Daniel Holden et. al, 2017), but that's really getting into the weeds of things. Ultimately anything less than neural networks and predictive movement is a compromise, but games are made on compromises for reasons ranging from performance to game feel, and more. I mean, competitive shooter games might even opt for ramps only so that player heads (the main way to define skill by clicking on them) aren't jerkily moving up and down that would otherwise disrupt player aim and cause missed shots.
Personally I still prefer the invisible-ramp-inside-fake-staircase method for its consistency and smoothness despite the additional work for non-stair steps (and even that might be easy to solve by "baking" a level's steppable areas like you would bake a lightmap - and for procedural levels it wouldn't be too difficult to add additional checks as to where invisible ramps should go in the level generator code).
Hey, thanks for the comment! I really do appreciate feedback on these videos and love sharing this project and getting other people’s opinions. I actually have modified the code since this video have the player smoothly slide up/down steps at whatever their movement speed is to avoid having the jerky camera movement.
I think it’s perfectly fine to use ramps and invisible colliders if it serves the purpose in a game. As long as a level designer is willing to put up with two layers of colliders (one for player movement and one for IK/animation and everything else’s), you can usually make this work. Or if you write some fancy automation to handle that generation of a secondary collider for player/avatar movement. I’m releasing this as a library though so I at least need some solution :) and, this stair solution is actually generalized and works just fine with ramps and can be disabled and revert to the previous behavior.
These videos are always a compromise in making these videos and I think I didn’t even have time to discuss some of those tradeoffs I made while designing and iterating on the step code. That’s one reason why I like the fact that OpenKCC is open source, people can view and modify the source code as they need.
I’m definitely interested in adding procedural animation to the project and I’ll be sure to check out that paper you linked! Neural networks might be overkill for this project but having some intelligent way to mix and set animations or values would be interesting. Since adding the cinemachine library I’ve looked more into having the player model move somewhat I depend rely of the avatar and it seems to be resulting in some good changes. With vertical dampening you can get around some of the jittery changes on steps or slopes as well without bouncing the character everywhere.
@@NickMaltbie Glad you liked my rather verbose reply (I hope my tone was neutral enough - I'm terrible at communicating tone via text). There's a few videos about the study and its implementation by various people on RUclips as well if you want to see it in action. It's neat, but yeah, for smaller indie devs and people just getting into gamedev (or shaking off the rust like myself) it's definitely overkill.
And I forgot to mention it in the first reply, but thank you for making it FOSS! I look forward to seeing it evolve and potentially even have community contributions. I rely on a lot of FOSS applications (Linux/Gnome, Godot, Krita, Audacity, etc), and it's people like you who help keep the dream alive. Every little bit helps make the greater tech community and our software/devices even more awesome.
@@MajatekYT thanks! No problem with tone over text. I always try to assume that people are trying to be nice. Always like sharing open source projects like this because other people probably will find it useful and be able to help improve the project for everyone.
People keep their heads level *somewhat,* but not nearly as level as, say, a chicken does.
My head moves around a lot when climbing stairs. Having just my legs going up and down while my head goes smoothly up a slope would look pretty ridiculous by comparison.
Like, it would look like I was doing a bit.
But the brain is good at hiding all that motion so that it's not disruptive to our continuous perception of the movement. So how much of that "brain feel" versus how much of the "actual head motion" you want to portray is I guess a matter of taste.
Star Citizen went to great lengths fine-tuning this, in their attempts to make the first person camera always reside in the actual head position, for example. It's kind of a hairy problem that involves compromises no matter what, like you said.
@@delphicdescant Yes, when climbing. But when going down, my head moves in a straight line if possible. I noticed this recently when I noticed I had developed a habit of putting on my garden slippers to go down the stairs in my house (I'm usually barefoot at home). This prompted me to pay attention to my movement patterns. When barefoot, I step onto each step with my toes about half an inch away from the edge, which results in a jerky step-by-step movement. With my shoes on, I step directly onto the edge with it between my toes and the rest of my foot, which gives my body and head a ramp-like travel path. This feels like the ideal path to me, and I even started missing it when I'm in my street shoes on stairs outside my house (negative factors: unfamiliarity, stiff soles, no handrail, soft/slippery edge, bad geometry).
I do not feel high enough, but I don't think my solution is climbing or stairs 0:10
I am a gamedev myself and I think it's a very interesting and well made video and 3d visual animations are very helpful!
Thanks for the comment. These 3D animations were actually what I used to debug errors and I realized they could be extended to work for videos as well to help explain how they work. Character movement is more complex than it might seem at first and it’s nice to have visual aids that integrate well with the game engine.
Before stair motion can even be fully considered i feel that matching the characters moving speed and animations is really important, if it looks like your feet are sliding under you even on solid ground because the speeds don't match, stairs will never look natural even with a perfect all encompassing stair solution
I saw a video about wheels and terrain, and formulas to calculate how any shape can be a wheel with a specific terrain. The most common one is a square wheel, which it's terrain is just bumps that look like half circles in 2d or half cylinders in 3D.
Smoothness was defined by having a point inside the shape that remained linear in motion taking into account the wheel and the terrain. Maybe something like that could be done to solve the stair problem.
Define a point that you want to maintain linear motion, like the player torso, and then make the bottom half of the player adjust to the heigh difference between the step you're on and the next one and rest the difference to the upper half so it maintains the same height no matter what the bottom half bumps into.
Somewhat like wheel suspensions.
Yep, balancing smooth motion and climbing up steps is a hard problem and suspension is a great analogy! thanks for sharing the design and description. It's a very close solution and all different parts have tradeoffs and benefits.
I love the way the characters go up and down stairs on Resident Evil 1 Remake. You should check it out! It feels really good and it doesn't have that awfull thing where a character seems to ignore the stairs' geometry completely
4:24 Valve has been trying to figure the whole curved staircase thing out for the past two decades... they know how painful it is.
Haha, seems like it would be straightforward but not always as easy as it seems!
3kliksphillip made a nice video about this a few years ago. While hidden ramps do add a little work for the map makers it makes them so much better to walk on. It's crazy jarring when you go over some normal stairs and your view jerks upward on every step
It all depends on the game as well. You could smooth the camera's up/down axis to lag behind the actual location by a foot or less. This actually makes the camera feel very smooth but in CSGO imagine if you stopped moving on the stairs and your camera was slowly drifting up to recenter the camera. It'd feel annoying in a twitch shooter. In something like dishonored or thief it doesn't effect your gameplay and is barely noticeable. So hidden ramps or what 3kliks called stair clipping is really the best solution for CSGO that Valve could come up with. Pros and Cons to every solution.
I wouldn't be surprised if this has already been said, but there's a better way to do the snap method. Checking collisions and teleporting upward is risky if you're in an environment where you have a lot of collisions going on. Weird geometry, especially one-way colliders, have the potential to break it significantly if something goes wrong. Also, it's tricky to know for certain if a collision is happening due to the player walking into a step. This is all stuff you could filter out, but requires additional work to identify each of those cases and account for them.
A safer way to do effectively the same thing is to say that any situation where you'd move the player forward, you instead actually move up, then forward, then down, all instantly. On a flat surface, the up and down movement will be completely canceled out. If you walk onto a step, you will move up, then forward, then the step will stop you from moving down any further and you are simply on the step. This solution excels at handling weird geometry and unusual situations because there is very little that can go wrong. Everything that happens can be accounted for during that stepping maneuver. An example of this is how to handle minimum step depth - during that forward step, you can test to see if you are able to walk further than the minimum. If you can't, you rewind back to the original position and only walk straight forward with no stepping. Pure math and movement checks, no waiting for collisions. Far more elegant.
One complication with this is that when moving, the size of the collider will appear to be slightly taller, as you will hit up against low ceilings. You could account for this by reducing the height of the collider specifically while performing this up and down movement, but you would not want to do that at all times because that would change other collisions.
I believe that the unity default character controller does exactly this, but I am unsure.
And for what it's worth, I agree with some of the other comments that in most cases, a floating character controller is better overall. But it does have some tradeoffs, and so if you find yourself needing a step-up solution, I would point to this as a more elegant alternative to collision detection and teleportation.
Why not have the player collider use the ramp, and have the IK use the stairs? You could also sorta "flatten" the ends of the stairs so that going up the stairs isn't a constant motion. The ramp at the edges, combined with the IK snapping to the flat stairs, visually simulating the effect of the character's legs pulling the rest of the body upwards.
So many people have been suggesting this, I'll have to make a follow up video with a demo like this. It should work in most cases and replacing the stairs with a ramp is a nice simple solution if you can add it to your game.
You don't need any of that. Your pelvis and head and camera should work independent of each other for motion. There shouldn't be any snapping that needs any solving of extra steps or hidden geometry.
I heard of a case between BOTW and TOTK, where in the latter game Link's ladder climbing was changed, including having him jump farther up the ladder when beginning to climb. A result was that a really short ladder on the top of Hateno Ancient Tech Lab became unclimbable because it's shorter than the distance Link jumps up it.
do you have a video link talking about this case?
OK before the final solution comes up for me, here's what I think: Use a ramp collider on all steps, and give your player two types of colliders. A rectangular or triangular one for each foot that collides with the visible step using IK animation, and a capsule one for the root of the player model, that collides with the ramp. Depress the ramp collider into the stairs *just* enough for the feet to be able to travel down to the step without stretching the model.
The player should slide smoothly up and down the steps, (which would have to have their angle defined by the level designers) and the feet should reach down to meet the actual step at the same time.
Essentially: "Don't do that. Just make it *look* like you're doing that!"
You're moving up and down a ramp that *looks* like stairs.
Yes, this is a great solution many games use to get around the issue of stairs entirely, simply pretend they don't exist but move the feet like they do. It's a great solution and works for most simple cases.
A very common variation is to run a "body" capsule at just above the step height, and then do a sphere cast from that position down to the ground. It's effectively the same thing, but ends up a little cleaner code and you get fewer re-tries if you have some jagged terrain and potentially a low ceiling, where you have to re-try collisions after adjusting height. But otherwise, this is fairly standard. There's some additional magic a lot of character controllers will do for hip offsets to reduce IK over-extension and to also make the character movement both up and down the stairs a bit more smooth, but that's sugar on top.
Yeah, I noticed this floating capsule solution during my research but didn’t try to implement it as snapping seemed simpler. I made a follow up work item in the open source repo to tackle it in the future :) github.com/nicholas-maltbie/OpenKCC/issues/189
Just need more time to address these issues!
fun fact. Source engine uses the same snap up and down idea you are using. but they set the minimum snap depth really small. so you can literally climb up a near 90 degree wall as long as there are tiny 1/16th in ledges every foot up.
Thanks for watching the video and leaving a comment. Haha, I didn’t realize the snap depth was so small. Different games need different solutions so it’s good to have multiple ready to use when designing a game!
as someone who isn't any sort of game developer, i find that i don't think about stairs in any sort of way but this video has shown me just how complex all these stairs i have ascended and descended in games, and you looked at the third person pov, first person i would imagine would be more complex as having all those bumps up the stairs might be a motion sickness issue with all the jittering happening. that aside very informative video now whenever i ascend and descend stairs in a game i will know just how complex they really are.
In my experience (and I have written sphere sweeping) your capsule will go over low steps and rough terrain just fine. Getting the animation to look realistic is a different story. Also an overhang will make no difference if it's low enough. It has to be under half your bottom sphere but maybe a 3rd is better. But it reacts the exact same as a regular step.
Honestly the main thing is just don't move the camera so there's a weird bouncing effect. The camera should behave like a ramp but the player should move
It's generally still better for a level designer to add a ramp their stairs even if the snap stair movement method is used as it makes stairs look much smoother.
Yes, if you have the resources and skills for adding ramps and it fits your game, it’s a perfectly good solution.
@@NickMaltbie i did this for a game from 1999 called unreal tournament. moving up stairs was very annoying for other players as it would warp the player and causes you to be 'warpy'. i added invisible ramps which were perfect for the gameplay there. the videos is called duku stairs before/after if you want to see how bad of a difference it is in that game.
i think counterstrike uses the same thing for clipping stairs by having invisible brushes made in the editor.
Okay, turned this on on my TV, and pulled up my PC to comment. You're RIGHT!!!! I was not high enough for that intro. Really intrigued by the concept though, so excited to learned something new. Here's a like for the intro.
Something interesting, ive been into game development for like half a decade now (and sadly am not really close to being in the industry because that's less knowing what to do and more networking skills...) but one thing I can say is... This is exactly what ive done in 2D with gamemaker studio. But instead of stairs its slopes, but they are pixelated slopes. So effectively stairs. And the tutorials ive followed for that work in the *exact* same way. Which is ironic because as ive started working with Unity ive found they do slopes in Unity much differently.
Yep, a lot of game engines run into the same issues. Happy that you found this interesting even for platforms besides unity.
Why is this literally the most helpful video I have ever seen?
I was wondering if a non-dynamic floating capsule could help you (similar to the Toyful games method but without using forces). In essence, always having your collider a certain distance over the ground, this distance being your step height.
That’s a great observation. I actually do have the capsule float above the ground by anywhere between 0.001 and 0.01 units to smooth out any error the user might see. Although the rest of the algorithm is the same. Allowing for around 0.1 units of wiggle room helps the steps look much smoother!
This is what I used in my game and worked perfectly
Would be neat to have an A.I. control the character model rather than these smoke and mirror tricks. Let the A.I. study how humans interact with things, and then let it decide how the model should react when a player gets into a certain situation. Maybe even have the developer train the A.I. by telling the A.I. what the character should be able to do as the developer attempts to make the model do the thing.
I don't even know if that's possible, but it would be a cool way to teach a character controller what animations should occur in certain circumstances. Basically, give the A.I. a virtual body, and let it figure out how to interact with its world.
I have to say, it depends on many things if this solution works for your game or not.
For example using a ramp or having a capsule collider just hit the step doesn't work on some physics configurations.
The same goes for your snapping technique. It works like you said in most cases. Many games like sonic on sega game gear even made extra physics checks on the player for edge detection and so on. Which you get for free with your stair check if done correctly (correctly means in game dev if it fits your game, because there are multiple solutions to that as well).
Snapping the player might have two issues for example:
1) the rough camera movement might look strange and might be better with a "ramp"
2) if the player as physics entity can move boxes around and so on. This snapping might depending on physics engine create a big force because of the moved in 1 frame. Let's say you have 15 cm stair and a 50 Physic Updates per second then you moved the player in that frame with a velocity of 7,5 m/s or 27 km/h, which is a normal human full sprint against an object. If you snap that upwards in your physics engine this might have unexpected behaviour to the game simulation. So depending on what you want a jagged foot on a "ramp" is the better option.
Don't get me wrong, the video and information you provide is awesome!
I've testet your Controller in the Browser Link you provided. I can make the character fly above a stair:
ibb.co/FwpmwKt
Hey, thanks for checking out the video and leaving a comment! Also, with that demo image, I haven’t setup IK yet so the player can float off the edge of the collider is grounded but their feet are not! More to fix in the future.
I actually improved the snapping algorithm a bit since the video was published to have the player smoothly slide up a step at the rate they are moving forward (could still use some work but a much better solution, you can see it live in the demo now). Also, since the player is “kinematic”, they aren’t controlled by the regular physics engine so all that collision code is handled manually and can be capped to be within a max velocity.
Although I agree it’s good to have more options. You can disable the snapping in the OpenKCC config via the stepHeight variable and use ramps as well - nickmaltbie.com/OpenKCC/docs/manual/usage.html I should probably make a follow up directly comparing all these versions since so many people are talking about them and interested in it!
You mentioned the floating method. When I was trying to solve this without looking at tutorials cause I'm stubborn and wanted to solve it myself, it felt so good when I finally figured out that I can just make the collision float and maintain a minimum distance to the ground. It's so incredibly easy compared to all other methods. I don't get why you didn't talk more about that one. Of course just making the collision float is just part of the solution: I also made the character move along the normal of the surface instead of directly where the input says, changed the speed depending on the angle, etc.
The trick of having Tha character just "float" above the ground sounds very nice, the hidden with their feet and stuff, might actually work well, I want to try that. Very nice video!
Another graceful solution to consider has to do with physics masks.
Since the movement of the player you're attempting to achieve is that of a ramp, and the problem you're attempting to solve is to do with the IK'ing or foot visual placement, you could instead have a more detailed physics mesh that is accurate to the steps *and* a ramp. The ramp is set such that it only interacts with the player capsule, and the higher detail mesh is set such that it only tests against IKs.
Solving all the other "step-like" cases (via a similar raycast clearance check like you're describing) is generally much simpler if you can eliminate stairs from that equation.
This was a great video! Thanks for making it!
The first retro game that comes to mind when it comes to high-effort player character animation for me is Jak and Daxter, so this video made me try to remember how stairs are handled there. I then realized that everything that could be considered stairs are exaggeratedly large, adjusting with how far into the game you are. (The steps to the final boss each being twice Jak's height.) The idea that they did that partially to avoid stair-step animations is really funny to me.
This made think about super Mario 64 which did snapping
Someone referring to a ps2 game as retro made me feel old as fuck
I have a couple problems with this video, but let me take the lead on this instead of complaining. First, a character controller can help determine what is an acceptable slope. Secondly, your stairs foot length should be relative to your animations making relative sense with the speed at which you move. Next, I use a ramp shape as a trigger. This can tell your camera to ignore the bumpiness by slerping. Lastly, you can make an event that triggers the use of a separate animation and movement speed so that it feels clean or choose some other result. I personally use Unity's free addon of generated inverse kinematics for this so that my feet will always match the steps that I walk.
Nice video but you forgot to mention the easiest trick in the book: using an invisible plane with a special collision flag for feet collision. It's extremely cheap in terms of computations and provides the smoothest surface possible, you won't have any head bobbing in First Person view no matter the steepness so it works very well for FPS. Only drawback is that you have to set them up manually (but in most cases you have to create invisible walls in the level anyway) and they're not the best for spiral stairs with short radius (but these are rare in video games). This technique is used in World of Warcraft for both straight and spiral stairs.
Also I don't think OW use a custom collider for climbing stairs, the body collider is actually much higher than the character's feet (somewhere around the knees). Instead the ground probing is achieved with a raycast and the feet position is smoothed to prevent jitter. For stairs and nearby floors, I believe the topology around the character's feet is analyzed to find the best possible floor height. This allows the character to stand on nearby platforms, even if the character's feet don't touch the platform.
Yes, these are all great ways to tackle uneven surfaces in games. I like the idea of a floating capsule as well, I might add it as a separate kind of KCCMovementEngine in the future since so many people are suggesting it and it's a natural extension of the current movement engine. Also, I'd love to add IK to the project, but it will take some time.
I really appreciate this kind of content, I started making games when I was becoming a teenager (I'm not sure what is the correct term in english).
But only recently, I started to realize that games aren't made with special assets, systems and engine features taught by famous tutorials that solves your problems magically, instead it's a endless problem solving process, and with problems that you never really thought existed until you start making games, like stairs.
Really nice content! Videos like these desmitifies game development!
I've seen Lost Judgement(Judgement is a spinoff series from the Yakuza/Like-a-dragon series) do some really impressive foot kinematics with actively moving escalators.
this is really interesting to me specifically because of how much I play Destiny 2. that game has highly detailed environmental collision boxes that can be somewhat frustrating to deal with because of how they interact with wave generating projectiles. There are a number of weapons in that game that have projectiles that generate a damaging wave that travels along the ground based on the direction the projectile was moving as it hits the ground, and this almost guarantees that if you try and send a wave up a staircase it will hit the face of a stair, bounce off, instantly hit the surface of the next stair down, and then send the wave down the stairs toward you. there's also plenty of other heavily greebled angular environments that will do this to you if you're not careful with your shot placement (especially vex architecture.) I always figured it would have been so much simpler for them to just make ramps and hide them like you mention, but this video has given me so much insight into the problem that it is clearly more complicated than I gave them credit for.
Great video. I might have to give your KCC a try this weekend at the GGJ. Maybe get crazy and try to implement it in a networked game.
Good luck with the GGJ project this weekend!
I wrote an extension for the OpenKCC using using unity’s netcode multiplayer if you want to try it out. There is still a bug with synchronizing position on moving platforms (player sometimes jitters a bit) but otherwise it works fairly well.
Pointing out the 11 minute runtime like it’s a long video is so funny. I half expected you to say it was like 3 hours
I’ve been watching this guy make content for 23 years, he has always been awesome! I still have trouble walking up stairs irl sometimes
Thanks Bro 😎
Where was this guy in the early 2000’s?
Great vid! Thx for adding SMO clip!!! Made me smile.
There's a handful of games I've played in which the devs created an entirely separate animation for going up or down stairs and with how complex the whole stair problem is, I have so much respect for them. That must've been one hell of a project lmao
Regarding "snapping the character down to the ground to not fall down stairs", one neat trick I've found for myself was to make the length of the downward cast proportional to the character's horizontal movement during that frame. You simply multiply the length of horizontal movement by a factor of your choice. Larger factors support steeper slopes, and smaller factors flatter slopes (I've only tested it with slopes, but I'm pretty sure stairs will work, too). A factor of 1 would support walking down 45° slopes. With a bit of trigonometry, you can even rotate the formula so that the user can specify the desired maximum angle and the cast distance automatically gets the correct multiplier in regards to that setting.
Anyways, I think this way of handling the snapping has a few benefits:
1) You don't need to manually configure a cast distance based on feel.
2) The differentiation between walking down slopes and falling down is automatically handled for you (anything that goes beyond your desired slope angle is considered falling).
3) This method is stable across framerates and even scales with player speed. So if you have a super long slope at a constant angle and the player is running down at 100 miles per hour, as long as the slope angle is within the threshold you configured, the player will still stay on the slope and not start falling. (Well, I guess it could be argued that this isn't really physically accurate, but I think for games, it's usually what we want).
4) You can mostly prevent that issue where the player visibly snaps to the ground near the bottom of stairs.
There might still be situations where a fixed cast distance will work better, but for my personal needs, this turned out to be a great solution.
Hey Nick! What a great video. I don't even make video games, but as someone who finds programming interesting this video was amazing! Even though it was entertaining and instructive I would've really liked to see clips from games where stairs were NOT implemented correctly. While I am writing this I realize you might have done so without me realizing. If that is the case I would like to apologize. But for someone like me who doesn't have a lot of experience (or none at all) with making video games I would appreciate if you could have told us what is correct or (close to realistic or the most used solution) while shwoing examples of both, While watching the video I was not sure if the character was considered moving smoothly or realisticly.
Anyways, this is an amazing video and you have certainly earned another subscriber.
Thanks for the feedback on the video. I'm still pretty new to making instructional/educational videos for game dev. I think presenting clear cases of what works and what doesn't would be a great example. I'll make sure to include this more clearly in the future.
No solution was "correct" or "incorrect", it's always a compromise. However, I can create situations where the character specifically moves incorrectly or has a difficult situation to navigate.
i cant believe this guy doesnt have more subs, he def deserves at least triple what he has now because this is good content
5:03 "you can't hide the stair problem, you just put that work somewhere else" great line.
I really liked, really liked this. Presenting historical solutions, then ultimately a solution 'better' than those, and mentioning which cases were covered and not.
Thanks! Those old solutions still work for certain situations and designs so it’s useful to have all those tools when making a game.
never knew there was so much to know about stairs in video games, very educational and thnx for bringing this to the public. Hope many nice things come from it.
Just look at literally any game from Naughty Dog. They mastered stair animations since Jak & Daxter and it only got better from there. TLOU has a completely separate animation set that activates when the player interacts with stairs, making climbing stairs slower, but more realistic because the feet land on each and every step perfectly. Naughty Dog's inverse kinematics systems overall are just mind-blowing tech in every example they come up in.
is there anything you might recommend that specifically covers that?
Their solutions and animations are really awesome! I want to add IK to the project in the future, but lots of features to work on.
What a great video! I'm surprised you have so few subs--well you earned one
Metal Gear Solid does really good stairs. It locks you into an animation.
Ooo, animation and stairs is difficult. And so are doors. Lots of big challenges from places you wouldn’t expect in games.
I'm not even a game dev (Wish I could) yet, but still I love watching this type of content, good job mate :)
I've always use ramps/slopes for my stairs, just got used to it from using Hammer editor half my life.
Yep, it's a simple solution that works well for many scenarios. Ramps are an easy way to avoid stairs.
I’m pretty sure this is why a certain funny glitch can end up occurring with this solution, in destiny (the game I’m most familiar with) we can actually abuse stair snapping by using it to gain extra speed. On certain sloped surfaces (aka stairs) if the snapping speed isn’t instant (usually not to avoid it feeling clunky to walk down stairs) you can actually have just enough horizontal speed to get the down snap just as you leave the snapping threshold horizontally but then you still get pulled down by the snap which places you into the threshold of the next step to snap you down then aslong as you are constantly leaving and reentering the snapping threshold horizontally your character builds up speed very quickly which results in a massive burst of speed as long as you then leave the stairs without becoming grounded… a bit hard to describe but if anyones interested and can link a video of it happening
The discussion under the video is amazingly academic. It deserves to be summarized into a full paper.
How do you handle the movement with the rotating platforms? Check your ground cast for a rigidbody and apply their velocity to yours?
Bit of a complex solution actually. Before the player moves it checks for motion in the object below it and corrects to maintain the same relative position. It also has a bunch of complex logic for handling other situations as well, but that’s a future video topic :)
I think anyone who's tried to write a character controller for a game knows how much of a headache stairs and slopes are
Yup, and especially when the developers of the engine don't work with you. In Godot, you used to have to be very clever to solve sliding down slopes for instance. And, the developers acted as if this was fine even when you turned off sliding on slopes.
I think this is a great video! With procedural animations, stairs are pretty simple to create, you won't need to have in mind the player speed either because the dot that follows each set of stairs is relative to the position of the players legs :)
I think for most games, a fairly practical solution is to separate the collision mesh from the visual appearance of the stairs. You can then base the position in which the character is shown on the terrain mesh. This allows the camera to move smoothly up and down, while also making your character look like they're firmly grounded.
It also signals intent. If you just leave it up to the physical characteristics of the terrain, you might get situations where a player can walk up something they're not supposed to, like for instance up the seats of bleachers. What you want to allow the player to do in situations like this is going to depend on the kind of game you're making.
Not everything needs its own collision mesh though. Most terrain will be fine with either using the terrain mesh for collision (like slopes, floors, paths, etc), or not having collision at all and just use IK to smooth things out (thresholds, cobblestones, branches, etc).
Of course I agree that it would be ideal to use a one-size-fits-all solution, but in practice that often ends up being more restrictive than liberating. I think a separation of the different concerns of rendering, movement and IK is a far more elegant solution. And you can define all three for each of your terrain elements depending on their intended function, which will allow the level designer to place them down without worrying much about it
Your stairs then come with a sloped collision mesh pre-installed, so no matter how steep or shallow they are, they function like stairs. If you don't want your stairs to function like stairs, you can add an exception for a particular instance of that element... or better, place down a different element that wasn't intended to be walked on top of.
The only real snag with this system imo is if you want the same element to function differently in different situations, for examples because either the player or the terrain can shrink/grow. In that case, it might be better to use the system you present in this video, since the intent is to let the player traverse big objects not meant for walking on when they're large, and stop them from walking up even small steps when tiny. So if the intended way for a player to interact with something changes over the course of the game, you want a way to deal with that.
It's always tempting to design things like we see them in the real world. In the real world, if we can touch an object, we can stand on it and collide with it. But this isn't a design feature. Rather, it's a restriction. We build stairs precisely because we can't walk up walls when the need arises. We want our game to mimic the way things look in real life for the sake of familiarity, but that doesn't mean it has to work the same way under the hood, unless you want the amount of extreme realism from your game that really only VR games could benefit from at the moment.
In conclusion, this is what my critique on your movement system boils down to: it doesn't have a concept of intent, and takes any non-visual design work out of the normal level and world design processes. I think that in most cases, "intent" is a crucial thing to have at your disposal when designing. You want the player character to interact with the world as the world wishes, not as the player character wishes, or you'll run into lots of problems later where the intent of your design doesn't match what the player can actually _do_ there.
These different elements should not be made to rely on one another if there's no need for it. It just makes things more complicated. There's something nice and declarative with having collision, appearance, and other such properties separately defined on level elements, and it makes it easy to fix problems without having to introduce a whole host of new ones. It's a flexible system, whereas this one is inflexible.
Ask yourself what you will do if your level designer comes to you and says, "I want the player to walk up these stairs, but they can't. I also want the player to be unable to climb this slope, but they can." Are you just going to tell them "that's not how physics works, so deal with it"?
I don't think this video or your work on OpenKCC is useless. Far from it. It's very impressive. But I think it's also important to realise and accept what its limitations are, and what it is _not_ suited to.
I think you put into words exactly what bothered me in this video.
"that's not how physics works, so deal with it"?
Yes? If something looks climbable, it should be climbable. Consistent rules are important to immerse the player. It's basically the entire point of the genre "immersive sim".
@@phasmidjelly1429 The physics system does not decide what the player expects to be climbable, and neither is a physics system simple enough to be a comprehensible ruleset.
Furthermore, you argue the importance of player empowerment and immersion without ever considering how prioritising these things concretely affects the player experience.
These ideas of empowerment and immersion can certainly be reasonably applied to your _experience_ of a game; if a game makes you feel empowered and immersed, that's fun. But they're far too vague to guide the design process.
If you want to design a unified, comprehensive experience, you shouldn't put the power to decide what you can make in the hands of an arbitrary system. That system exists to support your intent as a designer, so you should have the power to make it do what you need it to do.
Saying "that's not how physics works, so deal with it" is shooting yourself in the foot. It shows that you believe your value as a game designer is in how closely your game can mirror people's expectations.
I'll be blunt: if you limit yourself to designing only what people already expect, you will never create anything memorable.
The real power of a designer lies in their ability to _set_ expectations. A good game designer can make the player expect almost anything, including that they can walk up those steep stairs, but not up that shallow slope.
The only solution that i could think is making especific animations for stairs by "press a to use" and you go up/down or to have the entire animation controlable by limited controls, up/down or align with the camera angle.
And this "auto-animation" will have 4 versions: walking up/down and running up/down (last two skipping some degrees).
The good side is will be more realistic, but other side is that will cost so much time because you will have to make an animation for each stairs or make an entire engine for just the stairs locomotion.
Thats why stairs is just another ramp.
What method do you think Rockstar uses in Grand Theft Auto V? Walking up and down stairs in that game feels quite realistic from my experience
Having a game play smoothly and look realistic are sometimes at odds. To have something look realistic animation IK and good movement tracking are important. Smooth “looking” movement can actually feel weird when playing a game because when you walk in the real world, it’s not a consistent speed. But seeing your character constantly slow down or speed up can feel weird in game so most games smooth movement.
Right. You could code the player character to deliberately step up the stairs by targeting each step and animate it perfectly, but what if you have to stop and go back? What if you are fighting an enemy while on the steps? This is where it's easy to over engineer a problem and make is worse because now you have to account for every edge case.
@@NickMaltbie Nice way of not answering his question, because you don't know how they did it because you don't actually know anything about the subject you're talking about.
This is like modern egyptians discovering ancient egypt and not knowing what it is. The works been done, people already know how to do this stuff well. Just because you've discovered the problem making your shitty indy game for the first time, why do you think you should be making a video on this like some point of authority?
Watching a video about something that I'll probably never gonna find any use for in my life is always a win
0:30 you repeated someone's else joke just told, but made it worse
Programmers aren’t known for their sense of humor. Just check my git commit history.
No one credits the person who made the chicken crossing the road joke
@@HimKnot But you don't repeat it 25 seconds later in front of the same people
Really makes you appreciate the finer details of game development, and especially the fine touches like Link looking down when he goes down steps or up as he approaches a wall in tears of the kingdom
This is awesome! I wonder how this compares to the Unreal 5 equivalent and their new ik hand and foot stuff. Give’s me a better understanding, as a 3D artist, of level design things to be aware of!
I appreciate this video. There aren't enough think pieces about character controllers IMO
I still think the "hiding" part (pushing it to the level designers) is the best one still. Snapping up stairs isn't perfect like you mentioned but far worse is that in first person you dont want the camera snapping upwards, it's incredibly immersion breaking and jarring. You can smooth out the camera but that has its own issues with feeling floaty and detached and slopes can mess it up etc but if the game requires precise aiming then that smoothing is even worse of a tradeoff. The best solution is pushing it to the level designers+snapping, which is what CSGO uses and they've basically perfected smoothing out stairs with ramp colliders, it checks all the boxes it's smooth, you don't notice it so no immersion is lost, it keeps the camera steady and not floaty (mostly, there is still some from older source games that just had snap and camera smoothing like CS:S), and you never snag on anything random. I think it's the best of all worlds.
This was pretty cool dude thanks :)
The way the snapping works looks completely unnatural to me. You can tell just by watching it that it's snapped to the surface, it doesn't feel like you're walking up or down a surface it looks like you're walking along it, glued to it. If I walk fast off the edge of a step I don't immediately snap down, I get a little air time, with appropriate speed and gravity configured "falling" down a stair is more realistic. In real life if you're walking briskly down a stair, you don't fully stop moving downwards when you put your foot on the step below, your leg continues to bend allowing your center of mass to continue moving downwards slightly, but other than that you really are doing a controlled fall with every step. Something similar happens with stepping up, you are pushing yourself up with your feet, but if you're doing it at speed you also maintain some upwards momentum from the previous steps, effectively tiny jumps. The physics behind stepping up and stepping down is an entirely physical mechanics problem which is difficult to simulate with only primitive colliders. The most accurate form of dealing with steps would be to simulate the forces on an actual skeletal system with the feet targeting and being planted on the ground via a predictionary system that looks for viable spots based on current momentum, expected trajectory and current limb placement (Think of this like the current IK system used for animating moving up steps, but the positions actually used for the calculations themselves not just visual). This would be computationally expensive, but not prohibitively so, the main problem would be the complexity, combining such a system with the more traditional collider-based controllers would be rather tricky, so you'd likely have to design the entire character controller in this style which would be far more complex and would have it's own difficult issues to solve.
Yes, I agree. As you describe in your solution, accounting for all those variables is very complex and can lead to difficult to handle edge cases. Most of the time in tight platformer games you want responsive and snappy motions. So the logical collider for the player should snap up or down to provide smooth motion that doesn’t result in the player clipping between the falling and grounded state when walking up and down small ledges.
However, the camera and player avatar should not be bound to these snappy motions as they can look jarring and unnatural. Lots more to cover on this and different types of games require different solutions depending on what the game designer is attempting to achieve.
Snapping is not ideal for every game but can work under some scenarios. Additionally, something needs to be done to handle sharp edges. I’ll make a follow up video describing and comparing some of these solutions. The character controller style you described is sometimes referred to as an active rag doll based character controller and is used in some games like human fall flat. However, making a game more realistic can also make it feel unnatural to play and probably would need to be separated from the actual player movement mechanics. Games like super Mario galaxy actually do this and have the character avatar move completely independently of the character collider to make it look natural while also feeling smooth to play.
Im struggling to understand what the issue is that hasn't already been solved.
UE for example, has a max step height var on their character class to define the max height the character can step onto. This has been in since the beginning of UE4 as far as I can remember. (Well over 10 years now)
How is what youve described different from this?
Using the max step height, its just a case of using IK to place the feet on the actual step and move the hips down slightly. One of the main issues i can see people having is with the characters skeleton not being setup correctly (bad bone orientation) which would result in strange behavior when trying to do IK.
Adding smoothing to the cameras z movement is easy enough to help combat the jerkiness.
Am i missing something?
yes, stairs are great and all... but the foot sliding is killing me!
Haha, will make an IK video where I fix the foot sliding soon enough.
My approach was a bit different than yours, as different use cases needs different solutions. But your explaination of the subject was very helpful. Off topic question: What tool did you use to create the image seen at 8:18 ?
Thanks! Yes, every game needs different solutions but wanted to provide a guide on how to implement snapping because I didn’t find another good solution online.
I used google drawings tool to make these static images and just faded between the different frames. I think learning adobe animate/after effects would probably be a good step in the future to make good 2D animations, just haven’t had time to do that yet :)
Don't fix stairs. Fix the walking animations.
I'm not entirely sure I understand? Games like Unreal and Quake from the 90's (and all their sequels) already do this snapping up/down method, with configurable step height and everything you can mess with in the editor. Even Super Mario 64 does this. If I'm not mistaken, a lot of games today still do this method (along with combinations of the other methods more so now), though mostly seen in first person shooters/faster paced games I'd say.
Great video explaining and breaking it all down, but the snap up/down method has been a well proven stair solution for decades now. A little unrealistic perhaps since it lets a player zoom up and down them at inhuman speeds lol, but from a gameplay perspective, it's fun and doesn't break the flow of playing, so it's the one I tend to see a lot more than most.
stairs dont suck in games. ur just overcomplicating it
Many games that use this teleporting up solution suffer the problem that moving stairs upwards is much easier and faster than moving stairs downwards. Upwards you just teleport up each step, movement is instant. On the other hand, if you want to move downward the stairs, your player might loose contact to the floor and is overall limited by gravity on how fast he can move the stairs downwards. This doesn't feel right at all. For now I think its best to simulate the player as a little hovercraft, a capsule that does not touch the ground, like it was done at 3:40 it can be extended to have legs, but they are not part of the collision with the environment.
Not a game dev by any means but would like to know. Why isnt the bean(character) and legs movement two separate things. Like the bean can slip up a ramp so it looks more natural, while the legs follow the terrain instead of snapping the entire character. Wouldnt this allow there to be a check in the animation for the legs to only snap them to the flat part of the terrain based on the position of the bean.
Kind of like if character bean is over step entity do a check for the position of the forward leg in the animation cycle to make sure it is colliding with the terrain. Sorry if this was covered.
Hey, I haven't had time to add IK to the project yet, that's a bit of a complex addition and adding it would take quite a bit of effort but is on the list for the future. I didn't really cover it in the video, the character and her animations are just meant as a visual reference so it's more interesting than the capsule shape moving up and down.
Alot of people DO NOT understand how hard it is to setup just opening and closing a door and making it look good in a game.
This is the same idea and how hard and bad it can look in a game without thinking what it takes to fix it.
Thanks for showing us how it works and how to fix it :3
yeah, I've seen a similar video essay about doors, too. Complicated stuff.
playing your demo I've come across an issue. When the stairs are small enough and you try to jump, there's an inconsistent quirk that happens where you snap to the next stair instead of leaving the ground. I think another kcc library I've seen solves this by very distinctly separating grounded and ungrounded states. This logic that keeps you on stairs (and I believe slopes) only happens while you're grounded. Then when you decide to jump you're forced ungrounded so you're not attached to slopes and stairs.
Apologies if this has been mentioned a million times already
I think I’ve seen this too. I found the issue for when the player snaps down stairs causing it to interrupt a jump but never resolved it for snapping up stairs. I think I need to add that check to prevent snapping up when the player is moving up/down as well (I only have that check for snapping down). I’ll add an issue on the GitHub page for this.
github.com/nicholas-maltbie/OpenKCC/issues/218
The best stairs-to-character animations I have seen are from some old games, like the original Resident Evil and Dino Crisis, where you get the cut scene/loading screen and you can see the character going up the stairs; no weird floating or clipping. It's a trade-off between looking nice and consistent play flow.
To no surprise, The game that got stairs down the best is RDR2. That game is just perfection
Fun fact. That overhang he is talking about on the edge of each step is called a "nosing"
Cool, didn’t know these parts all had different names :) I just made a table of all the edge cases when designing the solutions!
4d chess move: make an ai that determines the step-ness of a situation and moves the character model to literally have the player WALK up the steps
I absolutely disagree with your comment about not holding devs accountable who do NOT do decent stairs physics. As a player, the time management of a studio making hundreds of millions, or billions of dollars is absolutely not my concern, any more than the long working hours of a car designer gives them a pass on car safety. When I pay for a product, my concern is the quality of that product. It is up to the studio to allocate sufficient time and staffing resources to ensure that their games are presentable. Indies get a lot more leeway.
That said, targeting specific programmers or artists is not helpful.
Great video, excited to implement this a bit later today! One quick question: at 1:37, you're using some "Create Shape" thingy-mer-bob to click and drag your stairs into your scene. Is that a package? Where can I find it?
It’s called pro builder and is an official unity package. You can look it up as pro builder Unity :)
@@NickMaltbie Many thanks!
I'm curious about the floating collider method, tbh. I've seen snapping as well as the hidden ramp trick, but I hadn't really looked into just...not putting the player's collider on the floor.
I’m going to try and add that as a configurable option in a future patch and will definitely make a video on it in the future!