I 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 private message, totally a troll. Then it exploded.

I like fire. It quiets my inner demons to watch things burn. So while I was on a plane yesterday, I cobbled together a few more logs to toss on top of it.

“It’s impossible to have a data driven game that isn’t like playing a spreadsheet.”
bah. Any behavior that can be coded or scripted can also be encapsulated and exposed to the designers in a data driven format. Whether or not it -should- is another matter altogether, but saying otherwise just means that the programmers haven’t exposed enough functionality components to the designers to make truly interesting and innovative gameplay.

For the record, Shadowbane had no scripting whatsoever. As an example, all of our class and skill functionality was determined in a data driven manner. I suppose you could argue that it’s game math was like ‘playing a spreadsheet’, but by most accounts, Shadowbane’s PvP was considered to be well-balanced and interesting by the people who like that sort of thing.

“We will give the designers tools so good that scripting is unnecessary. Also lepers will be healed and walking on water will be involved.”
These are all filthy lies. Nine times out of ten, these tools will never move above ‘adequate’. You are urged -not- to get in the van with the man with the candy.

“Designers shouldn’t be writing code.”
Um, whatever. Many, many times, designers write perfectly adequate code for scripting purposes, especially when designers are hired in part based on their scripting expertise. The problem is that -some- designers should most assuredly not be writing code (and yet are asked to when things get crunchy). The more incendiary problem is that often designers attempt to write in script functionality that really needs to be written by a programmer, often in code, due to issues with that particular system. As an example, a certain nameless designer wrote the original UO guild system in script. Unfortunately, a key thing you need a guild system to do is to build a roster, a function that requires searching and sorting of some fairly hefty lists. Between inefficiencies of the code and the limitations of the scripting language, large guilds opening their guild roster would cause the entire UO server to lock up.

Designers have a tendency to take whatever tools they have (be it scripting, worldbuilding, kismet, whatever) and attempt to make it work as best they can. Why? Because most often than not, we don’t have the programming resources to have them code it, or to have them give us a tool that does it in a simple, non-hacktastic way. Designers make do. It’s our lot in life. This usually works out fine, but can result in some spectacular explosions when it doesn’t.

“Scripted behavior is where designer ingenuity can truly shine.”
Actually, overly ambitious scripted behavior is often where MMO code bases fall down and go boom.

The most frequent problem with an environment where designers script systems is a lack of oversight – often, these designers end up designing a system and then coding it immediately, resulting in features going into the game that have neither code review nor design approval. This usually results in the most spectacularly bad features – features that both have poor performance and do not interact well with other game systems from a design point of view. This is solvable via good process, but it becomes harder and harder to maintain that process once the schedule gets crunchier.

Scripting has many bugaboos that people hinted at in their various posts: scripting is inherently frail – systems designed to be more universal are much more likely to be robust enough to handle the unusual demands that players will find to put on it. Scripting creates balance issues – a monster whose stats are adjusted or treasure that is dropped via script is prone to be missed when you have to do a balance pass of everything in the game. Too much scripting can be a QA nightmare. Many scripting languages are slow, and are hard to debug (many home-brew script languages have no debugger!), with a frequent problem being jumping in between the script language and the C++ layer.

Tools and data driven systems have their issues as well. Designers will, almost always, be asked to deal with a solution that sucks to build the game. We make do. We usually have little choice in the matter.

For my two cents, scripting is a valuable and useful tool, but it is best reserved for worldbuilding, to create unique events and quests. Worldbuilding is a good candidate because scripting can have a high impact: interactions tend to be simple, the events tend to be called rarely (sidestepping performance issues), but you can still create truly memorable game events.

I’d data drive as much as possible, and push the programmers to give us as many configurable data drivable widgets as possible. Also, I’d give my lead gameplay programmer permission to punch any designer in the mouth that tried to write a major system like an Auction House, guilds, or even a friends list in script language without programmer oversight. But then that’s just me.

Original comments thread is here.