Add "Add Advanced Node" button to instance scenes/nodes from a community approved repository

[ca3games]

Describe the project you are working on

2D fighting game.

Describe the problem or limitation you are having in your project

Godot is a great engine, but a lot of times it feels like you're simply starting from scratch every project.

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

Imagine some button next to the Add node, that basically opened the same Add node window, but instead you get a list of "advanced nodes" made by the community. It would be similar to how construct has some premade entities made from the community, like a platformer player or a RTS character.

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

It would be simply to download a single scene, that is configured to work as another basic node, just happens to have a tool interface to edit and control it's inner workings. Basically you would have a button that adds one of these scenes (configured) in a similar window to the add node button, but it checks an online repository to download them. So that way, similar to how some advanced nodes in Substance designer are just a combination of multiple basic nodes, just grouped as a new basic node in designer. This way, it would be simpler than the current use of the asset store, and a huge improvement over Unity asset store (one of the downsides of unity asset store is that it imports an entire new project, filled with unrelated files to your project folder). Godot developers could have a community approved list of quality "nodes" that would appear on this "Add new online button node", and only high quality nodes would then be approved.

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

Sure, It doesn't require new advanced tech Godot doesn't have, It's just a timesaver to make Godot into a really much better tool.

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

It's a core engine issue.

[YuriSizov]

That's what the Asset Library is for (also accessible from the editor itself). You find the nodes or other assets you need, install it and then use it just as you would use your own code and scenes.

[Calinou]

The editor asset library integration intends to remain similar to what it is now. Exposing community-developed stuff in something as essential as the Add Node dialog could be misleading as to what is officially supported and what isn't.

[ca3games]

@pycbouh It would be simply an improvement over the current asset store. Instead of opening the entire asset and browsing it, it would arranged and organized just as the add node window.

The asset store could be used for other purposes.

@Calinou It's an idea I have of some advanced nodes the comunity could support to easily make much easier godot development speed. Besides these nodes could be as simple as made for more niche cases that godot nodes. Like "2D platformer player Rigidbody", "RTS kinematic body enemy" "Some AI behaviour node"

[ca3games]

The editor asset library integration intends to remain similar to what it is now. Exposing community-developed stuff in something as essential as the Add Node dialog could be misleading as to what is officially supported and what isn't.

They could still be an official list of "niche use cases" that are supported by the Godot comunity or main devs, but still made as an online repository to not bloat the main engine.

[ca3games]

In any case, this could also be an official list of "niche use cases" of nodes that are still very useful to have, but are not so essential to have on the basic nodes.

An example list of such "niche cases":

JRPG/isometric 3D camera Platformer Rigidbody for the player Steering behaviours or other niche AI behaviours Companion 3D rigidbody that just follows the player A 2D Rigidbody that happens to have a caterpillar behaviour similar to rpg maker Inventory node Visual novel/JRPG dialog box AI flowchart FPS floating weapon hand Zelda hearth HP lifebar Switchable weapon model in a 3D character hand A cage boundary box for the camera's boundary levels

I'm sure I can think more "niche cases" that are very common between games from most genres, that may be nice to have some "advanced node" but they're not basic enough to justify being in the main add node window.

[YuriSizov]

Instead of opening the entire asset and browsing it, it would arranged and organized just as the add node window.

You would still need some browsing capabilities, filtering, descriptions, a way to pick between two contesting solutions. And you would still need to store the code for it somewhere in your project. AssetLib provides a more flexible solution to the problem, giving users full control over what to pick and how to use it.

We won't maintain a featured list of user-made nodes because that would be against our hands-off approach. It doesn't make sense to prioratize some assets over others and be a judge of that. If someone wants to do this as an alternative to the AssetLib, this can be easily done with a plugin.

[Jummit]

You are describing all the benefits of custom nodes added by plugins. All the other features like downloading them is covered by the asset library. I think it would be more productive to suggest simple changes to the existing asset library instead of proposing a completely new, but redundant feature.

[ca3games]

Instead of opening the entire asset and browsing it, it would arranged and organized just as the add node window.

You would still need some browsing capabilities, filtering, descriptions, a way to pick between two contesting solutions. And you would still need to store the code for it somewhere in your project. AssetLib provides a more flexible solution to the problem, giving users full control over what to pick and how to use it.

What if there was an "advanced node tab" with officially supported nodes for some features that are very common to specific genres? By example, an Isometric/JRPG 3D camera would be very well inside those "advanced nodes" and is a very common feature that would make godot much better to begginers if they could simply import some 3D Isometric camera instead of making it their own.

Some features like a node to switch weapons in a 3D character could then be officially optimized for this case.

Again, those are super common situations that happens in most games, would make then sense to support such cases somehow.

