Welcome to the forums @vomppis!
There is not really a specific use case for each node per say, it really depends on the project and how the programmer(s) want to go about solving the problems to make the game work. I’ve used all of the physics nodes for all sorts of tasks, including ones they’re probably not intended for but ultimately it worked.
That said, I can give some general advice on the three nodes, just keep in mind that all these nodes can be used in a multitude of ways.
StaticBody2D: generally great for static, non-moving objects.
There is a performance penalty for moving these nodes (rebuilds the physics scene, if I recall correctly) so you ideally want to use these nodes on things that do not move or move only really infrequently.
Most common use case is for level geometry, like the floors and walls.
* These nodes are also great for invisible barriers! They have the benefit of being built into the physics scene, so fast moving objects are generally aware of their presence, making collision tunneling less frequent.
KinematicBody2D: great for physics you want to control
KinematicBody2D nodes do not move automatically, you need to call move_and_collide
, move_and_slide
or move_and_slide_with_snap
to move them through the physics world. These functions are all really easy to use and because you can control when they are called and how much the KinematicBody2D moves, this node is ideal for when you need controllable physics
Mose common use case is for player characters! They are also super usable for moving platforms, spinning platforms, or really anything you want to control.
KinematicBody2D nodes work fine with other physics nodes even when moved manually, just make sure to move them in _physics_process
. For example, if making a moving platform, put the movement code in _physics_process
and other physics nodes should work fine with the moving platform.
When in doubt, this is my go-to physics node!
If you are looking to make a player, there are dozens of tutorials showing how to use it! Can be really helpful when debugging or running into an issue.
No extra performance cost for moving them!
RigidBody2D: The most universal and flexible
RigidBody2D nodes solve their physics using the physics engine by default. Unlike the other nodes listed, they use physics forces to move. This can make them harder to control, but its doable.
Most common use is for physics elements in the environment, like boulders, crates, cars, etc. They can be used for player characters as well, but because they are harder to control, KinematicBody2D nodes are generally used instead.
They can also be used for bullets and fast moving objects! (So can KinematicBody2D, actually. Either are suitable, but I noticed RigidBody2D are used more often)
Works with 2D physics joints!
Does not require code to move in the physics world! Just give it a collision shape and it will be good to go.
No extra performance cost for moving them! Of all the nodes, I believe they are the most performance friendly.
And an extra, Area2D: The physics detection node
Area2D nodes can detect when physics nodes or other Area2D nodes enter, leave, or stay within their collision shape.
Most commonly used for triggers! This makes them suitable for spikes, lava and water pits, or really anything where you need to know when something has entered/exited a space.
Because they do not use physics and only detect it, they can go through physics objects. For this reason, they are often paired with one of the physics nodes above when you want to detect things on moving objects.
No extra performance cost for moving them!
If you are just starting out, I would recommend using KinematicBody2D nodes for players. For things like trampolines, I would recommend using an Area2D node, as then you can detect when the player entered/collided with it and bounce it away. For the ground itself, a StaticBody2D is ideal. To tell if the player/egg hit the ground, you can either use the collision info from the KinematicBody2D, or attach an Area2D to the player and use that to detect when you hit the ground.
All of the nodes are really quite flexible, but hopefully this gives an idea on the use cases for the nodes. :smile: