would you use a script engine (like this) if available?
by Ryan Rogers · in Torque X 2D · 02/22/2009 (10:23 am) · 8 replies
If there was avaiable on the market a quality script engine designed specifically for XNA use, would you use it for your TorqueX (2D or 3D) game, assuming it was sufficiently complex to warrant the use of a script engine (ie multiple developers, dedicated level designers, etc.)?
Such a script engine would be bytecode interpreter based, and can compile code on any XNA target platform, or pre-compile in the content pipeline if desired. Integration into the host application would be straightforward as any host type can be registered for use directly within script, and you can also invoke script static methods directly form the host. Host instances can be registered as well, and are directly accessible from script. Of course, such flexibility is open to abuse...
The available scripting languages would be (not all available in 1.0 ;-)
C#
VB.Net
J#
Delphi.Net
IronPython
LUA.Net
In short, there would be a parser and byte code compiler for each of the above languages, and "dot net" script source files of any of those languages can be built dynamically within XNA CLR, and interpreted, on demand.
Scripts of different languages could be comingled easily, and interoperate fully, since it is all the same bytecode underneath at runtime. There are obviously some limitations, like using uint's on public interfaces in C# and trying to access it from a VB.Net script.
A standalone script debugger would be provided, which could also be hosted as an add-in to visual studio (non-express versions only). All of the normal debuging operations including edit and continue would be supported for windows deployments. A built-in "watcher" game component would also be provided, which would allow you to see and even tweak script values within the game itself. Hooks would be available to implement even more robust debugging functionality into the game itself if desired.
Upon termination fo the edit session, any changes to the scripts could be reviewed and individually approved for merging back into the project source. For Windows deployments this would be automatic. For 360 deployments, modified scripts would be written to a game-save memory card automatically, and using a Datel or similar memory card reader script changes could be imported back into the development PC, and then approved or rejected as normal (including auto-approve if desired).
So at an extremely high level that's what it does. Would anybody be interested in such an engine for use in their XNA games? I have the engine already, but am thinking of possibly productizing it specifically for XNA use.
I know C# is extremely flexible and many of the concerns addressed with script engines in larger games can be overcome through creative use of reflection, attributive programming, etc. Furthermore, some of the problems solved with a traditional "script engine" for a C++ game engine aren't as big of problems when working with C# given it's "Edit and Continue" feature. However, that feature is of little use for the 360, which is something this script engine is meant to address.
As far as licensing goes, the script engine would be either free or dirt-cheap in binary form for non-commercial use. Source licenses would be available per dev seat in both Indie and Professional versions. Indie version would have a yearly revenue cap as well as logo display requirement; Professional licenses would have neither. I haven't settled on a price, but obviously it would be less than TX2D / TX3D licenses.
And of course, there would be complete documentation as well as lots of samples to get one up and running.
So, does this sound like something anybody would use?
Such a script engine would be bytecode interpreter based, and can compile code on any XNA target platform, or pre-compile in the content pipeline if desired. Integration into the host application would be straightforward as any host type can be registered for use directly within script, and you can also invoke script static methods directly form the host. Host instances can be registered as well, and are directly accessible from script. Of course, such flexibility is open to abuse...
The available scripting languages would be (not all available in 1.0 ;-)
C#
VB.Net
J#
Delphi.Net
IronPython
LUA.Net
In short, there would be a parser and byte code compiler for each of the above languages, and "dot net" script source files of any of those languages can be built dynamically within XNA CLR, and interpreted, on demand.
Scripts of different languages could be comingled easily, and interoperate fully, since it is all the same bytecode underneath at runtime. There are obviously some limitations, like using uint's on public interfaces in C# and trying to access it from a VB.Net script.
A standalone script debugger would be provided, which could also be hosted as an add-in to visual studio (non-express versions only). All of the normal debuging operations including edit and continue would be supported for windows deployments. A built-in "watcher" game component would also be provided, which would allow you to see and even tweak script values within the game itself. Hooks would be available to implement even more robust debugging functionality into the game itself if desired.
Upon termination fo the edit session, any changes to the scripts could be reviewed and individually approved for merging back into the project source. For Windows deployments this would be automatic. For 360 deployments, modified scripts would be written to a game-save memory card automatically, and using a Datel or similar memory card reader script changes could be imported back into the development PC, and then approved or rejected as normal (including auto-approve if desired).
So at an extremely high level that's what it does. Would anybody be interested in such an engine for use in their XNA games? I have the engine already, but am thinking of possibly productizing it specifically for XNA use.
I know C# is extremely flexible and many of the concerns addressed with script engines in larger games can be overcome through creative use of reflection, attributive programming, etc. Furthermore, some of the problems solved with a traditional "script engine" for a C++ game engine aren't as big of problems when working with C# given it's "Edit and Continue" feature. However, that feature is of little use for the 360, which is something this script engine is meant to address.
As far as licensing goes, the script engine would be either free or dirt-cheap in binary form for non-commercial use. Source licenses would be available per dev seat in both Indie and Professional versions. Indie version would have a yearly revenue cap as well as logo display requirement; Professional licenses would have neither. I haven't settled on a price, but obviously it would be less than TX2D / TX3D licenses.
And of course, there would be complete documentation as well as lots of samples to get one up and running.
So, does this sound like something anybody would use?
#2
C# is already a rapid development language though.
I guess in the C# world it would be useful when you want to make real time changes. Maybe for online types of games or rpgs or something.
I mean you could use it the same way you would in a C++ have the script be your game and just write the engine in C#, but I'm not sure you really gain anything with that. Seems like if you are going to do it that way might as well just go with regular Torque.
Also. I'm not sure that the performance would be up to par.
02/24/2009 (10:27 am)
To be honest, It's really hard to say. I think for some types of games it would be useful and for anything written in C++ because you can more rapidly develop your game content.C# is already a rapid development language though.
I guess in the C# world it would be useful when you want to make real time changes. Maybe for online types of games or rpgs or something.
I mean you could use it the same way you would in a C++ have the script be your game and just write the engine in C#, but I'm not sure you really gain anything with that. Seems like if you are going to do it that way might as well just go with regular Torque.
Also. I'm not sure that the performance would be up to par.
#3
Taking C# as an example, C# is already an excellent language. It would be easy to allow modders/scripters to extend the game simply because .NET does not require any design-time linking etc. Your assembly libraries' public interfaces are already exposed - for free, no need for script binding. Furthermore, everybody can get a free copy of Visual C# Express, so there's a free IDE for your modders/scripters. Add the functionality to compile your mods/scripts from within your game (on the regular .NET framework, not on the compact framework, so not on the XBox itself) and it seems to me your game gets powerful "scripting" functionality for free! Apart from the edit-and-continue feature, I don't see a reason to use a custom scripting language.
Just my two cents :)
02/24/2009 (11:05 am)
I wonder why exactly one would want to use a scripting language in a game developed based on the .NET framework. Are there any reasons to favour this over the CLR?Taking C# as an example, C# is already an excellent language. It would be easy to allow modders/scripters to extend the game simply because .NET does not require any design-time linking etc. Your assembly libraries' public interfaces are already exposed - for free, no need for script binding. Furthermore, everybody can get a free copy of Visual C# Express, so there's a free IDE for your modders/scripters. Add the functionality to compile your mods/scripts from within your game (on the regular .NET framework, not on the compact framework, so not on the XBox itself) and it seems to me your game gets powerful "scripting" functionality for free! Apart from the edit-and-continue feature, I don't see a reason to use a custom scripting language.
Just my two cents :)
#4
For example, using this engine it's possible to write all but about 10 lines of your entire XNA 360 game in VB.Net or J# (Framework 1.1 compatible), but you do pay quite a performance hit for this capability.
Yes the edit and continue on the xbox is nice, but I'm wondering how much it really buys you, especially since you have to use an alternate debugger, and you can edit and continue by simply retargeting Windows, even if temporarily?
- Rhino
02/25/2009 (11:50 am)
Thanks for the feedback guys. I had similar feedback over in the XNA forums. It seems that the most interest in using a product like this is not as a scripting engine, but as a tool so that you could write XNA games completely in a non-C# language.For example, using this engine it's possible to write all but about 10 lines of your entire XNA 360 game in VB.Net or J# (Framework 1.1 compatible), but you do pay quite a performance hit for this capability.
Yes the edit and continue on the xbox is nice, but I'm wondering how much it really buys you, especially since you have to use an alternate debugger, and you can edit and continue by simply retargeting Windows, even if temporarily?
- Rhino
#5
If it is true your scripting engine allows you to write your game in a fraction of the code-effort required compared to using regular C# and XNA, maybe you could market this as a Domain Specific Language. A DSL with the domain obviously being games. One could "model" games (to speak in Microsoft terms, check Microsoft DSL Tools for Visual Studio if you want to learn more) in stead of writing piles of code.
Substitute your compiler / bytecode virtual machine with a compiler that compiles to C#, MSIL, or even uses reflection emit to directly compile to .NET assemblies, and you might have a great product there. In fact, with some more effort, you could make it compatible with existing .NET languages.
Anyway, just some ideas :)
02/25/2009 (12:39 pm)
Yes, I think using a scripting engine per se is not a great plus in this form. However, what you are saying might have some interesting potential.If it is true your scripting engine allows you to write your game in a fraction of the code-effort required compared to using regular C# and XNA, maybe you could market this as a Domain Specific Language. A DSL with the domain obviously being games. One could "model" games (to speak in Microsoft terms, check Microsoft DSL Tools for Visual Studio if you want to learn more) in stead of writing piles of code.
Substitute your compiler / bytecode virtual machine with a compiler that compiles to C#, MSIL, or even uses reflection emit to directly compile to .NET assemblies, and you might have a great product there. In fact, with some more effort, you could make it compatible with existing .NET languages.
Anyway, just some ideas :)
#6
Sounds like a pretty difficult feat, but I'd bet that would be the best target market for such a tool.
02/26/2009 (7:42 am)
I think your best "Market Research" is not going to be done in forums where people have C# programming exp. I think there IS a pretty good market out there for people who don't know anything about programming but want to make games. If you can make your scripting languages in a way that allows 100% novice programmers to get into game programming it may be a worth while effort. It will have to be easily integrated into an engine though. It might make sense to have it 100% torquex based so that you sell it as a plugin to torquex then the novice can use the TXB to build their scenes and potentially write simple scripts to make stuff happen.Sounds like a pretty difficult feat, but I'd bet that would be the best target market for such a tool.
#7
03/01/2009 (11:39 am)
Yes, I also think that being able to write an entire TX2D game in a non-C# language (like IronPython) would be of great interest folks. I know that I'd definitely be interested in such a product.
#8
One of the features would be "Publish to XNA..." whereby it would under the covers, if Visual C# Express is installed, build, compile and even deploy automatically. Since C# Express is not open to extensibility, this would be prohibitively ugly and brittle code, but it could be made to work, and would therefore allow people with CC memberships to run this game on their 360 without knowing anything about C# or XNA.
In fact I could make the installer quite smart, and first inspect to ensure that Visual C# Express and XNA and TX2D are installed, and if not detected, prompt with a list of missing required components with a check-box for each unchecked, and offer to download and install them. If the user agrees, checks each item, the installer would lookup the download URI's off of my site per item (just in case they move), as well as the command necessary to install them successfully (just in case it changes). It would then download and install them, in silent mode if supported. If the user did not explicitly check and item and installed without that 3rd party component being downloaded and installed, they are perfectly capable of doing so, and the app will "work", but they won't be able to build XNA games. They could however build any other application types.
Yeah, it's pushing it a bit. ;-) But I've seen this done many, many times, and done it a few myself. The 3rd parties are of course more than welcome to prohibit this by making registration and active login be required in order to get to their downloads...thereby forcing the end user in this case to register, download, and install it for themselves.
Ryan
03/02/2009 (8:18 am)
Thanks for the feedback guys. I've been digging into this aspect further, and of course the TX2D license expressly prohibits the building of a game creation tool. However it seems that this would apply only if the application redistributes TX2D (it's worthless without it). If the TX2D is independetly downloaded and installed by the user, such a "game builder" could be done, but it by itself wouldn't do anything. I know similar projects have been done in the past, such as the MMO Kit, which was only usable if you were a Torque licensee.One of the features would be "Publish to XNA..." whereby it would under the covers, if Visual C# Express is installed, build, compile and even deploy automatically. Since C# Express is not open to extensibility, this would be prohibitively ugly and brittle code, but it could be made to work, and would therefore allow people with CC memberships to run this game on their 360 without knowing anything about C# or XNA.
In fact I could make the installer quite smart, and first inspect to ensure that Visual C# Express and XNA and TX2D are installed, and if not detected, prompt with a list of missing required components with a check-box for each unchecked, and offer to download and install them. If the user agrees, checks each item, the installer would lookup the download URI's off of my site per item (just in case they move), as well as the command necessary to install them successfully (just in case it changes). It would then download and install them, in silent mode if supported. If the user did not explicitly check and item and installed without that 3rd party component being downloaded and installed, they are perfectly capable of doing so, and the app will "work", but they won't be able to build XNA games. They could however build any other application types.
Yeah, it's pushing it a bit. ;-) But I've seen this done many, many times, and done it a few myself. The 3rd parties are of course more than welcome to prohibit this by making registration and active login be required in order to get to their downloads...thereby forcing the end user in this case to register, download, and install it for themselves.
Ryan
Torque Owner Ryan Rogers
;-)