所以我在工作中一直在争论脚本语言在游戏开发中的正确角色。据我所知，对此有两种观点：
1) 脚本语言功能强大且功能齐全。大部分游戏代码都是用这种语言编写的，并且只有在性能要求有必要时才会将代码转移到 C++ 中。这通常类似于 Lua 或 Unrealscript。
2) 这种脚本语言非常有限。几乎所有的游戏代码都是 C++ 语言，该语言只是为了向设计人员公开底层功能。
我的沮丧来自于看到第二种方法经常被滥用，大型系统使用的语言不具备使代码可维护的特性。
所以我开始支持第一种方法，但在与一些设计师交谈后，我意识到他们中的许多人似乎更喜欢第二种方法，而且大多数程序员更喜欢第一种。
所以我仍然想知道哪种方法更好。我只是看到糟糕的代码并责怪工具而不是程序员，还是我们真的需要更复杂的工具？
【问题讨论】：
当您处理像视频游戏这样复杂的事情时，编译后的 C++ 代码的编译-链接-运行-测试周期非常非常慢。使用脚本引擎可以让您对游戏进行较大的功能更改，而无需编译程序。这是一个巨大的、大量的时间节省。正如你所说，需要优化的东西可以根据需要移到C++中。
AAA 引擎高度受脚本驱动。 Torque，用于 Tribes II（和许多其他游戏！）是脚本化的，Unreal 有 Unrealscript 等等。脚本不仅适用于模组，也是高效开发的关键。
【讨论】：
我认为设计师需要找到适合他们的语言。这是没有商量余地的：他们必须把时间花在设计上，而不是编程上。
如果脚本允许快速开发具有产品价值的游戏代码，那么程序员也应该这样做。但它必须具有产品价值：每件事都做两次并不能节省时间。因此，您必须保留脚本。如果开发人员可以在一周内编写库存系统脚本，或者在一个月内用 C++ 编写它，那么您需要功能齐全的脚本，如果只是为了给您更多时间来手动优化可能会达到性能限制的部分。所以不是库存，或者高分表，或者键映射系统，或者像角色应该做的那样的高级游戏逻辑。如果这样做可以节省您花在加速图形和物理上的任何时间，那么这一切都可以编写脚本：程序员需要能够准确地找出瓶颈是什么，并且高级程序员可以做出合理的预测'不会的。
设计师可能不应该知道或关心程序员是否使用脚本语言来实现游戏代码。他们不应该对（1）是好还是坏有意见。所以即使程序员想要（1）是对的，为什么这会给设计者带来不便呢？如果他们只需要相当少量的标准食谱，他们怎么会注意到脚本语言功能齐全？出了点问题，但我不认为 Lua 是一种太好的语言。
一种可能性是，对两者使用相同的脚本语言会成为在设计师使用的界面和游戏代码内部界面之间划清界限的障碍。正如我在顶部所说的那样，这是没有商量余地的。即使他们使用相同的脚本语言，程序员仍然必须为设计人员提供他们完成工作所需的功能。仅仅因为设计师使用 Lua 来编写 AI 策略和对话树，并且 Lua 是能够编写物理引擎的全功能语言，并不意味着您的设计师应该编写自己的物理引擎。或者使用超过 10% 的 Lua 功能。
请注意，您可能可以同时执行 (1) 和 (2)。没有理由不给程序员 Lua 和设计者一些功能不足的微型 DSL，这些 DSL 使用 Lua 脚本“编译”成 Lua。
【讨论】：
我认为你想要的平衡是这样的：你希望游戏逻辑在脚本中，但游戏功能在代码中。
脚本的一大优势是您可以轻松设置等待。例如：
enemy = GetObjectFromScene ("enemy01"); 在 5 秒内 { 敌人.ThrowGrenadeAt (玩家); }
只是一个人为的例子。这种逻辑在 C++ 中设置会很烦人。脚本可以更轻松地表达这种逻辑，但您希望实际功能（它调用的函数）在 C++ 中。
而且脚本没有 很慢。有大量脚本游戏在游戏机上以 60fps 的速度运行，但它需要良好的设计并在上述选项 1 和 2 之间找到适当的平衡。
【讨论】：
我看不出大量脚本代码将优于大量 C++ 的论点。有人可以提出反驳论点。我见过用脚本语言编写的可怕的大型项目，这些项目都是从脚本思维开始的——把事情完成得又快又脏。不幸的是，这不能很好地扩展。真的没有办法仅仅基于编程语言来进行代码质量论证。人们可以用任何语言编写大量可维护的代码，无论是编译的还是脚本的。
无论如何，如果不知道性能瓶颈在哪里以及用户最想“编写”什么脚本，就不可能知道“方法 1”和“方法 2”之间的界限。
我建议使用“方法 3”，即全部或部分使用 C++ 完成，并在 C++ 中公开一个干净的 SDK。这将具有强制您编写代码的优势，就好像它是您组织之外的人必须使用的用户界面一样。它有望使它更易于维护，并具有为您实现脚本接口的附加副作用。您现在需要做的所有脚本接口就是转发到您的 SDK。中提琴！
使用这种方法，您可以避免在“脚本化”领域与 C++ 领域之间划清界限。您和您的用户可以选择使用 SDK 添加 C++ 功能或使用脚本语言。
【讨论】：
像往常一样，我认为答案是“视情况而定”。
光环 3 或使命召唤 4 不可能主要基于脚本。从定义上讲，顶级 AAA 游戏必须突破他们所接触的任何平台的极限。脚本无法做到这一点。
然而，休闲游戏是另一回事。 Unity 等主要游戏引擎内置了大量脚本。
模组也有市场。具有良好脚本环境的可靠游戏引擎可以成为调整、衍生甚至在某些情况下全新游戏的平台。 Counter Strike 是我个人最喜欢的例子。我认为您在这种情况下仅限于 FPS 跑轰类游戏。
所以，在游戏中有一个脚本编写的地方，但它可能会留在小型/休闲游戏和模组开发者的空间。
【讨论】：
《文明 IV》是脚本编写的最佳示例之一。它使用 Boost Python。结果，它非常缓慢。与“当性能表明有必要时将代码移入 C++”这一说法的明显对立面。
正确的方法是预先设计架构，并确定哪些问题在计算上很困难，哪些问题很难预先指定。图形、物理、寻路、输入的即时反馈、文本到语音——所有这些显然都很难计算。 “友好或敌对姿态”、“防御或攻击”、“支出或储蓄”类型的 AI 决策都很难预先指定。
结论是，您希望将有能力但没有灵魂的演员暴露给您的脚本代码。脚本代码描述了演员应该做什么，但 C++ 代码负责如何。
关于编译链接周期，拥有适当的模块化架构非常重要。当您处理寻路逻辑时，您永远不必编译图形代码。此外，Incredibuild 等工具可以帮助加快编译时间。大型游戏公司可能已经有一个渲染农场，它可以作为编译农场翻倍。
【讨论】：
说游戏应该只用 C++ 完成（或声称 AAA 游戏就是这样完成的）只是无知。现在的大多数游戏都以某种方式编写脚本，无论是专有脚本语言（UnrealScript）、通用语言（Lua、python、C#、Java 等）还是数据驱动（xml、专有二进制格式等）。只需进行一些研究，您就会发现大多数引擎都以一种或另一种形式使用脚本。
我认为是否拥有 1) 功能强大且功能齐全的脚本语言与 2) 极其有限的脚本语言的问题正在从错误的角度解决问题。脚本环境（语言或数据驱动）的设计应使其能够最好地支持创建游戏的过程。系统的表现力在这里至关重要：设计者和脚本编写者应该能够轻松解决他们遇到的问题而不会太头疼，同时他们不应该接触到他们难以理解和学习的过于复杂的系统。通常程序员（包括我自己）倾向于通过假设系统将如何使用并试图确保地球和天堂之间的所有功能都可以实现来设计系统，从而导致复杂的系统。设计师被这种复杂性压得喘不过气来，最终使用最少的东西来完成工作。
例如，在我们的游戏 (Rochard) 中，我们设计了一个完全可扩展且可编写脚本的数据驱动 AI 系统，但关卡设计师最终只使用了现有的 AI 模式，因为他们没有时间或精力来利用人工智能系统发挥最大作用。所以最后我只是创建了一个很好的 UI 来轻松选择那些股票 AI 模式。
我想说这件事没有灵丹妙药。
【讨论】：
所以我开始支持方法 第一，但在与一些人交谈之后 设计师 我意识到他们中的许多人 似乎更喜欢第二个，它的 大多数是喜欢一个的程序员。
这应该是显而易见的：如果脚本语言“功能强大且功能齐全”，那么设计人员就有责任创建系统，因为他们可以利用这个机会。另一方面，如果脚本语言只暴露了硬编码游戏的小细节，那么程序员就必须创建这些系统，因为设计师做不到。我并不是说每一方都懒惰，但显然双方都有项目需要他们关注的个人技能（因为没有其他人可以有效地做到这一点），这意味着总是有兴趣让其他人完成给定的任务，如果可能。
然后自然而然地，合适的角色将取决于您公司的人力资源是如何布局的，以及您游戏的任何性能要求。一旦你知道有多少人需要任何类型的脚本，你就会知道有多少游戏需要它，因此可以决定界面需要多宽或多窄。正如上面 onebyone.livejournal.com 所述，这有助于确定语言的“域”。
（无论如何，我是一名专业的游戏开发人员，也是 Gamedev.net 上脚本语言论坛的版主。）
【讨论】：
游戏开发社区已经将脚本作为构建用户界面和调整 AI 响应的一种非常常见的方式。您可以在 Gamasutra 等网站上找到大量信息。有趣的是标准语言开始取代自定义解释器。
我想到的 AAA 游戏中最好的两个脚本示例是魔兽世界（使用 Lua）和 EvE Online（使用 Python）。 EvE 也在服务器端使用脚本：他们对 Stackless Python 进行了大量投资。
更新：由于多核，性能基本上不会成为问题。即使是低端机器最终也会拥有比显示器和型号更新所需的更多内核。您不妨将其中一个内核用于运行 UI 脚本解决方案。
【讨论】：
如前所述；使用脚本编写游戏逻辑，使用 C++ 编写游戏功能。例如，编写游戏模式脚本，但使用 C++ 进行渲染。
【讨论】：
如果我们将游戏分为两部分：引擎和实际游戏（设计）。
一个可靠的顶级游戏引擎很可能是用 C/C++ 编写的，有些人甚至使用汇编代码进一步优化。您可以使用特定的 CPU 指令为图形和物理做很多非常快速的事情。仅从脚本语言渲染大型景观或多个复杂对象时，无法获得性能。
就游戏本身而言，有很多方面可以用更慢但更高级别的编程语言来完成。 AI和其他游戏逻辑可以成功地用脚本编写。它可以加快开发速度，并以简单的方式为改装和社区扩展打开大门。
【讨论】：
我认为这里的海报支持方法#1 是正确的。这是一种更清洁的方法，尽管有设计师的抱怨，但仍会产生更好的长期效果。最后，代码将确定好game programming 从平庸（坏）。
【讨论】：