Видео

Hello! I'm a gamedev beginner, so sorry if this is obvious to most people, but what do you mean when you say to reduce the colliders bounding box every frame? Because to me it sounds like that would just shrink your collider into a single point over a few frames. Do you reset its size at the end of each frame?

That’s awesome bro good luck

You've saved my game

Couldnt even bother leaving the code or a project file in the description, disliked.

what i don't get is why character controllers are supposed to so often be kinematic, when in a multiplayer game that would mean players cant collide with each other because theyre all kinematic.

Hi. In the Unity templates for first and third person, jumping and hitting a ceiling makes you stick, permanently from memory until, in this case, slide out of the shipping container. I recently got Flax, and followed 2 tutorials which give the same result, and so I think the methods used in Unity templates and Flax tutorials are the same. I had never come across this method before, but I'm sure it's widely known. When jump, set a (float) yVelocity to a jump power and decrease it by (jumpPower * Time.deltaTime) each frame. This does create a nice graphical curve to the jump. But, this is what causes the ceiling sticking in Flax, which dies off. I don't recall the Unity ceiling stick dying off in the templates. I write this, because I think I saw this happen in your video at the end (11:01) when you first explained how you tested for ceiling detection. Are there any solutions out there, either for jumping with even better code which doesn't stick to ceilings, or for cancelling the update yVelocity change when hitting something? In much simpler scenarios, like games made in the 90's, there's just perfection, like in Duke Nukem/II/3D, you jump, hit a ceiling, you stop magically going up, and if you hit a wall, you just go straight up. In all my attempts in Unity to mitigate the first thing, it causes problems and unwanted behavior in the second thing; I fix one issue and cause another. Please help us all.

Great video ! I am trying to implement the algorithm right now and your explanations are very clear. But isn’t the velocity you mention in the code more like a position displacement ? (So actually velocity * fixedDeltaTime?). Maybe I misunderstood something here…

Amazing! Thank you!

Would love a breakdown of the character controller :3 great video!

