Make physics nodes easier to understand

[pouleyKetchoupp]

Describe the project you are working on

Godot Engine

Describe the problem or limitation you are having in your project

Current state: After #2184 (physics nodes reorganization) has been implemented, each physics node consistently takes care of a specific game use case, or a group of related game use cases, which is a big step in the right direction.

Problem: As a consequence though, some physics node names are confusing and their name could reflect their general usage better, as most nodes do.

Examples: Some physics nodes have names that describe their functionality very well, like CharacterBody (the new node that replaces KinematicBody for character specific features), VehicleBody (obviously specialized in vehicles) or SoftBody (generic node for soft physics used for clothes and soft volumes).

On the other hand, some names are less clear.

For example, StaticBody can not only be used for actual static bodies (walls, floors), but also moving platforms. It makes sense to group these functionalities together, but the name can be misleading, especially for beginners. Basically, StaticBody has two modes of functioning: Static and Kinematic (more details about body modes below).

Another example is RigidBody, which follows a usual convention from physics engines, but can be misleading for users not familiar with these terms. Rigid can be interpreted as something fixed, while this node is meant to be used for any general physics object (with a specified body mode, see more details below).

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

This proposal is about harmonizing the way physics nodes are named, by giving them names that describe their game functionality rather than their state in the physics engine, by following two simple rules:

1. Physics nodes are named after their use case

Change physics node naming to be based on use cases, while physics modes are based on behavior within the physics engine.

2. Body modes are not used for naming physics nodes

The physics engine uses body modes internally (Static, Dynamic, Kinematic, DynamicLocked - previously Character). These modes shouldn't be used to name physics nodes, because different nodes can use the same body modes, and the same physics node can switch between different body modes.

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

Name proposals: I will post specific suggestions to rename some of them in the comment section. If anybody wants to propose different names, you can add them in separate comments as well, after reading the details below for context.

Note: This proposal is about naming physics nodes. Discussions about the way functionalities are split between nodes, or comments about adding new nodes will be considered off-topic.

---

Body modes

These names would be reserved for internal modes in the physics engine, that way none of the node names can be mistaken for one of the body modes.

Here's the definition of the different body modes, used inside of the physics engine for different nodes: Static means the object can't be physically pushed by other objects. Kinematic can't be pushed by other objects and also moves following a predefined motion. Dynamic means the object is fully simulated with applied forces and can be pushed around. DynamicLocked same as Dynamic but can't rotate.

---

Current physics node names

Here's the list of all physics nodes, with their current name, usage and corresponding body modes. Note discrepancies between some of the node names and their possible modes.

-StaticBody Use cases: Commonly used for floor, walls, platforms and moving platforms. Modes: Static, Kinematic.

-RigidBody Use cases: Standard usage for anything that is physically simulated or can switch modes, and uses solid shapes. Modes: Static, Kinematic, Dynamic, DynamicLocked

-CharacterBody Use cases: Used specifically for character controllers. Mode: Kinematic

-VehicleBody Use cases: Used specifically for vehicles. Mode: Static, Kinematic, Dynamic, DynamicLocked

-PhysicalBone Use cases: Ragdoll parts attached to skeleton bones. Mode: Static, Kinematic, Dynamic, DynamicLocked

-SoftBody Use cases: Standard usage for anything that uses soft physics (clothes or soft volumes). Modes: n/a (different type of physics simulation)

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

Node names are set in the core engine.

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

Physics nodes are already part of the core engine.

[pouleyKetchoupp]

-StaticBody: I'm proposing ObstacleBody instead, which is a more generic term that applies well to any kind of wall, floor or moving platform.

[pouleyKetchoupp]

-RigidBody: I'm proposing SolidBody which may better describe the functionality. It can be any kind of body, as opposed to SoftBody, without the term Rigid that can be misinterpreted as a fixed object.

[jcostello]

What would be the diference between StaticBody, RigidBody and CharacterBody in the same mode Kinematic?

[charlesmlamb]

Well, one could maybe look at the best names, like try to find better ones . . <3

StaticBody could, also be called FixedBody, or ImmovableBody, or BarrierBody . .

KinematicBody could be called PlayerBody, but one can also use it for doors, in official docs . . :OO

RigidBody, could be called PhysicsBody, bec. that's what it is, and SoftBody could be called SoftPhysicsBody, or not sure . . .

There aren't many names that capture what they do well . . . one thing, that could be possible, was on node selection list, to add a more full description <3

So, if the description below each body - type was more descriptive . . That'd help beginners . . tbh, I'd not change the names, since for many it'll be confusing . . It's already weird, bec. KinematicBody has a ' person ' icon but, official docs say it's also used, for doors, etc . . .

you could call StaticBody, maybe SolidBody . . I guess, it's too complex, or so . . Also, one could basically call a StaticBody, a RigidBody since, it doesn't move, or so . . . I'd rather stick with the current names, until there's some REALLY good ideas, for making them better, I also had this problem, didn't know if KinematicBody, or RigidBody was better, for a character controller, had to ask online, they said RigidBody is if you want a character, with physics, like a boat - game or, helicopter game, where player had SOME physics simulations . . .

Also call RigidBody PhysicsBody, or GravityBody, or ForceBody . . . Well, hope you find the answer, it's really complex, Thanks . . . . .

It's complex, not easy to answer, current one's do the job, but are rather complex, for beginners <3 . . . Even after one year, I'm still not 100 % sure, I'm using the ' right ' nodes, etc . . .

[AttackButton]

Ok. My suggestion is to change the name from StaticBody to ComponentBody.

This could also be StructuralBody or InteractiveBody.

[theraot]

For another name for StaticBody, consider StageBody. As in wall and floor are part of the stage. In fact, if we go with the theater analogy (see CharacterBody), then RigidBody could be PropBody, in particular considering that prop is a term already in use in game development.

By the way, if we consider RigidBody the opposite of SoftBody, then HardBody makes sense, and it does not connote inmovible.

[MadMinstrel]

My two cents: I don't much care what the actual names are, but please make sure this sort of unembellished plain english overview of what each of them is supposed to be used for makes it in to the documentation. This PR is already much, much better than the docs at explaining the basics.

[SilencedPerson]

For another name for StaticBody, consider StageBody. As in wall and floor are part of the stage. In fact, if we go with the theater analogy (see CharacterBody), then RigidBody could be PropBody, in particular considering that prop is a term already in use in game development.

By the way, if we consider RigidBody the opposite of SoftBody, then HardBody makes sense, and it does not connote inmovible.

I like this one the most, the allusion to theatre makes it much easier for me to think about these concepts. It even makes sense with the existing Scene system and well the name Godot. In the same spirit, we could also do ActorBody instead of CharacterBody just because it's shorter and has basically the same meaning.

[charlesmlamb]

If this was to be done, I'd rather have we get maybe 5 nodes in total, and give them specific names, for specific use - cases . . .

If StaticBody can be used for animated stuff, as well as never move, make a ' StaticBody ' that can only be used for one thing, static objects, that DON'T move . . .

Then, make a PlayerBody or, ControllerBody ( FPS, TPS controller ) body, that has everything for classic characters, and make a PhysicsBody, that can ONLY be used for one thing . . .

