Thoughts on Godot 4 naming for physics nodes

[azur-wolve]

Godot 4 looks like its going really well.
But there's something that keeps me thinking since some time ago..

The new explicit names RigidDynamicBody, SoftDynamicBody and AnimatableBody sound long and confusing.

RigidBody is already an industry standard, just like KinematicBody.
Not sure if is a good idea change it, as either users of previous Godot versions and those who migrate from other engines are already familiar with such.
There's plenty of info in the web for those terms, and are also the right technical ones, thus more appropriate.

What about to have either MovingStaticBody or DynamicBody (as can move, contrarily to StaticBody) instead of AnimatableBody, which sounds weird.

Also BodyCollision instead of KinematicCollision, as it has become more "generic".

Naming change suggestions:

─ KinematicCollision → BodyCollision

─ PhysicsBody
  │
  ├ StaticBody
  │ │
  │ └ AnimatableBody → DynamicBody || Mobile / MovingStaticBody || Animated / AnimableBody
  │
  ├ CharacterBody || KinematicBody [?]
  │
  ├ RigidDynamicBody → RigidBody
  │ │
  │ └ VehicleBody
  │
  └ PhysicalBone

─ SoftDynamicBody → SoftBody

What remains unclear for me is if keep CharacterBody or switch back to KinematicBody.
(the former is more descriptive, but the later is an industry standard)

About having more descriptive names.. such is good.
But keep names short is as well. (they already add 2D | 3D at name ending)

Instead of changing too much naming I would focus more on improve the definitions on API reference and promote its usage.
Pretty sure that many doesn't use it as much as they should.

The first short description in the top section (API reference) lets figure out what it is and does without too much jargon:

RigidBody → body affected by collisions (simulated physics), doesn't deform.

SoftBody → body affected by collisions (simulated physics), gets deformed.

StaticBody → body that can't be affected by collisions (simulated physics), but can be collided by others. Doesn't move.

AnimatableBody → like StaticBody but can move by scripted motion.

KinematicBody → body moved by scripted motion
etc

Related:

#4072
#2184
#2867
https://www.reddit.com/r/godot/comments/wrwzig/what_should_rigidbody_be_called_in_godot_4/

[golddotasksquestions]

I'm all for sticking with the well known game industry and beyond naming conventions. However,

StaticBody → body that can't be affected by collisions, but can be collided. Doesn't move.

Did I miss something? Last time I checked core devs wanted StaticBodies to move as well (really bad idea imho). See #2184 #2867

MovingStaticBody || DynamicBody → like StaticBody but can move.

MovingStaticBody is just as bad if not even worse than RigidDynamicBody. Why anyone would think putting a contradiction in the name would make it more intuitive to understand what this node is for, is beyond me.

DynamicBody, is as far as I understand, is the "meta" idea for anything physics driven, including SoftBody physics.

I've said this in #2867, the reason we are having troubles with naming here is with the unclear direction on how these classes should be used.

Give them clear cut functionality which is not overlapping each other, and it will be a breeze to fix the naming. Otherwise this discussion will be endless, going on forever.

[Zireael07]

@KiwwiPity Actually I like AnimatableBody a lot, it's a good solution and a good name that fits what it does

[golddotasksquestions]

@KiwwiPity

