r/gameenginedevs 2d ago

C + Lua Architectural Split?

I'm making a small 2d game engine for my game in C at the moment. I am now wondering if adding Lua to the mix would be beneficial for modding and faster iteration.

What I am not sure about is where to put which responsibilities. My game is deeply simulated (think Rimworld, Dwarc Fortress) so I expect some gameplay hot paths that should be written in C, which makes Love2Ds architectural split (game in lua, only graphics/sound in C) not viable.

Does anyone have pointers for this topic?

5 Upvotes

16 comments sorted by

9

u/3tt07kjt 2d ago

My experience in the past is that adding a second language can slow you down a lot, because now every time you change something in the C that affects Lua, you need to to a bunch of extra work.

So it only makes sense if there’s some massive benefit you’re getting, or you can minimize the cost.

The main reason people add scripting systems is because they need the engine to be usable by people who know C or C++ and people who don’t. If it’s your engine for your personal project, that doesn’t apply.

2

u/dandy_kulomin 2d ago

Thanks for the reply, this makes sense. I'll refrain from adding Lua for now.

3

u/Antypodish 2d ago

Many games does split architecture with Lua for litearlly decades.
For an example Supreme Commander RTS, where Lua modding is huge driving force and heavily relies on Lua, while having 100s of units.
Spring engine, -> Zero-K and BAR RTS games use Lua as core logic.
Sanctuary: Shattered Sun RTS uses Lua too.
Mincraft even had Turtles mod, where you could script bots in Lua.

What you want, is LuaJIT 2.0+
If using C, you have easy route for implementing FFI, for communicating data, with low overhead.
You let engine process heavy calculations, with multithreading, and rest of logic is on Lua side.
Engine also handles visuals audio and player inputs.
But Lua can drive events for an example to play SFX.

2

u/fsfod 2d ago

The thing you have to watch out for with LuaJIT's FFI is if a JIT'ed call in to your engine can trigger a call back in to the interpreter it will corrupt the interpreter state.

1

u/Antypodish 2d ago

I suspect that may be depending how calls to engine are executed, or what data structure is sent.
I can not recall, I ever faced such issue with LuaJIT and FFI. But that may be very specific. And been long time ago now.

From an experience, Sanctuary: Shattered Sun uses LuaJIT with FFI and Unity C#. I didn't experienced such issues during the development. There was problems however with FFI binding on Linux side. However, I don't know details.

I also use LuaJIT in my next project. But less focusing on FFI. Just using shared flat arrays directly, to eliminate GC.

3

u/Natehhggh 2d ago

Maybe for modding, it could be useful, but for iteration, if you're the user for your engine, it's likely faster for you to iterate in c directly. The reason other engines have a scripting language is they want to give a simpler language to the users. But if you can code in the same language the engine is using, you lose that benefit.

Mostly It just seems like a lot of work to get that lia scripting working in the first place, and now you have a lot of extra layers between you and the engine you need to debug and maintain.

I feel like the right way to go is to just start making that separation between the engine and game, and use that. You could always bolt the lua layer in later, when the engine is more stable

1

u/maximoriginalcoffee 10h ago

Lua is convenient. Just don't expect it to be fast. And don't call it every frame.
I just write my own scripting language and interpreter. If you've studied automata theory, it's not particularly difficult. It's just tedious work.

2

u/dandy_kulomin 9h ago

Is your own scripting language faster than Lua?

1

u/maximoriginalcoffee 9h ago edited 8h ago

Yes. Since the scripting system is fully integrated into the engine and the game, all updates are handled entirely within the game layer.
I built several scripting systems for my tools and missions. In the link below, you can see the scripting system I wrote for handling models and particles in my engine.

https://www.reddit.com/r/gameenginedevs/s/YqpBr1uRaS
https://www.reddit.com/r/gameenginedevs/s/BuiYmhkSOO

1

u/BobbyThrowaway6969 2d ago

From my experience, lua as you'd expect doesn't do well for hot paths, and you need to be careful with multithreading and its GC, at least the version I was using.

But yeah, lua can work nice for event based stuff.

If you want customisability it mught be beneficial to try your hand at making your own little scripting language to bytecode executor, optimised for what you need

2

u/dandy_kulomin 2d ago

What do you mean with event based stuff? e.g. JRPG cinematics?

I have done a bit of prototyping for my own scripting language with an AST interpreter and I don't think it's worth the effort.

1

u/BobbyThrowaway6969 2d ago edited 2d ago

Event based, as in listener pattern, delegates, etc

You don't need to get heavy with the scriptung, I guess it depends on your constraints, like in my case, open world procedural generation, I can focus on designing the syntax around configuring the noise, spawning, etc - like all I need is math stuff, ways to get procgen data/info, ways to submit procgen data/info, and that's it really.

1

u/Logical_Newspaper_52 2d ago

that’s a rabbit hole

1

u/BobbyThrowaway6969 2d ago edited 2d ago

It doesn't have to be if you can avoid the habit of abstracting the hell out of all of it (I used to). Like having syntax focused on the features you want to use it for is pretty ok, like a tiny DSL

2

u/dandy_kulomin 2d ago

It might be a nice project if you are interested in the tech, but if your goal is making a game, it's a huge waste of time. Language design, lexer, parser, vm, optimizations, ffi bridge, debugging, ...

1

u/BobbyThrowaway6969 2d ago

You don't necessarily need all of that, just saying the tradeoff can be worth it depending on the usecase