Scripting for Designers

I started a kerfuffle on the subject of designers writing scripts. Since my original post was more about our experience with Lua than about scripting for designers I thought I would collect what I’ve already written in everyone else’s comment thread in one place.

Raph believes that designers should know how to write scripts. I agree completely. Games are more about algorithms than they are about art, sound, or databases, and knowing how to code at some level is going to help any system designer immensely. It will allow them to communicate with programmers more effectively, it will make their designs fit better within existing game or technical systems, and it will improve the quality of their designs overall.

Where I draw the line, however, is at actually shipping those designer-written scripts with the game. They are a fine prototyping mechanism, incredibly useful at creating gobs of data, and a brilliant simulation mechanism. Designer scripts are also often slower, more obtuse, and less maintainable than the equivalent script (or code) written by a professional programmer.

Does that mean I think designers have some mental deficiency that makes them write crappy code? Of course not. While there are some basic concepts of programming that require a certain talent to grok (pointers, branches, order of algorithms) by and large most scripting designers have that talent. What they lack is the experience required to write code that you can keep running for years on end. Programmers spend all day, every day on the subject of how to quickly write maintainable code that runs well. For designers, it’s at best a sideline. We put our programmers though a hard-core technical interview to try to determine if we want to put up with their code. Any designer who can pass that interview is welcome to write production code in my book.

A much better approach is to provide a rich mechanism for driving game logic with data and give designers reasonable tools to manipulate that data. That doesn’t mean designers are reduced to inputting tables of numbers. The data-driven systems we use in Pirates allow designers to add entire new game systems by combining existing building blocks. We also work closely with the designers to implement new blocks for them on a regular basis.

Damion mentioned that schedule constraints often lead to programmers changing their tune when it comes to designers writing scripts. Tight schedules are why we integrated Lua in the first place. I thought it would let us take advantage of the people in the office who were less overloaded to write some of the game. My current position on designer scripting is a direct result of that Lua integration.

One thing I discounted in the “let’s get some designers to write some scripts” approach was how valuable the designer’s time is. In most cases it’s easier to build a new system using our data-driven system than it would have been to implement the same system in Lua. When using data isn’t easier, a day or two of a programmer’s time can usually make it so. Our system design team is even more critically understaffed than our programming team, and by using data instead of code we can save them time.

Just about everyone has said, “It depends on your situation.” It certainly does. If you have a team of 5 and your lead designer is also your junior programmer, you would probably be well served to have that designer writing production code. In a more general case with more specialization among your staff, it’s a bad idea to plan on all your design hires having that level of programming ability. And if you reject all designers who don’t meet some minimum programming skill level you may find it hard to hire designers.

All in all, the Great Designer Script Debate of ’07 has been great. It’s nice to take a break from whining about how many users Second Life doesn’t have or how raid content in WoW is the best/worst thing to ever happen to MMOs. Who’s going to kick off the next kerfuffle?

~Joe


7 Responses to “Scripting for Designers”

  1. robusticus commented on :

    I thought it was a good point. It did get lost in all that faction warfare, but still… I’m now wondering how to store pre-compiled DLLs instead of scripts and if that will work seamlessly with my debugger.

  2. Joe wrote on :

    Oddly enough the post on sweng-gamedev that started people talking about scripting at all was a question about using native code in DLLs instead of a scripting language. It’s certainly a possibility.

  3. Chris White commented on :

    Before I got into making games, I did some work for a defense contractor building battlefield simulations, and found this debate interesting to watch because we faced the same problem. The “designers” in this case were Army officers who needed to specify mission scenarios and doctrinal rules that agents in the simulation were required to follow. Our original simulation involved a point-and-click interface that allowed them to draw up glorified flow-charts that got saved in a database in a format that the simulator could interpret at run-time, but after a while of using this, the Army officers told us that this was too cumbersome, and wondered if they could develop simulation scenarios in a format more similar to how they were used to describing doctrine. It turns out that the Army has stacks and stacks of books describing exactly what soldiers are supposed to do in a given situation. They sent us a couple of these books and one of our leads drew up a formal grammar that looked similar to the format they were using to describe the doctrine, and 2 months later we had a compiler and editor for this new language that let our designers script situations in a way that was very familiar to them. The big take-away from this is that, as you mentioned above, it depends on your situation and who your designers are. There won’t ever be a cookie cutter solution that will work for everybody.

  4. Rich Bryant commented on :

    I’m afraid I side with Joe here, almost completely. I’d much rather designers were producing use cases than scripts.

    Or scripts for rewriting. And not to be executed by a scripting engine. There is one very simple reason for this stance:

    SCRIPT LANGUAGES TEACH SHITTY CODING HABITS.

    I wouldn’t want any programmer working in a team with me to spend time on lua, javascript or (god forbid) vbscript, ever.

    Your code must be maintainable and above all else, that means any talented programmer should be able to walk in off the street, read the relevant documentation, look at the diagrams and make the changes you need. It absolutely must not ever look like amateur baby-talk script language.

    I’d say this was even more important than the performance and testing issues which come up around script-blocks (which is again mostly due to shitty coding habits taught by script languages).

    A programmer must be replaceable.

  5. Joe thought on :

    Wow, you’re even more hardcore than I am. :)

  6. Rich Bryant commented on :

    Hah, I’m currently recruiting coders. I guess it makes me worse than usual.

  7. Joe thought on :

    While scripting languages can certainly teach some shitty coding habits, I think a far bigger concern is the kudzu effect. Once you have a scripting language in your game it starts to get into everything and you end up writing far more of the game in scripts than you expected. When your scripts are of marginal quality to begin with, the script-creep makes them really really bad.

Leave a Reply