Additional Content
by Glenn Thomas · in Torque X 2D · 09/10/2007 (2:04 am) · 9 replies
Is it possible to allow users to install game content that is created after the games release? I'm creating a game that plays differently based on the character chosen. I wanted to release additional characters for the game for player to download after it's release without having to download the complete game again with additional characters. Ideally if we can find a way to do it without ruining gameplay (and this first problem is resolved) we want to allow Torque X owners the ability to upload their own created characters. My small but efficient team doesn't know if we'll be able to do this without tracking who's purchased the game and have the player download the complete game again with additional content. Any input on this matter would be greatly appreciated.
#2
09/10/2007 (10:20 am)
Yeah it gonna be a challenge but should benefit the community if we figure it out. We keep at it and I'll keep you posted.
#3
09/10/2007 (3:57 pm)
Note that you can add Lua to C# XNA if you want scriptability. See http://www.gamedev.net/reference/articles/article2275.asp for an example.
#4
09/10/2007 (4:54 pm)
That was a nice article I've saved that for reference. Thanks.
#5
The problem specifically may be the lack of some Reflection methods on the 360 version of the framework:
From the referenced LuaForge Tutorial webpage, the method behind adding Lua scripting to C# relies heavily on C#'s ability to use Reflection (taking apart it's methods for dynamic use):
Someone may commit to the scripting after they find it works fine on Windows only to find out too late specific methods they need are absent on the 360 framework. I don't know if they are or not, but I'd look into it further before you get too involved.
Thomas can maybe clarify, but my guess is the lack of those particular methods on the 360 is possibly one of the reasons there is no scripting in TorqueX?
09/10/2007 (10:00 pm)
Make sure you look into the Lua stuff before committing to it. I was reading it and had just finished reading some of the TorqueX preliminary documentation and foresaw a problem if you are planning on deploying via 360..The problem specifically may be the lack of some Reflection methods on the 360 version of the framework:
Quote:Torque X Documentation
Object cloning requires you to implement the CopyTo method on all your objects and components. The CopyTo method must copy all public properties not marked with the TorqueCloneIgnore attribute. If you fail to do this you will get an assert in debug mode which will tell you exactly what lines of code need to be added. You might be wondering why you have to implement the code if the program can tell you what lines of code to add. The reason has to do with missing reflection methods in the compact framework on the 360. For this same reason, the assert will not occur if you are running in debug on the 360.
From the referenced LuaForge Tutorial webpage, the method behind adding Lua scripting to C# relies heavily on C#'s ability to use Reflection (taking apart it's methods for dynamic use):
Quote:Using Lua with C# by Martin Echenique
If you don't know what reflection is, a brief introduction is in order. If you do, just skip to the next paragraph. C# (like Java) has a very nifty feature: reflection. In a nutshell, it lets you rip apart any class, property or method at run time, without needing to know anything about it at build time. The MethodInfo instance we have to pass to the Lua VM is the reflected method taken from the object. We'll make use of it for quite a lot of things later on.
Someone may commit to the scripting after they find it works fine on Windows only to find out too late specific methods they need are absent on the 360 framework. I don't know if they are or not, but I'd look into it further before you get too involved.
Thomas can maybe clarify, but my guess is the lack of those particular methods on the 360 is possibly one of the reasons there is no scripting in TorqueX?
#6
--C# is managed code, more powerful than TorqueScript itself (fully object oriented, etc), and can be accurately considered a "super-script language"
--Writing a C# parser for TorqueScript didn't make much sense at all, when C# fits all the needs of a scripting language
--one of the main purposes of a scripting language was to allow players to "mod" a game without having access to the source, and C# allows for just as much flexibility in modding in this style as a scripting language would
The reflection issues (and more importantly, restrictions of other types in the compact framework) are a consideration as the documentation notes, but not necessarily for this particular question. For example, the main reason their isn't an editor for GUI's is do to not having full reflection on the 360 (I honestly don't know the specifics, but that was the answer I got when I asked the question internally).
09/11/2007 (8:41 am)
Yes and no one the decision (and Thomas, Adam, or another dev might jump in here as well), but in general, there were 3 reasons for no scripting equivalent to TorqueScript in TorqueX:--C# is managed code, more powerful than TorqueScript itself (fully object oriented, etc), and can be accurately considered a "super-script language"
--Writing a C# parser for TorqueScript didn't make much sense at all, when C# fits all the needs of a scripting language
--one of the main purposes of a scripting language was to allow players to "mod" a game without having access to the source, and C# allows for just as much flexibility in modding in this style as a scripting language would
The reflection issues (and more importantly, restrictions of other types in the compact framework) are a consideration as the documentation notes, but not necessarily for this particular question. For example, the main reason their isn't an editor for GUI's is do to not having full reflection on the 360 (I honestly don't know the specifics, but that was the answer I got when I asked the question internally).
#7
I think I may try to find out some more infromation about using the C# engine for dynamic scripting with the 360's XNA framework to determine what can and can't be done. Perhaps there are no problems, or perhaps there will be some requirements as to what kind of new functionality can be used.
It shouldn't even be anything near as difficult as say the TMMOKIT (PG) since it's the same language using the same engine (can't remember the class).
09/11/2007 (4:28 pm)
Yeah Java is the same way in that you can use type reflection for adding scripting features (using Java itself for the scripting within a Java program similar to using C# for scripting within a C# program). The engine is there in both frameworks, I think as far as even using C# scripting it really probably depends on what features are needed and what features are missing 360 side. If you are de-serializing new classes then there may be reflection problems there, but I don't know enough about what the 360 is missing or the specifics of the C# engine requirements. Most of my next gen lang programming has been enterprise Java including reflection and RMI for extensibility and remote execution.I think I may try to find out some more infromation about using the C# engine for dynamic scripting with the 360's XNA framework to determine what can and can't be done. Perhaps there are no problems, or perhaps there will be some requirements as to what kind of new functionality can be used.
It shouldn't even be anything near as difficult as say the TMMOKIT (PG) since it's the same language using the same engine (can't remember the class).
#8
@Stephen - I'm new to C#, so pardon me if I've missed something. But are you saying that users can write C# code (without having Studio or Studio Express installed), and have it accessed by my game? If this is true, I think a mini-tutorial is in order along the lines of the Lua tutorial that I linked to above.
09/11/2007 (4:40 pm)
@Kevin - I've only been working on Windows games. But thanks for the heads up on 360 reflection limitations.@Stephen - I'm new to C#, so pardon me if I've missed something. But are you saying that users can write C# code (without having Studio or Studio Express installed), and have it accessed by my game? If this is true, I think a mini-tutorial is in order along the lines of the Lua tutorial that I linked to above.
#9
www.vsj.co.uk/dotnet/display.asp?id=417
Compiling and Executing C# on the fly
www.ziggyware.com/readarticle.php?article_id=98
MSDN - Any scripting support?
forums.microsoft.com/MSDN/ShowPost.aspx?PostID=635814&SiteID=1
The last thread seems to have an answer but I don't know whether it still holds or not. It's in regards to the 360.
Also try checking out Microsoft.VSA which would allow you to use JScript, VB, or C# as a scripting language I believe.
Alternatively you could write your own but it's always better to find a resource and not re-invent the wheel.
I think maybe VSA (Visual Studio for Applications) may be a good choice, though I don't know it's performance.
09/11/2007 (5:20 pm)
There are several ways to do it I believe. One is to dynamically compile at runtime, there's the Microsoft.VSA (which may not be integrated yet),a nd then there may be some sort of Engine class similar to Java you can use. I don't know if any of these methods are available Compact, but here's an example of the first one:www.vsj.co.uk/dotnet/display.asp?id=417
Compiling and Executing C# on the fly
www.ziggyware.com/readarticle.php?article_id=98
MSDN - Any scripting support?
forums.microsoft.com/MSDN/ShowPost.aspx?PostID=635814&SiteID=1
The last thread seems to have an answer but I don't know whether it still holds or not. It's in regards to the 360.
Also try checking out Microsoft.VSA which would allow you to use JScript, VB, or C# as a scripting language I believe.
Alternatively you could write your own but it's always better to find a resource and not re-invent the wheel.
I think maybe VSA (Visual Studio for Applications) may be a good choice, though I don't know it's performance.
Torque Owner Thomas Buscaglia