© 2000 - Zachary Booth Simpson. Copied with permission from http://www.mine-control.com/zack. If you find any of this work useful, please sign Zack's guest book: http://www.mine-control.com/cgi/gbook-zbs.cgi.
Create a simple and safe embedded language with which game designers and (potentially) end-users can build game logic.
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.
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.)
Not available at this time.
None at this time.
Issues and Risks
None at this time.
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)
Comments? Questions? Feedback? Click here!