Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I've read that Lua is often used for embedded scripting and in particular game for scripting. I find it hard to picture how it is used exactly. Can you describe why and for which features and for which audience it is used?

This questions isn't specifically addressing Lua, but rather any embedded scripting that serves a purpose similar to Lua scripting.

Is it used for end-users to make custom adjustments? Is it used for game developers to speed up creation of game logic (levels, AI, ...)? Is it used to script game framework code since scripting can be faster?

Basically I'm wondering how deep between plain configuration and framework logic such scripting usage goes. And how much scripting is done. A few configuration lines or a considerable amount?

share|improve this question

Is it used for end-users to make custom adjustments?

Not doing games (VFX), but currently working on a little indy software where I lean on Lua a whole lot.

First the user-end adjustment goal is there. Users can invoke things from the UI or script them on the fly or add scripts they wrote to become like a permanent resident accessible through the UI. Shown below with something resembling the Quake console users can bring up with the tilde key and start typing stuff in for the application to do (sorry, UI is still rough and I need to add icons):

enter image description here

Is it used for game developers to speed up creation of game logic (levels, AI, ...)?

This is also there in mine, and it's a HUGE deal for me. I can really do things a lot faster in Lua (maybe 4x faster as a rough estimate), and I use LuaJIT which tends to almost rival C in performance in some cases. Yet I often need C and C++ when I need SIMD and multithreading. Lua makes it possible to do multithreading, but we have to use separate Lua states for it and it gets kind of messy and painful.

There's also an interesting dynamic that goes on between the Lua code and native code. Since I favor doing as much as possible in Lua, my C and C++ code shrinks to just the core API implementation and most performance-critical parts. That reduces build times a whole lot, helping me work faster on the native end too.

It also just has a satisfying organization to me where I'm reserving these native languages for just core and performance-critical areas. It kind of forces a discipline on me where I'm not tempted to optimize things that don't matter. Also when I'm optimizing the things that do matter, vtune ends up showing me more relevant hotspots since there's much less native code involved. Any time used by Lua just shows up in the profiler as a few LuaJIT function calls.

But most of all, I'd say the most valuable reason to favor LuaJIT when possible is safety. There are no undefined behaviors in Lua. I cannot possibly crash it within the language, only get a scripting error. There's nothing I hate more than tripping over an undefined behavior which only shows up on some random user's machine on a full moon, and while I've developed a lot of safety and testing practices to mitigate those to a minimum when I'm coding natively, the guarantee that comes when using Lua is really, really a nice reassurance.

Basically I'm wondering how deep between plain configuration and framework logic such scripting usage goes. And how much scripting is done. A few configuration lines or a considerable amount?

In my case, I use Lua as much as possible. When I first started using Lua about a decade ago, I used it sparingly for just small tasks like configurations, front-end UI stuff.

Now I use it so much that it's almost "pseudo-extended" instead of "embedded". My application feels more like a Lua application calling C library routines rather than a C application doing a handful of tasks in Lua.

Perhaps one of the greatest things to appreciate about Lua is how easy it is to bind functionality from your C or C++ codebase in a way that allows Lua to instantly run and invoke your functions on the fly. It only took me a day even when I first tried Lua to have it calling functions in my codebase, and I was plugging it into a very mature codebase. With LuaJIT, it can call your C functions directly through the FFI with no binding effort whatsoever, and the funniest thing: LuaJIT can call your C functions faster than it can call native Lua functions. The JIT generates the machine instructions on the fly to call your dylib C function in a way that's as cheap as calling it from C itself.

I love Lua and consider it like a natural extension of my C and C++ arm. It gives me those safety and runtime characteristics I lack (especially C with the safety side) in these languages.

share|improve this answer

It can be used by people other than original game programmers to modify or extend game logic. Such people can be relatively non-technical, e.g. game designers or end-users (gamers).

Scripts are usually higher-level languages and as such Lua is easier than C++. Code written in scripts can usually be modified without recompiling the main application (game engine) which is useful for game designers to tweak game scenes quickly.

PS: better ask this question on gamedev.stackexchange.com

share|improve this answer

A scripting language in a game engine is there to expose your game engine in a higher-level, interpreted manner.

Take a game like Skyrim, for example. You'll notice that there are many quests and interactions that occur, and some of these have fairly impressive logic built into them, such as a guard reacting to you getting to close to an item during some scene. These are things would be difficult to express in a pure data format, and for this reason, quests and custom behaviours are typically expressed as scripts.

There are also many practicalities to consider - the game designers who create these scripts often work at a higher level of abstraction than the game engine coders; they do not want to be worrying about memory allocation, etc. A scripting language is a good fit for them, and with LUA, they're typically calling into a nice high level facade of the engine. You also don't want to recompile your game every time you want to adjust some minute attribute in a script.

On top of all of this, they allow for easy debugging, modding, and all the other nice things you mentioned.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.