This may seem obvious to some of you who know the .net framework well, but I thought I''d point out a technique to others in case they hadn''t thought of it. If you''re writing your game with C# (or another dotnet language) and you are thinking about using scripting in your game, for whatever purpose, you can take advantage of the Microsoft.CSharp namespace and invoke the Compiler.Compile() method to generate a compiled assembly on demand from supplied C# code. You can then use the System.Reflection namespace to load the assembly and instantiate its types. This occurred to me not too long ago and I''ve decided to use it in my project (see my sig for details). I just think it''s really cool, the idea that you can have your game scripts compiled to run in parallel and at the same speed as your core game code. :D Snowman | Ardaxus | Nathan --------------------------------- Tangle - Persistent World Toolkit tangle.netlab.com.au

Is there any sort of security model so that I could block access to certain classes (for instance)?

[ MSVC Fixes | STL Docs | SDL | Game AI | Sockets | C++ Faq Lite | Boost
Asking Questions | Organising code files | My stuff | Tiny XML | STLPort]

You need to be in complete "trusted" mode for this to work, and as far as I know, only things like web applications and stuff don''t fall in that zone.

Sorry, I misread your question. When you actually do the compile, you get to specify what references the compiler needs to do the compile. If you don''t want them to have access to something, just don''t pass it is as a parameter. Also, if you don''t want them using something that hangs of the System namespae, just do a regular expression interrogation of their code and remove the namespace reference. Alternatively you could set up their coding environment so that the code is partially filled in with a class name, etc, and the namespaces are already filled in, but the bits you have auto-generated are read only. i.e. they can only fill in the blank area...

I don''t know if parsing it with a regular expression would catch everything. But if you can trust the scripter (ie. they''re not running on a central server, or are part of your design team) this sounds useful.

[ MSVC Fixes | STL Docs | SDL | Game AI | Sockets | C++ Faq Lite | Boost
Asking Questions | Organising code files | My stuff | Tiny XML | STLPort]

Or, you could only let the scripts call functions from a class specifically designed for the scripts. For instance, a script for AI would only have access to the AIFramework class, which includes Attack, Flee, IsHurt, etc. Then they would only have access to the things each script needs and scripting would be simplified. It would still be possible to hang the code (like with an infinite for loop), but they couldn't really mess anything up. You should be able to trust your scripters, anyway.

[edited by - nagromo on March 15, 2004 6:47:59 PM]

The question is nagromo, how do you enforce that limited access?

Some game models need more stringent security on the scripts. I''m not saying this is a problem with .Net scripting, but I was interested in seeing if it can deal with it.

[ MSVC Fixes | STL Docs | SDL | Game AI | Sockets | C++ Faq Lite | Boost
Asking Questions | Organising code files | My stuff | Tiny XML | STLPort]

Gah, I swear I replied to this >_<

Anyway, Microsoft made a game a while back to give developers something fun to do with .Net, called Terrarium. Basically, it was a giant peer-2-peer game of connected ecosystems. Each programmer would write code to create an insect, and then release the insect into the local ecosystem and see how well it spread.

Terrarium

Here is a quote from the Whitepaper:

quote:
Creatures represent mobile code that is transmitted from one machine to the next in the peer-to-peer Terrarium network. Thanks to the .NET Framework’s evidence-based and code access security infrastructure, machines are kept safe from code that might be intentionally or unintentionally harmful.

Generally speaking, evidence-based security in the .NET Framework enables code to be trusted to varying degrees, depending upon its origin and other characteristics such as the identity of the author. These characteristics represent evidence which is used to assign the code in question to a code group, or category, each of which has a permission set which determines what resources can and cannot be accessed by that code. At runtime, thanks to a technology known as code access security, the .NET Framework’s common language runtime (CLR) performs low-level security checks, ensuring that code executes only those operations allowed by the security permissions it has been granted. In doing so, the CLR checks not only the permissions allotted to the assembly attempting a particular operation, but those of all the other assemblies in the stack that might be calling the active assembly to act on their behalf. Only operations approved in this comprehensive stack walk will be performed. Others will not.

Code groups and their corresponding permission sets can be set at the enterprise, machine, user, or application domain level. At runtime, the permissions are intersected, so effectively, machine level settings can only be more restrictive than enterprise settings and so on. With Terrarium, the principal security settings take place at the application domain level. Within the Terrarium application domain, creature code is given execute-only security permissions. That is to say, the code may run, but it is forbidden access to any system resources, such as the local disk, the system registry, etc. While highly restrictive, this policy grants creatures the freedom they require to exist and act in the Terrarium ecosystem, while providing users with the protection they need to participate in this peer-to-peer network.

quote: Original post by Kylotan
The question is nagromo, how do you enforce that limited access?

Quite easily actually. Create an assembly that only contains the public classes you want the scripter to access. Any script you then compile at runtime would only include a reference to that assembly. This doesn''t stop you from having other classes in the assembly, they can be defined as ''internal'' (meaning that they can only be used from within the same assembly).

For example, you could have an AIFramework.dll assembly that exposes your AI interface. When you compile an AI script at runtime you would only reference AIFramework.dll. Even if AIFramework.dll references other assemblies, these wont carry through to the script.