search

godotengine / godot

Godot Engine – Multi-platform 2D and 3D game engine
https://godotengine.org
MIT License
88.66k stars 20.11k forks source link

Proposal for renaming nodes for Godot 4.0 #30736

Closed reduz closed 4 years ago

reduz commented 5 years ago

Breaking compatibility

I know I promised to break as minimum as possible to compatibility for Godot 4.0, but I' ve been thinking this over for a while and based on feedback, and I think it's worth it. It should not break compatibility with existing scenes (we can add internal renames), but it will with code...

So maybe what we could do is a tool in Godot 4.0 that basically converts a script from 3.0 to 4.0 doing symbol renaming or just re-tokening.. this way no manual work has to be done by the user (so no huge amounts of pain like when we moved from 2.0 to 3.0).

For reusing existing tutorials (that I think won't really be affeced much anyway), we can put up an doc article showing what was renamed.

What I would change

Despite that many say that Godot was originally a 2D engine, that is false. Originally, it was a 3D engine and the only things supported as 2d where the canvas (UI) nodes. The 2D nodes came later.

So, this makes it quite confusing that for 3D nodes, the "Spatial" term is used and for 2D nodes, there is "Node2D".

For users starting to use Godot (and even for advanced users), this is pretty confusing in general (only aided by the node colors, but if you make a mistake in code, it can be confusing to realize you are using the right version 3D instead of 2D)).

My proposal is to simply make explicit, in case nodes exist both as 2D and 3D form, that they should be named the same, but add a 3D or 2D at the end (save for some exceptions).

So, typical renames would be:

and so on.

For some, I think we could keep the current way, because the use case is mainly for 2D or 3D, and the opposite version, such as:

But then again, feel free to suggest if you would prefer something more explicit and make everything 2D/3D always.

Namespaces

I'm not that too keen on namespaces within Godot for a few reasons

