Another developer and I have begun to experiment with the Unreal Development Kit and have installed the UDK to our local computers. He's been toying around and experimenting and has some basic code and assets already developed. We want to set up a VCS repository so we can collaborate on development of a UDK project.
Some things we've noticed:
- Source code goes in Development/Src/GameName/.
- Binary Content and other assets go in UDKGame/.
- The rest of the folders in the root directory are for the core UDK installation.
In terms of repositories, we've already come up with several options:
- Commit everything (even the core UDK code).
- Pro: Easy
- Con: We're committing lots of code that, while a dependency of our project, isn't technically part of the project.
- Commit the two folders we contribute to in two separate repositories.
- Pro: Isolates versioned code to stuff we create.
- Con: Slightly more difficult to set up, commits for one fix span multiple repositories, and we're committing a lot of binary content.
- Change the config so both the src and the assets live in one folder, then commit that.
- Pro: Isolates versioned code, commits for changes are in one repo.
- Con: Committing binary content.
- Commit SRC to one repo, use another solution for assets (FTP, Dropbox, etc)
- Pro: Isolates versioned code, no extra overhead in versioning binary content.
- Con: Changes span multiple places and manual updates to a remote storage solution are needed.
As we assess the best way to go about this so we don't back ourselves into a corner later, I'm wondering if there are other options and what their pros and cons are. I realize we could easily just pick a solution and change it up once we ran into scaling issues, but version control has always been one of those things I like to do once upfront and then forget about when I work on projects.
Answer
If Perforce is an acceptable option for you, then I can suggest a solution.
Repository layout
Try to separate UDK and your game, but keep them in the same repository. Don't forget that Perforce has client view for vHere is a possible depot layout:
+- UDK
| +- 2011-09
| +- 2011-08
|
+- YourGame
| +- Src
| +- Assets
|
+- YourOtherGame
+- Src
+- Assets
And one possible corresponding workspace (I don't have the exact UDK layout in memory, but I hope the idea is clear):
//depot/UDK/2011-09/... //client/UDK-LATEST/...
//depot/YourGame/Src/... //client/UDK-LATEST/Development/Src/YourGame/...
//depot/YourGame/Assets/... //client/UDK-LATEST/YourGame/...
One advantage is that you can switch a single workspace line and replace the current UDK version. And at any time you may create another workspace that has YourOtherGame instead of YourGame.
A note about Git and P4
Personal story: my company uses Perforce for an Unreal Engine project. When I arrived there I refused to use Perforce because of the huge step backwards it was compared to Git, and decided to use git-p4.
git-p4 religiously keeps all P4 revisions in my .git directory. After 3 months of preproduction this was no longer an acceptable solution. .git had grown to several dozen gigabytes. git-import crashed on files larger than 400 MiB.
So I went for the dual workspace solution: one workspace for the data, and one workspace for the source. The former I still manage with P4 and the latter with Git. They are interleaved in my working tree, but P4 ignores the files managed by Git, and Git can ignore the P4 files with a few .gitignore entries.
In the end I get the best of both worlds: the speed of P4 when dealing with large files, and the features of Git when branching, rebasing or blaming. One major drawback is that I cannot do a single atomic commit that touches both workspaces.
No comments:
Post a Comment