嵌入式脚本语言深层原理答案

【问题标题】：embedded scripting language deep rationale嵌入式脚本语言深层原理
【发布时间】：2013-11-05 13:03:29
【问题描述】：

我的问题是指：

Scripting languages and Game Dev/Programming

我想问的是将脚本语言嵌入游戏的深层原理。如果您查看维基百科：

http://en.wikipedia.org/wiki/Freescape

然后您可以看到 80 年代的 3D 引擎使用嵌入式脚本语言。例如，在 ZX Spectrum 48 上运行的游戏有一个用于脚本语言的嵌入式解释器。长期以来，脚本语言的嵌入一直很流行，这似乎暗示着将脚本语言嵌入到游戏中是有根深蒂固的原因的。从 80 年代一直到现在，有什么理由这样做？还是改变了原因？参考问题中给出的答案不可能全部适用于过去计算时代的情况。

【问题讨论】：

我认为引用问题中给出的答案确实适用于过去的计算时代。
@lhf 你够大知道吗？ :)

标签： game-engine scripting-language 8-bit

【解决方案1】：

我不是很了解过去的所有原因，但我可以想象现在所有的原因都适用于 80 年代硬件/工具的游戏开发。重用“组件”并对其进行编辑更容易、更快捷，并且可以更轻松地完成不同的任务。

脚本可以制作更好的游戏原型。有时为了测试一些新功能或配置而编译您的（原型）游戏需要很长时间。脚本允许即时重新编程和（重新）测试您需要的内容。现在并没有太大的不同。似乎原因并没有太大变化。主要原因可能仍然存在，因为游戏（在特殊的“三 A”游戏中）比以前复杂得多。

【讨论】：

【解决方案2】：

脚本的所有好处现在同样适用。因此，您可以立即奖励积分：

关注点分离 — 关卡设计师和引擎程序员几乎不需要说话，因为特定游戏成为了与代码主体分开的项目；和
更快的原型设计和实验 — Freescape 的脚本语言被编译成字节码，但相对于整个游戏的重量而言，脚本往往非常短，因此尝试更改更快。

此外，Freescape 引擎在当时是一项巨大而昂贵的开发——他们花了 14 个月的时间来开发它，而大多数现代产品只花了一两个月。编写所有游戏逻辑的脚本为他们实现了一个重要的次要目标：可移植性。

第一款 Freescape 游戏 Driller 在其所有版本中使用完全相同的数据和脚本。他们必须为 Spectrum、CPC、C64、Amiga 和 PC（总共四种 CPU 架构，用于需要用汇编语言编写的项目）构建它，但一旦完成，游戏逻辑一次编写，随处运行——构建后续游戏并同时全面发布它们变得非常容易。

算上 3D 构建工具包，在接下来的四年里，他们成功地发布了五款主要游戏和两款次要游戏（Total Eclipse II 和 Castle Master II，两者都是为了重新发布主要游戏）。

现在可移植性已经不是什么大问题了，因为人们使用更高级的语言并且通常与硬件隔离，但原型设计和分离与以往一样重要。

【讨论】：

“关注点分离”是指关卡设计师应该能够在没有引擎程序员的情况下创建游戏？
是的——脚本语言定义了关卡和引擎之间的接口，这样一组人就可以指定某人会识别为游戏的所有内容，即关卡以及当你采取不同行动时会发生什么，而另一群人只关心如何将文件从磁盘和像素移到屏幕上。