Lua vs the others

[zajoman]

I'd like to ask the programmer of LOG2 a few questions.

I love Lua. No, love is a weak word for that. I absolutely friggin' love Lua! Yet, I fear that a bigger project made mostly in Lua (only things like rendering & audio system done in C++) could get very difficult to maintain and debug over time. That's because of Lua's dynamic nature.

So, the questions:

• How did you deal with this? How did you maintain order in Lua code?
• I believe you were the only programmer on the team, so keeping a good understanding of the code base wasn't a big problem, I guess. Can you imagine making a game in Lua with 2-3 or even more other programmers on the team?
• What role did your in-house code editor play in this? Did it just help you debug or was it a big boon to development (if yes, why?)?
• Is there any chance the code editor will get published (paid or free)?
• Did you, at any point, miss the features of strongly typed languages like C# and the IDE call tips that are readily available for C# classes?

[petri]

For starters writing most of the code myself helped a lot, as every little detail was inside my head. With a dynamic language it helps to have a good dicipline and good coding standards. There are other big projects written in Lua, with bigger teams working on them, Natural Selection 2 comes to mind. They have a strong modding support too I believe, so maybe you could take a look at their modding reference to see how they handle things.

The big benefit of using Lua is fast iteration speed. I've used C++ in the past for making games and I've done work on the console where the iteration loop is quite horrible -- several minutes to test a change. With Lua I can make a change in the code and see the effect immediately. We have moved on from our own editor to working in Sublime Text and we have a custom plugin which allows sending Lua code to the game process with a keyboard short cut. E.g. when I press Ctrl-E, the current function I'm editing is live updated and I can see the effects immediately on the screen. If there's an error I get a stack dump and after which I can fix the error and resume execution. This has a tremendous positive effect on productivity. Comparing this will C++, I would have to compile, restart and somehow get the game to the state where I can test the recent change. Just thinking about this nowadays gives me the creeps.

The lack of a debugger is one thing that I've missed a few times, but having REPL and just plain old printf style debugging is a surprisingly effective strategy when you can do live edits.

To sum this up, without Lua (or other equally powerful dynamic language), Grimrock 1 & 2 would have been much worse games, simply because we could not have afforded to make so many tweaks & changes that was possible with Lua.

[zajoman]

Thank you, Petri.

Even though I'm currently working on a Unity project in C#, I was very curious how you managed Lua in Grim 2. Your response enlightened me. The most important thing seems to be the ability to do live edits (with which even the most basic debug methods such as printf become effective again). I see. It's brilliant!

I didn't know NS2 was written in Lua. I'll check that out.

Hah, I write all my code in Sublime, too (even C# scripts for Unity). I just find myself very productive in it.

As for the REPL, do you redefine functions that don't work the way they should via some line command, or you rather change the file and have that file reloaded during runtime?

[petri]

Lua functions are first class values, so they can be redefined by simply setting the new definition in the Lua state. I can send arbitrary code from Sublime to the game process via TCP/IP. REPL and live updates are just Lua code sent by ST and executed by the game engine.

[zajoman]

I see. Thanks, man.

[petri]

No problem!