im trying to implement this algorithm and as far as i know i have everything down exactly as you do, but for some reason the float variable scale is just. always 1? which leads to the character acting really really weird towards walls and jittering all over the place :[ help

good stuff, used this for a lightweight 2d ECS character controller

To anyone who tries to implement this using a box collider: Don't divide the algorithm up into horizontal and vertical passes if you plan to have sloped floors in your game. Doing this will occasionally "miss" a collision detection and pass the player straight through floors. My solution to this problem was to only use one "pass" with the entire velocity vector, not separated into horizontal and vertical passes. And if the floor was angled within a walkable steepness, I would set the leftover vector3's y value to 0. This will stop the player from slowly sliding down slopes that he should be able to walk on, but would still slide him down along a steep wall.

you remind me just of @Jam2Go another game dev with a super similar editing style.

this was cool dude, gonna for sure check out updates

Your original concept isn't too far off, just have a timer for finding the treasure, and some keyswitch puzzles to flesh out the "exploration" act of each level's early phase, some mechanics that play along with the schmovement options (the way Sonic widgets do)... Donkey Kong '94 had a fun moveset to explore and so did Celeste - all the moves were available from the start, but the progression of the levels taught you each thing as it was going, so having a scope of game like that would be pretty great. Don't overbuild the game, just work out your schmovement options first and then scale the game/progression accordingly. Then you just need an art layer and a jammin' soundtrack! Good game.

I am so excited to follow along!!! ❤ keep up the great work. Loved this video, excellent job explaining your process and steps. I love the Indiana jones concept 😊!

Great video. I'm with you on Godot for the most part but I'm really optimistic about it all. Still, it did completely corrupt my project and version control couldn't help so I am a little biased. Still, couldn't imagine working in Godot for my current project and I'm happy about Unity's trajectory

I‘m really new to unity and also like to search for the perfect player controller,but I habe a few questions(sry if they‘re maybe stupid, like i said im new to unity: do you makw basic movement for the player with a rb and addForce() or another way to add velocity, and if not how do u do it then? And basic collisions with the ground, are they also managed with a rb? Thanks already and this is a really cool vid!

Use any-state transitions in Unity, don't link individual nodes to eachother like that, sometimes you do that but most of the time you don't need to. With what you briefly show, it is a typical example of what you shouldn't do; Their system can work if you know how to use it.

great video! can't wait to see more of this project

really cool game and the editing is great, cant wait for the next dev long

This game looks so fun, and I LOVE the artstyle. The mario world inspiration is clear and I adore it. It looks so good

your editing style is poppin off man great content!! excited for more devlogs :)

The first Idea about the treasure felt like you'd start/enter a Level at [A], explore, grab the treasure at [B] and then exit at [C]. My Idea would rather be, just from [A] to [B] and exit where you started. While exploring and finding the treasure, you would change the map by interacting with it: opening paths, destroying parts and bridges you walked by/on and collect items/powerups and much more. The key at first would be, to find a viable path to the exit and on reruns (motivated by medals and leaderboards), to find different routes to complete a level faster, or even with a secret item, additonal challenge (pacifist, no jumping, ...) or even a hidden exit. The faster you go the more difficult the routes become and eventually, people find crazy routes and competeing for top leaderboard times. The levels would obvl. scale in size and complexity to not overwelm people starting out, but always hint a faster routes or possibilies. :D just an Idea to expaned upon, inspired by yours. Great Video. Inspires me to retry creating a small game myselfe.

Great vid, I wanna see that fisheye lens in game engine ha

Have you heard of a game called Pizza Tower? It's a 2D platformer which focuses a lot on having really smooth movement. All the levels are split into two phases. First you can just explore the level at your own leisure, finding secrets, defeating monsters etc. but as soon as you get the macguffin in the level a time limit starts and you have to escape back to the beginning. While not exactly what your first scrapped idea was, it is very similar. So it might be a good idea to check it out for inspiration if you haven't already

Ha, I feel the exact opposite to you on the the Godot/Unity situation. Unity is bloated and jank while Godot is clean and clicks for me. But I understand what you mean as when I started Godot I had to relearn things as I came from GameMaker. Either way - cool video!

I asked myself years ago:" is there still demand for 2d platformers?"

🔥🔥🔥

This is fire!!! Cant wait to play it once and rage quit

FISH EYE LENZ

I believe that as of Unity Unite 2024, Unity is in a much better state.

Holy shit, looks like I've come up with collide and slide on my own when trying to improve on a basic character controller tutorial that didn't do what I wanted. Originally I just wanted a wall slide effect but in the end I arrived pretty much exactly here. It felt like nothing special when I wrote it, I totally dismissed it as probably a bad solution since it wasn't in the tutorial but someone else based a paper on this. Huh.

I've been trying for months to create a 3d engine on my own and came almost with the same conclusions as this video, but with some exceptions. I'll borrow some things I've missed and if it works you'll have my eternal gratitude :D

is there a way to get this project?

Thanks, this made my movemant way better

great help. I managed to recreate exactly this in Unreal, using Blueprint. Works great for having the camera slide at the edge of the map in an RTS game

When does one make use of the gravity pass? Is this for when you're falling and trying to catch ledges?

my goat

Very great video. One question I have though is how do you handle moving platforms that can push the player? The implementation is working well in my game, but it starts bugging out as soon as the player comes across a moving wall that should push them. Thank you.

this should be very helpful for my botw inspired controller

Here's a question: you say the leftover projected onto the collision plane is to short, so you scale it to be the same size. Then later you say that oops, our character doesn't slow down when walking into walls, let's scale that by the angle between the normal and desired velocity vector. Couldn't you just leave the initial scaling out and then not bother with the second step? In fact, pretty sure that would solve the problem of the projected normal factor being zero when you try to normalize and scale it

I don't understand the logic behind the line at 7:30. Since you're already subtracting the skin width when calculating snapToSurface, isn't the skin width already factored in? By adding this check, you are canceling out all magnitudes where 0 <= hit.distance <= 2*skinWidth. If hit.distance is between skinWidth and 2*skinWidth, then there is still space between the collider and the wall, so you'd want to close that space. Even if hit.distance is between 0 and skinWidth, this means the skin of the collider is penetrating into the wall. The resulting snapToSurface vector would be in the opposite direction of velocity, forcing the collider out of the wall. Wouldn't this be a good thing since it prevents clipping into the collider? By adding this check, it would seem like you open the door to inconsistent behaviour with snapping to the wall, as well as an increased risk of clipping by not taking advantage of automatic correction that happens when the skin is penetrated. Someone please correct me if I'm wrong bc I want to understand this better.

First of all, this video slaps, no question. I was struggling for some number of hours creating a controller for exploring a 2.5d top down map with potentially sloping terrain. I found solutions for moving on slopes, but there were always problems addressing steep slopes (among other things). This is the first video I've found that addresses those problems while still using a similar algorithm for moving up slopes. The one gripe I have is I don't like when people say something is the "right way" or "actually good" when it comes to programming, because there are multiple valid ways of doing things, and some people don't always have the time to implement everything from scratch. The Unity character controller addresses these problems and has parameters for slope limit, skin width, etc. It's a perfectly valid way of doing things. I just didnt want to use it in this instance because our game had potentially unique requirements, and I wanted to understand the math myself anyway.

Fucking amazing, only thing that bugs me is thau way you write your code lol. But bravo for the video!

I need to learn this....

4:10 Why scale the projected vector up, if we're just gonna scale it down (based on the angle) anyway? If you leave the code there, it should be so that the straighter you go into the wall, the slower you move which is what we want.

Thanks bro for the link to the material, it helped me a lot.

Fairly inexperienced programmer here! This is an excellent tutorial, but I'm running into an issue where my character gradually slows down to a crawl when heading toward an obstacle, only to pick up speed and slide correctly once the collision occurs. I think it might be related to snapToSurface, as this value decreases along with the character's speed, but I can't really wrap my head around what's going on. Anyone have any ideas?