Thoughts on Scripting - You Can't Always Get What You Want

After looking at motivations for scripting, visual vs code, and a few script archetypes, I am going to look at some considerations you might have if you were going to start on a new script system tomorrow.

Script is code
It doesn't matter how you slice it or dice it -- script is code and writing script is coding. You can delegate your script work to people who don't have the word "programmer" in their job title, but you will be turning them into programmers of some variety if you do so.

This doesn't mean that you need to design your script for programmers (though I think they should definitely be considered part of the user group). It does mean that you should consider the completeness of your proposed script solution, particularly what facilities your scripting has to manage complexity. I have never yet met code that stayed simple in a production environment.

Don't create a ghetto
Ask yourself this question: If I were to work primarily in this script environment for the next two years, how would that impact my ability to get a new job? If your answer was that it would hurt your chances of finding a new job, you are creating a ghetto. Once you enter the ghetto you have to fight tooth and nail to escape.

There might not be a short term impact to creating a ghetto, in fact it often can make things easier. However in the long term it hurts you. It isolates your scripters from external colleagues, makes it harder to attract good people, and lowers the value of external resource groups. Script is too often seen as "lower class" work anyway; attaching additional stigma to working with your script system is something you can live without.

Rapid development is less rapid with crap tools
More than once I have seen script systems with much poorer tools than the native code programmer environment. I don't just mean no auto-complete. I mean no debugger, no syntax highlighting, broken text editing, and an "IDE" that crashes frequently. And yet this was where most of the gameplay and game flow was being developed.

If you go with the "rapid development" argument for why you should use a scripting language, seriously consider what the script development environment is going to be. A poor development environment can cost you most of the speed benefit of using script in the first place.

Houston, we have a problem.
At some point something will go wrong in script. How will you figure out what? Having good tools for debugging script is important, especially the more of development that takes place in script. A parallel issue is how do you make problems manifest earlier in development? This gets back to my point of script is code. In the same way that you want tools that expose problems in code, you want tools that make problems in script easier to detect.

Who are the users?
I know I said earlier that making someone a scripter was turning them into a programmer, and I stand by that statement. However it can be a long, long road and not everyone gets to the end of it. Consider where your scripters are coming from. Consider what kinds of WMD you are arming them with. Consider how to paint smiley faces on the WMDs (they are still WMD, but friendlier!). You don't want to candy-coat your scripting, but you do want to consider the mindset, background, and tool set most commonly used by the people you are drawing your scripters from.

< crazy bonus thought > It is less about complexity and more about precision. As a gross generalization, non-programmers handle a lot of complexity, a lot of detail, but they don't have to have a lot of precision.  I think programmers tend to think that because other disciplines don't deal with the same amount of precision that they aren't dealing with complexity. This impacts the design of tools a lot, I think. </ crazy bonus thought >

What can we afford?
How much can you get for how little money? My assessment is that you can afford more scripting goodness now than ever before. There are more options, more tools for straight up scripting now than ever. The performance of COTS script environments are better than ever. The tools for building tools are better than ever (I'm looking at you Qt).

However, there is certainly a limit to what you can afford. The more you pour into making tools, the less you have left for making product. Clearly identifying what your goals are for your scripting system is vital for determining how much of what you are going to build. I would argue that a limited set of well-developed, targeted scripting tools will serve better in the long run than a super feature rich script environment.

What critical consideration have I missed?