29

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?

Tetrad
  • 30,124
  • 12
  • 94
  • 143
  • Good question. I'm pretty interested in hearing how others approach this. – David McGraw Jul 20 '10 at 07:11
  • 1
    For info on version control: http://gamedev.stackexchange.com/questions/480/version-control-for-game-development-issues-and-solutions and http://gamedev.stackexchange.com/questions/245/what-version-control-systems-work-best-with-games-closed I don't think this is a duplicate as it's specifically about assets – Sean James Jul 20 '10 at 07:22

3 Answers3

21

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.

Community
  • 1
Andrew Russell
  • 21,268
  • 7
  • 56
  • 103

  • The suggestion that assets belong in a separate repository only makes sense for very large sets of assets,

    How large? >1GB?

     – Konrad Aug 09 '20 at 09:55
  • 1
    Back in 2010, when this answer was written, maybe. These days I'd say that it's something that you'd only even start thinking about with many 10s of GB of assets. And then, you'd probably look into version control schemes that let you store bulk data externally, long before considering taking them out of version control entirely. – Andrew Russell Aug 10 '20 at 03:22
  • 1
    Also, to add additional commentary to my answer: These days I put almost everything into version control, including source files for art, music, etc (pre-export). Anything that would make its way into the final product. Having versioning for art is great. (I'd probably draw the line at video that isn't actually going to ship with the product -- a trailer, for example, might be safely be considered a separate project.) – Andrew Russell Aug 10 '20 at 03:29
  • what VCS do you use? – Konrad Aug 10 '20 at 09:10
9

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.

moonshadow
  • 201
  • 1
  • 5
  • 2
    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 08 '10 at 20:35
8

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.

Unsigner
  • 81
  • 1