Alternative, rename it from 'Body', to 'Object', so they're called StaticObject, CharacterObject, ClothObject and, so on . . .

I mostly don't like the word RigidBody for physics, bec. those bodies well, tend to move a lot, and not be 'static', more like GravityBody or, PhysicsBody . . Also, KinematicBody doesn't really make sense, bec. it's used mostly for characters or, ' actors ' . . .

I'd rather we had a few more nodes, where one was made for NOT moving, ever . . Call it, EnvironmentBody or, StaticBody . . . Or, BackgroundBody . . . maybe FixedBody, or LockedObject . . :OO

The biggest problem with naming them is, they do different things, not just 'one' . . I'd like to add, maybe it'd be smarter to first make these 4 nodes, into 5 - 6 nodes and, THEN rename them, when it's clear, what they do <3 . . .

Also, I'm fine with the current names, think it works rather well, I just think you really need to brain-storm this, REALLY think, bef. you rename them and, consider making these 4 nodes, into maybe 5, or 6 . . With, more specific use - cases for each, like a special CharacterBody or, so . . . <3 Maybe, CharacterBody had RayCast gravity built into it, or something . . . As long as the nodes can be used for several things, properly renaming them is, brutally tough . . it never ' really ' fits, etc . . .

Hope you'll really brain-storm this, from all angles, then implement a ' solid ' suggestion, thx . . .

Also, RigidBody could be called SolidBody . . :OO . . . Hope you could make a list, of all these suggestions, and vote-discuss-etc, thx <3 <3

ps. I really like this proposal, it's just difficult, how to fix it, without creating new problems, ie. KinematicBody becomes CharacterBody, but it can be used, for doors, also . . . :OO . . .

Also, KinematicBody is sometimes used for creatures, that are not 'theater' actors so, the name ActorBody doesn't make sense, it's horribly complicated, hope you can find a great update, to Godot 4, atm it's not the best, etc . . <3 . . .

[charlesmlamb]

Why not make some-thing like a PlatformBody, that has a feature, it can add it's 'translation' to anything attached to it . . .

Also, divide into KinematicBody into well 'DoorBody' and, 'PlayerBody' or, 'CharacterBody', and also divide StaticBody into something that will never move, and a staticbody, that could be moved and, impact the environment . . .

Last, maybe have a GravityBody, with just a few physics settings, and one, with almost every physics setting . . . :OO

I'd rather we talked, can the nodes be divided into more clear use - cases and, then also re-named :OO . . .

ps. Really like the suggestions here, one problem is, also, a ' CharacterBody ' would also be used, for ' enemies ' or, even creatures, etc . . . So, is that a really good name, for instance is a skeleton, a ' character ', since it doesn't really do ' theater ' acting, ie. it can't talk, same thing for say, a stone - golem, so on . . .

Sry, for the long text, it'd be easier to rename them, if they had more specific use - cases, or so . . . .

[charlesmlamb]

One last thing, I don't like ActorBody, bec. it almost is same, as DramaBody, or TheaterBody . . It sort of assumes you want to do 'drama' or, acting, and for me, that's not something I'm looking to add, ie. ' drama ' . . :OO <3

Other than that, suggestions here are all very good <3 . . .

[theraot]

Some more ideas:

• StaticBody -> FirmBody (trying to convey that you cannot push them, however they are not static in that they can move)
• RigidBody -> LooseBody (you can push them, they fall, they bounce)
• CharacterBody -> AgentBody (they do things)

[Zireael07]

AgentBody, actually, is a nice alternative to CharacterBody <3

[eon-s]

The word agent suggest a relation with navigation and AI controllers, which is common on other engines/frameworks.

[AttackButton]

For another name for StaticBody, consider StageBody. As in wall and floor are part of the stage. In fact, if we go with the theater analogy (see CharacterBody), then RigidBody could be PropBody, in particular considering that prop is a term already in use in game development.

By the way, if we consider RigidBody the opposite of SoftBody, then HardBody makes sense, and it does not connote inmovible.

Nice. StageBody fits very well with the StaticBody new design. I really can see the use of "Stage body in static mode" or "Stage body in kinematic mode".

[pouleyKetchoupp]

@jcostello

What would be the difference between StaticBody, RigidBody and CharacterBody in the same mode Kinematic?

They propose very different functionalities even when based on the same mode in physics, because they all have their own code and a separate API:

StaticBody uses kinematic mode for moving platforms. When enabled, it can be controlled by script or animation to move to a certain spot and collide with anything on the way, and has sync_to_physics option to help synchronizing with characters walking on it.

RigidBody is a generic node that is mainly used for dynamic objects, so it has an API for applying forces, gravity, etc. But it can also be used to switch between modes. It doesn't have the same options StaticBody has, but it allows a simple version of kinematic mode this way (motion can be controlled, but it doesn't have the specific moving platform options).

CharacterBody has a specific API for character controllers. Its main use is for move_and_slide which handles floor and walls detection as well as moving in slopes. It has a set of properties to help with different scenarios, and it will be extended to handle special cases for different types of character controllers.

[AaronRecord]

Isn't RigidBody also somewhat commonly used for character controllers? They come with gravity, and they work with area's physics overrides without any custom logic.

[jcostello]

@pouleyKetchoupp knowing that im OK with the naming it currently has. But if you want suggestions:

StaticBody leave it as it is. Is static not because is not moving, but because is not receiving any forces. Maybe MechanicalBody but Im not sure RigidBody -> PhysicBody

[charlesmlamb]

Last, I think the names KinematicBody, RigidBody has something to do, with physics, in school . . .

I think having such names make it more ' universal ' and, I like the convention . . It's sort of ' neutral ' and, appeals to every-body . . . So, not sure what physics names one can use, anyway one mostly sees ' Actors ' in the commercial engines, Unreal, etc . . I like the more neutral, any use-case physics, math names, over the engine making me think, in terms of ' Actor ' or, drama . . . It belong in some games, in many others, it's moot . . . I prefer a physics based naming, also because Principle shader runs on that, so on . . Most engines are making that standard, and work in ' scientific ' units, not more ' soft ' names, etc . . . <3 . . .

I'd rather not have ' theater ' names, for the nodes, bec. it implies one has to be 'interested' in those things, to ' use ' the nodes, ie. not just a character, like a ball, or so . . . But, is more for 'theater' and Hollywood production . . .

I think the current one's are better, physics based naming . . Bec., it's more ' neutral ' or, universal, and one can easily make a character, even, with mo-cap, acting . . If one wants :OO . . Anyway, physics are more neutral than, ' acting ' names, etc . . .

[Strangemother]

I feel it's important to identify them using existing terminology. When I picked-up godot, I instantly knew the purpose of RigidBody and StaticBody due to their name. That said, a static body isn't strictly static, and not all user agents are a "character".

Current	Suggestion	Reason
StaticBody	ColliderBody	More informative, it's part of the dynamic body set, universe locked (like a superconductor train)
SoftBody	--	No change
RigidBody	DynamicBody	Explicitly Identify this node as world relative / affected by local gravity
CharacterBody	ActorBody	A dynamic body the user manipulates. An actor is ambiguous to application (but not a "puppet" due to RPC references)