But nothing should avoid us from defining them using the ClassDB API, so languages that are heavily namespace based, and where users are very used to it (like C#) can make use of them.

As an example:

Below a GDCLASS("Node2D") definition, an optional GDNAMESPACE("Nodes2D")

It will also make browsing help and documentation probably easier too.

Other things I would like to change

SpatialMaterial is confusing as hell to new users (and existing too). I think we should rename to StandardMaterial3D. I would probably also want to make two different versions, one similar to the existing one, and another that instead uses ORM style textures (setting them up in Godot right now is a huge hassle using Spatial Material and assigning channels manually). This way we could have something like:

+ Material3D
- + StandardMaterial3D
- + ORMMaterial3D

or similar..

The 3D scene import process is still quite a hassle because you can't set options to individual meshes and materials while importing them, so I want to add an option in the import dock to have import windows with settings for some types of resources (in this case for imported scenes).

The 3D scene import would show you a tree with all the data and then you can choose a lot of nice stuff in there for every node/material such as:

Feedback welcome!

jahd2602 commented 5 years ago

I use Godot professionally for more than a year.

I agree with everything you said, except for:

For some, I think we should keep the current way

If we have this golden opportunity, let's just rename everything. That includes Sprite2D and MeshInstance3D.

It's always better a full painful refactor, that many partial painful refactors.

Zylann commented 5 years ago

Speaking of renaming: https://github.com/godotengine/godot/issues/16863

reduz commented 5 years ago

@jahd2602 I don't mind either way personally, we can poll that in the worst case.

I definitely can see people bothered with that simply for the fact that it's an inconsistency, but we can at least see if they are majority or minority.

reduz commented 5 years ago

@Zylann I know, if we decide something here, we'll move this over there.

AlexDarigan commented 5 years ago

I think the stance against namespaces is short-sighted. It makes sense from perspective of the engine workflow in general but it ignores the perspective from toolmakers. Godot Unit Testing (GUT) by bitwes for example broke due to a naming conflict in one of its updates. There is a likelihood this could have been avoided with a dedicated GUT namespace.

I would also like namespaces for Waiting And Testing (WAT) so I can I can use class names like Test (accessed via WAT.Test) while not running over other frameworks (like GUT if it were to use GUT.Test) or just the user's script. I've tried a number of times using a WAT class that contained all of the scripts used as subclasses but that's just a cyclic reference hell.

If we are to be encouraged to build tools from within the engine, then we need the tools to make those tools in the Engine even if they aren't absolutely necessary for the engine workflow itself.

In summary, a dedicated namespace system which can be both accessed as well as defined from the engine (or at the very least the plugin script) so tool makers don't end up walking over each other or their uses would be a godsend.

reduz commented 5 years ago

@CodeDarigan I understand it has benefits and I'm not denying them, but I sincerely believe that the costs outweighs them.

Add to this that pretty much we had no significant complains from GDScript users, who prefer the current approach, so it would force them to an unwanted worfklow and type more code in a language that is intended to just write quick and dirty stuff fast. (C# users seems to do want them, though).

This is why I mean that they can exist as metadata for script language bindings, and we could even add them for GDNative C++. Just not add them for core C++ engine.

nitodico commented 5 years ago

Navigation -> Nagivagion3D Is this a typo?

reduz commented 5 years ago

@nitodico indeed

Duroxxigar commented 5 years ago

@reduz I agree with @jahd2602. Even if some things may be obvious, for consistency sake, we should postfix with either 2D or 3D.

swetland commented 5 years ago

I'm still getting started with Godot and the proposed changes sound sensible to me -- using subtly different names for the 2D or 3D variant of a node is something that's caused me a bit of confusion while learning which end is up and moving to Thing2D/Thing3D or Thing/Thing3D feels like a significant improvement to clarity and comprehensibility.

ripperdave commented 5 years ago

Please do it.

StyrmirNathrakh commented 5 years ago

Tbh this change would come anyway, so better to do it now and stick with it. For 3d there are not that many tuts so now the change will do less damage than in one, two years later.

Janders1800 commented 5 years ago

Regarding materials it would be nice to have some kind of Legacy Material that only uses minimum resources, like diffuse and specular, this would be useful for 3D mobile games.

MuffinManKen commented 5 years ago

I'm also in favour of renaming things to be explicitly 3D or 2D.

Wouldn't it be possible to have the original names still exist as aliases to the new ones? They would be hidden from the editor so the old names wouldn't be usable (or placed under a "deprecated" heading). That way old code would still work, without changes and without needing additional logic to convert anything.

A warning could be added for code using the deprecated node names and then in 4.1 or 4.2 they could be removed.

pkowal1982 commented 5 years ago

If there are two versions of a node I would always append 2D/3D suffix.

MuffinManKen commented 5 years ago

Also, I would be happy if Label -> TextLabel. I go to add a node so I can show some text, so I type text in the search bar and of course only RichTextLabel shows up which reminds me that the standard text node doesn't actually have Text in the name.

reduz commented 5 years ago

@Janders1800 that's how it works now, the less features you use in SpatialMaterial, the smaller the shader it creates.

nobuyukinyuu commented 5 years ago

I'm a 2d person, so for nodes with mainly 2d application, keeping the node names without a suffix if it doesn't already have one seems fine to me. This seems like a more painful refactor for 3D users, but it does make a lot of sense where certain nodes have only a 2d or 3D application for the most part that they retain the shorter name for their intended domain and have a suffix elsewhere. Anything else that can be unified would be nice to see unified, specifically Spatial.

RandomShaper commented 5 years ago

I'm in favor of unconditionally using 2D/3D suffixes, too.

While it's true that for some nodes it seems like a lost opportunity to have more "natural" names, consistency wins.

What I don't quite like is that the StandardMaterial3D is the non-ORM one. My point is that ORM is more strongly backed by a standard (at least RM, which is what you have in glTF).

But I can't yet suggest a better naming.

Maybe this is also an opportunity to do something about 'canvas'. I found that concept a bit confusing at times.

I know it's difficult, because is has no 3D counterpart: 3D scenes live in Spatial nodes, but canvases can contain a mix of Node2Ds and Controls.

However, it would be great if we could define some naming that allowed renaming CanvasItemMaterial to Material2D, while keeping it meaningful for the "pure" 2D and the GUI realms.

m4nu3lf commented 5 years ago

I'm not necessarily against the rename, but the original names make sense to me, maybe because of my background. The default in physics or engineering is "3D". You don't say a "3D kinematic body", you say a "kinematic body", unless you're working in some other space. However, I'm sure not everyone has the same background or even agrees on that, as this after all is game engine and doesn't have to strictly follow physics or engineering conventions.

RKiemGames commented 5 years ago

for future compatiblility, in gdscript

a gdscript file...

extends Spatial class_name Node3D

And so on.

BeayemX commented 5 years ago

Have you thought about renaming translation for spatial nodes to position?

eon-s commented 5 years ago

@BeayemX I think that translation is a common term for 3D space, and position is common for 2D developers :thinking:

I do not know if 4.0 will be the best for node name changes, there will be a lot of things to deal with and there were many changes from 2 to 3, it means deprecating books, videos, courses. Even documentation is not complete, with changes in mid completion, fixes will slow things down a lot...

neikeq commented 5 years ago

I'm in favour of renaming 3D nodes as suggested here. I don't know how much of a problem it will be for tutorial makers though. At the very least, it should be trivial to refactor existing code bases. In C# we could even abuse the ObsoleteAttribute in debug mode to make it easier (not sure if a good idea though): [Obsolete("Use Node3D", error: true)] class Spatial { /* Nothing here */ }

I hope we add namespaces/categories as discussed in #18711. I want to separate the C# API into namespaces and perhaps assemblies as well to make it possible for users to pick only what they need. My plan for 4.0 was to hard-code a table of namespaces myself if there was no other choice, but I would prefer if instead I could get this information from ClassDB.

Zylann commented 5 years ago

@eon-s I don't think it is... while translation is technically valid to represent coordinates, Godot is the first engine where I see a different term being used here, otherwise I've always seen position regardless of 2D or 3D. Also to me translation is associated with movement, and conflicts with another term related to language/transformation, which makes it odd. This was mentionned in https://github.com/godotengine/godot/issues/16863 too.

neikeq commented 5 years ago

BTW, why are we planning to break as little as possible? I understand why people don't want more compatibility breakages, specially those making tutorials; but if we won't take 4.0 as an opportunity to break compatibility, when are we going to? #16863 is already accumulating a lot of suggestions.

eon-s commented 5 years ago

@neikeq can't wait for 5.0? since no new or big features are planned, otherwise people will stop making things and buying courses for an engine that changes important parts every 1 or 2 years (for video tutorial makers this mean redo all their work) and with a few months of warning time...

martin-jw commented 5 years ago

I'm in favor of renaming to have a consistent 2D/3D suffix, and I agree with many in this thread that it should be done for all nodes for consistency. Having a consistent naming convention is extremely helpful for someone learning the engine, or someone moving from the 2D side of things to 3D, or vice versa.

@eon-s Surely waiting until 5.0 just means there will be an even larger body of work that needs updating?

swetland commented 5 years ago

As much as tutorials are wonderful to have, I'd vote for making the engine more comprehensible over keeping it confusing for the sake of existing tutorials. Hopefully fixit scripts or optional aliases (as discussed variously above) could be used to smooth the upgrade path.

dpalacio commented 5 years ago

I appreciate the difference in naming between Node and Spatial because Node nodes have no knowledge of space, having Node, Node2D and Node3D would BE confusing. Unless you plan to get rid of Node, then it'd make completely sense.

I'm for having only one realm 2D or 3D having to bear with having a suffix. It's 2D at the moment and the confusion between 2D and 3D ends there.

Please don't add the 3D suffix. Is it really worth the headache for what it adds? Is it worth the cost? of updating everything or having outdated tutorials? Unmodifiable and outdated youtube tutorials? It will bring more confusion.

abraaofilho10 commented 5 years ago

@dpalacio I'm using Godot for only a few months but I think it is more clear and concise to use Node3D, Node2D, and Node because of the Spatial acts as a Node3D and the Node has no space information. I think adding suffix for 3D will be much more simple to understand as it will be named "oppositely". I know it is not really opposites but I don't know how to express it better because English is not my native language. Put 3d versus 2d explicitly looks great to me. I think it will be very easier for beginners, and still more for the people that are having the first contact with a game engine. The namespaces are great too, mainly for big projects and plugins. Conflicting names are a headache. As a beginner, I think the compatibility breakage needs to be minimal and automatic because it is hard to keep changing projects between versions. If we have many changes we'll need to have an automatic conversion tool and documentation for it too.

reduz commented 5 years ago

@neikeq yeah, category should be replaced by namespace and we should make proper ones.

noobaldrin commented 5 years ago

Exactly what I was thinking when I tried Godot. My OCD tells me that it should be this way.

Have you thought about renaming translation for spatial nodes to position?

'position' sounds more like it's an absolute position instead of relative position. Calling it position might help new developers but eventually they will realize it should be called translation.

TwistedTwigleg commented 5 years ago

I'm kinda on the fence with this proposal as someone writing Godot tutorials and using Godot for my own fully featured projects.

I am totally in favor of changing the names of the nodes to stay consistent, and I agree with others that consistency is important, even if it makes things perhaps a tad more wordy. I would much rather have to add 3D or 2D to the end/beginning of nodes if it makes things more consistent in the code base and documentation.

Here are some nodes that I would like to see changed to stay consistent:

Here are my thoughts on this proposal, starting with the positives:

I think this change will make things easier for those who have no Godot experience, but only those who come after these changes are made. Especially on the 3D side, one of the biggest problems I find is that it can be hard to find what nodes you need, and I think renaming the nodes using a consistent naming scheme will make this much easier for everyone.

Many of the times I am helping others with Godot, I find one of the most surefire ways to find a solution is to look in the documentation. However, since the names of nodes are not always consistent, finding the documentation page can be difficult for certain nodes unless you already know the name of the node you are looking for. The changes in this proposal would make finding the correct node much easier.

Another benefit I can see with this change is that it sets a standard on how nodes should be named, which could be helpful for plugin creators and future Godot Engine contributions. For example, if I am making a decal node (for example), then with this change I know I should name it something like Decal3D instead of just Decal. This might also help with the naming of GDScript/C# defined classes.

This would also make tutorial writing in the future a little easier, as no longer you have to explain that Spatial is basically a Node2D in 3D.

Now for the negatives:

One of the biggest issues I have with this proposal is that it seems too soon, especially given how much Godot 3.0+ changed things up not too long ago. I think only a few games using Godot 3.0+ have even come out, and very few 3D Godot games. A lot of the big, impressive 3D games in the Godot showcase are still not released, and making a big change like this means those projects will need updating too, further delaying some really strong 3D Godot games.

Also Godot 3.0+ tutorials are still coming out. Especially on the 3D side, things are starting to somewhat gain traction. While this is in part due to the 3D side of Godot becoming stronger in Godot 3.0+, I fear that a lot of the material tutorial writers are making (or have in the works) will suddenly need massive rewording to account for the name changes. This will take time away from making new tutorials, as old tutorials will have to be dropped, remade, or rewritten.

The naming change would also make existing resources that are not tutorials, just simple solutions found to problems, suddenly outdated. While Godot's 2D side is arguably quite strong and can probably adapt quickly, the community using the 3D side is noticeably smaller. By changing the names of the nodes, I worry this is going to stunt Godot's 3D user growth and the ability to find solutions to 3D related problems.

I agree with @eon-s: can't these changes wait a bit? Things are already changing pretty dramatically, at least in the code base, with Godot 4.0. I think adding another massive change is only going to make development harder and reset a lot of progress people are making with the 3D side of Godot.

Once Godot 4.0 is out, I think working on renaming the nodes in version 4.1 or 5.0 would be excellent, but in my opinion I think adding another big change like this is going to do more harm than help.

One thing that might make this transition better is to have an alias/transition period, perhaps from Godot 4.0 to Godot 4.1 for example. This would not make tutorials and resources (especially 3D ones) obsolete instantly and would give everyone a chance to adapt to the upcoming changes while still being able to benefit from the changes in Godot 4.0.

Using a alias/transition period would allow compatibility breaking changes to be made without suddenly forcing everyone to update all at once. This would also allow compatibility breaking changes to be made more often, as theoretically once a system is in place for transitions it could be used again for future compatibility breaking changes. This would make things easier going forward with changes listed in #16863.

TLDR: I am all for the changes, I think it should just wait until Godot 4.1 or a transition system/period should be made to give everyone time to adjust to the changes.

Regardless of how this proposal ends up: I think Godot 4.0 will be great and I am looking forward to it 🙂

Norrox commented 5 years ago

@reduz i say go for it. And I second @jahd2602

aaronfranke commented 5 years ago

I'm not a big fan of making all 3D nodes end with "3D", but sure, if everyone wants to. I do think that it's fine keeping different names rather than always having a suffix (ex: TileMap and GridMap) EDIT: Complete 180 on this.

I would vastly prefer "position" instead of "translation". The latter can be confused with localization & languages, and the former is immediately clear and beginner-friendly. However, doesn't Godot already use "origin" in most places for this?

I also agree with @neikeq that it's worth it to break compatibility if it's a beneficial change to new projects. I would personally love to see the vast majority of things in #16863 implemented.

(btw why does Sprite3D exist when it could just be a quad mesh?)

reduz commented 5 years ago

@TwistedTwigleg Read my post, 3.0 projects will open fine in 4.0 if an internal compatibility system is added..

kruglinski commented 5 years ago

Nice change, as a programmer I'm happy to see the name for the counterpart as symmetric as possible

fire commented 5 years ago

Can you explain what ORM style textures mean in more detail?

fracteed commented 5 years ago

@reduz is the only difference between the standard spatial material and the ORM one, that you only have one texture channel (rather than 3 as it is currently) with the ORM? Will you still have access to the same parameters (in metallic and roughness) such as specular and the multipliers? Not used often but sometimes used to tweak.

I do like the idea, but wondering if it is overkill to have 2 material types for such a small change. Could there instead be a toggle to switch between 1 texture channel for ORM mode or 3 for the existing style, using a single material?

I have also recently been putting the depth(height) channel into the alpha channel of my ORM maps to get more mileage out the textures. Then you can do most textures using just 3 textures...albedo/normal/ORM(H). This could be worthwhile to add in by default (unless we get a 16bit option for height maps, where you would want to use a separate one). If 4.0 eventually gets tessellation/displacement, the height channel will be much more important than it currently is.

And speaking of which, it would also be a good opportunity to change the naming of the DEPTH channel to HEIGHT in 4.0 and have it use the inverse of what it currently uses (ie white is a raised surface and black is recessed). This would put it in step with other renderers and game engines, and more importantly with tools like Substance, Quixel and Marmoset.

PaulHMason commented 5 years ago

I'd much prefer explicit suffixes for 2D and 3D nodes, and no suffix if it's not applicable. I'd also like the "Control" nodes separated completely for the "Node2D" nodes (they're both currently grouped under "CanvasItem").

RandomShaper commented 5 years ago

About translation versus position, I'd go for the former in both 2D and 3D.

position looks more friendly, but it stops making sense once an ancestor has some rotation or scale.

Regarding compatibility, the transition stage should last for all the 4.x releases to give plenty or time to tutorials, users and projects. The new names should be the first-class citizens and encouraged, but the old ones should work, with some in-editor mechanism to tell people about the change.

aerger commented 5 years ago

I'm absolutely in favor the suggested changes as long as it's done in a way that makes it easy for end users to update existing code--either their own or code from existing tutorials and documentation--via some sort of tool as mentioned. Lacking such a tool, I would tend to agree that we're piling on rather soon after the big shifts in v2 to v3.

Norrox commented 5 years ago

@TwistedTwigleg regarding of the release of 3d games, that's because we're waiting for 4.0 and Vulcan 😎

Beelzenef commented 5 years ago

I would also review Control nodes names... and inline documentation.

Sometimes I wonder what's the difference between AcceptDialog and ConfirmationDialog, and the same with PopupPanel, PopupDialog, PopupMenu... hope this helps!

NathanLovato commented 5 years ago

As a tutor and a docs contributor, I'd say go ahead! I don't mind producing more content if the changes make it easier for everyone to learn and to understand the engine in the future. Better do this kind of change ASAP as well.

akien-mga commented 5 years ago

Coming late to the party, but some clarifications to keep things manageable:

chucklepie commented 5 years ago

Hello, Why not follow practice of other APIs and create an Obsolete/Deprecated decorator for classes (or even methods), i.e. the old names are simply aliases/pointers to the new. This would stop any breaking changes and allow the names to be dropped in version 5 so less people would be affected or even notice.

Using a decorator could also give two other benefits:

  1. The IDE could easily pick up this tag and display it in the node selection window, e.g. instead of simply saying 'Spatial' it could read 'Spatial (obsolete use Node3D)'.

  2. The decorator could then become a built in warning shown in the code editor.

Plus it doesn't stop anyone creating a renaming tool...

akien-mga commented 5 years ago

Some thoughts:

I agree with renaming nodes, as well as a few methods and properties (see current list in #16863) for improved consistency and to make the API easier to learn and use. Making the 2D / 3D distinction clear seems a good idea, and if done it should be done consistently (so e.g. also MeshInstance3D as mentioned). I suggest that we use a spreadsheet to list all current Nodes and what their new names in 4.0 should be - and we can bikeshed there about specific nodes like TileMap/GridMap. I'll create this spreadsheet in coming days if we confirm that this is the way we want to go.

Yet, we should strive to limit compatibility breakage as much as we can. As Juan mentioned, we can have compatibility renames in the engine internals so that old scenes can be loaded and converted, but that's not enough.

As @RandomShaper and @chucklepie mentioned, we should add deprecated aliases for the all the nodes, methods, properties, constants, signals, etc. that we rename, with a property decorator/metadata that would signal them as obsolete and encourage users to change their code. Using this information in the IDE should make it possible for users to follow 3.x tutorials in 4.0 without issue, while learning easily about the new names as they go.

To do so, we need helper methods that can let us define deprecated aliases when registering bindings. #23023 is a first attempt to add such an interface, but it still needs to be reviewed, merged, and maybe expanded if it's not sufficient for what we will need in 4.0. Those deprecated aliases can be kept for the whole 4.x release cycle, and dropped in 5.0. I would oppose any compatibility breaking renaming until we have this interface well designed and merged, so anyone interested in this is welcome to give this PR a try and suggest changes if needed.

As for the when, I insist that if we want to ever break compatibility again, this is now. Waiting for 5.0 doesn't make sense, as it would make even more content obsolete once we reach 5.0, and it would not help depict Godot as a stable development tool if we break compatibility with (hopefully) many great games in development with Godot 4.x.

Godot's userbase more or less doubles each year, so each year that passes makes a refactoring less realistic, as eventually the inertia of a big userbase outweighs the benefits from breaking compatibility. If other engines like Unity or Unreal seem relatively stable in terms of API compared to Godot, it's not because they don't have things that they would like to refactor or rename, but because they cannot afford to. We still can, for now, so we have to use the opportunity. It was the same for Godot 3.0 and the community came out of it relatively unscathed, though we do have a small proportion of users sticking to 2.1 as they can't afford porting to 3.0. For 4.0, the scope of those changes should hopefully be a lot less, and any porting work should be straightforward, but the community has grown manifold in the meantime, so the impact of any compat breakage will be as big or bigger than for 3.0 in terms of image/cumulated user annoyance :)

aabmets commented 5 years ago

I'm a big proponent of breaking compatibility.
Why it's not an issue: if a dev puts out their game on an older version, then keep developing on the older version of the engine, nobody is forcing the dev to migrate to the new version. Also: keep offering older versions for downloading just exactly for this purpose.
New projects can be started in the new version of the engine and then it comes down to whether the developer has the patience to re-learn how to engine works.
When it comes down to improving engine usability, the patience for re-learning should never be an issue, if the goal is to become the most user-friendly or powerful engine around.

As for the renames, it helps to reduce the learning-curve if there are patterns in the material to be learned. For instance, Node2D vs Node3D, etc for all the other nodes. If it looks like a duck, you know how it goes, it most likely is a duck, or a node in this instance.
Human brain works as an optimizing quantum computer, which learns by connecting lowest energy states of systems with each other to create logical paths between ideas. If the ideas to be learned are similar, their lowest energy states are more closer to each other, which makes it easier to connect (and remember) them, which explains why its easier for a student to understand 3D if they have been taught 2D beforehand. If the names of the nodes reflect the similarity between them, it's also easier to learn and understand how a new type should be used if knowledge is present on a similar type.

I say go ahead and refactor and break compatibility any way you wish. Even if you lose few users, you'll gain many more by increased user-friendliness and reduced learning-curve.