Sorry your browser is not supported!

Hi all, just wondering if its possible to make a scripting language in pro as part of my engine so that i can interpret the script from a file and trigger events, cutscenes, sounds, music etc.

Virtualy every game these days uses a script, and also they are used for basic AI and other stuff.

Can anyone tell me how to make one, any help on how they work and how they should be exported?(E.g. array etc).

Thanks in advance.

Yeah, it's possible. Just make something load up your file and check lines and their data against the various scripting triggers you have hardcoded... not much more complex than loading a .cfg file, but a painstaking process.

Thanks, im glad to hear its possible, but i need a more in depth explanation of how to interpret. I plan to interpret each command in a custom format script file, but have each as a function in my main code. Problem : how to interpret them (strings look at the whole file content, i need a line-by-line interpretation), do i use arrays?, are they fast/will it slow the game down, how can i interpret the parameters?

EG - [play_obj_anim](object no, start frame, end frame)

Ive got a felling this is going to get complex. Bah.

You can read line by line with READ STRING

I imagine you would load each line into a multidimensional array, or type, or array of types. You're going to have to "read ahead", possibly loading in a whole level worth of script at a time. It's only variables, shouldn't be a problem.

How you interpret them is entirely up to you, that's the "engine" bit which is your code.

Actually strings read line by line, not the whole file .

For a quick example--

PlayObject 1,15,15

is a line you want to read. You open up the file and Repeat Until the file ends, reading its data to a temp string. Each loop you check the temp string against a list of possible commands with left$(); for example, if left$(temp$,10)="PlayObject". Then you can use right$() or find-string DLLs to load the paramaters from the right side of the string. Good luck .

Explaining it quiet simple (well, to a point), but it all depends upon the sort of functionality you envisage the language having ?

Do you want.?

* Constants ? (what types ?)
* Variables ? (what types ?)
* Arrays (What types ?)
* Formula Evaluation
* Decisions ? (If / THEN)
* loops ?
* Control changes ? Goto/Gosub
* 1 command to a line ?




A lot of these questions can't really be answered without knowing if you need the language to make control changes/decisions and thus jump forward in the code. Or, do you want to interpret the code from the sources constantly or compile to a byte code equivalent then interpret it (this is faster).... Personally, I find it far easier to load the file into a 1D Integer array and then process it chr by chr. But it depends on the style of the language your going for.

Something that fits an operational style is really easy to set up quickly. You will need to develop several rules that apply to variables and command names though, in particualr if you wish to get more adventurous. For omething like this all yuo'll really need is split routine to cut the string into it's alphanumeric parts, using = + , - / etc etc as delimiters

So something like this,

Add Hello=Stuff+OtherStuff

Is cut into the follow 6 strings

ADD
Hello
=
Stuff
+
OtherStuff


Since the first part is expected to be a command,you'd search for this string in the command database. This data base contains the Command NAme, It's Compiled TOKEN/Opcode Value, and perhaps the basic input template for this command.

So your command definition data statements could look something like this

; Commands Name, Compiled Command OPcode/TOKEN, Input parameter format.

Data "add",1000,"var","=","var","+","var"
Data "sub",1001,"var","=","var","-","var"
Data "positionobject",5555,"var",",","var",",","var",",","var"


So when the command is located in the database. You then attempt to match the remaining strings to the commands input template. If they match up, then dump this data into your 'memory pool'. So we end up with a bunch of codes that represents this line of source code. This is much easier to interpret at run time.

As rather than your compiler store the string back into memory, it stores the UNIQUE opcode token that represents this operation. IN This Case the "ADD" operation. If the operation requires any variables to work on, you'd then store them after the opcode.

Since were storing the operations in numerical format rather than strings, which is commonly referred to as Byte Code. We'd then do the same thing with variables. The only exception is that variables will be represented with 2 values. The first is the TYPE of variable (perhaps Int,Float,String whatever) and the second is the index (offset) of this variable in it's particular variable array/table.

So if you have 3 basic Variable arrays. Each of say 2000 in
size..

Dim IntegerVariables(2000)
Dim FloatVariables#(2000)
Dim StringVariables$(2000)

and thus we defined a rule of a variable type of 1 = integer, 2 = float, 3 = string say..


So the above ADD string source code might compile to look like this in byte code format. Ready to be translated at run time.

1000, 1,40,1,50,1,60

So that data would represent, the ADD command as the opcode is 1000, then the next pair of values are 1 & 40. The first value would the type, it's 1 so it's an Integer, and the second value of the pair is the index into the InetgerVariables array. The same applies to the next 2 pairs of values


So if you think about it for a second, the code is doing this..


IntegerVariable(40)=IntegerVariable(50)+IntegerVariable(60)


Anyway, that's prolly more than enough to get the creative juices following for now..

For the curious this basically describes the rough outline of how the entity parser in Play Basic current works. The PB and K2 compilers are both purely token based (meaning they never deal with strings).

So for those who are curious..

http://www.PlayBasic.UnderwareDesign.com
http://www.Kyruss2.UnderwareDesign.com

Thanks everyone, this looks like its gonna get complicated.

Probably the easiest language by far to write an interpreter for is Forth. In Forth you read a space delimited token and see if it's in the dictionary (Forth's symbol table). If it is, you execute it. If it's not, you try to interpret it as a number. If it's a number, you push it on the stack. If it's not, you have a symbol error (if I remember correctly).

You have words which can define new words and these words can be variables, constants, functions, objects or whatever. Of course, what you end up with is Forth, which not everybody is crazy about. I adapted a version of Forth in C for a project once. It can be built up incrementally so you can start with a simple set of commands appropriate for your application and add the bells and whistles later.