Lua，游戏状态和游戏循环。

我的基本规则是针对 Lua 或者游戏中的任何脚本语言：

• 每帧中发生的所有事情：C++
• 异步事件 - 用户输入 - Lua
• 同步游戏引擎事件 - Lua

基本上，每秒被调用33-100次（根据帧率而定）的代码是 C++，我尽量在<10Hz 时调用脚本引擎。

基于任何实际指标吗？不是真的。但这确实在设计中划分了分界线，将 C++ 和 Lua 任务清晰地区分开来 - 没有这种最初的划分，每帧执行的 Lua 任务将会不断增长，直到它们每帧都很卡顿 - 然后就没有清晰的准则来决定需要修剪什么。

IMHO Lua 脚本用于特定的行为，如果您每秒调用 Lua 脚本 60 次，那么性能肯定会受到影响。

Lua 脚本通常用于将行为和特定事件与游戏引擎逻辑（GUI、物品、对话框、游戏引擎事件等）分离。例如，在触发爆炸（粒子特效）时，如果游戏角色走到某个地方，则在引擎中硬编码该事件的输出选择非常丑陋。但是，让引擎触发正确的脚本将是更好的选择，将该特定行为解耦离开您的引擎。

我建议尝试将您的游戏状态保留在一个部分中，而不是升级需要在两个地方（Lua 和引擎）同步状态的复杂性级别，并添加线程，否则您将最终得到非常丑陋的混乱。保持简单。 （在我的设计中，我大多数情况下将游戏状态保留在 C++ 中）

祝您的游戏好运！

Lua最好的地方在于它有一个轻量级的虚拟机，而且在预编译代码后，在虚拟机中运行它们实际上相当快，但仍然不如C++代码快，并且我认为每个渲染帧都调用Lua可能不是一个好主意。

我会将游戏状态放在C++中，并添加可以访问并修改状态的Lua函数。基于事件的方法通常更好，其中应在Lua中完成事件注册（最好在游戏开始时或特定游戏事件时完成，但不要超过每分钟几次），但实际事件应由C++代码触发。用户输入也是事件，它们通常不会在每一帧发生（除了可能是MouseMove，但应谨慎使用）。您如何处理用户输入事件（您是否在lua中处理所有内容，例如哪个键被按下等，或者是否例如对于键盘上的每个键有单独的事件（在极端情况下）取决于您要制作的游戏（回合制游戏可能只有一个事件处理程序处理所有事件，实时战略游戏应该有更多事件，FPS应谨慎处理（主要是因为每帧移动鼠标会使事件发生））。通常，您拥有的不同类型的事件越多，您需要在Lua中编写的代码就越少（这将提高性能），但是如果您需要处理的“真实事件”实际上由多个“编程级事件”触发，则问题可能会变得更加困难（这可能会降低性能，因为Lua代码需要更复杂）。

或者，如果性能确实很重要，您实际上可以通过为其添加新的操作码来改进Lua VM（我已经看到了一些公司这样做，但主要是为了使编译后的Lua代码更难解码），这实际上并不难。如果您有许多次需要Lua代码执行的操作（例如事件注册，事件运行或更改游戏状态），则可能需要在Lua VM中实现它们，这样它们将只需要一个或两个（例如，您可以创建一个带有0-255和0-65535参数的SETSTATE操作码，其中第一个参数描述要修改的状态，第二个描述状态的新值。当然，这仅适用于最多具有255个事件，最多具有2^16个值的情况，但在某些情况下可能足够。而且，这只需要一个操作码意味着代码运行得更快）。如果您打算混淆您的Lua代码，则这也会使解码更加困难（虽然了解Lua内部工作原理的人不会受到太大影响）。每帧运行几个操作码（最多约30-40）不会太影响性能。但是，在Lua VM中运行30-40个操作码不能让您做非常复杂的事情（一个简单的if-then-else根据表达式可能需要10-20或更多个操作码）。

我不喜欢C++，但我喜欢游戏。

我的做法可能有点不同寻常：我尽可能多地使用Lua来完成所有任务，只是用最少量的C++。游戏循环、实体等都是用Lua完成的。我甚至还用Lua实现了一个四叉树。C++则负责图形和文件系统等，以及与外部库进行接口交互。

这不是机器决定，而是程序员决定；在Lua中，我能够更快地输出代码而非在C++中。所以我将程序员的时间用于新功能的开发，而不是用于节约计算机资源。我的目标计算机（过去三年内的任何笔记本电脑）都能很容易地处理这么多的Lua代码。

Lua的占用空间令人惊讶（如果您不了解，请看一下[luaJIT]（http://luajit.org/））。

但话说回来，如果我发现了性能瓶颈（到目前为止我还没有发现），我会对游戏进行分析，找到慢的部分，并将该部分翻译成C++……仅当我无法找到使用Lua解决它的方法时。

大部分性能会因为Lua和C++之间的绑定而丢失。函数调用会需要被包装、重新包装，通常会多次这样做。对于小的操作，纯Lua或纯C++代码通常比混合代码更快。

话虽如此，我个人并没有在每帧运行Lua脚本时看到强烈的性能损失。

通常脚本编写适用于高级别操作。Lua已经被用于着名游戏的机器人（_Quake 3_）和用户界面（_World of Warcraft_）。使用在高级别上，Lua的微线程非常方便：协程可以节省很多的时间（与真实的线程相比）。例如只在一段时间内运行一些Lua代码。

关于性能问题：如果 main.lua 文件没有改变，可以使用 lua_loadfile 或者 loadfile 函数加载它一次，并保存返回函数的引用，需要时再调用即可。

我在一个我正在开发的游戏中第一次使用 Lua 。我的应用程序的 C++ 部分实际上持有每个游戏状态实例的指针。一些游戏状态是用 C++ 实现的，而一些是用 Lua 实现的（例如“游戏玩法”状态）。

更新和应用程序主循环存在于 C++ 方面。我已经公开了一些函数，允许 Lua VM 在运行时将新的游戏状态添加到应用程序中。

即使在资源有限的硬件上（Atom 处理器带有集成视频），我还没有遇到任何速度慢的问题。Lua 函数每帧被调用。在我的应用程序中，最昂贵（从时间上）的操作是渲染。

在 Lua 中完全能够创建新状态是我在项目中做出的最好决定之一，因为它允许我自由地添加游戏部分而不需要重新编译整个项目。

编辑：我使用的是 Luabind，我已经阅读过它的性能通常比其他绑定框架和当然是 Lua C API 更慢。

1. 你可能不希望在每一帧迭代中执行整个 Lua 脚本，因为任何足够复杂的游戏都会有多个具有自己行为的游戏对象。换句话说，除非你有处理较大游戏特定部分行为的多个小型脚本，否则 Lua 的优势就会丢失。你可以使用 lua_call 函数调用脚本中任何适当的 lua 例程，而不仅仅是整个文件。

2. 这里没有理想答案，但传统上大部分游戏状态都储存在游戏引擎（例如 C++）中。你向 Lua 揭示了足够让 Lua 执行你赋予 Lua 的决策功能的信息。

你需要考虑哪种语言适合哪些行为。Lua 对于高级控制和决策非常有用，而 C++ 对于性能导向的代码非常有用。例如，Lua 尤其适用于需要在不重新编译的情况下调整游戏的某些部分。所有魔术常数和变量都可以放入 Lua 中。不要试图在非其所属的领域中把 Lua 硬塞进去，例如图形或音频渲染。