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 deviding it up into 3 seperate ideas:
1. A source code respository for storing all the C++ code
2. A exported asset 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 asset 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 guys think of this structure. Any comments are welcome. I'm really down in the dirt with this one.
Version Control
1 and 3 are logically the same thing (raw material). That said, if your source control system does not handle media files well, your proposed structure sounds good. Many studios use separate version control systems for media and code, because the act of comparing versions of media files as opposed to code changes is very different.
You are correct in that "drop" type items (such as compiled assets and media) should be in a separate place from the raw assets. This way, you can cleanly separate the concerns of developing, building, art production and testing. You could also store the build results (your binaries) in the drop location, so that your artist can run the latest version of your program without having to compile the code.
In short, I think your plan is good.
You are correct in that "drop" type items (such as compiled assets and media) should be in a separate place from the raw assets. This way, you can cleanly separate the concerns of developing, building, art production and testing. You could also store the build results (your binaries) in the drop location, so that your artist can run the latest version of your program without having to compile the code.
In short, I think your plan is good.
Author
Hmmm maybe I should put the raw assets and source code into the same repo, just in different workspaces. Thus, the code and the assets can be labeled under the same version and they both can stay in sync.
So you're suggesting I should put al the compiled artifacts into a network share type of thing where a script can just sync them to the other users machines?
Thanks for the quick reply
So you're suggesting I should put al the compiled artifacts into a network share type of thing where a script can just sync them to the other users machines?
Thanks for the quick reply
1: Yea, but source control systems do not usually provide means to - for example - visually compare versions of art assets. This fact usually necessitates using a separate version control system for art. Art assets are just files, though, so technically you can store them in the same place as the code if you don't care about the practical limitations of version comparison.
2: Yes. It is beneficial that the whole team can access the built product at any time, even though they don't necessarily have the means to actually build it themselves.
2: Yes. It is beneficial that the whole team can access the built product at any time, even though they don't necessarily have the means to actually build it themselves.
Personally I'd suggest you move to Git. You could have your assets in a different repository and then have it in as a sub-module.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
