Move and Animate a 3rd Person Character in Unity3D 

You can also have a normalized variable for velocity, and an un-normalized variable for input. This lets you keep track of the player's input separate from the velocity (in case you want to read inputs, but keep the player from moving, say during a cut scene, or maybe a mini-game type interaction within the game). You can also get nice movement by having your input act more as an accelerator than a direct movement, which could be useful when your game has things like ice, and you want to make the inputs apply to the movement with lower strength, to give the effect of slipping/sliding.

don't worry even those who go to college are figuring out what coding is and how things work 😂

Not at all :)

21:06

saved me lots of time in future by saying this!

Not really a mistake and personal preference. Prefixing private fields with "_" is actually against the official C# naming guidlines. But a lot of people like to do it. A lot of people don't do it.

If you want to learn more about official naming guidlines here's the source: docs.microsoft.com/de-de/dotnet/standard/design-guidelines/names-of-type-members

@@fejza Thanks, but I'm well acquainted. You've missed the point a bit. He used an underscore naming convention with a local variable, not a private field. That would communicate that the local variable was a private field to most developers. So, I'd agree either way. You're right, it's not technically a naming "mistake". At the same time, I would have serious problems with any developer suggesting underscores for local variables project-wide is a sound idea. It's poor code communication and something that should be corrected, kind of like a mistake would be.

@@djProduct2008 thanks. Sorry my bad. It was late a night haha. I agree, naming local variables like that may spawn a lot of confusion. I've actually seen people doing that a couple of times as well.

​@@fejza No worries man! I'm a big fan of the Microsoft naming convention guidelines in my professional LOB work. I find them hard to adhere to with Unity C# sometimes. The first time you sit in front of a MonoBehaviour with public fields as a norm, as an experienced C# dev, and survive the shock and horror, and turn ReSharper off for a while, we realize this isn't C# Kansas anymore. Some concessions do have to be made in Unity with regards to naming conventions or even good practice (like public fields vs our standard approach encapsulated properties) or countless other issues in order to support the Unity Editor, design-time variables, performance reasons, etc. So, be careful hitting too many potentially terrified C# newbies over the head with that book of guidelines in this particular culture of C#. It's great intel, I agree, but it's only so helpful in this ecosystem.

Look into Scriptable Objects

@@davidcalderwood5540 thank you

Only for tutorial videos. Still love rider :)

Awesome. Keep up the great content ;-)

Not yet. Still not sure its ready for the average yet. Setup is too complicated still without some good defaults. May do one soon anyway though

Thought it had gone to ‘verified’ state

"P.S. Please forget the Like button" Gotta love it.

Did you find out ?

@@Giluby not yet.

@@telmonks I don't have smooth player movements either 😕

Go to Window > Animation > Animation Parameters > "+" sign > And create "VelocityX" and "VelocityZ" with Float type