Sandboxing and Mod Loading

I've been looking at implementing an API/interface for my game that will allow for mods. What i've gathered is that the simplest way to implement this is just use C# and load them dynamically with System.Reflection.

What i'm curious about is how to best way to enforce a security policy. Obviously I don't want mods to perform malicious activity. Is this something I need to do, and if so has anyone tackled this before? Any suggestions on loading mods and securing them would be great!

 

Bump, as i'm still trying to figure this out.

 

I do not know much about this but this may be useful.
Another thing to try is to have a whitelist of allowed namespaces. That way, namespaces that are potential security risks like System.IO can be identified and would allow you to handle them.

 

It depends on how you intend for players to create mods. Will they load up the Unity editor and make assets there? Access an in-game modding interface? Use an external tool and data files?

Lua is a good choice for letting modders write code. Most modders are already familiar with Lua, since it's a standard modding feature in a huge number of games. You can find a lot of good, free Lua implementations that run well in Unity, such as KopiLuaInterface. And you can provide safe, game-specific functions that will help prevent malicious activity. It's much safer than using reflection with C#, and your modders will appreciate you using a standard modding language.

For art assets, again it depends. A lot of games have a built-in editor that only lets the modder build using the game's original assets. You could use something like Multiplatform Runtime Level Editor for this. Otherwise you need a way to prepare and import data, and this really depends on what data you need. Urban Brain Studios, for example, launched http://play.chatmapper.com/ by using the Dialogue System to import XML files and audio files that are generated by their Chat Mapper software.

 

Thanks random, I looked into this, but unless i'm mistaken Unity does not support the AppDomain functions, so I can't sandbox that way.

An API. I've found that I can load native C# code created as a DLL to allow for mods. This does not require the mods to use Unity nor become Asset Bundles (since that's a pro only feature), however by doing so i'm not sure what code the mods can potentially run that could be malicious.

I thought about this, but i'm worried about speed, however it may just be the route i'm forced to go.

I found out that Unity now can dynamically load resources that are in "resource" folders, so my thought was to just require all mods to be put into project/Resources/mods/<modname>. Not sure if this will work, but that's the plan anyway!

Thanks for the responses, and the Lua solution may be the answer i'm looking for, however I would prefer to use C# since speed may be a factor, and i'm not sure how fast Lua will run in Unity.

 

Many high-performance AAA games use Lua for high level logic and C++ (or C# in Unity's case) for low-level routines. If you want the modder to be able to, say, spawn an object or create a particle system, write the routine in C#. Then present it as a function call in Lua. No speed worries.

So modders will have the original Unity project? (They could have DLLs if you don't want to expose your code.) Assets in Resources folders are compiled into the game when you build it. It essentially creates an AssetBundle that's packaged with the game that you can use in Unity free. This would require modders to rebuild the game in Unity. If you want them to load external data that's not part of the game build, they'll have to use an AssetBundle (which requires Pro) or load from another source such as WWW. (You can use WWW to load local files using the URL "file://...")

 

Yea, I understand how Lua has been used in other games, but I'd still like to see some speed tests with Lua in Unity.. I might just have to do them myself, but thank you for this information.

This I didn't know. I knew about AssetBundles, but didn't know that assets in the Resources folder required a full game rebuild. Using WWW could certainly work, however! Thanks!