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

我认为设计师需要看到一种适合他们的语言。这是不可谈判的:他们必须花时间设计,而不是编程。

如果脚本允许快速开发有价值的产品游戏代码,那么程序员也应该这样做。但它必须有产品价值:每做两次都不会节省时间。所以您必须保持脚本的位置。如果开发人员可以在一周内编写清单系统,或者在一个月内用C++编写,那么你需要全功能脚本,如果只是给你更多的时间来优化可能会达到性能极限的部分。所以不是库存,或者高分表,或者关键映射系统,或者像角色应该做的那样的高级游戏逻辑。如果这样做可以节省你花在加速图形和物理上的任何时间,所有这些都可以被编写成脚本:程序员需要能够精确地计算出瓶颈是什么,而高级程序员可以做出一个合理的预测。

设计者可能不应该知道或关心程序员是否在使用脚本语言来实现游戏代码。他们不应该对(1)是好是坏有意见。所以,即使程序员想要的是正确的(1),为什么这会给设计师带来不便?他们怎么会注意到脚本语言是全功能的,如果他们所需要的只是相当少的标准配方的话?出了点问题,但我不认为Lua语言太好了。

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

你可以同时做(1)和(2),注意。你没有理由不能给程序员Lua,设计师们也可以在特色DSL下做一些小模型,这些DSL是用Lua脚本“编译”成Lua的。

当你处理像视频游戏那样复杂的事情时,编译的C++运行代码测试循环非常慢。使用脚本引擎可以在不编译程序的情况下对游戏进行较大的功能更改。这节省了大量的时间。正如你所说的,需要优化的东西可以根据需要移动到C++中。

AAA引擎是由脚本驱动的。扭矩,用于部落II(和许多其他游戏!)是写剧本的,不真实的有不真实的等等。脚本编写不仅适用于mods,而且是高效开发的关键。

我认为你想要的平衡就是这种效果:你想要游戏 逻辑 在剧本里,但是游戏 功能 在代码中。

脚本的一个很大的优点是可以轻松设置等待。例如:

敌人=GetObjectFromScene(“enemy01”); 在5秒内敌人.throwgrenadeat(玩家);

只是一个做作的例子。这种逻辑在C++中会很烦人。脚本可以更容易地表达这种逻辑,但是您希望实际的功能(它所调用的函数)在C++中。

脚本没有 有 慢慢来。在游戏机上,有大量脚本化的游戏以每秒60帧的速度运行,但它需要一个好的设计,并在上面的选项1和2之间找到正确的平衡。

我真的无法看到大量脚本代码要优于大量C++的说法。我们可以进行反驳。我见过用脚本语言编写的可怕的大型项目,它们从脚本思想开始——让事情快速而肮脏地完成。不幸的是,这并不能很好地扩展。没有办法仅仅基于编程语言来进行代码质量的论证。人们可以用任何语言编写大量可维护的代码,可以编译或编写脚本。

无论如何,在不知道性能瓶颈在哪里以及用户最想“编写脚本”的情况下,很难知道“方法1”和“方法2”之间的界限。

我建议一个“方法3”,它是在C++中全部或部分地进行,并在C++中公开一个干净的SDK。这样做的好处是,迫使您编写代码,就好像它是一个用户界面,组织外部的人必须使用它一样。希望它能使它更易于维护,并具有为您实现脚本接口的附加副作用。现在需要做的所有脚本接口都将转发到您的SDK。Viola!

通过这种方法,你可以避免在“脚本”和C++中的某个领域之间划一条线。您和您的用户可以选择在SDK中添加功能,或者使用脚本语言。

和往常一样,我认为答案是“视情况而定”。

Halo3和CallofDuty 4不可能主要基于脚本。最受欢迎的AAA级游戏必须,通过定义,推动他们接触的任何平台的信封。这不能用脚本来完成。

然而,休闲游戏则是另一回事。像Unity这样的主要游戏环境内置了很多脚本。

还有一个mods市场。一个具有良好脚本环境的稳定的游戏引擎可以作为调整、派生和在某些情况下全新游戏的平台。反恐精英是我个人最喜欢的例子。我认为在这种情况下,你只能玩FPS跑步和枪类游戏。

因此,在游戏中有一个脚本编写的地方,但它可能会停留在小型/休闲游戏和modder的空间中。

在实际中编写脚本的最好例子之一是文明四,它使用了Boostpython。结果,速度慢得可怕。一个明确的对应点,即“当性能指示有必要时,代码被移动到C++中”。

正确的方法是从前面设计一个体系结构,并决定哪些问题难以计算,哪些问题很复杂,需要预先指定。图形、物理、寻路、输入即时反馈、文本到语音——所有这些都是很难计算的。”友好或敌对的姿态,“防御或攻击”,“花费或保存”类型的人工智能决策都是复杂的,需要预先指定。

