Site menu:

Home | Most popular smArticles | smArtist Reading | Archives | Blogroll | About Jon | Contact Jon

smArt Management

Archived Posts from this Category

smArt Management26 Nov 2009 06:04 pm

The Art of Documenting Art

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 diffuse\color 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.

Comments (5)
Interesting links& smArt Management& smArtist thoughts31 Mar 2009 03:05 pm

Productivity tip #14: Lookout – hyperfast indexed search in Outlook

Here is my FAVORITE Outlook tool. It’s lightning fast indexed search that beats the pants off anything Microsoft has. Microsoft liked it so much, in fact, that they purchased the company, then killed the project completely. This paved the way for their horrible and criminally useless Desktop Search without any pesky competition to get in the way. Hooray!

Anyway, Lookout is the best email search tool ever devised. You can download Lookout here:

http://majorgeeks.com/Lookout_d4808.html

And if you’re using Outlook 2007, follow these VERY simple instructions to make it work:

http://www.belshe.com/2007/12/06/how-to-install-lookout-on-outlook-2007/

Once you have tons of email, you’ll see why this rules so much. :) The flexibility, speed and ease of use is astounding. To give you a brief comparison, I spent about an hour trying to figure out how to make Microsoft Desktop Search manually index my email. After I figured that out, it took 30 hours to index fully. Within 30 minutes of installing Lookout, everything was set up and fully indexed. Lookout’s search is also ridiculously faster and easier to use. It’s the first thing I install with any new Outlook installation. Enjoy!

Anyone have any other handy Outlook plugins? I’ve been meaning to do a post on Xobni as well…

Comments (2)
smArt Management& smArtist thoughts23 Feb 2009 02:33 pm

Tip for smArtists: Making sure you get paid on time

Artists: Getting paid is important. If it’s a small studio, they simply may forget to mail off a check in a timely manner. That sucks. It’s usually not intentional. They got the art, which is all they wanted, so they’ve probably moved onto working on something else and aren’t thinking about it anymore.

One way you can counteract this is by setting an expectation as early as possible about when you’ll receive payment after submitting an invoice. If they don’t have a date in their head that you need to expect to be paid by, it’s more likely to slip their mind.

See, if you’re working with inexperienced clients, having a set of expectations you can subtly impress upon them can help give them cues on how to think and act. Here’s an example:

You: “Hey, when I submit my first invoice, what’s a reasonable timeframe to expect the check to be sent to me?”
Them: “Oh. A week or so after the invoice, probably.”

And when you submit the invoice, reiterate it:

“Okay, here’s my invoice. Based on our initial conversation about turnaround time on an invoice, you said to expect about 7 days. Is it reasonable to expect a check on or around [specific date]?”

Everybody trains everybody in their own way. :) If you make your expectations clear and are polite and respectful about it, you’ll make sure your business gets taken care of and they learn how to deal with people more effectively and respectfully.

Managers: One additional way to treat your artists well is to tell them in advance exactly when they’ll get paid after invoicing you, and remind them again when they invoice. Setting and meeting expectations is good business. :)

No Comments Yet
smArt Management08 Feb 2009 04:21 pm

Speccing out contracts smArtly! aka, Automatically Building Awesome Teams

Another big post this weekend! I’ll explain how I spec out a contract, divide the work into meaningful divisions, and how I handle asset revisions. I’ll even explain a bit of the psychology behind it that helps me automatically build kickass, super-talented external art teams. :)

My typical approach to pricing something out — especially tricky and difficult-to-quantify work — works pretty much like this:

1) Provide a highly accurate initial spec, but keep cost flexible.

Explain and detail all the work in advance as much as possible. Setting initial expectations early is important for all future negotiation, for more reasons than you might think.

Always leave flexibility on cost on the table. Let the contractor know that you’ll adjust prices up or down depending on how the first batch of work goes. If it’s harder, negotiate the price upward. If it’s simpler, negotiate it downward. Being open, candid and fair in the beginning of the negotiation process pays off down the road, and by the end of this post you’ll see why. :)

Ultimately, it gives both of you an opportunity to show the other that you’re interested in offering fair value for fair value, and that you’re not going to get everything you can out of the other guy for as long as he’ll tolerate it. This emphasizes transparency and helps build trust. Being candid and fair like this strongly encourages reciprocation, and you’ll quickly weed out vendors that aren’t worth working with if you take this tack up front.

2) Divide the work into as few meaningful divisions as possible.

