Hey.
I have a project that manages the Inventory.
I have a main project that manages the Player Character Logic.
I have a project that manages the UI.
What I want is to work on the Inventory once without migrating it thousands of times just to test it in my main project
With Shared Assets/Folders I could work on my Inventory once and could also have it implemented with the newest version automatically.
This is not a viable approach.
Maintain the whole game in the same project. One game - one project.
There is a reason why your suggestion wuld not work: Redirectors.
If a project/package/whatever is not loaded, redirectors cannot be updated.
Why would you split your game into several projects to begin with ?
Encapsulation. I think it’s better to isolate one aspect that I’m focusing on from the main project.
Encapsulation is a noble and right goal. But you do that on the asset level. Not the project level.
So if you put your UI, player values, etc in different Blueprints instead of, say, the level blueprint, then you have your encapsulation.
But all those elements need to work together and communicate with each other.
In what way would the existence of the player logic in your project be distracting when working on the UI for example?
ok, another reason. We have a large team and each person often works in what we call a ‘white room’ where they develop smaller parts of the game. Eventually, these could be migrated into the main project; that’s not the issue. However, they build these whiterooms out of shared assets that are in all the whiterooms AND in the game itself. Making these all just levels/maps within the same project is a poor solution.
Of course there are workarounds, but we’ve been very successful with this workflow before and it seems like we’re giving it up for no gain to the users. It might make the tool more complicated to implement, but users could care less.
What I would do (if I had a team):
-Build a test project that contains all your whiteroom maps.
-Each team member uses a local copy of it. (Ensures they all use the same)
Now the modeller can build his meshes in his 3d application and test it in his personal version of the test project.
But instead of migrating the asset into the master project, the raw asset (fbx) is copied and imported into the master project.
the fbx (and all other assets like textures for that matter) are stored on a network folder as well.
The artist can now tweak the mesh locally all he wants.
Once he thinks the new version should go into the master project, he just overwrites the fbx on the network folder and in the master project the mesh is reimported with a single click.
The same can be done with textures.
So in a nutshell: Update and reimport the assets… Dont migrate too much 