Learn best practices on setting up an Unreal Engine studio when it comes to technical production workflows like version control, branching strategies, binary deliveries, virtual assets, shared/cloud DDC, UGS and more!
https://dev.epicgames.com/community/learning/tutorials/8JYW/epic-for-indies-setting-up-an-unreal-engine-studio-the-epic-way
4 Likes
The Submit Tool looks super cool and we’d definitely be interested in having access to that. Thank you for another superb talk Ari!
4 Likes
Thank you very much for sharing!
Is the Epic Game Sync a full-featured Perforce GUI or you’re still using p4v? I’d wish to have a normal client for Perforce, as by default it’s totally frustrating even after you learn how to use it.
Do you mean Unreal Game Sync? UGS is only useful for getting file revisions (as far as perforce goes, it has lots of other useful elements). You’ll still need to use p4v to do commits, resolve conflicts, do diffs or any other perforce operation that is not some variation of “sync to … latest/CL/good build/etc”.
This is great ! Learned about UShell and some other thing, going to be very convenient 
1 Like
We still use P4V for submitting code, and Unreal Editor or our (currently internal only) SubmitTool for submitting assets (we can’t use P4V for submitting assets because we’re using virtual assets).
UGS is for browsing changelists and syncing to them / building them.
Thank you for making this tutorial, it’s full of great information!
Definetly would be interested in the Submit Tool if there’s any plans to release it to the public in the future.
Also in regards to Ushell and P4VUtils, you mention that internally they’re distributed as UGS custom tools which seems like what we’d like to do as well, however I can’t find any information anywhere about how to setup UGS Custom tools, is there any documentation about this that I’m missing, or do you have any pointers to start looking into?
Thank you!
Hi @GVercellotti1010, you’re right in that there’s no info anywhere on it. I had to investigate quite a bit how we do it, I’ve now added some documentation on how to do it at the bottom of the article, here.
1 Like
Hey,
Thanks for the write up, it’s very handy.
One question in regards to Swarm reviews, how do you manage locks while files are in review?
Currently we run p4 unshelve -s ID on our build server to do a test build before commiting, but for this the files need to be unlocked - but then we run into the situation where another developer will submit changes for the same file that’s already in review.
How does Epic handle this workflow?
Cheers,
Steve
@ShadyKutz We don’t lock them. The reviews are only for code files, which don’t need locking and merge just fine even if others are working on it. We don’t do shelve-style reviews for content / binary files.
1 Like
Thank you very much 
What about blueprints?
We just do simple Jira ID checking in Swarm for content reviews, unless they have BP / Code - but it does cause issues with locking.
For blueprints it’s best to review them in editor using the Review Tool:
There you can put in the changelist for a commit or a shelve and diff any BP from it in the editor.
But yes, exclusive checkouts (locks) of BPs make this a bit of a headache, only one person can review at a time.
When installing the Horde Server, I don’t have any Horde Agent download under Tools. Where can I find the Horde agent installer?
@kiwidog The server can get in that state if you built Horde without also building and registering tools, which is done through - Engine\Source\Programs\Horde\BuildHorde.xml ~Ln 123
We do not expect that state if Horde was installed from the Release-5.4 Installer - https://github.com/EpicGames/UnrealEngine/releases/tag/5.4.0-release
I appreciate the reply, I’m currently working on a blog post hopefully that will be helpful to others setting this up giving some feedback to the team as well. Thanks a lot!
1 Like
Hello Ari!
Thanks for the speech, everything is very helpful!
Following all the tutorials on setup UGS, precompiled binaries etc I find something a little odd on engine build management.
Right now in my company we share the same engine code using some stream mapping like explained in the p4 tutorials:
UE stream: //UE5/main/…
ProjectA:
//ProjectA/main/… with view:
share ProjectA/…
import+ … //UE5/main/…
ProjectB:
//ProjectB/main/… with view:
share ProjectB/…
import+ … //UE5/main/…
And we create Precompiled binaries with the command:
RunUAT.bat BuildGraph -Script=ProjectA/Build/ProjectABuildGraph.xml -Target=“Submit To Perforce for UGS” -set:UProjectPath=“ProjectA/ProjectA.uproject” -set:EditorTarget=“ProjectAEditor” -BuildMachine -set:ArchiveStream=//ProjectA/binaries -p4 -submit
The issue is that the build.version in UGS and on the script is driven by the project stream and not by engine stream, resulting on CL and stream versions incompatible between the 2 project.
How do you manage this in Fortnite (or other companies) and is there something i am missing in the setup?
Thanks for the help
This is every studio need, so amazing, thanks for your contributions. It’s so helpful.
1 Like
I also read the similar depot configuration.
But I found that, using the import+ to inlcude the engine depot will cause some problem.
When you create a new Dev stream from ProjectA mainline, the new stream will also include the main stream of engine.