Typically I’ll divide this down by asset type, and then by difficulty. There’s a kind of art to it beyond that, though. I don’t like dividing or categorizing anything too much, because at a certain point it become too granular to organize efficiently. Too big, and it feels to both parties like nothing ever actually gets done. A division should only be as large as it makes sense.

If I’m outsourcing a full character, I try to keep each chunk fairly flexible. I’ll price out the individual cost of the model, the texture, and the rig and make that precise, then I’ll add those three numbers together, round up to the nearest hundred or so, and that’s the cost of one average Character. It leaves wiggle room for small variations.

For example, say it needs 100 more polygons or if it doesn’t need that 64×64 texture. No big deal, no renegotiation needed. It all averages out. I’ve gotten stuck in the trap of suddenly needing to renegotiate for a 512×256 instead of a 512×512 texture in the middle of working on a single character because I had each stage priced out differently, and that sucks. If the difference is substantial, then sure, you’ll renegotiate. But don’t sweat the small stuff, and price out the work accordingly.

Remember: Your goal is to keep the new art rolling in, not spend all your time figuring out how much to pay for each Space Marine’s toenail.

When the workload is less discrete than “one character,” I’ve had great results by dividing each chunk of work into 1 to 2 day segments on a contract that’s invoiceable every two weeks. Contractors all love accomplishing something every day or so, and having a regular bi-weekly payday. Morale stays high and they keep cranking out results consistently and without getting bored. This is my favorite sweet spot.

Which leads me into two more very important considerations: ease of amending the contract, and ease of invoicing. If you broke it down into reasonably modular chunks, it’ll be easy to add on extra work to an existing contract without mid-stream renegotiation. Example: “Okay, turns out we need 3 more Weapons and 2 more Helmets. Let’s slap that onto the contract.”

However, if you priced it out as one large block or added some type of strange and arbitrary division in the middle of a piece of work, billing and invoicing gets complicated. You don’t know how to amend the contract to add or remove more work, so you have to put on the brakes in the middle of production to figure out what the hell to do.

BUT, if you show initial goodwill and flexibility and divide the work meaningfully, this is a nonissue and production keeps moving smoothly. Essentially, you’re frontloading all the serious negotiation so you don’t waste time midway through the contract trying to figure out how to price additional work. This really saves enormous amounts of time later if the workload increases or decreases, or if the contract is split up into separate invoiceable segments.

3) Roll a preset revision number into the per-asset cost, then price out extra revisions as a separate percentage of that.

Defining an acceptable number of revisions in the beginning of a contract is crucial. I like the number three as a safe buffer built into the cost of each individual asset or chunk of work. If more than three revisions are needed, I’ll pay an agreed-upon percentage. If 50% of the asset has to be reworked, I’ll pay 50% of the cost of the original asset. If 25%, then 25%. If the asset has to be COMPLETELY redone, however, that’s a different issue. I *always* include provisions detailing when a “revision” turns into a completely new asset, and who eats the cost of that rework. I’ll explain…

Iterations are ultimately a useful metric for determining whether process improvements need to be made. If I spec things out properly, explain them well, and I pick the right contractors, I shouldn’t need to revise anything more than twice. Period. If I’ve failed to spec something out well and that creates extra revisions beyond what we’ve specified initially, I’ll revise the spec, then pay the contractor the agreed-upon amount of rework, and I eat the cost of my mistake. If I suck, why should my contractor have to pay for it? They did exactly what I asked, nothing more.

Think of it like this: Imagine your boss comes to your desk at your salaried job and tells you “Yeah, you did all that work I asked you for, but I actually don’t know what I want, and I still don’t, but I’m not going to pay you this month.” A *lot* of managers treat external artists this way and see nothing wrong with it. Don’t be that guy.

Contrariwise, if my spec is good and it’s simply the contractor that’s sucking, it’s up to them to give me what I want and eat the cost. They’re not living up to their end of the bargain, which we agreed upon before we even started work. This is exactly why I preach cost flexibility and transparency up-front: it makes people more honest, less defensive and more willing to admit that they made a mistake. If they take any pride in their work and if they value my business, they’ll make it up to me. If we can’t reach a result we both agree upon, then I cut the contract short, pay them for all the completed work up to that point, half the cost of the asset they failed me on, and then I go find a new vendor.

Speccing and negotiation is actually my favorite part of the outsourcing process, because it clears away all ambiguity, it speeds up production and every stage of it is an instant and binary vetting process! If you draw them into your framework of honesty, candor, transparency and specific predetermined expectations, any deviation from that will be immediately obvious to both parties. When that happens, the only possible responses are 1) fix it or 2) break it off. There’s no ambiguity, there’s no guesswork and there’s no drama.

