# How to separate production and test assets during development?

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.

• very nice solution, simples and effective. Thanks! – bcsanches Jan 10 '11 at 17:57

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 know that this is not the main purpouse of branches ... – Notabene Jan 10 '11 at 12:14
• we use mercurial, but I do not like the idea of using branches for that. – bcsanches Jan 10 '11 at 12:56
• I feel that is a perfectly acceptable use of branches. – Nate Jan 10 '11 at 15:35
• Branching for release is a fine use of branches, but it doesn't really solve the problem - you still need some way to identify the things to remove from / not include in the release branch. – user744 Jan 10 '11 at 19:13

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.

• With this kind of system it's very easy to beat your head on the wall for an hour trying to fix something and not realize your changes aren't working because someone else checked something into an overlay. Likewise, it's easy to check something into the "underlay" that works fine with its data set, but breaks one of the overlays. It also leaves open the question of what overrides what - if production overrides development, then development is kind of worthless - if development overrides production then you end up with heisenbugs. – user744 Jan 10 '11 at 19:18
• Agreed -- but it's also easy enough to provide debugging aids to understand where content is coming from in the game itself and train developers to use them. What is, admittedly, not so easy, is preventing the system from being overused: it becomes very problematic if you end up with a large number of packages so you want to make sure that everybody isn't making six or seven packages for all their little features, et cetera. – Josh Jan 10 '11 at 19:39
• Well, that's if you remember to use the debugging aids. I think it's just far too big a hammer to use for such a simple problem. We used a system like this in conjunction with the system I described in my answer, but for a different purpose - separating data sets for different games - and it was just always getting in the way of something. I don't know a better way to solve the (maybe intractable) "multiple games, same codebase" problem, but I do think we had a much better way to solve the simpler problem the question is about. – user744 Jan 10 '11 at 20:06