Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I've embedded Lua in my game engine and I'd say that

  - performance is a joke
  - GC can cause really bad hick-ups
  - loose runtime typing makes it hard to build static tooling for developer support
  - lack of predetermined more rigid structure makes some things confusing (like you can mess with the internals such as the meta tables and stuff, which can be useful but also confusing)

  + functionality wise it's adequate for a game programmer, perfect for writing (smallish) scripts of game play
  + it's simple to integrate and provide bindings for
  + lots of flexibility how you use it and what kind of code you use to write with it 
In my experience I'd say that if you're planning to integrate and use Lua in your projects you need to

  - have a fallback for performance sensitive code, either by being able to mix and match native and Lua user (game) code or  provide functionality natively in your engine OOTB
  - make sure you can run things properly (using real threads not joke threads) in parallel as much as possible
  - stay on top of perf at all times and integrate performance tests and bench marks to your development process
Despite the problems I've managed to build a Lua code editor that has

  a) auto formatting
  b) syntax highlighting
  c) auto completion (limited but still)
  d) simple navigation support
  e) built-in help
The editor is integrated in my game engine's editor.

You can find more details on my GitHub

https://github.com/ensisoft/detonator



Why not integrate a Lua LSP instead of reimplementing all that language support?


Good question. But essentially because things started out small and then grew from there.

Going forward being able to have seamless integration between the scripting and rest of the editor is a key differentiator and value added. For example being able to jump to the right API documentation relevant for the function call under the caret, or being able to open and jump to the game asset from the script.

I'm not sure how well a LSP type of integration would work here. As far as I can tell it'd need to evaluate the script in order to have best possible diagnostics and analysis and that won't work without the interpreter having the native game engine code available as well.

Of course my "solution" was mostly about slapping components other people built together.

  - Qt already has a text editor component with components for doing stuff such as syntax highlight quite easily.
  - I use tree sitter to extract symbol information from the Lua code.
  - I use an open source code formatter someone else built.


„joke threads“ I assume you mean coroutines?


I read that as "green threads". But it could be anything just short of a thread maybe even futures and promises.

Just about any thread that isn't a full-on proper thread is not ideal for general purpose game development. There are a lot of thread implementations for various user interfaces that have a goal of minimizing latency or maximizing CPU utilization. But if you are in a latency sensitive environment like a game and you're highly likely to be pushing the CPU to 100% you often need real threads not something like them.

Coroutines have their place in game development too, but they're not (in my experience) used as a thread replacement. They are used to manage complex flow control. Similarly, I have seen green threads and event loops used to manage the user interface or Futures and Promises to manage certain IO in a game but not the rest of the general game work scheduling.


I also need elaboration on this. I presumed calling lua from c can be used to implement user-defined callbacks. Launching a thread for lua + locking seems even slower?


So what lua needs- is a c-compiler, that allows "static" library code to compile additions directly into dll, that those can be reused by lua via api


This is the goal of the Pallene project: https://github.com/pallene-lang/pallene


It isn't terribly hard to write the bridge code to lua, just monotonous to translate inputs and outputs from C++.

You throw a lua function into a table (usually tables are used as namespaces and globals are just a table) and then make that C++ translate to your normal one and handle the return value correctly.

The hard thing is building a system to pass in a C++ object in general as that required building a table for each instance that matches its class.


>GC can cause really bad hick-ups

What version were you using? Recent Lua versions have a smoother GC overall


Right now on Lua 5.4.2

I've had some success by tuning the GC with `collectgarbage('setpause', 100)` and then manually calling ` collectgarbage('step')`every once in a while.

That being said this problem isn't unique to Lua, There are horror stories about Unity and their integration of C# for example.


It's especially bad in Unity because it's using the Boehm garbage collector. C# everywhere else has a performant generational GC. Unity have been working on this problem for years now trying to get the engine to work with .NET (Core) and it's better GC.


I did this on my engine, 16000 squares running at 60fps on WebAssembly.

1 - https://github.com/khromatizo/squares/blob/main/scripts/main...


I believe Roblox's Luau would be suitable for this case? It's got pretty good performance and typing support. Still supports metatables I think (they needed backwards compatibility with old Lua 5.1 code), but it's a start ¯\_(ツ)_/¯


AFAIK metatables are still in Lua 5.4?




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: