I know that this question has been asked multiple times, but honestly I haven’t found a decent solution. Here’s my scenario:
yesterday) C++ game project, multiple team members. Until now we’ve used the official engine release from Epic. Programmers distribute the binaries of the game (UE4Editor-gamename.dll and other modules) via SVN. Artists update their local copy of the game project, they get the new game binaries checked in by programmers and everything works fine.
today) We are forced to build our own version of the engine. Firstly because certain plugins cannot be used in c++ without compiling the engine from source (ie. FMOD) and secondly because the documentation of UE is so lacking on certain aspects that the only solution to understand how something is supposed to be done is by debugging the engine itself (inspecting call stack etc.). The problem is that now distributing the game binary to artists doesn’t work anymore. Since they are still using the official release when they open the project they get the infamous “the following modules are missing or built with a different engine version” dialog.
In my understanding the only possible solution is to distribute the custom built engine to the artists but how precisely this is supposed to be done is very unclear. All the proposed solutions found on answerhub are vague and look very “unconfortable” to me (sharing 20gb of engine via perforce to artists?). Also which files should be shared? What version of the engine should be shared? (shipping, development editor, development…) I can’t believe that there isn’t a clear step by step guide on how to do this…it’s almost easier to install Visual Studio on every machine and let them build their own version…
Is it possible to have an official and clear guide on this topic? I think it would be beneficial to many people.
The best way is to put everything on a source control server as you’ve said. However artists don’t need any Source folders as they won’t be compiling code. This can be done through your source control’s form of permission control. Perforce is great at this.
They won’t need every binary, but they’ll need every binary that isn’t prefixed with UE4Editor except for anything that is Debug or Shipping. You only need Development UE4Editor binaries for your artists to work without issue, and Development binaries aren’t tagged with any name.
You also don’t need any Saved or Intermediate folders at all. You don’t even need the Visual Studio project files as your programmers can generate them.
I kind of made a long-winded tutorial for setting up Perforce, if that helps.
first of all thank you for your quick reply. Your suggestions are valuable but I think that there are still dozens of possible “unanswered questions” on this topic. Just to name a few:
should the artists launch “UnrealVersionSelector-Win64-Shipping.exe”. Is it the right thing to do?
Unrealfrontend doesn’t get compiled building UE4, while it’s present in the official distribution. Should I compile it by hand? Is it needed? Who knows?
Why the guid of the engine differs on every machine (it seem’s just based on where the directory is located)? What’s the point in this, really?
As a consequence of point 3 every team member needs to modify his/her .uproject file to link it to their own local copy of the custom UE. Since the uproject is under source control this could lead to possible problems (ie. they accidentally check it in etc. especially with the less tech-savvy artists). Not a big problem but still annoying.
there are a lot of different configurations, which is the right one?
Why the official release contains ue4game-redist library files while the custom compiled one does not? .pdb files should be shared or not? Does they affect performance?
I could go on for hours Anyway I’ve tested sharing my own version to other members (basically just by copying the entire directory for now) and it works…it just doesn’t feel like a very clean way to doing things…