I’ve been getting more into UE4 recently, but before I start creating a bunch of content for projects, it would be great to get a sense of how you guys manage stuff you create. My main questions are as follows:
How do you separate work-in-progress files (.MAX, .PSD, etc), finalized content (.FBX, .TGA), and Unreal assets? Do you store all of these in the same place or use separate directory structures for each purpose?
What is the simplest way to create a bunch of UE4 assets that can be imported into projects? (Kind of like the starter content, but more on-the-fly)
I’m interested to hear how different people tackle the issue of organization, just to get an idea of what might work best for me. Thanks!
UE4 wants the imported uassets to all live in the project structure, but the source data can live wherever.
I find that a best practice is to define a place where everybody checks out their project and work files, no exceptions.
That way, you can write scripts that know where to find things, and “last imported path” will point at the right location for re-import, etc.
Often, you’ll define some drive letter in Windows (“Q:” say) and use “subst” to make that point at the “real” location of the files.
The game would then go into “Q:/Checkout” and everyone will be good.
Separately, I keep my PSD, MAX, and similar files in a “ToImport” directory that’s inside the project directory, as a peer of “Content.” I then version control the entire project directory.
This works for smallish games, and should work for larger games if you use some source control that’s good for large binary files (like Perforce.)
If your programmers want to use Git, but your artists want Perforce, then you might want to have your “Checkout” directory contain “Project” as the UE project folder, checked out from Git, and “Art” as the source art folder, checked out from Perforce.
Finally, if you work on really, really, big projects with very long lifetimes (MMOs, integrated military simulations, etc) then the “everybody uses Q:\Checkout” rule breaks down, because you need to be able to build and run multiple versions in parallel, and re-subst-ing to point at different checkouts starts hurting your workflow.
For those situations, you need to write all scripts to know which project/version/directory they are run from, and do everything based on that directory, rather than a hard-coded path.
It’s still a good idea to have “Checkout” as the directory, with “Project” and “Art” as sub-directories in this case (and perhaps “Scripts” as a third checkout for all your custom scripts/tools.)
TL;DR: github repo for game project (and certain folders that are primarily data), github repo for my custom engine fork, and then two workspaces in p4 (being stored on an AWS EC2 server) to hold ALL THE THINGS.
Thanks for the in-depth responses! I wasn’t even really thinking about source control, but it’s definitely something I’ll need to consider down the line. I’ve never really been sure how one manages such large files in version control, so this helps a lot.
