 |
Using scripting languagesNovember 2nd, 2007 |
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.
You can follow any responses to this entry through the RSS 2.0 feed. Responses are currently closed, but you can trackback from your own site.
In games, not so much.
Using scripting languages
[...] 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 [...]
[...] 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 [...]
[...] a comment in the last post : Is there an outline somewhere that one of you professional game people can point [...]
[...] 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 [...]
[...] 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 [...]
[...] [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 [...]
[...] an interesting debate going around about designers and [...]
[...] 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 [...]
[...] 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 [...]
[...] 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 [...]