A current CACM article recommends game-specific scripting engines. The authors (White, Koch, Gehrke, Demers) review current practice across game architects and find it wanting. Theirs are well-considered suggestions, though the game industry is quite fragmented and shows even less inclination to standardize than the standards-phobic software industry generally. For example, in a project to develop a game to teach computer network defense, we originally planned separate scripting engines to manage the network configuration / behavior and the vignettes. I still favor this approach, but there's little doubt that it would add a layer of initial design complexity that some believe is premature as the game's other requirements are still morphing.
The authors of "Better scripts, better games" are, though, well aware of the challenges this approach would face.
Performance is not the only reason for the runtime to monitor how the game changes over time; it is also useful for debugging. Debugging a game is not as simple as stepping through a single script. Each object is scripted individually,and these scripts can interact with one another in subtle ways. An incorrect data value in one script may be the result of an error in a completely different script. In addition, many errors are the result of user input that is not always easy to reproduce. A script designer needs some way of visualizing which scripts modify which objects and how these objects change over time.
- A CiteULike entry for this paper