Brad Wardell's site for talking about the customization of Windows.
Published on May 29, 2020 By Frogboy In PC Gaming

I recently wrote an article for Gamasutra on scripting languages and game engines.  

Whether it be Lua or Python or some other scripting language, I think there is a lot to be said about not having to compile your code after every change.  It makes iteration much faster to be able to be playing the game and be writing code changes to improve it while it's running and have those changes simply update.

I don't have a strong preference between Lua and Python other than I prefer Lua's C++ like nature and it's small and fast.  Our engine, Cider, can use any but our next generation of games will be using Lua.  

Using Lua means other people could, in effect, completely mod up our games to be completely different because the gameplay is largely available.

Traditionally, performance is an issue in using scripting.  But that was before we had a core-neutral engine core: Nitrous.  If you have a 4 core system (8 logical threads) then scripting becomes a non-issue.  At that point, it's really video card stuff that becomes the limiting factor.

I'm a total convert.  The only thing I don't love, which we have to deal with still, is the debugging.


Comments
on May 30, 2020

I prefer Python, largely because I already know it, but I'll give Lua a look.

I'm curious as to what kind of games you'll be able to make with Nitros. You've been teasing us with it for years.

on May 31, 2020

I'm still averse to deferring all of my errors to runtime. C++ compile times can be insane, but Go is very quick.

on Jun 02, 2020

We use Lua scripting into our IOT/SCADA platform since 2013. The core process is written in C++.  Vanilla lua 5.3 hooks in nicely. It allows us to sandbox highly custom customer functionality. 

The coroutine system in Lua is a huge. Calling c/c++ functions from Lua that do IO can yield and resume when complete. We commonly have thousands of coroutines 'running' at a time. 

The c-style longjump for error handling surprisingly hasn't been an issue. MVC++ cleans up the stack even when in a c-function in a lua-function in a c-function stack trace. 

For debugging, we use mobdebug and ZeroBrane. It connects to the process via TCP and allows stepping, variable inspection. I'd rather use VisualStudio code but wasn't happy with any of the lua debugging plugins that were available last time I checked. 

Only complaint is performance of the GC and generally slower code execution being an interpreted language. Like you said, a lot of that is less of a problem with multiple cores.