脚本
目标、触发器、谜题
最后更新于
关卡设计师使用脚本工具来为关卡编写特定的游戏规则和行为。关卡脚本的一些常见示例包括：
目标、委托、任务——一系列有始有终的目标和遭遇战
触发器在进入某个区域时执行逻辑，以失去生命值或获得点数等。
门会阻碍玩家前进，直到玩家以某种方式解决游戏世界中的问题
可互动的游戏对象，如按钮、门、电梯、火车、陷阱等。
在游戏引擎的过去几个世代中，游戏引擎代码和游戏关卡的脚本逻辑之间存在很大的技术差异。
例如，Quake 1 的游戏引擎 idTech2 是用 C/QuakeC 编写的，而关卡脚本编写者依赖于已预定义行为的预制实体。例如func_button实体只能用作按钮，func_door实体只能用作滑动对象。如果设计师将门设计成向上“打开”的平面平台，那么门基本上就可以算作是电梯；这些另辟蹊径的技巧是有必要的，因为关卡设计师无法轻松编写新类型的实体。实体是特定于关卡的可视化脚本逻辑，以游戏引擎解释的数据形式存在。
对于现代游戏引擎来说，脚本编写越来越像文本和代码。虚幻引擎 5的蓝图可视化脚本在功能上与c++类似，Unity 的 Playmaker / Bolt 可视化脚本与 C# API 相匹配，辐射 4 / 上古卷轴5脚本编写者使用 Papyrus 语言，其他引擎则经常嵌入 Lua。现在基本上都是代码了。
因此：关卡脚本是只限于游戏关卡范围内的编码行为。脚本通常与地图中的特定对象或位置交互，绑定到特定实体。它们在此地图之外或跨不同地图的功能有限。与整个游戏的所有关卡共享的“硬”核心游戏代码相比，可以将其视为特定关卡独有的“软”代码。
脚本破解是一种一次性的脆弱解决方案，它以非预期的方式利用游戏系统，因此无法支持更广泛的其他行为，也无法在游戏的其他地方轻松复用。
这种脚本破解可能看起来很荒谬，但它确实有效，并且它为开发人员节省了大量时间，使他们不必专门为这些特殊的玩法来设计复杂的功能。所以有时破解是恰当的，但首先需要对项目规模进行足够的规划。在这个例子中，Bethesda的设计师已经规划好了他们的 DLC，所以他们知道编写一个他们永远不会再使用的火车系统是没有意义的，所以他们破解了一个假火车并成功交付了他们的项目。
委托、任务……通常由触发器和门组成
分支标志模型
以流程图的形式进行可视化，可能会变得非常复杂
触发器让我们定义体积和区域，并将行为应用于这些区域
触发器知道某物何时进入、停留和退出……触发器是一个事件
基本触发因素是陷阱、死亡、熔岩等，或打开一扇门
对于单人游戏，触发器应该是隐形的、无缝的，有时只是一次性触发器？
复杂触发器：像《Gone Home》里父母衣柜那样动态调整触发器的大小？
对于多人游戏，触发器不应该是隐形的！... CS 中的炸弹点区域，守望先锋中的捕获点
门是阻碍或阻挡玩家在关卡中移动的事物，通常是沿着主要路径。
尽管门的名字是“门”，但它并不只是门而已。关卡中几乎所有东西都可以充当门，因为任何阻碍进程或流程的障碍物（无论大小）都是一种门。
硬门是指不完成遭遇战或谜题就无法前进的情况。当我们只说“门”时，我们通常指的是硬门。
杀死所有怪物/boss来打开一扇门
按下所有按钮
找到钥匙
只有 NPC 想要开门时才可以开门（例如在战斗之外）
或者将所有这些连在一起...杀死一个怪物来获得一把钥匙，按下一个按钮来释放一个掉落钥匙的怪物，等等。
玩家可以绕过门而不完成遭遇战或谜题，但是强烈不鼓励他们这样做（例如怪物太多）
更复杂一些，更少的手动操作，可以更好地支持速通玩家……但如果玩家在不知不觉中不断绕过大门，不确定发生了什么，或者门太软以至于什么都不需要做，可能会让玩家感到混乱
非常柔软：视线受阻，发夹弯（见类型学）
软：简单的解密，堆叠盒子
较软：Valve式缓开门
软到破坏游戏：布局混乱，不清楚如何继续游戏（可能会让玩家感到很糟糕的“困惑”，而不是好的“困惑”）
怪物壁橱
导演人工智能
寻路节点、怪物跳跃、掩体节点、裁剪体积
为 NPC 和 AI 提供掩护提示
“高的红色方框是站立掩体（也称为“全”掩体，提供最大的保护），较小的粉色方框是低掩体（游戏中的半掩体）。每个掩体节点上的黄色箭头显示士兵在该掩体节点时可以从哪个角度射击。一些低掩体节点上方的黄色弯曲箭头表示士兵可以跳过掩体节点进入相邻侧的节点。精心放置掩体节点并严格遵守指标对于创建清晰、无误且按玩家期望运行的掩体设置至关重要。如果一块掩体太高，那么您将无法跳过它，如果掩体节点没有正确放置在角落，那么占据该节点的士兵将无法绕过角落射击。这两个例子都会让玩家感到沮丧，必须避免！”
当我们编写脚本让 NPC 执行超出其正常 AI 范围的特定操作时，尤其是游戏过场动画和故事叙述，这种类型的脚本称为编排。在大型团队项目中，角色编排可能是脚本编写者、动画师或专门的电影艺术家的职责。
常见的编排脚本动作包括：
NPC 演员的身体控制，如观察、转身、行走、说话。这种类型应与游戏 AI 挂钩到相同的身体系统，因为维护两个不同的行走系统会给您的项目带来额外的技术负担。
动画控制。完全覆盖默认的空闲姿势或当前的全身动画。例如，如果两个演员在游戏中拥抱一次，您不应该设计专门的拥抱系统——相反，您应该暂时用拥抱动作覆盖他们的动画。
道具和附件。将对象暂时绑定到角色关节，例如将帽子附加到头上，或将杯子附加到手上。
定时延迟。等待 X 秒，对于戏剧性的节奏或暂停很有用。
摄像机控制。强制第一人称控制器查看某物，或生成具有其他摄影角度的第三人称摄像机。
游戏状态管理。对于系统性或战斗导向的游戏，最佳做法是禁用编排演员的战斗 AI 和物理，以及暂停/阻止/删除附近的敌人，并使编排的 NPC 暂时无敌。如果您不管理和清理编排的游戏状态，那么您的演员可能会在过场动画期间意外倒下或死亡。
我们发布了一个针对“游戏认为我的同伴已经死亡”漏洞的修复程序，我相信我调查该漏洞所花的时间比我职业生涯中调查任何其他漏洞所花的时间都要多。
这个漏洞的本质是，对于一些玩家来说，同伴任务会在任务日志中被标记为失败，理由是同伴已经死亡——尽管事实上同伴还活着。这个漏洞很难确定的一个原因是，我们无法确定漏洞究竟是什么时候发生的——我们遇到的所有情况基本上都是“在过去的十个小时里发生了一些糟糕的事情，所以我的任务失败了”。
调查涉及找出每个脚本和代码行的位置，这些脚本和代码行可能会让游戏认为同伴已死亡。唯一合乎逻辑的罪魁祸首是当同伴的生命值达到零时运行的一段脚本：如果他们在队伍中，它会等待战斗结束并复活他们；否则它会将他们标记为“真正”死亡。但游戏中唯一一个同伴在场但不在活动队伍中的情况是玩家在船上时。问题是，当同伴在船上时，他们是不会受到伤害的。最终我们发现“不会受到伤害”并不意味着“无懈可击”——他们无法受到攻击的伤害，但仍然会受到其他东西的伤害。其中之一：从很高的地方坠落。
问题在于，玩家的飞船上没有足够高的地方导致致命坠落。所以现在我们必须弄清楚同伴们是如何神秘地到达高空的。我研究了大量理论，包括“也许他们的身高数据在从其他地图快速旅行时会保留”和“也许两个同伴之间的物理相互作用导致其中一个快速向上加速”。（我个人最喜欢的是“如果一个同伴站在随机事件中一头牛出现的地方，然后他们被发射到太空中会怎么样”。当这个理论没有成功时，我真的很沮丧。）到那时，游戏已经发布了，所有希望这只是一个只有少数开发人员才会遇到的奇怪巧合的希望都破灭了，因为各地的玩家都开始报告他们的同伴任务失败了。
最终，一位用户在评论中随口提到看到一个奇怪的错误，即同伴“什么都没爬”，这条评论让我弄清楚了整件事。
在开发方面，NPC 与环境交互的系统被称为“家具”。有时这是字面上的家具，比如坐在椅子上，但它涵盖了从使用终端到靠在墙上的一切交互。在家具系统这个复杂的庞然大物中，我们编写了代码，如果玩家正在交谈，则禁止所有 NPC 开始新的家具交互。
包含许多对话过场动画的大型项目（如角色扮演游戏）通常依赖半自动化工作流程来编写其编排脚本。他们的工具会自动为每场对话生成基本的过场动画脚本，因为手工制作数百（或数千）个简短的过场动画是不可行的。然后，编剧和动画师会通过额外的编排来完善最重要的场景，而 QA 测试人员会报告任何需要特别注意的低优先级编排错误。配音繁重的项目还需要调整每种配音语言的场景时间，而具有昼夜循环的游戏应该自动用更好的过场动画和特写镜头照明设置覆盖全局照明。
对于大型开放世界角色扮演游戏《巫师 3》（2015 年），开发商 CD Projekt Red 将任务工作流程分为四个阶段：（1）以剧本格式编写脚本和选择，（2）在可视化脚本流程图工具中为任务编写可能的分支和游戏状态脚本，（3）使用初步自动生成对话和编排，（4）后期制作，对过场动画进行修复和视觉润色。
对话设计工具的自动过场动画生成器在这里尤其有趣。它接收音频旁白并自动生成演员的音轨和时间，并采用半随机动画变化和遵循基本电影摄影模式（如正反打和 180 度规则）的标准镜头。结果是过场动画的基本起点已经基本完成，编排人员可以更专注于添加细节和氛围，而不是枯燥乏味地死记硬背设置基本内容。
有关 CDPR 编排工作流程的其他有趣细节：
编写脚本是一项创造性解决问题型的任务，与其他任何关卡设计任务类似。首先，你要了解问题，然后你要尝试各种方法。
做一些规划和研究。
对最基本的版本进行原型设计并进行游戏测试。
逐步迭代和完善脚本，直到满足您的需求。
与任何创造性任务一样，一点规划会大有帮助。在打开脚本编辑器之前，请花几分钟时间定义您希望脚本执行的操作。以下是规划文档的一些示例：
编写任务脚本？绘制流程图并标记带有任务位置的布局图。
编写对象或行为脚本？勾勒出其外观和各种状态/属性。
编写战斗或遭遇战脚本？请先进行遭遇战设计。
编写对话或过场动画脚本？编写脚本并绘制故事板。
接下来，通过谷歌搜索来研究实现该功能的各种方法。在谷歌搜索编程或技术脚本帮助时，请确保：
从技术角度上要具体。包括游戏或引擎名称以及脚本语言。将两者括在引号中，以要求搜索结果中包含这些术语。
概念上要通用。用通用术语描述所需行为。对于更复杂的功能，将问题分解为更小、更简单的部分，然后分别进行谷歌搜索。
搜索词的一些示例：
😢how to code a ceiling fan含糊不清（哪种代码语言？），通用性也非常差（你希望别人专门建造了一个虚拟吊扇）
😎"unity" "c#" spinning object code在技术上是特定的（我们只想要 Unity C# 代码），并且具有很有帮助的概括性（吊扇是一种旋转的东西），我们可以从通用示例中推断出我们的具体用例
😐game dev scripting objectives system可能会告诉你关于如何构建目标系统的观点，但不会提供任何具体帮助。你到底想编写哪种类型的游戏目标？没有搜索引擎可以为你设计游戏玩法。
如果我们将这个问题分解为更简单、更具体的步骤，并分别在 Google 上搜索这些较小的步骤，会怎么样？
😎帮助我们弄清楚如何通知玩家目标 "ue4" "blueprint" display text on screen
😎"ue4" "blueprint" player enters trigger帮助我们了解如何检测目标何时完成、玩家何时到达关卡中的某个位置等。
何时寻求帮助。除非你完全不知所措，否则在这个非常早期的阶段不要向其他人寻求帮助。尝试用你已经找到的东西自己做，看看你能走多远。当你有更具体的问题或有一些现有的脚本需要排除故障时，向别人寻求帮助会更好。要得到有用的答案，你必须首先了解问题。
在您完成一些搜索之后，您现在对问题有了更好的了解，并且准备在脚本工具中对该功能进行原型设计。
向社区成员寻求建议。加入特定引擎的论坛、网站或 Discord，然后提出您的问题。如果可能，请回顾您已经完成的研究并包括任何错误消息。以下是您可以发布的示例问题：
“我正在尝试制作一个可以运行的嘉年华旋转木马。我找到了这个 C# 代码来让一个物体旋转 (链接)，但当我尝试....
通常涉及生成/激怒敌人，以及迫使玩家处理敌人以打开大门
开始编写脚本之前：
在纸上设计一些遭遇战。在打开编辑器之前要有一个计划，哪怕是一个基本的计划。玩家在这次遭遇战中会使用什么武器或能力？
了解你的战斗指标。理想的敌人交战距离是多少？战斗规模有多大？
然后，放置一些 AI / NPC / 敌人并开始游玩
NPC 对现有空间有何反应？他们会做任何你想阻止的事情吗？
您可以使用哪些工具？静态、脚本化还是动态？
脚本是使用轻量级编程语言设计的特定关卡行为，通常使用特定于引擎的可视化编程工具。
脚本的常见特征包括目标、编排、触发器、门和AI。
使用谷歌搜索时，请包含引擎名称并使用通用术语进行搜索。
对于短期小型项目（<1 个月），最简单、最快的破解方法就足够了。
对于长期大型项目（6 个月以上），更稳定的系统方法更好。
例如，在《辐射 3》的 Broken Steel DLC 中，玩家在执行任务时需要修理并乘坐地铁列车。然而，游戏中没有任何实际的车辆或火车系统。相反，。通过脚本，游戏迫使玩家秘密装备一个名为“DLC03MetroCarArmor”的物品——一种执行相机脚本的臂章，让玩家感觉自己仿佛身处行驶的火车中。在《辐射 3》的 GECK 游戏编辑工具中，臂章看起来就像是一顶巨大的火车形帽子。（见下图）
——摘自 Splash Damage 博客文章
Taylor Swope 是《The Outer Worlds》（2019 年）的 QA 负责人，他花了很长时间尝试来调试 NPC 对象交互脚本问题
问题在于，使用梯子被视为两种不同的家具互动：一种是上梯子并开始攀爬，另一种是停止攀爬并下来。因此，如果有人开始爬梯子，而玩家在他们停止之前进入对话，他们将无法离开梯子，而且…… ——Taylor Swope (@_taylorswope)
游戏引擎往往具有用于编排的可视化轨道时间轴工具，如 (Unity) 或 (UE)。编剧和动画师设置不同的轨道，并将事件放置在每个轨道上。这样，游戏就可以将编排作为游戏资产而不是代码导入，从而避免任何耗时的重新编译并简化代码库。
如果您的项目没有或不需要专门的编排工具，那么仍然可以使用游戏脚本代码直接进行编排。使用诸如（Unity C#）或（Unity Bolt）或 / 节点（UE BP）之类的东西，按照您想要的时间顺序调用函数。当您需要在编排过程中完全访问所有脚本函数时，这种直接方法非常有用。想象一下编排100个NPC一次一个地穿过一扇门；这项任务在可视化工具中会是一项缓慢而痛苦的繁琐工作，但在具有for()循环和数组的脚本语言中却很简单。
虽然中并没有真正提到这种方法的缺点，但我们可以想象它的主要缺点是，它要求你完成并系统化大部分脚本、画外音录音和动画集，以便将其输入到生成器中。如果没有音频资产和接近完成的角色，生成器很难理解该做什么。与任何程序生成系统一样，它严重依赖于其输入，如果没有好的有意义的输入，它只会导致“”。
游戏的脚本和编排都是用英语编写的，但配音的长度显然会因语言而异。因此，对于每个本地化版本，编排和镜头序列都会自动加快或减慢；例如，法语编排比英语慢 16%。
为了防止 NPC 和野生动物打断过场动画，编舞人员遮挡了隐形碰撞盒/触发体积/“拒绝区域”，以推开非编排角色并保持镜头清晰。
大多数成熟的游戏引擎都有可视化脚本工具。Unity 使用，虚幻引擎 4 使用，Godot 有。请参阅以获取游戏及其脚本工具的完整列表。
虚幻脚本简介：，2021 年 11 月。
是一个 Tumblr 档案，其中包含使用虚幻引擎 4 的蓝图系统编写的混乱/粗糙的可视化编程图表。它很有趣，但也有点夸张；有时发布一个低效的脚本比设计一个耗时的“更好”的设计更有意义。如果一个更干净的方法快了 0.0001 毫秒，但制作时间却是原来的两倍，那么可以说它不是一个更好的脚本。
