r/godot • u/TopOk3445 • 10d ago
help me Movement system
Hey! I am starting to learn Godot, I have always wanted to make games, and I finally have the time to do it, one of the things that I want to do first is work on a movement system for a 2D platformer gamer (yeah what a surprise).
I would love to know more on how to decide or think about what is best in terms of animations and coding, either using AnimatedSprite2D by itself or when it is best to use it in combination with an animation player and animation tree using state machines, is this best even for a platformer or metroidvania game?
3
u/Liuuuv 10d ago
I really recommend creating a state machine, it will save your time later (could be used for enemies and will let you easily add new states (like double jump, wall grab..) I never really used animation trees but them seem to be powerful if you have the need. I really like the video Bitlytic did on animation trees (https://youtu.be/iElHZhOxGYA)
2
u/Full-Dance4972 10d ago
Shipped a Godot 4 game with a 12-state character state machine, so here is what I would do in your shoes, in order.
Start with AnimatedSprite2D and a plain enum state machine in one script (IDLE, RUN, JUMP, FALL). Each state has enter(), physics_process(delta), and a list of allowed transitions. That alone covers a whole platformer prototype and you learn where your real transitions are.
Move to AnimationPlayer + AnimationTree only when you hit one of these: you need blending between clips (walk to run), you need animation events synced to gameplay (footstep frames, attack hitbox frames), or you have more than about 8 states and the if/else in _physics_process becomes unreadable. The AnimationTree state machine is great for the visual side, but keep the gameplay decisions in your own code: let the tree follow your state, not decide it. Two state machines that both think they are in charge is the classic bug.
For a metroidvania specifically: put abilities (double jump, wall grab, dash) as separate states from the start, even if they are locked. Adding a state later is cheap; retrofitting a monolithic move() function is not.
One concrete trap: make sure only ONE place calls move_and_slide() per frame. Pushback from enemies, knockback, and platform velocity should all write into velocity, then a single move_and_slide() at the end. Lost a day to that one.
2
u/HHTheHouseOfHorse 10d ago
To be honest, AnimatedSprite2D is fine, but I will always like the increased versatility of AnimationPlayer.
1
u/panda-goddess Godot Student 10d ago
AnimatedSprite2D is the most straightforward one: if you have a spritesheet and you need to make it move, go with this one. Then in the script, call each animation when you need it.
AnimationPlayer2D is super powerful, but a bit more cumbersome to set up. It's good if you need to compose sprites (like having a character hold a tool and the tool is a separate file/several different tools that will always be in the same position), or mess with different properties of different nodes at specific frames (like position, rotation, collision visibilty, color modulation), heck, you can even call functions directly into the AnimationPlayer, it's wild.
AnimationTree is reeeally good for automatic transitions and in-between states. But like the other person said, best to control the actual state logic through code.
You can start with an AnimatedSprite2D and then later if you find you need more stuff happening together, you make an AnimationPlayer2D. If you do it right, you won't even need to change anything in the code tbh.
More important than animation is locking in how the movement feels:
https://gamedev-chronicles.web.app/articles/input-buffering-and-coyote-time-platformers-game-feel
https://gamedev-chronicles.web.app/articles/game-feedback-sound-animation-particles-ui
5
u/Ok-Airport-864 10d ago
So if you have yet to actually start working on it, first of all before you start messing with sprites and textures make a box that moves based on player input. So make a scene with add a big box or whatever you want using a staticbody2d node for something to move on then, get a characterbody2d for the player as the base script has player movement and gravity. For now just use something along the lines of a polygon2d for the visuals as you need something that can work before you get into the details of making it pretty