Managed Scripting Engine Beta

Managed Scripting Beta 1 is finally available for download, providing support for source compiling, batch script compiling and runtime code generating with the help of its code building classes. The scripts can be compiled during your applications runtime, and it provides instancing of classes, method invoking and property access during runtime as well.

What does this have to do with Garage Games? This was implemented to allow Torque X users to have a scripting engine that they can build scripts and just execute their game without needing to do any pre-compiling within visual studio. The engine works how the Torque Game Engine works, compiling the scripts during the apps startup, with the exception that the compiled scripts can be held in memory during runtime and dropped after the game is closed.

At the moment the engine can compile any script passed to it, but the Code Building classes will provide support for XNA based projects (allowing for GameComponent and DrawableGameComponent objects to be created during runtime), when it is released, which will allow developers to develop visual editors for their script editors similar to that of Unreal's Kismet.

The engine is easily implemented into existing projects, with the following example showing the engine compiling the scripts during it's startup, holding the compiled scripts in memory, and instancing the class.

The following example shows the engine compiling source code provided to it via a text box.

ScriptingEngine engine = new ScriptingEngine();
engine.CompileStyle = ScriptCompileStyle.CompileToMemory;
string results = engine.Compile(txtSource.Text);

engine.InstanceObject("MyScript", "MyNamespace", null);
ScriptObject obj = engine.GetObject("MyScript");

//Invoke the method and convert 
//the returning value into a string
string name = (string)obj.InvokeMethod("GetMyName");
MessageBox.Show(name);

and this is the code contained within the text box

namespace MyNamespace
    {
        public class MyScript
        {
            public string GetMyName()
            {
                return "Billy Bob";
            }
        }
    }

The end result is a message box being displayed showing 'Billy Bob'.

Next I have an example of how the engine would be used with a Torque X project. The Game scans a 'scripts' directory for all of it's scripts, adds them to an array and passes the array of scripts to the compiler for compiling. Once compiled, each Type within the newly compiled assembly is scanned to see if it inherits from GameComponent, and if it does it is added to the games component list. You can also check if it inherits from DrawableGameComponent or any of the Torque X components if you want. This is supported in Beta 1. Generating dynamic classes that inherit from GameComponent and DrawableGameComponent during runtime however is not until Beta 1.1.

ScriptingEngine engine = new ScriptingEngine();
string[] files = System.IO.Directory.GetFiles("Content/Scripts", "*.cs");
string results = engine.Compile(files);

Type[] types = engine.GetAssembly.GetTypes();

                foreach (Type t in types)
                {
                    if (t.BaseType.Name == "GameComponent")
                    {
                        engine.InstanceObject(t, new object[] { this });

                        ManagedScripting.ScriptObject obj = engine.GetObject(t.Name);
                        GameComponent gc = (GameComponent)obj.Instance;
                        this.Components.Add(gc);

                    }
                }

With that example, each one of the scripts that where compiled and inherited from GameComponent will be included in your games components list and act like any other game component. This makes it nice for quickly exiting your game and making a change to the script file, then re-starting your game.

At the moment the engine allows for compiling scripts into memory or locally to an assembly file. If developers compile their scripts into memory, then they can easily add the functionality for re-compiling and re-instancing scripts during runtime, allowing you to edit your scripts while your game runs, re-compile during your games runtime and see it's re-compiled results. If the developer chooses to compile the scripts to a local assembly, then the game will need to be shut down before re-compiling the assembly, as the assembly is placed within the same domain as the game, and thus can't be over-wrote until the domain is released (game shut down). Beta 1.1 should have assemblies being generated within their own domains, allowing for runtime re-compiling with local assemblies as well, however local assemblies shouldn't really be needed with game development.

Managed Scripting is available and runs on Windows via .NET 3.5 and on Linux with Mono.NET 2.4. I have an XBOX360 and Zune version of the engine under development and they will be ready when the next version is completed over the next month or so, and this will allow you to develop your Torque X projects using the scripting engine, and deploy your game to both Windows and Xbox platforms with no re-scripting needed, however XBox games will need their scripts pre-compiled into a local assembly using the scripting engines compiler. At which point the assembly is loaded during runtime on the xbox and treated as it would normally be on windows. It just wont be able to compile the scripts during runtime due to Compact Framework limitations. Documentation will be provided on the 360 and XNA part of the engine when they are released.