Moving static bodies are useful for moving platforms in platformer games and the like (probably you've played Spyro, Crashbandicoot, etc)

I agree with you on your other points, but having that functionality in the StaticBody is utter BS. If you want a moving platform or conveyor belt, use KinematicBody! That's what they are for! It's even in the name!

[azur-wolve]

@golddotasksquestions not 100% sure about this, but if IIRC heard that the KinematicBody implementation is a bit expensive on performance.
Maybe this is one of the reasons they have taken this path.
(take a look on my last entry if so)

[golddotasksquestions]

@golddotasksquestions not 100% sure about this, but if IIRC heard that the KinematicBody implementation is a bit expensive on performance. Maybe this is one of the reasons they have taken this path. (take a look on my last entry if so)

That's simply not true. You can run hundreds of KinematicBodies simultaneously without doing any meaningful optimization. Seriously, how many platforms do you need at once on screen?

Also, if this would be a performance issue and a separation of functionality therefore is required, why not just do that instead of mix-mashing various functionality and node names together? Keep the StaticBody as an actual static body, add new node that does what ever else is commonly needed. Like MovingPlatform node.

[azur-wolve]

My knowledge ends there, but surely they have their reasons to have separated it as derived node.

[azur-wolve]

Instead of AnimatableBody, what about StaticKinematicBody.
Such name reflects exactly what it does: "Like a StaticBody but can be moved by scripted motion."
Placing Static first means that it is a StaticBody with kinematic behavior.
The word Animatable by itself doesn't describe that it is a StaticBody with moving capability.

I would suggest:

─ BodyCollision

─ PhysicsBody
  │
  ├ StaticBody
  │ │
  │ └ StaticKinematicBody
  │
  ├ KinematicBody
  │
  ├ RigidDynamicBody → RigidBody
  │ │
  │ └ VehicleBody
  │
  └ PhysicalBone

─ SoftBody

CharacterBody will be used for more use-cases than only characters, so better leave it as KinematicBody, as it is also an industry standard. (why not explain well what "kinematic" means in the API definition?)

Not all are bad things; I praise the devotion of the Godot developers to make the engine more accessible for everyone, but things can be eased and simplified until a certain point..
Gamedev aspirants always will must overcome their comfort zone and clear their ignorance and expand their cache by researching, asking and experimenting.

For the case being discussed here, the common sense says that is better keep names short and use industry standards.

I would encourage anyone who wants that to give it visibility to let the devs know our opinion, otherwise we will be forced to use those names during years.

About using Dynamic.. such term is so generic, so it feels obscure.

[golddotasksquestions]

StaticKinematicBody

How do you (and others who propose similar solutions) don't see how bad of an idea it is to combine contradicting concepts in the name and functionality of a node?

If we are going to change such fundamental aspects of the engine which are used daily by pretty much everyone, why would you replace the old (which at least kinda follows well known convention beyond the industry) with even more confusing functionality and naming??

[azur-wolve]

On that single aspect you're mixing the literal universal meaning of "static" with its true use-case on gamedev.
(however your complains have their own sense)

For gamedev:
Static → body Tansform isn't affected by simulated physics (collisions), but can be collided by other bodies that can be affected by.

Kinematic → moves by scripted movement, instead by simulated physics (collisions). But it can be affected by those.

Static + Kinematic → isn't affected by collisions, but can be moved with scripted movement logic.

The word Animatable by itself is obscure; it means that only can be moved by animation nodes?
Here's an unclear barrier between movement and animation.
(if movement stuff is influenced by animations is something too custom of a project, rather than something generic)

The problem with computer programming here regarding naming, is that various types of complexity collide:

• Essential Complexity → relative to the problem to solve.
• Accidental Complexity → relative to computing limitations.
• Information Complexity → ubiquitous (here would be the necessity of having fixed-excluding meanings for names to avoid semantic collisions)

I notice here that make emphasis on the differences between the 2 types of movement:

• physics simulation (collisions)
• scripted movement

could clear a lot of doubts, and be instructive as well.

[azur-wolve]

Another alternative to AnimatableBody could be MovingStaticBody.
Or AnimatedStaticBody.

[azur-wolve]

[Take it as constructive feedback]

Something that I wonder is:
Changing the names of physics nodes for letting newbies figure out things fast will really change much?
I mean, physics isn't a basic aspect, and even if they understand their names, they still need to learn coding to use them, without speak about the complex problems of made themselves to the Godot's way of doing things, and other non-basic stuff like debugging and so on.
Newbies will eventually overcome the initial learning curve, if they persist.
Computer programming in general never will be easy, specially for those who don't.
Same for gamedev in general, due its inter-disciplinary and real-time nature.
You can ease it some amount with tools like Godot itself, but there will be always an unavoidable difficulty.

On the other hand, if those names are kept as now, they won't align with industry standards, so its another barrier for users that already know the names in Godot 3 and users that migrate from other engines.

Also it can be perceived by experienced developers as something opposed to "professional / serious".
Is good that Godot does stuff on its own style, but names can become a barrier; better stick to industry standards, there are already definitions and info about terms like RigidBody, SoftBody and KinematicBody on the web that apply to them in general, not only relative to Godot.

If another reason to change them to avoid confusions between versions, it only needs to clarify that Godot 4 is different to Godot 3.
Users will stumble with it and figure out soon.
Found that the new names are confusing, obscure, weird and too long (already have the 2D / 3D suffix added).

Conclusion:

Better keep names short and following industry standards.
That's a preoccupation for me because if it isn't change will be forced to live with it for years.
But I assume that if those names are kept, there will be complains about.