Something that I have observed is that the requirements and motivations for scripting systems are often very broad, or very vague. We know we need scripting, but we're often not sure what we need it for. Not exactly. And there is where we can run into problems. With a poorly defined goal, we can miss a lot of the benefit we are trying to obtain.
It doesn't help that "scripting" covers a lot of territory. The term is used to refer to:
- Animation drivers (aka blend trees, aka animation state machine)
- Mechanics
- AI
- Mission
- Gameflow
- World Logic
Sure, all of those can be done via scripting, but there is a broad range of needs there.
So if scripting is covering a lot of bases, what makes us think of these as "scriptable" systems? What are we trying to gain through scripting? I have heard a variety of motivations for using a scripting language.
Probably the most common is "rapid development". The argument goes like this: scripting languages are faster to write logic in, don't have compile time over head, and support garbage collection. For these reasons it is more cost efficient to script than to use a "real" language like C or C++.
By-and-large, I buy this argument. You can quibble with the details, and you can argue that code can be made equally accessible, but the general point is that the "business logic" for games don't have the same performance and memory requirements as the underlying game systems. That being the case, how do you maximize your development throughput? Make the job of programming the business logic easier.
By-and-large, I buy this argument. You can quibble with the details, and you can argue that code can be made equally accessible, but the general point is that the "business logic" for games don't have the same performance and memory requirements as the underlying game systems. That being the case, how do you maximize your development throughput? Make the job of programming the business logic easier.
Two parallel but different arguments are simplicity and staff. Script is simpler than code and can be handed to less technically competent staff. I am going to reveal a personal bias, whenever I hear this argument my blood runs cold. Some of the worst disasters I have experienced or heard about were the results of this argument being taken to an extreme. Scripting is coding, straight up. We can talk lots about levels of abstraction and complexity, but at the end of the day scripting is coding and you need to have the correct set of chops. This might be worth its own post.
Another motivation I have heard for scripting, particularly visual scripting, is expressiveness. Looking at a piece of script it is easy to understand what is going on. Questions like "what is going on in this state", "what is the set of states", and "what are the transitions from this state" are easier to answer.
A lot of this expressiveness comes from dealing at the correct level of abstraction. For scripting to be "more expressive" the scripting framework must provide a level of abstraction that is expressing for the target domain. You are probably wondering why I bother to point out this most obvious of details. I don't think many people pay attention to this point. It is critical, and I think a lot of people jump straight over it to the generalization that script is expressive.
A lot of this expressiveness comes from dealing at the correct level of abstraction. For scripting to be "more expressive" the scripting framework must provide a level of abstraction that is expressing for the target domain. You are probably wondering why I bother to point out this most obvious of details. I don't think many people pay attention to this point. It is critical, and I think a lot of people jump straight over it to the generalization that script is expressive.
Another justification for scripting is allowing run-time manipulation of game logic and state. Within a script system, there is a fairly clear path to allow adding and replacing chunks of logic while the game is running. It can be incredibly powerful to iterate repeatedly on a behavior or mechanic, seeing the variations immediately.
Equally powerful is the ability to diddle with the games state in complex ways. I don't just mean flicking switches on and off (those that is pretty darn nice), but running chunks of logic that have wide ranging effects. The ability to hot-load external script during development is very powerful. It allows you to establish a particular state repeatably, which can be worth its weight in gold when developing a feature.
Anybody got other great (or terrible, for that matter) motivations for using a scripting language? I am sure there are others that I haven't thought of here.
Having looked at some of the motivations for why we even want script, next time I'll look at some of the forms that script can take.
Equally powerful is the ability to diddle with the games state in complex ways. I don't just mean flicking switches on and off (those that is pretty darn nice), but running chunks of logic that have wide ranging effects. The ability to hot-load external script during development is very powerful. It allows you to establish a particular state repeatably, which can be worth its weight in gold when developing a feature.
Anybody got other great (or terrible, for that matter) motivations for using a scripting language? I am sure there are others that I haven't thought of here.
Having looked at some of the motivations for why we even want script, next time I'll look at some of the forms that script can take.
Hey! I'm liking the first post, and looking forward to more.
ReplyDeleteScripting languages for games are very odd beasts. One particular excuse I've heard to invoke them is that they can make dealing with deferred actions and time in general easier. A particular flavour of expressiveness, if done well, when you can have a script wait on an animation, sound effect, pathing task or what-have-you and then resume the script without any of that icky explicit concurrent business getting on your clothes.
A couple make really nice data definition languages, as well.
At the moment, I'm finding the interface between scripting and 'native' code to be the tricky bit. Not due to the technical issues, but simply due to impedance mismatch between the languages. If your scripting language is garbage collected or dynamically typed and the host language isn't, that can cause significant pain. In some cases there are spontaneous outbreaks of GC'd C++, which never seems to end well. Using a less icky host language is probably the answer.
Anyway, I'll stop wall o'texting now. And yes, I'm in the 'hating the scripting system' camp ;)
Something I would add, which arguably would be included in the increased productivity and ease of use argument, is that scripting languages are supposed to be less error-prone than traditional languages. More robust (or non-existing) memory handling, point-and-click interfaces and the like at least remove that bottom layer of silly mistakes, and ensure the script can't crash the game (or so we'd like to think).
ReplyDeleteGreat overview of scripting language motivations. Looking forward to more!
Someone suggested to me that another motivation for scripting was a loose binding between code and art. For example, a completely functional UI screen can be build without reference to runtime code except through collusion. Either script or script reflection can be used for runtime bindings.
ReplyDeleteLOGIC as a RESOURCE
ReplyDelete-------------------
Joel, you forget a very important aspect of an extreme engine/scripting architecture we both worked on. That architecture had pretty efficient game engine systems behind (dare I say) a "complete" script interface. The scripting language itself was quite efficient, and terribly robust with somewhat managed memory (no garbage collector). Aaaaanyway... what I liked best about that implementation was that the entire game was constructed in the scripting language which was compiled into files along with all the other resources. It is the only engine that I know of that truely considered logic to be a resource. One of the other great consequences of this is that logic could be streamed. The entire game program did not have to exist in memory at any one time. The logic is also completely platform independent.
Cool blog
~ Scott
@Scott
ReplyDeleteWould it be fair to say that logic as a resource is more significant the tighter the platform specs are? Because there is an irony there that there is a significant benefit to platforms where script is traditionally rejected for performance reasons.