I am aware of the post on this forum "Java and Lua" and the premise is very similar, but my question is different.

Basically, I'm not new to scripting; but I am new to Lua scripts and integrating it into my C++ programs. Now, I have already found libraries to do that, so everything's fine for that particular concept. My problem, is that I'm not sure what should be scripted. I understand the "logic" should be what's scripted, but I'm not visualizing it in my mind correctly. How should I separate the C++ classes and code from the LUA script's tasks?

Say I am making a 2D car game. The psuedo-C++ file of the car might look something like this:


class Car : public Drawable, Entity
{
public:
Car(...) { ... lua_do("CarLogic.lua") }

void onDraw() { ... }

void onUpdate( ... )

void onEnd() { ... }
}


I am assuming the script wouldn't do anything for onDraw() but am I on the right track for the rest of the functions? Also, what about other auxiliary functions I may want to add? Would I simply define them in the script? What would that look like for one script to define a class? I'm skeptical about the whole thing I suppose.

Thanks so much for any enlightenment on this.

personally, my approach when attempting to draw a line between what the script handles, and what does the engine handle, is such:

-i generally keep most drawing left to the engine, i allow my script to control what can be drawn(through flags), and the shape of the object, but i generally attempt to leave the actual draw pipeline to my engine.
-anything modular, if their is anything in the game i forsee that could be expanded dynamically, i try to leave it as much to my script as possible, i leave anything to do with updating(including the physic's aspect), collision management(although not collision detection), and finally, i generally have a resolve/create function, which do not directly create/destroy the object, but define/close anything that needs to be done.

at the end of the day, you need to make the decision between, "This is what my engine will handle", and "This is what lua will handle". lua can handle everything if you truly wanted, or it can handle just the small stuff(for example, variable interpolation techniques between animation frames.)

I'm leaning toward all in script scheme myself these days aswell with the advent of LuaJit and a home grown debugger.

Just downloaded! I didn't know there was a JIT compiler for Lua. I've been using Lua for about 3 years and remember seeing something about a Lua compiler called "Kore", IIRC. This was commercial software though and I never bothered with it. Lua's fast, so this should be pretty amazing!

Back OT to the OP, I'm big on prototyping so I make nearly everything accessible from Lua though I leave a lot of the heavy lifting to the applications systems. There's usually a single update call per system (renderer, physics, etc.) that handles things within the main game loop and many of those systems run in threads. All initialization and uninitialization is handled by Lua. I also have a master script written in Lua that initially loads and manages all scripts and other major details of the application.

I started off in Lua trying to embed it in a game application so that I could use it to run AI. Problem with this was that I had so many other things I wanted to use it for: defining game object behaviors, level map logic, menu systems, etc. So, I backtracked and started with a simple application that registered some functions for graphics and input and fired up the Lua VM. I used this to make a couple of simple Lua-based programs such as a star field, pong clone and stuff like that. This got me familiar with both the language and the API. I revamped the application I was working on and, rather than try to embed Lua into the application, I integrated the application into Lua, using the VM as the central core of the app. It's heavy-handed but there have been so many benefits in prototyping and saving time in general.