Is Boo a viable option for Scripting for both PC and XBox360?

Is Boo a viable option for Scripting for both PC and XBox360?

• shmulik_segal

  Thanks Leaf.
  I'll definitely check this out.
  
  -Kevin
  
  

• Duque Vieira

  Boo's core is P/Invoke free (but you can put a P/Invoke in your Boo-based library if you want).
  
  Boo is System.Reflection.* free as long as you do not use duck-typing.
  
  

• llmpro

  I'd be very surprised at this point if any scripting capability was available for XNA. One more question to add to my list.
  
  

• bubu

  Jim Perry wrote:

  I'd be very surprised at this point if any scripting capability was available for XNA. One more question to add to my list.

  
  Lua2IL works, which means you have to pre-compile lua into assemblies... I'm just finishing up some work on this (see another question about the content pipeline).
  
  For me the major benefit of having a script language (specially Lua) is that its easy to customise to a more game play specific form than C++/C#
  
  And also Lua is almost an industry standard, which helps it be used by different people.
  
  Deano
  
  

• lushdog

  Some Random Fellah wrote:

  Boo's core is P/Invoke free (but you can put a P/Invoke in your Boo-based library if you want). Boo is System.Reflection.* free as long as you do not use duck-typing.

  
  
  Note: System.Reflection works fine on Xbox. It is only the System.Reflection.Emit namespace that is missing.
  
  
  

• ap231

  well said leaf.
  
  
  

• learneroob

  As you mentioned, the reason LuaInterface doesn't work on the Xbox 360 is because LuaInterface uses native code (via P/Invoke). IronPython uses dynamic code generation (System.Reflection.Emit) which is not supported on the Xbox 360 framework.
  
  The best place to find out if you can use Boo is to ask the Boo devs if Boo relies on either of those things. Or you could just try it, write some XNA code in Boo and try it on the Xbox 360, or use Reflector to have a look at the generated IL and see if it uses anything odd.
  
  Note: Boo is a full .Net language much the same as C# or VB.Net - if you are using Boo to do 'scripting' it doesn't really offer anything better than just writing your code in C#. They both have to be compiled. Boo does offer an interactive interpreter, like IronPython, but that will be of little use on the Xbox 360. Boo also has different syntax which you might prefer, in which case write the whole game in Boo and skip C# entirely.
  
  I think people writing games/engines in purely managed code don't need to worry about scripting so much. The common reasons for adding scripting to a game don't apply as much when using managed code.
  

  • Sandboxed game code prevents it from breaking the engine: You are already running in a managed environment, with various methods for preventing code from breaking a process.
    
  • Modularity: Assemblies promote writing modular code and you can easily write plugin/addin systems.
    
  • Quicker iterations: C# compiles really quick, and thanks to the easy modularization it's easy to separate engine code from game logic.
    
  • Simpler to program: C# is already much simpler than C++, especially when used with a nice IDE like Visual Studio. There's certainly room for a simpler language but is that Boo or IronPython And as said before, if Boo is nicer to program in then just use it for everything - it compiles to much the same as C# (assuming there are no problems as mentioned above).
    

  The main reason I can see for scripting in purely managed game code is when you want a very specific language which could have much simpler and more direct syntax; these are sometimes referred to as Domain Specific Languages. Creating a DSL for some area of your game is a very interesting idea (e.g. describing a character's actions at a high level) especially if you can offer the users something different to typing commands. The Visual Studio SDK has some interesting ideas and tools for creating DSLs that can be manipulated graphically - similar to Windows Workflow which you could consider as a DSL. The Unreal Engine v3 has its UnrealKismet scripting system which is also based on a graphical representation of nodes. The .Net's Code DOM could also be used to generate code from other representations, like the Forms designer in VS does.
  
  Then again, writing scripting components in managed code is so easy (you've got a compiler built into the framework) that I wouldn't want to dissuade anyone from the fun of writing one. I just wanted to say that its not as necessary as you might first think - especially coming from native game frameworks.
  
  Cheers,
  Leaf.
  
  
  

• PaulFred

  The problem isn't P/Invoke, as much as it is the fact that the 360 uses PPC processors, so the x86 DLLs you have aren't going to work. The Xbox 360 security model apparently allows unsafe code, which means that it could allow native code -- the protection of the system uses memory protection, rather than just the isolation of the VM.
  
  I have written a simple LISP which compiles in C#, and lets you run runtime-created LISP code. You can download it at http://www.mindcontrol.org/~hplus/xna/lisp.html if you want.
  
  
  
  

• pinoyz

  Hmm.. I'll have to look into Lua2IL.
  Which other question are you referring to I'm not sure which one you're talking about.
  
  -Kevin
  
  

• OmegaMan

  Jon Watte wrote:

  The problem isn't P/Invoke, as much as it is the fact that the 360 uses PPC processors, so the x86 DLLs you have aren't going to work. The Xbox 360 security model apparently allows unsafe code, which means that it could allow native code -- the protection of the system uses memory protection, rather than just the isolation of the VM.

  
  
  I'm pretty sure Boo is pure managed code in any case.
  
  Another potential issue, even for languages that do compile to pure IL, is what version of the system assemblies they link against. By default the compiler will probably include the standard desktop versions of mscorlib, System.dll, etc, in which case the resulting assembly will fail to load on Xbox because we are using different versions of those assemblies (different version number, different public key, etc).
  
  When compiling C# code for Xbox, we use a special compiler switch telling it not to link with the default system assemblies, and instead manually specify references to the Xbox versions of these files. Whether this is possible for any given language depends on:
  
  a) the compiler must have a switch to skip including the default system assemblies.
  
  b) the compiler must be able to build against non-native assemblies. ie. when resolving symbols during the compilation process, it needs to load things in reflection-only mode, so it can pull out type information even though the assembly in question may not actually run on the platform where the compilation is taking place.
  
  I have no idea whether these things are true for the Boo compiler, but if not, that can make cross compilation difficult.
  
  I have to say it would be very cool to see Boo code running in Xbox. It looks like a really nice language...
  
  
  
• Is Boo a viable option for Scripting for both PC and XBox360?