Call main.lua script at each game loop iteration - is it good or bad design? How does it affect on the performance (relatively)?
Maintain game state from a. C++ host-program or b. from Lua scripts or c. from both and synchronise them?
(Previous question on the topic: Lua and C++: separation of duties)
The best thing about lua is that it has a lightweight VM, and after the chunks get precompiled running them in the VM is actually quite fast, but still not as fast as a C++ code would be, and I don't think calling lua every rendered frame would be a good idea.
I'd put the game state in C++, and add functions in lua that can reach, and modify the state. An event based approach is almost better, where event registering should be done in lua (preferably only at the start of the game or at specific game events, but no more than a few times per minute), but the actual events should be fired by C++ code. User inputs are events too, and they don't usually happen every frame (except for maybe MouseMove but which should be used carefully because of this). The way you handle user input events (whether you handle everything (like which key was pressed, etc) in lua, or whether there are for example separate events for each keys on the keyboard (in an extreme case) depends on the game you're trying to make (a turn based game might have only one event handler for all events, an RTS should have more events, and an FPS should be dealt with care (mainly because moving the mouse will happen every frame)). Generally the more separate kinds of events you have, the less you have to code in lua (which will increase performance), but the more difficult it gets if a "real event" you need to handle is actually triggered by more separate "programming level events" (which might actually decrease performance, because the lua code needs to be more complex).
Alternatively if performance is really important you can actually improve the lua VM by adding new opcodes to it (I've seen some of the companies to do this, but mainly to make decompilation of the compiled lua chunks more harder), which is actually not a hard thing to do. If you have something that the lua code needs to do a lot of times (like event registering, event running, or changing the state of the game) you might want to implement them in the lua VM, so instead of multiple getglobal and setglobal opcodes they would only take one or two (for example you could make a SETSTATE opcode with a 0-255 and a 0-65535 parameter, where the first parameter descibes which state to modify, and the second desribes the new value of the state. Of course this only works if you have a maximum of 255 events, with a maximum of 2^16 values, but it might be enough in some cases. And the fact that this only takes one opcode means that the code will run faster). This would also make decompilation more harder if you intend to obscure your lua code (although not much to someone who knows the inner workings of lua). Running a few opcodes per frame (around 30-40 tops) won't hit your performance that badly. But 30-40 opcodes in the lua VM won't get you far if you need to do really complex things (a simple if-then-else can take up to 10-20 or more opcodes depending on the expression).
My basic rule for lua is - or any script language in a game -
Basically, any code thats called at >33-100Hz (depending on frame rate) is C++ I try to invoke the script engine <10Hz.
Based on any kind of actual metric? not really. but it does put a dividing line in the design, with c++ and lua tasks clearly delineated - without the up front delineation the per frame lua tasks will grow until they are bogging processing per frame - and then theres no clear guideline on what to prune.
The best thing about lua is that it has a lightweight VM, and after the chunks get precompiled running them in the VM is actually quite fast, but still not as fast as a C++ code would be, and I don't think calling lua every rendered frame would be a good idea.
I'd put the game state in C++, and add functions in lua that can reach, and modify the state. An event based approach is almost better, where event registering should be done in lua (preferably only at the start of the game or at specific game events, but no more than a few times per minute), but the actual events should be fired by C++ code. User inputs are events too, and they don't usually happen every frame (except for maybe MouseMove but which should be used carefully because of this). The way you handle user input events (whether you handle everything (like which key was pressed, etc) in lua, or whether there are for example separate events for each keys on the keyboard (in an extreme case) depends on the game you're trying to make (a turn based game might have only one event handler for all events, an RTS should have more events, and an FPS should be dealt with care (mainly because moving the mouse will happen every frame)). Generally the more separate kinds of events you have, the less you have to code in lua (which will increase performance), but the more difficult it gets if a "real event" you need to handle is actually triggered by more separate "programming level events" (which might actually decrease performance, because the lua code needs to be more complex).
Alternatively if performance is really important you can actually improve the lua VM by adding new opcodes to it (I've seen some of the companies to do this, but mainly to make decompilation of the compiled lua chunks more harder), which is actually not a hard thing to do. If you have something that the lua code needs to do a lot of times (like event registering, event running, or changing the state of the game) you might want to implement them in the lua VM, so instead of multiple getglobal and setglobal opcodes they would only take one or two (for example you could make a SETSTATE opcode with a 0-255 and a 0-65535 parameter, where the first parameter descibes which state to modify, and the second desribes the new value of the state. Of course this only works if you have a maximum of 255 events, with a maximum of 2^16 values, but it might be enough in some cases. And the fact that this only takes one opcode means that the code will run faster). This would also make decompilation more harder if you intend to obscure your lua code (although not much to someone who knows the inner workings of lua). Running a few opcodes per frame (around 30-40 tops) won't hit your performance that badly. But 30-40 opcodes in the lua VM won't get you far if you need to do really complex things (a simple if-then-else can take up to 10-20 or more opcodes depending on the expression).
I don't like C++. But I do like games.
My approach might be a bit atypical: I do everything I can in Lua, and only the absolute minimum in C++. The game loop, the entities, etc are all done in Lua. I even have a QuadTree implementation done in Lua. C++ handles graphical and filesystem stuff, as well as interfacing with external libraries.
This is not a machine-based decision, but a programmer-based one; I output code much faster in Lua than In C++. So I spend my programmer cycles on new features rather than on saving computer cycles. My target machines (any laptop from the last 3 years) are able to cope with this amount of Lua very easily.
Lua is surprisingly low-footprint (take a look to luaJIT if you don't know it).
This said, if I ever find a bottleneck (I haven't yet) I'll profile the game in order to find the slow part, and I'll translate that part to C++ ... only if I can't find a way around it using Lua.
I am using Lua for the first time in a game I've been working on. The C++ side of my application actually holds pointers to instances of each game state. Some of the game states are implemented in C++ and some are implemented in Lua (such as the "game play" state).
The update and main application loop live on the C++ side of things. I have exposed functions that allow the Lua VM to add new game states to the application at runtime.
I have not yet had any problems with slowness, even running on hardware with limited resources (Atom processor with integrated video). Lua functions are called every frame. The most expensive (in terms of time) operation in my application is rendering.
The ability to create new states completely in Lua was one of the best decisions I made on the project, since it allows me to freely add portions of the game without recompiling the whole thing.
Edit: I'm using Luabind, which I have read performs slower in general than other binding frameworks and of course the Lua C API.
IMHO Lua scripts are for specific behaviours, it's definitely going to hurt performance if you are calling a Lua script 60 times per second.
Lua scripts are often to separate stuff like Behaviour, and specific events from your Game Engine logic (GUI, Items, Dialogs, game engine events, etc...). A good usage of Lua for example would be when triggering an explosion (particle FX), if the Game Character walks somewhere, hard-coding the output of that event in your engine would be a very ugly choice. Though, making the engine trigger the correct script would be a better choice, decoupling that specific behavior off your engine.
I would recommend, to try to keep your Game State in one part, instead of upscaling the level of complexity of keeping states synchronized in two places (Lua and Engine), add threading to that, and you will end up having a very ugly mess. Keep it simple. (In my Designs I mostly keep Game State in C++)
Good luck with your Game!
You probably don't want to execute the entire Lua script on every frame iteration, because any sufficiently complex game will have multiple game objects with their own behaviors. In other words, the advantages of Lua are lost unless you have multiple tiny scripts that handle a specific part of the behavior of a larger game. You can use the lua_call function to call any appropriate lua routine in your script, not just the entire file.
There's no ideal answer here, but the vast majority of your game state is traditionally stored in the game engine (i.e. C++). You reveal to Lua just enough for Lua to do the decision making that you've assigned to Lua.
You need to consider which language is appropriate for which behaviors. Lua is useful for high level controls and decisions, and C++ is useful for performance oriented code. Lua is particularly useful for the parts of your game that you need to tweak without recompiling. All magic constants and variables could go into Lua, for example. Don't try to shoehorn Lua where it does not belong, i.e. graphics or audio rendering.
I'd like to throw in my two cents since I strongly believe that there's some incorrect advice being given here. For context, I am using Lua in a large game that involves both intensive 3D rendering as well as intensive game logic simulation. I've become more familiar than I'd have liked to with Lua and performance...
Note that I'm going to talk specifically about LuaJIT, because you're going to want to use LuaJIT. It's plug-and-play, really, so if you can embed Lua you can embed LuaJIT. You'll want it, if not for the extra speed, then for the automagic foreign function interface module (require 'ffi') that will allow you to call your native code directly from Lua without ever having to touch the Lua C API (95%+ of cases).
It's perfectly fine to call Lua at 60hz (I call it at 90hz in VR..). The catch is that you are going to have to be careful to do it correctly. As someone else mentioned, it's critical that you load the script only once. You can then use the C API to get access to functions you defined in that script, or to run the script itself as a function. I recommend the former: for a relatively simple game, you can get by with defining functions like onUpdate (dt), onRender (), onKeyPressed (key), onMouseMoved (dx, dy), etc. You can call these at the appropriate time from your main loop in C++. Alternatively, you can actually have your entire main loop be in Lua, and instead invoke your C++ code for performance-critical routines (I do that). This is especially easy to do with the LuaJIT FFI.
This is the really hard question. It will depend on your needs. Can you quite easily hammer down the game state? Great, put it C++-side and access from LuaJIT FFI. Not sure what all will be in the game state / like to be able to prototype quickly? Nothing wrong with keeping it in Lua. That is, until you start talking about a complex game with 1000s of objects, each containing non-trivial state. In this case, hybrid is the way to go, but figuring out exactly how to split state between C++ and Lua, and how to martial said state between the two (especially in perf-critical routines) is something of an art. Let me know if you come up with a bulletproof technique :) As with everything else, the general rule of thumb is: data that goes through performance-critical pathways needs to be on the native side. For example, if your entities have positions and velocities that you update each frame, and you have thousands of said entities, you need to do this in C++. However, you can get away with layering an 'inventory' on top of these entities using Lua (an inventory doesn't need a per-frame update).
Now, a couple more notes I'd like to throw out both as general FYIs and in response to some of the other answers.
Event-based approaches are, in general, critical to the performance of any game, but that goes doubly for systems written in Lua. I said it's perfectly fine to call Lua @ 60hz. But it's not perfectly fine to be running tight loops over lots of game objects each frame in said Lua. You might get away with wastefully calling update() on everything in the universe in C++ (though you shouldn't), but doing so in Lua will start eating up those precious milliseconds far too quickly. Instead, as others have mentioned, you need to be thinking of Lua logic as 'reactive' -- usually, this means handling an event. For example, don't check that one entity is in range of another each frame in Lua (I mean, this is fine for one entity, but in general when you're scaling up your game you need to not think like this). Instead, tell your C++ engine to notify you when the two entities get within a certain distance of one another. In this way, Lua becomes the high-level controller of game logic, dispatching high-level commands and responding to high-level events, not carrying out the low-level math grind of trivial game logic.
Be wary of the advice that 'mixed code' is slow. The Lua C API is lightweight and fast. Wrapping functions for use with Lua is, at worst, quite easy (and if you take a while to understand how Lua interfaces with C w.r.t. the virtual stack, etc, you will notice that it has been designed specifically to minimize call overhead), and at best, trivial (no wrapping required) and 100% as performant as native calls (thanks, LuaJIT FFI!) In most cases I find that a careful mixture of Lua and C (via the LJ FFI) is superior to pure Lua. Even vector operations, which I believe the LuaJIT manuals mention somewhere as an example where code should be kept to Lua, I have found to be faster when I execute via Lua->C calls. Ultimately, don't trust anyone or anything but your own (careful) performance measurements when it comes to pieces of code that are performance-sensitive.
Most small-ish games could get away just fine with game state, the core loop, input handling, etc. done entirely in Lua and running under LuaJIT. If you're building a small-ish game, consider the "move to C++ as needed" approach (lazy compilation!) Write in Lua, when you identify a clear bottleneck (and have measured it to make sure it's the culprit), move that bit to C++ and be on your way. If you're writing a big game with 1000s of complex objects with complex logic, advanced rendering, etc. then you'll benefit from more up-front designing.
Best of luck :)
About the performance of 1: if main.lua does not change, load it once with lua_loadfile or loadfile, save a reference to the returned function, and then call it when needed.
Most of the performance will be lost through the binding between Lua and C++. A function call will actually need to be wrapped, and re-wrapped, and like that a couple of time usually. Pure Lua or pure C++ code is usually faster than mixed code (for small operations).
Having said that, I personally didn't see any strong performance hit running a Lua script every frame.
Usually scripting is good at high level. Lua has been used in famous games for the Bots (Quake 3) and for the User Interface (World of Warcraft). Used at high level Lua micro-threads come handy: The coroutines can save a lot (compared to real threads). For example to run some Lua code only once in a while.
© 2022 - 2024 — McMap. All rights reserved.
