# Finding the right directory structure for version control

Recently I've started thinking about how to layout the directory structure for my game engine. And well, I kinda hit a little snag.

There's going to be 2 people working on this project. Me and one of my friends. The problem is how do I do the layout of the directories so that it works nicely with version control (I'm using Plastic SCM. It has really nice features).

I'm thinking of dividing it up into 3 separate things:

1. A source code respository for storing all the C++ code

2. An exported assets repo where my friend can store all his exported data. (Exported as in final version that can be used by the engine).

3. And a raw assets directory where all my friends raw assets go into. These include stuff like psd files and mb files for easier backup and versioning.

What do you think of this structure? Any comments are welcome. I'm really down in the dirt with this one.

• You should read the top answers to this question: gamedev.stackexchange.com/questions/801/… – Marton Jul 26 '12 at 8:57
• What VCS are you using? If you're using Git, you could use assets as a submodule. – YuriAlbuquerque Jul 26 '12 at 13:43
• Could you elaborate a bit more Yuri – Wynand Pieterse Jul 26 '12 at 17:28
• About these submodules of git :) – Wynand Pieterse Jul 26 '12 at 17:28

That's quite neat and clean. Just don't mess with different repos, make this separate directories at the root of your repo. This will of course evolve with your project, but as a startup layout this is way enough.

Your exported assets directory should probably be excluded from version control. It might be a good idea to have a separate "exported code" directory (object files + symbols + executables), to exclude from version control as well.

So, for instance, something like that:

repo
├── code
├── assets
├── export *
│   ├── code
│   └── assets

* Excluded from source control


It's apparently straightforward to exclude files/directory from version control with Plastic SCM, by using an ignore.conf file.

• Hmmm that's way different than what I thought. I like this aproach more. Keep all "source" data under source control, and generate all data locally as needed. This will also work nicely with a CI server building the stuff and just pushing it out to everybody – Wynand Pieterse Jul 26 '12 at 10:55
• +1. This is exactly what I was going to say - separate directories for assets and code (so that artists don't have to check out code and vice versa) but exported assets - like binary builds of code - should be excluded and generated on demand. (If you want to keep snapshots of the build, that's fine, but that's usually best done outside of version control.) – Kylotan Jul 26 '12 at 11:13
• What I meant with exported assets is assets that are ready to be consumed by the engine. So basically the artist will export into this format straight out of their DCC tool – Wynand Pieterse Jul 26 '12 at 11:27
• Yes, my comment is meant to read as "exported assets, just like binary builds of code, should be excluded" :) – Kylotan Jul 26 '12 at 11:40
• Hehe sorry just tought I should express it a more :) – Wynand Pieterse Jul 26 '12 at 17:30

Let's get to roots of SCM - it is for sources. Now sources are not only text files, they are everything that you use as a source (source codes, scripts, PSD files, sounds). Everything that can be repeatedly generated are not sources (spritesheets, executables, resource packages).

You need to store all sources in one repository for the sake of consistency. Because each and every revision ought to be self-sufficient. You also need to have build scripts to produce application and all its assets from sources. Builds are not stored in SCM because you can always regenerate them.

EDIT: Once you put size out of the question, it makes sense to keep all sources in SCM because it's quite often when engine behavior depends on lookup textures, models sizes and shapes, assets count and location (also think TDD). When you have source codes revision A you ought to be very confident in your engine to allow it to work with any other assets revision. Otherwise you need to make a tie that code A works only with assets A, B-B, C-F etc.. and then when you rollback the code you need to rollback assets as well. That ruins SCM idea.

From practice: we were storing paletted textures, but since r2879 we switched our format to full-color textures. Having source textures (some unchanged since r1000) and generation scripts under SCM we don't have a problem of finding right assets/exe combo.

• In traditional versioning, sounds, images etc don't count as source but as binary file. Most SCM can story binary files, but they aren't optimized to be used like that (we even had guidelines at my old employer that forbid the storage of binary files in SVN). I only keep small assets, that I use for game testing and tools in subversion (so developers can check out the source an run it). Assets (artwork, graphics, sound, levels etc.) should be managed in a sepearte control system (specifically for binary files or assets). I currently have the seperate control system "Copy to FTP folder" ;) – tom van green Jul 26 '12 at 10:12
• I though agree on the generated items. I also tend to only store the basics and generate everything as needed from the base assets, as this ensures, that I have always the most recent version of the assets, my artist created (provided I updated the assets folder). – tom van green Jul 26 '12 at 10:13
• Replied in answers body – Kromster Jul 26 '12 at 10:50
• Yes yes that makes perfect sense now lol. This will also keep all generated assets up to date with any new stuff you add to the asset compiler – Wynand Pieterse Jul 26 '12 at 10:52
• It's not a matter of size, more a matter of using the right tool for the right job. If you have very few assets it may be overkill to use multiple versioning systems, but when you have a lot of assets to manage, it would be wise to use a seperate system. Take a look at alien brain for example: alienbrain.com . As it is designed specifically for that purpose, it is much easier to manage and work with the asset library and gives you some useful tools. You could make a web application only with textfiles as data store, but most likely you would chose a database to store your data in. – tom van green Jul 26 '12 at 11:33

I would recommend using Trunk-Branches-Tags as your top level. Branching is invaluable for experimentation. I am not familiar with Plastic SCM, but my experience with Subversion is that you need to plan for these needs from the outset. Then under the trunk you can set up your files. Otherwise, as for binaries, I like to store the optimized final format and the most up to date source(photoshop, raw video, etc.,) in my repository. The main reason is that most of my tools support Subversion.

• Branching is very easy with plastic. They promote the task per branch methodology a lot. That's the main reason I started using plastic, as it allows easy experimentation. – Wynand Pieterse Jul 26 '12 at 17:34