That’s the beautiful thing about it: Only winners and worthwhile people will be able to continue working with you. The people that aren’t essentially disqualify themselves as time goes on. And it all happens automatically, because the conditions of working with you are so transparent, open and clear that you’re never left wondering what to do when a problem arises. The key is to maintain a healthy level of self-reflection and be willing to admit that you’re wrong if you made a mistake.

If you operate by those rules long enough, everyone that isn’t worthy gets replaced and you’ll find yourself only working with extremely talented people of high moral character… automatically. :)

Questions, comments and criticisms welcome as always!

Comments (11)
smArt Management07 Feb 2009 03:35 pm

Outsourcing Animation Isn’t Scary: A Guide

I often run across questions people ask regarding outsourcing animation. I seem to be one of the few people that has outsourced animation successfully. I’ve written a handful of short articles on the subject, but I thought it was time I edited and assembled them all into one handy guide. :)

I won’t dwell on the philosophical question of whether to outsource animation or not. If you’re reading this guide, it’s probably because you have X animators and need X * 4 animators, but don’t have the budget to hire inhouse. Let’s move on instead to the first practical considerations.

What do you need before you find a studio? Direction, documentation and reference.

Ask yourself: How much initial direction can I give? i.e. everything is predefined in advance, the ideas and expectations are set in stone and can be clearly communicated to the contractor, OR you intend to leave it up to the animator to figure out. If the latter is the case, do not outsource. Pick a direction, define it, build consensus, set the ideas in stone, and THEN outsource.

Internal ambiguity, indecision, and aimlessness is your problem, not the contractor’s. If you’re going to make it their problem, let them know up front, then pay them more for the time you spend spinning your wheels.

You need to be prepared enough to answer every question before it can be asked! Being specific up-front is paramount. That’s why you need to create an all-encompassing Animation Outsourcing Kit to contain all the documentation and reference your contract animators will need, and then a Specific Assignment with the details on the job you want the contractor to do.

1) Assemble documentation.

The idea behind an Animation Outsourcing Kit is that to have one single ZIP file that contains everything a new contractor needs to get started on animation. Direction, documentation, reference, tools, etc. It doesn’t have any assignment-specific information; that comes separately in what I’ll arbitrarily dub the Specific Assignment.

Now, when I’m writing documentation for any kind of outsourced work, I go through the entire process myself step by step and detail everything as I go instead of recalling it from memory. Why? I always forget something or realize “hey, that’s not something they would necessarily know unless they worked with this particular toolset.”

Even if it’s blindingly obvious such as the animation package you’re using, include it somewhere. If you learned something from a previous feedback iteration that you should have included in the first draft, update the documentation to include that, and send it back to the contractors, even if you’re working with the same one. What if they swap animators and you don’t know, and they miss it again? Documentation doesn’t have to be a big ugly mess that I have to sit down for hours and do… it can be incremental. After all, why answer the same question more than once? Documentation must always evolve!

When writing the documentation, never assume assumptions. :) Even if it seems anal, every piece of information should create its own context and be totally self-encapsulated. Something obvious to the writer and studio may not be obvious to the person that’ll eventually be reading it, or the person that is ultimately working on it. Documentation like this is essentially a game of telephone, and the win condition is trying to transmit your original message with as much clarity as possible to the other end despite the number of intermediary connections (translation being one of them).

