Adrian Woods is giving a talk entitled The Make Art Button: Batches, Actions, and Scripts. I think he sums it up in the session description just perfectly:

Do something once, it's creative. Do something twice, it's repetitive. Do something three times, you can probably automate it.

I've said the same thing many times, but maybe I start to automate at twice.

This session will use comand-line tools, Photoshop automation, and MaxScript for 3DS Max. For myself, I've used plenty of command-line tools, a tiny bit of MaxScript and no Photoshop automation. I do find that a lot of Photoshop tools have counterparts in the Gimp however. Given the work he's been involved in on Microsoft Flight Simulator, I'm looking forward to hearing what kinds of work he recommends automating and how much effort it's worth. The question that I have about automation for art is about balance. Specifically how to balance the work needed to produce new tools for automating a very specific task against the work needed to complete these tasks manually. The way I approach this issue is by considering a few factors that are all around time savings, reuse, and repeatability.

How many times will I need this script for the current project; that is how much time can this save me?

The first question is the obvious one. The first steps into scripting and automation are about saving time and reducing manual effort. Am I saving a couple clicks with a couple seconds in between? Can I just hit keyboard accelerators for those buttons and get the same results as a script? How many times do I have to use this script before the development time pays off? If I'm already under a time constraint then this question can dominate the decision. If there are a few hours to complete a task and I don't know a good scripting language for the tool, then I'm apt to stick to the manual route only because I've got a more predictable time. I don't enjoy it, but predictable can be better than fast. The worst part of making the wrong decision here would be missing a deadline because you were learning a scripting language. It's not fun to explain that lapse in judgement.

How much of this script can I reuse in future projects?

Reuse in scripting can be tricky (depending largely on the language and script host). It's often of the cut and paste variety. There are so many scripting languages and scripting hosts that it doesn't always make sense to try a code library approach. I'd imagine that users in more controlled environments than me can build collections of code snippets and libraries over time though. If 90% of your work centers on the Gimp then you might use a lot of Scheme and collect up a sizeable library of code, but you might find that you also build up a collection of scripts that automate your shell (in Windows or Linux) to move files around or manipulate meta-data of the files. Those shell scripts have different storage and reuse rules than the Gimp scripts. This only gets more complicated if you're automating multiple tools in your pipeline.

I don't aim for reuse the first time around. For example, I've written scripts that use the Windows Scripting Host to execute some Javascript that builds up an HTML report as an output from a lengthy process. The next time I need such a report in a different application, I'll grab that code, copy it, and make it function as a superset of the needs of both projects. After that time I start looking at how it can be generalized into a report-generation function that an arbitrary script can call. Even though I've said I don't consider reuse an immediate concern, I do consider it an important secondary concern. The only reason I don't think of reuse in scripts as being as critical as reuse in "real" software projects is that scripts are often one-off creations built to serve a specific purpose for one strange set of input with another strange output. Then a script may never be touched again. Spending time to make it reusable can be time wasted. The value of reuse and other software design concepts depend largely on the size of the input set, the more frequency of the task being automated and the number of users for the script.

How severe are the consequences of mistakes in manually producing this resource?

When weighing the benefits of scripting resource creation, I have a concern that's kind of tough to explain to some people. The idea is that sometimes when I process photos or draw pictures, I might make a mistake. I might then take those graphics and use them as the input for some more long and complicated work (that I can't automate). If I find out after all that work that I made a mistake up front, it could be tough to deal with and I might even need to repeat the whole long complicated part of the work. There are two things I do to combat this problem. The simple thing I do is save my intermediate work. One example that comes to mind is a graphic which I'd lit then cut into pieces so it could be recomposed on a web page. After the page was complete (and hours of CSS-wrestling later), I found that one of my cut up images was cut in the wrong spot. So I couldn't just offset it because of the lighting process. Luckily I had the intermediate graphic in one of my intermediate folders, so I was able to avoid repeating many steps of the process.

The other thing I do to fight mistakes propgating is automation. If I can't automate the long complicated part, then I can still sometimes work to ensure that the input is correct by automating the creation of that input. The reason this is hard to explain to people is that they generally ask "what mistake are you going to make?" That means I'm not explaining myself clearly (see how I graciously avoided calling the question dumb?). Obviously, if I knew what mistake it was, I wouldn't make it. I'm talking about an unknown mistake. A mistake that falls within certain bounds of course. Automation can fix things like putting text in different spots on different buttons, but it can't fix things like me forgetting to put pants on in the morning.

Automation can give more predicatable results than I can get through manual production. That means more predictable mistakes, so fixing the mistakes can be automated. The manual mistakes have to be spotted manually and fixed manually.

Where I'm coming from and what I hope to get out of it

I've learned piles of scripting languages for the purposes of automating different steps of the software I build, but I've only started in the last few years to do the same thing for some art resources. Working in a scripted way with graphics is a lot tougher than scripting manipulations of text and numeric data though. While the Max Script and MEL will be mostly new to me, I've found that ImageMagick can be great both on the command line and as a tool for ActiveX-aware languages. I've also had some success with building graphics in SVG then using Apache Batik in a batch file to make raster output when needed. In the Gimp, Scheme has been a stumbling block, but I have done one snippet for the Gimp with Script-Fu on hue rotation.

If I get to attend this session then maybe what Adrian has to say can help give me some guidance on directions to take going forward. Given the huge amount of content he's worked with and the huge titles it's gone into, it should be very interesting.