How to use functionality which allows "creating your game project directory outside of the Lumberyard engine directory" with an existing project?

Looks like 1.12.0.1 has a new functionality which is designed to handle having a project outside of the `dev’ dir. Currently looking into converting my project to use this functionality.

I created a new project using the instructions here (https://docs.aws.amazon.com/lumberyard/latest/releasenotes/lumberyard-v1.12-fixes.html#lumberyard-v1.12.0.1-fixes). This seems to work fine.

However, I’m not sure how to properly migrate an existing project to use this functionality. Any advice/documentation regarding this would be very helpful.

Based on the directory structure of the newly created project, I gather that all the binaries which in principle can be shared between different game projects would now be duplicated for every game project; is this correct? If so, is there a way to have multiple external game projects use the same binaries for i.e. the editor and gems? (or plans to implement such a feature?)

Finally, supposing I am going to have all my game projects as external game projects, do I have to keep the entirety of the `dev’ directory around? In particular, I have the Lumberyard folder in source control, and I’d like to minimize the size of the repo required for a clean build. Does having external game projects allow me to do that?

Great! Since it was in 1.12.0 and not an earlier version the process should be as you described. This feature does do what you’re hoping for in allowing you to move the project outside the dev folder. The dev folder will have some configuration generated to point at the active project which is how the link is maintained. Let me know if you have further questions here.

In what version of Lumberyard did you originally setup your project? If it’s isolated to a gem, it should primarily involve moving your gem into your external project. This isn’t something I’ve attempted personally so I’ll have to run through it myself to give you the detailed steps.

It was created in 1.12.0.0. On further investigation, it seems the migration is easy. The remote project directory contains another directory named which contains a project.json, gems.json so it seems that placing the old project directory there would work.

If you don’t plan to modify the core engine you could, in theory, forego versioning it. This should also make updating to a newer version of Lumberyard significantly easier. You could also try maintaining separate streams for each external project and the engine core.

Having recently updated 1.12.0.0 to 1.12.0.1 in our source control, I didn’t find the process difficult at all. The burden of having parts of the engine duplicated in multiple project directories makes this feature in its current form more difficult to use than any benefit we would gain.

Overall, what I was hoping for with this feature is a project/editor structure which is identical to the current one, but the project folder is just in a different location than the `dev’ folder. This could be accomplished with a symlink, but for an issue with the Asset Processor not working when the project folder is a symlink.

Hey @yuriy000,

In what version of Lumberyard did you originally setup your project? If it’s isolated to a gem, it should primarily involve moving your gem into your external project. This isn’t something I’ve attempted personally so I’ll have to run through it myself to give you the detailed steps.

As for your question on duplication of common resources, yes you are correct. They would in fact be duplicated per external project. I can’t comment as to future plans but it is something we are aware of.

For your last question, that really depends on how you want your workflow to look. In a vacuum, yes you will need the dev folder and the engine resources to complete a build. If you don’t plan to modify the core engine you could, in theory, forego versioning it. This should also make updating to a newer version of Lumberyard significantly easier. You could also try maintaining separate streams for each external project and the engine core.