Fast Pre-existing embeddable scripting language I can use in C#

I am working on a "building game" (in the same vein as MineCraft, Roboblox and Dwarf Fortress). Obviously this开发者_如何转开发 game will be completely brimming with objects that interact with one another. I'd like to use a scripting language to describe the objects and their behaviours. Since these scripts will be executed in rapid succession, I need to find a scripting language such as lua, python, etc that is both very fast, and easily integrable into a C# program. Bonus points for specific information on how to implement.

---

IronPython http://ironpython.codeplex.com/ is well mantained easy to interop with your application, and you can even compile it programmatically to be faster in your game. A quick start example can be found here: http://www.codeproject.com/KB/cs/C_Sharp_and_Iron_Python.aspx once yoiu read you for sure get the idea on how to start. Other thing, since IronPython is based on the DLR Dynamic Language Runtime MS library, it should be easy to change the engine without changing hyour main program infrastructure. Just for completeness I will cite as well http://boo.codehaus.org/ boo. This language was for sure earlier than the other one, and there is a book about writing DSL's from it ( look over the net for DSL languages in boo I don't want advertise here ), whith I think you can grab from idea to make your game script looking better.

---

You can use C# :P It's possible to compile and load .cs files at runtime.

And since C# is statically typed the scripts will be rather fast(just as fast as any other (non ngen-ed) C# code. And of course the compiler is already included with .net.

See CSharpCodeProvider

The main weakness of C# as scripting language is that it needs to compile a whole assembly at a time. So it's not well suited for an interactive command prompt.

---

IronPython and IronRuby stand out as obvious candidates since they are .net languages. The only downside is that they are no longer actively developer by Microsoft. That may not matter since they won't stop working, but they may not move on to new .net versions too rapidly.