I assume you're talking about attaching a script to the actor that can update their position? This kind of thing is fairly common. The thing you usually have to watch out for is performance, but that's true of any system that relies of per-frame updates.

One pitfall is crossing the C++/Script boundary too much. You really want to cross that boundary as little as possible. For example, let's say you have 100 objects, each with a Lua Update() function as you described. You could spawn 100 Process objects that each links to an actor to call the appropriate Update() function. This would cause you to cross the C++/Lua boundary 100 times. Another approach is to create a manager in Lua that maintains a list to all of these objects. You have one C++ Process that just calls into the Lua object manager, which in turn loops through all objects and calls Update(). The effect is the same, but the second method is MUCH faster because it only crosses that boundary once.

In GCC, I show you how to write the ScriptProcess class. Really, there should only ever be a single ScriptProcess object. It should call into Lua to tick the script system and, ideally, that should be the only place where you cross that boundary and call into Lua.

Calling into C++ from Lua is also slow, but it's generally faster than whatever you were trying to do in Lua. For example, it's common to write complex math functions in C++ and have Lua call them. The overhead of doing this, especially since you're often using primitives, is still faster than executing the function in Lua in the first place.

-Rez

Yeah, physics systems don't do well with shifting frame rates. They generally prefer to be completely deterministic and when your frame rate slows to a crawl, they get confused. The Box2D documentation talks about this a bit.

Scripting systems give you a lot of flexibility and power, but the cost is performance. Still, I'm betting that there are some simple optimizations you can make to speed that up, like not crossing the Lua / C++ boundary so much. One thing you can do is not update objects every frame. On The Sims, every single sim has a set of stats that constantly decay, like hunger, energy, social, fun, etc. I don't loop through every motive and decay them based on a delta every frame, that would be too slow. Instead, I set up callbacks that are triggered when the Sim reaches an "interesting" value. Even on The Sims 3 and The Sims Medieval where there were constantly updating meters, they were only decayed about once a second. These kinds of optimizations can really help. It might be worth running your game through a profiler to see where all your time is going.

-Rez