I realize the choice of Lua was chosen by the developers, partly for the ease of integrating into the engine and it's small footprint, but also partly because it's the language the developers prefer for scripting. Not everyone is comfortable with Lua however. I believe a better choice would be to replace the Lua scripting engine with an embedded Mono runtime. Like Lua, Mono has a small footprint and is easy to integrate, unlike Lua it gives developers a wide range of choice in scripting languages including Lua.

I am currently working on a game by contract, that requires my full time attention. Thus I don't have the time to make the change myself. When the contract expires, if mono is not yet integrated into Grit, and I have time (as in no pending contracts), then i will work on modifying Grit to use Mono myself. Hopefully that change would be accepted into Grit's main branch.

Grit is definitely being added, to my list of engines for future personal (and possibly contract) game development projects.

Hi, nice to meet you.

The Lua VM we use is actually modified to allow the allocation of 3d vectors and quaternions on the stack to avoid excess garbage collection cycles. Unless mono supports this, it would not be possible to switch.

We're also MIT licensed so cannot link to GPL or LGPL code.

I just had a quick look at the source code, this would require the rewriting of 15000 lines of code (half the core project) assuming none of the actual Lua scripts would need rewriting.

You can link to LGPL, unlike the GPL, LGPL does not infect your project unless you link statically. Many MIT/BSD projects use LGPL'd libraries.

Mono's garabage collection has always been very efficient, and in Mono 2.8 the GC was rewritten to increase efficiency 4 fold. My current contract requires me using an engine that uses Mono as it's scripting engine Unity3d. From experience, i can tell you the garbage collection is not an issue. I haven't looked deep into Mono's internals, but i do know it's a stack based system, that gets 90-120% native code speed out of it's JIT (speeds greater then 100% are due to runtime optimization of the JIT'd code that is not possible with non JIT'd languages, and primarily effects certain highly repetitive code paths).

But as I've said, when I am between contracts I'll work on it myself unless someone does it first.

That's true, we've tried to avoid dynamic linking but have been forced to do it by Cg (which is proprietary) and ICU (which has a complicated build system that does not support static linking by default). It wouldn't be the end of the world to have to link something else and maybe on windows we would just be using the system libraries.

The problem is not that it has a garbage collector. Lua actually has quite a good GC. The problem is that it does not allow stack allocated objects. Even Hotspot would not be fast enough. For instance, for 10 vehicles, 4 wheels each, and 30 allocations per wheel per physics frame (as a result of vector arithmetic), we are talking about 120000 allocations per second, and a heap with thousands of objects in it to mark. If stack allocation were not available we would have to rewrite the code to avoid these allocations, which is what we did before modifying the Lua VM, implementing 2 different approaches on different occasions, but the resulting code was bloated and error-prone.

But feel free to try it anyway

This is a terrible suggestion. Mono's patent situation is very unclear. You put the project at risk by tightly integrating it with Mono.

http://www.fsf.org/news/dont-depend-on-mono

I'd also wager (but can not attest to) that implementing "a wide range of choice in scripting languages" is not as simple as adopting a VM that supports them.

Btw, a better option for this would be Parrot (http://www.parrot.org).

Apologies for the manual links. Spam prevention is preventing this non-spam post.

mortaleditification: fixed links

Sorry about that, we've been fighting spam bots a bunch

Nice to see a real person posting, and I'll give a try to make your links working.

But yea, good to see some new faces, what do you guys think of the project (assuming you've had some time to look deeper)

Spark has extended lua slightly, assuming parrot is smart for this engine, how would it do with supporting changes made? (spark may be the only one who can answer this, knowing the depth of the changes)

Haven't started working on it yet, still on my contract project. But got word from some friends of mine who have experience with Mono internals. Seems while classes are allocated to heap, structs are allocated to stack. So it does indeed allow stack allocated objects, in the form of structs.



I put nothing at risk, the FSF warning is nothing but unsubstantiated hype. The only risks with Mono and patents, involves come of the framework classes built on top of Mono such as Windows Forms and ADO.NET. These would not be needed for game scripting engine, and should be left out of the build. The classes included should be the base types, networking, XML, IO, reflection, and a class created for the engine. None of which would be a patent risk.

As for Parrot, the vast majority of the languages it supports are typeless or weakly typed, and/or have weird syntax. Strict typing produces more efficient code, and is likely to have fewer bugs. The 2 languages (from the listed languages) which are acceptable to me, are both listed as "?" as to whether it works with the latest Parrot builds. I think i would rather stick with Mono and be certain of having decent languages, and a VM that is much better maintained.

Structs would be enough, I forgot C# had them.

Another hting that's needed is decent coroutine support. It's not used much at the moment but it will be fundamental to NPC and gameplay logic.

I am also a bit skeptical that implementing lua on top of mono will be as good as the current implementation.

Mono has a Continuations framework, which allows everything from simple coroutines, to serializable preemptive microthreads. It's one of the things that sets Mono apart from DotNet. Most game development would probably use coroutines. But in the rare case where you want to allow the end user to create scripts in a multiuser environment (such as Second Life does), preemptive microthreads are a must. Thus Mono provides for not just the common needs, but also the niche needs as well.



It would not be implementing Lua on top of Mono, it would be compiling Lua to Mono. The Lua compiler for Mono already exists. Compiling it to Mono allows the Lua scripts to run just as fast as any other Mono routines.



Mono also has support for SIMD allowing Vector operations to be performed on the entire vector at once instead of one of it's components at a time. This means vector operations which normally take 40 cycles or more to complete could be completed in 4 cycles on any system that supports SIMD instructions (which is basically EVERY PC these days).

Just to clarify the legal issue with mono. Microsoft released a pledge not to sue people for using Mono (search for Patent Pledge for Open Source Developers). That pledge doesn't cover some key libraries for desktop app's but as Corscaria points out this would not directly effect Grit as it won't use those libraries. However if Grit is intended to be used in commercial app's, it's worth pointing out that the pledge only applies to non commercial uses.

I'd like to keep commercial avenues open -- that has been the reason for choosing MIT license over e.g. GPL.

What does "I'd like to keep commercial avenues open" mean in the context of Grit? Does this mean that you'd like the option of a commercial license for Grit in the future? Or that you want people to be able to use Grit for commercial games?

We want the core to be open source, but to allow anyone to use the engine commercially if they like.

Good, that's what I was hoping you'd say.

To be honest, as an open source project, you actually run the risk of alienating potential developers by moving to Mono.

The patent situation is not just FSF hype until Microsoft puts something legaly binding into writing. Even if they do, it won't hold up in court.

For a lot of people though, just the fact that Mono is based on .NET is enough to make them avoid it, even if patents were not an issue.

i agree

I personally find LUA the best. Never ran across mono, but many FOSS games use LUA and seem happy with it. One thing I like about GRIT is the bundle of systems it uses (OGRE + OpenAL + BulletX + LUA).

OpenRA is written in C# without any script support and creating missions is far from user friendly. Everything has to get compiled into the code tree so you can't just post a custom map to the net you have to push it into the devs repository. Non-coders also have a hard time. They even started a fork to get Lua support for mini-games.