Metastasis
It all began with Joe’s post. Then Damion picked it up. Then Raph did. Then Sara did. Joe, you created a monster.
Rather than spam everyone’s comment threads up, I figured I’d just write up a few thoughts here. I’m the guy who has to live with Joe’s anti-scripting bias, so I’m the only one with a dog in the fight, as it were. (no actual dogs involved; please don’t ban me from professional football)
I’m a fan of scripting. I’m also a fan of a game that doesn’t crash or have bizarre, untraceable performance problems. I’m a fan of code reviews, and code written by people who are trained to do so. I’m a fan of bulletproofing the mechanical operation of the game. I’m a fan of tight security, and of not giving users unintended loopholes to jump their goldfarming bots through. In short, I’m a fan of professionally-written code.
But I script a lot, because, as I said, I’m a fan. I model systems in scripts. In an earlier, simpler version of the PotBS economy, I wrote a script that included simple AIs making decisions about buying and selling goods and traveling between ports to see what a thousand players might do. I have a set of php scripts that tell me the expected value for any good based on the cost to produce it. I have another script that compares distances between resources for every nation, and a script that generates spreadsheets for all the outfitting in the game. (And Joe makes me check all this into our source control system, because he’s anal about that.)
I would never, ever want any of my scripts to make it into production code that’s exposed to the user in any way. See, I can make things go ‘beep’ just fine. What I can’t do is anticipate the user who figures out how to use my ‘beep’ to launch a SQL insertion attack against the game servers. That’s not my job, and it shouldn’t be my job. I’m good at imagining how adding a mission that allows users to trade silver ingots for gunpowder will impact the market for ammunition in the French auction houses. That’s the stuff we don’t expect the coders to do, and that’s why we have a design team in the first place.
I don’t think it’s unreasonable to expect your designers to be pretty technical. Everyone in my team is reasonably technical. But to me that’s just part of thinking like a designer — thinking in terms of technical achievability, not just wild-eyed dreaming. That’s the difference between designers and the guy on your forum who has a great idea and wants you to pay him $1,000,000 for it (no kidding, saw this on the WoW forums before it was moderated into oblivion).
But I don’t expect my designers to code. We have enough to do just figuring out how systems should work, how they should be balanced, and how the content will express our ideas. If we were scripting, too, we’d have no time to do design, and we’d create substandard code. Or, if one of us wasn’t creating substandard code, it would be because he was part of the dev team, working for Joe, at which point he wouldn’t be a designer anymore, because we have way more things that need coding than we do coders to implement them.
I work closely with the developers. In some cases, I work way too closely, and find myself getting shot down when I suggest things that they know — because they’re software architects and think about these things — are impractical or should be done in a different way. When I propose a system, Joe and the dev who’s going to implement it go off and talk about how to make our object model do that intelligently. My eyes glaze over. I am not a software architect. But when a dev is working on something I designed, there’s an enormous amount of back-and-forth, where he figures out what I want, and I figure out what’s possible. Neither of us has the specialized knowledge available to do the other’s job.
So what do I think of data-driven design? I think that I’d really like to have OR conditionals in our requirements system, instead of just AND conditionals. Otherwise, it’s worked out pretty well. And I believe it’s worked out because I’ve been involved at every stage of the construction of the systems, making sure they’ll produce the outcomes I need to create the systems I want.