Making the car decelerate

[Samsuma]

Does anyone have a good suggestion for making the car movement feel a bit more natural by decelerating gradually when you let go of the drive key? (or accelerating when first moving).

Thanks!

[Nina]

Hi Samsuma,

Welcome to our community!

You could try to override the value of drag in the player’s Rigidbody2D component.

https://docs.unity3d.com/ScriptReference/Rigidbody2D-drag.html

With if-statements, you could check GetKeyDown and GetKeyUp and set the value of drag to, for example, 1f and 10f respectively.

Let me know if this approached worked for you.

---

See also:

• Forum User Guides : How to mark a topic as solved

[Samsuma]

Hi Nina, thanks for the tip. I also thought this, and tried changing the linear and and angular drag settings, but they have no effect on the car (I also tried this on a Box obstacle to get it to “slide” after the car hits it, but with no success).

From what I could gather from reading sources online, it’s because we’re moving the transform position “manually” issuing code, instead of using a force to move the car.

What do you think?

[Nina]

Ah, yes, I think you might be right. By manipulating the transform.position, we do not affect the velocity. The drag affects the velocity, though.

If you want to challenge yourself, replace the current code for movement. It’s not difficult.

• Create a new method named FixedUpdate. It’s a Unity method like Update.
• Comment out the code for the current movement. You could do that with // in front of the lines.
• Reference the Rigidbody2D component at the top of your class if you haven’t already.
• In the FixedUpdate method, you call the AddRelativeForce method on the Rigidbody2D object referenced by your Rigidbody2D variable.
• The AddRelativeForce method takes in a Vector2 object. Bear in mind that it is a force, not a target position or something like that. The force is determined by the user input. The best would be to test values to figure out what they do. You could also test the shorthands.
• Do not use Time.deltaTime in FixedUpdate.
• Test your code.

Theoretically, that should work. Unfortunately, there is no code example for the AddRelativeForce method but you could take a look at the AddForce method.

• If the AddRelativeForce method worked for you, you could apply your knowledge to the rotation with the AddTorque method.
• Ideally, user input should be fetched and processed in Update but for methods such as GeyKey or GetAxis it is also okay to use them in FixedUpdate.

Good luck, and let me know if/how it worked.

[Samsuma]

Thanks Nina, great advice thank you. I played around with it (for longer than i care to admit and managed to get it working in a way that is a lot more fun (in an arcadey way) to control.

My code here:

void Update()
    {
        turnAmount = Input.GetAxis("Horizontal");
        forwardAmount = Input.GetButton("Fire1");
        reverseAmount = Input.GetButton("Fire2");
    }

    void FixedUpdate()
    {

        if (forwardAmount && reverseAmount == true)
            return;

        if (forwardAmount == true)
            {
 
            rigidbody2d.AddRelativeForce(Vector2.up * moveSpeed);
            }

        // moveSpeed is slower when reversing - to keep turning cirlce the same, turnSpeed is also reduced by the same amount.
        if (reverseAmount == true)
        {
   
            rigidbody2d.transform.Rotate(0, 0, turnSpeed * 0.3f * turnAmount * Time.deltaTime);

            rigidbody2d.AddRelativeForce(Vector2.down * moveSpeed * 0.3f);
        }

[Nina]

Good job! I like that you processed the user input in Update instead of opting for the simpler (but not that optimal) approach in FixedUpdate.

A little tip: == true is not necessary unless you like it this way, for example, if (forwardAmount && reverseAmount) and if (forwardAmount) would be sufficient. That’s a matter of personal preference, though.

And remove Time.deltaTime from the FixedAmount method because that might give you laggy results even with transform.Rotate. FixedUpdate gets executed every x seconds, where x is constant. For this reason, we are not dependent on the framerate in FixedUpdate.

Apart from these two details, I do not see any issues. Keep it the good work!