In my first-person game, I want to make it to where the script can detect if the player is moving by pressing WASD, so it’ll play a walking animation. I’m currently using rigidbody.velocity.magnitude, but that also triggers when the player simply spins in place, which I don’t want. I could also simply detect if the player’s actually pressing the WASD keys, but that feels a bit overcomplicated for my taste. As always, any help would be appreciated!
In the latest versions of Input System, you can create Project-Wide Actions automatically, including moving.
Please learn and use it.
It can be complicated at first, but it gives you the high flexibility.
If you want to take this seriously, look into animators and maybe take a poke on the asset store. Lots of rigged character controllers that fire off different animations and animation blends based on triggers and lerps in the animator modulated at real time through C#.
(Grabbed two quality ones randomly, by all means poke around and see if you can find better resources more suited to your needs)
Best thing you can do early on is find quality learning resources and immerse yourself in well made code and systems that aren’t so complex they scare you off.
It’s all about the wax on wax off. You really gotta just try lots of stuff and the more mistakes you make and the more often you make them, the more you’ll get better. So look at other working systems and see if you can see key bits of logic you think you’re ready to adopt.
But don’t just copy paste stuff in. When you’re first starting it’s not about just using other assets, that’s a recipe for disaster. It’s about learning to improve your own bare bones things. In time you can start to adopt other code and actually make it better. But only after you first make those tiny baby steps, which it looks like you’re doing.
Best thing to do is to start learning what “movement” even means in a game and the only way to learn it is through this confusing experimentation. Movement can derive from several systems but nothing is set in stone. It ranges from physics, input, rigging, states, rotations etc. It’s a constant balance of making things look flued and dependent on several factors blending in and out of each other, but also keeping it manageable so it doesn’t reach a horribly complex state that can no longer be improved.
You could for example create a more procedural system like fall guys that reacts to rigidbody velocities, or you could do a more call of duty approach that relies on input states like you post seems to be leaning towards.
The best animation systems rely on the best elements of all these animation setups and fit the kind of game you want to make. Like for instance, you may rely on if the player is pressing shift to lerp between your sprint run or normal walk animation, but you’d be smart to tie the animation speed to the rigidbody forward velocity, so if say the player is running uphill at a slower rate they wont have this wonky fast run animation while moving slower.
This is just one tiny example, but there are so many tiny considerations it’s kind of mind blowing. You gotta figure out how to create robust animators for your game objects, while keeping track of all the movement variables.
Kind of like that Carl Saigon quote, “In order to make a cake from scratch, you must first create the universe.” That’s kinda the same for movement controllers, they’re just so complex and dependent on referencing and understanding several other complex systems.
Point is, look at what’s out there, but don’t try to copy them exactly, the most important thing you can do is beat your head against the wall and try new things. It’s frustrating and its often when we feel the most frustrated that we’re learning the most.
Long reply I know, but it’s just CRAZY how deep these systems are for newcomers.
TLDR: Check out some cool functionality from other working move controllers and try adopting them into your own without going to far and don’t be afraid to make mistakes along the way.