Take the 2-minute tour ×
Game Development Stack Exchange is a question and answer site for professional and independent game developers. It's 100% free, no registration required.

While developing the assets for the game, (meshes, textures, sounds, videos) ho do you manage them?

  1. Keeping them together with the source code inside the versioning system? (perforce, git, etc…)
  2. Or having a central back-upped, database dedicated to the assets and having the editors always work liked to it? (PostgreSQL, MySQL, etc…)
  3. Other?

What are the pro and cons of each, and why one should choose it over the other/s?

share|improve this question
    
Good question. I'm pretty interested in hearing how others approach this. –  David McGraw Jul 20 '10 at 7:11
1  
For info on version control: gamedev.stackexchange.com/questions/480/… and gamedev.stackexchange.com/questions/245/… I don't think this is a duplicate as it's specifically about assets –  Sean James Jul 20 '10 at 7:22
add comment

3 Answers

For many of us - especially working on smaller games - you absolutely should have assets in the same repository as your source.

The suggestion that assets belong in a separate repository only makes sense for very large sets of assets, or for somewhat-large sets of assets when there's a clearly defined engine/data boundary. Unless there's a specific technical reason for it - it's bad advice!

You want your version control to behave like version control. You want to be able to rewind and fast-forward and branch and merge revisions and still have your game working. And your code and assets will depend on each other.

For example: Your code might expect to be able to set a parameter on a shader, and that shader might depend on a texture being there. Or maybe the data format of your levels might depend on a particular version of your game code.

It almost certainly will get messy. And you have better things to do than to try and keep it tidy.


Now, as Mike Wagner commented (on this answer) - you don't want or need all the "in progress" versions of your assets under version control! Just the final/working version, as used by your code, will do - often this is what you export from your tool.

(Although if you do want to version-control the in-progress versions of assets - that's fine. And well suited to a separate repository. I personally find that good folder organisation and a proper backup system suffices.)

That being said - it's sometimes nice to have the option to just stick "in progress" assets under version control. Typically this involves having a content pipeline that can handle any 'export' steps for you - for example: flattening a multi-layer image to a single texture.

share|improve this answer
add comment

Versioning system.

With a roll-your-own approach you'd effectively end up rolling a versioning system, so better to use an off the shelf one that's already had years of design/code/test cycles.

Keep the assets in a separate repository from the source, to make it easier to keep checkout / sync times to a minimum and take different decisions on how much history to retain (though disk space is cheap, retain it all whenever feasible. Individual textures don't change that much over the life of a project).

Mark XML files as binary, merge tools tend to be very bad at merging nested markup and artists aren't likely to spot broken markup if the tool thinks there are no conflicts.

If you can, arrange a syntax check or even asset build on every commit and reject the commit with an email back to the person committing if it fails; this will save a great deal of team time.

share|improve this answer
1  
Agreed on keeping the art assets and code assets in separate repos. You may also find that the artists are more reluctant to check something in than the coders, and not necessarily because they find the system intimidating. They may have 30 rough outlines of a concept and not want to submit until they've narrowed it down to something they like. Factor this into the production pipeline. If there's a technical director breathing down their neck to check in everything they'll spend more time in the repo than roughing things out. –  Casey Wagner Jul 20 '10 at 14:06
1  
On marking XML files as binary: If your VCS allows separate diff tools, ask it to use something that specializes in XML diffing for XML files. This may help avoid weird broken markup. –  Jeff Jul 20 '10 at 15:58
    
+1 on this. :) Assets belongs in their own repository - if in a repository at all. Maybe using a dedicated asset repository software? Specifically created for that purpose, instead of trying to make it fit into versioning control systems designed for mainly textual content. –  jacmoe Aug 8 '10 at 20:35
add comment

Everything in one repository, if you can afford it in terms of size. I've heard of Subversion repositories in the vicinity of 1 TB. We are currently a bit below 400 GB.

Also, artists much check in everything, including the 30 rough outlines of a concept; we use separate folder trees for "source assets" and for "exported" - the ones that go into the asset build script. If your artist is hit by a bus tomorrow, you need to be able to have someone continue work on his assets the next day, only looking through the repository (no archeology on his personal machine). Once upon a time when games were 2D and sprites were prerendered from complex animated Max scenes, we had to ship a bunch of units in an RTS game with a bit crappy, and very inconsistent look (vs. the rest of the units), even though it was a matter of re-rendering with slightly different lighting and antialiasing settings - because the original artist had quit, and we didn't have his original Max scenes. Don't let this happen to you.

share|improve this answer
    
Upvote for mentioning "bus factor" ) –  Krom Stern Jul 26 '12 at 10:58
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.