As the primary goal for Project Sulphur is to create a user-friendly game engine, there should be a simple way to program your gameplay. How do you program those cool designs that you have lying around? We didn’t want to leave it at “C# is cool, let’s do that” and ended up taking a plunge into the wonderful world that is scripting. In this blog we want to elaborate a bit on the “why and how” we made decisions regarding such a system.

The library

The major purpose of Project Sulphur is to go lightweight, meaning our scripting interface should use a library that is small in size and performant. This was taken into consideration while looking through our grand scala of options. There are so many to choose from!

To name a few, these are the most common languages used for scripting:

• Lua
• C#
• JavaScript
• Python

We shouldn’t reinvent the wheel, so it’s the safest bet to go with something that users are already familiar with. In-house scripting languages are somewhat of an option as well. Then again we’re simply a team of students, not a commercial, state of the art, enterprise.

However, if we were to make a poor decision; designer friendliness would go down the drain faster than the compilation time of a Lua file*. After all, the entire reason we’re even implementing a scripting language is to make their life easier, not harder.

*That’s pretty fast

C# (Mono)

Let’s have a look at C#, what it brings to the table and what it lacks. The first thing we need to know about C# is that it compiles to an intermediate language called CIL, this language will then be run in the engine using Mono.

Using Mono provides us with the big advantage of being able to support multiple scripting libraries and having a debug layer allowing us to connect an IDE (i.e. Visual Studio) to the engine application. This then allows us to debug our code using for example breakpoints and watching variables, which is a huge plus when designing.

Implementing C# via Mono is also really fast, even getting close to the level of LuaJIT at some points^[1]. Another big pro is that it comes with extensive documentation from Microsoft for the base functionalities and with a lot of available code and help online from places like Stack Overflow and the Unity3D forums.

Of course it is not without its flaws, the biggest one being the relatively big library it comes with. This is especially clear when comparing it to the likes of Python (PyPy) and LuaJIT. This is also one of the main points why we have decided to not use it for our engine. Another flaw is that while Microsoft provides extensive documentation for C# itself the documentation for embedding Mono is quite lacking, sometimes having to go as far as having to go through the samples to actually find ways to access certain functionalities, i.e. setting custom memory allocators.

All in all I think mono (and by extension C#) is a great way to do scripting if these flaws are less of an issue for you. It especially excels for people who would like to provide a wide variety of scripting languages as almost every major language has a CIL compiler available (although performance may vary when not using one of the Microsoft languages).

Native scripting APIs (Lua, JavaScript, Python)

A pretty common approach for a scripting interface is to use a native API. Natively implementing a language has the advantage of having a lot of control over the low level functionalities. Aside from this -- in general -- native scripting APIs are also faster than other implementations^[1].

Earlier, we mentioned the three major scripting languages used. From personal experience and usage, LuaJIT^[2] and Google’s Chrome V8^[3] were the two top contenders. Aside from these two, even though more commonly used as an extension language for plug-ins, Python running under PyPy^[4] came up after researching the subject as well.

We then compiled these three languages into a comparative analysis based on a few requirements, namely:

• Object lifetime
• Custom memory allocation
• C++ bindings
• Performance
• Usability
• Cross-platform compatibility

Based on our findings, we assigned a point system to check which scripting language would best suit our needs for Project Sulphur. The language with the lowest points was the definitive “winner” of the analysis.

Picking a scripting language doesn’t end there, however. Of course our designers would have to use the engine to create games. The language should not only be performant and easier to implement; the syntax and methodologies of the language are also very important.

Fortunately for us, Lua is pretty commonly used within modding communities like Garry’s Mod^[5] and big titles like World of Warcraft for their interface customisation^[6]. Designers are potentially already familiar with the language, which is a plus.

Where do we go from here?

We decided to go with the implementation of LuaJIT for the continuation of the project. In the upcoming blogs regarding scripting, we want to tackle more implementation specific topics. Look out for any of the following:

• Hot-reloading of scripts, and their workflow
• Creating class based systems in Lua using metatables
• Communication between C++ and a scripting environment

All in all, we outlined a good portion of the scripting interface so far and are really stoked to deliver the actual system for our designers to use!

Thank you for tuning in and until next time!

References

[1] A. Chaos, “Programming Languages Benchmarks”, [Online]. Available: http://attractivechaos.github.io/plb/.
[2] LuaJIT, “The LuaJIT Project”, [Online]. Available: http://luajit.org/.
[3] Google, “Chrome V8”, [Online]. Available: https://developers.google.com/v8/.
[4] Armin Rigo, “PyPy”, [Online]. Available: https://pypy.org/index.html.
[5] Garry’s Mod, “Lua Tutorials”, [Online]. Available: https://wiki.garrysmod.com/page/Category:Lua_Tutorials.
[6] WoWWiki, “Lua”, [Online]. Available: http://wowwiki.wikia.com/wiki/Lua.