C#: read text file and interpret as script at runtime?

In runtime, how to read a text file (assumed error free) and interpret it as a script, i.e 1/ Create new script class from that text file 2/ Add or remove script to game objects

I think if the first can be done then the second can be done too, but how can I do it?

 

You ask about two different things. One is to have text file driven logic. The second is to have text file defined program data structure - objects.

For first you will have to implement some scripting language that will be interpreted at runtime or use one of the existing ones. I know there's been work done by community on implementing LUA interpreters in Unity.

For the second you want serialization: http://msdn.microsoft.com/en-us/library/ms233843.aspx (not to be confused with Unity "SerializeField" relating to exposing class fields in inspector)

 

I guess you're only asking about the first one. So to answer your specific questions:

2. Use: http://docs.unity3d.com/Documentation/ScriptReference/GameObject.AddComponent.html

1. That depends. If you want to interpret code at runtime (or even modify it at runtime) then what I said before stands.

If what you want is to have C# code in text file and load it at runtime then you need to implement compiler and build assemblies at runtime. Assuming there are ready solutions for that this one might actually be easier but I don't see a reason why you would want to do this.
If you want to allow users to extend you app functionality then you should expose this functionality with API and the users could build they're assemblies and put them into folder where you expect to find them. This way you don't have to build the assemblies yourself and that's beneficial on both sides.

 

No need to implement anything actually, depending of the platform. .NET allows for runtime evaluation.
You can compile and attach the newly compiled assembly using CSharp.CSharpCodeProvider. Of course, it means;

1) You have access to the .NET library (Ex.: Unsure about Mac/Linux, most likely supported by Mono)
2) You're on an environment that allow JIT code. (Ex.: Not iOS or any other closed platform, such as 360, PS3, Wii, etc.)

An easy way for that is by the use of an exposed "plug-in" base class. Let's say you only allow runtime class assembly to derive from "MyInterface", and reject anything that isn't.

Or you could even use Reflection.Emit to create new assembly from scratch using whatever form you wish.

 

Yes. better expressed what I meant by API. When done this way users can use they're own compiler and then deploy the built assemblies on any platform that runs Unity.

 

Just depend if you want that to happen at runtime or not. Like I said, not every platform allows for runtime evaluation and attachement. As a rule of thumbs, closed platform don't allow it. If you meant building a .DLL and attaching it to the executable... again, it's dependent on the platform. Usually, if you're on Windows, Mac or Linux, you got pretty much access to everything.

 

Exactly. From what I understand the way Unity works is the exe is static and when rebuilding the project only dll assemblies get updated meaning the Unity itself loads dlls at runtime

 

Ah, sorry... I guess I had to be more clear on that. The biggest issue is the Webplayer version which is not exactly friendly with .DLL. It's because of the security around internet and browser. Loading unverified DLL from a web source is a very high security risk.

 

Unity uses Mono on all platforms except Windows Store/WP8. It doesn't use .NET for regular Windows apps.

In any case, you can just use eval() with Unityscript; simpler than reflection. (If you know C#, you can learn Unityscript easily enough.) It works on the webplayer. There are certain limitations with the code that can be compiled on the fly, but perhaps more important is the lack of limitations, since people can mostly write whatever code they want. So you may want to reconsider the idea, and use something more restricted instead.

--Eric

 

Well, looks like CSharp.CSharpCodeProvider is also available on Mono.

Another issue to consider is what is deployed; http://answers.unity3d.com/questions/505382/is-there-any-way-to-use-csharpcodeprovider-in-buil.html - http://answers.unity3d.com/questions/364580/scripting-works-in-editor-try-it-but-not-build.html

Sounds like it's not as easy as it should be.

 

I'd probably go the route of integrating Lua or Python into your game and build a "scripting API" instead of screwing around with new assemblies. Also gives you a level of control over what people can actually do.