Intent

Create a simple and safe embedded language with which game designers and (potentially) end-users can build game logic.

Problem

Many game problems are inherently algorithmic. However, it is often desirable to allow designers and customers to create this logic without recompiling the game. Script languages are Interpreters which are designed to simplify the implementation of game specific puzzles or features.

Solution

A language is designed with a small library appropriate for the game. A parser is typically implemented which translates this code into virtual machine code which is then loaded into the game and interpreted. Alternatively, the game may choose to implement the parser directly into the game and avoid the compilation step; this is called "immediate execution".
It is a common problem with Usecode implementations that they become very unwieldy. They have a tendency to grow and grow in scope until the problems they are solving might as well have been implemented in the native language (C, for example). If Usecode is used, it is best to keep a very limited scope on its implementation. When more sophisticated logic or libraries are needed, revert the native language. (A common solution is to use dynamiccly linked libraries with standard interfaces for this.)

Structure

Not available at this time.

Examples

None at this time.

Issues and Risks

None at this time.

Related Patterns

Controller, Interpreter

Uses and References

Thanks to Richard Garriott. Name evolved at Origin from "usable" objects and their associated scripts in the Ultima series.

Discuss this article in the forums

Date this article was posted to GameDev.net: 6/19/2001
(Note that this date does not necessarily correspond to the date the article was written)

See Also:
Design Patterns