Using C# for game scripts, part 2

re: Using C# for game scripts, part 2

Max Battcher — Thu, 19 Apr 2007 05:19:02 GMT

Here's a quick tip for setting up that Scripts Class Library... Visual Studio does not provide a decent UI for this, but MSBuild supports wild-cards. So, create your Project in Visual Studio and then open up the project's .csproj file in the text editor of choice. Then you can edit in your choice of Compile tags like:

This way you don't need to worry about adding each and every script into the process and all of the latest files will be included on build.

(Quick Caveats: Visual Studio won't refresh it's Project Explorer all that often, and I would suggest not using Visual Studio to Add/Remove any further items after adding in your wild card.)

Game: Scripts and XML Data

Walter Stiers - Academic Relations Team (BeLux) — Fri, 20 Apr 2007 15:22:40 GMT

David's Blog has some recent entries I would like to refer: Using C# for game scripts, part 2 Using C#

re: Using C# for game scripts, part 2

zygote — Tue, 24 Apr 2007 02:21:22 GMT

Very nice work indeed. I have written a scripting engine in c# myself for XNA. I have yet to write an article on it however :)

Ziggy

Ziggyware.com XNA News and Tutorials

re: Using C# for game scripts, part 2

kamil — Sat, 28 Apr 2007 00:42:56 GMT

thank you very much

re: Using C# for game scripts, part 2

Bubu — Sat, 12 May 2007 19:52:19 GMT

How are such scripts debugged???

re: Using C# for game scripts, part 2

Digini — Mon, 14 May 2007 08:30:06 GMT

I just wanted to point out that if you use this technique as it stands you should be careful not to change the scripts too often while the program is running.

There is currently no way in the CLR to unload an Assembly from an AppDomain after it has been loaded. You have to throw away the whole domain and start over. So, this is why the technique David talks about here is cool as long as the scripts are loaded at startup and never change. If you anticipate the need to change scripts a lot during runtime you need to load these dynamic script DLLs in a seperate AppDomain so you can unload it.

If you do use a seperate AppDomain you should be aware that there is some overhead associated with cross domain method calls since the calls actually go through a proxy-stub to ensure the preservation of the security context of the domain.

re: Using C# for game scripts, part 2

Geron — Mon, 18 Jun 2007 17:44:51 GMT

Is there any way to restrict a compiled script from using file I/O etc (or certain namespaces). The compiled assembly will run under the same credentials as the host application I believe. So I want some way to restrict a user from writing "malicious" scripts. Simply scanning the script file and removing all occurrences of "#using System.IO;" etc doesn't feel secure enough. A user might even use ImportDLL-declarations to access unmanaged code!

re: Using C# for game scripts, part 2

dowens — Mon, 18 Jun 2007 21:00:07 GMT

Geron, this is actually one of the biggest drawbacks to this approach; you are not allowed to limit the namespaces that are available. You could probably run the scripts in a lesser access than the app that is running, but I don't know of a way to actually limit the libraries that can be used in a full-proof manner.