Introduction
If your project’s artists have to open Visual Studio to work, you’ve failed them. If they have to come to you to get every piece of art implemented, you’ve failed them worse.

The primary driving motivator behind every engineering decision I’ve made for Iron Heinrich is thus: I want to allow the artist (Nate) to do awesome things. Each barrier in his way is a high priority for me.

There are plenty of barriers, and we’re working on addressing a lot of them. The purpose of this post in particular is the art build system. The system set in place so that when an artist does something, after he’s modified the data, he can see everything running.

The Goals
The current XNA content workflow is pretty much the following:
(1) Start Visual Studio
(2) Add your content to the Content project
(3) Set any necessary importers or content processors
(4) Build and wonder why you got all those errors
(5) Fix up those errors
(6) Build and run

Which isn’t particularly good for an artist. It’s cumbersome. It’s error-pone. It requires technical knowledge. Here’s the ideal:
(1) Build and run.

A lofty goal, but can it be done? It’s not entirely trivial, but I do believe it can.

Changing the Art Build Step
The first thing we need to do is take Visual Studio out of the equation. Artists shouldn’t need to know about IDEs or content projects or importers. Artists should be able to double-click on a file and watch it go. This is an art build step, and a good art build step hides all the ugly details from the artist.

How is this done with XNA? Here’s an outline of the current process we’re using now:
(1) The Content directory is crawled by a program. Each file is evaluated against an Art Manifest which details how that file should get built. The artist doesn’t need to know about the Art Manifest.

(2) Based on the above, a new Content project file gets generated that the XNA build system can interpret. This file is actually a mashup of a Template file (which contains all the standard stuff that goes in a Content project) and the new data determined by the crawler/manifest.

(3) msbuild is run on the new Content project, which performs the necessary art build.

All this is fairly simple. The trick is in the details - the details specified by the Art Manifest.

The Art Manifest
Each type of file has a few things associated with it:
(1) An importer & exporter
(2) An asset name
(3) Various parameters

It’s not enough to specify these once per file type and be done with it. That would lead to a broken build within minutes. Consider:

Level1.x is a level file. It uses an exporter that spits out its vertices for collision purposes.
Char1.x is a character. It uses an exporter that spits out a skeleton for animation.

The same “type” of file, but they meet radically different requirements. The art system has to manage that.

The Iron Heinrich build system specifies a hierarchy, where each part of the hierarchy takes precedence over the previous:
(1) Default (Per File Type) - If a file of this type is encountered, this is how it will be built by default

(2) Group (Per Directory) - Build information can be set at the directory level such that if a file is in the directory, the ‘Default’ no longer applies. For instance, all levels may go in a group “Levels” and will be built specially.

(3) Override (Per File) - Specific files have specific requirements regardless of where they are.

(4) Ignore (Per File) - Sometimes you just don’t want a file in the Content directory to get built. For example, we definitely want the crawler to ignore Content.contentproj.

I as a programmer handle that - I setup the manifest, specify the importers, exporters, etc, and the artist almost never has to worry about it. Sometimes he may need to add something to the Ignore list or even the Override list, but 99% of the time he just puts his assets in place, executes a script, and runs the program.

Final Thoughts
The system isn’t perfect. Some errors will still require some technical knowledge, and the manifest is more cumbersome to make small changes to than settings within Visual Studio. Comparatively, though, I think it allows for a much smoother workflow, which is vital to artists.

This is all overkill for small projects, but for larger projects (and especially projects which are largely data driven), it can be pretty helpful. It also sets up the framework for a rapid iteration scheme which I’ll talk about… if/when I ever implement it.

Not nearly as complex as some of the build systems I’ve worked with.