脚本语言在游戏编程中的作用

因此,我一直在讨论脚本语言在游戏开发中的正确作用.据我所知,有两种思想流派:

1)脚本语言功能强大且功能齐全.大部分游戏代码都是用语言编写的,代码只有在性能表明它是必要的时候才会被转移到C++中.这通常类似于Lua或Unrealscript.

2)这种脚本语言非常有限.几乎所有的游戏代码都是用C++编写的,语言只是为了向设计人员公开底层功能.

我的挫折感来自于看到经常被滥用的第二种方法,大型系统以一种语言实现,该语言没有使该代码可维护的功能.

所以我开始支持第一种方法,但在与一些设计师交谈之后,我意识到他们中的许多人似乎更喜欢第二种,而且大部分程序员更喜欢一种.

所以我仍然想知道哪种方法更好.我只是看到错误的代码并指责工具而不是程序员,还是我们真的需要一个更复杂的工具？

当你处理像视频游戏一样复杂的东西时,编译的C++代码的编译链接运行测试周期非常非常慢.使用脚本引擎可以让您对游戏进行大的功能更改,而无需编译程序.这是一个巨大的,大量的时间节省.正如您所说,需要优化的东西可以根据需要移动到C++中.

AAA引擎受脚本编写的高度推动.Torque,用于Tribes II(以及许多其他游戏!)是脚本化的,Unreal有Unrealscript等等.脚本不仅适用于mod,它是高效开发的关键.

我认为设计师需要看到适合他们的语言.这是不可协商的:他们必须花时间设计,而不是编程.

如果脚本允许快速开发具有产品价值的游戏代码,那么程序员也应该这样做.但它必须具有产品价值:做两次都不能节省时间.因此,您必须将脚本保留在原位.如果开发人员可以在一周内编写库存系统脚本,或者在一个月内用C++编写,那么您需要功能全面的脚本,如果只是为了给您更多时间来手动优化可能会达到性能限制的部件.所以不是库存,高分表,键映射系统,或高级游戏逻辑,如角色应该做的事情.如果这样做可以节省您花在加速图形和物理上的任何时间,那么这些都可以编写脚本:程序员需要能够确切地解决瓶颈问题,

设计人员可能不应该知道或关心程序员是否使用脚本语言来实现游戏代码.他们不应该(1)是好还是坏.所以,即使程序员想要(1),为什么这会给设计师带来不便呢？他们甚至注意到脚本语言是全功能的,如果他们只需要相当少量的标准配方？出了点问题,但我认为Lua不是一个好的语言.

一种可能性是,对两者使用相同的脚本语言,成为在设计者使用的接口和游戏代码内部接口之间划清界限的障碍.正如我在顶部所说的那样,这是不容谈判的.即使他们使用相同的脚本语言,程序员仍然必须为设计人员提供他们完成工作所需的功能.仅仅因为设计师使用Lua编写AI策略和对话树,而Lua是能够编写物理引擎的全功能语言,并不意味着您的设计师需要编写自己的物理引擎.或者使用超过10%的Lua功能.

你可以同时做(1)和(2).没有理由你不能给程序员Lua和设计师一些微型功能不足的DSL,它用Lua脚本"编译"到Lua中.

我认为你想要的平衡是这样的:你需要脚本中的游戏逻辑,但需要代码中的游戏功能.

脚本的一大优势是可以轻松设置等待.例如:

enemy = GetObjectFromScene("enemy01"); 在5秒内{enemy.ThrowGrenadeAt(玩家); }

只是一个人为的例子.这种逻辑在C++中设置会很烦人.脚本可以更容易表达这种逻辑,但是你想要实际的功能(它调用的函数)是在C++中.

和脚本不具有缓慢.在游戏机上以60fps运行大量脚本游戏,但它需要良好的设计并在上面的选项1和2之间找到适当的平衡.

我无法真正看到大量脚本代码优于大量C++的论点.人们可以提出反驳论点.我已经看到了用脚本语言编写的可怕的大型项目,这些项目始于脚本的心态 - 让事情快速而肮脏.遗憾的是,这不能很好地扩展.实际上没有办法仅仅基于编程语言来制作代码质量参数.人们可以用任何语言编写可维护代码,编译或编写脚本.

无论如何,在不知道性能瓶颈在哪里以及用户最想要"编写脚本"的情况下,真的不可能知道"方法1"和"方法2"之间的界限.

我建议使用"方法3"来完成或部分使用C++,并在C++中公开一个干净的SDK.这样做的好处是可以强制您编写代码,就好像它是组织外部的用户界面必须使用的那样.它有望使其更易于维护,并为您实现脚本界面带来额外的副作用.您现在需要的所有脚本界面都转发到SDK.中提琴!

使用这种方法,您可以避免在"脚本化"与"C++"之间划分界限.您和您的用户可以选择使用SDK添加C++功能或使用脚本语言.