结论是,您希望向脚本代码公开有能力但没有灵魂的参与者。脚本代码描述 什么 演员应该做的,但是C++代码负责 怎样 .

对于编译链接周期,有一个适当的模块化结构是很重要的。当您在进行寻路逻辑时,您不应该编译图形代码。此外,像incredibuild这样的工具可以帮助加快编译时间。大型游戏公司可能已经有了一个渲染场,这个渲染场可以和编译场相当好地翻倍。

说游戏应该用C++来完成(或者声称AAA标题是这样做的)只是无知而已。现在大多数游戏都是以某种方式编写脚本的,它是专有脚本语言(unRealScript)、泛型语言(Lua、Python、Cype、Java等)或数据驱动(XML、专有二进制格式等)。只要做一些研究,你就会发现大多数引擎都使用这种或那种形式的脚本。

我认为,是否要有1)功能强大、功能齐全的脚本语言与2)极其有限的脚本语言的问题正从错误的角度来解决这个问题。脚本环境(语言或数据驱动)的设计应该能够最好地支持创建游戏的过程。系统的表现力在这里是至关重要的:设计师和编剧应该能够轻松地解决他们所遇到的问题,而不会感到太多的头痛,同时他们不应该暴露在太复杂的系统中,因为他们很难理解和学习。通常,程序员(包括我自己)倾向于通过假设如何使用系统来设计系统,并试图确保地球和天堂之间的所有特性都可以实现,从而产生复杂的系统。由于被这种复杂性所压倒,设计人员最终使用最小值来完成工作。

例如在我们的游戏中( Rochard )我们设计了一个完全可扩展和可脚本化的数据驱动的人工智能系统,但是级别设计人员最终只使用库存人工智能模式,因为他们没有时间或精力充分利用人工智能系统。所以最后我创建了一个很好的用户界面来轻松地选择那些库存人工智能模式。

我想说在这件事上没有银弹。

所以我开始支持这个方法 第一,但在和一些人交谈之后 设计师们我意识到他们中的许多人 似乎更喜欢第二,它 大多数程序员都喜欢这样。

这应该是显而易见的:如果脚本语言“功能强大且功能全面”,那么设计人员就有责任创建系统,因为他们可以利用这个机会。另一方面,如果脚本语言只公开硬编码游戏的小细节,那么程序员必须创建那些系统,因为设计者不能。我不是说每一方都懒惰,但很明显,双方都拥有项目要求他们关注的个人技能(因为没有其他人能够有效地完成这些技能),这意味着如果可能的话,总是有兴趣让其他人完成给定的任务。

当然,根据这一点,正确的角色将取决于你公司的人力资源如何配置,以及你游戏的任何性能要求。一旦你知道有多少人需要任何类型的脚本,你就会知道游戏中有多少人需要它,因此你可以决定界面需要多宽或多窄。正如上面的onebyone.livejournal.com所提到的,这有助于语言的“领域”。

(我是一个专业的游戏开发人员,也是gamedev.net上脚本语言论坛的负责人,这一点毫无价值。)

游戏开发社区已经使用脚本作为构建用户界面和调整人工智能响应的一种非常常见的方法。你可以在Gamasutra这样的网站上找到很多信息。有趣的是,标准语言开始取代自定义的解释程序。

AAA游戏中的两个最好的脚本例子是魔兽世界(使用lua)和在线夏娃(使用python)。EVE也在服务器端使用脚本:他们在无堆栈的Python上有很大的投资。

更新:由于多核,性能基本上是没有问题的。即使是低端机器最终也将拥有比显示和模型更新所需更多的核心。您也可以将这些核心中的一个用于运行UI的脚本解决方案。

如前所述,使用游戏逻辑脚本和C++游戏功能。一个例子是编写一个游戏模式,但是用C++来渲染。

如果我们把游戏分成两部分:引擎和实际游戏(设计)。

一个实用型的顶级游戏引擎最有可能是用C/C++编写的,有些人甚至用汇编代码进一步优化。你可以用特定的CPU指令为图形和物理做很多非常简单、非常快速的工作。在仅从脚本语言呈现大型景观或多个复杂对象时,无法获得性能。

当涉及到游戏本身时,有许多方面可以用较慢但更高级的编程语言来完成。人工智能和其他游戏逻辑可以成功地用脚本编写。它可以加快发展,并以一种简单的方式为改造和社区扩张打开大门。

我认为这里的海报对方法1有利。这是一种更清洁的方法,尽管设计师抱怨,但会产生更好的长期效果。最后,代码将确定良好 game programming 从平庸(坏)。