7 November, 2007
It seems like everyone got together and decided to have an interesting discussion right as I was out of town. The issue brought up by Joe Ludwig was: No designer scripting. This assertion created a lot of discussion, including a followup post by Joe.
Since I fancy myself both a programmer and a designer, I have something to say about this!
I wrote a post about scripting languages years ago on this blog. My core assertion was that for online RPGs, you want to give non-programmers the ability to create content easily. But, the larger issue is that you need to use the tool that’s appropriate for your situation. If you need a fast-and-lean solution, then that limits what tools are appropriate for your task. But, taking this a step further, you need the right tool for the resources you have, particularly the people in your team and the schedule you have to meet.
Damion explained the issue with scheduling with a fair amount of snark. Programmers, especially ones with experience, don’t grow on trees. Therefore, expecting all game implementation to only happen with programmers is usually something that hurts the schedule. Having designers wait on a programmer to implement a feature is a waste of time that can impact the schedule; if you have programmers sitting around idle waiting for things to implement from designers, then you’re wasting money.
However, you also need to keep in mind the type of people you have on the team. A designer like myself, with a Computer Science degree, shouldn’t fill the “real” programmers with a sense of dread because of having to deal with my code. (They usually get that sense of dread when they realize they can’t simply tell me, “That’s not possible,” and get away with it because I can often show them how it is possible.) Other people have other strengths, and this is the point that Raph and Sara are talking at each other about. Someone like Sara, with a background and keen interest in data, will work better in a system that allows for interesting combinations of data. I, however, would probably find such a system very limiting since I probably don’t think in terms of data as well as Sara does; I think in terms of code. Raph makes the comment that data-driven systems designers don’t have as much of a career path. I disagree slightly, because given that the position of “designer” is so ill-defined, any designer will have to make his or her own career path. However, I think it’s important for designers to understand the basics of coding and computer science even if they can’t sling C++ code around like an expert, because it gives insight into what can and cannot easily be done. For example, if a programmer notices that a design is NP-hard, I know what that means and won’t argue the point. :)
One issue that nobody has talked about is what types of scripting systems we’re talking about. For example, a simple quest definition system with conditionals probably qualifies as a very simple scripting system. For example, Kevin Maginn (who works with Joe), laments that, “I think that I’d really like to have OR conditionals in our requirements system, instead of just AND conditionals.” Adding in features to save on development time takes a tool such as this closer and closer to a “real” scripting language. However, as I said in my post I linked above, I think it’s better to use an off-the-shelf language that meets your needs as closely as possible. If you pick a robust language that allows for additions, you can get a tool that you can use with less work than creating a scripting language from scratch. You also save on training since there will be books for the existing scripting language.
Of course, there are still many issues you have to watch out for no matter which system you use. Scott Hartsman points out a lot of pitfalls with scripting using a humorous faux-definition. Scott’s post really supports my point: that scripting languages, just like any other tool, isn’t a magic bullet that makes everything work perfectly. Giving someone with absolutely no programming experience access to a scripting language isn’t the trick to make the project stay on track. It will lead to the problems Joe pointed out in his original post.
So, in the end, I don’t think you can make universal pronouncements. Maybe “no designer scripting” worked well for Pirates of the Burning Sea, but that wouldn’t necessarily work well for a project someone with my level of coding ability was working on. On the other hand, giving the junior designer with no background in coding access to scripting is just asking for problems. Yet, that junior designer should probably learn a little bit about coding to understand how to design more effectively. Once again, it’s all about picking the right tools for the job.