I am going to be integrating lua in my next 2d project I have a few questions that I hope someone can shed some light on. I plan to code the bare essentials of my engine in C, and then the game specific stuff in lua. For example, I'll have a linked list in C to store all my bitmap resources which can them be used in lua via a glue function with an index #, id or something. I don't think my game logic will be very complex, but there is a possibility my game loop will be iterating over a few hundred objects. Will having all of my game logic in lua cause a hit in performance? Any input is appreciated :)

I'm actually going thru this right now. Course I'm doing it in Delphi witch makes a difference of a DLL call per conjunction, but thats another story. Here is what I've done (don't know if its right, but it works):

API:

  GetImageID(ImageName) -> Pointer  DisplayImage(ImageName or ImageID, AtX, AtY, PatternID, AlphaID) -> Boolean  StretchDraw(ImageName or ImageID, AtTop, AtLeft, AtRight, AtBottom, PatternID, AlphaID) -> Boolean

This way if (for example) I want to test out a new splash screen I can simply say:

  while (IsKeyDown('Enter')~=true) do    DisplayImage('SplashTest', 0, 0)  end

Then in the final I can cache images to LUA Classes (ok tables) for faster workings. So far I am getting about 230 fps on my machines with no problems. I'd display the entire API but its quite long and the brief above gets the idea across. Basically in your code you just have to test and see if the 1st type is an integer, if it is then cast it as a pointer and go, otherwise get it as a string and perform your lookup.

Hope that helps,
- Jeremy

Don't worry it'll be too slow if you put the game logic in the scripting language. It is commonly done, but you need to think ahead how to implement it. The game logic should not contain such things for which it matters whether they're run in C or the scripting language(or at least it shouldn't make a big difference).

So, it's perfectly ok to put your game logic in a scripting language, but don't go too far. Create your 'engine' in C, and export only higher-level functions to lua. For example, don't export functions like 'blit', but instead, create a sprite system in C, and then only export functions for manipulating those sprites to lua. I hope I'm not getting too much into details here :)

I haven't used lua much, but if you can later compile it to byte-code, there's even less reason to be worried about it.

The bottleneck in the performance is usually not a simple counting loop in a scripting language which could have been done with a few instructions less in C, but mostly in badly designed algorithms - so pay attention to that. The days when evey single cpu instruction mattered are over - at least as far as the standard game development goes.

-Ivan

The LuaGlue functions should keep lua from causing a bottle neck in performance since your scripts can call C functions made available from your engine. If you find that you're asking your scripting engine to do too much it usually isnt very difficult to just transfer the functions over to C and call them through luaglue functions.

As I said I'm going through this right now, and while its still a Major work in progress you can see the API that I've developed thus far at: http://www.eonclash.com/JumpStart/API.xml. For the most part what I've done is built my sprite and tiling engine into the actual engine and then offered up some of the drawing routines for the things (such as start screen, storyline, and splash/death screens) where speed isn't really as necessary (even on those the framerate is quite good). Looking back their are things I wish I had done different, and things that at the end of PGD I'll go back and completely re-write, but overall it works well.

As others have pointed out, plenty of games are also doing this (WoW lets you do GUI editing from what I've heard). My experience thus far is that your bottle-necks will come from not understanding or knowing how to use LUA properly :). I've made ALOT of mistakes, and its really affected my results. In the next version I can say that I won't have a single script for each object in the game world (or at least a possiable script) instead I'll make use of table based classes, co-routines, and dofile's to generate a better relationship between my scripting environment and my game world. Seperating everything out into multiple instances of LUA has caused more pain then pleasure, especially when I have to work between sprite or game object instances.

- Jeremy

Thanks for your input everyone! I've used LUA in projects before but never on the scale that I intend to with my current project. While waiting for some feedback here in the forums I got a simple engine running with all the lowel level stuff coded in C and accessable by higher level functions in lua and it seems to do ok. I did some simulated load testing blitting a bunch of sprites and it seems to be handling it.

Oh, good point EricmBrown about migrating stuff from lua to C if my scripts get bogged down... I'll definately put that to use.

Thanks again everybody!