Okay, you may remember I made a stupid post in this forum before. I took the time to learn, read some tutorials, and purchase Game Scripting Mastery. So here we go (hopefully I dont make a fool of myself again)! I decided to take a computer independent study this year in school (I am a senior). My goal is to create a simple, assembly like scripting language, hopefully for the use of content creation in games (instead of actual processes). What I mean by this, is call Host API graphic functions and set specific variables for swords, etc. So have a script for each spell, etcetera. So before actually starting the coding of the compiler or the VM, I wanted to flesh out some design documents (good idea, right?). The first I have written actually fleshes out the language itself. I wrote it last night in two hours. If you could please check it out and tell me what you think, I would greatly appreciate it. After I meet with my advisor, discuss this design document (and hopefully incorperate any deisgn issues you guys have!), I am going to flesh out my compilation process in a document and hopefully have you guys look at that! So here is the initial document (text and .doc) .doc | text Thanks for any feedback and advice! [Edited by - visage on September 6, 2004 7:34:53 PM]

I created a minimalist design document for my compiler. It simply has a quick walk through of how the compiler works...nothing incrediably specific.

Here is the document: .doc

If you see any gaping problems, please tell me. Or perhaps any ideas to speed up how to do it?

Thanks
-visage

I took a quick glance and it looks fairly solid. Are you a senior in HS or College? That seems like a fairly advanced task, but you seem to have a good grasp on it.

I'll take a closer look tomorrow and see if I can come up with some sugestions.

Looks good, but bear in mind that if you want this to be a practical language (other than theoretical) you may get frustrated with the assembly-like syntax. You've thought about your language long and hard, which is good. What you haven't covered is how the language will be bound to the host application. I think that this is often overlooked as many languages seem to be designed with scripters, not embedding in mind - as a result, scripting can be horrific to embed within an application without third party tools and code. If you could design a nice way to link C and C++ classes, functions and variables to your scripting environment then it'd be attractive to more people.

Okay! I am back with more! Also, to answer some previous questions: I am a senior in Highschool. I am using the assembly like structure so that I can (hopefully) move to a C syntax next semester, if all goes well. But for now, the ASM syntax works fine for learning.

I thought a good while and wrote some ugly, ugly convoluted test code and finally came upon a method that I like for my Host and Scirpt integration method.

[EDIT: Turns out my ftp server is down, so I cant upload the file? Here it is in all its ... beauty]

Quote:
Voodoo Script Host Integration
Design Document


Calling Host Functions from the Script
General:
Before a function can be called from a script, the function must be registered to the Virtual Machine or the Host class (if it is a host script). All general functions (that do not belong to classes) should be registered upon the initialization of the Virtual Machine. Done simply:

RegisterFunction(Voodoo Machine vm, std::string FunctionName, void(C::*ptr)(int));

After this is done, any script can make a CallHost call to that function, by its function name. So if you have “CallHost function1” in your script, it will call the function who has the name “function1”, even if the actual function itself is “function2.”

Registering Class functions is similar. However, only the scripts that is associated with that class can call the class functions, and they can only be called in that instance of the class. For example: if I create a spell class called “Fireball,” and one called “Lightning,” and registered some function to the Fireball instance, I could not run it from Lightning, even if they derive from the same base class. Each function has to be registered with each instance of the class. The prototype for the registerClassFunction function is as follows:

template<class C> int registerCFunc(C &c, std::string name, void(C::*ptr)(int));

This means that each function registered to the VM or the host class must be of void return (actually pending. Might be int return in final version), and only take one parameter (again, pending. Use VA_ARGs?). The first parameter will always be the stack number ID associated with the script you are trying to run. That way the general functions you design take from the top of the proper stack.

The Class Script:
The Class Script is a script meant to run within a specific class. It can call both Host functions (“CallHost”) and class functions (“CallClassHost”) from the class the script belongs to. Class Scripts, unlike Host Scripts, do not actually belong to the virtual machine, and are in no way controlled by it (which means that loops will greatly effect system performance, because scripts are run straight through, not timesliced). The Class Script’s stack and script data is held within the class itself. More than one class script may belong to a class at a time. These scripts are best suited for data loading to class variables.

The Host Script:
Host Scripts are general scripts, loaded into the Virtual Machine and run (timesliced) by the virtual machine. Their stack data and script data is all held by the virtual machine. To call a host function, you simply have to perform a “CallHost.” These scripts are unable to access specific class information like the Class Scripts are, but can be run side-by-side with other scripts. These scripts are suited better for AI, etcetera.
While Host Scripts cannot access class functions, wrappers can be written so host scripts can access specific classes’ functions and variables. So while you may only be calling the general function “GeneralFunc(int iStackNum)”, it may take the data off the top of the stack and call a specific classes function with that data. Though, that class must already be active: so dynamic class creation is very difficult. Which is why Class Scripts are better for loading data, and Host Scripts better for controlling data, AI, etcetera in games.

Calling Script Functions from the Host
Calling a specific script function is simple.

template<class C> int CallClassScriptFunction (C &c, int iStackNum, std::string FunctionName);

or

int CallHostScriptFunction(int iStackNum, std::string FunctionName);

Each will call the “FunctionName.” CallClassScriptFunction will call the function associated with that function name in the class list of stacks. CallHostScriptFunction will call the function name in the host list of stacks.

Returns –1 if the function does not actually exist.

Revision History
9/12/2004 – visage – Initial Draft Started

Hopefully you all understand that, and it looks good from a programmers point of view. Anything you think I am missing? Any features you would like to see?

Thanks for any feedback or suggestions.


Please note that I am still in the design phase, and any features can pretty easily be added so long as they fit with the overall scheme of the system. So ask away!
-visage

Anyone have any thoughts on this...or should I take your silence as approval for the method?

Cheers,
visage

For variable return types, parameter types, and number of paramaters, you could have a base type Object, which everything implicitly derives from (like in .NET), and have the parameters be a vector of Object*, the return type being Object*, and add a second parameter to the regestering function, saying how many parameters the function should be.

PS: AAAAAAAAAAAAHH! WTF!? The cursor is randomly being placed behing the letter I type, making my words come out wardskcab (SEE THAT!?!? I WON'T DELETE THAT ONE!!!). What the hell is happenning!? It is almost every third word!!

I smell a trojan.

Jimmy...get the gun.

Ah, good idea. I will get to work and see if that fits in my design and really makes sense. Thanks.

Another feature that I just added was the ability to register global variables for the virtual machine. I was thinking of possible uses for my scripting language (remember, for now its just about learning), and realized I didn't want to have to write a wrapper for every variable I wanted to change, like the camera x position or the player position.

So I made it so you can now register player.x or player.y or anything like that as a global variable.

So if we register:

registerGVar("playerx", &player.x);

and in our script write:

mov playerx, 5


player.x would equal 5. You can register any amount of globals you want.




Do people think this feature would be handy? I already wrote all the implementation code for it, and it all works. I think it would be great. It cuts out me having to do something like:

var $temp
mov temp, 5
push temp
callhost SetPlayerXPos //wrapper function to pop stack and set x pos as that value



So, ideas on this? Any other things you would like to see?

-visage