this is like a complement for Assets Management, database or versioning system?.
I am wondering about how to separate development, specially programmers assets from production assets?
For example, if we keep all the assets on the same repository, how do you keep with programmers assets and final game assets? Do you keep a separate directory for each of those, allowing duplicates? Or do you use some fancy scheme for striping out the "development" and "test" assets from final build?
At my last job we prefaced everything that was development-only with _, and the support for that convention ran into the lowest levels of our filesystem handling code in the game, like directory listing and our file opening wrappers. Test and development-only assets were just checked into the same RCS repository as the real game data.
So for example,
# This is always loaded
data/texture_library/titlescreen.tex
data/spells/magicmissile.spell
# These are only loaded in development mode.
data/texture_library/_foo.tex
data/spells/_testmissile.spell
data/spells/_testing/fireball.spell
It's a very simple convention, but was easy to use with other tools (grep, one-off Perl scripts, etc.), and straightforward for everyone on the project to understand.
We tend to keep all of our test assets in a 'test' folder which get stripped out when making final releases of our games. These folders can be broken down by person (which is what we do) or perhaps asset type, or both. Once benefit that we've gotten is that we can use perforce exclusionary mappings to allow people to remove folders (inside of 'test') that they don't want to look at.
To do this method right though, does requires some planning and adherence to the scheme on the part of the development team. This type (or any type) of organization can be hard as you scale up the number of members on your team. I guess the advice here is that no matter what scheme you pick, make sure that your team members follow it, otherwise, it will break down in ways that can be pretty irritating. For example, the scheme that involves prefacing files with an underscore sounds workable. But in practice, it also seems easy for someone to forget this convention (either way) and then you wind up with missing or extra assets (the latter typically being less of a problem). Again, these problems can happen with any scheme, so it's worthwhile to have it documented and drilled into your team's collective head.
If i understand well. In my team we use SVN. If you didn't know, you can also create branches in SVN. So it is simple. We create branch for every release we do. Then we have releases untouched and marked in same system we are using.
I like to take an approach where content is organized into 'packages' with the content root, and packages can be scheduled into the production build (in order) via some kind of manifest.
The simplest implementation of this technique is a flat-file one, where you have an asset directory which subdirectories for each package. Each package subdirectory contains assets, possibly in a fixed tree form (such as all the models in a 'model' folder).
The manifest simply contains an ordered list of packages to apply to a build -- packages applied later override those applied earlier. The manifest for dev builds includes the packages for developer-only stuff, and the manifest for live builds doesn't.
Obviously you can scale this out to an arbitrary complexity, supporting things like efficient fallbacks for missing resources if you forget to schedule in a package, or emitting warnings, et cetera. The system lends itself well a local 'override' directory, too, allowing for quick asset iteration.
This approach is orthogonal to the SCM package used, so you don't necessarily need a branch per package or anything like that.
