DerrickBarra
commented
10 months ago As a studio head, this is absolutely critical for our day to day operations. Unity supports a buggy and half baked version of this which is what our team uses, and Unreal does not have any support for this workflow out of the box (they push you towards mono-repo based development using branches). You can achieve a worse version of this using a custom Unreal fork. But Unreal's C++ only supports scripting define symbols, but those are not supported by Unreal Blueprints so your scripters are writing very brittle logic.
Our teams use a methodology called plugin based development (also called multi-repo based development), where every dev or group of devs are working on their own seperate plugin, which has its own dependencies for tools and assets. Each of these plugins then gets used by another dev or group further to the right of this dependency tree. Eventually this ends with the final repository for the project.
Each plugin is given its own namespace, scripting define symbol, and assembly definition file for ensuring code and asset links can safely be broken without causing compiler errors to appear. Instead you'll recieve a nice message written by the plugin dev team in the log pointing out what your likely missing and possibly alternative functionality for the plugin to compensate.
This approach has a multitude of benefits.
- Onboarding of devs is much faster
- Easy to debug and optimize code
- Plugin documentation is easier to read and write
- Breaking code and asset links is safe
- Asset store integrations are more likely to be allowed in a full production codebase (as they can be safely wrapped by a manager and replaced as needed)
This is our opinion of course, but once you use a multi repo based approach, you'll never go back to using a mono-repo if your a mid size or large scale team, its simply too painful and adds too much scope.
So to sum it up, this proposal (as well as the other missing pieces of this workflow) are our highest priority asks to replace Unity with Godot.
I'd be happy to talk more about this as well and provide details, I'll be following this proposal with great interest.
Calinou
Loufe
Describe the project you are working on
Various version controlled projects derived from a single game template.
Describe the problem or limitation you are having in your project
When I push a game to Git, I add the addons folder to my .gitignore. When I clone that project again (in a CICD pipeline or local machine), the engine does not know what addons are missing. It seems like the intended solution is to commit the entire addons folder to my repo (including potentially conflicting licenses). My projects are open-source, so this will absolutely become a much bigger issue if we start offering closed-source or paid assets on the store in the future.
There is no valid way to version control a project that contains multiple addons. My project's source code should never contain the entire source code of another asset.
Describe the feature / enhancement and how it helps to overcome the problem or limitation
We need to support addons through the editor or version control. We could officially integrate Git submodules into the asset library (since we support Git already), but an easier approach might be to simply add a manifest file to each project. This file could then be checked each time Godot loads a project, and if the addon is missing, the developer will be prompted to download and install the missing dependencies.
For an example of how this can be handled, look at Node.js (NPM). The packages in package.json will be installed if they are missing, but the only file to be committed to version control is the package manifest itself.
Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams
When the user adds an addon to the project, the addon is added to
project.godot:When the project is loaded, the editor checks if the folder exists. If one or more addons are missing, a popup window is presented:
The user then could download one or more packages automatically before they start working.
There would also need to be a command-line option to download and install all missing addons so headless systems could set up dependencies properly.
If this enhancement will not be used often, can it be worked around with a few lines of script?
No. My current solution is to use Git Submodules. This usually involves forking the addon to delete extra project files, then including my fork as a submodule in the addons folder.
This solution is tedious and requires me to manually keep my fork up to date with the addon's master project
Is there a reason why this should be core and not an add-on in the asset library?
The problem is the add-on asset library.