So that leads to the question — what does one put in an Animation Outsourcing Kit? The answer: everything a contractor need to be able to do his job. Naturally, that’s a big list, so I’ll give an example list of everything I put into my Animation Outsourcing Kit. First, the Documentation:

  • Technical specifications. For each asset type in my game, there is a guidelines document with detailed technical specifications. Animation framerate (30?), average sequence length (2s\60 frames, 5s\180 frames?), MAX or Maya, Skin or Physique, bone count limit, vertex influence limit, etc.
  • Overview of the animation work:
    • Style of animation. (realistic, cartoony, cartoony realism?)
    • Type of sequences. (Run, walk, jump, attack, pain, etc)
    • Is the contract animator creating the skeleton himself or is it being done inhouse first?
    • Is the contract animator handling the rigging and character setup, or is it being done inhouse first?
    • Who integrates the animation? (Are you going to handle all the game’s implementation inhouse or will the contractor? Depending on your desired level of risk, it may be easier to set up your contractors with a copy of the engine and the ability to export to the engine and test the animation.)
  • List of animations. Here I include a master list of the game’s animations divided by type: characters, creatures, animated objects, miscellaneous, etc. From that basic designation, I break each down into structured lists divided by their role in the game. For example, creatures are either Melee (hand-to-hand combat), Ranged (attack with guns or bows), and Caster (magic user). Each role has a unique animation set, so I list all the animations in each set.

    This is especially useful for when I want to create a new creature. Before I even outsource it I can say “Okay, Fat Ogre 3 is going to use the Melee and Ranged Animation Sets.” I don’t have to decide which animations it has one by one every time I want a new creature, because I already figured it out beforehand.

    Then when I send the Specific Assignment details to the animator, I can simply copy and paste those pre-made animation lists. Time savings ahoy!

  • Style guides. I include the style guides relevant to the race of creature he’ll be animating, so he can see the other members of that race, their size in relation to each other, and get a sense of their attitude.
  • Scale guide. I have a MAX file demonstrating the scale of the object in the world so the animator can get a better sense of scale and how to animate what it is I’m giving him.
  • The exporter. I include a copy of our proprietary 3DSMAX exporter plugin, along with simple installation and usage instructions.
  • The tools. I include a copy of our proprietary Model Editor, along with simple usage instructions so the animator can create usable assets for our engine. Why should I have to spend time fixing each asset myself later, when I can explain it once and pay him to do it instead?
  • FAQ. I’ve assembled a brief FAQ full of common questions I’ve been asked by my contractors. One very important note I’d like to make about the FAQ: It was a huge breakthrough to me to realize that every time I talk to one of my contractors to explain something or answer a question, I’m generating documentation. Everything I say is usable. So I just remember to write it down in one document, organize it, give it a coat of spit-shine, and my project is better documented. :)

2) Assemble reference.

The second part of the Animation Outsourcing Kit is the Reference:

  • Animation samples in the animation package. I have directories set aside that offer example animations of every sequence for each type of creature and animatable object. There’s a directory for the Melee Animation Set that has sample animations for every sequence in that set, and so on for everything else that needs an example. I *never* leave gaps in reference for things like this.
  • Animation sample AVIs. In addition to providing MAX or Maya animation reference files from your game, show an existing AVI sample (with a widely compatible codec, or include the codec in the contractor kit) of EVERY animation you expect to receive from the studio. Whether or not it’s a sample of something existing from your game, this should be a style target to hit. The crucial part here is to not only show them the reference, but also to explain what is good about each one.

Ideally, fire up Premiere or a video editing app and put captions in there. “Note that the windup here is powerful.” “This movement feels like the character has weight.” “The impact is very heavy and he really looks devastated by it.” Use plain language but be very specific. Never assume they’ll know what you like about each one.

At first, including both MAX and AVI samples of animation may seem redundant. Realistically, the animator is probably not going to look at all of these if he has the kit but no specific assignment. The reason to have all these included in the Animation Outsourcing Kit is so that when I create the Specific Assignment and assemble that information, I can pick and choose which animations to use as reference.

“For the idle animation, check out Fat_Ogre_Idle_04.max. For the attack animation, check out LOTR_Cavetroll_smash.AVI.”

That way, he’ll already have all the files he needs from the kit, instead of having to bloat up the Specific Assignment. :)

3) Assemble the Specific Assignment.

The Specific Assignment is intended to provide the information an animator needs to complete the job you’re assigning him. If the Animation Outsourcing Kit is the foundation, the Specific Assignment is the blueprint for the house.

List out the specific animations needed in the job you’re giving the contractor, and give a brief description of what happens in each animation, call out what frame it needs to happen on or by, and define the exact length. Even if you don’t have a specific length that it requires, I’d suggest making one simply so there’s a constraint there. Animation is really prickly, so limit your risks by leaving nothing up to chance.

Here are other questions that can be answered in the Specific Assignment:

  • How fast do you want it?
  • How will you be paying? (Paid per day, per hour, or per sequence?)
  • If per sequence, are revisions included in the flat rate or are they priced differently? Is there a maximum number of iterations?
  • Remote or on-site?

Since outsourcing animation can be tricky, I’d strongly suggest going with a studio that communicates very well in your native tongue (I’m assuming English) and also has a strong animation background to remove the difficulties caused by the language barrier. Running quickly through a typical animator’s glossary with them would be a good idea, to see if you speak the same language there as well. That’ll help down the road when you’re writing feedback. “What does follow-through mean?”

