First off, I'm going to make some assumptions. You know a programming language (this idea should work in any, but I have it coded in VB), but it's a little object orientated. You know what scripting is - i.e. your game engine doing stuff on it's own accord. Whatever source code snippets I include in here will be in VB or psuedocode, but seriously, if you know C++ or Java then you'll have no trouble interperating it. Also, you'll probably find me a bit wordy, but it explains it all. Also, there won't be any copy / pasting of my hard earned source code into your projects - it will work better if you write this engine to your specs, not mine.
By "fast scripting" I don't mean quick to code - that's "lazy scripting". No, fast scripting is a way I dreampt up (as have many others, I dare say) that eliminates most parsing and syntax checking and tokenizing, and all the other joys of interpreted scripting. You see, that all takes CPU time. We're programming games here, and we're *always* using too much CPU time. But face it, somewhere in your game engine / editors you'll need a syntax checker for scripts and parsing and all that stuff. So why not delegate that responsibility to the script editor? When you're programming a script editor, I'll wager you're not so concerned about frame-rates and all the other fun stuff that separates the men from the boys. But how do we get rid of lexical parsing / tokenizing and stuff like that? My game engine has none of that, and my script editor has none of that either. Scripts are each only a few bytes at max so far - it's very compact (and I'm also using compression, but that's another story for another time), and the important thing is that my game engine reads and executes them, and it does it fast. Hence the name, "fast scripting".
The Script Anatomy
/me pulls out a surgeon's knife - let's open this up.
While I was tinkering around with making Assembly grahpics functions, I thought it was pretty simple:
Instruction Data. Instruction Data.
You tell the CPU what you want done, and pass it data. The program was made up of many instructions.
Guess what! A script is a program written in the programming language you're about to make! So, wouldn't it be a reasonable idea to "borrow" the ASM idea for our own use?
A "Script" is made up of "Instructions". Instructions may or may not have "Data". Instructions are always followed by another Instruction, unless it's the last instruction.
I've found that the best way (after finding out the hard way) for me to represent this is to have a class called CScript, and a class called IInstruction. (You'll find I prefix the name of interface classes with an I, and general classes with a C)
IInstruction does nothing - it's an interface for all the different types of instructions you have. Each possible instruction has a class. My scripting language allows for things like "End Script", "Simple If", "Set Variable", "Show Window", and they are represented by the classes CEndScript, CSimpleIf, CSetVariable, and CShowWindow respectively. BTW, I have more than just these 4 :-P CEndScript implements (or extends if you want) IInstruction.
IInstruction has the following members:
IInstruction has the following methods:
CScript has the following members:
CScript has the following methods:
If you do not know what interface classes are, then learn! This will be hard to understand at the best of times, so I really don't want to imagine learning this stuff without knowing about interface classes.
You'll probably have to read that again, I'm hopeless at explaining things. But basically, the CScript class contains one linked list of IInstructions. It's all simple!