Lua, game state and game loop

Question

1. Call main.lua script at each game loop iteration - is it good or bad design? How does it affect on the performance (relatively)?

2. Maintain game state fro

Answer 1

My basic rule for lua is - or any script language in a game -

• Anything that happens on every frame: c++
• asynchronous events - user input - lua
• synchronous game engine events - lua

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.

Answer 2

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.

Answer 3

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).

Answer 4

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!

Answer 5

1. 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.

2. 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.

Answer 6

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.