Unity and Lua

Since the last development report, progress has slowed down a little. This is going to be a long post, so I’ll start with some screenshots of what progress was actually made!

Randomly seeded stars

Random tests of the new star seeding system

Unit selection shader effect.

Unit selection effect.

Unit selection. Before & After.

Unit selection is now working!

A test of the new sun effect.

A test of the new sun effect — screenshots don’t do it much justice!

Now on to the long part. I recently made the decision to add Lua scripting to the game. This was going well until I realized one massive problem. Lua does not play nice with multi-threaded calls to lua code. For some, this is fine and they’ll work around it, but for what I want to achieve with the game in terms of modding capabilities, this is unacceptable! 🙂

Here is an example scenario of where the problem is:

  1.  A mod adds a biome generator to the game (used to build planets).
  2. The game needs to call that biome generator’s Lua code/functions/scripts from multiple threads
  3. Luck comes into play and the game will either stutter massively, or completely freeze due to deadlocked code from multiple calls on different threads
  4. Behold, the problem I need to get rid of!

Now there are a couple of solutions (that I can remember right now!) to the problem, but for the direction I have in mind for the game, none of them will allow a decent amount of performance + resource usage:

  1. Spawn separate generator instances per thread — lots of garbage generation to dispose of (which is highly likely if the player is in and out of different sectors constantly)
  2. Load a single instance of each needed generator, then queue requests up on each one – slow, probably needs a loading screen to hide, but would work just fine…but… slow…

In my opinion, modding should be a pleasant experience for both modders and players alike. So I’ve set out a few design rules on this for myself to stick to:

  1. No external tools required to build mods besides a text editor (i.e. notepad, or n++).
  2. No compiling or packaging of mod files needed to make them work
  3. Game must include system for loading mods  and allowing them to talk with each other if needed (so things like helper/framework mods are possible)
  4. Mod support must be built into the game early in development and evolve with it

Which leads me to the last part of this post, the crazy solution!

I’ve started on a multi-threaded Lua interpreter, written entirely in C#, which is also capable of running under the free/indie version of Unity3D. Similar libraries  already exist in many forms, Nlua/KopiLua and MoonSharp being the most popular ones right now. But from my experience so far, they all have one problem. They don’t place nice with multi-threaded game code, as mentioned earlier.

So there you have it. My insane plan. I want a lua library that plays nice with multi-threaded code, so that modders (and myself) don’t have to walk through a minefield any time multi-threading meets scripting.

Before I can get back to working on the game though, I need to have the Lua interpreter working, which is coming along nicely. So, to end this epically massive post, here’s a few of progress shots for those who like the nerdy side of things! 🙂

Lua Interpreter - Day 1

Lua Interpreter – Day 1 – Chopping script code into tokenized bits and tagging each one into a basic category.

Lua Interpreter - Day 3

Lua Interpreter – Day 3 – Added multi-line support and making it figure out what each bit of script code is.

Lua Interpreter - Day 6

Lua Interpreter – Constructing meaningful code blocks from all the bits. This is the last stage before it going of for interpretation into C# code/calls.

Lua Interpreter - Later in day 7.

Lua Interpreter – Later in day 7 — Continuation of day 6 — It now assembles Lua function declarations into usable data in C#.  Still a long way off yet!