Using scripting languages
The latest game dev debate around the blogosphere is about designer scripting. Joe Ludwig says,
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.
No, it doesn’t. Because it means that implementing designers are nothing more than content creators, and that is not what the core job of game design is.
In fact, it’s the most commodified part of game design. The core of game design lies in systems. And systems require massaging and testing and iteration. Doing it on paper is hopeless. At the very least you need to seat designer and programmer together to work like Siamese twins — like a lyricist and the composer. But better yet is to acknowledge that systems, for better or worse, are defined in code. And therefore knowing how to code at least a little is like saying that a painter needs to know how to use a paintbrush, or a composer really should play at least one instrument even if not as master.
As one commenter said over on Zen of Design, a purely data driven system feels like wandering through a database. Well, yes. That’s because that is what it is. You can stick conditionals in everywhere you like, and it boils down to the fact that the inputs and outputs are fixed, a Chinese menu.
Two points I must make even though they are obvious:
- Content creation is still a noble pursuit, and a difficult one. Yes, content is critical, it’s king, etc. It’s just not the core. No system, no content. And there’s a lot more people who can make content than can make systems.
- Bad scripting is bad. Sure. Train your budding designers. Ramp them gradually. Still have the data-driven system, because you do still need content. And feel free to have the scripting designer prototype and iterate, and then port the final result over to a robust programmer-created system.
It’s also worth pointing out that a designer who only works inside of data-driven systems will not have a career path and training path to learn systems design unless they are given access to system modifications. So I strongly advise designers to find a way to learn to code.
Again, it’s not about being as good as a professional programmer. It’s about understanding the tools of your chosen medium well enough to actually work with them.
In fact, you can go back through this post, and substitute “Excel,” “presenting,” “visual design,” and “writing.” The gist of the post would be exactly the same.
48 Responses to “Using scripting languages”
Sorry, the comment form is closed at this time.
Using scripting languages
Wholeheartedly agree. Its also key to understand programming at least a little and at least from a theoretical level to be able to have really good productful chats with programmers. If only so that they don’t feel like you have no idea what you’re talking about when you ask if they can do something. Asking the impossible when you understand its impossible and are just trying to get as close as you can is far easier to swallow than being asked the impossible because the person doesn’t know enough to realize its impossible and instead expects it to be done in two days.
The same goes for a game designer and understanding as many of the tools that people will use to interact and flesh out the systems their designing. Understand as much as you can about art and programming and scripting and playing so that you can understand how your iterations will effect everythign down the line.
We’re not talking about mastery, but a basic understanding that doesn’t take *that* long to achieve.
[…] boils down to the fact that the inputs and outputs are fixed, a Chinese menu. […] Pingback by Raph’s Website » Using scripting languages — 11/2/2007 @ 10:34 […]
I think that good designers need to be able to understand code – how it works, how it fits together, how it interacts with other code. At the same time though, if you spend a lot of time coding it’s easy to fall into the trap of being constrained by your tools. Good design requires that people can think outside of the box, that they can come up with something and then say things like “why can’t we do this?”
So yeah, designers doing psuedocode, scripting, etc. can be helpful, but I still think that maintaining a healthy seperation between the role of designer and programmer is very important.
Except that the problem isn’t an issue of language, it is about the actual systems. As you note,
This has nothing to do with whether the system is controlled via a scripting language or C. One could argue that the poverty of most contemporary game design comes from the lack of creative, applicable, or new “system” development.. not the languages used to create those systems.
So, can Joe Ludwig’s scripters control or modify the system, or just work with the systems defined by the programmers / actual game designers.
[…] order for this post to make sense, please read this entry in Raph Koster's blog. I've also reposted it at the bottom of this […]
I find that this sort of idea pops up every so often, and usually fails. It’s not that a purely data-driven technology is such a bad idea, it’s that history suggests that all such technologies were saved from failure only by turning them into one of the following two classes of successful technologies:
1. Those that provide a powerful (relative to the problem domain) embedded language for interacting with it’s features. Relational databases fall into that category, as would command line shells, etc.
2. Those that provide a clear interface for hooking other technologies into it. Operating systems’ interface for starting other software would be the most important, if not the most visible example.
Creating a purely data-driven system seems like an exercise in futility to me. What’s especially annoying is that if people /do/ graft on features to turn a technology into a representative of one of the above classes, the new features usually don’t fit in well with the rest of the design, and turn the whole into a pretty ugly mess.
If you want to plan for the future, think about making the use of your technology as flexible as possible. /Especially/ when you want people to be creative with it. When it comes to games, either embed a general-purpose language and provide some API bindings to the language, or just provide a clear way for creating such API bindings for any language.
Is there an outline somewhere that one of you professional game people can point to that describes, in general terms, the people involved (by title/position) and what they actually do in a game-production team? What does a ‘designer’ do? And I’m sure that varies a great deal with individual projects and particularly with team size, but I’d love to be able to follow along with these conversations.
Steven Davis wrote:
It sort of depends on how you define “the systems.” We have a huge number of conditions we can test and results we can apply, and add more every week. We also have fundamental systems that the designers use as building blocks of bigger systems: factions, status effects, stat modifiers, DOTs, client notifications, messageboxes, inventory items, missions, etc. Putting those blocks together in new ways builds new systems.
For instance, one of our designers decided that he wanted a system that allows players to be able to collect flags off defeated enemies and turn them in to NPCs for a reward. So he added a skill that requires that the target be a derelict ship (which is sort of our equivalent of a corpse) and as a result rolls on a loot table to generate one of a set of items he created. Then he created a set of missions that allow players to turn those items in for a reward. Is that a system or is it content?
Raph wrote:
I completely agree with the first part. I’m very interested in the scrum-based organization they’re using at Bioware to get the programmers closer to their customers (by which I mean designers and artists) instead of putting them on their own isolated team.
I think programming is a great skill for a designer to have. Many of our designers have some level of programming/scripting ability, and those that do have a much easier time understanding how things really work. I just don’t believe that their interface to the actual game should be through a scripting language. I think a data-driven system plus programmer time is a much better way to go.
This is all generally speaking, of course. I’m sure there are designers who can write production-quality code just as there are programmers who can generate production-quality art. I still wouldn’t want to build a team or develop a game around assuming that you’re going to fill all the design positions with those people.
[…] a comment in the last post : Is there an outline somewhere that one of you professional game people can point […]
As a general rule : designers should not code.
Designer should design the system (on paper, yes), let the programmer do its magic work, test the programmed result and finally make change/feedback to its initial design doc. Repeat the result as desired.
Good business practice in IT are also applicable to game development.
– Grinless
In IT, a spec is more capable of reflecting intent. 😛 In games, not so much.
Programmers are not black boxes. Programmers often don’t implement the design as specced (and a paper-only designer cannot tell).
A paper-only designer cannot spec well, either. They can only spec desired inputs and results, and not guts. Good games are in the guts.
Lastly, the iteration loop needs to be FAST. Like, < 1 minute for adjustments. There's a reason why in IT, you also see people moving to agile methods.
[…] up on Joe and Damion’s posts, Raph says “a designer who only works inside of data-driven systems will not have a career path and […]
Im a big BIG proponent of seeing more AGILE methods in IT, but having designer design and coder code has nothing to do with using AGILE or not, it is just about having a good team architecture.
Fast iteration (your
*sorry for the trucated post above, I dont know what happenned*
Im a big BIG proponent of seeing more AGILE methods in IT, but having designer design and coder code has nothing to do with using AGILE or not, it is just about having a good team architecture.
Fast iteration (your less than 1 minute) should be done using data driven applications, exactly as described by Joe.
Design by designers and code by coder WILL result in better design and better code. It is almost a no-brainer.
That limits iteration to only data (obviously).
Well, my actual point was “designer should be coders.” 🙂
The underlying point is that game design is algorithm design.
Why do I need a scripting language to design systems? Yesterday I designed a system by which pirates are able to convert captured ships into any ship of similar size (to solve an issue we have with the rate at which pirates acquire new ships). This is an entirely new game system, and it’s built entirely on the data-driven tools Joe’s talking about.
The thing is, I have a lot of tools. A huge number. I have building blocks out the wazoo, and with those blocks I can build just about anything. And when there’s something I can’t build, I can ask the dev team for another block that lets me build that. Or I excercise some design discipline, and ask myself ‘How badly does the game need that particular block?’ It turns out that not every ‘great’ idea I have that implies a shit-ton of work is actually worth investing design time in, much less code time.
What’s more, I designed the building blocks in the first place. I wrote the specs that caused things like ‘skill handlers’ and ‘results-generating cargo’ and ‘effect objects’ and ‘structure deeds’ to be coded. I’ve also been running each of those building blocks through many iterations with the dev team, until each of them does basically what I need it to. And almost every time I think there’s some piece of design work I can’t do, it turns out I really can do it with the existing tools.
Where I think scripting would be valuable: pre-production. We’ve thrown away a fair amount of code while iterating (for instance) ship combat, and some of that could have been avoided with some quick-and-dirty script prototypes. I say this based on the amount of value I’ve gotten out of writing a set of php scripts that model economic activity — it’s become my default tool of choice for making design decisions about the economy.
But the outcome of my economic work is this: last milestone I did some path-based analysis of the resource layouts of the four nations, and discovered some inequities, and adjusted resources to put ship construction goods at comparable distances for all nations. I did the adjustment by changing some entries in an XML file that I originally created, based on specifications I wrote and handed to the dev team. Then I looked over the labor costs for various recipes, found some bottlenecks in food production, and therefore adjusted the time required to make bread. I did that adjutment by changing some values in an XML file, as above. As well, I revised tax rates for foreign merchants, and also adjusted a merchant skill that reduces taxes, so that the merchant edge in production would have a slightly higher gold value. That involved changing some values in an XML file and an ini file, as above.
If that’s content creation, I guess I’m a content creator. But from my perspective, it’s me taking responsibility for the systems I designed, regardless of who actually wrote the code that makes the systems go. The success or failure of a data-driven system has nothing to do with whether or not I wrote the code; it has everything to do with creating smart, useful building blocks and knowing how to use those building blocks.
So, is it enough to know just a bit of scripting to get a design for a system to a point, that at least illustrates with some guidance during explanation to a programmer?
I find knowing concepts (And some of the lingo) can go along way towards explaining to a programmer what your looking for.
So, to be clear — I am not at all dissing data or systems that enable more powerful use of data. I am just saying they are not sufficient in and of themselves.
Isildur, just from what you have described it’s clear that you ARE a systems designer and you DO know code, and you DO use it to prototype, and that you pretty much fit exactly what I said. 🙂
The question for me, in a setup like that, is how do more junior folks learn to do what you did?
As a tangent, I should also point out that it is entirely possible to get a data-driven system to the point where it is effectively a language. At that point, you’re back at scripting, just with a very different UI. 🙂 Not knowing what you guys have to POTBS, it may be you have elaborated a system up to that point.
“…how do more junior folks learn to do what you did?”
My junior folks are actually better at it than I am. Actual conversation:
Drew (designer): [crazy stuff about how to make a nested result list work]
Brady (senior dev): Do you ever feel like we’re in too deep?
Drew: Every day.
Heh, so those junior guys you have are ALSO scripting designers. 🙂 That’s great, but it’s not the example I was referencing.
I have often had on my teams large quantities of folks who only know how to fill out tables — even tables with conditionals. For that matter, I have also frequently had folks who have only worked within systems, not created systems from scratch. And the path for them to become systems designers IS hard. Scripting is an on-ramp for that.
Isildur daid he wrote the spec from where the code came from, not the code itself. As should be.
When a designer code he is wasting precious DESIGNING time. His very area of expertise.
Algorithm design can and should be part of the design spec, but good specs contain sensibly more info than just algorithms.
And, yes, good data driven application tend to become a kind of pseudo-script, the idea here is to have the coder set the limits of this pseudo-scripting environnement.
– Grinless
Raph wrote:
You mean programmers ARE black boxes, they’re just a little buggy and often have their own agenda. 🙂
Much of the work our programmers do is to add new building blocks for system designers, mission designers, and artists. In those cases the new feature doesn’t really get into the game until the designer (or artist) tries to use it to do something. That’s where they find the discrepancy and get the programmer to fix it. Keeping that designer-programmer-designer iteration loop time down as low as possible is important.
True! Why must there always be gray areas!?! 🙂
He also said:
You can design on paper, on a whiteboard, in Word, in Excel, and yes, in code. It’s not necessarily time wasted. 😛
Of course they do.
[…] all began with Joe’s post. Then Damion picked it up. Then Raph did. Then Sara did. Joe, you created a […]
[…] o facto de se poder notar nesta descrição a omnipresença da programação ou código, recuperei um outro post do Raph Koster que fala exactamente da necessidade dos designers saberem programar pelo menos um […]
I absolutely grant you that.
But is code really the tool of choice when it come to design ?
It sure is not in the rest of the IT industry, I wonder how game developpment differ so much from any other software developpment.
By the way, im french speaking, so if any of my english sound a tad retard, please do not hold it against me…
– Grinless
I think that one key difference is that in most of IT, you are building towards known outputs. In games, you are building towards outputs that are unknown to some degree.
For example, building a UI in a game, sure, you can do that with a detailed spec in advance and test against it just fine. You aren’t really creating algorithms and systems.
But if you are trying to make a game system, then the tool that gives you the most immediate feedback is the tool that actually changes the system. That’s why even the data-driven tools that are described in this thread tend to have conditionals support, rapid feedback, and so on. They are close to the code. And you don’t know what you are looking for, in some ways — you can get exactly the output you wanted and not have it be fun.
Oh — and no, code is not always the best tool. Back here, I actually said “don’t design in the code!”
But for iterating and massaging the system — sure, being hands-on makes it much much easier.
There is no question that a designer who knows coding can be a huge asset when it comes to rapidly prototyping a design. There’s nothing more rapid than someone with a vision who knows how to implement that vision.
It’s also true that a little knowledge can be dangerous. A designer who knows some coding may unintentionally hamper the design by wedging it within the boundaries of what he or she is familiar or thinks is possible. This is why it can be advantageous for a designer to focus on the “what” and have a dedicated coder focused purely on the “how.”
But any such debate is unwinnable because it’s entirely situational. Sometimes the first case will provide the better results, while other times the latter will. It depends both on the people involved and how they happen to approach the problem that must be solved.
Finally, the following Raph statement:
is true but should be followed by an asterisk. Because it’s not about content or systems, it’s about quality content and quality systems. I’m not convinced it’s easier to find someone to make quality content than it is to find someone who can make quality systems, though surely there are some metrics somewhere that prove me wrong.
[…] [HTML][XML][PERM] on Fri, 02 Nov 2007 19:26:02 -0400 Following up on Joe and Damion’s posts, Raph says “a designer who only works inside of data-driven systems will not have a career path and […]
In any interface design, you encounter a variety of users with different experience levels (and requirements).
As an interface designer, you can design the interface to be really easy and do one thing well, at the expense of flexibility. (At the extreme: Press one of five buttons and create one of five stock virtual worlds.)
Or you can go for flexbility, but your tool will be more difficult to use. (At the extreme: C++/assembly)
Or, you can create a bi-modal system with an easy-to-use system, and a different flexible-but-complicated system. Unfortunately, bimodal systems invariably require users to learn TWO UI’s: The first is the easy system. The second is the flexible system, which they have to learn when they realize that the easy system doesn’t do what they need.
Of course, your content design team might contain both designers (who use the easy system) and designer-scripters (who use the complex one). If a designer needs something that the easy system can’t deliver, they bother the designer-scripter. (This is what Joe Ludwig is basically doing, and what Microsoft does with “testers” who don’t know coding, and “programmer testers” who write code for automated testing.)
IMHO, designer-scripters should use a scripting language, not C++. A different set of skills is needed for the core engine functionality.
[…] an interesting debate going around about designers and […]
I wish that when people referred to quality, they would define what they mean by quality. Informally, you could be talking about anything. Formally, you could be talking about quality as in the degree of tolerable defects in a product.
What are you talking about when you refer to "quality"?
[…] Raph Koster really gave the whole thing legs, with a thought to what’s good about designer scripting apart from it can be done when all the programmers are busy. It’s also worth pointing out that a designer who only works inside of data-driven systems will not have a career path and training path to learn systems design unless they are given access to system modifications. […]
[…] started a kerfuffle on the subject of designers writing scripts. Since my original post was more about our experience with Lua than […]
With a scripting system you can easily fall in the trap of having your designers write too much code. With a purely data-driven system it’s easy to end up with your programmers doing too much design. Both pitfalls can be equally damaging to the productivity of the team as a whole.
I tend to prefer giving designers more freedom to iterate and experiment. Programmers can provide an initial set of tools, and then oversee the designer work to identify when complexity escalates beyond what designers are trained and to handle efficiently. Programmers can then support the designers by abstracting, optimizing and refactoring the systems and algorithms that designers come up with, as well as the tools that the designers use to build said systems.
A good rule of thumb is that every line of code / script that a designer writes should have a rather direct influence in what the player sees.
For the record, I love wandering through databases.
As someone who does both jobs for IT systems but also has to cat herd: in a RAD, the data-driven tool generates the tedious, repetitive, gotta-have-it-but-don’t-enjoy-it parts. The programmer fills in the rest. And no, specs are generally just as bad and worse, a lot more boilerplated.
The RAD is a very good tool for cat herding. It means better maintenance, easier to follow structure, in a word, consistency.
Now the question is, is the value of a game five years past its release the same as for an IT system of equal cost to develop?
The difference between a virtual world and a database is enormous except for the wandering given a bad UI. Creatively, I agree with you, Raph. From a management perspective, I’d hate to be signing the time sheets.
What is assembly language, but a very efficient data-driven system? You get given a few million boxes, and get told that putting certain values in boxes will achieve certain results, referencing other boxes to bring in extra information. The processor does the dirty work of interpreting the data and operating the system based on what it reads. All you have to do is decide which data to give it.
Of course, after putting up with this for a while, people decided that it would be better to invent some sort of compromise between this and natural languages, so that the data could be generated in a quicker and more intuitive way. And thus, programming languages were born.
I am being a little facetious there, but ultimately I feel that any purely data driven system of any degree of complexity will eventually evolve to a point where you’re either continually asking coders to give you new building blocks to work around limitations of the old ones, or your blocks become so generic that you require new tools – new languages, essentially – to attach them together in an effective manner.
Languages are both powerful and user friendly at the same time, tools that we know are almost infinitely scalable from the youngest child to the most literate author. It’s a shame that this isn’t more widely recognised. (But then, look at how rare it is for developers to have something like The Sunday Poem on their blogs… I think that says it all, really.)
[…] Raph’s Website » Using scripting languages A discussion of the role of scripting in game development. […]
[…] often show them how it is possible.) Other people have other strengths, and this is the point that Raph and Sara are talking at each other about. Someone like Sara, with a background and keen interest in […]
[…] starts with a blog post about data driven design, Damian Schubert continues it and Raph Koster piles in. Very intersting reading.Now none of these people have even heard of RML. I wonder what […]
This just sounds like Chris Crawford’s distinction between process intensive game mechanics, and data intensive game mechanics, as expounded in his book The Art of Computer Game Design back in the 1980s. I still cite him on that often, to this day.
[…] Raph’s Website » Using scripting languages (tags: metaplace) […]
[…] merely coming up with a cool idea and selling it to someone else – it’s about systems, as designer Raph Koster points out in a recent blog entry. Games are active and the design must manage the flow of the players and the non-players through […]
[…] people have other strengths, and this is the point that Raph and Sara are talking at each other about. Someone like Sara, with a background and keen interest in […]
[…] […]