[ca3games]

You are describing all the benefits of custom nodes added by plugins. All the other features like downloading them is covered by the asset library. I think it would be more productive to suggest simple changes to the existing asset library instead of proposing a completely new, but redundant feature.

Well, yeah, feel free to suggest ideas to improve the asset store. I feel is one of those areas with great potential but I feel It needs some polish.

[Xrayez]

I think the idea is great (would also benefit from some mockups), but I'm afraid that's a can of worms to open for the Godot developers.

I've actually had a similar (or exact) idea as in this proposal. Here's what I mean:

Package authors would need to define a list of classes a plugin "contributes" to the editor, and then the create dialog could populate those classes from the AssetLib.

If someone wants to do this as an alternative to the AssetLib, this can be easily done with a plugin.

Even if this won't be implemented in Godot, I don't see a way to extend the create dialog nor a way to interact with the AssetLib to implement something like this via plugins (at least in a way I've shown in my mockup). The idea here is to have a tight integration (VS Code anyone?).

[Xrayez]

The editor asset library integration intends to remain similar to what it is now. Exposing community-developed stuff in something as essential as the Add Node dialog could be misleading as to what is officially supported and what isn't.

Is there any intention to have plugins officially maintained by the core developers? The only thing I see are demo projects:

[Calinou]

Is there any intention to have plugins officially maintained by the core developers?

Official plugins such as webrtc-native already exist, but these aren't plugins you can download on the asset library.

[KoBeWi]

The problem with advanced nodes is that their implementation and usage may vary greatly between games. You either end up with something that's useless for you so you have to create your own anyways or with nodes that are bloated with extreme customization. I doubt they would be useful for more than making basic prototypes.

[Xrayez]

Isn't Godot widely used for prototyping purposes currently? That would make it even more compelling to use.

Godot's development philosophy tells that it should take you little effort to start making something and those games should look and feel like those created in AAA game engines. This leads to the other side: there's little to no knobs that would allow you to configure for specific use cases, so I think that's one of the reasons why this proposal was created in the first place, because it would soften the lack of customizations for built-in classes, since most of the features in Godot are implemented by solving concrete problems, meaning that we have a good deal of pragmatism here.

We won't maintain a featured list of user-made nodes because that would be against our hands-off approach. It doesn't make sense to prioratize some assets over others and be a judge of that. If someone wants to do this as an alternative to the AssetLib, this can be easily done with a plugin.

I think there's no need to be autocratic in this regard, it's a community-driven game engine after all. Pick those plugins which community need in their own projects (or those already commonly used).

Again, the idea here is to pick good quality (community or semi-official) plugins that:

• fulfill a popular request;
• easy to install and use in projects.

If there are some plugins which are not quite there, interested contributors can help plugin writers to make those plugins to pass the requirements. We even have a page for this in the docs: Submitting to the Asset Library,

[YuriSizov]

I think there's no need to be autocratic in this regard, it's a community-driven game engine after all. Pick those plugins which community need in their own projects (or those already commonly used).

And this can still be a fully community-driven effort if one makes it into a plugin. I see no problem creating a plugin-driven editor UI that connects to a "database" of nodes described in some metadata file on some GitHub repo, where links to publicly available nodes are listed. That UI would give an easy to use option to copy the node's code into your own project.

It would take a day to make such a plugin and its ecosystem. The only problem would be maintaining it, but that's up to the community. If there is someone interested in this, they can give it a try.

[Xrayez]

Implementing this proposal via plugin ecosystem defeats the purpose of having "out-of-the-box" or "batteries included" experience for users, so this proposal only applies for core development (even if it won't likely receive any consensus).

A user needs to find out a community developed plugin which provides a list of good-quality plugins. That's just a lot of effort for both a user and a developer. It would also take a significant chunk of time for such a system/approach to become commonplace.

Maybe I'm wrong and someone will actually succeed with this approach.

[YuriSizov]

Sure, plugins are not as discoverable as built-in functions are, but core team doesn't have resources to maintain a repository of those nodes on top of the AssetLib. Besides, many ecosystems have community-driven projects that succeed without technology's core support. It would be more productive to try it this way.

[Xrayez]

Sure, but I'd start describing the engine's purpose the way core developers want the engine to be more clearly, and change the way Godot is currently advertised to end users. Many people wrongly assume that Godot will solve all their problems, but it's not actually the case.

Read the problem in this proposal:

Godot is a great engine, but a lot of times it feels like you're simply starting from scratch every project.

And an official description of the engine at the homepage:

Godot provides a huge set of common tools, so you can just focus on making your game without reinventing the wheel.

We definitely have a mismatch here, don't you think? 😛

[Calinou]

Closing due to lack of support (see reactions on OP and general lack of activity here).