All these items are part of the "Dynamics Body" family - Of which extend Physics Body units.

SoftBody shouldn't change - it makes sense. ActorBody is a great suggestion by @SilencedPerson (and others but not me originally). Personally I feel RigidBody could remain as it matches other 3D apps.

[vesk4000]

Last, I think the names KinematicBody, RigidBody has something to do, with physics, in school . . .

I think having such names make it more ' universal ' and, I like the convention . . It's sort of ' neutral ' and, appeals to every-body . . . So, not sure what physics names one can use, anyway one mostly sees ' Actors ' in the commercial engines, Unreal, etc . . I like the more neutral, any use-case physics, math names, over the engine making me think, in terms of ' Actor ' or, drama . . . It belong in some games, in many others, it's moot . . . I prefer a physics based naming, also because Principle shader runs on that, so on . . Most engines are making that standard, and work in ' scientific ' units, not more ' soft ' names, etc . . . <3 . . .

I'd rather not have ' theater ' names, for the nodes, bec. it implies one has to be 'interested' in those things, to ' use ' the nodes, ie. not just a character, like a ball, or so . . . But, is more for 'theater' and Hollywood production . . .

I think the current one's are better, physics based naming . . Bec., it's more ' neutral ' or, universal, and one can easily make a character, even, with mo-cap, acting . . If one wants :OO . . Anyway, physics are more neutral than, ' acting ' names, etc . . .

Yeah I mostly agree with this. Despite that on the face of it choosing better names seems like a good idea, I actually think that the current names are quite alright. I spent some time trying to think of better names, but I just couldn't. I also just really didn't like any of the ones suggested here. I especially don't like all of these theatrical suggestions. I mean Scene is fine, but ActorBody, StageBody and PropBody just don't sound right to me at all. I've seen such names in other engines and they have always been kinda odd to me. They are way too specific and they aren't all that intuitive to me. In my opinion the nodes should ideally be named after how they behave and these names don't do that at all.

RigidBody is perfectly fine, it is rigid - it's not flexible, it doesn't deform CharacterBody is alright, my only gripe with it is that 'character' is not an adjective but I guess that's not much of a problem. To me the term 'character' feels broader than 'actor', but it still encompasses only what it actually is, so I think it is better. StaticBody is ok, although given that it will be able to move like a platform or something they should probably be a better name, but I as I said I just can't think of one and I haven't seen one on here that I think is better

Maybe there really are some better names out there, but I dunno ¯\_(ツ)_/¯

[vesk4000]

I feel it's important to identify them using existing terminology. When I picked-up godot, I instantly knew the purpose of RigidBody and StaticBody due to their name. That said, a static body isn't strictly static, and not all user agents are a "character". Current Suggestion Reason StaticBody ColliderBody More informative, it's part of the dynamic body set, universe locked (like a superconductor train) SoftBody -- No change RigidBody DynamicBody Explicitly Identify this node as world relative / affected by local gravity CharacterBody ActorBody A dynamic body the user manipulates. An actor is ambiguous to application (but not a "puppet" due to RPC references)

All these items are part of the "Dynamics Body" family - Of which extend Physics Body units.

SoftBody shouldn't change - it makes sense. ActorBody is a great suggestion by @SilencedPerson (and others but not me originally). Personally I feel RigidBody could remain as it matches other 3D apps.

To me ColliderBody sounds like something about it's collisions is special, when what is actually special about it is that it's movement is not controlled by the physics engine

DynamicBody sounds very ambiguous to me, it doesn't really tell me much about what it actually is. RigidBody is better imo, and it also contrasts well with SoftBody, which deforms, while RigidBody is 'rigid' and doesn't deform

As I said in my previous comment, ActorBody really just doesn't sound intuitive to me at all. My character in my game is not some 'actor' in a play or a film, it's a character in a game. This also makes even less sense if we are not using the rest of the theater analogies for the rest of the bodies.

[theraot]

@pouleyKetchoupp How about we go the other way? Rename the modes instead of renaming the nodes. If I understand correctly, one of the goals of this proposal is to avoid confusion between the names of the modes and the names of the nodes. However, people are going to see the names of the nodes first, and there is already some familiarity with the current names.

In fact, I believe the names of the modes can afford to be more descriptive.

For example:

