When should I use a KinematicBody or a RigidBody for 2D platformer characters?

Question

Which Physics body would be the best for, let's say the player character, enemy and collectibles. StaticBodies are quite different and easy but it is very confusing when we have to choose between a KinematicBody or a RigidBody. I am recently making a 2D platformer and while I was making the enemy it struck me that I didn't which body would be the best... I looked up at the Internet but the explanations were very vague. I ask anyone who knows, what is the difference between these two bodies and when to use one over the other?

I used a KinematicBody2D for the main player but I do not what will work best for the enemy and the collectibles, especially since my enemy will involve complex animations and attack sequence and the coin will have some basic hovering and turning animations. Also, I think that my player is not interacting with the in-game objects as was expected. I would be best if anyone could give a simple explanation for this and also a simple list of platforming elements along with the best physics object to be used...

Answer 1

RigidBody vs KinematicBody/CharacterBody

This applies for both the 2D and 3D versions of these classes.

The main difference between RigidBody and KinematicBody/CharacterBody is who is in charge of moving the object.

With KinematicBody/CharacterBody your code is responsible for moving the object, using move_and_slide et.al. methods. With RigidBody the physics engine is responsible for moving the object.

The KinematicBody/CharacterBody classes are intended to be used for characters. Yet, the fact that you are responsible for moving it means that you code gravity for it. And if you want something to push the character, you have to code that on your own too.

Just to be clear: The fact that you are responsible for moving KinematicBody/CharacterBody does not mean it does not interact with physics. It does. It will collide, and it will push things around (and you don't need to write code for this, however you might improve upon the default behavior, see Kinematic to Rigid body interaction).

The question "can things push the character?" can often be the deciding factor between KinematicBody/CharacterBody and RigidBody.

So, yes, you can use RigidBody for a character. And it it might be worth it if KinematicBody/CharacterBody is giving you much trouble. However, avoid moving it directly, so you do not fight the physics engine (e.g. the physics engine wants to move the object one way, and your code wants to move it another way). If you need to, you can take control of the RigidBody (which might require to use _integrate_forces, or changing its mode, or talking to the PhysicsServer class) but most of the time you would be using impulses and forces to move the RigidBody around. A notable gotcha case being teleporting.

Similarly, you could, in theory approach the behavior of a RigidBody using a KinematicBody/CharacterBody (with the help of other nodes, notably an Area), but is a bigger challenge.

---

Your Questions

Characters

I used a KinematicBody2D for the main player but I do not what will work best for the enemy […] especially since my enemy will involve complex animations and attack sequence

Figure out what you want, and then on top of which it will be easier to build it. Yes. Not on top of what you can built it, there will be multiple options. And not on top of what you should built it either. But on top of what it is easier.

As I said earlier, you can use the question: "can things push the character?" if yes, then prefer a RidigBody, otherwise I suggest KinematicBody/CharacterBody.

By the way even not using KinematicBody/CharacterBody, nor RigidBody, nor StaticBody nor Area is an option. You could work at a lower level and talk with PhysicsServer directly. Which is not easier… yet doable. So, do you need to? Probably not, unless you really need to squish for performance (and you only really get there when you many objects - e.g. a bullet hell game - which you replace with a single node).

---

Also, I think that my player is not interacting with the in-game objects as was expected

I believe you need the solution covered by Kinematic to Rigid body interaction (which I also linked above).

---

Collectibles

and the collectibles […] the coin will have some basic hovering and turning animations

If nothing pushes it, and it pushes nothing, then use Area. Even if it does move around.

---

On using Area for the player character

I want to point out that the official tutorial uses Area for the player character, which is also an option. In the tutorial game, the player pushes nothing, and nothing pushes it, it just needs to detect other objects for which Area is sufficient. However, I find that using KinematicBody/CharacterBody is a better recommendation for beginners. In particular, beginners might want to transfer what what they learned in the tutorial to games where Area is not a good option for the player character.

---

Common Nodes for platforming games

I would be best if anyone could give a simple explanation for this and also a simple list of platforming elements along with the best physics object to be used…

Games are different. But sure, let us talk about the most generic cases, but remember that this is not an straitjacket. These are the usual nodes starting from the use case:

• Static Platforms and Walls: StaticBody.
• Moving Platforms: In Godot 4 use AnimatableBody. in Godot 3 use KinematicBody (e.g. moved by AnimationPlayer or a Tween). In some cases an AnimatableBody that is not moving by itself, but it is a child of a moving object, does not behave as expected... Try using an StaticBody or a CharacterBody. Worse case: write the code in the AnimatableBody to follow the other object.
• Characters: KinematicBody/CharacterBody.
• Projectiles: Area.
• Collectibles: Area.
• Throwables and Pushables: RigidBody.

Some other things I want to mention:

• You can make platforms bouncy using the physics_material_override property.
• You might also do static platforms with a TileMap in 2D or a GridMap in 3D.
• Use StaticBody for conveyor belts.
• Use StaticBody (Godot 3) or CharacterBody (Godot 4) for hidden objects that are detected with Area※.
• If you need to change gravity or apply a force in an area, you use Area※※.
• If you need something to trigger when the player steps on it, use Area.
• Similarly, if you need interactive objects (the player approaches it, and then presses a key) use an Area (either the character has an area where it detects the object, or the object has an area where it detects the player, I prefer the latter the Area in the interactive object is easier to work with, but if you want to handle having multiple interactibles nearby and let the player choose, you need the Area in the character).
• Use RayCast for line of sight checks. You can have an Area for the vision range of an enemy, and then check line of sight with RayCast for each one (call force_raycast_update if you are moving the RayCast from code, which you probably would be).
• If there is an explosion, and you need to push away things that are nearby, use an Area to detect them. Combine with the RayCast again, so objects can be under cover.
• If you need to detect the end of a platform, to prevent a character from falling off, use a RayCast offset so it is ahead of the character, and have it pointing downwards.

※: I'm changing my recommendation for Godot 4 due to this issue: Issue #57539. By the way, you can dedicate a physics layer for "audible" objects, then spawn a StaticBody in that layer where something makes a sound, and give the enemies that can "hear" an Area that detects body in that layer.

※※: Since you write the gravity code for KinematicBody/CharacterBody that means either reading the gravity from PhysicsServer.body_get_direct_state(get_rid()).total_gravity or otherwise communicating the change to the KinematicBody/CharacterBody. For example see Overriding KinematicBody2D movement within Area2D?.

---

I have an explanation of (almost) everything you need to know about setting physics in Godot elsewhere.