Lua与C++：职责分离

开始小型化。允许访问游戏实体，以便执行特定于地图 / 关卡的脚本。跨地图 / 关卡保持一致的行为可能不需要编写脚本。

此外，只允许访问对象的公共接口。

我的方法是尽可能限制 Lua 可访问的内容。我从未发现过需要一个类似于“main”之类的函数，每次渲染场景（或更多时）都需要调用。一些 Lua 引擎（如 LOVE）确实会这样做。我更喜欢为常见事件定义具有可选回调函数的对象，例如碰撞、鼠标单击、进入或离开游戏世界等等。

最终结果是非常声明式的，几乎类似于对象的配置文件。我有一个用于创建类或对象类型的函数，另一个用于基于这些类型创建对象。然后，这些对象具有可以在响应各种事件时调用的一系列方法。所有这些 Lua 方法映射到 C / C++ 方法，反过来修改对象的私有属性。这里是一个捕捉球对象的桶对象的示例：

define {
    name='ball';
    texture=png('images/orb.png');
    model='active';
    shape='circle';
    radius=16;
    mass=1.0;
    elastic=.7;
    friction=.4;
}

define {
    name='bucket';
    model='active';
    mass=1;
    shape='rect';
    width=60;
    height=52;
    texture=png('images/bucket.png');
    elastic=.5;
    friction=.4;
    oncontact = function(self, data)
        if data.subject:type() == 'ball' then
            local a = data.subject:angleTo(self:getxy())
            if a < 130 and a > 50 then
                --update score etc..
            end
        end
    end;
}

我不会将其视为实现脚本 API 的“唯一正确方法”。 Lua 的美妙之处之一就是它支持许多不同的 API 风格。这只是我发现适用于制作的游戏（2D 物理游戏）的方法。

我建议这样分类：

1. 极端变种：Lua 脚本控制一切（游戏逻辑、图形、人工智能等）。更甚的是：脚本作为主程序，拥有游戏循环。一些引擎会这么做。最坏的情况：完全没有分工，也没有脚本安全性。

2. Lua 脚本维护游戏状态并处理游戏逻辑。可能在每个游戏循环迭代中都会被调用。

3. Lua 脚本很少用于初始化、配置、回调。主程序为脚本提供（绑定）极简接口。因此脚本是由这些精心设计和提供的模块构建而成。