4) Ensure high quality with effective feedback.

I’ve been trying to come up with a simpler and easier way to structure my feedback on assets I receive that makes it easier for the contractor to focus on one aspect at a time, without being dependent on anything but plain text.

Most of my job is communicating ideas. And there are so many different ways to go about it that even the specific structure of the way you speak to someone can make the difference between doing it right and doing it wrong.

See, it’s easy to get lost in a lengthy changelist, or accidentally overlook a problem, or simply not know what I’m asking. It’s put a lot of pressure on me to learn how to communicate the most with the fewest words, and to arrange the data in such a way that certain parts of the feedback will pop out at them and really stick in their head.

In the example below, I’ve adopted a very specific, consistent structure for presenting feedback on art assets to my contractors. Right now, this is my formula:

Orok_Chieftain_Run_Animation_01 – Awesome! Great sense of weight.
– CHEST: Some vertices on his chest poke into his body. Can you fix the rig?
– FEET: His feet dip below the floor in frames 14-17 and 28-31. Can you bring them up?

In other words…

[Asset_Name] – [Brief Praise]
– [SPECIFIC LOCATION]: [Brief description of problem. Ask for specific fix?]

My reasoning is as follows:

  • [Asset_Name] – Obviously you’re going to want to specify which asset you’re commenting on.
  • [Brief Praise] – I generally try to say something nice and positive about everything I get. I never put anything negative here. If I have nothing good to say, I leave it blank. But I always start out with praise. Studio or contractor, I feel like this matters.
  • [SPECIFIC LOCATION] – This is the REALLY important part. An endless bullet list, even numbered, can be a bit much to look at. But if you can have an IMMEDIATE callout of the specific area that’s affected by the problem, it’ll be easier to go through the list of changes component by component. “Okay, chest, foot, leg.” Reference the specific filename of the screenshot \ paintover \ MAX reference with each part.

    When questioned, it’s a little easier to refer to areas specific to the asset itself instead of an arbitrary number that forces them to go back and look at the feedback list and remember what ‘3′ corresponded to. Granted, yeah, they should always have that available, but I have to look, too. :) Every bit of time savings I can squeeze out of something, I will.

  • [Brief description of problem. Ask for specific fix?] – The reason I describe it and end with a period, then ask the question, is because a question mark stands out in a sentence. They read the problem, and the proposed solution jumps out at them more readily than would a sea of periods. It also forces me to parse my thoughts very simply and clearly, which helps me. That, and I prefer coming off slightly nicer by asking a question instead of stating a list of demands. Sure, I’m paying them and I could be brusque if I want, but I personally prefer the softer touch unless I’m straightening someone out.

To provide extra information, I offer screengrabs of what’s wrong (if anything), and offer AVI or MAX file source art reference when available. Create a custom camera to highlight the problems at different frames and send them that MAX file as feedback if you need to be very precise, and detail that in the text. (“Switch to Camera 05 – Feedback Camera for frames 800 – 900 and observe vertices above the right knee…”)

Never let a single piece of feedback go unresolved in successive iterations or they’ll learn what they can get away with. This requires a lot of time and dedication by the outsourcing manager, but it ensures quality.

In doing all this, I generally had only 1 to 2 iteration passes per individual animation, which is pretty sweet. :)

I hope this guide proves helpful. Any questions, comments, criticisms or suggestions for improvements would be greatly appreciated!

Comments (2)
Interesting links& smArt Management& smArtist thoughts04 Feb 2009 02:01 pm

Tools of the Trade: HTTrack Website Copier!

Ever bookmark a website full of great information, only to revisit it later and discover the link is dead?

Worry no more! HTTrack Website Copier is here, and you need never fret over dead links again.

It’s a free, very easy-to-use, highly customizable tool that automatically downloads webpages in their entirety. You can set how deep you want them to follow links on the page, how to organize them on your hard drive, selectively include\exclude certain filetypes, and much, much more. And perhaps most usefully of all, you can customize how many connections to send at once and whether to cap the maximum download speed so you don’t hassle the server you’re accessing. It’s a very nifty, very clever little application that I’ve used for years.

In fact, I’m using it right now to back up an online copy of a beautiful Illustrated Architecture Dictionary, which has definitions for more architectural terms than I even knew existed. It’s fascinating and has been very educational. It’s the kind of site that I’d hate to lose access to… and with HTTrack Website Copier, now I won’t have to! Not to mention the speed bonus of having everything located locally, because that is a *LOT* of content to constantly be downloading and displaying.

