Script Interfaces

One of the most serious script writing issues that I have run into is mixing the code that performs the work with the UI the scripter wrote. Its pretty clear from most of the examples I have seen of this that the person writing the script was going along and and all of a sudden realized that they needed to ask the artist to give them some important information. Right there in the middle of their code they will pop up a dialog asking for the necessary information. Even worse they will actually query the UI element in the middle of some other function performing the work.

Why is this a problem? Well what if you want to batch process this function. The dialog will be popped up every time you go through the lop requiring artist input even if its the same value every time. Another thing to consider is if you want to modify the function you might have references to UI objects scattered through the code that may or may not exist at the time you need to get the value.

Instead write your code that actually does the work as a stand alone function that has parameters passed into it for all the information it needs to perform its function. This does one very important thing, it separates the code functionality from how it gets the values it needs. This separation means that if you need to re-factor the code you will not have to worry if UI widget exists that has the value you need. It also allows you to use the code in other processes, for example batching. 

This way you could have two different ways for the artist to perform the same function, one would be hooked up to a UI that would collect all the information to run the function and call it when the user hits the Okay button. The other could be a batch script that determines the values somehow and runs the function on a collection of objects or files with no human intervention.

The important concept is to separate the desired functionality from how you actually get the information you want the function to use.

Introduction to Technical Art

I've got over 16 years of game development experience creating art and writing tools for artists, and have recently been training technical artists to fulfill the growing demand for people who can fill the growing divide between programmers and artists. While doing this I found had to explain the insights and practices that I had spent the last 15 years developing. Some of this had to do with coding techniques and tools architecture, but I found the most of the coaching I was doing was around communication.

An enormous amount of time in tool development can be spent solving either the wrong problem, or as I have found through hard personal experience, problems that don't even need to be solved. What I ended up sharing with the technical artists was the thought process I went through evaluating all the tools requests being made and how I went about resolving them. And that is what I'm going to share here.

What's the problem here
Superficially this is trivial, the artists request a feature change or a new tool and it yours job to make it for them. The artists know what the problem is, they are using the tools on a daily basis and know better than you what problems they are having. The artists will also know if the solution is satisfactory. What they don't always know is how to get from where they are to where they need to be. If they did know how to do this they would most likely do it themselves and not even bother a technical artist.

So the first thing you need to understand is, what is the problem that the artist think this tool will solve. If you don't understand this how can you deliver a tool that will solve the problem. While this may appear stupid obvious I have been guilty of failing to do this step in the past and solving the wrong problem.

Secondly you need to understand what they think the solution will look like and how they intend to use it. This is a potentially big place to screw up. As the Technical Artist/Tool Programmer you why you can and can't do somethings, to the artists they don't know why and usually aren't interested in why, but they know what they want. Understanding what they think the solution will look like will help guide your technical solution to match their need.

The third thing which is easily over looked is how this fits inside the over all art content production. It's not enough to understand what tool they want and how they want it to work, you need to understand how this tool fits in with their production practices and the other tools that they are using. your tool rarely exists in a vacuum and it needs to work with the existing production practices.

Knowing the answers to these three things is absolutely critical before you start developing your solution.