I have setup the source code of Unreal Engine 4.6 from github within our team’s svn repository and everything is working just fine. The problem we are currently facing, is that we have artists, musicians and game designers in our team, which need access to our game project. Since we plan to add modifications to the engine source, we cannot just have them open our project with an “official” binary installation.
My question is now, is there any way to have the non-programmers of our team launch our project with our own source build, without them having to install Visual Studio and build the engine themselves? And if yes, what would be the best approach to doing so? I reckon we’d have to manually extract the required binaries from a somewhat stable build, check them into a separate repository, and include our game folder as svn:external, so the svn locks/commits are properly synced. Which binaries/folders would we have to do that with?
Hi, we don’t know yet which changes we will need exactly, but one of the changes we need to do, is modify how the camera works, so you can hide a SceneComponent from some cameras (not from all cameras). This will probably include new Blueprint-Functions in the “native” UE-classes.
It might be possible to later launch our project with the unmodified 4.6 binary build, but our custom features will be missing, which isn’t optimal anyway, if artists/designers want to work with it.
First of all I’ll describe what we do here at Epic; as you’d expect, in general we don’t get content creators to build the engine themselves. Our process goes something like this:
Programmers check in changes into Perforce as and when they need.
Our build farm performs continuous integration of these changes, creating builds periodically and checking binaries into our depot.
QA pick up these builds and perform quick smoke tests on them to make sure they are OK to use.
If the build is verified OK, then a Perforce label is made that designates a changelist as a ‘Promoted’ build.
Artists then use a program called UnrealSync (source to which is located in Engine\Source\Programs\UnrealSync) to sync to the labels specified by QA. These are usually only the binaries and content required to run the build, rather than the whole depot. UnrealSync is not set up to work with SVN, unfortunately.
Content is not checked into our depots unless it is from a ‘Promoted’ build. This ensures that file versioning is straightforward (i.e. we don’t have to cope with file format changes from the ‘future’).
Now in your case you are using SVN, which has a different set of capabilities. “Labels” can be replaced by “branches”, for instance.
Using a separate repository for each “part” of the build may be easier from a data management point of view as the repository could get large with lots of binaries in it. I agree that extern-ing your Game & Engine directories sounds like a useful exercise if you plan on using separate repos. I think making a branch before a build is made would be convenient. Branches are lightweight and you may want to revisit that build at some point in the future.
As far as directories go, it depends on what you are building for, but in general you would want to these directories available for people to sync:
(Engine/Plugins contains source as well, so you could be more picky with what you sync from there - you don’t really need the /Source directories, for instance.)
Game build:
Game/Binaries
Artists should only need to work with these files/directories in their local working copies:
Game/Config
Game/Content
Game.uproject
Bear in mind that this is all only theory as we only use Perforce internally and have not tried SVN as a build distribution method!
One more thing to mention too - a shared DDC can be really useful when working on a team with many artists and anything more than a small project. I strongly recommend setting one up!