Enjoy!

No Comments Yet
smArt Management& smArtist thoughts29 Jan 2009 03:08 pm

Random tip for finding good artists: Find their friends!

This may be outlandishly obvious, but for some reason it never occurred to me until this week. Here’s a tip for Art Managers and Artists both!

Art Managers, when I find a portfolio of an artist I like (even mildly), I go to his Links page and find a list of all the artists he links to, which are usually his friends or coworkers. I’ve been finding an absolute treasure trove of great artists I keep liking more and more. I don’t know why this didn’t occur to me sooner, but my oh my has this been fruitful. :)

So, Artists, in your websites and portfolios, link your friends! Get them to reciprocate! It’ll make you all a lot easier to find by chaining your sites together and giving hiring managers like me MULTIPLE paths to finding your portfolio. Remember, it’s all about accessibility and making yourself easier to be found. Get your name and your work out there.

No Comments Yet
smArt Management08 Jul 2008 10:22 am

Improving contractor feedback

I’ve been doing some thinking and experimenting with the way I structure contractor feedback and I have some slight tweaks I’d like to share. Here’s my new template:

[Absolute asset name] ([Iterative asset filename)]) – [Positive Feedback]
[Reference\paintover image filename]
- [Locational callout] – [Feedback]

Instead of using absolute asset names, I’ve been using the filename of the submitted asset. It’s been fine for tracking individual submitted asset names, but it doesn’t work well if they vary slightly from the asset’s true name. From now on I’m going to give each asset a rigid asset name, and then reference in parenthesis the name of the submitted file, AKA the iterative asset filename.

Example:

Mutant_Cave_Dweller (Mutant_Cave_Dweller_wip_05.jpg)

Furthermore, anytime I include a reference image, I’m going to call it out immediately below the absolute asset name and the iterative asset filename. Below that goes the feedback.

Example:

Mutant_Cave_Dweller (Mutant_Cave_Dweller_wip_05.jpg) – This looks great! I dig the gnarled knuckles and callouses on his hands.
- REFERENCE: Mutant_Cave_Dweller_leg_paintover.jpg
- LEG: Refer to Mutant_Cave_DWeller_leg_paintover.jpg to see the changes I made to the leg. Specifically…

This’ll make it easier to search through my feedback text files for the history of a single asset. Granted, I’d much rather have a centralized asset database that I can track all these through, because what I am doing could be streamlined further with a system like that. I’m still figuring out the best way to handle that on my own. For the scale of production I’m dealing with, though, I tend to avoid solutions that are more complex than the problem at hand. It’s easy to forget all the additional overhead required for the compliance with and maintenance of that system. :)

Thoughts, anyone?

No Comments Yet
smArt Management17 Jun 2008 03:06 pm

Project: Outsource Everything followup – SUCCESS!

This is a followup to my Project: Outsource Everything post, nearly a year later.

