Psychochild's Blog

A developer's musings on game development and writing.

7 November, 2007

The role of scripting for designers
Filed under: — Psychochild @ 5:02 PM

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.


  1. The elephant in the room is that a lot of programmers like to “Design by veto”, if they don’t like the gameplay effects of what a designer is wanting to do, they’ll drag their feet or claim it can’t be done. If they’re dealing with a designer who knows code, the “can’t be done” excuse won’t work, he/she is going to want to know why it can’t be done, and is going to be hard to snow with technobabble. So that leaves dragging their feet, claiming that other demands on their time keep them from doing what the designer wants. It might even be true, but usually either the designer winds up backing down before the programmer starts punitively being too busy for other things, or it winds up on the producer’s desk, with much acrimony on all sides.

    If the designers have a robust scripting language, they can simply say “Fine, I’ll do it myself.” This can have bad consequences, if the designer isn’t a good programmer, the system is complex, or if the scripting engine isn’t bulletproof and efficient (just running a sort or a search can have huge performance impact, if the designer has to roll their own or isn’t aware of how much overhead the canned routine imposes). And nobody likes working on tools, and a scripting language requires constant monitoring and tweaking (if the designers are using a search too much, somebody has to be watching to either optimize the search, write a specialized one, or kick it back for a “is this trip really neccessary?” decision).

    Programmers are much happier if they are the only ones touching the code, and not all of their reasons are really based on technical validity. The designer who hasn’t had a programmer play the FWIW card in a design disagreement hasn’t worked with many programmers, or has unusually well-behaved ones.


    Comment by Dave Rickey — 7 November, 2007 @ 6:16 PM

  2. Do you actually work with programmers who use “can’t be done” as an excuse not to implement something??

    That sounds totally unprofessional to me. I know managing programmers is sort of like herding cats, but seriously–any programmer who won’t do his job should just be fired.

    Comment by moo — 8 November, 2007 @ 8:17 AM

  3. The problem is that most schedules are planned to go to the last possible minute, and often go over. Programmers are one of the most expensive employees you have, so your programmers are usually busy 100% of the time. (All employees generally are, but if a programmer is sitting idle, the producer can almost hear the money being thrown into a black hole.)

    So, when a designer comes on after initial planning and has a great idea, it’s not uncommon for the idea to be labeled as “can’t be done” given the time that has already been allowed. As Dave points out, this is sometimes a valid concern, but other times it’s the programmer nixing a system. Part of the problem here is a lack of real project management, especially for the larger games.

    In the defense of programmers, note that sometimes it isn’t just the programmer being an dick and not liking the design, it could also be that the programmer doesn’t want to have to develop the system given the already tight schedule; designers are often just as stubborn about not wanting to cut existing features to make room for the new ones, even though that’s almost always what has to happen. Programmers go into game programming for two main reasons: 1) the challenges of game programming, and 2) the creative aspects of game development. Most programmers that are good enough to do game programming could easily land better paying jobs, especially when first breaking into the industry.

    Unfortunately, there tends to be a lot of factionalism between designers and programmers, and people with cross-disciplinary abilities tend to confuse others with where they should fit in. I don’t think Joe was merely trying to keep the dirty designers out of the beauty of programming, but some programmers are very jealous about guarding their domain. Likewise, some designers are jealous of programmers that want to help with design, often because they feel the programmer didn’t “pay his/her dues”. Mmm, politics.

    Comment by Psychochild — 8 November, 2007 @ 5:55 PM

  4. Damion has further discussion about designer scripting. He also points out that there are no “right” answers in absolutes.

    Comment by Psychochild — 9 November, 2007 @ 1:19 AM

  5. ..And that’s why you need to plan for 80% (4 days a week), like every other industry out there. Yes, it’s expensive. But is it as expensive as the schedule slipping and you losing a third of your experienced staff after the project to burnout?

    Anyway, I’ve commented over on Damon’s blog, but I’d like to add that I find it amusing when coders have issues with wiki scripting and refuse to use it.

    Comment by Andrew Crystall — 9 November, 2007 @ 7:07 AM

  6. So far, I’ve had really good experiences with scripting. However, it’s not as though the programmer makes a set of scripting callback and turns his head to the content guys.

    The programmer must be there to review the scripts, establish ideal scripting templates, and answer questions on why one approach is better than another approach. It sounds like a lot of trouble, but in the end, you’ll get:

    1) Content guys that understand the underlying system and the ramifactions of their actions.
    2) Programmer guys that understand their customers (the content guys) and will be in the best position help the content guys do their job or tell them “NO!@!”.
    3) These content guys with the knowledge can now go on to train other content guys, program, or become a producer (with a lobotomy first of course).

    Programmers must be willing to spend time in order to get an elegant but powerful scripting system. It really helps if the programmer is willing to eat their own dog food by scripting a few quests, combat actions, and/or items.

    Comment by Bobby — 9 November, 2007 @ 8:38 AM

  7. Well, your code is your baby. You dont want some lunatic coming over and forcing you to dye your kids hair green. I wield the “cant be done” veto when necessary. Designers make mistakes as much as the next guy and Im the last line of defence for the customers, (cough Vanguard cough), and conversely the first line of attack when I make a mistake :(

    Also cant be done is shorthand for not an efficient use of time and resources. You CAN build a McDonalds on the moon, doesnt mean you should, because too much else would have to suffer to do it.

    Theres also the “Health and Safety” veto. Theres code you know from experience is very delicate and last thing you want to do is mess with it because the consequences of mistakes are catastrophic, so its not a question of if but when.

    Comment by paul — 16 November, 2007 @ 3:19 AM

Leave a comment

I value your comment and think the discussions are the best part of this blog. However, there's this scourge called comment spam, so I choose to moderate comments rather than giving filthy spammers any advantage.

If this is your first comment, it will be held for moderation and therefore will not show up immediately. I will approve your comment when I can, usually within a day. Comments should eventually be approved if not spam. If your comment doesn't show up and it wasn't spam, send me an email as the spam catchers might have caught it by accident.

Line and paragraph breaks automatic, HTML allowed: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Email Subscription

Get posts by email:

Recent Comments


Search the Blog


November 2019
« Aug    



Standard Disclaimer

I speak only for myself, not for any company.

My Book


Around the Internet

Game and Online Developers

Game News Sites

Game Ranters and Discussion

Help for Businesses

Other Fun Stuff

Quiet (aka Dead) Sites

Posts Copyright Brian Green, aka Psychochild. Comments belong to their authors.

Support me and my work on