godotengine / godot-proposals

Godot Improvement Proposals (GIPs)
MIT License
1.16k stars 97 forks source link

Resource Subsets as a Resource #6583

Open jasonwinterpixel opened 1 year ago

jasonwinterpixel commented 1 year ago

Describe the project you are working on

Rocket Bot Royale, a game that is available on HTML5 builds on web platforms.

Describe the problem or limitation you are having in your project

We are trying to shrink the size of the exported .pck as much as possible. We would like to use the 'export only selected resources and dependencies' system, but it is difficult to iterate on because we have to actually export the game every time in order to see if we have it working.

We have a massive godot project with > 1000 godot resources. It takes a lot of time to manage and update the settings for these resources.

It is also difficult to manage this resource subset across all the different export targets. We ship to 9+ client targets (iOS, Android, Web, Web No Threads, Web Platform Specific, Mac App Store, Mac Steam, Linux Steam, Windows Steam).

Currently we have to specify the subset of resources that we would like to export in this UI: image

Note that the 'resource subset' is defined not only by these checkboxes, but also by the wildcard (*.sdf etc) patterns specified in a text box below t.

We should merge these into a specific new resource type: Resource Subset or Exported Resource Subset or something like that. Then each export target can refer to the correct resource subset, can share resource subsets, and the Resource Subset inspector can offer developers some useful features.

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

The 'Resource Subset' should be a .tres that could be referenced by each of these targets, so that each export target could refer to the same one.

Id like to be able to tell the editor to only allow the game process access to the resource subset .tres file. Then I can quickly test a build right out of the editor with only access to the subset of resources. Then I can confirm if I have the right subset selected. This would be a faster iteration loop than exporting a client each time, and gives better access to debugging.

Id like to be able to have the inspector for the resource subset .tres file display the complete set of dependencies that it will include. And I'd like the resource subset .tres file to allow me to individually add specific resources, folders and even wildcard patterns like *.json to it, similar to the checkbox UI that is currently present on the Export window (as displayed in the screenshot above).

Id like for each resources 'View Owners' to also display which resource subsets it is a part of, bonus points would be if it displays the resource subset that is a part of as an indirect dependency.

It would be also very useful if we could inherit one resource subset from another and add (or even remove) files from it.

ie: client_base_resources.tres has all the files necessary for the client game to run, mac_steam_client_resources.tres inherits from client_base_resources.tres and adds the files necessary for the mac steam client version of the game.

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

The code for computing resource subsets already exists in godot, I'd simply like for it to be split out from the export presets and into a unique .tres, and then for it to have some extra features like displaying it's full set of dependent resources.

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

No. It would be perhaps a few hundred lines of very slow script.

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

This is to improve the usability of Godot for large projects, with thousands of resources and many export targets.

jasonwinterpixel commented 1 year ago

Related: https://github.com/godotengine/godot-proposals/issues/5992

KoBeWi commented 1 year ago

Sounds like something that can be done with EditorExportPlugin.

No. It would be perhaps a few hundred lines of very slow script.

Not really. idk which part you think is complex, but finding dependencies is just parsing ext_resource tags of scenes/resources, which can be done with a regex. You can scan your project and store subsets in any text format.

jasonwinterpixel commented 1 year ago

You're right, it could be done in EditorExportPlugin. Just discovered that today.

YuriSizov commented 1 year ago

I still think that there is merit to the proposal. Export configurations have shared properties between different platforms, and it would be great to improve usability by making those parts reusable. Using resources for that seem like a very Godot-approved idea too.

KoBeWi commented 1 year ago

228

jasonwinterpixel commented 1 year ago

Note: EditorExportPlugin is not currently capable of fully trimming the outputt'd binary.

EditorExportPlugin only gets the oppurtunity to skip godot resources. It has no say regarding imported assets like .png, .ogg and even .gd's that are compiled to .gdc.

This severely limits the usefulness of EditorExportPlugin.

EditorExportPlugin's should be able to skip every file.

The key issue here is that maintaining the list of resources to export across every export target is very error prone. Using a EditorExportPlugin to workaround this issue is quite a bit of work and unfortunately presently not possible due to the aforementioned issue.

If we could share parts of the configuration for a export target, then it would be far easier to maintain the list of resources to export across many export targets.

Also, when a folder is checked by in this resource list, and then a new file is added to that folder, that new file is not added to the resource list. So the workflow for adding a new file to the game would be: add the file, go through every export target and add it. That is unreasonable and should be improved.

I think perhaps this is a superset: https://github.com/godotengine/godot-proposals/issues/228

But at the very least, having this list of resources to export be itself a resource with some more powerful features (match file name patterns, truly export the entire folder with everything in it), then this particular issue would be helped.