Comments on: Scripting for Designers http://programmerjoe.com/2007/11/03/scripting-for-designers/ Joe Ludwig\'s blog Mon, 01 Dec 2008 17:19:47 +0000 http://wordpress.org/?v=2.2.3 By: Joe http://programmerjoe.com/2007/11/03/scripting-for-designers/#comment-60330 Joe Fri, 09 Nov 2007 23:41:25 +0000 http://programmerjoe.com/2007/11/03/scripting-for-designers/#comment-60330 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. 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.

]]> By: Rich Bryant http://programmerjoe.com/2007/11/03/scripting-for-designers/#comment-60318 Rich Bryant Fri, 09 Nov 2007 23:02:08 +0000 http://programmerjoe.com/2007/11/03/scripting-for-designers/#comment-60318 Hah, I'm currently recruiting coders. I guess it makes me worse than usual. Hah, I’m currently recruiting coders. I guess it makes me worse than usual.

]]> By: Joe http://programmerjoe.com/2007/11/03/scripting-for-designers/#comment-60282 Joe Fri, 09 Nov 2007 19:10:29 +0000 http://programmerjoe.com/2007/11/03/scripting-for-designers/#comment-60282 Wow, you're even more hardcore than I am. :) Wow, you’re even more hardcore than I am. :)

]]> By: Rich Bryant http://programmerjoe.com/2007/11/03/scripting-for-designers/#comment-60250 Rich Bryant Fri, 09 Nov 2007 16:19:43 +0000 http://programmerjoe.com/2007/11/03/scripting-for-designers/#comment-60250 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, <b>ever</b>. 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. 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.

]]> By: Chris White http://programmerjoe.com/2007/11/03/scripting-for-designers/#comment-58901 Chris White Wed, 07 Nov 2007 05:11:27 +0000 http://programmerjoe.com/2007/11/03/scripting-for-designers/#comment-58901 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. 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.

]]> By: Joe http://programmerjoe.com/2007/11/03/scripting-for-designers/#comment-58112 Joe Mon, 05 Nov 2007 17:51:07 +0000 http://programmerjoe.com/2007/11/03/scripting-for-designers/#comment-58112 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. 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.

]]> By: robusticus http://programmerjoe.com/2007/11/03/scripting-for-designers/#comment-58101 robusticus Mon, 05 Nov 2007 16:59:54 +0000 http://programmerjoe.com/2007/11/03/scripting-for-designers/#comment-58101 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. 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.

]]>