Scripting Roundtable (Saturday): Roll your own (Josh's Notes)
- Topics:
- Direct interpretation vs. tokenizing vs. bytecode
- Language features
- Table driven languages
- Target audiences?
- Threaded code?
- Customized off-the-shelf languages
- Form-based scripting languages
- Editting tools
- Debugging tools
- Implementation technology
- Time to develop
- When/why use custom vs. off-the shelf?
- Control over memory -- maybe even elminate dynamic memory entirely
- Start w/ small expression parser, grows
- Big language, found many small uses (e.g. console)
- If grows too big, is the problem a complex grammar or large interface to C (someone voted for the second)
- Target audience: designers who tweak, not time critical code
- Reload script without rebuild or even exitting game
- Domain-specific grammar key reason to make a custom language
- High level of integration with game and control at all levels
- Very high level language
- Designers/artists aren't programmers, don't like even simple languages; one alternative is for a dedicated scripter to give pieces to artists (who tweak parameters). For some scripters, using prefab components was the only solution.
- Some concensus that having several "layers" (don't touch it, use pre-fab components, scripting in script code, C++ code) to accomodate all the different aptitudes.
- GUI languages
- What about documentation/training?
- Even with manual, glossary, etc. no one used it
- Copy an existing language (esp. C) and use off-the-shelf books
- Sample scripts seen as very valuable -- designers prefer this to documenation hands down
- Some users want Visual Basic
- MEL like Visual Basic, nice that whenever they use menus, it outputs the equivalent MEL code to another window
- Black and White: Some fans will disassemble the p-code
- If the scripting system is simple enough, documentation can be short or even just a few pages
- Released to the public? If so, even more documentation needed.
- Scripting system for Diablo 2 was only being used by the programmers, was too slow, they just threw it away
- Others found that there was a magical experience allowing designers to experiment if they took to the tools
- Implmenetation issue: Binding to C functions
- Template metaprogramming worked for one
- COM? (a suggestion no one had tried)
- Having the internals of the script language be very compatible with C++ worked for another
- Having very little crossing over, separate domains
- Some found it to be a major pain, worth spending some time to make it easy
- Game Programming Gems I has a trick using DLL export
- Scott Bilas gave a talk on this, search the net for papers
- SWIG used by several
- Backend
- Byte code common
- That virtual function design pattern
- "Threaded code" (bad for threading, good for speed)
- Parse strings at run-time, tokenized -- found to be slow with lots of ugly string manipulation by the people who used it, not recommended
- Baldur's Gate and Planetscape: Torment: compiled dialogs when loaded, ended up slow with really big dialogs
- Output C/C++ code that is compiled. Lionhead guy: convert script to C++, launched compiler in background to regenerate DLL, told game to reload DLL (can even use one DLL per function) -- get speed of C++ code and almost as fast iteration of scripts.
- Lionhead guy: prototyping a JIT for particle systems (one or two others tried this too): found it not that big a performance improvement given the work involved
- Running many scripts at once
- Some used a stateless approach
- Others maintain thread-local and global state
- Multiple virtual machines with no communication
- Debugging
- Printf common
- Some created a full debugger
- Another idea: Visual .Net debugger with CLR
- Several people targetting consoles. Ditto with PCs