DBLTW ("DoubleThrow") - Don't Build Languages This Way Kinda stack based. Stack entries are "variables". A variable is anything. Mainly using a stack based VM to make dealing with variables easier. The compiler is going to be odd. It needs to know about EVERY variable used in EVERY script. Variables are persistent. Setting one in one script makes it available in other scripts. The game engine needs to be able to set and read VM variables somehow. Useful game data such as current map and player position should be in variables for the scripts to use. - We say the VM is "kinda stack based" because we skip all the pushing/popping for operations where it's not needed. This may go away. - Variables are assigned "memory addresses" (index into an array) by the compiler. This prevents the need to look up where a variable is stored. - Exported variables are regular variables that additionally get added to a lookup array so the game engine can find their "memory address" by name. - The map compiler needs to generate a script that associates map names with map numbers so authors can use map names in scripts. - Stupidly simple pre-processor for constants. It just replaces tokens/variable names with another value. - All strings must be in quotes. This allows us to easily determine if text encountered in a script should be treated as a variable name or not. - To use a variable in a text string, prefix it with $$. - Do we want to load all script data for a map at once? Or individual scripts? - The compiler should produce statistics on memory requirements that we can send to the game at startup to configure the VM and not waste resources. --- Preprocessor: define include Keywords: export set add subtract if [<,>,!=,==]