Rename RigidDynamicBody to either RigidBody or DynamicBody

[Mickeon]

Describe the project you are working on

A typical 2D game, dipping my toes into Godot 4.

Describe the problem or limitation you are having in your project

Time to make up your mind.

The industry term has always been RigidBody as a whole, but DynamicBody would also make some sort of sense. Making use of both adjectives to describe this Node is needlessly verbose and does the opposite of what Godot 4's new Node naming scheme aims to achieve.

For being such a common Node to be made use of, its name is irritatingly long to write. People needing to explain how to implement something in the Engine may just shorten it to "Rigid Body" in speech, confusingly enough for beginners. "RigidBody"? All I see is the "RigidDynamicBody". Is it an extension of "RigidBody"...? It doesn't help that all of the other PhysicsBody classes do not have double adjectives like this one does! SoftDynamicBody exists too, but the current naming scheme implies may imply they inherit from the same class.

And amusingly, by default it doesn't even fit on the Scene Tree Editor, likely prompting the user to change it into something shorter right off the bat, like... "Rigid Body", or... "Dynamic Body".

Over these years, I've seen a few users pouring in, complaining about the new name on the official Discord server, but it never really was noticed, since development all still was still in early stages, and not many people are well-versed in the physics side of Godot. All of that, until now, that Godot 4 is reaching feature freeze.

"The problem with "RigidDynamicBody" is that there are no other types of "rigid" or "dynamic" bodies"

"yea that one is a strange choice.. even if it somehow perfectly describes the node on a technical level, it's still not a good name imho"

"I prefer RigidBody, RigidDynamicBody is much longer but doesn't add much meaning imo"

"All I could really find was a twitter thread Juan started where the majority preferred sticking with "RigidBody". The PR that made the change had 4 ups and 3 downs and no discussion..."

Describe the feature / enhancement and how it helps to overcome the problem or limitation

Rename RigidDynamicBody to either RigidBody or DynamicBody.

~Or heck, even DynamicRigidBody. At least it would flow better on the tongue!~

Applies to both 2D and 3D.

Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams

If this enhancement will not be used often, can it be worked around with a few lines of script?

It cannot.

Is there a reason why this should be core and not an add-on in the asset library?

Rigid... Dynamic... Body is a core class.

[Mickeon]

Linking to this old discussion: https://github.com/godotengine/godot-proposals/issues/2867

[MewPurPur]

So "SoftDynamicBody" is not a physics body apparently, but I was misled thinking it was... Adds to the reasons I don't like the name. Really hoping a rename of RigidDynamicBody makes it into 4.0 so we don't just have to live with it

[Lielay9]

Using any other name than RigidBody is just plain inaccurate. Rigid body is not just an industry-standard name for a physics body that emulates rigid body dynamics, it is the term used in kinematics. I can understand that the word rigid may sound contradictory to how rigid bodies work, but that is not reason enough to try to be quirky and break a naming convention deeply rooted in both physics simulations and physics.

So "SoftDynamicBody" is not a physics body apparently, but I was misled thinking it was... Adds to the reasons I don't like the name. Really hoping a rename of RigidDynamicBody makes it into 4.0 so we don't just have to live with it

The name soft body has also been used to describe deformable objects in physics simulations longer than Godot has existed. I do not see a reason why this was changed.

[Mickeon]

The name SoftBody has also been used to describe deformable objects in physics simulations longer than Godot has existed. I do not see a reason why this was changed.

It's because, in the process of attempting to be more explicit with all base classes' name, the exact opposite was achieved in this case. It is technically dynamic by word, but that's not how it's called anywhere else. When looking up the full, raw name of both of these classes as they are now, little to nothing shows up. As is, Godot is the odd one out. Putting myself on the perspective of the casual, learning user, that is looking at generic RigidBody tutorials, to learn what they are and how to use them in ways that may be applied across multiple engines, I see the current, longer, more verbose name to be just an annoyance to remember when going forward.

[reduz]

This discussion is basically having two fronts:

• New users being very confused by the names in 3.x (which is not Godot's fault these are used everywhere).
• Existing users expecting standard names.

The renames were made mostly to solve the first problem while trying to see if they can still be understood. The confusion happened too often to just not do anything about it. If the problem is that it just bothers you because these not 100% standard names, but you can still tell what they are.. then it's not really a problem because it helps make Godot easier to approach. If you can't tell what they are, then something should be done about it.

[Zireael07]

SoftDynamic is def confusing whichever way you look at it.

RigidDynamic sounds like a case for documentation aliases/keywords proposed in another proposal imho.

[Mickeon]

The renames were made mostly to solve the first problem while trying to see if they can still be understood.

But it doesn't solve the first problem. As I've already fully explained in the proposal, this causes even more confusion going forward.

[Lielay9]

This discussion is basically having two fronts:

• New users being very confused by the names in 3.x (which is not Godot's fault these are used everywhere).
• Existing users expecting standard names.

I think it is a little unfair to extrapolate that new users would prefer RigidDynamicBody over RigidBody because they were confused in 3.x by what each node did. Also, the only new users that could find the name helpful are those that have never been exposed to physics systems or studied classical mechanics before, have not read the documentation, are not following a tutorial or otherwise taught. That's only a subset of new users, not all of them.

For the new names to have merit for that subset of users, they'd have to be self-explanatory enough to not need documentation or description, and/or they must be more discoverable. If they can't meet those criteria they lose their benefits over using standardized names (or any other name for that matter). Neither RigidDynamicBody nor SoftDynamicBody meet said criteria.

The original proposal missed the mark on why new users were confused about which node to choose and too quickly jumped to the conclusion that the names are to blame. It was even brought up multiple times there that it is more the fault of lacking descriptions

and confusing properties,

both of which have already been remedied in 4.0. This aligns with my experiences of teaching Godot to a dozen or so people from the ground up (confirmation bias is strong here). The only complaint I've heard, but yet not addressed is that the icon of the RigidBody resembles a beach ball which often aren't "rigid". If we want to cater for the aforementioned group of new users, we could try to do so through iconography. Examples:

Bouncy Speedy

[Calinou]

Instead of a name change, we could try to address the underlying problem through iconography, something like this:

Unfortunately, both of those icons won't scale well to a 16×16 pixel grid (which is the size editor icons are displayed at on low-DPI displays).

[Lielay9]

Instead of a name change, we could try to address the underlying problem through iconography, something like this:

Unfortunately, both of those icons won't scale well to a 16×16 pixel grid (which is the size editor icons are displayed at on low-DPI displays).

Maybe I shouldn't have included them 😆. Their purpose was to show the direction a more suitable icon could take, not be candidates themselves. I can create one that may suit the requirements better but I'm not a dedicated artist by any means. I'm sure there are plenty, more capable of improving the design.

[Mickeon]

I know it's beyond the purpose of this proposal, and it wouldn't solve it at all, but I do see potential for a new icon.

I made an extra mockup. It makes it look less like a StaticBody, and resembles a wooden crate of sorts (nicely common object present in several physics puzzles and during testing):

It doesn't scale nearly as badly, but I can't really say too much.

[Lielay9]

@Mickeon I know I started it, but maybe it'd be best to start a new proposal or else we steer away too far from the original topic.

[Lielay9]

In hopes to get more feedback from a wider audience, I opened a poll on Reddit (link). (In hindsight I probably should've also included the option for DynamicBody, but it is what it is.) I wouldn't look at the numbers as a decisive factor, but I'm hoping it brings forth more opinions from users of different levels of expertise.

[robbertzzz]

The renames were made mostly to solve the first problem while trying to see if they can still be understood.

How is RigidDynamicBody a clear name? I can see how RigidBody seems like an odd term for someone who has no knowledge of physics, but RigidDynamicBody sounds like it contradicts itself. Rigid and dynamic?

To me a term like SimulatedBody would make way more sense, if a rename would even be necessary (which I don't think it is, physics are just hard to work with for beginners regardless of class names).

[Pixelatex]

The fact that the 2 main game engines also use the term "rigidbody" is a compelling argument for me to also stick with it for Godot. It will lessen the confusion for users who want to migrate over and expect certain industry standard terms to be there.

[Mickeon]

I compiled some answers from the poll (some are formatted to make them easier to digest)

I think changing the name does the REVERSE of making it easier it understand.

I haven't checked but are there other bodies in Godot 4 that adding dynamic is important? like RigidStaticBody :D?

Rigid Body and Soft Body are Physics terms, there's no reason to change it, since if someone don't understand it, they just have to search "RigidBody" on the internet and they will find the answer from multiple different sources, while the new name will only be found in the official documentation.

IMO RigidBody was fine. Simple Google search will tell you everything and you can find tutorials (even from other engines).

Keeping it in the global standard would help people when switching from other engines like Unity

I've gotten used to RigidBody, so that's my vote.

I get that newbies have some confusion between a RigidBody and a StaticBody. It might be more of an issue for non-native English speakers, as well. But consider what is being differentiated. Rigid vs Soft, Static vs Dynamic."

Interestingly, these users with unique backgrounds may actually favour DynamicBody:

In the land of Tumult Hype, which uses matter.js as the Physics engine, there are three choices for Physics…

• Inactive — No Physics Applied
• Static — Interacts without movement
• Dynamic — Full Physics body So… what does Rigid mean? I don't know. I'm new to Godot. 🤷🏻‍♂️ …but I do understand Dynamic from working with other software.

DynamicBody because it aligns with the respective area of physics. Statics: Can't move. Kinematics: Can move but not affected by external forces. Dynamics: Affected by external forces.

The voting on any of these comments, too, doesn't matter nearly as much as a nicely written comment, it's true. But these are people actually using the Engine, all with different background and experience. Their opinion could matter a little, even they prefer to summarise it with a thumbs up on a comment.

[taylorhadden]

If the name absolutely cannot be RigidBody (which I vastly prefer over all others due to the industry standard), I would prefer DynamicBody over RigidDynamicBody. The length of the latter does nothing to differentiate it from either RigidBody or DynamicBody. If somebody is new to physics simulations in games, they will need to look at the documentation to understand what it does regardless of what name is used.

[and3rson]

The renames were made mostly to solve the first problem while trying to see if they can still be understood.

How is RigidDynamicBody a clear name? I can see how RigidBody seems like an odd term for someone who has no knowledge of physics, but RigidDynamicBody sounds like it contradicts itself. Rigid and dynamic?

To me a term like SimulatedBody would make way more sense, if a rename would even be necessary (which I don't think it is, physics are just hard to work with for beginners regardless of class names).

I second this. Anything can be considered "Rigid": KinematicBody, StaticBody, etc. Furthermore, "rigid" sounds like some physical property and might be confused with "rough".

As for the DynamicBody, I don't like it because it sounds like the opposite for StaticBody which I don't think is the case since there's also KinematicBody (please bear with my 3.x slang), and all three have different purposes.

To me, SimulatedBody is the most accurate name: because it's being simulated by the engine while others are simulated by the developer. On the other hand, I've gotten used to RigidBody name for the past years, so maybe not rename it after all whatsoever? :)

[TrialDragon]

After noticing a Reddit post on this issue, and voting, I've had some time to contemplate and research the issue and have come to a conclusion in regards to how the node at present called 'RigidDynamicBody', and in part how the node presently called 'CharacterBody', should be named based off the facts and understanding I could come to. My 2 cents are in the form of a little essay.

"Stiff and difficult to move or bend" and "Not moving, changing, or developing". Both are definitions provided by the Oxford Learner's Dictionary; one in regards to the word static, the other rigid. Whilst not truly the same they are primarily similar in use to any layman unversed in physics. To someone new to Godot, to read RigidBody next to StaticBody can be disorienting once they realize these two nodes with similar names have practically opposite effects compared to the other. They both involve objects which are 'rigid' in the physics sense; not deforming when forces interact. Yet one of them has a valid name, 'static', that represents the type of movement it can receive, or lack thereof. The other, 'rigid', is left with a descriptor for its state of deformity, not the type of movement. Why should it be named thus when it appears inaccurate?

The 'RigidBody' node is named thus to represent 'Rigid body dynamics' as it is known in physics nomenclature and industry tools. However in Godot what is called 'PhysicsBody' appears to represent 'Rigid Bodies' as a whole; each of its children represents a type of movement such as 'static; unmoving', 'dynamic; moved with forces', and 'kinematic; moved without forces'. To name the node RigidBody thus would connotate importance regarding its deformity when instead emphasis should be put on its type of movement. The rigid part of its name, whilst technically accurate, is implicitly presumed due to it being a child of PhysicsBody which seems to more accurately be 'RigidPhysicsBody'. If the implicit part of the name, rigid, was added it would end up as 'KinematicRigidBody', 'RigidRigidBody', and 'StaticRigidBody'. Instead, the PhysicsBody derivatives should follow a naming standard based on types of motion instead of the industry standard for clarity's sake.

Why should the PhysicsBody nodes diverge from industry standards and follow the seemingly unique naming standard of 'KinematicBody, DynamicBody, and StaticBody'? Due to Godot's OOP central approach with nodes, they each inherit from the 'PhysicsBody' which represents what the industry and physics would consider 'RigidBody' typically, as such Godot can not aptly follow industry standards whilst maintaining clarity and uniformity among names since the rigid aspect of RigidBody is handled not in the 'RigidBody' node but the PhysicsBody class itself. Instead, Godot should follow the alternative naming standard used inside physics engines to describe the types of movement experienced by a rigid body; kinematic, dynamic, and static. It would not be a wholly new unique design for Godot to implement as a folly for being different. Rather it'd be following a different, equally valid, standard that is ultimately more relevant to game development than following the industry standard which chooses physics nomenclature instead of physics engine nomenclature. Usage of this standard is found in Bullet Physics, the default physics engine for Godot 3.x. In its SDK and manual, it refers to three types of Rigid Bodies; kinematic, dynamic, and static. These each represent the type of movement they experience whilst denoting that they are all rigid. Looking at Godot's current standard of naming the PhysicsBody nodes it is clear that the 'KinematicBody', and 'StaticBody' both already seem to follow this nomenclature from the physics engine leaving 'RigidBody/RigidDynamicBody' as an outlier. Now, would these changes improve or impact the readability, and learnability of Godot for new users?

Changing 'RigidBody' to 'DynamicBody' will make the PhysicsBody nodes more readable and learnable to new users. As it stands 'RigidBody' and 'StaticBody' can have conflated meanings to those without knowledge of physics leading to both being misremembered for the other. Rigid is interpreted as hard to change whilst static as unchanging. 'DynamicBody' and 'StaticBody' however do not clash in this way instead their meanings suggest that they're effectively opposites in their use, which they are. Dynamic suggests that stuff is happening to the node, whilst static suggests nothing is happening. This change will make it easier to remember the actual use of the nodes given the new name would be closer to what is happening. 'RigidBody' on the other hand can become a name without relevant meaning itself that correlates to the node's purpose, like naming it the 'AwesomeBody'; new users can learn that the 'AwesomeBody' can be moved with forces, but the name itself does not lend to any association of meaning. This associated meaning will make it especially easier for programmers unfamiliar with physics to learn Godot as dynamic and static have ulterior meanings there such as describing whether a language is a compiled-- static--or runtime-- dynamic--language, or as a keyword similar to constant to mean unchanging in static. Ultimately, what should be considered is what is easiest for new users to learn per the purpose of the renaming, and neither 'RigidBody' nor 'RigidDynamicBody' provides that.

To maintain similar names of nodes with logically opposite effects is nonsensical. Adding the implicit rigid to the PhysicsBody nodes gives us 'KinematicRigidBody', 'RigidRigidBody', and 'StaticRigidBody'. That naming of 'RigidBody' is undescriptive of its actual feature, being dynamic with forces. 'RigidBody' also is an odd one out in how it's named compared to its siblings, described by the common lack of deforming of the three nodes instead of its unique type of movement. To best fit in with the other nodes, it should be called 'DynamicBody'. It fits in once you add the implicit rigid descriptor, 'DynamicRigidBody', whilst fitting into the naming standard of Godot's current default physics engine, Bullet Physics, as kinematic, dynamic, and static. Dynamic can be better associated with its learned uses compared to the ill-fitted descriptor of just rigid. Dynamic won't be conflated with static by anyone who isn't versed in physics or industry standards as rigid currently can be. 'RigidBody' is a poor and inaccurate descriptor of the node and 'DynamicBody' best encapsulates what the node is while making it easier to learn for new users to Godot.

[wareya]

The battle over whether the term "rigid body" is good or not has already been lost. Regardless of any arguments about its intuitiveness (or lack thereof), it is the standard term, both in physics and in simulation. Trying to create a better name is just going to make godot "weird" and less standard for no reason. Existing godot users are also already familiar with rigid body, and users who are not yet familiar with it would benefit from learning it because it's used everywhere else.

This is not a battle that can be won, and attempting to fight it will just hurt godot.

Stepping back: various other things use the terms "static rigid body", "kinematic rigid body", and "dynamic rigid body". If you absolutely must use three words, this is the correct order to put them in. The rigidness of the body is more inherent than its mode of operation (static/kinematic/dynamic), and english adjective order requires that more inherent properties are closer to the noun being described. "rigid dynamic body" is automatically unacceptable and must at the absolute minimum be changed to "dynamic rigid body", but if we're going to change it, we might as well change it to something people actually want.

[taylorhadden]

@TrialDragon, your arguments make tons of sense to me. I'll throw my support fully at DynamicBody.

[TrialDragon]

Thanks, @taylorhadden, though I've realized something regarding this situation since I wrote that that makes things more complicated than I first thought.

I was under the impression that the RigidBody was just the physics server RigidBody in dynamic mode, yet apparently this entire time it's had 4 modes as an actual RigidBody should, just nothing I'd actually learned about Godot from mentioned this, except apparently the docs in one line. This kind of makes it harder to say it's just DynamicBody since it is technically also RigidBody in the industry sense too. Though according to PhysicsBody node reorganization stuff it seems it is intended to be used in a dynamic form, that is to say, it's the node to use when you want stuff to be dynamically affected by physics, yet also at the same time it's meant to be the full-on RigidBody most engines use. That same general reorganization also makes StaticBody effectively KinematicStaticBody in that it is used for both now, so stuff is more complicated.

Ideally for making naming simple, each of the *[Rigid]Body nodes would be single-use for the most part, ala CharacterBody for characters as a descendant of KinematicBody, KinematicBody for moving platforms and such, DynamicBody for objects which are affected by physics like marbles, StaticBody for unmoving things such as your walls, stairs, or general random objects that should be collided with but not move, and a RigidBody that is either parent of Kinematic, Dynamic, and Static or as a sibling, for more complex things that you don't want any specialization made in the other specific nodes for.

Or on second thought in regards to the above paragraph, perhaps kinematic as a mode for Dynamic and Static Body nodes instead so that way you can have Kinematics with physics and without. Either way, this is about the name, not the organization of the nodes, the current way PhysicsBody nodes are structured seems to be why it's so difficult to currently name the node.

TL;DR 4.0 PhysicsBody node reorganizations make the names a complicated matter because nothing has a single use, except for CharacterBody, and instead implements multiple movement type behaviors; StaticBody is static and kinematic, RigidBody is dynamic, and every other mode at once. And technically everything is a little bit kinematic due to splitting up some bits of KinematicBody into PhysicsBody if I understand correctly.

[Diddykonga]

My Proposal opened a few weeks ago, I believe I explained proper reasoning for renames/restructuring. Refactor Physics3D nodes

I would rather us move this discussion there, as I believe it contains this Proposal and more. It also backs up the idea's/realizations of @TrialDragon and those that agree with them.

[TrialDragon]

@Diddykonga, I agree that future discussion of the PhysicsNode potentially brought on by my logical realizations should be held in your proposal. However, there is still a discussion and eventual final decision to be held here so that the name can be changed before 4.0 is released as I doubt any form of your proposal will be potentially included until 4.x, or potentially 5.0 if enough stuff breaks after decisions are made.

As to my own personal thought regarding this, it is at present that it should be renamed to DynamicRigidBody to flow better on the tongue whilst encapsulating that it is at this time intended to be used both as a DynamicBody and RigidBody, or if the preference of a shorter name is preferred then RigidBody since that is the most inherent property of it. That discussions to improve the PhysicsNode organization so that its nodes maintain single-use and are intuitively learnable to beginners-- such that the names are not correlated with multiple uses that are hard to succinctly name-- should be held in #5003.

[azur-wolve]

If you can't tell what they are, then something should be done about it.

What about improve the descriptions in the API reference (editor built-in), it is really accessible. The first short description should tell what it is and does in a comprehensible way, without jargon. (the rest is explained in more detail in the following definition).

Currently in the add node dialog (Editor), the short descriptions it gives for some nodes are really scarce, just a single short phrase that says almost the same as the name of the nod. Not a short definition that gives an idea of what it is and does.

Focusing on improving the API reference and promoting its usage could end-up bringing much better results, regarding user friendliness. (just let know newbies from a beginning that if you press F1 or Ctrl + Click an identifier you go to the definition. When I started I wasn't aware of that. When discovered, it boosted my progress. Now I can't live without it, one of the best Godot QoL features by far.

Have already seen proposals to have description hints when hovering the mouse (similar to Wikipedia). It would be just amazing. Similarly being able to go to the definition of properties from the tooltips on the Inspector. (not tried Godot 4 yet, but can't do it on Godot 3)

Regarding physics naming, have opened a discussion, check the names and argumentation and see what you think: https://github.com/godotengine/godot-proposals/discussions/5254