To be frank, almost everything I planned to do succeeded beyond my wildest dreams. :) Not without a few hitches and problems from which I learned much, but on the whole, my crazy notions were a complete success. It’s actually silly how well they’re going now. I’ll go through them point by point:

  • Armor Set Integration. I handed this off to the artist I had create my Creature Trees and he stepped up to the plate and started cranking all of these out and making them work in the game. An artist I had internally would check over and critique his work and make sure everything went smoothly. I did have a few problems with the way I priced all of this out, though.

    For complex operations like this, a per-asset rate is really a liability for the contractor, both for the time it takes on his end to test and iterate, but also for the time on our end to verify everything worked. In the contractor’s haste to get paid, a lot of problems cropped up he’d have noticed if he’d been paid for his time, so we ended up having a LOT of iteration passes (3 – 6 per set sometimes, and I prefer having a hard limit of 2 iterations per asset if I can help it) and built a backlog of 90% complete armor sets that were a pain in the ass to test and finish off.

    I solved this by moving him over to a flat daily rate where he actually took the time to really dig into the armor sets, fix a lot of problems he wouldn’t have before because he was in a hurry to get paid (no telling if a set would take a day or two weeks to final), and the number of iteration passes is getting lower and lower and we’ve finally hit a nice groove with it.

  • Give them Perforce \ Find a dedicated bugfixer. I have one contractor (the same guy as above) hooked into Perforce now, as well as our internal bug database. The first thing I gave him to do was work through the project’s entire backlog of art bugs and paid him a flat daily rate to do it. This guy is uniquely motivated to crank out as much stuff as possible and be hyperproductive at all times, so this was perfect personality fit. He fixed virtually every outstanding bug we’d ever had in about three weeks, and checked everything right into Perforce with minimal issues.

    Additionally, I gave him his own account in the bug database and started encouraging the team to start noticing all the outstanding little art glitches and bugs they’d normally filter out and ignore and to assign them to this guy. After awhile, you get used to seeing something ugly or broken, and you don’t even bother mentioning it because you know it’ll never be fixed. That is no longer the case because We Have A Guy For That. :)

    All the low-priority bugs (small clipping issues, etc) he would fix and check in without checking with me. All the medium and high priority bugs I went through and explained the solutions to and told him to reassign them to me to check his work before committing all the changes. This has worked out extremely well. Pricing this out per day was also crucial in making it economical and efficient.

    It was a nice little morale boost for the team to see things that were broken forever suddenly start working properly. Whenever possible, I seek high-value, high-visibility, morale-building tasks that’ll make the team feel like everything’s moving forward. A lot of my job is invisible to them in terms of management, organization, structure, etc, so it’s good for them and me when I can come in and show them concretely that their needs are being met and that Cool Stuff Happens.

    (man, I still can’t believe I outsourced bugfixing. :)

  • Ramping up dedicated world-builders. I finally have a studio starting work on our environment art content with a clear path ahead to start expanding the scope of the assets they work on as they familiarize themselves with our terrain system. Woot!

  • Drop in world integrators. We hired a technical artist inhouse that’s handling this, actually, so that’s been delegated fully. He’s going to be looped into the feedback forums we’re setting up with the dedicated world-builders to help see everything through to completion.

  • The only thing I didn’t do was find a standards enforcer, which is really quite ambitious and has horrifying, far-reaching implications that I don’t want to mess with since we’re a live game. Maybe if he was inhouse I’d think about it, but that’s such a Herculean task that can make everything blow up that I’m abandoning that idea entirely.

    You know, it was pretty cool to go back, read that post, and find out everything I did totally, completely, fully worked. Quite a nice confidence-booster. :) I have a few ideas for what’s next, and I’ll formulate those into a post soon!

    Do any of you have questions about any of these things I’ve done? I’m happy to share all the knowledge I can, especially if I can go into any more detail on mistakes I’ve made and what I learned from them. Yay knowledge!

    No Comments Yet
    smArt Management15 May 2008 05:22 pm

    Seven Maxims of Writing smArt Feedback

    I’m on a major feedback-writing pass this week and I had seven feedback maxims I’d like to share:

    1. Make subject lines COUNT. Be as descriptive and meaningful as possible, especially when dealing with contracts. Use special easily searchable key words like “ArtStudio signed contract AS-0004″ or “(2008-05-15) Feedback for Fat Stinky Orok.”
    2. Everything MUST create its own context. Act as if the feedback you’re writing is the only feedback you’ve ever written to them. Never create dependencies on past feedback! If you need to, re-paste relevant feedback from a previous email. Be specific, and don’t say “do it like that one time” when you could say “In the 2008-05-12 feedback revision when I asked you to adjust the size of the legs.”
    3. Official feedback comes from one place ONLY. I’ll answer very basic work-in-progress questions in an instant messaging app, but for me, OFFICIAL feedback is only for email. Feedback comes from only ONE place! This establishes a consistent approach with the artists, gives you a paper trail, minimizes your contact points and gives everyone only ONE place to search.
    4. Save feedback to its OWN directory. I have a directory for each individual contractor I work with. It’s divided chronologically by their asset deliveries and my reference and feedback drops. Every piece of feedback I ever send them gets saved into a text file and dropped into the appropriate dated directories. This makes it blazingly easy to refer to whenever I need it.
    5. Save ALL work-related instant messaging chat logs. If a casual IM conversation turns into something work-related, save all the relevant bits from that log into the same feedback directory. Every piece of correspondence is important, especially for potential legal issues that may arise in the future. Keep everything in one place!
    6. NEVER include a hyperlink to an image. The site can go down. Always save it, name it meaningfully and attach it in the email, forum post or FTP drop.
    7. ALWAYS specify filenames. In the feedback, never say “check the attached image” without giving the image’s exact filename! This will aid searching later. I can’t tell you how many times I’ve gone through old feedback and seen that and thought “WHAT IMAGE?!?” and had to search through old emails.

    These tips will make all your feedback ridiculously easy to search through and refer to anytime you need, ever. It DEFINITELY pays to be smArt and organized. Leave nothing to chance and let absolutely NOTHING slip outside of the organizational systems you create! A system is only as effective as one’s continued adherence to it. Making even ONE exception defeats the system’s purpose. From there, it’s a slippery slope, and the system falls apart.

    If I’d known these tips going into this job I’d have saved myself countless hours of pain and struggle. :) I’m wincing to imagine the HOURS I’ve spent trying to find “that one email where I’m SURE I asked you to…”

    Comments (1)
    smArt Management& smArtist thoughts19 Mar 2008 06:59 pm

    Contracting tip: Layered PSD paintovers for color roughs!

    Agh, sorry for my slowness to respond to comments lately… I’ve been crunching on something big ever since GDC. I only have time for a short post relating to a thought I had tonight. I’ll expand a bit on my “Outsourcing Concept Art smArtly” article…

    I’ve found an approach working with one of my outsourcing partners that I’ve liked. When putting together the thumbnail color roughs, something I love to see is a layered PSD file with different layer groups showing alternate color schemes that let me mix and match.

    For example, if it’s a character, I can toggle between Red, Black, and Blue color schemes for the Helmet, Chest Piece and Boots. All are individually toggleable. With the varied layers that I can toggle on and off at will, I can mix and match them as I like, fiddle with my layer settings, then pick out the colors I like. Let’s say I choose Red Helmet, Black Chest Piece and Black Boots.

    Leaving only those layers visible, I can lock down those colors I prefer, save out that PSD as a layered example for them to use. :) They can lift the exact colors and settings I want from the layered PSD instead of second-guessing.

    One additional VERY useful tip that I learned from a mistake is to ALSO save out a JPG from that, and deliver BOTH to them. Why? To make sure no one accidentally unhides the wrong layer and delivers the wrong color version to me later. So they have the layered AND flattened reference to ensure everything is solid.

    I’m quite happy with this arrangement so far, and will be using it again moving forward. :)

    Hope that helps you crazy smArt managers out there! And smArtists that are paying attention…

    No Comments Yet
    smArt Management& smArtist thoughts05 Mar 2008 03:15 pm

    Contracting Tip: Bi-weekly payments for maximum motivation!

    One really interesting trend I’ve found in the last couple years is that artists are *far* more motivated to keep working if their contracts are structured so they get paid bi-weekly. The “big fat contract” high wears off after a week or two on average, and productivity goes SHARPLY down after that.

    But, if I make sure they get paid every couple weeks by changing how the payment \ invoice schedule works, they stay happier and more productive longer. Having some semblance of a normal schedule and normal-seeming payment schedule has surprising productivity benefits.

    One week is too frequent (who wants to split up work that finely and invoice that often, anyway?), three weeks is too long (productivity falls after week two ends), and two weeks really seems to be the sweet spot.

    I’ve noticed this trend enough times and in enough artists and studios that I finally paid heed. I try *VERY* hard to make sure the blocks of work I give my artists last roughly two weeks to keep things moving smoothly.

    Artists, take note and push for this if you can. You’ll be happier and more motivated.

    Art managers, this is something definitely worth considering and experimenting with.

    Anyone have any thoughts on that? :)

    No Comments Yet

    Next Page »

    Monthly Archives

    • February 2010
    • January 2010
    • December 2009
    • November 2009
    • October 2009
    • March 2009
    • February 2009
    • January 2009
    • August 2008
    • July 2008
    • June 2008
    • May 2008
    • March 2008
    • January 2008
    • December 2007
    • October 2007
    • August 2007
    • July 2007
    • June 2007
    • May 2007
    • April 2007
    • March 2007
    • February 2007
    • January 2007
    • December 2006
    • November 2006
    • October 2006
    • September 2006
    • August 2006
    • July 2006
    • June 2006
    • May 2006
    • April 2006
    • March 2006
    • February 2006
    • January 2006
    • December 2005
    • November 2005
    • October 2005
    • September 2005
    • August 2005
    • July 2005
    • June 2005
    • May 2005
    • April 2005
    • March 2005
    • January 2005
    • December 2004
    • October 2004
    • September 2004
    • June 2004
    • May 2004
    • April 2004
    • March 2004
    • November 2003
    • June 2003
    • May 2003
    • April 2003

    Categories

    • Daxter ravings
    • General
    • Interesting links
    • smArt Management
    • smArtist thoughts


    (c)2003 - 2007 Jon Jones.