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.

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.

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...