Sign in to follow this  
Rob Loach

[.net] .NET Scripting Engine

Recommended Posts

I've updated the .NET scripting engine I've been working on: GakScript Scripting Engine It compiles a number of different languages during runtime in an easy fashion (C#, Boo, VB.NET, J#, etc). From there you can invoke methods, create classes, etc. The new update includes:
  • The new Eval example that compiles the given text into C# code and then executes it, returning the value.
  • Language plugin support - Boo plugin included.
I was just wondering if you guys would be willing to download it and test it out and tell me what's missing or what would be a nice improvement to it. I plan on using this scripting system for a tile mapping engine I'm working on to load tile maps programatically from files.

Share this post


Link to post
Share on other sites
It looks pretty good so far. I haven't messed around with it yet, just looked at the examples.

There's a few things I'm wondering about:

You released it GPL. Is it possible to dynamically link to it without my code being GPL? Or is that only for the LGPL?

Is it possible to keep the script from having access to whatever it was compiled in (if I compile it in Main() in MyClass, can I keep it from having access to MyClass)? I suppose it's possible to get around this by putting everything you want the script to be able to access into one dll, put that dll into a seperate AppDomain, and do everything script-related in there. It would be a pain in the butt, though.

How easy is it to define a class in the script and use it in the parent program? (This one will be easy enough to answer on my own when I mess around with it later.)

If it works well, I'd be interested in using it in a project of mine. I'll do actual testing later, hopefully after my homework.

Share this post


Link to post
Share on other sites
Thanks for the suggestions. With some of your comment, I decided to put out GakScript v1.1.1.... (download)

Some of the updates are:
  • LGPL was a better license for it so it's completely relicensed.
  • I changed the "Modules" to "Types" because in my opinion, Types make more sense.
  • I added in an example the demonstrates the use of inherited classes (what you were looking for). All you need to do is define a base class in your program and then have the script class derive from that class. You can then get the class, make instances of it, and use it to all desire.
  • There was a bug in the Visual Basic plugin DoCode fragment that's now fixed.
  • Other then that it was pretty much administration stuff.

As for assembly security, I haven't really experimented with it. I know that if you don't add the reference to the script, the script won't beable to use the referenced assembly... I'll have to look into this further. Thanks a lot.

Feel free to use this in your project. I'm planning on writing up a particle editor that uses this for easy development of a particle system. Once I have it under way, I'll post what I have. Has anyone else tried this out?

Share this post


Link to post
Share on other sites
Are there any plans to use .NET sandboxing to be able to limit what scripts can do? That way the scripting can be used to enable 3rd party mods without exposing the users system to arbitrary code.

Share this post


Link to post
Share on other sites
I talked with the great Washu for a while yesterday and he suggested using the CodeAccessPermission class as opposed to sandboxing it in another assembly. He even decided to put up an awesome article on Code Access Permissions in .NET. I'll do some research on the topic and do some brainstorming as to how to implement it into GakScript. I also saw a nice post that VizOne made about sandboxing in .NET here. I guess the true question is Sandbox or Code Access, or both. Any suggestions?

Thanks a lot for the help guys and if you have any better ideas for the security, please tell me. Any more ideas for it would be extremely appreciated.

Share this post


Link to post
Share on other sites
I also thought about creating a scripts-engine for my engine and had the same security thougts that are being talked about now.

I thougt you could use an assembly with script relevant classes and only expose that .dll file (at compile time)


Basically you only need a few things for simple scripting ( i maybe forgot something - i just thought about it and actually never developed a full blown script engine :-) )

1. Game Variables
2. Objects - Object Fabric/Manager
3. Events
4. The ability to load other scripts within the script

--- 1. Game Variables -----------------------
i wanted to implement Game Variables like in lua.net:
Game.Constant["Name"] --> you can easyly use this for the ingame console too

and

Game.Constant["Name", defaultValue]

eg.:
Game.Constant["Gravity", 9.81f]; // Sets the gravity to 9.81f if it is not
// already set (differently)

- could be implemented in a single assebly
- coud be exposed with CodeAccessPermissions
- ?

--- 2. Objects - Object Fabric/Manager-------

You add Levels and objects like Boxes and stuff through the script

eg.:
GameObjects.Add(new GameObject( mesh, texture, ObjectAttributes.Something );

This maybe already is in an external Assembly?
- could be hooked up in the same assebly as the GameVariables
- coud be exposed with CodeAccessPermissions
- ?
--- 3. Events -------------------------------

Events like OnJump ...

- same implementationoptions as in 1.

--- 3. Loading other scripts ----------------

1. Completely load a new script
optionally 2. an #include command to just copy and paste some code into the file

---------------------------- Conclusion and other thinkings --------------

If you only expose few assemblies (instead of the whole engine)

pros:
- you could save compilation time because only one or two assemblies get loaded
- you don't need to understand the internal game logic to use the scripts
- easyly extendable

cons:
- You are more restricted can't manipulate the Engine as much as you could do it by loading all assemblies - but I think that deep changes to the engine should be done in the code or by Interfaces ...

--

hmm... i am just going to code a bit and check out how this idea works out...

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this