🔒 Locked

Asset management

Started by DaBono Jul 29, 2007 at 5:16 AM 2 replies 1.2k views

Original Post

Jul 29, 2007 at 5:16 AM

I'm looking for some advise on asset management (so, levels, textures, sounds etc.). Currently, we're storing all assets in the same Subversion-repository as the source code, but checkouts are taking longer and longer and the repository balloons out of proportion. The 'sources' of the assets (the .max and .psd-files) are stored on a simple file server, making it hard to go back to older versions. We were considering to, at least, put the assets in another repository, using svn:externals to include the correct assets. And to prune the asset-repository, so that old versions are stored for about two months. So, how do others go about this? Do you use a SCM-system for your assets, like SVN, Perforce or Alienbrain? Do artists store their .max and .psd-files in that repository, and how does that scale wrt. off-site backups?

ldeej

Jul 30, 2007 at 7:57 PM

we use a perforce type of system (proprietary), which has a folder for the raw data:

root
raw_data game_data code

so artist map raw_data which has their max files, psds, etc
game_data is a mirror structure of raw_data, but contains game friendly data

Artists import game data from raw data (i.e. from .max to .level, or from .max to .model)

This way we can manage the raw data differently from the game_data, the game only needs game_data to run which is usually not as heavy as the raw data, and we can map the stuff that we need to run, not everybody needs the whole raw_data folder, and they do not need everything inside raw_data, so we manage the complexity by allowing people to restrict their mappings to the repository.

LorenzoGatti

Aug 2, 2007 at 4:29 AM

Quote:
Original post by DaBono
I'm looking for some advise on asset management (so, levels, textures, sounds etc.).
Currently, we're storing all assets in the same Subversion-repository as the source code, but checkouts are taking longer and longer and the repository balloons out of proportion. The 'sources' of the assets (the .max and .psd-files) are stored on a simple file server, making it hard to go back to older versions.

This is the opposite of good configuration management: the editable sources should be under version control along with code, while the bulky exported products can be regenerated at will and need not be versioned unless convenient.
The issue is of course tied with how you build the project. Do you have an automated system that regenerates all assets from source graphics, or are some of them exported by hand from interactive tools? In the latter case, putting them into version control to replace a tedious operation with a checkout is better than nothing.
Do you need a full checkout to make a build? Can't you replace only the few files that changed?

Silver Phoenix

Aug 2, 2007 at 4:45 AM

I agree with LorenzoGatti.

Also, have you considered using several repositories stored at the same location? One repository for each "block" of source code (module, dll, exe), one for game data (pictures, models, textures) and so on.

Most likely some assets are unrelated or even disjoint, so they shouldn't be versioned at the same repository.

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.