• Static -> NoMotion (so you can keep StaticBody)
• Kinematic -> ScriptedMotion (you can bring back KienamticBody)
• Dynamic -> DynamicMotion (Dynamic has no conflict, I'm just giving a naming pattern)
• DynamicLocked -> DynamicUprightMotion (Locked what? this is more descriptive)

[Strangemother]

... To me ColliderBody sounds like something about it's collisions is special, when what is actually special about it is that it's movement is not controlled by the physics engine

DynamicBody sounds very ambiguous to me, it doesn't really tell me much about what it actually is. RigidBody is better imo, and it also contrasts well with SoftBody, which deforms, while RigidBody is 'rigid' and doesn't deform

As I said in my previous comment, ActorBody really just doesn't sound intuitive to me at all. My character in my game is not some 'actor' in a play or a film, it's a character in a game. This also makes even less sense if we are not using the rest of the theater analogies for the rest of the bodies.

Ye you raise some good points. I think at this point we could yak shave forever regarding semantics and subjective vernacular. I feel your response somewhat validates my point, as you're right DynamicBody is ambigous, but so is Collider - as static infers unmovable solidity and in my humble opinion is less special that a "Static" entity. e.g. "everything in the world is collidable, but not everything is static"

And you've really driven the point home with the Character <> Actor term; as you see "actor" a theatrical product, but I see "Character" in the same manner and an "actor" as a generic entity for action. At this point I like to find the real world appliance of the term, and see which one fits best.

Actor:

• a person whose profession is acting on the stage, in films, or on television.
• a participant in an action or process.

Character:

• the mental and moral qualities distinctive to an individual.
• a person in a novel, play, or film.
• a printed or written letter or symbol.
• a characteristic, especially one that assists in the identification of a species.

My character in my game is not some 'actor' in a play or a film,

And I feel this is my point - You've identified a CharacterBody as as a "character" within a game. And if we're working with your analogy; an Actor has many roles - including the Character you prefer; I don't use the Character in the same way

---

As such, perhaps both terms aren't perfect; and a more InteractiveBody is needed - but this steps upon the "Kinematic" reference and detracts from the real purpose of imparting inferred knowledge through association of terms.

---

[golddotasksquestions]

I appreciate the opportunity you asking the community to participate in finding easier to understand names, but I think the problem why the role and purpose of the Physics Nodes are hard to define/understand is not the naming of the bodies, but the ambiguity of what those bodies do, their behaviour.

You propose to solve this issue with giving them names by usecase. However this is hurts discoverability and understanding of role and purpose in every other usecase other than the one used for the name and does not solve the ambiguity of their behaviour. Case in point: Renaming KinematicBody to CharacterBody. KinematicBodies are used for a million different things that are not characters, but have deterministic kinematic behavior.

I don't see a single good reason to use a StaticBody for a moving platfrom. But since someone wants this usecase to the be included with this body, (therefore a moving StaticBody), we have an issue with naming them and explaining their role and purpose. It would be so easy: Remove the platform usecase and the Kinematic mode from StaticBody and done. Self-explanatory! No need to rename anything.

I don't know why we need three Bodies that all have the same modes and therefore probably very similar behaviour. Why can't this just be one node? I honestly did not see many (or any) people using the VehicleBody anyway over the last two years on the community channels I frequent daily. I'd much rather have a beginner friendly RigidBody (only has Rigid Body mode) and another more advanced RigidBody (called DynamicBody?) with all the other modes.

[just-georgeb]

Last, I think the names KinematicBody, RigidBody has something to do, with physics, in school . . . I think having such names make it more ' universal ' and, I like the convention . . It's sort of ' neutral ' and, appeals to every-body . . . So, not sure what physics names one can use, anyway one mostly sees ' Actors ' in the commercial engines, Unreal, etc . . I like the more neutral, any use-case physics, math names, over the engine making me think, in terms of ' Actor ' or, drama . . . It belong in some games, in many others, it's moot . . . I prefer a physics based naming, also because Principle shader runs on that, so on . . Most engines are making that standard, and work in ' scientific ' units, not more ' soft ' names, etc . . . <3 . . . I'd rather not have ' theater ' names, for the nodes, bec. it implies one has to be 'interested' in those things, to ' use ' the nodes, ie. not just a character, like a ball, or so . . . But, is more for 'theater' and Hollywood production . . . I think the current one's are better, physics based naming . . Bec., it's more ' neutral ' or, universal, and one can easily make a character, even, with mo-cap, acting . . If one wants :OO . . Anyway, physics are more neutral than, ' acting ' names, etc . . .

Yeah I mostly agree with this. Despite that on the face of it choosing better names seems like a good idea, I actually think that the current names are quite alright. I spent some time trying to think of better names, but I just couldn't. I also just really didn't like any of the ones suggested here. I especially don't like all of these theatrical suggestions. I mean Scene is fine, but ActorBody, StageBody and PropBody just don't sound right to me at all. I've seen such names in other engines and they have always been kinda odd to me. They are way too specific and they aren't all that intuitive to me. In my opinion the nodes should ideally be named after how they behave and these names don't do that at all.

RigidBody is perfectly fine, it is rigid - it's not flexible, it doesn't deform CharacterBody is alright, my only gripe with it is that 'character' is not an adjective but I guess that's not much of a problem. To me the term 'character' feels broader than 'actor', but it still encompasses only what it actually is, so I think it is better. StaticBody is ok, although given that it will be able to move like a platform or something they should probably be a better name, but I as I said I just can't think of one and I haven't seen one on here that I think is better

Maybe there really are some better names out there, but I dunno ¯_(ツ)_/¯

I generally agree with this.

"Soft Body" I think is clear & the same name as in other software

"Rigid Body" is the common name in other software, and while it doesn't specifically imply it is force based / dynamics / etc, it does imply how is it different to "Soft Body". The only real suggestions I can think of as alternatives are "ForcedBody" or "DynamicBody" but I don't think either of those are any clearer, and if it isn't clearer than the current name then changing it will presumably just add more confusion than it solves? I don't really like the suggestions like SolidBody because they don't tell you that it is simulated/force based so again don't really add any clarity to what the node is doing

"Static Body" to me should always be static, so being able to move it other than by teleport seems counter intuitive. I'm thinking of the moving platform tutorial - if it opens with "First, you need to add a StaticBody...", the first thing I'd do is check I'm on the right tutorial!

"Kinematic Body" as it is currently is fairly intuitive to me - kinematics means it is movement based not force based, but implies that the body is going to be moving during the game. This node makes sense to me to be used for anything that you want to control movement of, whether it's moving platforms, characters, ...

With that in mind I think the best way would be to keep static and kinematic bodies separate so end up with: StaticBody KinematicBody RigidBody SoftBody

And I'm fine with CharacterBody, VehicleBody & the other extended nodes to add extra functionality to those.

If static and kinematic bodies need to be combined, I think I'd actually feel better about it being called "KinematicBody" and giving it a tickbox "Static":

• kinematic says it's movement based not forced based
• static tickbox then means it can get some physics / rendering optimisations

Downside is it's probably less intuitive if your buildings are all made up of kinematic bodies.

[vesk4000]

... To me ColliderBody sounds like something about it's collisions is special, when what is actually special about it is that it's movement is not controlled by the physics engine

DynamicBody sounds very ambiguous to me, it doesn't really tell me much about what it actually is. RigidBody is better imo, and it also contrasts well with SoftBody, which deforms, while RigidBody is 'rigid' and doesn't deform

As I said in my previous comment, ActorBody really just doesn't sound intuitive to me at all. My character in my game is not some 'actor' in a play or a film, it's a character in a game. This also makes even less sense if we are not using the rest of the theater analogies for the rest of the bodies.

Ye you raise some good points. I think at this point we could yak shave forever regarding semantics and subjective vernacular. I feel your response somewhat validates my point, as you're right DynamicBody is ambigous, but so is Collider - as static infers unmovable solidity and in my humble opinion is less special that a "Static" entity. e.g. "everything in the world is collidable, but not everything is static"

And you've really driven the point home with the Character <> Actor term; as you see "actor" a theatrical product, but I see "Character" in the same manner and an "actor" as a generic entity for action. At this point I like to find the real world appliance of the term, and see which one fits best.

Actor:

• a person whose profession is acting on the stage, in films, or on television.
• a participant in an action or process.

Character:

• the mental and moral qualities distinctive to an individual.
• a person in a novel, play, or film.
• a printed or written letter or symbol.
• a characteristic, especially one that assists in the identification of a species.

My character in my game is not some 'actor' in a play or a film,

And I feel this is my point - You've identified a CharacterBody as as a "character" within a game. And if we're working with your analogy; an Actor has many roles - including the Character you prefer; I don't use the Character in the same way

---

As such, perhaps both terms aren't perfect; and a more InteractiveBody is needed - but this steps upon the "Kinematic" reference and detracts from the real purpose of imparting inferred knowledge through association of terms.

---

Yeah, you definitely do raise some good points as well. Maybe most of this is simply subjective, but:

My problem with ColliderBody is that it just doesn't sound like what it actually is. To me if I read ColliderBody I would assume that it is a body that collides with other bodies or at least other bodies collide with it. Now this is true for StaticBody, but it is also true for RigidBody, so ColliderBody is not descriptive enough, it is too broad. I mean if I didn't know I might even assume that this is some parent node that other nodes which use collisions inherit from. I agree though that StaticBody is the worst of the current names simply, because the actual node can non-static. However I don't think it's much of a problem since, to me at least, it's not too unintuitive. If I use a StaticBody for the walls/ground it's not much of a stretch to think to use it when making a moving platform, even though it is not actually static.

DynamicBody honestly just means nothing to me. Again I don't think it describes the actual node very well. What's dynamic about it? Can it change its shape, like a SoftBody? No. Can it move around? Yes, but so can StaticBody, CharacterBody and SoftBody. It doesn't actually describe what is special about it, which in this case is the fact that its movement is entirely controlled by/within the physics engine, but it doesn't deform like a SoftBody.

And maybe this is the most subjective of the three but ActorBody really just doesn't sound right to me. In a game, when I think of a player, an enemy or an NPC, I always think of them as a 'character' and not an 'actor'. Even if it is some random inanimate object that for whatever reason needs to move in some sophisticated scripted way, I wouldn't think of them more as an 'actor', than I would a 'character'. Also I may be wrong but from what I understand, this CharacterBody will contain specific features, which are often a part of so-called 'character controllers'.

Overall, I don't actually care that much about what they are called, but I really do think their names are mostly fine for now. Also I'm not a native english speaker, so maybe that has something to do with why some things sound off to me. I'm not sure though, maybe it is just very subjective.

[vesk4000]

I appreciate the opportunity you asking the community to participate in finding easier to understand names, but I think the problem why the role and purpose of the Physics Nodes are hard to definte/understand is not the naming of the bodies, but the ambiguity of what those bodies do, their behaviour.

You propose to solve this issue with giving them names by usecase. However this is hurts discoverability and understanding of role and purpose in every other usecase other than the one used for the name and does not solve the ambiguity of their behaviour. Case in point: Renaming KinematicBody to CharacterBody. KinematicBodies are used for a million different things that are not characters, but have deterministic kinematic behavior.

I don't see a single good reason to use a StaticBody for a moving platfrom. But since someone wants this usecase to the be included with this body, (therefore a moving StaticBody), we have an issue with naming them and explaining their role and purpose. It would be so easy: Remove the platform usecase and the Kinematic mode from StaticBody and done. Self-explanatory! No need to rename anything.

I don't know why we need three Bodies that all have the same modes and therefore probably very similar behaviour. Why can't this just be one node? I honestly did not see many (or any) people using the VehicleBody anyway over the last two years on the community channels I frequent daily. I'd much rather have a beginner friendly RigidBody (only has Rigid Body mode) and another more advanced RigidBody (called DynamicBody?) with all the other modes.

Very well said. Honestly I've always wondered why there is StaticBody and KinematicBody when there is RigidBody, which - through its different modes - can do all of the things that they can do and more that they cannot. Honestly maybe there should be just RigidBody, which is also used instead of StaticBody and KinematicBody. And then maybe there should be nodes like CharacterBody and VehicleBody, which simply extend RigidBody and provide some more specific but nevertheless quite commonly needed additional functionality.

[theraot]

Forgetting analogies and so on. Considering types of physics simulations, we have:

Physics
├ Solid
│ ├ Static
│ ├ Kinematic
│ └ Dynamic
│    ├ Rigid
│    └ Soft
└ Fluid

Fluid for contrast here. Also, to make a point that soft bodies are solid. To be fair, there are also particles and flocks. But we are not talking about that here.

And once we consider the modes Godot has to offer:

                                                  Moves      Force reaction
Physics
├ Solid
│ ├ Static ·················· Static mode           NO           None
│ ├ Kinematic ··············· Kinematic mode        YES          None
│ └ Dynamic
│    ├ Rigid
│    │ ├ With rotation ······ Dynamic mode          YES          Moves and rotates
│    │ └ Without rotation ··· DynamicLocked mode    YES          Moves
│    └ Soft ················· (not a mode)          YES          Deforms
└ Fluid ····················· N/A

---

And then we consider the Nodes:

                                                 StaticBody    RigidBody    CharacterBody    SoftBody
Physics
├ Solid
│ ├ Static ·················· Static mode             x            x
│ ├ Kinematic ··············· Kinematic mode          x            x              x
│ └ Dynamic
│    ├ Rigid
│    │ ├ With rotation  ····· Dynamic mode                         x
│    │ └ Without rotation ··· DynamicLocked mode                   x
│    └ Soft ················· (not a mode)                                                       x
└ Fluid ····················· N/A

I'm not including VehicleBody because they are RigidBody. And I'm not including PhysicalBone because they are specifically to be part of a skeleton.

---

Should we reconsider the names?

• StaticBody: YES. They can move.
• RigidBody: YES. They are not limited to rigid simulation.
• CharacterBody: NO. However, when they are only ever kinematic, what is wrong with KinematicBody? Perhaps rename both the node and the mode.
• SoftBody: NO.
• Static mode: NO. Although it conflicts with StaticBody, StaticBody needs renaming so, rename StaticBody instead.
• Kinematic mode: NO. Although, if we want KinematicBody back, then sure, rename the mode.
• Dynamic mode: NO.
• DynamicLocked mode: YES. Locked does not convey "not rotating".

---

Heads up: I have broken what I what want to say in multiple incoming post, to allow votes on individual parts.

[theraot]

So, what is a good name for StaticBody? Well, it is a solid, that is not dynamic.

PassiveBody, and FixedBody come to mind, but they allow interpreting them as "not moving". I'd say UnyieldingBody, but there is something called yield in Godot.

Renaming StaticBody to KinematicBody would make sense (after all, it only has static and kinematic mode, and you can make something that does not move with kinematic mode), but it is begging for confusion.

I still think FirmBody makes sense. But didn't get a good response, did it?

Perhaps StageBody, even thought it has detractors.

If I were to pick, I'd say: StructuralBody, suggested by AttackButton. It got downvotes, however, I think the downvotes there are for "ComponentBody", if I saw "ComponentBody" I would have no clue what is it for.

[theraot]

I wonder if static mode is simply an optimization for something that does not move. If we recognize that static mode is just an optimization, then merging CharacterBody and StaticBody into a new KinematicBody makes sense. It would have two modes available, and that's it.

In #2184 KinematicBody was split. One part was given to StaticBody and the other to Characterbody. Of course, the original KinematicBody never did what StaticBody did. And now StaticBody has an identity crisis!

By the way, when I say marge them, I don't mean to revert #2184. Because I would suggest deleting StaticBody.

But let us find another route… Split StaticBody. We would have:

• A true StaticBody (StructuralBody?) not intended to move, as we had before.
• A new "KinematicBody" which is for moving platforms and stuff like that.
• And, of course, CharacterBody intended for character controllers.

Currently, nobody would guess they need StaticBody for something like a moving platform. However, with a new "KinematicBody" people would be able to find and recognize it for such use cases.

However, perhaps not call it KinematicBody because it can cause confusion. Call it MotorBody, LocomotiveBody or something like that. I did consider MotionBody, but virtually all of them have motion. And I did considier AnimatedBody, but animations could move any of them.

[theraot]

So, what is a good name for RigidBody?

Perhaps RigidBody can keep its name. People have familiarity with it. And it is not causing a conflict.

I did consider SolidBody. The issue I have with it is that SoftBody is solid. Although, that is not the only acception of "solid".

Yet, given that they are not limited to rigid simulation (they can be static and kinematic), I'll propose something else anyway: MechanicalBody. It also goes well with StructuralBody.

[theraot]

So, what is a good name of DynamicLocked mode?

My first idea is DynamicUpright mode. And all the other ideas that come to mind can be misconstrued or are hard to understand. Is this name OK? Anybody has other ideas?

[theraot]

Other remarks:

• If StaticBody is keeping its name. Perhaps renaming the modes to be "motion" as I suggested before would help. So it would NoMotion mode instead of Static mode, and that way you avoid the conflict with StaticBody. I also suggested ScriptedMotion mode for Kinematic mode.
• What is a character and what is not a character in a game. For instance, are Tetris pieces characters? What if I give them a texture with googly eyes? Is completing a row killing them? If what puts CharacterBody apart is that they are intended to be controlled, then consider calling them ControllerBody. The issue is that some times we control RigidBody because we want to allow the player to be pushed around by the physics simulation. This is the issue with use case based naming. Let us have functionality based naming.
• Ah, by the way. They are all kind of InteractiveBody, aren't them? You interact with StaticBody by colliding with them. But RigidBody is trully interactive because it can also push other things. But actually CharacterBody is the real interactive because we control it… Yeah, sorry InteractiveBody not a great name.

[theraot]

Which solution requires less effort:

Just rename StaticBody (it is the only one in direct conflict with a mode, and the main identity crisis), pick some suggestion, perhaps make a poll. And don't rename or rework anything else.

[charlesmlamb]

Last, well some thoughts . . I don't mind ' CharacterBody ' as such, for KinematicBody, but it leads to a problem . . A ' character ' is typically a person, or intelligent being, and it's often the main character, or important character . . But, I also use KinematicBody to make for instance, the ' enemies ', that are more like ' creatures ', than ' characters ' . . .

Here's a ' critter ' I made, some time ago, just an example . . Now, this is an animal, and I'd use a KinematicBody to set up collision, etc . . . But, it's not well a ' character ', like say Tomb Raider Lara Croft, or Uncharted N. Drake . .

Like, it has no ' lines ', or acting, it doesn't have a ' personality ' . . It's just an ' animal ', that works as an enemy . . And, I don't think I'd call that a ' character ', more like, a ' critter ', animal . . So, in a weird way, we'd need a ' CritterBody ', to sort of, make up for it . . . Like, suppose I have some big bugs or, bees flying around, are they ' characters ' or, well ' Insects ' <3 And, would you call a be, in a video - game, with no lines, or acting, or ' big ' AI, a ' character ' . . I'd call it an insect, not sure . . .

That's where I feel ' CharacterBody ' is sort of weird, but sometimes I also have a skeletal warrior, it's just an enemy, and it doesn't speak . . And, it can't in fact speak, or ' act ', do theater . . Yet, it still use the KinematicBody, for setting up ' collision ', so on . . Like, don't walk through walls, don't clip with player, so on . . . Like, there are grey areas, where one'd use a KinematicBody to set up an enemy, but it wouldn't be a ' character ' or, actor . . . :OO . . .

Tbh, I think there's a really good brain-storming, my idea was, we really do ' big ' brain-storming, and then decide, is there a better alternative, so on . .

On one point, I think renaming these nodes, makes a TON of sense, I've struggled with them, and I'm still not sure, if I have the right ideas . . But, at least not rename them, until there's some BETTER names . . . And, I think the real discussion should be, should these nodes be divided up, from 4 nodes ( Static, Kinematic, Rigid or, Soft ), to different categories, maybe 5 - 6 nodes, that have more specific use - cases, and it makes SENSE, to call one of them PlayerBody or, PlayerObject . . :OO . . .

Every concern I had prior has, been mentioned now . . . The nodes would benefit from renaming, imo, but finding something that's BETTER, than what there is, is quite tough . . .

Sigh, renaming them would really help, but how does one improve the one's that are there and, not just end up with some new one's, that don't really fit every use case either . . .

For instance, a StaticBody doesn't collide actively with other objects, when it moves . . So, it's a staticbody, 'officially', that never moves ANYTHING, when it collides stuff . . You can collide with it but, it can't collide with you, if I understand it correctly . . .

But, if I animate it, move it up, and down, and place a character, with RayCast gravity, that detects the static surface, then I can make an elevator, by sort of, going around it's limitations . . . So, one can often, with a bit of code, or well 'trickery' create functionality, that wasn't there . . . Same way one can quickly, add a RayCast to a KinematicBody, and have simple gravity . . . That's where one can't really say, the nodes have ONE function, bec. it's often easier to animate a staticbody, and use RayCast gravity, to make an elevator, than set up the physics . . .

So, I hope these nodes can be renamed, it's just really difficult, to do it well, without just making some new situations, where for instance a ' CharacterBody ' be used, for say, elevators, cars even, etc . . . And, having physics-related names also makes it more ' neutral ', in a way . . So, those are all my thought, hope you can rename them, it's not EASY, that's all, good luck . . . <3 . . . Also, thanks for opening this discussion, it's been on my mind, for well long time, in fact since starting using the engine, Thanks . . . :OO <3 . . . Also, even if we don't find answer, THIS time, at least now contributors have some ideas, and brain-storming, for finding better names, in the future <3 Thanks . . .

[nezvers]

The naming convention needs to take into account that Godot is not the only game engine around. There are plenty of new developers from Unity where already Rigidbody exists and Defold has a Static, Dynamic, Kinematic, and a Trigger object.

I liked the suggestions for StaticBody as ColliderBody. A very descriptive name of its nature.

[golddotasksquestions]

@nezvers

This argument sounds valid at first glance, however if you continue this thought, nothing would ever change for the better unless the industry leader makes a change.

Godot is the underdog. It is still small and nimble. And right now during the transition to 4.0, Godot is in the unique position to make a transformative change for the better.

For existing Godot users the physics nodes are going to change either way. We should use this unique opportunity to make the physics system more intuitive, simpler and more clear, instead of just as confusing as other engines and physics systems by copying them.

I'd much rather have Unity and other devs come to Godot and be like "Oh man, why is this different? Oh ... this actually makes a lot more sense", than just repeating the same convoluted mistakes others did, just so they can feel at home in a convoluted mess. The Node system is a good example for this. Most people from other engines coming to Godot are confused at first why this is different, but everyone loves it after adjusting to it.

You also have to take into account that this accumulation of hereditary mess is one of the biggest reasons people who use Unity and other game engines are looking for alternatives. And they are looking at Godot, because it is small and nimble and does things with a fresh perspective instead of just copying others.

[eon-s]

About some terms mentioned before.

I'm used to the term "static body" because is consistent with the implementation in other engines like Box2D, on other (component based) engines it also implies that is static for lights and other things which can confuse some users, so even if I don't like the options like obstacle (because it can be a prop or floor), it may be good to change. One term for this could be StationaryBody or FixedBody.

About mentions of Actor and Character, Actor can be problematic because it has a particular meaning in a very popular game engine and it will be really confusing in the context of Godot.

[theraot]

Reminder: StaticBody - in Godot 4.0 - has both a static mode and a kinematic mode, it can move. See also https://github.com/godotengine/godot/pull/48908

[LillyByte]

Seriously, can we all just not with the renames of physics nodes? This makes zero sense to do; as you'll pretty much be setting a whole field of confusion for both old and new users and going against what's, basically, a casually agreed upon understanding of what Rigid, Kinematic, and Static bodies are. There's, literally, an understanding in game dev going back for ages what these body types are; covered by tutorials and books, and not just for Godot tutorials/books. You're just adding levels of difficulty while in some misguided quest to do what... step away from common understanding of physics bodies?

There's no static argument for this, even the most rigid arguments for this fall away. And you're just trying to kinematically force something that doesn't make sense.

[theraot]

While I agree on keeping nodes with the well-established names. The nodes Godot 4.0 do not behave as you would expect.

To reiterate, in Godot 4.0 StaticBody has a kinematic mode. Perhaps I'm stuck on that point, because I keep bringing it up (at https://github.com/godotengine/godot-proposals/issues/2867#issuecomment-861880058, at https://github.com/godotengine/godot-proposals/issues/2867#issuecomment-861880237 and at https://github.com/godotengine/godot-proposals/issues/2867#issuecomment-862642126).

@LillyByte This is why simply not renaming is not enough.

Don't take me wrong. Godot can keep the name StaticBody.

The fact that StaticBody in Godot 4.0 has a kinematic mode does not mean there can't be a StaticBody in Godot 4.0. It means that the name and the behavior don't match. To keep the name, it would be better to change the behavior (back).

To be more precise: Renaming what Godot 4.0 currently calls StaticBody to something that better describe what it is would be a solution※. However, removing the kinematic mode from what Godot 4.0 currently calls StaticBody is also an avenue.

※: It would have to a name that cannot be interpreted as "not moving", because it can move, it is intended to move. For example OP's ObstacleBody. I tried suggesting some other possible names.

---

We, of course, should first consider why the kinematic mode was added to what Godot 4.0 currently calls StaticBody. The context is #2184 and godotengine/godot#48908 - The argument is that this node would be used for static or moving platforms. For the explanation of why StaticBody was chosen for moving platforms see https://github.com/godotengine/godot-proposals/issues/2184#issuecomment-767071094.

Existing tutorials for other engines would correctly lead people to KinematicBody for moving platform. Because - spoilers - moving platforms move. By the way, the name KinematicBody is available in Godot 4.0, because the old KinematicBody was renamed CharacterBody for Godot 4.0.

One solution is to remove the kinematic mode from StaticBody, and rename CharacterBody to KinematicBody. Which is probably the less disruptive behavior change (from what Godot 4.0 has). The only reason I'm not advocating this, is because it defies #2184 - which had good reception.

Another solution is to rename what Godot 4.0 currently calls StaticBody to KinematicBody. But that would leave Godot without a StaticBody. Which is why I suggest (at https://github.com/godotengine/godot-proposals/issues/2867#issuecomment-861880336 - with different wording) the following:

• Add a true StaticBody, which would be intended to not move.
• Rename what Godot 4.0 currently calls StaticBody to KinematicBody.
• Keep CharacterBody, which is intended for character controllers.

RigidBody, SoftBody, and so on, would remain the same.

I understand that me saying that StaticBody in Godot 4.0 is actually a KinematicBody is odd. After all, StaticBody in Godot 3.x (which is what most Godot users are familiar with) is decidedly not a KinematicBody, which is why I keep reiterating that I'm talking about what Godot 4.0 currently calls StaticBody. So, where I'm coming from? From here: godotengine/godot#48908 - Reminder: PhysicsBody is the base class. So when it says that KinematicBody was split between PhysicBody and CharacterBody, it means StaticBody also got the additions to PhysicBody. That combined with the kinematic mode added to StaticBody means that what Godot 4.0 currently calls StaticBody is pretty much a KinematicBody.

---

The other issue OP brings up is the collision between the names of the modes and the nodes, I also made a suggestion (at https://github.com/godotengine/godot-proposals/issues/2867#issuecomment-861749205 and referenced at https://github.com/godotengine/godot-proposals/issues/2867#issuecomment-861880727):

• Static mode -> NoMotion mode (so you can keep StaticBody)
• Kinematic mode -> ScriptedMotion mode (you can bring back KienamticBody)
• Dynamic mode -> DynamicMotion mode (Dynamic has no conflict, I'm just giving a naming pattern)
• DynamicLocked mode -> DynamicUprightMotion mode (Locked what? this is more descriptive)

Added the word "mode" here in case people thought I was suggesting NoMotionBody or something like that. I'm not.

---

@pouleyKetchoupp

Is this good? Are this changes viable, or is only renaming nodes on the table?

[mrtripie]

I think trying to describe the actual use case may not be a good way to go about these names. For example, Obstacle Body doesn't work great for Static Body as I can easily think of Rigid Body obstacles, and Static Bodies that I'd hardly call an Obstacle.

Solid Body won't work for Rigid Body either, because it doesn't really change the meaning that much, and I could also see it as the name for Static Body: Something big, heavy, and solid that your character can't budge by pushing it around.

Here would be my suggestions: Static Body -> Basic Body or Simple Body, as it would be the most basic one, and I would choose it when I just want a basic body for collision that does nothing special. Rigid Body -> Physics Body or Physical Body, as this one reacts to physics forces, unlike the others. (The base class, Physics Body, would then be renamed to just Body). Alternatively, just go with consistently with other engines (including previous Godot versions), and keep Rigid Body.

I agree that part of the confusion is likely due to the different modes on Static Body and Rigid Body making them act like each other, so maybe these should be restructured.

[charlesmlamb]

I have to admit, I like the old, physics-based names before, bec. they were neutral, and in a sense CharacterBody makes it 'worse', in Godot 4, bec. it's even MORE specific, and will mean, if I add a skeleton warrior, that's not a ' character ', well sort of, a walking zombie . . That it won't be a character, or a NPC, that mostly talk, same thing for say insects, animals, or bridges, with KinematicBodies . . .

The ' good ' thing about KinematicBody is, it doesn't say it CAN'T be used, for a character, though it is a bit weird, or so . .

In terms of finding better names, it's very complex, bec. the better names, that capture SOME aspect of the nodes, end up forgetting much more or, just being slightly well, worse . .

I'd sort of, like if they kept the old names, but I'll get used to the new names, one can sort of 'understand' how, KinematicBody might be a good ' start ', for a character, as well . . it has the properties one needs, collision, move_and_slide(), so it makes sense to ALSO use it for characters, though it's name is based on the semi-rigid body properties, it has . . . like, it's between a staticbody and, a rigidbody, with many physics settings <3 . . .

So, I think the current names make MORE sense, or are more fitting, still, it's just ' weird ', or so . . . sort of, hope you nail it, for Godot 4, or at least have some really good alternatives . . In a sense, one can also just 'rename' a node, so after making a ' KinematicBody ', one can rename the node, to skeleton_warrior, so on . . The problem is really only, in terms of the list, esp. for beginners . . They might have to invent a new word, PartialRigidBody, ControllerBody or, 50%RigidBody :(( . . <3

I think it'd be better, if they made them into nodes, where one was most accurately, a CharacterBody . . It had the SPECIFIC settings, for that use-case, was best for that, alone . . . Then, keep KinematicBody, so or call it DynamicBody . .

Well, been hoping someone would make this better, it's like, 'impossible' . . . :OO . . .

[JamesC01]

Seriously, can we all just not with the renames of physics nodes? This makes zero sense to do; as you'll pretty much be setting a whole field of confusion for both old and new users and going against what's, basically, a casually agreed upon understanding of what Rigid, Kinematic, and Static bodies are. There's, literally, an understanding in game dev going back for ages what these body types are; covered by tutorials and books, and not just for Godot tutorials/books. You're just adding levels of difficulty while in some misguided quest to do what... step away from common understanding of physics bodies?

There's no static argument for this, even the most rigid arguments for this fall away. And you're just trying to kinematically force something that doesn't make sense.

I completely agree. This is a horrible idea. Rigidbody, StaticBody are fine, and used on plenty of engines, and when I first heard of a rigidbody, it took like 5 seconds to understand what it was. People renaming all of these things are just going to confuse people coming from new engines, and beginners who have looked at some tutorials for multiple engines. They're going to wonder why godot has such different names. Most beginners aren't going to just download an engine and be able to do anything anyway, most would need a tutorial, and that tutorial could easily explain what a rigidbody is. I do agree that there should be a CharacterBody node, though, similar to Unity's character controller component.

[JamesC01]

If I'm being honest, most of the suggestions I've seen just don't sound good. I think all of the names, StaticBody, RigidBody, CharacterBody, VehicleBody, SoftBody all sound good, and line up with most other game engines. Maybe StaticBody shouldn't have a kinematic mode, but other than that, I'd say they're all good. This is coming from someone fairly new to game development. People seem to be trying so hard to change the names to make it easier for beginners, but it will probably only make it harder.

Explaining a RigidBody takes a few seconds, same with StaticBody. CharacterBody is great, and sounds similar to unity's character controller component, which provides very similar behaviour. These names aren't really hard to understand for beginners, especially if they're explained well in the docs, and they're very familiar for people coming from other engines. Calling CharacterBody "ActorBody" isn't good. The only other popular engine I can think of that uses "Actor", is unreal engine. It's Actor class describes a generic game object, similar to a Node3D, or unity GameObject, I believe. I just think renaming these things is a bad idea. Especially for beginners, who may have checked tutorials for other engines, and also for people coming from other engines. I don't see the point of deviating from the standard names, just to save 5 seconds of explanation for a complete beginner, and possibly provide even more confusion for people switching engines.

Maybe the modes should be changed a bit, but not the Node names, in my opinion. I feel like you're just focusing on the wrong thing. These things probably don't matter to a beginner. Everything is confusing for a beginner. "Rigidbody" not being a perfect description is the least of their worries. Most beginners don't just open up an engine and know to look for a physics body. They'd have to be told that, most of the time. I just feel like this is a tiny thing that will just end up making to engine look different, rather than help.

[pouleyKetchoupp]

Thanks all for the feedback and suggestions! Let me try and summarize what I get from the discussion:

• RigidBody will keep the same name, as a majority is more familiar with this term, and it's fairly easy for complete beginners to learn what it means.

• If anything should change, it would be StaticBody renamed to ColliderBody (based on https://github.com/godotengine/godot-proposals/issues/2867#issuecomment-861723295) which seems to be the closest to a consensus and addresses the confusion around StaticBody being used for moving platforms. It would still use a well-established term.

• Other physics nodes can stay the same because their use case is clear and there's no name confusion.

@theraot About your suggestion to rename the modes instead of physics nodes (https://github.com/godotengine/godot-proposals/issues/2867#issuecomment-861749205): I'm afraid that would add to the confusion, and the mode names are probably fine since they are only used in the physics server or when switching modes for RigidBody. It's an advanced use case for which I would expect users to have done some research and know what they are doing. Although, I agree DynamicLocked mode could be changed to something clearer. Maybe DynamicLinear mode would be a better name for dynamic bodies with no rotation.

[JamesC01]

Thanks all for the feedback and suggestions! Let me try and summarize what I get from the discussion:

• RigidBody will keep the same name, as a majority is more familiar with this term, and it's fairly easy for complete beginners to learn what it means.
• If anything should change, it would be StaticBody renamed to ColliderBody (based on #2867 (comment)) which seems to be the closest to a consensus and addresses the confusion around StaticBody being used for moving platforms. It would still use a well-established term.
• Other physics nodes can stay the same because their use case is clear and there's no name confusion.

@theraot About your suggestion to rename the modes instead of physics nodes (#2867 (comment)): I'm afraid that would add to the confusion, and the mode names are probably fine since they are only used in the physics server or when switching modes for RigidBody. It's an advanced use case for which I would expect users to have done some research and know what they are doing. Although, I agree DynamicLocked mode could be changed to something clearer. Maybe DynamicLinear mode would be a better name for dynamic bodies with no rotation.

I'm quite happy with this so far! I don't mind ColliderBody, but I feel like there could be confusion with collisionshapes. But it's probably the best replacement for staticbody I've heard so far. I agree with pretty much all the points in your comment!

[charlesmlamb]

@pouleyKetchoupp you know, I really like the physics based name, ie. KinematicBody, RigidBody, also now DynamicLinear . . bec., one can then use them, for character, but also many other stuff . . .

But, if one makes a characterbody, using it for say a platform, becomes more tough . .

That's the advantage of the physics stuff . . It can be used for anything, and if one is a bit flexible, also characters . .

It's like physics based names can also be used for characters, but it's not so easy the other way, ie. a characterbody would never be considered for, a moving platform . . Hope you find some better names, we really need them, also amazing to read so many comments, and insights, wow . . Hope you find a good solution, at least there's food for thought, hope you find a solution, looks complicated . . :OO . .

[theraot]

@charlesmlamb,

In Godot 4.0, you would use ColliderBody for the platform (in static or kinematic mode depending if it is a moving platform or not).

On the other hand, CharacterBody is intended for things you control, like - you know - your character.

In fact, you probably can and will use ColliderBody in kinematic mode for most enemies. And I say "most" because there could be situations where CharacterBody is necessary for enemies.

---

ColliderBody is future name for what Godot 4.0 currently calls StaticBody. Being renamed because - unlike StaticBody in Godot 3.x - it is not really static. It has a kinematic mode, in which it is intended to move. If it will have both static and kinematic modes in a single node, then StaticBody is not a good name.

The nodes in Godot 4.0 would be: ColliderBody, CharacterBody. RigidBody, SoftBody, VehicleBody and PhysicalBone.

To reiterate, the ColliderBody isn't exactly an old school StaticBody, because it can move. If nobody thinks of using CharacterBody for moving platforms, that is good. They should be looking for ColliderBody.

I also like the physics based names. However, I think this approach is good too.

---

Notice there will be no StaticBody and no KinematicBody. People coming from old tutorials or from other engines would not find them. Which means there would be some friction in migration. I think that should be addressed in documentation.

Godot will be different. We'll get use it to it. And that's fine. As golddotasksquestions was saying: Godot is in the unique position to make a transformative change for the better.

Keep bringing ideas, and keep pointing potential problems. There is still room to improve.