The difference between success and failure in outsourcing can come down to documentation. Effective and thorough documentation is absolutely the most important component of outsourcing, even more than finding good people! You can have the best artists in the world at your disposal, but if they have no guidelines, insufficient direction and bad documentation, you’ll be lucky to get good results from them.

Documentation is your first line of risk mitigation. Know your pipeline in and out, backward and forward. A prerequisite to outsourcing is knowing your own engine, your project, and can explain every step of the pipeline in detail to someone that’s never seen your project before. If you can’t do that, you are not ready to outsource. Period.

Unless you define the scope of the work so rigidly that there is minimal room for error, you will waste time and money, and your project will suffer. Every minute you spend writing good documentation now will save you ten minutes later.

I go further with this than most, so I urge you to soldier on, because there’s some real meat in here. 🙂

The Contractor’s Disadvantage #1: No Institutional Knowledge

The first reason for good documentation is that contractors are inherently at an enormous disadvantage compared to an inhouse game developer. Game developers in a studio environment rely on collective institutional knowledge built up over time to do their job every day.

Here are examples of “collective institutional knowledge:”

• That thing that guy said that time about how the exporter functions
• Using that neat 3DSMAX plugin you found for UV mapping
• Remembering where to download that rigging tools MEL script
• Knowing which programmer to ask about how this tool works again

My point is that you have a network of collective institutional knowledge to lean on if you don’t know what to do. There are many potential points of contact to help you solve problems you’re having. This is very easy to take for granted, especially if you’re not very close to the actual development process.

What should be obvious by now is that external artists don’t have that network! This is often forgotten because the inhouse artists you deal with every day already know all this. Contractors rely on you and you alone to provide them every snippet of information you take for granted so they can do their jobs.

The Contractor’s Disadvantage #2: Unfamiliarity with Games

The second reason for good documentation is that many artists that work at art studios have never worked at a game development studio. They typically don’t have the practical development knowledge and methodologies earned through hands-on development experience. They may not know how game-ready usable assets work. They also may have some key knowledge deficiencies that could result in getting some truly perplexing and unusable art assets back from the art studio.

Examples of “practical development knowledge and methodologies” off the top of my head include:

• Knowing how to bake a normal map properly
• Building character models to deform correctly
• Effective UV mapping techniques (particularly for tiling pieces)
• Knowing what does and doesn’t go into a diffusecolor map on a next-gen game
• Simply knowing how to build assets efficiently and with a minimum of waste.

This type of knowledge comes primarily from the trial and error of putting an art asset into the game on your own. You make the asset, put it in the game, see the problems, then tweak it until it works. Art studios are very rarely involved in that process. Most of the time they’ll never know if there’s something they could do better, or if they’re doing it entirely wrong!

Identifying a common timesink in contracting

A problem I often see is that game developers frequently accept errors like this as “just one of those quirks with working with outsourcing” and never mention it to the art studio. What a mistake!

My philosophy is that an art studio is only as effective as you allow them to be. Letting things like this slide and spending time fixing it yourself every time is a waste of your time. It’s simple math:

1. Spend 10 minutes of your time per asset fixing 100 assets. Result: 10 minutes * 100 = 16.67 hours = 2 days of work, OR
2. Spend 10 minutes of your time on documentation explaining how they can fix it and sending them that document. Result: 10 minutes total.

The problem with thinking “It’ll take only a minute to fix it” is that it’s not always a one-off expenditure of time. Over time it adds up to a lot of wasted effort. Remember: Your time is also money, and the more of it you spend doing work you can delegate, the more expensive outsourcing is. It really can be self-defeating.

Identifying areas of concern like this and addressing them in the documentation before the problems happen can make the art studio much more effective and free up your time to spend elsewhere. Remember: they have no way of knowing what to do to make sure it works if you don’t tell them!

Granted, this isn’t as big a concern for simpler assets like props and environment pieces. Complex animated models like characters or interactive objects, however, are typically much trickier to develop and implement, and that is not a part of your process you want handed over to someone without a lot of preparation.

The Contractor’s Disadvantage #3: Overseas studios

The risk of this lack of practical development experience is much more likely to be the case overseas, particularly in China and India. I’m going to make some fairly broad generalizations below, so bear in mind that there are individual exceptions, but these are useful to keep in mind when shopping overseas.

I find that there are more people on this side of the pond that want to work on games and have some rudimentary knowledge of how that works. Americans and Europeans, in my experience, are more likely to create their own user-made game modifications or trying to develop their own games for fun. Practical game development knowledge can be gained from activities like this, and finding people with this experience can be a blessing.

It’s increasingly common to see game developers in the US and Europe quit their game development jobs to become full-time contract artists. It can be lucrative and the most talented, effective contractors can make a great living for themselves. The practical development experience they’ve gained in their career prior to this makes them more valuable because they can avoid mistakes in developing art that inexperienced developers wouldn’t know.

However, in countries like India and China, art studios staff up their studios by mass recruitment from art schools. Some even develop their own internal art school or training program to vet, test, train and hire new artists. That’s fine, and even admirable, but they’re limited by what may be a generalized formal education with little to no specialization in game development. There are only a handful of schools in the world that teach game development competently and competitively, and I don’t personally know of any outside of the United States or Canada that do this.

