TXScript Diary 2
by Johnathon · 05/18/2009 (1:15 pm) · 2 comments
DotScript 4 Torque X seemed like to much of a mouth full to say and type, so I gave it an official name. TXScript. Which btw, is working and useable. However I am still working on better integration with Torque X so it can take full advantage of what Garage Games has to offer.
The Scripting Engine inherits from TorqueComponent, allowing you to add the script engine to your Base Types and giving them the
ability to execute scripts. Such as creating a Base Player Type, and adding the Scripting Engine to it's components list. You could
create a Player Interface as well, that all scripts will be forced to implement. At this point your Player Type can scan through
all of the loaded scripts in memory, searching for all scripts that implement the IPlayer interface, and then once it's got
all Instanced Types that inherit from the Interface, it can invoke the methods it needs. This way you don't need to know a specific class name, and you can search through
all of the instanced scripts for a specific method such as 'Fire', if there are several 'Fire' methods the Scripting Engine will
generate a warning if debugging is enabled and invoke the first 'Fire' method in the list, ignoring the rest. As development
continues on the Scripting Engine and sorting method will be implemented allowing developers to choose how to sort methods, so if
multiple methods called 'Fire' are found, the Scripting Engine will know how to sort the methods, and which one to actually invoke
based off the Developers priorty/sorting that has been selected.
Next, Hybrid Scripting is supported as well, allowing scripters to just write methods and create properties without declaring a class
name or defining a namespace for the class to reside within. The Hybrid script takes the code the script contains and injects it into
a C# class and namespace. It automatically inherits from TorqueObject and will implement the Interfaces specified by the developer. I am leaning pretty strongly towards forfieting standard C# script files in favor of forcing the Hybrid script, as this allows for all scripts to quickly be updated in the event I make changes to a namespace, or need additional using statements placed in the scripts. It can be done in one location, within the engine itself, and the end users writing the scripts will never need to modify their scripts.
The TODO list for this project continues to grow and I will continue to post updates as work progresses.
The Scripting Engine inherits from TorqueComponent, allowing you to add the script engine to your Base Types and giving them the
ability to execute scripts. Such as creating a Base Player Type, and adding the Scripting Engine to it's components list. You could
create a Player Interface as well, that all scripts will be forced to implement. At this point your Player Type can scan through
all of the loaded scripts in memory, searching for all scripts that implement the IPlayer interface, and then once it's got
all Instanced Types that inherit from the Interface, it can invoke the methods it needs. This way you don't need to know a specific class name, and you can search through
all of the instanced scripts for a specific method such as 'Fire', if there are several 'Fire' methods the Scripting Engine will
generate a warning if debugging is enabled and invoke the first 'Fire' method in the list, ignoring the rest. As development
continues on the Scripting Engine and sorting method will be implemented allowing developers to choose how to sort methods, so if
multiple methods called 'Fire' are found, the Scripting Engine will know how to sort the methods, and which one to actually invoke
based off the Developers priorty/sorting that has been selected.
Next, Hybrid Scripting is supported as well, allowing scripters to just write methods and create properties without declaring a class
name or defining a namespace for the class to reside within. The Hybrid script takes the code the script contains and injects it into
a C# class and namespace. It automatically inherits from TorqueObject and will implement the Interfaces specified by the developer. I am leaning pretty strongly towards forfieting standard C# script files in favor of forcing the Hybrid script, as this allows for all scripts to quickly be updated in the event I make changes to a namespace, or need additional using statements placed in the scripts. It can be done in one location, within the engine itself, and the end users writing the scripts will never need to modify their scripts.
The TODO list for this project continues to grow and I will continue to post updates as work progresses.
About the author
#2
It currently works pretty well, but I want to work the way the scripts are generated into Torque X a little better.
05/22/2009 (8:32 am)
Yes that is the plan. You will write C# or VB.NET styled scripts that your game will actually compile for you similar to how .cs files are compiled into .dso files by TGE.It currently works pretty well, but I want to work the way the scripts are generated into Torque X a little better.
Torque Owner Bryce
Tactical AI Kit