Scripting in TorqueX

#1 Use C# for everything, possibly use XML to deserilize stuff

#2 C# should certainly work for most places in C++ that you would want a specialized scripting language. If you would certainly prefer to see some of your code in another .NET language you can use it as long as the language itself supports the .NET Compact Framework currently. I've heard F# currently works and that IronPython and VB.NET do not currently work.

#3 Is there a clean way to add new code to your game that is not known at compile time. For example if one creates an RPG and then adds new levels that can be downloaded seperatly. Such levels usually contain some level-specific scripts for setting flags or something like that. Would I have to provide a DLL with the level? Or is there another way to go about this?

#4 @Christos - Yes, you can use scripting languages and tie them into your C# TXE project, but there are steps you need to take to distribute it on the 360 as compiled binaries. Search the XNA forums for info.

@Max - You can only use C# with XNA right now. It wont even recognize any other project formats with game studio express yet unless you hack it in.

@Michael - Hijacking threads is poor netiquette, this question belongs in a new thread. As for answering your question, I'm not getting exactly what you are asking? Are you saying you have code somewhere else that you want executed AFTER the program has been compiled during runtime? Like dynamically adding controls in a web app?

#5 Jonathon, don't be a jerk. Michael's question was on topic.

@Jonathon: There aren't other project formats, but you only need one. C# is the only supported for deployment of the main .exe and the only language currently guaranteed by Microsoft to work on the 360's flavor of the .NET Compact Framework, on the one hand. On the other C# is a Turing complete programming language and it is entirely possible to write (and many have done so) other languages in C#.

Furthermore, the main executable in XNA GSE currently needs to be C#, but the Common Language Runtime makes it possible to reference and make use of assemblies (.dlls) in other languages. Perhaps you may have a few problems with the "Not Supported If Anything Blows Up" barrier (although if bad CIL bricks an Xbox the system has major bugs), but there aren't any real barriers keeping you from compiling a small scripting language inside your C# code, or referencing another language's compiler .dll or already-compiled self-contained .dll just as you would reference Torque X's binary. There's also nothing stopping you from using text resource files as scripts. (If you don't believe me, here's the information on a working F# project: http://letskilldave.com/archive/2006/12/11/XNA-Games-on-the-360_2E002E002E002E00_in-F_2300_-_2100_.aspx)

The biggest real barrier here is only that the Xbox does not support the full .NET Framework but instead has a modified Compact Framework. If you work with Windows Mobile devices you already know the difference and if you don't it should be easy find details.

@Michael: There are several strategies. Here's probably the two biggest:

1) It's very easy to load .NET Assmblies (.dlls) at run time. You can do a search for ".NET plugins" and should turn up a number of strategies and a number of code examples.

2) Just as you might in a C++ application, you could write or find a scripting language in C# that you can embed into your application. Scripts can then be passed around as text files/resources.

The choice is up to you depending on your needs and your project. .NET's dynamic loading is well worth a try and should give you some great performance (after the initial load, obviously).

I hope that helps.

#6 @Max - I don't know you, so I'm assuming you don't know me. Calling names is childish and unprofessional. The topic of this thread is scripting language tie ins to .net, not external binaries or tossing code in at run-time. Since I don't want to start a flame war and you seem to be upset, this is all I'm going to say about it.

As far as the other comments, obviously you could write scripting languages from C#, but that's not what he's after, as far as his post was stating. He was after current scripting languages. If you have time to build your own scripting language, and experience, then this thread wouldn't have been created to begin with.

You can't state that anything will work and use the F# as an example. F# is a hack and slash of C# and runs on the compact framework. To even run it on the 360 you have to do some real spaghetti code and compile it into a C# project. This is neither efficient nor recommended outside of the 'hey cool, i can do it' factor. You can NOT reference ANY language dll's that require the full framework such as visual basic, python.net, etc.

@Michael - If I came off harsh, it wasn't meant to be, I was just pointing that out that you should start a new thread.

#7 @Max, thanks, that was very helpful.

@Jonathan, I don't think my question should go in a new thread. Let me explain how I see it.
What are the benefits of using a scripting language? The 2 most important ones for me are:

1) You can use an easier language like Python or Torquescript that shortens devtime and even your artist can learn it in a couple of hours. (C# might already fulfill this criterea)

2) You can use the scripting language for level-specific code. Think of an RPG like Zelda. You may want to have a small map with a monster that always closes and locks the door if you come near it and opens it again when you go farther away. Such a piece of special-AI that is not useful in any other part of the game should not be compiled into the main executable. It might even not be known that such AI is ever needed at the time the game ships.

That's the 2 things I want to have from a scripting language. If C# already fulfills #1 and DLLs would be a good way to fulfill #2 then it would consider C# DLLs a way of "scripting". The difference between DLLs and .dso or .pyc files is not that big after all.

Do any of you think, that IronPython will ever become available on the XBOX? From the FAQ it does not look like it:

Quote:
Q: Do we work with the .NET Compact Framework?

A: No, IronPython 1.0 targets only the .NET 2.0 Common Language Runtime. The .NET Compact Framework lacks Reflection.Emit and lightweight code generation (dynamic methods), both of which IronPython requires.

Please mind that I am really a .NET newbie :)

-Michael

#8 @Michael - I would say C# is just as easy, if not easier, to learn than TS and Python.

Quote:Do any of you think, that IronPython will ever become available on the XBOX? From the FAQ it does not look like it:

Unless they move from the compact framework, then no it wont ever become available. You can use it with XNA for PC development however.

#9 I didn't fully read this whole thing, and i don't know if the following methods will work on an Xbox 360 BUT

www.codeproject.com/useritems/Run-Time_Code_Generation1.asp

is an example of how you can use C# to compile other C# files


the other advice in this thread seems pretty good, I just wanted to say (and again i didn't read some of the posts that started out negatively), remember the xbox 360 isn't intel its power pc, so unless you happen to have the software that allows you to compile for xbox 360 odds are that using C# is your best bet as that is guaranteed to work

#10 Thanks guys. I guess sticking with C# is the safest solution. Thanks.

#11 Pauliver: The specific techniques used in that article are not compatible with the 360. ALL code on the 360 is precompiled and the "compiler" classes do not exist. There is also no run-time code modification.

There is the ability to load precompiled DLLs as Max points out... but you will not get to the level of fully self-compiling and dynamic modification.

#12 Ah, well its unfortunate that the compact .net framework doesn't contain those compiler classes.

#13 Yea, if you ask me, it was a huge mistake the use the compact framework. I can understand their reasons for wanting to, but IMHO the reasons not to outweigh them.

#14 I'm a pretty big Microsoft fan, but I totally agree with the choice to go with the compact framework. There is just so much stuff that makes no sense on the 360. WinForms, WebForms, crypto stuff, all of the server-side web service stuff... that's not for games.

Now, you could say "Web services would be great for my game..." to which I say, "let's wait for v2..." I bet the networking stuff we see on Xbox 360 is quite a bit different that the networking / web service stuff in the full .NET.

@Jonathon: what are you missing that you NEED?

#15 @Jonathon: No name calling intended, merely a statement on the perceived attitude of your aforementioned post.

Jonathon: "You can't state that anything will work and use the F# as an example. F# is a hack and slash of C# and runs on the compact framework. To even run it on the 360 you have to do some real spaghetti code and compile it into a C# project."

Um... No. I'm a bit of a "language nerd" and "F# is a hack and slash of C#" is entirely wrong. C# is an Algol-derivative by way of C++ and Delphi. F# is an ML-derivative by way of OCaML. There is very little in common other than the fact that both can produce .NET binaries and both can be downloaded from *.microsoft.com. F# certainly qualifies under several of the pieces of the definition of "scripting language": Lisp, the forefather functional language (f stands for functional), is most commonly used today as a scripting language with the big example being its use in Emacs.

I didn't state any language would work, I stated explicitly (several times) that any language that itself supports the Compact Framework could be used in an XNA project. For now it is certainly a smaller list (and Runtime.Emit is indeed a major limiting factor), but there are other languages that support the CF. I think XNA may be an impetus for more "scripting languages" to support the CF.

Also, personally, I don't see any "spaghetti code" involved in the F# example.

#16 @Jason - Just because it exists in the full framework, doesn't mean you have to use them. The point of it is the possibility is there. As for a list of things that I'd want for the 360: web apps in asp.net (why not let us build websites so that you can use the 360 to go on the internet?); array's have to be 0-bound; XML schema validation; Better Threading support; Timers; Memory management (it's set up for battery devices, not plugged in devices, so memory usage isn't optimized for the 360); I could go on but those are some of the main things.

@Max - We'll have to agree to disagree about F# and it's usage in your examples for building XNA games.

#17 Putting something in the framework takes storage space on the console, development time (to port), and run-time memory usage (more functionality in each assembly = less memory for you to use). For me, I'd prefer that the XNA devs spend their time building us GAME DEV tools, and not porting parts of the .NET framework that have nothing to do with game development.

While it might be fun to build your own media center thing, or web server thing, etc... that's not the point of XNA. I'd rather see support for Live, a UI component, and more work in the content pipeline. I guess different people will have different ideas of what's important, but I expect that what I'm saying is closer to what Microsoft is going to prioritize.

#18 To address the original question about using scripting in C# we here at the studio have been using LUA via embedding into C#. I am not supposed to talk about specifics but here is the article I used to get started. With a bit of ferangling (ya I made up that word) we were able to get the lua functions to work on the 360. It has made tweaking and building tools MUCH easier.

www.gamedev.net/reference/articles/article2275.asp

#19 Very good choice. We're going to be hacking LUA into TXE shortly (we're finishing up some 3D support atm and a 2D game)