The Contractor’s Disadvantage #4: Inexperienced management

Worse still, inexperience with game development can be an issue at the management level as well as in the trenches. Management at the art studios may not know what questions to ask when bidding on a project that a seasoned developer would. This can create nasty time crunches down the road when you least expect it, because they simply didn’t visualize the process clearly enough to foresee potential problems.

Sadly, this is all a breeding ground for unfamiliarity with games at the management level and at the artist level. You could get art that looks great but is totally unusable. This requires a large amount of rework from your internal artists, or a complete do-over.

When this happens, you lose all the cost benefits of outsourcing. You’re paying salaried employees to rework assets that were already paid for! You’re paying at least double the cost per asset than you need to. This happens more often than developers care to admit. In fact, I’ll bet this is why many developers are disappointed by outsourcing. This risk can be minimized through planning and preparation with thorough, complete documentation.

How much time does this take?

Preparing everything is obviously important, but you must wonder how long it all takes. I won’t beat around the bush – it does take time. But what you may not realize is that this is essentially a one-time expenditure of effort. It happens before the contract begins, so you don’t waste any time when the art assets are in development.

You will waste immense amounts of time if you explain everything to every new artist you bring onto the project. You just want the guy to make art, not tie you up asking questions all day! You should expect them to be confused when they first begin.

The best way to buffer against these delays is to generate thorough and solid documentation before you speak to a contractor. It’s not only the best way to prepare for contingencies before the relationship begins, but it shows them that you’re professional, thorough, meticulous and well-prepared.

The well-organized manager has explicit expectations, and the people they manage take their work more seriously when the instructions they receive are not sloppy. Your contractors will know from the first moment of contact that you know what you’re doing and that you’re the boss. It’s your job to lead, so show you’re a leader in everything you do and say. If you don’t know what you’re doing or what you’re looking for, neither will they, and you won’t get acceptable results.

I have a theory about effective communication I’ll share that will help you with documentation. This is my favorite part of this article, and what you’re least likely to have seen written about anywhere else.

All information creates its own context

When writing documentation, never make assumptions. Even if it seems painfully obvious, every piece of information should create its own context and be totally self-encapsulated. Whenever possible, information should not be dependent on anything other than itself.

• When I read Document A, I shouldn’t need documents B, C and D for document A to make sense.
• I shouldn’t EVER wonder what “that” or “he” or “she” or “they” are referring to. This is very important and very hard to remember to do.
• I shouldn’t have to go talk to Ted the programmer about it.
• I shouldn’t need to remember that vertex weight influences less than 10% are stripped on export but that isn’t in the documentation for some reason.

Everything relevant should be in one place. You would not believe the amount of time this ultimately saves. If the contractor has a question about something and you’re not available, one of two things happens: Production STOPS, or he GUESSES. Both of those cost you time and money. Leave no stone unturned and leave nothing to chance.

Here are examples on how to write well:

BAD:

• “Please take the attached model and apply the jungle texture. After it’s applied, rig it with the Large Creature skeleton and export it. See attached image.”

GOOD:

• “Please take the Heavy Orc model (HeavyOrc_final.max) and apply the Heavy Orc Jungle texture (HeavyOrc_Jungle.tga).

  After the HeavyOrc _Jungle.tga texture is applied to the Heavy Orc model, rig the Heavy Orc model with the Large Creature skeleton (projectpath://Skeletons/LargeCreatureSkeleton_Base.max) and export it to the Heavy Orc directory (projectpath://Creatures/Large/HeavyOrc/).

  See the attached image (HeavyOrc_Example.jpg) for reference.”

These are points at which a contractor could become easily confused. In the first example, there is virtually no context to anything. Here are the points of confusion:

1. What attached model? I didn’t get a model. OR Which model? I got two.
2. I didn’t get a jungle texture. Is [this filename] meant to be the jungle texture? Or this one? They both look jungle-y.
3. Where is the Large Creature skeleton located? Did I get that?
4. What directory do I export to? Do I make something up or did you have a place that needs to go already?
5. “See attached image.” What attached image? I didn’t get one. OR there are five attached images. OR was that included in another email? Do I have the latest image?

Note closely the way I wrote the “Good” example above: each sentence retains its meaning, even if it’s broken off by itself and removed from the context of the paragraph!

To add to the confusion, let’s say the artist’s manager only copies and pastes part of that instruction to him, and the images aren’t attached to the email he sends to the artist. The manager already knows how this works, but doesn’t realize that the artist working for him does not. Not including clear information that creates its own context wastes time here by requiring the artist to ask the manager what to do and how to do it. He could already be hard at work simply doing his job, but he’s not, because the information doesn’t create its own context and it isn’t clear what he needs to do.

I make sure that all documentation I write is structured this way, then edited to be as readable as possible. It’s a very specific and challenging discipline to constantly ask yourself as you write “Would this make sense all by itself? What information would they need added for this to make sense on its own?”

That’s all I have to say on the subject of how to write effective documentation for outsourcing art. I have other articles coming soon explaining how and why to create an Art Outsourcing Kit using this style of documentation-writing and how it can help you manage contractors more effectively, ramp them up faster and mitigate the risks of outsourcing even further.