Physics naming issues

[cbscribe]

This is to discuss the current state of the physics node names for Godot 4, which I feel are inconsistent and/or needlessly verbose. See the bottom of the post for references to previous discussions on GH, which while closed, have ample confusion and lack of consensus.

Before I get into my objections and suggestions, I want to be clear about the context and motivation for them. As can be seen in the linked discussions (and I'm sure in those to come), this is a topic can lend itself to endless bikeshedding.

Motivation

I'm approaching this as someone who has written and will be writing a substantial amount of documentation and examples for Godot (so whatever happens I need to be able to explain things well). I also teach with Godot, so I expect to be fielding a lot of questions when it comes to the new paradigm.

Below, where I don't necessarily have a better suggestion, I at least want to raise the question so that we can discuss it and come to some consensus on whether it's actually a potential problem or not. We have to spend the next several years using these names, so it would be nice if they're something we can feel good about using in a practical way.

Here is the hierarchy of physics nodes we currently have (in both 2D and 3D):

─ PhysicsBody3D         ─ PhysicsBody2D
  ├ StaticBody3D          ├ StaticBody2D
  │ └ AnimatableBody3D    │ └ AnimatableBody2D
  ├ CharacterBody3D       ├ CharacterBody2D
  ├ RigidDynamicBody3D    └ RigidDynamicBody2D
  │ └ VehicleBody3D         │
  └ PhysicalBone3D          └ PhysicalBone2D
─ SoftDynamicBody3D     ─ SoftDynamicBody2D

1. PhysicsBody

• KinematicCollision
  PhysicsBody, the parent class for RigidDynamic, Static, and Character bodies, now contains the move_and_collide() and test_move() methods, which were on KinematicBody in Godot 3.x. However, they still return KinematicCollision objects. Something to note here is that the term "kinematic" no longer appears anywhere else in the API. This is inconsistent.

Should this be a "CharacterCollision", since that's what kinematic body is now called? What does it mean to get a "kinematic" collision after moving a "rigid" or "static" body?

2. CharacterBody

I don't object to this name change, but I do have some concerns with some of its properties:

• motion_velocity - I frankly don't like this at all. It's redundant for no discernable reason. It's equivalent to taking position and calling it location_position. This should be velocity.

• motion_mode == MOTION_MODE_FLOATING - this is in contrast to MOTION_MODE_GROUNDED, which indicates you have a floor/gravity, as in a side-scroller. However, if you're making a 2D topdown game, for example, you should use "floating" mode, which is not an intuitive name for it.

3. RigidDynamicBody

This seems needlessly verbose. There aren't multiple types of "rigid" body, so what is gained here over "RigidBody" other than more syllables? Yes, there's SoftDynamicBody3D, but that could just as well be SoftBody3D, without any loss of understanding. If this naming was necessary, why was VehicleBody3D kept as-is and not changed to VehicleDynamicBody3D? I wouldn't like it, but it would be consistent.

4. AnimatableBody

To be honest, I don't have a better suggestion for this one, I just know it doesn't feel right. It's awkward to read and to say.

It inherits from StaticBody, but doesn't add any additional API methods, just a single boolean property. Could this just be a toggle on StaticBody? Something like can_move or is_movable, or even is_animatable if you're stuck on that adjective.

Previous discussions

#2184
#2867

[Xrayez]

I just want to note the situation with verbose class names, which is not directly related to physics: you have to realize that many classes in Godot 4.0 are moving to explicit naming conventions, even if such explicitness is redundant. See recent renames and proposal like #3624.

But of course, the inconsistencies you mention are quite real in my eyes.

[cbscribe]

many classes in Godot 4.0 are moving to explicit naming conventions, even if such explicitness is redundant

That's fine. I like explicit. I just object when it becomes needlessly explicit. That's when it goes past clarification, and passes back into confusing again. It's not helpful to fix a nomenclature issue by creating a usability one.

I'm not kidding when I say I'm dreading having to type and look at motion_velocity for the next n years.

[azur-wolve]

1.

KinematicCollision → BodyCollision

2.

motion_velocity → body_motion
[the usage of name velocity as a user-custom Vector is a naming too spread along the community to rename it as]

MOTION_MODE_FLOATING → _FLYING | _AIR

3.

I would leave it as RigidBody tbh; it is a standard in the whole industry (thinking on users coming from other engines + ours).
[not sure if it changes as much as KinematicBody 3.x VS CharacterBody 4.x; in such case DynamicBody could work]

Agree with your SoftBody.

4.

And the pearl of the crown..
100%; "animatable?" the first moment I've read it (even not being native english speaker) thought "whats that, spanglish?" → animable | animed | animated sounds better.
Merging with StaticBody; less classes to care about.
[if the plan for Godot 4.x is to being considered more serious, definitely change it]

(the is_animatable suggestion/anecdote is from far the best quote of the whole post)

[cbscribe]

[the usage of name velocity as a user-custom Vector is a naming too spread along the community to rename it as]

I've seen this argument before, and I don't think it's valid.

The name velocity is used widely because that's what it is. We have position, and we should have velocity. We're already breaking old code in lots of ways, so this isn't a good excuse for using an awkward name.

[cbscribe]

MOTION_MODE_FLOATING → _FLYING | _AIR

This is still the same problem. In a top-down game, I'm not flying, floating, or in the air. I'm on the ground.

[azur-wolve]

Can implement an un-grounded state on practically any kind of 2D game (top-view, isometric, etc) so not sure if it is even an issue.

Only use it when need, otherwise don't.

[BastiaanOlij]

My 2 cents on this discussion, I agree with most of what @cbscribe states here. Some of these renames are just over verbose. RigidBody did just fine, I get and agree with the suffix 3D and 2D being added, that makes sense, but RigidDynamicBody3D doesn't add any more clarity to the name but it does add a lot of confusion to existing users who are going to wonder if it still applies to their use case or if there is some other rigid body they may need, and its more then a mouth full which is really fun for those of us who make tutorial videos and actually have to say this word out loud dozens of times.

While I agree with a lot of the changes in Godot as a whole (for instance Node3D makes so much more sense then Spatial), I do feel we've gone overboard by putting the focus on the wrong thing. What makes Godot great imho is how easy it is to work with and often short to the point names of nodes help here. Leave out the fluff.

Adding extra detail into a name just for the sake of convention needlessly confuses, it is much better to be to the point. motion_velocity is an excellent example here, there is only 1 velocity that is relevant here, so velocity is more then adequate and is consistently used as such throughout the application.
That there is an exception because for RigidBody there are two velocities and we need to be able to tell them apart, there it makes sense that we have a linear_velocity and an angular_velocity.

I've gone down this rabbit hole many times, trying to make up a convention for naming so things are precisely named, all its ever lead to for me is long confusing names where people start complaining when they find a use case for the object I made that doesn't fit the name precisely.

Keep it to the KISS principle and don't needlessly over complicate stuff.

[BastiaanOlij]

Btw, I do like CharacterBody over KinematicBody, I think character much better embodies what the nodes use is.

[theraot]

1. Yes, I agree KinematicCollision needs to change. and I like the idea of using BodyCollision that @KiwwiPity suggests.
2. • As far as I can tell, motion in motion_velocity refers to the fact that this velocity only has effect when we call move_and_slide. That is, writing it does not make the CharacterBody move. Which is also it makes sense to not have in the inspector. In fact, can we just have that one parameter? I know that all the parameters in move_and_slide et.al. became a mess, yet, at least the velocity would make sense. In some cases it changes virtually all the time, so we will be setting motion_velocity then calling move_and_slide.
   • How about MOTION_MODE_FREE vs MOTION_MODE_GROUNDED?
3. I don't care much about the word Dynamic.
4. We failed to agree on something better.

[cbscribe]

Well, I went ahead and made a PR changing motion_velocity to velocity, so that's taken care of.

I like MOTION_MODE_FREE, definitely better than FLOATING.

[eon-s]

My 0.000000002 cents:

1. PhysicsBody

• KinematicCollision: is a collision result of move which is a kinematic motion, but we can call it MoveCollision too I guess since it is result of move methods and nothing else.

2. CharacterBody

• motion_velocity - I think it is good for the reason that is hard for it to collide with existent code, calling it a common word like velocity will bring a lot of issues on code migrations, also it is not a physically simulated velocity but the fake velocity of this kind of bodies.
• MOTON_MODE_FLOATING- I agree _FREE could be a better word for it.

3. RigidDynamicBody
   I would go for DynamicBody and drop the Rigid (this will also separate Godot 3 examples from 4).

4. AnimatableBody
   This is part of a curse of inheritance, it is more clear to separate unmovable statics from movable ones, MovableBody does not sound good but is an option.
   Simplifying it in a property may end being confusing for users because behaviors will be strange and cumbersome because users will be forced to inherit a custom node to create movables and not movables easily and not having to toggle hundred of objects on and off in a big world.

[azur-wolve]

what about DynamicBody instead of AnimatableBody? (as it is the "counterpart" of StaticBody)
and keep RigidBody.

to keep it short:

─ PhysicsBody
  ├ StaticBody
  │ └ DynamicBody / Semi(/Demi)StaticBody / AnimableBody / MovileBody / MovileStaticBody / MovingBody
  ├ CharacterBody / KinematicBody
  ├ RigidBody
  │ └ VehicleBody
  └ PhysicalBone
─ SoftBody