Scripting in PotBS

The sweng-gamedev list is all a-flutter with a debate about the merits of scripting in games.  I wrote up a response that describes our experiences and figured I’d share it here too.

We had Lua integrated into the client and wrote much of our UI logic written in it. We struggled with bugs in our glue layer, difficulty debugging, and major spikes in our frame times whenever the garbage collector ran. Of course the glue code was terrible to begin with and we were exporting script hooks for much of the game instead of a nice clean interface, so that didn’t help. After a while we started moving away from Lua and began implementing new UI in C++. We’ve now removed all the Lua from the game.

On the gameplay side we use a rich data-drive system that lets designers define an arbitrary list of “requirements” with which they are able to test most any condition. When a trigger fires, object is used, or skill is activated, an arbitrary list of “results” is activated which is capable of modifying just about any state in the game.  The designers also have a few ways of maintaining persistent state on the characters depending on the circumstances.  This system is working pretty well for us and eliminates the need for any designer-written scripts.

If I ever integrate scripting into an engine again, there are several things I’ll do differently to make it go more smoothly:

  1. No designer scripting.  If designers are writing scripts, You’re Doing It Wrong. Scripts are code, and need to be just as maintainable as all your other code.
  2. A much cleaner API layer between the C++ code and the script code.  Exporting the whole game to Lua was just dumb.
  3. A built-in debugger. Printf-style debugging is so incredibly painful when you’re used to having a rich source-level debugger.
  4. Built-in profiling. All calls across the native/script interface should be timed and memory consumption should be strictly monitored.
  5. Dynamic script loading. Part was stupid glue and part was just our poor use of the scripts, but the first time around we ended up loading all the scripts when the client booted and couldn’t reload most of them. This one of the major advantages of scripting and we were missing out on it.
  6. Much more evaluation time. We know a bunch of things to look for the next time around including slow garbage collection, object lifecycle issues, memory corruption in the glue, testability of the scripts in isolation, etc.

On the other hand, I think writing servers in a higher-level-than-C++ language like C# or Java makes a lot of sense and would save us tons of development time. It’s the dynamically typed language with no debugger that didn’t work well for us.


13 Responses to “Scripting in PotBS”

  1. Darius K. wrote on :

    FYI, my friends at Unknown Worlds recently released a high-quality Lua debugger:

  2. Joe commented on :

    That’s good to know. If only Decoda (and Lua 5) had come out a few years earlier. :)

  3. Matthew Weigel wrote on :

    Well, now I’m interested in this list…

  4. wowpanda commented on :

    is there a reason everyone is using LUA (WOW)? No one every think of javascript?

    After I realized the need for custom code in my bot for WOW, I added in javascript engine from Mozilla, because it is small and been used since the beginning. It turned out pretty good. Any comparsions between all the script languages (php, LUA, ruby etc)?

  5. Joe replied on :

    There is a small, fast runtime available for Lua that’s easy to embed in a larger app. And everyone who is using Lua is doing that embedding, so there is lots of help on the web on the subject. The reason no one is embedding Javascript is probably just that no one is embedding Javascript. :)

    Also, Lua is quite good as a file format for data. It’s able to do arbitrarily nested hierarchies of data well. My impression of Javascript is that Lua beats it in that regard, but I’m not really familiar enough with Javascript to say that for sure.

  6. wowpanda replied on :

    Interesting! It is not possible for me to go LUA now because javascript is already choosen, but I will look at it in case of future use.

    But one advantage I am sure about LUA is, because javascript is heavily used on the web, it will be much easier to find embedding information on LUA than javascript, just because all the garbage might be pulled when searching for javascript embedding.

    javascript engine is very small though. The entire javascript engine plus glue code only added about 300k in my final exe.

  7. alexjc commented on :

    Lua is definitely popular because it’s so easy to embed. It’s also nice and elegant, as it uses tables everywhere in a similar way than Scheme has lists…

    I hadn’t considered Javascript though! I’m sure there’s an implementation that’s just as easy to work with.


  8. Dr. Cat wrote on :

    We’ve had a lot of luck with my DragonSpeak scripting language. It was designed for our players to use, but our staff uses it internally a fair amount too. The language is designed not only to be very english-like and easy to learn for non-programmers, but it’s also designed to make it pretty hard to generate large amounts of CPU overhead or bandwidth usage, and impossible to generate an endless loop, array overflow, or crash. If you’re interested in taking a look at the language, it’s in Furcadia, which is a free download. Not the right answer to every problem, but it’s a good answer to some.

  9. Charles Crain replied on :

    Excellent observations. I have a good deal of experience modding games with LUA, and I have been struck on many occasions with the poor quality of the LUA code included with the game itself (which I would guess is a manifestation of your lesson learned #1).

    I’d submit though, that if you solve your issues 2-6, that will go a long way toward alleviating the problems you had with #1. Or put another way, if your designers are having to write too much software, then your API is not clean and/or high-level enough. If you get the API right, then the “software” that the designers have to write will approximate the simplicity of the data-driven approach you are using now, but still allow more flexibility if needed.

    They’re also not mutually exclusive…I used to own a MUD, which are of course almost totally based on scripting, but we used a data driven approach where appropriate and where we wanted to make things friendly toward non-programmers. The data driven stuff was written *in* the scripting language.

  10. Marauder said on :

    Interesting.. it is funny how many companies put level designers on script duty. How often does that actually work out?

1 Trackback 2 Pingbacks

  1. Trackback from Anti Patterns on :

    L’art du script…

    La plupart des moteurs de jeu modernes ont plus de rapport avec des systèmes d’opérations qu’avec des jeux. Contraint d’être souple et versatile, les moteurs sont amenés à être exploité dans de multiples productions.     Du coup, la…

  2. Pingback from No Scripting for You! | Zen Of Design on :

    [...] always say, “No designer scripting!” This lasts until they see the production [...]

  3. Pingback from My Only Slightly Less Snarky, but Much More Thorough, Thoughts on Designer Scripting | Zen Of Design on :

    [...] didn’t start the fire, I just threw gasoline on it, with a terse, 3-line post that was, as Joe correctly surmised via a [...]

Leave a Reply