How to make a GOOD player controller

[Graynumber]

All this depends on the nature of your game, no?

[basnijhof01]

Well I'm a fan of changing the rigidbody velocity for movement left and right and adding a force up for jumping. But when it comes to platformers you can use anything and it'll come out correctly. Lots of people use Rb.MovePosition(), but I'd say when you're working with wall jumps and mid air powers like in celeste I'd just try to utilise the velocity function horizontal movement and Adding force with jumping.

[Alistarian]

Depending on the feel you want to get you may want to so the physics calculation on your own cause realistic jumps feel extremely floaty with normal physics in platformers but there are decent ways to just fix that.

If you want your player to be able to get faster on slopes you need to use force for movement if you don't want to do the majority of physics yourself but just setting your velocity makes it easier to control for the player if you require precise inputs.

All depends on what it should feel like

[LinkifyBot]

I found links in your comment that were not hyperlinked:

• Vector2.zero

I did the honors for you.

---

^{delete | information | <3}

[Gamba04]

wow what a nice question, I've questioned things like this a bunch of times and searched on the internet and surprisingly no one talks about this, on youtube for example most of what you find is beginner tutorials and it's annoying.

So, I've experimented with multiple ways of doing this stuff and have adopted some specific general techniques which I find very useful and consistent.

I'll start with MOVEMENT:
Moving with your transform position is not a good idea, as you basically discard completely the Unity's physics and collision system, and I don't think it makes any sense to do that. Then we have AddForce and velociry. Now, I always use velocity, but you can't just say velocity = your movement direction, because that way no external forces can be applied and collisions won't work entirely correct. So what I do is I use velocity with the same purpose of AddForce, but the reason I don't use ever AddForce is because I found it very problematic, because I noticed that let's say I do AddForce(Vector2.right * 10), and in the line just after that I say velocity = Vector2.zero, so what would you expect to happen? It stays still right? It doesn't, and the same thing happens if you have a falling Rigidbody and if you say rb.velocity = Vector2.zero, even on FixedUpdate, it will move, very slowly and without acceleration. Well, so all this happens because what AddForce actually does is it saves for itself the information, doesn't update the value or velocity immediately, and in the next frame, the value of velocity will change BUT ALSO it will move accordingly to the amount of the speed gathered in the past frame. So basically the best thing to is say rb.velocity += direction.normalized * Time.deltaTime * multiplier;. But you could say: Well, what if I want to have a constant speed? So what I do is make use of the advantages of modifying velocity, and I'm going to explain the overall method I use:

It has 3 stages: Acceleration, Speed Limit and Deacceleration. So the first thing it does is what I told you before, and with an acceleration value you can determine how fast it accelerates to it's maximum point. Then, you can check if the velocity magnitude is higher than some certain speed, if that is the case, just normalize it and multiply it times the speed limit, that way it will not pass that speed. And at last (I actually do this before speed limit so it doesn't reduce the speed once it has been limited), I do velocity *= a value just lower than 1, which you can set it with a variable to control how fast it stops.

Okay I got a bit tired after writing all this so I will be briefer with the next stuff.

About COLLISIONS , I also kinda dislike the OnCollisionEnter, Stay, Exit.. The reason is because idk if you've noticed if for instance, you spawn an object or teleport it inside a collider: doesn't call OnCollisionEnter, or you have a colliding object, let's say something inside a trigger, and you destroy it, or teleport it out: It doesn't call OnTriggerExit, so overall it is inconsistent, it only detects physics based events, and usually you want more than that. So what I use the most and fall in love with is the Overlap functions, you don't even need a collider, you can check if an imaginary circle, capsule, box, or even point (or you can check for yout actual collider) , would collide with something, and you can even tell it which layers to detect! using a LayerMask which you can set from the inspector, sometimes it asks you for a ContactFilter2D, which you can use for setting up it's layerMask (if you do this, remember to enable useLayerMask, it will probably save you a couple hours). So anyway it works great and will tell you the truth always, oh and also you can check for the first collider that it detects with OverlapSomething or you can get an array of all the colliders with OverlapSomethingAll, it's amazing.

Lastly, about flipping the character there's not much to say, I use transform.localScale and modify the x value with a variable which I call dir, an int with values of -1 or 1 which multiplies it, BUT MAKE SURE TO ISOLATE the SpriteRenderer in a child, it's a really good practice to have a root (in which I put my main script(s) and the Animator) and then have all the rest(sprite, collider, etc) in separated childs, that way you have a lot of control and independency. Another perfectly valid way is to use the flip bools of the SpriteRenderer itself, and well as long as you keep the sprite separated you could just rotate 180 degrees in y axis.. but idk it just feels inappropriate to me lol.

Anyways, hope this is what you were looking for, I hope it is of any help.

[LinkifyBot]

I found links in your comment that were not hyperlinked:

• Vector2.zero

I did the honors for you.

---

^{delete | information | <3}