How do games embed scripting languages?
Posted by No_Insurance_6436@reddit | learnprogramming | View on Reddit | 21 comments
I understand that multiple languages can be used to design a single program. Multiple C files can be used as headers, and compiled object files can be linked together with a linker.
However, I do not understand how games such as gmod and ROBLOX have the ability to run scripts in LUA and interact with the game engine while running.
The engine is written in C/C++, I assume. How is LUA implemented in such a way that a user can write a script and have it interact with the game engine?
And, why do many games use LUA for small math (damage/position calculations, etc)? Why not just program it all in C/C++?
Caddy666@reddit
search for 'conquest: frontier wars'. its a early 2000's game, but they give you the source for it, so you can make your own mods - it includes embedded python, so you can see how its actually done in a commercial example , albeit quite old
Express-Channel-1686@reddit
Lua is the classic choice — tiny runtime, fast, designed from the ground up to be embedded. WoW, Roblox, and a ton of indie engines use it
the C API is simple: push values onto a stack, call functions, get results back. binding your C++ objects to Lua is most of the actual work
Python works too but heavier. some devs pick AngelScript or Wren to avoid licensing headaches
HappyFruitTree@reddit
You could think of a script as a complicated data file. Your program reads it and does something with it. It's just a bit more complicated than your ordinary "data files".
I have no personal experience with LUA but I have used scripting and the biggest reason for me is to avoid having to recompile every time I make a small change that I want to test. With scripting I don't even have to restart the game. This makes a huge difference when working on a game where you just want to try and test a lot of things quickly.
Another advantage of using scripts is that the syntax can be customized to suit the specific problem that it's trying to solve.
ManyInterests@reddit
LUA is a uniquely fast interpreted language and portable between platforms and sandboxable. C/C++ has to be compiled per platform and binaries are opaque and not able to be sandboxed.
burlingk@reddit
Think of it like this: If you write an interpreter for a language, you decide what the interpreter does with the information that is returned.
dmazzoni@reddit
You can see the example from Lua's own manual:
https://www.lua.org/pil/24.1.html
Lua is an interpreter written in C. Rather than having a "main", by default it's a library meant to be embedded in your own program.
To execute Lua code, you call C functions that pass in strings, and the Lua library interprets them.
In order to make a game engine that embeds Lua, you register functions that Lua programs can call. When a Lua program calls one of those functions, it triggers your code.
grantrules@reddit
Python has a similar example as well:
https://docs.python.org/3/extending/embedding.html
Stopher@reddit
So a function in one language that takes code in another language as a parameter?
dmazzoni@reddit
Yes.
Disastrous-Youth9441@reddit
Been dealing with this exact thing at work actually - we embed Lua in some of our internal tools. The interpreter basically becomes part of your C++ program, and you expose specific functions from your engine that Lua scripts can call.
As for why use Lua instead of just C++ - it's way easier to modify scripts without recompiling entire engine, plus you can let modders mess around with game logic without giving them access to core engine code.
_Aardvark@reddit
Not just modders, but different teams inside the company.
tomysshadow@reddit
It's possible because scripting languages have "native functions" that call native code. From the perspective of the scripting language, these functions are "black boxes" that you can't step into. By "step into," what I mean is that when using a debugger, you can usually press a button/hit a key that will take you to the source code of a function to see what it does - but for native functions, you cannot.
A simple example: JavaScript has the
window.open()function that opens a new tab/popup window. When you're using Devtools, most normal JavaScript functions you can step into, and it'll show you the source code of that function. But notwindow.open(). You can only step over it, not into it. Why? Because it's a native function.window.open()is a function that was placed there by native code. When you run it, the browser switches to running code in a native language like C++ to open the window. So you can't step into the function, because it's going to call into code in a completely different language.Why? Because it has to: it's a chicken and egg problem. Without
window.open(), how can you open a new window? You just can't, because truly doing so requires communicating that intent to the browser - a browser that is not written in JavaScript. You can make something that looks like a window in pure JavaScript and HTML, a facsimile of a window with your own custom titlebar. But you won't be able to drag it off the page, because it's not a true window.Behind the scenes, when you write in a scripting language, the result is getting compiled to... something, on the fly. It could be getting compiled directly into actual machine code, as is the case with JavaScript. It might be "compiled" into some bytecode that is run by an interpreter, as is the case in Python (for the time being.) No matter what, the script needs to be somehow translated into something more native that the CPU can directly run. And if the script is being translated into something more native anyway, how hard can it be to replace certain functions, with certain names, with calls to other native functions at that stage?
From the perspective of native languages, these functions are often called "hooks," as in hooks on reality. They allow execution to temporarily escape the confines of the scripting language lala land and enter the real world - just underneath that one function call - until that function returns, and we're back to the scripting language again. This abstraction, of specific functions with known names actually being calls into native code, is what allows scripting languages to be possible.
Why is it done? Well, it's done less and less now these days. Scripting languages were a much more popular idea in the 2000's. But the perceived benefit was that it was more convenient. You could write up an HTML file in Notepad with a script in it, double click it and have something functional run. There was no build step or anything, you just wrote it and it was done. If you wanted to make a tweak you could just edit the file and hit the refresh button in your browser. It allowed for things to be developed rapidly. But then we discovered "oops, we actually kind of need a build step" for stuff like TypeScript and with that primary advantage gone, the scripting language becomes more of a nuisance to work around that has the side effect of making code slower than it could be. So, it's a double edged sword.
patternrelay@reddit
Games like GMod and Roblox embed scripting languages like Lua by embedding an interpreter within the engine, usually written in C/C++. The interpreter runs Lua scripts during gameplay, allowing dynamic interactions without needing to recompile the game. Lua is fast, lightweight, and easy to integrate for smaller, repetitive tasks like math or logic.
No_Insurance_6436@reddit (OP)
Thank you
NomadicScribe@reddit
The book "Game Programming Patterns" by Robert Nystrom is a good starting point for understanding this subject.
SenoraRaton@reddit
https://gitlab.com/senoraraton/algo.nvim/-/blob/main/lua/runners/c-runner.lua?ref_type=heads
I built an FFI runner for NVIM so that I could solve leet code problems inside of neovim directly.
psychophysicist@reddit
Addressing the “why do they do it” part of the question: Game development often requires making a lot of small tweaks to get an interaction just right. Scripting languages let you redefine functions on the fly, so you can make and test your tweaks while the engine is still running and not have to recompile and relaunch the whole thing every time.
BranchLatter4294@reddit
It's no different than the embedded scripting engines in MS Word, or PowerPoint, Excel, or your browser, or any other app.
no_regerts_bob@reddit
A lot of the game might be written in lua too. You create the foundation in c++ or whatever but you script the characters, events etc in lua. Then you just expose the same API to modders
AmSoMad@reddit
There isn’t a single standard way games “embed scripting.”
In World of Warcraft, Lua mostly hooks into the UI layer, where the engine exposes an API that gives access to game stats, actions, and data. That's why you see a lot of UI-based addons that give you additional data or visualizations for what's going on in-game.
Garry's Mod, on the other hand, uses Lua for directly modding the game. In Garry's Mod’s case, the engine exposes a much wider binding layer including entities, physics, hooks, networking, and game rules.
The core idea being, you program how the scripting programs work with your program (the API). So it depends on what you're trying to do, and how you architect it, that determines how any individual game embeds scripting languages.
In regards to "why Lua", it’s small, fast, and easy to embed into a C/C++ codebase (so, most games), and it’s designed for host control, making it easy to expose specific engine functions to scripts and keep everything else locked down.
kohugaly@reddit
I don't know about lua specifically, but the way it is typically done is, the scripting language is executed by an interpreter, which is ultimately some object code linked with the rest of the engine. The interpreter exposes some capability to the scripting language to access memory and call functions via pointers/addresses. Works vice versa too (calling script code from C/C++, by invoking the interpreter).
Why use scripting languages for game logic? They are easier to work with and modify. Often even at runtime (hot swapping). Not all game developers have skills to use C and C++ properly, but scripting is significantly more accessible.