Contents  Introduction  An Overview  Starting from  Familiar Ground  Source code  Printable version  Discuss this article The Series  An Introduction  Data Manipulation  Dynamic Loading  The Stack and  Program Flow

An Overview

Most useful programs, not just games, are not completely isolated systems; without some form of input, a program's capabilities are normally quite static (limited). Think of the difference between a "Hello World!" program, and a program that asks for your name, certain personal traits (which it may then process in some manner), and then spits out some kind of analysis. You could not achieve the same effect without taking some form of input unless you went to some ridiculous effort, such as creating a different program to suit each user's needs.

This would be insane.

This is why most applications are designed as a structure of rules and pipelines through which information flows and is processed, from the input data to the resulting output. It is akin to a machine. This is why the term "engine" is thrown around so often.

For many purposes, this is enough to obtain the functionality you desire from your application or game. But what happens if you want to be able to modify the rules? From a development standpoint, modifying rules which are hard-coded into an application can be very annoying, and in some cases bug-inviting. The annoyance can come in many forms, not the least of which is the need to recompile all components dependent on the source of the changes. This is where scripting comes in.

The main purpose of scripting from a development standpoint is to provide a way to make your application's "rules structure" as dynamic as possible. Game-dependent logic and data, therefore, become prime candidates for scripting.

However, a script has to run on top of code itself. There is additional processing cost for every procedure executed in a script, on top of the script itself. Because of this, scripted instructions inherently run more slowly than the hard-coded kind. This would currently make multimedia components better candidates for remaining hard-coded, although scripts can still be appropriately used to perform some kind of initialization of such components.

Forms of Scripting

One possible way of implementing a system capable of executing scripts is to create a language to be interpreted on the fly. Because there isn't much preprocessing done to generate a format of instructions more tuned to the procedural nature of a computer, interpreters are, as far as I know, one of the slowest implementations available.

The second way is to go a step further, doing as much preprocessing of a script as possible before execution, and then running it through a virtual machine. In this case the instructions are generated as bytecode, with each opcode representing a definitive action to perform, possibly accompanied by some data to use in the process. This idea of bytecode is very useful in other areas of game programming as well, such as in the networking aspect, where the information received from a server can be used to drive the state of the client's game.

Furthermore, the idea of using data as code allows for the code to be reordered on the fly according to some analysis of how the code is currently being run, dictating runtime optimizations. I've heard that Java is capable of this, but currently, this topic will be beyond the scope of this article series.

The scripting system implemented in this series will be of the virtual machine variety.

Next : Starting from Familiar Ground