Sharing Lua States

[EddieRingle]

Hey all. This is my first post here, but I've been following the AiGD series for quite some time.

A guy I know from another forum (if any of you have ever heard of a game called Uplink by Introversion, then this guy worked on probably the biggest mod of the game, called Onlink; he also recently bought me a shiny new GTX 580 as a gift) started work on a cross-platform 2D game engine capable of using a variety of different backends for it's different parts (SDL/OpenGL/Direct3D for graphics, SDL/OpenAL for sound, etc.). I've been interested in game development for quite some time and just recently got really serious with it. My first goal is to write a better Minecraft client (because the current Java implementation uses WAY too much resources). In order to do that, I've started converting this engine from 2D to 3D.

Anyways, I've just recently learned more about Lua. This engine already included the lua library, the engine itself did not wrap around it any way, however. I took it upon myself to add a Scripting system, and so far I've gotten a basic Lua subsystem up capable of running scripts with a single call.
The way I have the system set up is pretty simple, create a new state in the constructor and destroy that state in the destructor.

The scripting object is initialized when the engine is started and destroyed when the engine exits. In that sense, all scripts ran share the same state, meaning I can declare variable 'hello' in one script and print it's value in another, which I find handy. Is this the optimal way of doing things or might there be underlying issues that I haven't accounted for?

[Falco Girgis]

I believe that is really the most desirable way to handle it. We do it almost the same way, except that we use "threads" for each separately executing script (that have descended from the same state).

It almost pains me to see how many people embed Lua into game engines and literally create an entire new state for the Lua interpreter to execute every new script. That is NOT a good design.

If you can get away with using one state/thread for everything like that, absolutely go for it.

[EccentricDuck]

I came across an article/forum posting on slashdot this morning that reminded me of this topic:
http://developers.slashdot.org/story/05 ... ith-Python

I was wondering what your thoughts were on their approach, and I figured it was strongly related to the current topic. It's very obviously different from what you recommended with Lua, since Stackless (an implementation of Python) inherently uses a model based upon separate threads (and therefore, I'd assume states) for each actor. The key difference is that Stackless is actually designed with this in mind so it's incredibly efficient at running several "micro-threads" without the traditionally associated overhead. To quote the article:

The main feature that makes Stackless so attractive for use as a scripting language is the support for tasklets. Tasklets make it possible to create “micro-threads”, allowing the programmer to switch among several execution threads that only exist in the python environment and have no dependencies on the underlying OS threads. Some would call these threads”green-threads”. These threads has very small footprint on memory and CPU. You can actually create hundreds of threads with almost no overhead. Every tasklet has only a few bytes of memory overhead. And the scheduling of threads takes O(1) time with a simple Round-Robin scheduling algorithm. If we where talking about native threads we would have almost 1MB of memory per thread and high cost scheduling to do things we don’t need.

What are your thoughts? I'm no expert on using scripting languages on top of another platform - I actually have very minimal experience in that area (I've used Jython with a Java program my instructor created).